4 ms·

Wouldn't targeting GraalVM make sense, too?

by _pmf_ 8y ago

cube2222 8y ago
Could you elaborate please? Why do you think would it make sense?
- chrisseaton 8y ago
  It'd be great to see what a state-of-the-art optimising compiler can do for the performance of Erlang and Elixir.
  - giancarlostoro 8y ago
    While it would be nice this companys focus seems to be towards Erlang specifically so they may have their reasons not to have gone that route. Would be nice to hear what those reasons are for sure.
  - jerf 8y ago
    Given the not-all-that-great improvement of a targeted attempt to speed up Erlang with HiPE, I wouldn't hold your breath for how well a non-targeted approach would go. Unfortunately, Erlang-the-language has several features that seem to be fundamentally slow, in that I've never seen any runtime that goes quickly with them. (A lot of memory copying, for one, even after being as clever as possible with optimizations on that front.) (I no longer believe in the line that there are no slow languages. In practice, there seem to be, and languages in practice seem to plateau at certain performance levels no matter how much effort is put into them. Those who wish to argue are welcome to produce the fast-as-C-at-everything Javascript interpreter or some similar artifact and I will happily retract.) Erlang is still a fine language and it's performance is well in line with several other popular languages; by no means would I say it is unusable. It's just that real engineers need to have clear understandings of the costs and benefits of their tools, which includes understanding not all languages have the same speed characteristics.
    - chrisseaton 8y ago
      HiPE was done a long time ago, and I don't think it tried to use any particularly sophisticated techniques even at the time. Modern compilation techniques such as powerful escape analysis and partial evaluation may be able to do something new. GraalVM runs Ruby about 10x faster than standard Ruby, for example.
      - jerf 8y ago
        "GraalVM runs Ruby about 10x faster than standard Ruby, for example." Which puts it roughly up against the plateau I observe for dynamically-typed languages across the board, except LuaJIT (which AIUI compromises the dynamicness a bit to get there). Ruby is a great deal more than 10x slower than optimal (which is still roughly C, though keep an eye out on that as languages continue to challenge it). Based on the way Erlang works, I wouldn't expect it to get much past two times faster than it already is no matter how much money is poured into it. I remember hearing the line about how there are no slow languages, only slow implementations, back in the early 2000s, when we didn't have any implementations of dynamic scripting languages that had really had a lot of effort poured into them, by modern standards. In 2018, we have numerous such implementations with vast, vast amounts of work poured into them. They are faster than they used to be... and they are still meaningfully slower than optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't do all the bad things that Python or Ruby do to make them slow, but it does add a lot of memory copying that Python and Ruby don't do, and which is probably not as reducible as you'd like no matter how you optimized it (the low-hanging fruit, after all, is already in current Erlang). To be honest, if you like Erlang but you need the next step up in performance and are willing to lose a few guarantees to get there (a very common tradeoff in optimization, after all), the answer is Go, not waiting for a much faster Erlang. Go is significantly faster than Erlang, Go does not have Erlang's memory isolation, and these statements are deeply connected together, not just coincidence.
        pjmlp 8y ago
        None of them had the research money that JavaScript has enjoyed though. Also lets not forget C was quite slow in 8 and 16 bit systems, and it only became as fast thanks to the joy of UB and -O3.
zzzcpan 8y ago
Probably not. VMs are not universal. Things designed for shared memory model, like say GCs, make sacrifices that would not do so good for isolated processes. So a custom unoptimized VM might make more sense than an architecturally unfit VM.
rurban 8y ago
No. Graal is huge, one of the biggest of all VM runtimes. Gluon had the complete opposite goal. lua would be an idea for a small BEAM engine. It would also be much faster.

Wouldn't targeting GraalVM make sense, too?

by _pmf_ 8y ago

Wouldn't targeting GraalVM make sense, too?

cube2222 8y ago

Could you elaborate please? Why do you think would it make sense?

chrisseaton 8y ago
It'd be great to see what a state-of-the-art optimising compiler can do for the performance of Erlang and Elixir.
- giancarlostoro 8y ago
  While it would be nice this companys focus seems to be towards Erlang specifically so they may have their reasons not to have gone that route. Would be nice to hear what those reasons are for sure.
- jerf 8y ago
  Given the not-all-that-great improvement of a targeted attempt to speed up Erlang with HiPE, I wouldn't hold your breath for how well a non-targeted approach would go. Unfortunately, Erlang-the-language has several features that seem to be fundamentally slow, in that I've never seen any runtime that goes quickly with them. (A lot of memory copying, for one, even after being as clever as possible with optimizations on that front.) (I no longer believe in the line that there are no slow languages. In practice, there seem to be, and languages in practice seem to plateau at certain performance levels no matter how much effort is put into them. Those who wish to argue are welcome to produce the fast-as-C-at-everything Javascript interpreter or some similar artifact and I will happily retract.) Erlang is still a fine language and it's performance is well in line with several other popular languages; by no means would I say it is unusable. It's just that real engineers need to have clear understandings of the costs and benefits of their tools, which includes understanding not all languages have the same speed characteristics.
  - chrisseaton 8y ago
    HiPE was done a long time ago, and I don't think it tried to use any particularly sophisticated techniques even at the time. Modern compilation techniques such as powerful escape analysis and partial evaluation may be able to do something new. GraalVM runs Ruby about 10x faster than standard Ruby, for example.
    - jerf 8y ago
      "GraalVM runs Ruby about 10x faster than standard Ruby, for example." Which puts it roughly up against the plateau I observe for dynamically-typed languages across the board, except LuaJIT (which AIUI compromises the dynamicness a bit to get there). Ruby is a great deal more than 10x slower than optimal (which is still roughly C, though keep an eye out on that as languages continue to challenge it). Based on the way Erlang works, I wouldn't expect it to get much past two times faster than it already is no matter how much money is poured into it. I remember hearing the line about how there are no slow languages, only slow implementations, back in the early 2000s, when we didn't have any implementations of dynamic scripting languages that had really had a lot of effort poured into them, by modern standards. In 2018, we have numerous such implementations with vast, vast amounts of work poured into them. They are faster than they used to be... and they are still meaningfully slower than optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't do all the bad things that Python or Ruby do to make them slow, but it does add a lot of memory copying that Python and Ruby don't do, and which is probably not as reducible as you'd like no matter how you optimized it (the low-hanging fruit, after all, is already in current Erlang). To be honest, if you like Erlang but you need the next step up in performance and are willing to lose a few guarantees to get there (a very common tradeoff in optimization, after all), the answer is Go, not waiting for a much faster Erlang. Go is significantly faster than Erlang, Go does not have Erlang's memory isolation, and these statements are deeply connected together, not just coincidence.
      - pjmlp 8y ago
        None of them had the research money that JavaScript has enjoyed though. Also lets not forget C was quite slow in 8 and 16 bit systems, and it only became as fast thanks to the joy of UB and -O3.

zzzcpan 8y ago

Probably not. VMs are not universal. Things designed for shared memory model, like say GCs, make sacrifices that would not do so good for isolated processes. So a custom unoptimized VM might make more sense than an architecturally unfit VM.

rurban 8y ago

No. Graal is huge, one of the biggest of all VM runtimes. Gluon had the complete opposite goal. lua would be an idea for a small BEAM engine. It would also be much faster.