4 ms·

Yeah, isn't it weird that the Go implementation is so much faster than Erlang one?

• masklinn 11y ago
  Probably not entirely, Erlang's lightweight processes have their own private heap (~1.8KB by default on a 64b system), a process dictionary and likely more control structures, and the language is mainly interpreted. A 4x different in performance may be on the high side (idk), but I wouldn't expect erlang processes to be quite as fast to spawn as goroutines. edit: and the erlang bench allocates a bunch of lists on startup: https://github.com/atemerev/skynet/blob/master/erlang/skynet.erl#L10 https://github.com/atemerev/skynet/blob/master/erlang/skynet... `lists:seq()` will allocate a 10-elements linked list, considering this is called recursively and concurrently it might contribute to the issue (or not)
  • deleted 11y ago
    [deleted]
  • dxhdr 11y ago
    Minor clarification -- Erlang is not interpreted, it's compiled to bytecode and executed on the BEAM virtual machine.
    • masklinn 11y ago
      > Erlang is not interpreted, it's compiled to bytecode and executed on the BEAM virtual machine. And Python is compiled to bytecode and executed on the CPython virtual machine. That's still interpreted.
  • jlouis 11y ago
    The major problem, without any measurement and just guesswork, is that you have a larger allocation overhead in Erlang. Not only do you need the process control block for the process, you also need to go to the memory subsystem and grab a heap for the process. In the Go variant, you are allocating out of the same heap and you can usually avoid some allocation there because everything you allocate is used. Not so in the Erlang system. Were these processes/goroutines to do anything more complex, then the difference goes toward zero. But the constant overhead at the lowest level is probably higher.
• mijoharas 11y ago
  Yeah, I was wondering that. There could always be the general overhead in the VM, but the HIPE version (which is compiled IIRC) should be closer. A commenter mentioned that the erlang version would be creating intermediate lists that would have to be garbage collected (see all the lists:seq(0, Div-1) ), but I wouldn't know how to avoid that without writing unidiomatic code. I'm no erlang expert though.
  • masklinn 11y ago
    I don't think the lists would have to be collected, erlang processes have a relatively hefty private heap (233 words) by default, so chances are the process just dies without needing to run a GC[0]. The lists do need to be allocated and initialised though, which may or may not contribute to the runtime. [0] the way I understand it, each process would generate a 10-elements list of small integers, which would be 21 words (1 word + 1 word/element + the sum of the element sizes — 1 word each for small integers)
    • mijoharas 11y ago
      Good point, it would be the allocation, not the GC that would be the problem. My mistake.