5 ms·

There are a lot of weasel words for the other languages, but the comment about ruby is extremely interesting: "For example, the TruffleJS engine which implemen

There are a lot of weasel words for the other languages, but the comment about ruby is extremely interesting: "For example, the TruffleJS engine which implements JavaScript is competitive with V8 in benchmarks. The RubyTruffle engine is faster than all other Ruby implementations by far. The TruffleC engine is roughly competitive with GCC."

geodel 10y ago
> The TruffleC engine is roughly competitive with GCC It is not surprising in sense Java is competitive to C/C++ as per many Java developers.
- pjmlp 10y ago
  I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.
  - geodel 10y ago
    I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.
    - the_duke 10y ago
      UIs though... I haven't worked with a single Java based GUI application that did feel smooth, fast and efficient. I wonder why that is.
      - pjmlp 10y ago
        Because most developers don't care and code everything on the UI thread. Additionally Swing has bad defaults, so it requires effort to make the required set of calls to make them look better. Back in the Sun glory days, there were Sun blogs like Filthy Rich Clients, which lead eventually to a book http://filthyrichclients.org/ http://filthyrichclients.org/. It was a consequence of Sun not getting what it means developing GUIs for the consumer systems, think that their Solaris UIs (SunView, OpenWindows, CDE) weren't that great in that area. So most Java developers stick with the defaults and as such the majority of Java based applications send the wrong message.
        vvanders 10y ago
        Android does a bunch of things to keep you off the UI thread(IO throws an exception, handlers, Async Tasks, etc). You still have to GC at some point and when that happens chances are you're going to drop frames. Unless you're very aware of the garbage you're creating you'll take more than ~5ms which is usually enough to push you over 16ms with the other work that goes on during a frame.
        pjmlp 10y ago
        Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station controls of missiles and a couple of US Navy weapon systems. They surely don't want GC glitches in battle situations. The Android team seems to only bother with "good enough" in what concerns Android performance. As a side note, just check how many Android releases are they going through and yet real-audio support isn't quite there. Even Windows Phone has better support for it, and they do have WinRT and .NET on them.
        bitmapbrother 10y ago
        >Even Windows Phone has better support for it, and they do have WinRT and .NET on them. No they don't. Point me to one windows phone audio app that has low latency audio.
        pjmlp 10y ago
        Well there are these sources from Microsoft: https://blogs.windows.com/buildingapps/2014/05/15/real-time-audio-in-windows-store-and-windows-phone-apps/ https://blogs.windows.com/buildingapps/2014/05/15/real-time-... https://rtaudiowsapps.codeplex.com/ https://rtaudiowsapps.codeplex.com/ https://channel9.msdn.com/Events/Build/2014/3-548 https://channel9.msdn.com/Events/Build/2014/3-548 And I just found this, but not sure how good it fares. https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdncrdkgt7 https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdn...
      - merb 10y ago
        do you use or know cyberduck?
  - spriggan3 10y ago
    > In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. If the program runs on the user's machine, I'm pretty certain the users WILL notice the difference, memory wise.
    - merb 10y ago
      That's not true. Do you know Cyberduck? It actually takes less memory than most other FTP/SFTP etc programs. and probably feels a dozen times more smooth than most clients.
    - pjmlp 10y ago
      As I said "use the right algorithms and data structures in first place".
matthewrudy 10y ago
Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations. https://youtu.be/b1NTaVQPt1E https://youtu.be/b1NTaVQPt1E Previous discussion https://news.ycombinator.com/item?id=12062454 https://news.ycombinator.com/item?id=12062454
- vidarh 10y ago
  Chris is also reasonably active here. I've had the pleasure of discussing some of his jRuby work with him in the past (I occasionally plod along with own Ruby compiler in Ruby - it's nowhere near complete) and they've done a lot of impressive work to demonstrate how compiling Ruby into fast code is largely about assuming people will behave sanely (e.g. people won't usually give Fixnum#+ side-effects, or make it return weird stuff), but add fallbacks for when they do. This is the big challenge with Ruby: The subset of Ruby that people actually tend to work in is largely very predictable and possible to compile efficiently, but there's a lot of stuff around the fringes that people expect to work on the very rare occasions that we use it.
azakai 10y ago
I believe those benchmarks are for throughput, though. JS VM startup times (including v8) are highly optimized, while Graal+Truffle run on the JVM which is more optimized for sustained speed. JS VMs also tend to have multiple tiers for that reason - interpreter, baseline, and full JIT, etc. - while AFAIK the Graal+Truffle/JVM approach has just 2 (which is optimal for Java, but not for startup times of JavaScript and other dynamic languages).
- the8472 10y ago
  Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important. There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support but if I remember the talk correctly they're supposed to be added to openjdk eventually
  - azakai 10y ago
    True about AOT coming to the JVM, however, dynamic languages can't be AOT'd well in general, so that won't help Graal+Truffle languages much. Instead, dynamic languages tend to do tiering, which in principle is something Graal+Truffle could do, but it might be a lot of work.
    - deleted 10y ago
      [deleted]
    - hencq 10y ago
      Well at least it would help you avoid warm-up for the interpreter/compiler itself, so it might help a bit.

geodel 10y ago

> The TruffleC engine is roughly competitive with GCC It is not surprising in sense Java is competitive to C/C++ as per many Java developers.

pjmlp 10y ago
I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.
- geodel 10y ago
  I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.
  - the_duke 10y ago
    UIs though... I haven't worked with a single Java based GUI application that did feel smooth, fast and efficient. I wonder why that is.
    - pjmlp 10y ago
      Because most developers don't care and code everything on the UI thread. Additionally Swing has bad defaults, so it requires effort to make the required set of calls to make them look better. Back in the Sun glory days, there were Sun blogs like Filthy Rich Clients, which lead eventually to a book http://filthyrichclients.org/ http://filthyrichclients.org/. It was a consequence of Sun not getting what it means developing GUIs for the consumer systems, think that their Solaris UIs (SunView, OpenWindows, CDE) weren't that great in that area. So most Java developers stick with the defaults and as such the majority of Java based applications send the wrong message.
      - vvanders 10y ago
        Android does a bunch of things to keep you off the UI thread(IO throws an exception, handlers, Async Tasks, etc). You still have to GC at some point and when that happens chances are you're going to drop frames. Unless you're very aware of the garbage you're creating you'll take more than ~5ms which is usually enough to push you over 16ms with the other work that goes on during a frame.
        pjmlp 10y ago
        Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station controls of missiles and a couple of US Navy weapon systems. They surely don't want GC glitches in battle situations. The Android team seems to only bother with "good enough" in what concerns Android performance. As a side note, just check how many Android releases are they going through and yet real-audio support isn't quite there. Even Windows Phone has better support for it, and they do have WinRT and .NET on them.
        bitmapbrother 10y ago
        >Even Windows Phone has better support for it, and they do have WinRT and .NET on them. No they don't. Point me to one windows phone audio app that has low latency audio.
        pjmlp 10y ago
        Well there are these sources from Microsoft: https://blogs.windows.com/buildingapps/2014/05/15/real-time-audio-in-windows-store-and-windows-phone-apps/ https://blogs.windows.com/buildingapps/2014/05/15/real-time-... https://rtaudiowsapps.codeplex.com/ https://rtaudiowsapps.codeplex.com/ https://channel9.msdn.com/Events/Build/2014/3-548 https://channel9.msdn.com/Events/Build/2014/3-548 And I just found this, but not sure how good it fares. https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdncrdkgt7 https://www.microsoft.com/en-us/store/apps/audio-meter/9wzdn...
    - merb 10y ago
      do you use or know cyberduck?
- spriggan3 10y ago
  > In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. If the program runs on the user's machine, I'm pretty certain the users WILL notice the difference, memory wise.
  - merb 10y ago
    That's not true. Do you know Cyberduck? It actually takes less memory than most other FTP/SFTP etc programs. and probably feels a dozen times more smooth than most clients.
  - pjmlp 10y ago
    As I said "use the right algorithms and data structures in first place".

matthewrudy 10y ago

Chris Seaton gave this talk recently about JRuby+Truffle and some specifics about how it optimises so well compared to other Ruby implementations. https://youtu.be/b1NTaVQPt1E https://youtu.be/b1NTaVQPt1E Previous discussion https://news.ycombinator.com/item?id=12062454 https://news.ycombinator.com/item?id=12062454

vidarh 10y ago
Chris is also reasonably active here. I've had the pleasure of discussing some of his jRuby work with him in the past (I occasionally plod along with own Ruby compiler in Ruby - it's nowhere near complete) and they've done a lot of impressive work to demonstrate how compiling Ruby into fast code is largely about assuming people will behave sanely (e.g. people won't usually give Fixnum#+ side-effects, or make it return weird stuff), but add fallbacks for when they do. This is the big challenge with Ruby: The subset of Ruby that people actually tend to work in is largely very predictable and possible to compile efficiently, but there's a lot of stuff around the fringes that people expect to work on the very rare occasions that we use it.

azakai 10y ago

I believe those benchmarks are for throughput, though. JS VM startup times (including v8) are highly optimized, while Graal+Truffle run on the JVM which is more optimized for sustained speed. JS VMs also tend to have multiple tiers for that reason - interpreter, baseline, and full JIT, etc. - while AFAIK the Graal+Truffle/JVM approach has just 2 (which is optimal for Java, but not for startup times of JavaScript and other dynamic languages).

the8472 10y ago
Startup times are mostly important for scripting or running things in the browser. If you start applications once on the server or desktop and keep them running then steady-state performance is more important. There also are projects underway to bring AOT compilation / caching of compiled code to the JVM. Right now they're only available to commercial customers due to their experimental nature and the needed support but if I remember the talk correctly they're supposed to be added to openjdk eventually
- azakai 10y ago
  True about AOT coming to the JVM, however, dynamic languages can't be AOT'd well in general, so that won't help Graal+Truffle languages much. Instead, dynamic languages tend to do tiering, which in principle is something Graal+Truffle could do, but it might be a lot of work.
  - deleted 10y ago
    [deleted]
  - hencq 10y ago
    Well at least it would help you avoid warm-up for the interpreter/compiler itself, so it might help a bit.