|
|
|
|
|
|
by pheo
3815 days ago
|
|
|
Woah. I think that many "servers" today aren't going to benefit though from the level of optimization that you're talking about. Network bandwidth is at least an order of magnitude slower than memory and PCI throughput. For all but the most heavyweight computational tasks (ie. gaming, finance, scientific computing, etc.) this kind of multiplexing optimization is very helpful. If you're needing to get that kind of performance, you would userspace map off the NIC. With how fast modern processors (CPUs and GPUs) are, whats much more important nowadays is not stalling on the flow from the NIC. The solution of the original author seems to me like a very simple fix for the old naive paradigm of state machine switching off from a single thread. I think you might be (impressively) too close to the metal, and guilty of premature optimization. For example, a simple database application would benefit much more from keeping the slow I/O bottlenecks flowing than from the compute multiplexing. |
|
|
The real goal here, in my mind, was to allow people in those particular high-performance domains (gaming especially, though the other ones would probably benefit too) to code at a higher abstraction level.
In my ideal world, a physics engine, for example, would be implemented in code as actors sending messages—with one actor for each physical (e.g. collide-able) object. Not only is that really expensive; the naive approach wouldn't even work! (You need "tick" events spammed to every physics-actor once per frame, which is just absolutely ridiculous.) But then the compiler transparently takes that and spits out something that isn't actor-modelled at all, but rather is a modern-day physics engine doing GPGPU SIMD to arrays of quaternions.
Or, in short: I want to code games in Elixir, without an impedance mismatch in the places where one of my actors' components turns out to need groupwise synchronous shared-memory evaluation rather than piecewise asynchronous reduction-scheduled evaluation. (That sounds like something that should be followed up with "and a pony!", but—given that the Erlang BEAM VM already has the infrastructure of "dirty" schedulers for CPU-bound tasks, and an LLVM IR step in its JIT which could be shunted over to a PTX-ISA target—this actually shouldn't even be that hard an extension to make.)