7 ms·

I thought the point of erlang was that it was easier to code for distributed systems, not that it was necessarily faster as a language for simple benchmarks.

by far33d 16y ago

cperciva 16y ago
Macrobenchmarks are made up of microbenchmarks. More seriously, if your code is serially 10x faster, you can grow 10x further before you need to worry about horizontal scaling.
- davidw 16y ago
  Ok, but the problem is that part of the speed that Erlang is giving up in this benchmark is something you get back, with interest, if you make a more complex system, in terms of programmer time and program complexity. I suppose it's like comparing C with Python. C is simply faster, but you're making a tradeoff because it's slower to code with, generally.
  - cperciva 16y ago
    C is simply faster, but you're making a tradeoff because it's slower to code with, generally. Exactly. And you need to decide on a case-by-case basis whether having a longer runway (because C gives you more time before you run into scalability problems) compensates for needing longer before you can take off (because C is a harder language).
    - eru 16y ago
      > (because C gives you more time before you run into scalability problems) That's true for implementing the same algorithm. But C is so hard to get right, that you will probably be able to use only the simplest algorithms in your C code. (Or the other way round, you can scale by using better algorithms in a higher level language like Python much easier and longer than you can do so in C.) That makes the comparison more complicated. Also Python (and most other languages) work quite nicely together with C. So you can start with Python and replace the hotspots with C. (And be sure to identify the hotspots with a profiler---lest you guess wrong.)
      - ct4ul4u 16y ago
        > But C is so hard to get right, that you will probably be able to use only the simplest algorithms in your C code This is a gross exaggeration. It's not that hard to get C code right (C++ is a different story). I am unaware of any effort undertaken by skilled C programmers that failed because of limits C placed on algorithmic complexity. I am not arguing with your preference for higher level languages, just your statement that C is so difficult that it limits algorithmic expression. C is substantially less compact and requires you to write code for things you get for free from other languages. Longer code takes more time to write and more time to read. Each feature or function point will, on average, take significantly longer to develop. On the other hand, a developer trying to write an OS in Python would also have some productivity challenges in other dimensions. I am aware of the paradigmatic challenge C presents for many developers trained in the last 15 years. Trying to write in an OO style in C is neither fun nor advisable. Fortunately, most non-ui development is equally agreeable to other styles (although the developer may not be). I'm not a C bigot and I like or love a number of high level languages (Python, Lisp, Haskell). I just don't think people should be afraid of C. Its closer-to-the-metal nature is an opportunity as well as a cost. I'll close with a pointer to a great site written in C: http://www.halfbakery.com http://www.halfbakery.com.
        eru 16y ago
        I agree. And I should have chosen different words. What you say is pretty much what I wanted to express. The original comment said, that with Python you run into scalability problems earlier than with C. And I wanted to add, that with C you run into (solvable but hard) `scalability' problems in terms of effort needed to cope with algorithmic complexity, much sooner. And more clever algorithms are often the key to solving scalability problems. (P.S. I do not like OOP, either. State is ugly.)
        ct4ul4u 16y ago
        > And I wanted to add, that with C you run into (solvable but hard) `scalability' problems in terms of effort needed to cope with algorithmic complexity, much sooner. I have certainly seen this effect. In retrospect, I wonder if this could be somewhat mitigated by real refactoring for C?
- yxhuvud 16y ago
  Which is true if and only if the problem can be solved at all by a centralized system. This is not true for the major use cases of erlang.
  - cperciva 16y ago
    Of course. If you need your system to be distributed from the start, these benchmarks are irrelevant. But most people aren't writing telecommunication software and can handle having a few single points of failure.
mononcqc 16y ago
The main point is usually about reliability and fault-tolerance. Distribution and concurrency are a bit of a lucky side-effect from that (and the standards that were in the telecom world back then). I'm exaggerating, but distribution came into the language much much later and wasn't exactly a design goal when the language was started as far as I know :)

I thought the point of erlang was that it was easier to code for distributed systems, not that it was necessarily faster as a language for simple benchmarks.

by far33d 16y ago

I thought the point of erlang was that it was easier to code for distributed systems, not that it was necessarily faster as a language for simple benchmarks.

cperciva 16y ago

Macrobenchmarks are made up of microbenchmarks. More seriously, if your code is serially 10x faster, you can grow 10x further before you need to worry about horizontal scaling.

davidw 16y ago
Ok, but the problem is that part of the speed that Erlang is giving up in this benchmark is something you get back, with interest, if you make a more complex system, in terms of programmer time and program complexity. I suppose it's like comparing C with Python. C is simply faster, but you're making a tradeoff because it's slower to code with, generally.
- cperciva 16y ago
  C is simply faster, but you're making a tradeoff because it's slower to code with, generally. Exactly. And you need to decide on a case-by-case basis whether having a longer runway (because C gives you more time before you run into scalability problems) compensates for needing longer before you can take off (because C is a harder language).
  - eru 16y ago
    > (because C gives you more time before you run into scalability problems) That's true for implementing the same algorithm. But C is so hard to get right, that you will probably be able to use only the simplest algorithms in your C code. (Or the other way round, you can scale by using better algorithms in a higher level language like Python much easier and longer than you can do so in C.) That makes the comparison more complicated. Also Python (and most other languages) work quite nicely together with C. So you can start with Python and replace the hotspots with C. (And be sure to identify the hotspots with a profiler---lest you guess wrong.)
    - ct4ul4u 16y ago
      > But C is so hard to get right, that you will probably be able to use only the simplest algorithms in your C code This is a gross exaggeration. It's not that hard to get C code right (C++ is a different story). I am unaware of any effort undertaken by skilled C programmers that failed because of limits C placed on algorithmic complexity. I am not arguing with your preference for higher level languages, just your statement that C is so difficult that it limits algorithmic expression. C is substantially less compact and requires you to write code for things you get for free from other languages. Longer code takes more time to write and more time to read. Each feature or function point will, on average, take significantly longer to develop. On the other hand, a developer trying to write an OS in Python would also have some productivity challenges in other dimensions. I am aware of the paradigmatic challenge C presents for many developers trained in the last 15 years. Trying to write in an OO style in C is neither fun nor advisable. Fortunately, most non-ui development is equally agreeable to other styles (although the developer may not be). I'm not a C bigot and I like or love a number of high level languages (Python, Lisp, Haskell). I just don't think people should be afraid of C. Its closer-to-the-metal nature is an opportunity as well as a cost. I'll close with a pointer to a great site written in C: http://www.halfbakery.com http://www.halfbakery.com.
      - eru 16y ago
        I agree. And I should have chosen different words. What you say is pretty much what I wanted to express. The original comment said, that with Python you run into scalability problems earlier than with C. And I wanted to add, that with C you run into (solvable but hard) `scalability' problems in terms of effort needed to cope with algorithmic complexity, much sooner. And more clever algorithms are often the key to solving scalability problems. (P.S. I do not like OOP, either. State is ugly.)
        ct4ul4u 16y ago
        > And I wanted to add, that with C you run into (solvable but hard) `scalability' problems in terms of effort needed to cope with algorithmic complexity, much sooner. I have certainly seen this effect. In retrospect, I wonder if this could be somewhat mitigated by real refactoring for C?
yxhuvud 16y ago
Which is true if and only if the problem can be solved at all by a centralized system. This is not true for the major use cases of erlang.
- cperciva 16y ago
  Of course. If you need your system to be distributed from the start, these benchmarks are irrelevant. But most people aren't writing telecommunication software and can handle having a few single points of failure.

mononcqc 16y ago

The main point is usually about reliability and fault-tolerance. Distribution and concurrency are a bit of a lucky side-effect from that (and the standards that were in the telecom world back then). I'm exaggerating, but distribution came into the language much much later and wasn't exactly a design goal when the language was started as far as I know :)