7 ms·

I don't see why anybody should be surprised about the swing back to Ahead-of-Time compiled native code. I'm actually surprised it has taken as long as it has.

I don't see why anybody should be surprised about the swing back to Ahead-of-Time compiled native code. I'm actually surprised it has taken as long as it has. Although interpretation and Just-in-Time compilation were not new ideas at the time, Java first brought them to a wide audience around 20 years ago with its use of the JVM. Anyone who remembers those times, and even many years beyond then, will remember how slow JVM-based applications were compared to native apps. Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases. Since then we've seen similar techniques used by a variety of other platforms. Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance. While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world. Ahead-of-Time C and C++ compilers have consistently compiled software that's very fast, lean, and the best performer in real-world scenarios. For years, we've had people pointing out this very obvious reality regarding how Ahead-of-Time compilation proves to be superior to Just-in-Time compilation in realistic scenarios. Yet we've seen their claims very forcefully denied by the Just-in-Time advocates. Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach. With battery-powered devices more prevalent than ever, the need for high-performing and efficient binaries is greater than it has ever been. Returning to Ahead-of-Time compilation is just what we need given these circumstances. It's just a real shame it has taken so long for this important reality to be recognized.

brianwawok 11y ago
I mean, it's almost a moot point. Each year the number of native apps I run goes down by a couple, and the number of webapps I use go up by a few. Native apps I use right now? Chrome - Already native compiled IntelliJ - Full JIT mode, but due to the fact I start it once and run it for a month, not a huge deal. Command line unixy stuff - Already native compiled (On gaming computer) Games - Already native compiled I mean desktop apps DO exist, but just not that many to use day to day... from what I have seen of the windows app store, I can find 20 colors of calculator apps, but nothing that impressive.
- pjmlp 11y ago
  For me it goes the opposite direction. On mobile only apps. The Web is for reading stuff. On the desktop the same thing, except for all those forums and travel booking websites that don't offer me a choice. Messaging, email, productive software, work related stuff all native software. Exception being when some customers do require web projects.
  - mwcampbell 11y ago
    > all those forums and travel booking websites that don't offer me a choice. So you would prefer to have the friction of an app store, or even just a platform-specific native executable, for every little service? And of course there's also the friction on the developer side, especially when submitting to app stores which act as gatekeepers. Sure, native apps have better performance and often a better user experience all around, especially mobile apps. But your comment about forums and travel booking websites has got me thinking that we should really try to solve the performance and UX issues of the web platform rather than retreat to native apps. Edit: Yes, I've taken both sides on the web versus native debate. I recently posted that JavaScript-based mobile web apps are second-class compared to AOT-compiled native mobile apps. I attribute my latest flip-flop to the fact that just last night I went through the tedious process of submitting a new app to the iOS App Store -- an app that could probably have been a web app. So now I want the web to win.
    - pjmlp 11y ago
      > So you would prefer to have the friction of an app store, or even just a platform-specific native executable, for every little service? Yes, every time I have the option to do so.
      - mwcampbell 11y ago
        Why exactly do you prefer a native app whenever you have the option?
        11y ago
ygra 11y ago
Java was interpreted initially. The JIT compiler came later (around 2000, IIRC).
pjmlp 11y ago
There have been AOT compilers from third party JVM vendors almost since the begining. Used mostly by companies that didn't want to expose their bytecode. However Sun decided to bet the farm on JIT and was against having AOT compilation on the reference JDK. Meaning anyone that wanted a AOT toolchain for Java had to go shopping. Now, it appears Oracle is of a different opinion. "Java Goes AOT" at JVM Language Summit 2015 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=16 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar... Being used to memory safe languages with AOT compilation like Turbo Pascal, Modula-2, Modula-3, Oberon, Delphi, Ada among many others, I also would have prefer that Java and .NET had offered the same type of toolchain from the beginning. Now almost 20 years later, we need to teach young generations that their default implementations were just that, implementations. As they got used to the (wrong) idea that memory safe languages imply a VM.
- pilif 11y ago
  Delphi and pascal are memory safe? That's news to me. I have created my fair share of buffer overruns and memory corruption in both of them (they were my first languages I programmed in)
  - pjmlp 11y ago
    Compared to C they are. You surely were using unsafe constructs explicitly, like taking the address of a variable wiht Addr or @, using pointer manipulation functions. With C they just happen, given the lack of bounds checking, implicit conversions, automatic decay of arrays into pointers (specially bad as arguments), null terminated strings and undefined behaviours across compilers.
    - Roboprog 11y ago
      Alas, the Swiss version of Algol lost out to the New Jersey version :-( Bounds checking and non-nullable references are for wussies, after all. That, and a worse-is-better C compiler is easier to implement and thus more "available". (like Joel Spolsky said "Go ugly early")
7952 11y ago
A lot of change in computing seems to be moving the location of a cache to be closer or further from the user in a cyclical manner. Maybe the same observation can be applied to source code?
deleted 11y ago
[deleted]
chrisseaton 11y ago
> Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach. I think your argument is only correct for one subset of languages - C, C++, Haskell - languages like that. For languages like JavaScript, Ruby, Python, JIT compilation is proving to be massively more successful, and it's really easy to understand. As soon as you have features like eval, AOT compilation is never going to be effective.
- BigChiefSmokem 11y ago
  Agree with you but I have to call something out about JS. The thing I most hate about JavaScript is how slow JIT is and I think we have wasted tons of industry resources trying to write better engines instead of pushing for lower level access to the client metal from the web server.
  - pcwalton 11y ago
    > The thing I most hate about JavaScript is how slow JIT is and I think we have wasted tons of industry resources trying to write better engines instead of pushing for lower level access to the client metal from the web server. Like Web Assembly?
bad_user 11y ago
> Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance. I see this repeated ad nauseam, but it's false. Other platforms are not rivaling C/C++ in terms of performance and not AOT compilation. But the reason for why C/C++ is still winning in terms of performance has little to do with it being compiled ahead of time and more to do with manual memory management and not using a garbage collector. C++ compilers are also very mature, being themselves the subject of research. But compare Java's performance to Go, or to Objective-C for that matter and the situation changes completely.
- mkup 11y ago
  You are talking about high advancements in the compiler research. But is there any statistically significant performance difference between the code compiled via latest GCC vs. OpenWatcom (which is unmaintained for a few decades)?
AshleysBrain 11y ago
Whenever I read posts like this I feel like two technologies are being portrayed as combatants in an epic war over the years, with engineers taking sides and firing shots at each other. In reality I think technologies are just tools which have their appropriate and inappropriate uses. Both AOT and JIT have their strengths and weaknesses, and engineers make their choices based on those tradeoffs. With the linked article, it sounds like the startup time tradeoff is being used as the main motivation for making a change, probably because mobile users are more sensitive to this. That doesn't mean JIT fundamentally sucks - it's worked pretty well on the web with Javascript, for example.
- JustSomeNobody 11y ago
  You're wrong. It is a battle. Look at how quickly the swords come out when anyone brings up C# and Java or Python and Ruby or Backbone and Angular. Any discussion involving developers and the tech they use quickly devolves into all out verbal conflict. People LOVE to argue about this stuff because it gives them something to do besides actually doing anything productive. It's all rather sickening, really.
  - mahouse 11y ago
    How do you dare living your life doing something entertaining rather than doing something productive? To the gas chamber with you!
    - JustSomeNobody 11y ago
      HAHA! I see what you did there! But you missed my point.
  - Echoic 11y ago
    With your comment, I would think the correct course of action would be not commenting at all in the discussion. But, I guess you don't have anything 'productive' to do.
    - 11y ago
pcwalton 11y ago
> While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world. Other than JavaScript, which you're executing right now to post this comment? Web app usage is huge, and there isn't going to be any shift to native code there anytime soon. NaCl (not PNaCl) has been dead as a proposal for Web content for a long time. That's because JITs actually do allow for better portability. Edit: OK, HN doesn't actually use JS, so mea culpa on that rhetorical flourish. Still, the point stands that you're using the Web a lot, and that's a testament to the success of JITs.
- rymate1234 11y ago
  does HN even use that much JavaScript?
  - mrec 11y ago
    No, AFAICS there's no JS at all in either this page or the "Add Comment" page. One HTML file, one CSS file and a couple of tiny GIFs; that's it. EDIT: oops, tell a lie, there's a tiny inline snippet to do voting.
    - pdkl95 11y ago
      That simplicity (both the lack of client-side dynamics and the lack of unnecessary images) renders nice and fast, too. Too many sites waste time with "shiny" javascript tricks, way too many images and other bloat.
- pjmlp 11y ago
  Just because they took Usenet away from us, native guys. A am yet to use any forum online that is as comfortable to use. > Web app usage is huge, and there isn't going to be any shift to native code there anytime soon. I am betting on mobile to change the wave.
  - 11y ago
legulere 11y ago
The JVM was very slow in the beginning because it was just an interpreter and had no JIT compilation. Then there also was the issue with 80bit floats on x86 making float computations slow, as the results of each operation needed to be saved back to memory to truncate them to 32/64 bit. The speed difference since those problems have been overcome has been relatively low. The biggest performance problem is garbage collection, which you can't overcome just with implementing ahead of time compilation. Another issue is the lack of SIMD support of JIT VMs.
- redcalx 11y ago
  .NET has SIMD support as of version 4.5.2.
lovemetender 11y ago
>> Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases. Measurable I'd agree with, noticeable no, not really unless you mean startup time; otherwise the JVM is very fast once it's started, that isn't disputable.
- acconsta 11y ago
  Unmanaged native code definitely has an edge, even in I/O-heavy applications like databases. http://www.scylladb.com/technology/cassandra-vs-scylla-benchmark/ http://www.scylladb.com/technology/cassandra-vs-scylla-bench... Not to mention low-memory environments like mobile.
eslaught 11y ago
The issue is not AOT vs JIT, but one of language semantics and levels of abstraction. You could prove this point in a trivial way by JIT compiling C with LLVM. The binary would have an increased startup cost, but would otherwise run identically to an AOT compiled C program. It might even run faster, since the LLVM JIT could run with the equivalent of the -march=native to the AOT compiler. (In an AOT environment, you can only do this if you can guarantee that the binary will only run on the machine it was compiled on, or otherwise know the exact specs of the target machine.) A much more interesting example is Terra[1], a language with C-like semantics embedded inside Lua. The Terra-Lua combination allows you to use Lua as a sort of C++ templates replacement, giving you much better metaprogramming than traditional C/C++. This allows you to do cool things like implement a version of matrix-multiply which is specialized to the target hardware, allowing you to match or almost match the performance of ATLAS and Intel MKL. Mind you: these are not your usual C/C++ programs, they are mostly written in manually hand-tuned (or auto-tuned) assembly. What we're really looking at here is a difference in abstraction levels. It's not that the JVM JIT is incapable of getting C-like performance. Obviously it can, in certain cases. The issue is that the Java semantics prevent the JVM from getting C-like performance in a predictable and dependable way from idiomatic Java programs. This should not really be a surprise, given how far Java is from C. What we really need to do is take a step back and reconsider our assumptions. Our modern programming languages lock us into certain assumptions about language design and semantics that can be blinding at times. Consider that even C doesn't get optimal performance in all cases---this is why Fortran still exists. What would it take to get to programming language with nice semantics and truly optimal performance? I don't have a closed form answer, but I'm confident that the solution will require revisiting some of the assumptions baked into not just our compiler infrastructures, but also our languages. [1]: http://terralang.org/ http://terralang.org/

brianwawok 11y ago

I mean, it's almost a moot point. Each year the number of native apps I run goes down by a couple, and the number of webapps I use go up by a few. Native apps I use right now? Chrome - Already native compiled IntelliJ - Full JIT mode, but due to the fact I start it once and run it for a month, not a huge deal. Command line unixy stuff - Already native compiled (On gaming computer) Games - Already native compiled I mean desktop apps DO exist, but just not that many to use day to day... from what I have seen of the windows app store, I can find 20 colors of calculator apps, but nothing that impressive.

pjmlp 11y ago
For me it goes the opposite direction. On mobile only apps. The Web is for reading stuff. On the desktop the same thing, except for all those forums and travel booking websites that don't offer me a choice. Messaging, email, productive software, work related stuff all native software. Exception being when some customers do require web projects.
- mwcampbell 11y ago
  > all those forums and travel booking websites that don't offer me a choice. So you would prefer to have the friction of an app store, or even just a platform-specific native executable, for every little service? And of course there's also the friction on the developer side, especially when submitting to app stores which act as gatekeepers. Sure, native apps have better performance and often a better user experience all around, especially mobile apps. But your comment about forums and travel booking websites has got me thinking that we should really try to solve the performance and UX issues of the web platform rather than retreat to native apps. Edit: Yes, I've taken both sides on the web versus native debate. I recently posted that JavaScript-based mobile web apps are second-class compared to AOT-compiled native mobile apps. I attribute my latest flip-flop to the fact that just last night I went through the tedious process of submitting a new app to the iOS App Store -- an app that could probably have been a web app. So now I want the web to win.
  - pjmlp 11y ago
    > So you would prefer to have the friction of an app store, or even just a platform-specific native executable, for every little service? Yes, every time I have the option to do so.
    - mwcampbell 11y ago
      Why exactly do you prefer a native app whenever you have the option?
      - 11y ago

ygra 11y ago

Java was interpreted initially. The JIT compiler came later (around 2000, IIRC).

pjmlp 11y ago

There have been AOT compilers from third party JVM vendors almost since the begining. Used mostly by companies that didn't want to expose their bytecode. However Sun decided to bet the farm on JIT and was against having AOT compilation on the reference JDK. Meaning anyone that wanted a AOT toolchain for Java had to go shopping. Now, it appears Oracle is of a different opinion. "Java Goes AOT" at JVM Language Summit 2015 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3ArzUo2dtMurvpUTAaujPMeuuU&index=16 https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar... Being used to memory safe languages with AOT compilation like Turbo Pascal, Modula-2, Modula-3, Oberon, Delphi, Ada among many others, I also would have prefer that Java and .NET had offered the same type of toolchain from the beginning. Now almost 20 years later, we need to teach young generations that their default implementations were just that, implementations. As they got used to the (wrong) idea that memory safe languages imply a VM.

pilif 11y ago
Delphi and pascal are memory safe? That's news to me. I have created my fair share of buffer overruns and memory corruption in both of them (they were my first languages I programmed in)
- pjmlp 11y ago
  Compared to C they are. You surely were using unsafe constructs explicitly, like taking the address of a variable wiht Addr or @, using pointer manipulation functions. With C they just happen, given the lack of bounds checking, implicit conversions, automatic decay of arrays into pointers (specially bad as arguments), null terminated strings and undefined behaviours across compilers.
  - Roboprog 11y ago
    Alas, the Swiss version of Algol lost out to the New Jersey version :-( Bounds checking and non-nullable references are for wussies, after all. That, and a worse-is-better C compiler is easier to implement and thus more "available". (like Joel Spolsky said "Go ugly early")

7952 11y ago

A lot of change in computing seems to be moving the location of a cache to be closer or further from the user in a cyclical manner. Maybe the same observation can be applied to source code?

deleted 11y ago

[deleted]

chrisseaton 11y ago

> Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach. I think your argument is only correct for one subset of languages - C, C++, Haskell - languages like that. For languages like JavaScript, Ruby, Python, JIT compilation is proving to be massively more successful, and it's really easy to understand. As soon as you have features like eval, AOT compilation is never going to be effective.

BigChiefSmokem 11y ago
Agree with you but I have to call something out about JS. The thing I most hate about JavaScript is how slow JIT is and I think we have wasted tons of industry resources trying to write better engines instead of pushing for lower level access to the client metal from the web server.
- pcwalton 11y ago
  > The thing I most hate about JavaScript is how slow JIT is and I think we have wasted tons of industry resources trying to write better engines instead of pushing for lower level access to the client metal from the web server. Like Web Assembly?

bad_user 11y ago

> Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance. I see this repeated ad nauseam, but it's false. Other platforms are not rivaling C/C++ in terms of performance and not AOT compilation. But the reason for why C/C++ is still winning in terms of performance has little to do with it being compiled ahead of time and more to do with manual memory management and not using a garbage collector. C++ compilers are also very mature, being themselves the subject of research. But compare Java's performance to Go, or to Objective-C for that matter and the situation changes completely.

mkup 11y ago
You are talking about high advancements in the compiler research. But is there any statistically significant performance difference between the code compiled via latest GCC vs. OpenWatcom (which is unmaintained for a few decades)?

AshleysBrain 11y ago

Whenever I read posts like this I feel like two technologies are being portrayed as combatants in an epic war over the years, with engineers taking sides and firing shots at each other. In reality I think technologies are just tools which have their appropriate and inappropriate uses. Both AOT and JIT have their strengths and weaknesses, and engineers make their choices based on those tradeoffs. With the linked article, it sounds like the startup time tradeoff is being used as the main motivation for making a change, probably because mobile users are more sensitive to this. That doesn't mean JIT fundamentally sucks - it's worked pretty well on the web with Javascript, for example.

JustSomeNobody 11y ago
You're wrong. It is a battle. Look at how quickly the swords come out when anyone brings up C# and Java or Python and Ruby or Backbone and Angular. Any discussion involving developers and the tech they use quickly devolves into all out verbal conflict. People LOVE to argue about this stuff because it gives them something to do besides actually doing anything productive. It's all rather sickening, really.
- mahouse 11y ago
  How do you dare living your life doing something entertaining rather than doing something productive? To the gas chamber with you!
  - JustSomeNobody 11y ago
    HAHA! I see what you did there! But you missed my point.
- Echoic 11y ago
  With your comment, I would think the correct course of action would be not commenting at all in the discussion. But, I guess you don't have anything 'productive' to do.
  - 11y ago

pcwalton 11y ago

> While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world. Other than JavaScript, which you're executing right now to post this comment? Web app usage is huge, and there isn't going to be any shift to native code there anytime soon. NaCl (not PNaCl) has been dead as a proposal for Web content for a long time. That's because JITs actually do allow for better portability. Edit: OK, HN doesn't actually use JS, so mea culpa on that rhetorical flourish. Still, the point stands that you're using the Web a lot, and that's a testament to the success of JITs.

rymate1234 11y ago
does HN even use that much JavaScript?
- mrec 11y ago
  No, AFAICS there's no JS at all in either this page or the "Add Comment" page. One HTML file, one CSS file and a couple of tiny GIFs; that's it. EDIT: oops, tell a lie, there's a tiny inline snippet to do voting.
  - pdkl95 11y ago
    That simplicity (both the lack of client-side dynamics and the lack of unnecessary images) renders nice and fast, too. Too many sites waste time with "shiny" javascript tricks, way too many images and other bloat.
pjmlp 11y ago
Just because they took Usenet away from us, native guys. A am yet to use any forum online that is as comfortable to use. > Web app usage is huge, and there isn't going to be any shift to native code there anytime soon. I am betting on mobile to change the wave.
- 11y ago

legulere 11y ago

The JVM was very slow in the beginning because it was just an interpreter and had no JIT compilation. Then there also was the issue with 80bit floats on x86 making float computations slow, as the results of each operation needed to be saved back to memory to truncate them to 32/64 bit. The speed difference since those problems have been overcome has been relatively low. The biggest performance problem is garbage collection, which you can't overcome just with implementing ahead of time compilation. Another issue is the lack of SIMD support of JIT VMs.

redcalx 11y ago
.NET has SIMD support as of version 4.5.2.

lovemetender 11y ago

>> Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases. Measurable I'd agree with, noticeable no, not really unless you mean startup time; otherwise the JVM is very fast once it's started, that isn't disputable.

acconsta 11y ago
Unmanaged native code definitely has an edge, even in I/O-heavy applications like databases. http://www.scylladb.com/technology/cassandra-vs-scylla-benchmark/ http://www.scylladb.com/technology/cassandra-vs-scylla-bench... Not to mention low-memory environments like mobile.

eslaught 11y ago

The issue is not AOT vs JIT, but one of language semantics and levels of abstraction. You could prove this point in a trivial way by JIT compiling C with LLVM. The binary would have an increased startup cost, but would otherwise run identically to an AOT compiled C program. It might even run faster, since the LLVM JIT could run with the equivalent of the -march=native to the AOT compiler. (In an AOT environment, you can only do this if you can guarantee that the binary will only run on the machine it was compiled on, or otherwise know the exact specs of the target machine.) A much more interesting example is Terra[1], a language with C-like semantics embedded inside Lua. The Terra-Lua combination allows you to use Lua as a sort of C++ templates replacement, giving you much better metaprogramming than traditional C/C++. This allows you to do cool things like implement a version of matrix-multiply which is specialized to the target hardware, allowing you to match or almost match the performance of ATLAS and Intel MKL. Mind you: these are not your usual C/C++ programs, they are mostly written in manually hand-tuned (or auto-tuned) assembly. What we're really looking at here is a difference in abstraction levels. It's not that the JVM JIT is incapable of getting C-like performance. Obviously it can, in certain cases. The issue is that the Java semantics prevent the JVM from getting C-like performance in a predictable and dependable way from idiomatic Java programs. This should not really be a surprise, given how far Java is from C. What we really need to do is take a step back and reconsider our assumptions. Our modern programming languages lock us into certain assumptions about language design and semantics that can be blinding at times. Consider that even C doesn't get optimal performance in all cases---this is why Fortran still exists. What would it take to get to programming language with nice semantics and truly optimal performance? I don't have a closed form answer, but I'm confident that the solution will require revisiting some of the assumptions baked into not just our compiler infrastructures, but also our languages. [1]: http://terralang.org/ http://terralang.org/