Hacker News Reader

Comment by renox | Hacker News Reader

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

View on HN

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.

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

>> so could C <<

For example: 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

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.

    Erlang is optimized for latency.
    OpenCL is optimized for t-put.
    Everything else (including C) is in between.

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

More exactly latency of switching between concurrent activities, which might be handling user sessions, but might be something else too.

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.

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.

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.

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.

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

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

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

Reply on news.ycombinator.com