5 ms·

Very excited about this project, since I’ve been looking to wet my feet with Elixir and numerics are the perfect niche for me! Here’s something I’m confused ab

Very excited about this project, since I’ve been looking to wet my feet with Elixir and numerics are the perfect niche for me! Here’s something I’m confused about. For fast numerical code, it’s vey important to be disciplined about memory allocation. So in addition to considering of immutability -vs- mutable pre-allocation, it would seem that the scheduling model ought to be substantially different. Instead of constantly switching between concurrent processes to ensure none of them monopolize the processor, would it make more sense to finish one computation while the contents are in memory/cache, before cleaning it up and swapping to another process? (Especially for really heavy computations). Will process scheduling have to be micromanaged? Is the BEAM compatible with this mode of usage, or is this maybe not a concern?

dmpk2k 6y ago
I do not know what Nx is doing, but BEAM has "dirty NIF"s: long-running native functions that are scheduled differently so that they do not impact regular BEAM processes. They're transparent from the user space.
deleted 6y ago
[deleted]
dnautics 6y ago
If you're interested about the various modes of BEAM concurrency with nifs, I put together this video, but the code it is showcasing does (deliberately) elide over some of the finer details of beam reentrancy: https://youtu.be/l848TOmI6LI https://youtu.be/l848TOmI6LI
rkangel 6y ago
Memory allocation and scheduling are both important considerations but are separate problems. BEAM concurrency only involves memory allocation when the processes are created. Switching between them doesn't involve allocation and is very quick (don't forget we are talking about BEAM processes here not OS ones - it's all in userspace and very efficient). As long as you pre-create your pool of worker processes concurrency doesn't incur much allocation hit. You're right that immutability might do though. I am curious to see how this goes - the speed that Elixir normally runs at combined with some data sharing optimisations means that this issue doesn't exist normally. At the speed we care about when doing numerical work it's more of a concern. Or maybe we'll never get into the realms of full optimised C++ where things are sized for cache lines etc. (and that's ok).

dmpk2k 6y ago

I do not know what Nx is doing, but BEAM has "dirty NIF"s: long-running native functions that are scheduled differently so that they do not impact regular BEAM processes. They're transparent from the user space.

deleted 6y ago

[deleted]

dnautics 6y ago

If you're interested about the various modes of BEAM concurrency with nifs, I put together this video, but the code it is showcasing does (deliberately) elide over some of the finer details of beam reentrancy: https://youtu.be/l848TOmI6LI https://youtu.be/l848TOmI6LI

rkangel 6y ago

Memory allocation and scheduling are both important considerations but are separate problems. BEAM concurrency only involves memory allocation when the processes are created. Switching between them doesn't involve allocation and is very quick (don't forget we are talking about BEAM processes here not OS ones - it's all in userspace and very efficient). As long as you pre-create your pool of worker processes concurrency doesn't incur much allocation hit. You're right that immutability might do though. I am curious to see how this goes - the speed that Elixir normally runs at combined with some data sharing optimisations means that this issue doesn't exist normally. At the speed we care about when doing numerical work it's more of a concern. Or maybe we'll never get into the realms of full optimised C++ where things are sized for cache lines etc. (and that's ok).