7 ms·

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 -

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.
      - wglb 14y ago
        First VMS. That was one of the outstanding compilers ever written.
    - pbiggar 14y ago
      There is a major difference between performing profile-generated optimizations at compile-time based on sample data, and performing it at run-time based on real data. It is one pretty good way in which JITs could beat programs implemented directly in C.
      - gillianseed 14y ago
        Not really since the 'sample' data is 'real' data which has been gathered during run-time.
        pbiggar 14y ago
        That is the most optimistic statement about profile-directed optimization that I have ever read.
  - thedigitalengel 14y ago
    They're not the same. VMs can assume invariants (which may not always hold) and compile specialized methods which depend on those assumptions and then fall back to a non-optimized version during the execution of a method. To do something like that (OSR) in C, you'll have to have a very sophisticated runtime.
- tptacek 14y ago
  That PyPy example has nothing to do with C and everything to do with a particular implementation of libc.
dgreensp 14y ago
In the abstract, a just-in-time compiler will beat an ahead-of-time compiler because it has more information, including statistics about control flow (which branches tend to be taken, etc.) and what exact instruction set is being targeted.
jarel 14y ago
> 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. Yes. Exactly. Let's say there are two languages A and B, and A is compiled (be it JIT or AOT) by a smarter compiler, resulting in faster code than the same program written in language B, how does that not make language A faster? I do know that comparing interpreted/JITed code and AOT-compiled code is somewhat nonsensical, but then again, so is talking about "faster" and "slower" languages.
- goggles99 14y ago
  >Yes. Exactly. Let's say there are two languages A and B, and A is compiled (be it JIT or AOT) by a smarter compiler, resulting in faster code than the same program written in language B, how does that not make language A faster? Well I am talking about the performance limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Doing more (Which a more highly abstracted languages must do) in less time with all else being the same is not possible as we understand quantum physics today.
  - tptacek 14y ago
    Wow.
  - chousuke 14y ago
    > Doing more (Which a more highly abstracted languages must do) Can you explain why you think this assumption is true? I don't think it is. A higher level of abstraction may allow your to convey more information in less code, but that does not mean it necessarily translates to more machine code. In fact, when you operate on a higher level of abstraction with more information available, the compiler may even have more freedom to produce highly efficient output without breaking expected semantics.
tptacek 14y ago
This argument reminds me of when I was 15 and trying to explain Unix security to my democoder friend, who kept insisting that he could bypass file permissions by just programming directly to the hardware and reading the bits off the disk. If you want to keep arguing that every other language merely asymptotically approaches the performance of x86_64 assembly, that is a fine (if dumb) position. But the argument that C has a monopoly on assembly code generation is silly, as is the argument that C compilers are inherently better at code generation than all other compilers. Look at the LuaJIT2 direct-threading post upthread for an infamous example of a performant dispatching structure that isn't easily expressible in ANSI C.
- haberman 14y ago
  > Look at the LuaJIT2 direct-threading post upthread for an infamous example of a performant dispatching structure that isn't easily expressible in ANSI C. Sure, but the point of that post is that hand-written assembly can beat C-compiler-generated assembly. It's not arguing that any other language's runtime (even LuaJIT's own code generator) is going to generate assembly that's any better than gcc's in this case. I do know that one of Mike Pall's stated goals with LuaJIT is to minimize the performance difference between Lua and C as much as possible. Though one of his methods of doing so (the foreign function interface: http://luajit.org/ext_ffi_tutorial.html http://luajit.org/ext_ffi_tutorial.html) gives up the memory-safety of Lua to accomplish this. Even without FFI, LuaJIT is incredibly fast for functional/numerical calculations. > If you want to keep arguing that every other language merely asymptotically approaches the performance of x86_64 assembly, that is a fine (if dumb) position. I think what rubs some people (including me) the wrong way about these "faster than C" claims is the implied argument that C (and other non-GC'd languages) are obsolete. These claims often come from people who, as this article's author explicit states, want higher-level languages to win because they don't want to ever have to write in C or deal with anything written in C. If people can get stuff in higher-level languages to run faster, then great, but those of us working in system-space in non-memory-safe languages are still going to beat their pants off if we combine all the tricks of their VM with domain-specific knowledge and optimizations (specifically parsing, in this case). "Faster than C" claims can sometimes feel like a big "F U" to those of us trying to innovate in system-space, like "our VM is the only system software we'll ever need." It's the Java attitude where people only want "100% pure Java" and shun JNI and anything that won't run on their VM.
btilly 14y ago
Your argument is the same as the arguments that higher level arguments cannot be faster than assembly. In theory, any optimization available to a compiler is also available to an assembly programmer. In practice humans do not match automation. This has been demonstrated both in theory and practice for decades. There is no limit to the level of language that this argument could theoretically apply to. In practice the run-time guarantees and programmatic indirection that we demand in high level languages make the task insurmountable for current programs. But never underestimate what can happen with a good compiler and the right program.
- kevinnk 14y ago
  > "In practice humans do not match automation." Actually in practice human's almost always surpass automation mostly because they can start with automated output and improve upon it.
  - btilly 14y ago
    Humans can do that. But in practice we don't seem to. Instead the trend mostly seems to be that we do it by hand until automation becomes good enough to do it better than we were doing it, and then we move on to harder kinds of problems and let automation do its thing. I say "mostly seems to be" because there are plenty of counter-examples. But that's the general trend. As is seen by the explosion of programmers working in what used to be considered unbearably slow scripting languages, and the relative lack of people doing traditional assembly programming.
    - kevinnk 14y ago
      "In practice humans do not match automation." Maybe this is a nitpicky argument, but to me this means one thing: when put head to head, humans do not do better than automated output. This is wrong for exactly the reason I said. In 99% of cases you start out with an unoptimized version, find the areas that need optimizing, and improve the automated output by hand. Thus in practice and in theory humans almost always beat automated output. The general trend of people working on higher level problems isn't because automation can do low level stuff better, it's because automation can do it well enough for most cases that we don't need a human to step in. Automation isn't doing better than what a human would do, but it is doing well enough that there's no need to go back and optimize it.
gsg 14y ago
It's not all about the quality of the compiler. C compilers have to deal with a language that has terrible semantics for aliasing, and in which cross module information flow is usually limited to what programmers type into header files (although this is slowly beginning to change with LTO and WPO). This is a significant disadvantage for an optimizing compiler. In contrast, JS implementations have the entire program text and can optimise, say, calling conventions however they like. JS and Lua also have disadvantages, such as their inferior (but memory safe) representation of data, so I would not be surprised if JS were faster for some problems and slower for others.
- justincormack 14y ago
  That's why Luajit also has an unsafe C compatible representation too, the ffi.
digeridoo 14y ago
It's not like performance is a fundamental property of the language, it's just a matter of which tools are available. JITs outperforming compilers is just a matter of specialized compilation approach being able to outperform a generalized compilation approach, which is actually a far more fundamental truth than abstractions having a performance penalty. LLVM outperforms GCC in some cases. However, in general JITs do not outperform GCC. The JIT overhead only pays off in a limited set of cases. Most people publishing performance benchmarks on the Internet barely know how to compile a C program for production, let alone write or benchmark one. Google did a thorough benchmark of several languages and C++ was the clear winner: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...
- igouy 14y ago
  >> Google did a thorough benchmark... << No. One person employed at Google did a comparison and lots of other people (including some others employed at Google) explained what they thought was wrong with that comparison.

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.
    - wglb 14y ago
      First VMS. That was one of the outstanding compilers ever written.
  - pbiggar 14y ago
    There is a major difference between performing profile-generated optimizations at compile-time based on sample data, and performing it at run-time based on real data. It is one pretty good way in which JITs could beat programs implemented directly in C.
    - gillianseed 14y ago
      Not really since the 'sample' data is 'real' data which has been gathered during run-time.
      - pbiggar 14y ago
        That is the most optimistic statement about profile-directed optimization that I have ever read.
- thedigitalengel 14y ago
  They're not the same. VMs can assume invariants (which may not always hold) and compile specialized methods which depend on those assumptions and then fall back to a non-optimized version during the execution of a method. To do something like that (OSR) in C, you'll have to have a very sophisticated runtime.
tptacek 14y ago
That PyPy example has nothing to do with C and everything to do with a particular implementation of libc.

dgreensp 14y ago

In the abstract, a just-in-time compiler will beat an ahead-of-time compiler because it has more information, including statistics about control flow (which branches tend to be taken, etc.) and what exact instruction set is being targeted.

jarel 14y ago

> 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. Yes. Exactly. Let's say there are two languages A and B, and A is compiled (be it JIT or AOT) by a smarter compiler, resulting in faster code than the same program written in language B, how does that not make language A faster? I do know that comparing interpreted/JITed code and AOT-compiled code is somewhat nonsensical, but then again, so is talking about "faster" and "slower" languages.

goggles99 14y ago
>Yes. Exactly. Let's say there are two languages A and B, and A is compiled (be it JIT or AOT) by a smarter compiler, resulting in faster code than the same program written in language B, how does that not make language A faster? Well I am talking about the performance limitations imposed by the laws of physics. Not which compiler is better. I can always find a better or worse C or JS compiler/JITter so that proves nothing. Doing more (Which a more highly abstracted languages must do) in less time with all else being the same is not possible as we understand quantum physics today.
- tptacek 14y ago
  Wow.
- chousuke 14y ago
  > Doing more (Which a more highly abstracted languages must do) Can you explain why you think this assumption is true? I don't think it is. A higher level of abstraction may allow your to convey more information in less code, but that does not mean it necessarily translates to more machine code. In fact, when you operate on a higher level of abstraction with more information available, the compiler may even have more freedom to produce highly efficient output without breaking expected semantics.

tptacek 14y ago

This argument reminds me of when I was 15 and trying to explain Unix security to my democoder friend, who kept insisting that he could bypass file permissions by just programming directly to the hardware and reading the bits off the disk. If you want to keep arguing that every other language merely asymptotically approaches the performance of x86_64 assembly, that is a fine (if dumb) position. But the argument that C has a monopoly on assembly code generation is silly, as is the argument that C compilers are inherently better at code generation than all other compilers. Look at the LuaJIT2 direct-threading post upthread for an infamous example of a performant dispatching structure that isn't easily expressible in ANSI C.

haberman 14y ago
> Look at the LuaJIT2 direct-threading post upthread for an infamous example of a performant dispatching structure that isn't easily expressible in ANSI C. Sure, but the point of that post is that hand-written assembly can beat C-compiler-generated assembly. It's not arguing that any other language's runtime (even LuaJIT's own code generator) is going to generate assembly that's any better than gcc's in this case. I do know that one of Mike Pall's stated goals with LuaJIT is to minimize the performance difference between Lua and C as much as possible. Though one of his methods of doing so (the foreign function interface: http://luajit.org/ext_ffi_tutorial.html http://luajit.org/ext_ffi_tutorial.html) gives up the memory-safety of Lua to accomplish this. Even without FFI, LuaJIT is incredibly fast for functional/numerical calculations. > If you want to keep arguing that every other language merely asymptotically approaches the performance of x86_64 assembly, that is a fine (if dumb) position. I think what rubs some people (including me) the wrong way about these "faster than C" claims is the implied argument that C (and other non-GC'd languages) are obsolete. These claims often come from people who, as this article's author explicit states, want higher-level languages to win because they don't want to ever have to write in C or deal with anything written in C. If people can get stuff in higher-level languages to run faster, then great, but those of us working in system-space in non-memory-safe languages are still going to beat their pants off if we combine all the tricks of their VM with domain-specific knowledge and optimizations (specifically parsing, in this case). "Faster than C" claims can sometimes feel like a big "F U" to those of us trying to innovate in system-space, like "our VM is the only system software we'll ever need." It's the Java attitude where people only want "100% pure Java" and shun JNI and anything that won't run on their VM.

btilly 14y ago

Your argument is the same as the arguments that higher level arguments cannot be faster than assembly. In theory, any optimization available to a compiler is also available to an assembly programmer. In practice humans do not match automation. This has been demonstrated both in theory and practice for decades. There is no limit to the level of language that this argument could theoretically apply to. In practice the run-time guarantees and programmatic indirection that we demand in high level languages make the task insurmountable for current programs. But never underestimate what can happen with a good compiler and the right program.

kevinnk 14y ago
> "In practice humans do not match automation." Actually in practice human's almost always surpass automation mostly because they can start with automated output and improve upon it.
- btilly 14y ago
  Humans can do that. But in practice we don't seem to. Instead the trend mostly seems to be that we do it by hand until automation becomes good enough to do it better than we were doing it, and then we move on to harder kinds of problems and let automation do its thing. I say "mostly seems to be" because there are plenty of counter-examples. But that's the general trend. As is seen by the explosion of programmers working in what used to be considered unbearably slow scripting languages, and the relative lack of people doing traditional assembly programming.
  - kevinnk 14y ago
    "In practice humans do not match automation." Maybe this is a nitpicky argument, but to me this means one thing: when put head to head, humans do not do better than automated output. This is wrong for exactly the reason I said. In 99% of cases you start out with an unoptimized version, find the areas that need optimizing, and improve the automated output by hand. Thus in practice and in theory humans almost always beat automated output. The general trend of people working on higher level problems isn't because automation can do low level stuff better, it's because automation can do it well enough for most cases that we don't need a human to step in. Automation isn't doing better than what a human would do, but it is doing well enough that there's no need to go back and optimize it.

gsg 14y ago

It's not all about the quality of the compiler. C compilers have to deal with a language that has terrible semantics for aliasing, and in which cross module information flow is usually limited to what programmers type into header files (although this is slowly beginning to change with LTO and WPO). This is a significant disadvantage for an optimizing compiler. In contrast, JS implementations have the entire program text and can optimise, say, calling conventions however they like. JS and Lua also have disadvantages, such as their inferior (but memory safe) representation of data, so I would not be surprised if JS were faster for some problems and slower for others.

justincormack 14y ago
That's why Luajit also has an unsafe C compatible representation too, the ffi.

digeridoo 14y ago

It's not like performance is a fundamental property of the language, it's just a matter of which tools are available. JITs outperforming compilers is just a matter of specialized compilation approach being able to outperform a generalized compilation approach, which is actually a far more fundamental truth than abstractions having a performance penalty. LLVM outperforms GCC in some cases. However, in general JITs do not outperform GCC. The JIT overhead only pays off in a limited set of cases. Most people publishing performance benchmarks on the Internet barely know how to compile a C program for production, let alone write or benchmark one. Google did a thorough benchmark of several languages and C++ was the clear winner: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf https://days2011.scala-lang.org/sites/days2011/files/ws3-1-H...

igouy 14y ago
>> Google did a thorough benchmark... << No. One person employed at Google did a comparison and lots of other people (including some others employed at Google) explained what they thought was wrong with that comparison.