5 ms·

I think you are misunderstanding me, so let me ask a simple question: Is it (except for performance) always 100% equivalent whether a calculation is done "loca

I think you are misunderstanding me, so let me ask a simple question: Is it (except for performance) always 100% equivalent whether a calculation is done "locally" or whether it is ran on some other, potentially just spawned, thread and then retrieved from this thread? If your answer is "no it is not always 100% equivalent" then we agree (and I think we do).

SirGiggles 4y ago
No, they're equivalent. It makes no difference whether I calculate in the current process, spawned a process, started a process via the Supervisor, Task.async, or what not. They are all equivalent in the sense that they use BEAM processes. An Elixir, Erlang, or any other developer using the BEAM VM (or at the very least myself since I don't want to generalize) doesn't make a semantic distinction between spawn and Task.async/3 because there is none. The significant differentiation is whether or not the caller is expecting a returned value, if not then Task.start_link can be used instead. I don't need to worry about function colouring because there is none. I also don't need to worry about async vs Task.run like in C# because in Elixir there is none. To be asynchronous in Elixir/Erlang/etc... is to be synchronous. To equate it to modern backends, we basically have a microservice but every service can directly call each other. I think I also might have been talking around you a bit, the BEAM VM sets itself apart from C#'s async/await or the TPL due to its implementation of the actor model. This video by Sasa Juric can explain better than I can the general overview of the BEAM: [1]. But a rough tl;dw, a BEAM process is to the BEAM, what an OS process is to the OS. We don't define a main function as the process supervisor in BEAM spawns processes we define instead and those are our "entrypoints." [1] https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE
- valenterry 4y ago
  > They are all equivalent in the sense that they use BEAM processes. Sure, but that was not my question. 100% equivalent means that there cannot be any observable change in the behaviour of the whole program/application (except for performance). Or in other words: is the sole purpose of the existance of `Thread.async` (or spawn, pick whichever you want) to change performance characteristics? If not, what is the purpose of its existence then?
  - SirGiggles 4y ago
    > Sure, but that was not my question. 100% equivalent means that there cannot be any observable change in the behaviour of the whole program/application (except for performance). In a vacuum (i.e. via spawn/1 or spawn/3) there is no observable change in behaviour throughout the whole system. If they're linked via spawn_link then a child process crashing means the parent process dies with it unless handled in some way. So ultimately, no there isn't observable changes. My logging process doesn't care or even know that my WebSocket process crashed. > Or in other words: is the sole purpose of the existance of `Thread.async` (or spawn, pick whichever you want) to change performance characteristics? If not, what is the purpose of its existence then? As stated before Task.async/3 is just a convenience wrapper around low-level BEAM primitives, there isn't anything special about Task.async/3 that you couldn't do via spawn. The reason being that the BEAM VM schedulers prioritizes overall latency of the system over throughput by enforcing reduction calls (parlance for a function call, but specifically for tracking looping in the BEAM) at around 4000 calls, then it moves the current process back into the queue; repeat ad infinitum. So you don't get massive speedups just spawning a new BEAM process but your independent units of execution still enjoy the same overall latency as before. If you want performance increases in the BEAM you would need to jump to dirty schedulers and NIFs which carry their own dangers.
    - valenterry 4y ago
      > In a vacuum (i.e. via spawn/1 or spawn/3) there is no observable change in behaviour throughout the whole system. Okay, let me follow up on this one. So could we take arbitrary Erlang/Elixir programs and automatically/mechanically rewrite them to push previously inlined calculations to be run on a different process (using spawn) or the otherway around - and that without causing any observable difference in behaviour in any situation except for difference in performance? > As stated before Task.async/3 is just a convenience wrapper around low-level BEAM primitives, there isn't anything special about Task.async/3 that you couldn't do via spawn. You can likewise answer my question for the BEAM primitives (like processes/threads): is the sole purpose of the existance of those primitives to change performance characteristics? If not, what is the purpose of its existence then? Also, just so that we understand each other: I'm a big fan of the BEAM. This is not a criticism or anything; I just want to explain why I believe that function coloring (or however you call it) can never be conceptionally be removed from a language if sync/async is to be supported.
- throwawaymaths 4y ago
  They are not equivalent. Running a function in another process incurs the overhead of copying the data to the other process (potentially over the network). In both directions. Task.async introduces extra necessities like a linkage between the two processes, a timeout receiver, etc, and the result receiver. Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core. The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code.
  - SirGiggles 4y ago
    > They are not equivalent. Running a function in another process incurs the overhead of copying the data to the other process (potentially over the network). In both directions. > Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core. Yes I agree, but the question as presented by valenterry asks us whether or not there is some existing semantic difference and not under the confines of performance (both gains or losses). Regardless what you have stated are all true. But as an aside, and not directed towards you, Task.async/3 doesn't do anything that the developer cannot already do. Even in the tutorial for the learning Elixir, the fledgling developer is exposed to the different mechanisms that power Task.async/3, the source code [1] reflects this, although supervisors are covered much later down the line. The documentation for > The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code. And just to add on for those not familiar with the BIFs, receive, which is what Task.await/2 and Task.yield/2 use under the hood, yields execution. NIFs are another one. [1] https://github.com/elixir-lang/elixir/blob/fb729784e5504f499b0179c4f154e73ea2a6f216/lib/elixir/lib/task.ex#L437 https://github.com/elixir-lang/elixir/blob/fb729784e5504f499...

SirGiggles 4y ago

No, they're equivalent. It makes no difference whether I calculate in the current process, spawned a process, started a process via the Supervisor, Task.async, or what not. They are all equivalent in the sense that they use BEAM processes. An Elixir, Erlang, or any other developer using the BEAM VM (or at the very least myself since I don't want to generalize) doesn't make a semantic distinction between spawn and Task.async/3 because there is none. The significant differentiation is whether or not the caller is expecting a returned value, if not then Task.start_link can be used instead. I don't need to worry about function colouring because there is none. I also don't need to worry about async vs Task.run like in C# because in Elixir there is none. To be asynchronous in Elixir/Erlang/etc... is to be synchronous. To equate it to modern backends, we basically have a microservice but every service can directly call each other. I think I also might have been talking around you a bit, the BEAM VM sets itself apart from C#'s async/await or the TPL due to its implementation of the actor model. This video by Sasa Juric can explain better than I can the general overview of the BEAM: [1]. But a rough tl;dw, a BEAM process is to the BEAM, what an OS process is to the OS. We don't define a main function as the process supervisor in BEAM spawns processes we define instead and those are our "entrypoints." [1] https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE

valenterry 4y ago
> They are all equivalent in the sense that they use BEAM processes. Sure, but that was not my question. 100% equivalent means that there cannot be any observable change in the behaviour of the whole program/application (except for performance). Or in other words: is the sole purpose of the existance of `Thread.async` (or spawn, pick whichever you want) to change performance characteristics? If not, what is the purpose of its existence then?
- SirGiggles 4y ago
  > Sure, but that was not my question. 100% equivalent means that there cannot be any observable change in the behaviour of the whole program/application (except for performance). In a vacuum (i.e. via spawn/1 or spawn/3) there is no observable change in behaviour throughout the whole system. If they're linked via spawn_link then a child process crashing means the parent process dies with it unless handled in some way. So ultimately, no there isn't observable changes. My logging process doesn't care or even know that my WebSocket process crashed. > Or in other words: is the sole purpose of the existance of `Thread.async` (or spawn, pick whichever you want) to change performance characteristics? If not, what is the purpose of its existence then? As stated before Task.async/3 is just a convenience wrapper around low-level BEAM primitives, there isn't anything special about Task.async/3 that you couldn't do via spawn. The reason being that the BEAM VM schedulers prioritizes overall latency of the system over throughput by enforcing reduction calls (parlance for a function call, but specifically for tracking looping in the BEAM) at around 4000 calls, then it moves the current process back into the queue; repeat ad infinitum. So you don't get massive speedups just spawning a new BEAM process but your independent units of execution still enjoy the same overall latency as before. If you want performance increases in the BEAM you would need to jump to dirty schedulers and NIFs which carry their own dangers.
  - valenterry 4y ago
    > In a vacuum (i.e. via spawn/1 or spawn/3) there is no observable change in behaviour throughout the whole system. Okay, let me follow up on this one. So could we take arbitrary Erlang/Elixir programs and automatically/mechanically rewrite them to push previously inlined calculations to be run on a different process (using spawn) or the otherway around - and that without causing any observable difference in behaviour in any situation except for difference in performance? > As stated before Task.async/3 is just a convenience wrapper around low-level BEAM primitives, there isn't anything special about Task.async/3 that you couldn't do via spawn. You can likewise answer my question for the BEAM primitives (like processes/threads): is the sole purpose of the existance of those primitives to change performance characteristics? If not, what is the purpose of its existence then? Also, just so that we understand each other: I'm a big fan of the BEAM. This is not a criticism or anything; I just want to explain why I believe that function coloring (or however you call it) can never be conceptionally be removed from a language if sync/async is to be supported.
throwawaymaths 4y ago
They are not equivalent. Running a function in another process incurs the overhead of copying the data to the other process (potentially over the network). In both directions. Task.async introduces extra necessities like a linkage between the two processes, a timeout receiver, etc, and the result receiver. Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core. The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code.
- SirGiggles 4y ago
  > They are not equivalent. Running a function in another process incurs the overhead of copying the data to the other process (potentially over the network). In both directions. > Moreover, there is a context switch and it's more likely the code will run on a different core if you run it async than if you run it in the same process (which is very likely but not guaranteed) to run on the same core. Yes I agree, but the question as presented by valenterry asks us whether or not there is some existing semantic difference and not under the confines of performance (both gains or losses). Regardless what you have stated are all true. But as an aside, and not directed towards you, Task.async/3 doesn't do anything that the developer cannot already do. Even in the tutorial for the learning Elixir, the fledgling developer is exposed to the different mechanisms that power Task.async/3, the source code [1] reflects this, although supervisors are covered much later down the line. The documentation for > The way in which they are equivalent, is that the code that you write is identical, and the bytecode that gets run, and the existence of implicit yields is identical between the async and "sync" code. And just to add on for those not familiar with the BIFs, receive, which is what Task.await/2 and Task.yield/2 use under the hood, yields execution. NIFs are another one. [1] https://github.com/elixir-lang/elixir/blob/fb729784e5504f499b0179c4f154e73ea2a6f216/lib/elixir/lib/task.ex#L437 https://github.com/elixir-lang/elixir/blob/fb729784e5504f499...