3 ms·

Elixir never performs all to well in microbenchmarks. Yet in every application I've seen Elixir/Erlang projects compared to more standard Node, Python, or even

Elixir never performs all to well in microbenchmarks. Yet in every application I've seen Elixir/Erlang projects compared to more standard Node, Python, or even C# projects and the Elixir one generally has way better performance and feels much faster even under load. Personally I think much of it is due to async being predominant in Node and python. Async seems much harder than actor or even threading for debugging performance issues. Sure it feels easier to do async at first. But async leads to small bloat adding up and makes it very difficult to debug and track down. It makes profiling harder, etc. In BEAM, every actor has its own queue. It's trivial to inspect and analyze performance blockages. Async by contrast puts everything into one giant processing queue. Plus every function call in async gets extra overhead added. It all adds up.

hosh 2y ago
This has to do with how async works without preemption and resource limits. There's a counter-intuitive thing when trying to balance load across resources: applying resource limits helps the system run better overall. One example: when scaling a web app, there comes a point when scaling up the database doesn't seem to help. So we're tempted to increase the connection pool because that looks like a bottleneck. Increasing the pool can make the overall system perform worse, because often times, it is slow queries and poorly performing queries that is stopping up the system. Another example: one of the systems I worked on has over 250 node runtimes running on a single, large server. It used pm2 and did not apply cgroups to limit CPU resources. The whole system was a hog, and I temporarily fixed it by consolidating things to run on about 50 node runtimes. When I moved them over to Kubernetes, I also applied CPU resource limit, each in its own pod. I set the limits based on what I measured when they were all running on PM2 ... but the same code running on Kubernetes ran with 10x less CPU overall. Why? Because the async code were not allowed to just run grabbing as much CPU as it can for as long as it can, and the kernel scheduler was able to fairly run. That allowed the entire system to run with less resources overall. There's probably some math that folks who know Operations Research can prove all this.
- sapiogram 2y ago
  > When I moved them over to Kubernetes, I also applied CPU resource limit, each in its own pod. I set the limits based on what I measured when they were all running on PM2 ... but the same code running on Kubernetes ran with 10x less CPU overall. Why? Because the async code were not allowed to just run grabbing as much CPU as it can for as long as it can, and the kernel scheduler was able to fairly run. That allowed the entire system to run with less resources overall. As someone who has advocated against Kubernetes CPU limits everywhere I've worked, I'm really struggling to see how they helped you here. The code used 10x less CPU with CPU limits, with no adverse effects? What were all those CPU cycles going before?
  - evidencetamper 2y ago
    The adverse effect is higher latency, as the execution gets delayed due to throttling. Parent probably didn't care about latency.
    - hosh 2y ago
      It’s a data pipeline that polls periodically. Average latency matters a lot less than lower variance of latency. Even when I distribute offsets on polling, I would get these seesaws where enough fights over resources.
  - marcosdumay 2y ago
    > The code used 10x less CPU with CPU limits, with no adverse effects? The normal situation is that defective situations get a much large latency, while the correct requests run much faster. It's a problem on the cases when the first set isn't actually defective. But it normally takes a reevaluation of the entire thing to solve those, and the non-limited situation isn't any good either.
jayd16 2y ago
> Async by contrast puts everything into one giant processing queue I don't know about node but C# has async contexts you can use .
- kerkeslager 2y ago
  ...which is so much harder than actors.
deleted 2y ago
[deleted]
neonsunset 2y ago
> Async by contrast puts everything into one giant processing queue How can you make performance claims while getting the details completely wrong? Neither .NET's nor Rust's Tokio async implementations work this way. They use all available cores (unless overridden) and implement work-stealing threadpool. .NET in addition uses hill-climbing and cooperative blocking detection mechanism to quickly adapt to workloads and ensure optimal throughput. All that while spending 0.1x CPU on computation when compared to BEAM, and having much lower memory footprint. You cannot compare Erlang/Elixir with top of the line compiled languages.
- hosh 2y ago
  That sounds about right for .NET. One of the Elixir projects I worked on lived alongside a C# .NET, the latter being a game server backend. The guy who architect and implemented it made it so that large numbers of people can interact in realtime without having to shard. It is pretty amazing stuff in my book. On the other hand, I have yet to have to implement a liveness probe with an Elixir app, and I've had to do that with .NET because it can and does freeze. That game server also didn't use up all the available cores as well as the Elixir app. We also couldn't attach a REPL directly to the .NET app, though we certainly tried. I would be curious to see if Rust works out better in production.
  - neonsunset 2y ago
    [flagged]
    - gjvc 2y ago
      What are you saying?
    - lelanthran 2y ago
      > I swear, the affliction of failing to understand the underlying concepts upon which a technology A or B is built is a plague upon our industry. Instead, everything clearly must fit into the concepts limited to whatever “mother tongue” language a particular developer has mastered. Ironic, since any time you post about a programming language it's to inform that C# does it better. Not just here; someone with your nick also whined when the creator of C# made a technical deficient decision when choosing Go over C# to implement typescript. It's hard for a rational person to believe that someone would make the argument that the creator of the language must have made a mistake just because he reached for (in his words) a more appropriate language in that context. You have a blind spot when it comes to C#. You also probably already know it.

hosh 2y ago

This has to do with how async works without preemption and resource limits. There's a counter-intuitive thing when trying to balance load across resources: applying resource limits helps the system run better overall. One example: when scaling a web app, there comes a point when scaling up the database doesn't seem to help. So we're tempted to increase the connection pool because that looks like a bottleneck. Increasing the pool can make the overall system perform worse, because often times, it is slow queries and poorly performing queries that is stopping up the system. Another example: one of the systems I worked on has over 250 node runtimes running on a single, large server. It used pm2 and did not apply cgroups to limit CPU resources. The whole system was a hog, and I temporarily fixed it by consolidating things to run on about 50 node runtimes. When I moved them over to Kubernetes, I also applied CPU resource limit, each in its own pod. I set the limits based on what I measured when they were all running on PM2 ... but the same code running on Kubernetes ran with 10x less CPU overall. Why? Because the async code were not allowed to just run grabbing as much CPU as it can for as long as it can, and the kernel scheduler was able to fairly run. That allowed the entire system to run with less resources overall. There's probably some math that folks who know Operations Research can prove all this.

sapiogram 2y ago
> When I moved them over to Kubernetes, I also applied CPU resource limit, each in its own pod. I set the limits based on what I measured when they were all running on PM2 ... but the same code running on Kubernetes ran with 10x less CPU overall. Why? Because the async code were not allowed to just run grabbing as much CPU as it can for as long as it can, and the kernel scheduler was able to fairly run. That allowed the entire system to run with less resources overall. As someone who has advocated against Kubernetes CPU limits everywhere I've worked, I'm really struggling to see how they helped you here. The code used 10x less CPU with CPU limits, with no adverse effects? What were all those CPU cycles going before?
- evidencetamper 2y ago
  The adverse effect is higher latency, as the execution gets delayed due to throttling. Parent probably didn't care about latency.
  - hosh 2y ago
    It’s a data pipeline that polls periodically. Average latency matters a lot less than lower variance of latency. Even when I distribute offsets on polling, I would get these seesaws where enough fights over resources.
- marcosdumay 2y ago
  > The code used 10x less CPU with CPU limits, with no adverse effects? The normal situation is that defective situations get a much large latency, while the correct requests run much faster. It's a problem on the cases when the first set isn't actually defective. But it normally takes a reevaluation of the entire thing to solve those, and the non-limited situation isn't any good either.

jayd16 2y ago

> Async by contrast puts everything into one giant processing queue I don't know about node but C# has async contexts you can use .

kerkeslager 2y ago
...which is so much harder than actors.

deleted 2y ago

[deleted]

neonsunset 2y ago

> Async by contrast puts everything into one giant processing queue How can you make performance claims while getting the details completely wrong? Neither .NET's nor Rust's Tokio async implementations work this way. They use all available cores (unless overridden) and implement work-stealing threadpool. .NET in addition uses hill-climbing and cooperative blocking detection mechanism to quickly adapt to workloads and ensure optimal throughput. All that while spending 0.1x CPU on computation when compared to BEAM, and having much lower memory footprint. You cannot compare Erlang/Elixir with top of the line compiled languages.

hosh 2y ago
That sounds about right for .NET. One of the Elixir projects I worked on lived alongside a C# .NET, the latter being a game server backend. The guy who architect and implemented it made it so that large numbers of people can interact in realtime without having to shard. It is pretty amazing stuff in my book. On the other hand, I have yet to have to implement a liveness probe with an Elixir app, and I've had to do that with .NET because it can and does freeze. That game server also didn't use up all the available cores as well as the Elixir app. We also couldn't attach a REPL directly to the .NET app, though we certainly tried. I would be curious to see if Rust works out better in production.
- neonsunset 2y ago
  [flagged]
  - gjvc 2y ago
    What are you saying?
  - lelanthran 2y ago
    > I swear, the affliction of failing to understand the underlying concepts upon which a technology A or B is built is a plague upon our industry. Instead, everything clearly must fit into the concepts limited to whatever “mother tongue” language a particular developer has mastered. Ironic, since any time you post about a programming language it's to inform that C# does it better. Not just here; someone with your nick also whined when the creator of C# made a technical deficient decision when choosing Go over C# to implement typescript. It's hard for a rational person to believe that someone would make the argument that the creator of the language must have made a mistake just because he reached for (in his words) a more appropriate language in that context. You have a blind spot when it comes to C#. You also probably already know it.