5 ms·

> Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor I hate this kind of marketing trick.

by renox 12y ago

> Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor I hate this kind of marketing trick. So let me add: And here's the bad news, your Erlang program can be much slower than a C program on one core: for example in the alioth 'benchmarks' Erlang run between 3X and 30X slower than a C program on one core ( http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=hipe&lang2=gcc&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te... ) so you may have to throw MANY core at it before the Erlang program is faster than the C program. So beware! YMMV. That said, I hope that Elixir will improve Erlang's adoption as the high availability feature are the big deal IMHO.

brickcap 12y ago
Well I think he was just comparing it to the corresponding erlang programme on a single core. I don't see Joe saying anywhere that it will run N times faster than a c program.
- renox 12y ago
  Which is why this is dishonest.. The real question is 'how can I make my program go fast?' answering about a different question is a marketing trick.
  - lostcolony 12y ago
    "Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor" isn't dishonest. He's clearly speaking to Erlang programmers. What would be dishonest would be "here's the good news for C programmers: Your C program should just run N times faster on an N core processor if written in Erlang". To your point though, Erlang gives you scalability. Yeah, on a single core, the C program will be faster. On multiple cores, multiple processors, multiple -machines-, idiomatic Erlang should scale. C code will not. You have to tear it apart, rewrite it, figure out a distribution model, code that or find a good library, fix the bugs in your own code or work around the caveats of that library, etc etc.
  - rakoo 12y ago
    No, the real question is "how can I make my program scale". Scalability and performance are quasi-orthogonal concepts (quasi, because what matters to an end-user is overall performance, all things considered).
  - rdtsc 12y ago
    What is dishonest? Who is asking "how can I make my program go fast?". I've heard you ask that question. So you asked your own question, then claimed the other one was dishonest. Ok anyway,now that you've asked the question, maybe elaborate a bit why you think your program is slow and how do you think you can make it "go fast".
segmondy 12y ago
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.)

by renox 12y ago

brickcap 12y ago

Well I think he was just comparing it to the corresponding erlang programme on a single core. I don't see Joe saying anywhere that it will run N times faster than a c program.

renox 12y ago
Which is why this is dishonest.. The real question is 'how can I make my program go fast?' answering about a different question is a marketing trick.
- lostcolony 12y ago
  "Here’s the good news for Erlang programmers: Your Erlang program should just run N times faster on an N core processor" isn't dishonest. He's clearly speaking to Erlang programmers. What would be dishonest would be "here's the good news for C programmers: Your C program should just run N times faster on an N core processor if written in Erlang". To your point though, Erlang gives you scalability. Yeah, on a single core, the C program will be faster. On multiple cores, multiple processors, multiple -machines-, idiomatic Erlang should scale. C code will not. You have to tear it apart, rewrite it, figure out a distribution model, code that or find a good library, fix the bugs in your own code or work around the caveats of that library, etc etc.
- rakoo 12y ago
  No, the real question is "how can I make my program scale". Scalability and performance are quasi-orthogonal concepts (quasi, because what matters to an end-user is overall performance, all things considered).
- rdtsc 12y ago
  What is dishonest? Who is asking "how can I make my program go fast?". I've heard you ask that question. So you asked your own question, then claimed the other one was dishonest. Ok anyway,now that you've asked the question, maybe elaborate a bit why you think your program is slow and how do you think you can make it "go fast".

segmondy 12y ago

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.)