9 ms·

I am extremely doubtful that optimized C is going to be equally performant as optimized JavaScript. There is innate overhead when using an interpreted language,

I am extremely doubtful that optimized C is going to be equally performant as optimized JavaScript. There is innate overhead when using an interpreted language, no matter how advanced the interpreter. JavaScript is also garbage collected, while C is not, adding an additional level of overhead. At no point in this article are we shown the code of this new parser. We are also told that is incomplete. So we have a parser which we can't see and which is not finished, but apparently dominates its C counterpart in performance. This leads to me to believe one of two things: 1. The parser isn't complete, and its unimplemented functionality is going to be more expensive in terms of performance than the author anticipated, thus rendering his preliminary results void. 2. The implementation of the C extension he is comparing against is not very well optimized. As said above, I find it very hard to believe that well optimized C is going to be beaten by well optimized JavaScript.

Jare 14y ago
From the article: > JavaScript will no longer be the bottleneck. At this point the main cost is turning network data into JavaScript objects. This cost is equal for JavaScript libraries, as well as for C++ addons making V8 calls. Also, when a single client can process 5000 MBit/s utilizing a single CPU, your MySQL server has long exploded Remember these are Node drivers, so everything has to end up becoming a JS object.
eric_bullington 14y ago
Is that a blanket statement about C versus any dynamic language, or just JavaScript? Because with LuaJIT2, Mike Pall has already shown that a highly-optimized Lua interpreter can hold its own against optimized C, and sometimes even surpass it. Here's a nice look at some of the magic he does in assembler to get LuaJIT at such a high level of performance: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 My point is, there's nothing inherently unbeatable about C. I think that a select group of dynamic language -- probably including JavaScript -- can and will reach that level of performance, or at least close to it. They just haven't been around as long.
- goggles99 14y ago
  Yeah, well please tell me how? The JavaScript engine is written in C so how could the language running on top of it be faster? I will tell you how it can be - if the JavaScript engine JITs the JS in a more optimized way than the C compiler compiled the C. Well how does that make JS faster than C when JS will always carry more overhead? It cannot and does not - all it means is that the compiler was far better. A poor C compiler may be outperformed by the best JS one, but that is about the only scenario where JS will outperform C.
  - SoftwareMaven 14y ago
    You are wrong. A JITted environment can take advantage of knowing about the current run of the system. As a result, it can do things like unroll loops and inline function calls. Yes, you could do the same thing in C code, but the resulting executable would be unreasonably large because you would have to unroll every loop and inline every function. Pypy has show itself faster than C in some cases as well[1]. 1. http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a...
    - tedunangst 14y ago
      Maybe some day they will add profile guided optimization to C compilers.
      - taf2 14y ago
        you're kidding right? and at least referring to gcc's -fprofile-generate -fprofile-use right?
        tptacek 14y ago
        Profile-guided optimization is decades old. It was, for example, one of the things people loved about the (Ultrix?) DEC Alpha compiler was profile-driven optimization.
tptacek 14y ago
It feels likely that the fundamental problem facing JS programs competing with the entire solution space available to C programs --- apart from the nerd who will implement an equivalently fast JIT compiler to run the JS on just to make a point --- is that C code has much better control over the layout of data in memory. You can work around the GC issues and modern compilers work around the interpretation overhead, but a C program is going to tend to have the easiest time ensuring that its working set fits into cache. Of course, the real problem here is that he's comparing his JS code to a random blob of C code that just happens to be part of the MySQL package. Is the MySQL client library famously performant?
- SoftwareMaven 14y ago
  I agree with you. If getting every bit of performance out of your hardware is important to you, C (possibly with inlined assembly) is the way to go. I am so happy that I've never had to do that in my career.
  - tptacek 14y ago
    Are you being sarcastic? Because wringing performance out of a known-working piece of C code is a pretty fun problem.
    - SoftwareMaven 14y ago
      I'm not being sarcastic. I can see how it could be fun (in a particularly zen-coder way, in fact), except almost every performance issue I've had to deal with has shown itself in production, needing a fix yesterday.
      - sliverstorm 14y ago
        The difference, as best I can tell, is mixed C-assembly code is generally built for performance from the very start, so it isn't all performance bugfixes for production code.
  - 14y ago
jrockway 14y ago
node is compiled to native code at runtime, and the compiler uses runtime type information to generate that code. C (without LLVM's JIT, of course) is compiled to native code before runtime, and as such, cannot take advantage of runtime type information when producing the code. So in this case, node does have a theoretical advantage. But to be thorough, one should also compile libmysql's parsing routines with LLVM and turn on runtime JIT compilation, and then write a benchmark that will exercise the code long enough for the JIT to kick in.
- tptacek 14y ago
  So take the output of the profiler after running the program on a diversity of real inputs and use that to drive the optimizer.
inoop 14y ago
Modern JavaScript runtimes are not interpreters, V8 for instance is just a JS to native ahead-of-time compiler. Also, for the general case, garbage collection has been outperforming manual management for over a decade now.
JackdawX 14y ago
There are 3 common fallacies in this post that people continually bring up about modern languages. Thought i'd come on here and write some corrections: "There is innate overhead when using an interpreted language, no matter how advanced the interpreter." I think a lot of people think this is true, because they have an antequated idea of an interpreter which reads each line as a string, parses the string, then executes the code. Modern js (and jvm bytecode, similar-but-different scenario) 'interpreters' compile to native bytecode and the code runs directly on your hardware. The speed overhead from modern language has a lot less to do with the 'interpreted' nature of the language, and a lot more to do with (a) code structure (overhead of objects, closures, namespace resolution, all that junk), and (b) the maturity of gcc vs other compilers. Theoretically a language with a JIT compiler should actually be faster than a precompiled language in any scanario where you are intensely going round and round a loop which has a lot of logic inside it. The more the loop runs, the better the JIT compiler can optimise it based on the current runtime conditions. "JavaScript is also garbage collected, while C is not, adding an additional level of overhead." The overhead of the garbage collector is only really to do with memory and startup speed, not runtime speed. It does barely anything when not collecting. Every time you alloc in c, you must free, and those actions have to happen in proximity to each other. Free takes time. GC allows all those free operations to happen when the program is idle, instead of holding up your program. The more stuff you create and delete, the faster a GC language should be compared to an equivalent program in a non-GC language.
vidarh 14y ago
I'm also doubtful that this will beat C, however... > There is innate overhead when using an interpreted language, no matter how advanced the interpreter. There is an overhead in JIT'ing the code, yes. But it is not a given that when amortised over sufficient data, that this overhead can not be compensated for by making use of knowledge that is simply not there at compile time. E.g. there are several well known methods regularly used in optimising dynamic languages that depend on discovering and adapting the code based on the actual types used. But when you're first doing this specialisation at runtime, nothing would stop you from taking actual input data into account rather than just basic type information for example. > JavaScript is also garbage collected, while C is not, adding an additional level of overhead. This is not necessarily a benefit for C unless a) your JavaScript program uses enough memory to trigger the garbage collector, which will depend on both the VM and your system, or b) your C program is written in a way that requires no extra effort to keep track of when memory becomes garbage. Programs written for GC'd systems may sometimes require far less logic to keep track of memory, and instead take the cost at collection time, and so may spend less time dealing with memory in situations where collection isn't necessary during the lifetime of the program. In the general case, there's an extra overhead. In specific cases it is most certainly possible that the garbage collection can be a performance benefit by acting like a safety net that lets you do other stuff (avoiding logic to track ownership) that can speed up your app - this applies regardless of language. Other than that I agree with you.

Jare 14y ago

From the article: > JavaScript will no longer be the bottleneck. At this point the main cost is turning network data into JavaScript objects. This cost is equal for JavaScript libraries, as well as for C++ addons making V8 calls. Also, when a single client can process 5000 MBit/s utilizing a single CPU, your MySQL server has long exploded Remember these are Node drivers, so everything has to end up becoming a JS object.

eric_bullington 14y ago

Is that a blanket statement about C versus any dynamic language, or just JavaScript? Because with LuaJIT2, Mike Pall has already shown that a highly-optimized Lua interpreter can hold its own against optimized C, and sometimes even surpass it. Here's a nice look at some of the magic he does in assembler to get LuaJIT at such a high level of performance: http://article.gmane.org/gmane.comp.lang.lua.general/75426 http://article.gmane.org/gmane.comp.lang.lua.general/75426 My point is, there's nothing inherently unbeatable about C. I think that a select group of dynamic language -- probably including JavaScript -- can and will reach that level of performance, or at least close to it. They just haven't been around as long.

goggles99 14y ago
Yeah, well please tell me how? The JavaScript engine is written in C so how could the language running on top of it be faster? I will tell you how it can be - if the JavaScript engine JITs the JS in a more optimized way than the C compiler compiled the C. Well how does that make JS faster than C when JS will always carry more overhead? It cannot and does not - all it means is that the compiler was far better. A poor C compiler may be outperformed by the best JS one, but that is about the only scenario where JS will outperform C.
- SoftwareMaven 14y ago
  You are wrong. A JITted environment can take advantage of knowing about the current run of the system. As a result, it can do things like unroll loops and inline function calls. Yes, you could do the same thing in C code, but the resulting executable would be unreasonably large because you would have to unroll every loop and inline every function. Pypy has show itself faster than C in some cases as well[1]. 1. http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-a...
  - tedunangst 14y ago
    Maybe some day they will add profile guided optimization to C compilers.
    - taf2 14y ago
      you're kidding right? and at least referring to gcc's -fprofile-generate -fprofile-use right?
      - tptacek 14y ago
        Profile-guided optimization is decades old. It was, for example, one of the things people loved about the (Ultrix?) DEC Alpha compiler was profile-driven optimization.

tptacek 14y ago

It feels likely that the fundamental problem facing JS programs competing with the entire solution space available to C programs --- apart from the nerd who will implement an equivalently fast JIT compiler to run the JS on just to make a point --- is that C code has much better control over the layout of data in memory. You can work around the GC issues and modern compilers work around the interpretation overhead, but a C program is going to tend to have the easiest time ensuring that its working set fits into cache. Of course, the real problem here is that he's comparing his JS code to a random blob of C code that just happens to be part of the MySQL package. Is the MySQL client library famously performant?

SoftwareMaven 14y ago
I agree with you. If getting every bit of performance out of your hardware is important to you, C (possibly with inlined assembly) is the way to go. I am so happy that I've never had to do that in my career.
- tptacek 14y ago
  Are you being sarcastic? Because wringing performance out of a known-working piece of C code is a pretty fun problem.
  - SoftwareMaven 14y ago
    I'm not being sarcastic. I can see how it could be fun (in a particularly zen-coder way, in fact), except almost every performance issue I've had to deal with has shown itself in production, needing a fix yesterday.
    - sliverstorm 14y ago
      The difference, as best I can tell, is mixed C-assembly code is generally built for performance from the very start, so it isn't all performance bugfixes for production code.
- 14y ago

jrockway 14y ago

node is compiled to native code at runtime, and the compiler uses runtime type information to generate that code. C (without LLVM's JIT, of course) is compiled to native code before runtime, and as such, cannot take advantage of runtime type information when producing the code. So in this case, node does have a theoretical advantage. But to be thorough, one should also compile libmysql's parsing routines with LLVM and turn on runtime JIT compilation, and then write a benchmark that will exercise the code long enough for the JIT to kick in.

tptacek 14y ago
So take the output of the profiler after running the program on a diversity of real inputs and use that to drive the optimizer.

inoop 14y ago

Modern JavaScript runtimes are not interpreters, V8 for instance is just a JS to native ahead-of-time compiler. Also, for the general case, garbage collection has been outperforming manual management for over a decade now.

JackdawX 14y ago

There are 3 common fallacies in this post that people continually bring up about modern languages. Thought i'd come on here and write some corrections: "There is innate overhead when using an interpreted language, no matter how advanced the interpreter." I think a lot of people think this is true, because they have an antequated idea of an interpreter which reads each line as a string, parses the string, then executes the code. Modern js (and jvm bytecode, similar-but-different scenario) 'interpreters' compile to native bytecode and the code runs directly on your hardware. The speed overhead from modern language has a lot less to do with the 'interpreted' nature of the language, and a lot more to do with (a) code structure (overhead of objects, closures, namespace resolution, all that junk), and (b) the maturity of gcc vs other compilers. Theoretically a language with a JIT compiler should actually be faster than a precompiled language in any scanario where you are intensely going round and round a loop which has a lot of logic inside it. The more the loop runs, the better the JIT compiler can optimise it based on the current runtime conditions. "JavaScript is also garbage collected, while C is not, adding an additional level of overhead." The overhead of the garbage collector is only really to do with memory and startup speed, not runtime speed. It does barely anything when not collecting. Every time you alloc in c, you must free, and those actions have to happen in proximity to each other. Free takes time. GC allows all those free operations to happen when the program is idle, instead of holding up your program. The more stuff you create and delete, the faster a GC language should be compared to an equivalent program in a non-GC language.

vidarh 14y ago

I'm also doubtful that this will beat C, however... > There is innate overhead when using an interpreted language, no matter how advanced the interpreter. There is an overhead in JIT'ing the code, yes. But it is not a given that when amortised over sufficient data, that this overhead can not be compensated for by making use of knowledge that is simply not there at compile time. E.g. there are several well known methods regularly used in optimising dynamic languages that depend on discovering and adapting the code based on the actual types used. But when you're first doing this specialisation at runtime, nothing would stop you from taking actual input data into account rather than just basic type information for example. > JavaScript is also garbage collected, while C is not, adding an additional level of overhead. This is not necessarily a benefit for C unless a) your JavaScript program uses enough memory to trigger the garbage collector, which will depend on both the VM and your system, or b) your C program is written in a way that requires no extra effort to keep track of when memory becomes garbage. Programs written for GC'd systems may sometimes require far less logic to keep track of memory, and instead take the cost at collection time, and so may spend less time dealing with memory in situations where collection isn't necessary during the lifetime of the program. In the general case, there's an extra overhead. In specific cases it is most certainly possible that the garbage collection can be a performance benefit by acting like a safety net that lets you do other stuff (avoiding logic to track ownership) that can speed up your app - this applies regardless of language. Other than that I agree with you.