3 ms·

Does performance matter considering Elixir is already very slow in per-thread performance?

by blunte 5y ago

dnautics 5y ago
depends on what you are doing. And it's not necessarily "very slow", moving forward as the JIT gets better and better. I highly doubt that this technique is going to be very jittable.
brightball 5y ago
How is it slow?
- blunte 5y ago
  How? Do you mean how do I know it's slow? Because it takes longer to run. Write a typical computation such as Fibonacci in Java and Erlang/Elixir and compare. Fortunately someone has already done this. Elixir is 3x slower than C and 2x slower than Java for this single thread example. https://github.com/drujensen/fib https://github.com/drujensen/fib Apparently this upsets people for me to point this out. However, I did not say that Elixir was slow in general or a bad choice. It's an excellent choice for problems which suit parallelization or which require reliable, consistent performance. Since the parent poster had commented that adding this multi-module dispatch would not be performant, I merely pointed out that the single thread peformance was already slow (as in, why worry too much about the performance cost of the multi dispatch suggestion).
  - CraigJPerry 5y ago
    I’m starting to get a bit fed up with the down-voting behaviour here recently. It used to be that on HN you down-voted for people who were obstructing conversation, being disingenuous or in some cases being excessively disrespectful. Now having read 3 of your comments and seeing all 3 are heavily down-voted and yet the content of your messages is constructive and interesting. If you disagree with something, fine, just don’t vote on it. Save the down-votes for bad actors, not someone with a different view. The last thing HN needs is to become the kind of place where you’re actively encouraged to karma farm or whatever that term is for that behaviour on reddit.
    - dnautics 5y ago
      I think they were downvoted because the first response was almost contentless and the other posts complain too much about the downvotes. Yes, there is some "good info" there but basically they are still presented in a relatively context-poor fashion and defensive, and willfully ignoring other points being made, and most active practitioners of elixir are aware of the context, so the comments are of questionable utility except for people who don't use the system, who may interpret it out of context and come to conclusions that are wrong. In short, they still have a shitposty feel.
    - ddek 5y ago
      Eh, I'd rather the thread discussed the language features in TFA. Once again, a potentially interesting comment section is sidetracked by yet another referendum on {{ niche_programming_language }}'s application to web development. Can't we just keep this to release posts?
    - pjmlp 5y ago
      HN now has lots of folks that just down vote when they disagree, as it happens in many other communities after they grew beyond a specific user base. I always made my statements the way I feel like, since the BBS days, and voting systems haven't change that. There will always people that want to silence you, regardless of the medium. Life is too short to care for them.
  - brightball 5y ago
    It’s slower for an operation like that because of the scheduler ensuring a single process isn’t hogging all of the CPU. When was the last time you needed to write a Fibonacci for anything you’ve built in your career? It’s a benchmark that doesn’t show anything useful for real world applicability.
Zababa 5y ago
On the web site of things, it is faster than Rails, Django, Laravel, Express and even Spring, and this is with Plug and Ecto. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/. That seems to be very good performance to me.
- blunte 5y ago
  People go nuts here on HN if they think you said something bad about their baby. I said per-thread, but I meant single-thread... as in CPU bound single process activity. That is undisputedly slow compared to languages like Java, C/C++, Go, etc. That is also very much not what Erlang is designed for. It adds a lot of overhead with the supervisor and other features which do not give a benefit for single thread CPU heavy activities. And since the parent poster mentioned the multi-dispatch approach would not be performant, I attempted to suggest that the performance cost of that would be less relevant considering Elixir is already not very performant in single thread cases. In other words, it was a moot point. I never said that Elixir/Erlang was slow for multi-thread/process distributed activities. Obviously that is where it really excels. But if you want to crunch numbers sequentially in a way that cannot be spread across multiple processes/threads, then you will find Elixir to be slow. The benchmarks you are referring to are very much multi-thread comparisons. They are specifically NOT what I was was slow.
  - Zababa 5y ago
    You're right about the performance of single-threaded vs multi-threaded Elixir. However, I used web apps as a comparison because they are the most common use case for Elixir. Considering here Elixir performs very well, performance could be one of the reasons why people choose it. In that case, being aware of performance pitfalls is a good thing. I don't agree that performance is a moot point if what you use is slower than some alternatives, and I think that's the main point where we disagree.
    - blunte 5y ago
      I am not a fan of slowing something down, but in the multi-method dispatch example, unless it was being exercised in a tight loop (which would seem very much like a single thread CPU bound scenario which is already a problem), then it wouldn't be exercised often enough to make a big impact. That's just my gut feeling based on my experiences. But if this really is a big deal, then it would be fair to consider the other language features which do not contribute to the reliability, scalability, and other core Erlang/BEAM features. For example, what is the cost of pattern matching in general? Doesn't that add considerable overhead, just for the benefit of making code cleaner? If that's acceptable, then I don't see why "just one more" feature - in this case a homegrown multi-method dispatch across modules - should be considered non-performant.

Does performance matter considering Elixir is already very slow in per-thread performance?

by blunte 5y ago

Does performance matter considering Elixir is already very slow in per-thread performance?

depends on what you are doing. And it's not necessarily "very slow", moving forward as the JIT gets better and better. I highly doubt that this technique is going to be very jittable.

brightball 5y ago

How is it slow?

blunte 5y ago
How? Do you mean how do I know it's slow? Because it takes longer to run. Write a typical computation such as Fibonacci in Java and Erlang/Elixir and compare. Fortunately someone has already done this. Elixir is 3x slower than C and 2x slower than Java for this single thread example. https://github.com/drujensen/fib https://github.com/drujensen/fib Apparently this upsets people for me to point this out. However, I did not say that Elixir was slow in general or a bad choice. It's an excellent choice for problems which suit parallelization or which require reliable, consistent performance. Since the parent poster had commented that adding this multi-module dispatch would not be performant, I merely pointed out that the single thread peformance was already slow (as in, why worry too much about the performance cost of the multi dispatch suggestion).
- CraigJPerry 5y ago
  I’m starting to get a bit fed up with the down-voting behaviour here recently. It used to be that on HN you down-voted for people who were obstructing conversation, being disingenuous or in some cases being excessively disrespectful. Now having read 3 of your comments and seeing all 3 are heavily down-voted and yet the content of your messages is constructive and interesting. If you disagree with something, fine, just don’t vote on it. Save the down-votes for bad actors, not someone with a different view. The last thing HN needs is to become the kind of place where you’re actively encouraged to karma farm or whatever that term is for that behaviour on reddit.
  - dnautics 5y ago
    I think they were downvoted because the first response was almost contentless and the other posts complain too much about the downvotes. Yes, there is some "good info" there but basically they are still presented in a relatively context-poor fashion and defensive, and willfully ignoring other points being made, and most active practitioners of elixir are aware of the context, so the comments are of questionable utility except for people who don't use the system, who may interpret it out of context and come to conclusions that are wrong. In short, they still have a shitposty feel.
  - ddek 5y ago
    Eh, I'd rather the thread discussed the language features in TFA. Once again, a potentially interesting comment section is sidetracked by yet another referendum on {{ niche_programming_language }}'s application to web development. Can't we just keep this to release posts?
  - pjmlp 5y ago
    HN now has lots of folks that just down vote when they disagree, as it happens in many other communities after they grew beyond a specific user base. I always made my statements the way I feel like, since the BBS days, and voting systems haven't change that. There will always people that want to silence you, regardless of the medium. Life is too short to care for them.
- brightball 5y ago
  It’s slower for an operation like that because of the scheduler ensuring a single process isn’t hogging all of the CPU. When was the last time you needed to write a Fibonacci for anything you’ve built in your career? It’s a benchmark that doesn’t show anything useful for real world applicability.

Zababa 5y ago

On the web site of things, it is faster than Rails, Django, Laravel, Express and even Spring, and this is with Plug and Ecto. https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/. That seems to be very good performance to me.

blunte 5y ago
People go nuts here on HN if they think you said something bad about their baby. I said per-thread, but I meant single-thread... as in CPU bound single process activity. That is undisputedly slow compared to languages like Java, C/C++, Go, etc. That is also very much not what Erlang is designed for. It adds a lot of overhead with the supervisor and other features which do not give a benefit for single thread CPU heavy activities. And since the parent poster mentioned the multi-dispatch approach would not be performant, I attempted to suggest that the performance cost of that would be less relevant considering Elixir is already not very performant in single thread cases. In other words, it was a moot point. I never said that Elixir/Erlang was slow for multi-thread/process distributed activities. Obviously that is where it really excels. But if you want to crunch numbers sequentially in a way that cannot be spread across multiple processes/threads, then you will find Elixir to be slow. The benchmarks you are referring to are very much multi-thread comparisons. They are specifically NOT what I was was slow.
- Zababa 5y ago
  You're right about the performance of single-threaded vs multi-threaded Elixir. However, I used web apps as a comparison because they are the most common use case for Elixir. Considering here Elixir performs very well, performance could be one of the reasons why people choose it. In that case, being aware of performance pitfalls is a good thing. I don't agree that performance is a moot point if what you use is slower than some alternatives, and I think that's the main point where we disagree.
  - blunte 5y ago
    I am not a fan of slowing something down, but in the multi-method dispatch example, unless it was being exercised in a tight loop (which would seem very much like a single thread CPU bound scenario which is already a problem), then it wouldn't be exercised often enough to make a big impact. That's just my gut feeling based on my experiences. But if this really is a big deal, then it would be fair to consider the other language features which do not contribute to the reliability, scalability, and other core Erlang/BEAM features. For example, what is the cost of pattern matching in general? Doesn't that add considerable overhead, just for the benefit of making code cleaner? If that's acceptable, then I don't see why "just one more" feature - in this case a homegrown multi-method dispatch across modules - should be considered non-performant.