There are lots of potentially good languages. But some of the scripting (interpreted) ones, can be rather inefficient at their cpu processing time consumption. But it gets complicated with languages like Java, or others, when they use JIT and stuff, because that can compile it on the fly, to be approaching or maybe even faster (because of late, run time compiling, knowing what is going on), than even compiled C/C++ code.
That's why I say it is possible to use script languages. I'm a big fan of JIT. I'm now working on a finite element engine that is supposed to support user expression input, and apparently it is not appropriate to run a string expression evaluation program in each iteration on each dynamic material of each meshed unit. Also, this allows me to implement AVX or SSE whenever these extensions are available without forcing the users to know how to program on SIMD. I can not imagine how slow the program is if I did not use JIT (actually bytecode based solution is kinda okay also, but string parsing is just plain horrible), despite I have to say writing a JIT compiler, even only for math expressions, is not easy.
You'd probably find if you write more JIT compiler sub-sections. You would find it gets much quicker and easier each time (hopefully, your mileage may vary).
I'm wondering how good AVX-512 is going to be (ignoring Knights based computers), when it eventually surfaces. Then an even longer wait until it comes to mainstream, I7 etc cpus. (if at all, depending on how Intel are planning on doing things).
Yes, that is an amazing use of JIT. Just the sort of thing, which would give a HUGE speed up factor.
Essentially a typical C/C++ program would re-interpret it each pass. Potentially taking ages. But a high/top end C/C++ programmer, may have ideas, to significantly speed up that process, WITHOUT JIT.
E.g. to translate the reg ex (etc), into what amounts to a large look-up table of function pointers.
So Pass1 (When the C/C++) runs, would interpret the reg-ex into array(s) of function pointers, and stuff.
Then on pass2..etc, the C/C++ can directly access the already interpreted reg-ex, by calling the array of function pointers, directly.
There are other ways of doing it, fast. I may NOT know enough about the specifics of what you are doing, to correctly describe a very fast non-JIT solution. So my apologies in advance. I could easily be misunderstanding your requirements.
There are often/usually MANY ways of doing things quickly and efficiently.
There have been Basic (language) interpreters, which do a similar thing. I.e. as they run through the code (interpreting it), it remembers what it needs to do. So after it has run for a while, it considerably speeds up, as it mostly ignores the source code, and directly does what it needed to do, directly. If I remember correctly, I think it went as far as remembering the actual machine code to perform, for each line. If I'm mistaken then it was a JVM (bytecode) like (p-code), mechanism instead.
BUT I have to concede that if your JIT solution, means that it goes to SSE/AVX/AVX2 (or whatever). It could still potentially beat even a fairly well written C/C++ program. The array of function pointers, is probably significantly slower than JIT compiled code, as the JIT can just put the desired/needed instructions, straight into the new code.
So on second thoughts, this JIT thing, could still be a dramatic speed/efficiency improvement.