4 ms·

BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investme

by pron 7y ago

BEAM is a wonderful VM, but calling it "optimized" for anything is problematic. It has focused on certain use cases, but it's seen less than 1% of the investment in the JDK, so I guess it's better to call it "specialized". While it works well enough for many things, its performance is like the JVM limping on both legs after a terrible car accident and a bad case of pneumonia while trying to walk on an icy road. You are correct, though, that it probably performs better than a general-purpose platform with a similar level of investment.

nivertech 7y ago
BTW, many years ago, the author of Erjang told me that eventually Erjang will be faster than BEAM for running Erlang apps, b/c of all the investment that went into the JVM ecosystem. I'm not sure it's the case now (probably since nobody using Erjang in production). You are correct in describing the raw performance of BEAM, but I'm not sure it's relevant for a typical IO-bound Erlang/Elixir app. Also most large real-life apps would use NIFs written in a language capable generating native code, i.e. C/C++ or Rust.
patrec 7y ago
There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.
- pron 7y ago
  I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (there are somewhat similar features in Java platform languages like Kotlin's coroutines), but there is currently a project (that I'm leading) to add fibers (AKA user-mode threads, AKA lightweight threads, AKA green threads) to the JVM: https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/
  - mruts 7y ago
    There’s Akka. Also Scala has Future’s. Both are very similar to green threads.
  - chrisseaton 7y ago
    It's true that BEAM has excellent concurrency, parallelism, supervision, message passing... but I don't know understand why that has to come at the expense of being terrible at everything else. Why doesn't it have even a baseline reasonable quality JIT? Why doesn't its GC use a design more recent than half a century ago? It's got big corporate backers and PhDs working on it.
    - pron 7y ago
      I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.
      - zambal 7y ago
        Searching for TruffleBEAM+Loom doesn't yield any meaningful results. Could you provide any info about what it is?
        deleted 7y ago
        [deleted]
        pron 7y ago
        It's something that I hope would exist one day. Loom is a project that I'm working on to add lightweight threads to the Java platform (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/) and Truffle is a framework that allows writing fast language runtimes for the Java platform or standalone that chrisseaton is working on (https://github.com/oracle/graal/tree/master/truffle https://github.com/oracle/graal/tree/master/truffle).
    - 7y ago
- eternalban 7y ago
  IIRC, Kilim (a Java library) performed better than Erlang in benchmarks.
- verttii 7y ago
  I'd say the feature of BEAM is fault-tolerant massive scalability of concurrency rather than performance/throughput. JVM as a platform lacks all the concurrency tooling of BEAM like the integrated debugging and monitoring tools. The AKKA implementation seems like a total afterthought rather than the fundamental core which it is in Erlang. Moreover, from what I understand unlike BEAM, JVM does not prioritize low consistent latency but throughput instead. I just feel they're designed for very different purposes. BEAM is most definitely not a general computing platform and would not perform well as such. In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language.
  - pron 7y ago
    > In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language. Concurrent stateful distributed systems on the Java platform probably outnumber those on BEAM 100 to 1, but I agree that we absolutely love Erlang's relevant constructs, which is why we're bringing them to the Java platform.
tokenrove 7y ago
I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.
- pron 7y ago
  Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job done for whatever it is they're used for, and if all you're doing is IO it may not be too bad, but let's not mention those runtimes anywhere near good performance. BEAM is certainly in the bottom half or third of the Techempower benchmarks.
  - cutler 7y ago
    Don't forget Fibers - coming to a JVM near you soon!
    - Blackthorn 7y ago
      Hard for him to forget that -- take a look at who you're responding to.
  - verttii 7y ago
    yeah each individual process has low resource allocation. There could be millions running on the same box so that makes sense. Luckily, computational parallelization is not a big challenge with new libraries such as: https://github.com/plataformatec/flow https://github.com/plataformatec/flow However, immutability might still become a challenge in terms of resources/performance. Rust is often used to patch that with Erlang's NIF.

by pron 7y ago

nivertech 7y ago

BTW, many years ago, the author of Erjang told me that eventually Erjang will be faster than BEAM for running Erlang apps, b/c of all the investment that went into the JVM ecosystem. I'm not sure it's the case now (probably since nobody using Erjang in production). You are correct in describing the raw performance of BEAM, but I'm not sure it's relevant for a typical IO-bound Erlang/Elixir app. Also most large real-life apps would use NIFs written in a language capable generating native code, i.e. C/C++ or Rust.

patrec 7y ago

There is no doubt that JVM can provide massively better performance for a lot of stuff, but I wouldn't be suprised if Beam kicked JVM's butt in at least some areas. It's pretty much the only system I know of that provides for massive numbers of fairly scheduled, preemptive green threads. To do so it makes trade-offs that are not generally attractive, but I'd be surprised if it didn't beat the JVM here.

pron 7y ago
I would be. BEAM is just a very slow platform, not just compared to Java, but also compared to JavaScript and Go. Again, that's not to say it's not very useful for some things (although many Erlang apps are really mixed Erlang/C apps because of BEAM's performance). Hey, CPython is really slow, too and yet very useful. Green threads is another matter as it's not a feature that currently exists on the Java platform (there are somewhat similar features in Java platform languages like Kotlin's coroutines), but there is currently a project (that I'm leading) to add fibers (AKA user-mode threads, AKA lightweight threads, AKA green threads) to the JVM: https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/
- mruts 7y ago
  There’s Akka. Also Scala has Future’s. Both are very similar to green threads.
- chrisseaton 7y ago
  It's true that BEAM has excellent concurrency, parallelism, supervision, message passing... but I don't know understand why that has to come at the expense of being terrible at everything else. Why doesn't it have even a baseline reasonable quality JIT? Why doesn't its GC use a design more recent than half a century ago? It's got big corporate backers and PhDs working on it.
  - pron 7y ago
    I would imagine that's because they'd rather focus whatever resources they have on the needs and priorities of their target audience, which probably don't think performance is critical. I hope that one day TruffleBEAM+Loom would be a great platform for all those wonderful Erlang apps.
    - zambal 7y ago
      Searching for TruffleBEAM+Loom doesn't yield any meaningful results. Could you provide any info about what it is?
      - deleted 7y ago
        [deleted]
      - pron 7y ago
        It's something that I hope would exist one day. Loom is a project that I'm working on to add lightweight threads to the Java platform (https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/) and Truffle is a framework that allows writing fast language runtimes for the Java platform or standalone that chrisseaton is working on (https://github.com/oracle/graal/tree/master/truffle https://github.com/oracle/graal/tree/master/truffle).
  - 7y ago
eternalban 7y ago
IIRC, Kilim (a Java library) performed better than Erlang in benchmarks.
verttii 7y ago
I'd say the feature of BEAM is fault-tolerant massive scalability of concurrency rather than performance/throughput. JVM as a platform lacks all the concurrency tooling of BEAM like the integrated debugging and monitoring tools. The AKKA implementation seems like a total afterthought rather than the fundamental core which it is in Erlang. Moreover, from what I understand unlike BEAM, JVM does not prioritize low consistent latency but throughput instead. I just feel they're designed for very different purposes. BEAM is most definitely not a general computing platform and would not perform well as such. In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language.
- pron 7y ago
  > In contrast, I'd imagine it'd be painful to develop concurrent stateful distributed systems on top of the JVM, regardless of the language. Concurrent stateful distributed systems on the Java platform probably outnumber those on BEAM 100 to 1, but I agree that we absolutely love Erlang's relevant constructs, which is why we're bringing them to the Java platform.

tokenrove 7y ago

I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.

pron 7y ago
Yeah, but lightweight threading is a built in primitive in BEAM, so if you only measure scheduling overhead it is very low, but once you do any work inside those processes, it runs like any code running on low-performance runtimes. The isolated heaps are also OK, but the modern JVM GCs would still give you lower latency even with a shared heap. BEAM, CPython, MRI Ruby and other low-performance runtimes get the job done for whatever it is they're used for, and if all you're doing is IO it may not be too bad, but let's not mention those runtimes anywhere near good performance. BEAM is certainly in the bottom half or third of the Techempower benchmarks.
- cutler 7y ago
  Don't forget Fibers - coming to a JVM near you soon!
  - Blackthorn 7y ago
    Hard for him to forget that -- take a look at who you're responding to.
- verttii 7y ago
  yeah each individual process has low resource allocation. There could be millions running on the same box so that makes sense. Luckily, computational parallelization is not a big challenge with new libraries such as: https://github.com/plataformatec/flow https://github.com/plataformatec/flow However, immutability might still become a challenge in terms of resources/performance. Rust is often used to patch that with Erlang's NIF.