Likely because V8 only works on platforms where JIT is possible, so the regex engine relies on JITting specialized native code for the regex. A portable C/C++ regex library can't really do that.
It's not JavaScript bytecode, but regex bytecode. V8 parses regular expressions to regex ASTs, takes them through some more intermediate forms, then finally to a special regex bytecode. That bytecode is either interpreted, or JIT compiled (depending of some build options, I think).
You can look at a list of bytecodes in [1], and at the x64 JIT in [2].
But it does show how good V8 is at optimizing out the JS part of JS when it's irrelevant to the computation, and it shows how well-optimized the regexps in V8 are.
None of this is terribly surprising given V8's use case, but only a few years back this would have been a ridiculous result. I enjoyed taking a minute to reflect on that.
No, V8's regex library is not written in C. V8 compiles its regular expressions to machine code at runtime. The availability of the compiler at runtime can be a liability for things like startup time or memory use, but can also be a key advantage in situations like regular expression parsing or packet processing.
Regular expressions are part of the JavaScript language, so they're as much "written in JavaScript" as any other language construct.
The point is that a regular expression compiled by V8 (which is not written in JavaScript) is faster than a regular expression as compiled by some particular C compiler. Of course a C compiler could possibly be written to understand calls to a standard regexp API and compile those to binary.
You need a regex library to turn a regex into machine code. What the parent means is that the V8 regex library compiles them, while the one used in the C code merely interprets the regex.
(The C and C++ thing is just adding confusion here)
Reading through the responses to this comment, the upshot w.r.t regex performance is that it's a significant advantage to have native regex support in a language. Because C doesn't the regex ultimately has to be translated into C at parse time, whereas with Javascript the regex is converted to machinecode at run time.
This is similar to the advantage of abstraction layers in general, although there's a cost if you create abstraction layers for things no-one much cares about.
The V8 version used nearly 50% more memory than the C version. It is well known that you can often get faster execution times at the cost of increased memory usage.
Go not only uses a different library for processing regular expressions, but a different algorithm altogether. It is slower in some cases than the standard PCRE implementations but faster in others.
Rather than argue back and forth about which regex implementation is better here, I'd simply note the absence of multicore numbers for V8 and that the crappy Tcl library beats single-threaded Javascript when run multicore.
It would be interesting, however, to compare the performance here to that of the "grep" command on the same expressions. I'd be surprised at anything short of a total smackdown of Javascript V8.
I would expect an even bigger smackdown if one invoked GPUs:
The idea was obviously to pick a test and environment that would make it look like V8 can beat something other than interpreted JS. Otherwise it would've been the complete package: string manipulation, numerical computation, multi-core etc.
36 comments
[ 3.1 ms ] story [ 81.6 ms ] thread(And the program is IMHO clearer than the C implementation)
Disclaimer: I had anything to do with this, I just thought it was interesting enough to post it.
JS: http://benchmarksgame.alioth.debian.org/u64/program.php?test...
C: http://benchmarksgame.alioth.debian.org/u64/program.php?test...
I'll go out on a limb here and claim that this C program is not the shortest possible equivalent to the JS version.
http://benchmarksgame.alioth.debian.org/u64/program.php?test...
http://benchmarksgame.alioth.debian.org/u64/program.php?test...
Hardly surprising.
This is V8 calling a regexp library written in C++. C just happens to be using a different library that is slower.
But it also beat the C++ implementation though.
Please, let me know if you find the opposite.
[1] http://blog.chromium.org/2009/02/irregexp-google-chromes-new...
I was thinking: but V8 doesn't have byte code.
Then opened the link:
"After optimization we generate native machine code which uses backtracking to try different alternatives."
http://v8.googlecode.com/svn/trunk/src/interpreter-irregexp....
Skimming the code it does look like they are interpreting byte code from Irregexp but I would need to read further to say it for sure.
1 - http://code.google.com/p/v8/source/browse/trunk/src/bytecode...
2 - http://code.google.com/p/v8/source/browse/trunk/src/x64/rege...
But it does show how good V8 is at optimizing out the JS part of JS when it's irrelevant to the computation, and it shows how well-optimized the regexps in V8 are.
None of this is terribly surprising given V8's use case, but only a few years back this would have been a ridiculous result. I enjoyed taking a minute to reflect on that.
The point is that a regular expression compiled by V8 (which is not written in JavaScript) is faster than a regular expression as compiled by some particular C compiler. Of course a C compiler could possibly be written to understand calls to a standard regexp API and compile those to binary.
(The C and C++ thing is just adding confusion here)
This is similar to the advantage of abstraction layers in general, although there's a cost if you create abstraction layers for things no-one much cares about.
http://code.google.com/p/re2/
http://benchmarksgame.alioth.debian.org/u64/program.php?test...
It would be interesting, however, to compare the performance here to that of the "grep" command on the same expressions. I'd be surprised at anything short of a total smackdown of Javascript V8.
I would expect an even bigger smackdown if one invoked GPUs:
http://bkase.github.io/CUDA-grep/finalreport.html
Even more interesting would be an OpenCL implementation that did exactly what V8 is doing to the regexes (Why? Because it can).
And total aside, this is why I don't participate in TopCoder competitions - they never let you have any real fun.