4 ms·

it's no marketing trick. Here's the reality. Let's suppose you have a C program that can run 10x faster than an equivalent erlang program, and your erlang prog

it's no marketing trick. Here's the reality. Let's suppose you have a C program that can run 10x faster than an equivalent erlang program, and your erlang program scales by the core, then you need 10 cores to have your erlang program keep up with C. The idea is that it's far easier to scale up by cores in Erlang than in C. Parallelization is far harder with C than in Erlang, so you might find that even tho your C program runs 10x faster, given 1000 cores, you won't be able to scale it without a complete rewrite, whereas you can take the same erlang problem and with minimal modification have it run 100x faster than the C equivalent on your thousand cores.

JoeAltmaier 12y ago
Yes that sounds typical of scalable languages. There's a minimum working set where it starts to win. So for most startups, its premature to worry about scaling and C is a much better choice.
- AnimalMuppet 12y ago
  For most startups, it's premature to worry about maximizing single core performance, too. Write it in whatever language is best for writing it in. Worry about performance when you have to. If you never have to, that's a bit of a bummer, but it means you didn't do a bunch of wasted work.
jerf 12y ago
Even Erlang can't promise linear scaling forever, because nothing can. We call things that can linearly scale indefinitely "embarrassingly parallel", and the point of the first word in that phrase is that it's so easy that it's embarrassing to claim to be good at it, because it's easy. So for the class of problems that Erlang can scale like that, well, so could C. It's what I consider to be a core problem with the dynamic languages, which Erlang technically is... you take such a single-core hit that it's essentially impossible to gain the performance back on multithreading. It's one of the reasons to be taking a serious look at Go; while it is far from the first "modern threading" system, it's one of the first to be combined with simple near-C performance. (Emphasis carefully chosen.) Java arguably has some solutions though I've not yet taken a close look at Akka performance. Erlang doesn't have near-C performance. Haskell can only get near-C performance with a lot of work and care. (They're still working on it, but it's still non-trivial.) The scripting languages are laughably far away from near-C performance and you take such a performance hit that it doesn't matter how easy they make multiprocessing after that. I've still used Erlang for things that are truly IO bound. It's great for that and a very solid VM. But don't fool yourself into thinking Erlang is a performance solution for anything else. (And I find people yell "IO bound!" a bit too readily sometimes. That's really in the class of things you should profile before being sure.)
- virmundi 12y ago
  It is for this reason that I decided to use Clojure over Erlang. I get close to Java performance, which is fast enough for me. I get parallelism in the core language and actors from Pulsar. I've still got LYSE4GG on my desk, read about half, but I doubt I'll use Erlang for anything other than ruminations on ideas.
- igouy 12y ago
  >> so could C << For example: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=gcc&data=u64q#faster-programs-measurements http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... "Erlang FAQ 1.4 What sort of problems is Erlang not particularly suitable for? The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance. … Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages…" http://www.erlang.org/faq/introduction.html#idp27238416 http://www.erlang.org/faq/introduction.html#idp27238416
- nivertech 12y ago
  Erlang is optimized for latency. OpenCL is optimized for t-put. Everything else (including C) is in between.
  - renox 12y ago
    > Erlang is optimized for latency. Too short: for latency with multiple simultaneous users. If you have a 'one shot' program or one user at a time, you'll probably get better latency with C than with Erlang.
    - nivertech 12y ago
      More exactly latency of switching between concurrent activities, which might be handling user sessions, but might be something else too.

JoeAltmaier 12y ago

Yes that sounds typical of scalable languages. There's a minimum working set where it starts to win. So for most startups, its premature to worry about scaling and C is a much better choice.

AnimalMuppet 12y ago
For most startups, it's premature to worry about maximizing single core performance, too. Write it in whatever language is best for writing it in. Worry about performance when you have to. If you never have to, that's a bit of a bummer, but it means you didn't do a bunch of wasted work.

jerf 12y ago

Even Erlang can't promise linear scaling forever, because nothing can. We call things that can linearly scale indefinitely "embarrassingly parallel", and the point of the first word in that phrase is that it's so easy that it's embarrassing to claim to be good at it, because it's easy. So for the class of problems that Erlang can scale like that, well, so could C. It's what I consider to be a core problem with the dynamic languages, which Erlang technically is... you take such a single-core hit that it's essentially impossible to gain the performance back on multithreading. It's one of the reasons to be taking a serious look at Go; while it is far from the first "modern threading" system, it's one of the first to be combined with simple near-C performance. (Emphasis carefully chosen.) Java arguably has some solutions though I've not yet taken a close look at Akka performance. Erlang doesn't have near-C performance. Haskell can only get near-C performance with a lot of work and care. (They're still working on it, but it's still non-trivial.) The scripting languages are laughably far away from near-C performance and you take such a performance hit that it doesn't matter how easy they make multiprocessing after that. I've still used Erlang for things that are truly IO bound. It's great for that and a very solid VM. But don't fool yourself into thinking Erlang is a performance solution for anything else. (And I find people yell "IO bound!" a bit too readily sometimes. That's really in the class of things you should profile before being sure.)

virmundi 12y ago
It is for this reason that I decided to use Clojure over Erlang. I get close to Java performance, which is fast enough for me. I get parallelism in the core language and actors from Pulsar. I've still got LYSE4GG on my desk, read about half, but I doubt I'll use Erlang for anything other than ruminations on ideas.
igouy 12y ago
>> so could C << For example: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=hipe&lang2=gcc&data=u64q#faster-programs-measurements http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... "Erlang FAQ 1.4 What sort of problems is Erlang not particularly suitable for? The most common class of 'less suitable' problems is characterised by performance being a prime requirement and constant-factors having a large effect on performance. … Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages…" http://www.erlang.org/faq/introduction.html#idp27238416 http://www.erlang.org/faq/introduction.html#idp27238416
nivertech 12y ago
Erlang is optimized for latency. OpenCL is optimized for t-put. Everything else (including C) is in between.
- renox 12y ago
  > Erlang is optimized for latency. Too short: for latency with multiple simultaneous users. If you have a 'one shot' program or one user at a time, you'll probably get better latency with C than with Erlang.
  - nivertech 12y ago
    More exactly latency of switching between concurrent activities, which might be handling user sessions, but might be something else too.