5 ms·

As someone who's the exact target audience of this post (deploying Elixir apps in production), I have no idea what this PR piece is trying to say. > Unlike BEA

by derefr 4y ago

As someone who's the exact target audience of this post (deploying Elixir apps in production), I have no idea what this PR piece is trying to say. > Unlike BEAM it compiles applications ahead of time, allowing Lumen to perform optimizations BEAM can’t. What does this mean? Erlang/Elixir are AOT-compiled languages. They're compiled into bytecode. (Also, "BEAM" is not a compiler, but a bytecode VM which executes the bytecode emitted by the compiler.) Do they mean that they further compile the BEAM bytecode to native host-ISA object code? Or did they write alternative Erlang and Elixir compilers, to compile these HLLs directly to host-ISA object code, skipping both the language runtime and BEAM bytecode entirely? Do they mean "compiles applications" literally, in the sense of Whole-Program Optimization? In short — is this something like GraalVM's Native Images; or something like an AOT version of BEAM's HiPE extension; or something else? > FireFly is able to compile Elixir applications without having to run through the Erlang Virtual Machine. So is the key benefit here that the compilation is faster because it's not running on the BEAM (good for e.g. CI); or is the key benefit that the resulting executable is faster because it's not running on the BEAM? Also, there are some questions I have that this post didn't even try to answer. E.g.: It is my understanding that the the bytecode-ness of the Erlang VM is crucial to the lightweight bounded-runtime cooperative-scheduling mechanism that allows Erlang/Elixir code to be high-concurrency + soft-realtime. (Effectively, every ISA op implicitly decrements a per-actor reduction-counter as part of its implementation; and the yield-point checks are also inside the impls for certain BEAM ISA ops, rather than being their own explicit BEAM ISA instructions.) How does a non-bytecode version of Erlang/Elixir abstract-machine semantics, achieve these same guarantees? Is there an explicit reduction-counter being carried around in the emitted native code? And also, there is no mention of disadvantages/constraints of using this system. It's pretty clear that you wouldn't be able to do hot reloading or dynamic trace-point insertion without the BEAM there to intermediate it. That's fine for some use-cases, but they should explicitly mention the trade-offs and target audience.

e3bc54b2 4y ago
Indeed all the DockYard pieces announced are nice, but the posts are puff pieces at best. From what I understood, Elixir/OTP are there, but instead of compiling to BEAM bytecode, they compile for WASI (targeting whatever can run WebAssembly). It is not HiPE, nor JIT, there will not be any bytecode. Only AOT compiled native code, except targeting WASI. Generally BEAM is understood to be slower of the big runtimes (compared against Java, CLR, Go and often V8/Javascript). FireFly claims to be faster, and smaller in compiled form than current interation compiled against BEAM. How that plays with actor model and preemptively switched lightweight processes is a mystery to me too. I'd really appreciate something with more technical sauce but human explanation. Currently all we have is PR puffs like this and source code (at least for the LiveView native, haven't tried looking for this). All that said, this does indicate there is good activity and desires to get Elixir working on stuff other than its current strong suit. This usually means the language and ecosystem is growing. It could be Baader-Meinhof phenomenon, but I started learning Elixir couple of weeks ago, starting with LiveView tomorrow, and there is nice stream of posts coming for it. Exciting times :)
- freedomben 4y ago
  Agreed, these posts from Dockyard have been really low quality. Dockyard makes some awesome stuff generally, so I'm surprised at how shallow and marketing-speak these have been. That said I'm really excited for this and the other projects. Looking forward to some more technical dives.
  - hosh 4y ago
    They make up for it in their ElixirConf keynotes and presentations.
    - e3bc54b2 4y ago
      I'd love to watch it, but the recordings are not available yet and 250$ virtual.attendance was way too much for personal interest language.
      - hosh 4y ago
        They are published free after the conference. The 2019 keynote with substantial technical information on Lumen is available for free on youtube.
  - bitwalker 4y ago
    Speaking as the lead on the project, this is partially due to this weekend being ElixirConf, so things are hectic, but you can also blame me, as I probably should have written this post, but didn’t make the time as I was pretty heads down on the lead up to the conference. I’ll make sure to do a follow up post in the near future that is more in depth
    - nunb 4y ago
      Thank you for all the follow up posts on this thread... It strikes me they're probably taking up as much, if not more, time just in the clarifications!
- 4y ago
freedomben 4y ago
While I'd be fascinated to hear the answers to all your questions, I would guess maybe 2% of people would even understand them. I wouldn't expect a post like this to get anywhere near that technical.
bitwalker 4y ago
> What does this mean? Erlang/Elixir are AOT-compiled languages.. With the BEAM compiler today (and by BEAM compiler, they are referring to the compiler provided as part of the standard library shipped with the BEAM, it is just a way to clarify which Erlang compiler is referred to), Erlang sources are partially AOT-compiled to BEAM bytecode, then the code loader does additional compilation steps at runtime. Firefly AOT compiles Erlang to native code directly, and does not use a virtual machine at runtime. > So is the key benefit here that the compilation is faster because it's not running on the BEAM (good for e.g. CI); or is the key benefit that the resulting executable is faster because it's not running on the BEAM? There are a few benefits we hope to provide using this approach: 1. Compilation can be faster because the compiler is implemented in Rust, rather than implemented in Erlang and running on the BEAM. 2. We impose a restriction that hot code loading is not permitted, so we are able to do forms of optimization that the BEAM cannot do, as a result of having to pessimize in the presence of hot code loading. 3. Related to above, we can do whole program analysis, including optimizations that take advantage of unboxing terms and working with more machine-friendly types. 4. We can produce a single statically-linked executable that is as small as possible, in part due to being able to do more aggressive and precise dead-code elimination across both the application being compiled and the runtime it links to, because we know what must be available at runtime. On the other hand, if one were to ship the BEAM itself to run in browsers via Wasm (if it was modified in such a way as to be possible), you'd also need to ship large amounts of bytecode for most applications, regardless of whether much of that bytecode is actually needed at runtime. Deployment has always been a pain point of the BEAM (and I'm speaking as someone who built the primary release tools for the Elixir ecosystem), Firefly aims to make deployment as simple as Go/Rust/etc. 5. I'd like to be able to take advantage of the fact that we use MLIR behind the scenes to explore using Firefly as a natural pairing with Elixir applications using Nx, by being able to more seamlessly integrate regular Elixir code with Nx-managed functions. > How does a non-bytecode version of Erlang/Elixir abstract-machine semantics, achieve these same guarantees? Is there an explicit reduction-counter being carried around in the emitted native code? In short, yes, we implement preemptive-scheduling the same way the BEAM does, using compiler-injected yield points based on a few criteria (a reduction counter is just one, some others are garbage collection and blocking I/O). > And also, there is no mention of disadvantages/constraints of using this system. It's pretty clear that you wouldn't be able to do hot reloading or dynamic trace-point insertion without the BEAM there to intermediate it. That's fine for some use-cases, but they should explicitly mention the trade-offs and target audience. The readme of the project certainly does this, but I agree it would have been good to include in the blog post. In any case, Firefly is still in early stages, so this isn't something anyone is using today. When we reach the point where we feel it is production ready, I can assure you I will be writing up a very detailed analysis of what it is ideally suited for, and what it is not - like you, I feel it is critically important to be clear about that.

by derefr 4y ago

e3bc54b2 4y ago

Indeed all the DockYard pieces announced are nice, but the posts are puff pieces at best. From what I understood, Elixir/OTP are there, but instead of compiling to BEAM bytecode, they compile for WASI (targeting whatever can run WebAssembly). It is not HiPE, nor JIT, there will not be any bytecode. Only AOT compiled native code, except targeting WASI. Generally BEAM is understood to be slower of the big runtimes (compared against Java, CLR, Go and often V8/Javascript). FireFly claims to be faster, and smaller in compiled form than current interation compiled against BEAM. How that plays with actor model and preemptively switched lightweight processes is a mystery to me too. I'd really appreciate something with more technical sauce but human explanation. Currently all we have is PR puffs like this and source code (at least for the LiveView native, haven't tried looking for this). All that said, this does indicate there is good activity and desires to get Elixir working on stuff other than its current strong suit. This usually means the language and ecosystem is growing. It could be Baader-Meinhof phenomenon, but I started learning Elixir couple of weeks ago, starting with LiveView tomorrow, and there is nice stream of posts coming for it. Exciting times :)

freedomben 4y ago
Agreed, these posts from Dockyard have been really low quality. Dockyard makes some awesome stuff generally, so I'm surprised at how shallow and marketing-speak these have been. That said I'm really excited for this and the other projects. Looking forward to some more technical dives.
- hosh 4y ago
  They make up for it in their ElixirConf keynotes and presentations.
  - e3bc54b2 4y ago
    I'd love to watch it, but the recordings are not available yet and 250$ virtual.attendance was way too much for personal interest language.
    - hosh 4y ago
      They are published free after the conference. The 2019 keynote with substantial technical information on Lumen is available for free on youtube.
- bitwalker 4y ago
  Speaking as the lead on the project, this is partially due to this weekend being ElixirConf, so things are hectic, but you can also blame me, as I probably should have written this post, but didn’t make the time as I was pretty heads down on the lead up to the conference. I’ll make sure to do a follow up post in the near future that is more in depth
  - nunb 4y ago
    Thank you for all the follow up posts on this thread... It strikes me they're probably taking up as much, if not more, time just in the clarifications!
4y ago

freedomben 4y ago

While I'd be fascinated to hear the answers to all your questions, I would guess maybe 2% of people would even understand them. I wouldn't expect a post like this to get anywhere near that technical.

bitwalker 4y ago

> What does this mean? Erlang/Elixir are AOT-compiled languages.. With the BEAM compiler today (and by BEAM compiler, they are referring to the compiler provided as part of the standard library shipped with the BEAM, it is just a way to clarify which Erlang compiler is referred to), Erlang sources are partially AOT-compiled to BEAM bytecode, then the code loader does additional compilation steps at runtime. Firefly AOT compiles Erlang to native code directly, and does not use a virtual machine at runtime. > So is the key benefit here that the compilation is faster because it's not running on the BEAM (good for e.g. CI); or is the key benefit that the resulting executable is faster because it's not running on the BEAM? There are a few benefits we hope to provide using this approach: 1. Compilation can be faster because the compiler is implemented in Rust, rather than implemented in Erlang and running on the BEAM. 2. We impose a restriction that hot code loading is not permitted, so we are able to do forms of optimization that the BEAM cannot do, as a result of having to pessimize in the presence of hot code loading. 3. Related to above, we can do whole program analysis, including optimizations that take advantage of unboxing terms and working with more machine-friendly types. 4. We can produce a single statically-linked executable that is as small as possible, in part due to being able to do more aggressive and precise dead-code elimination across both the application being compiled and the runtime it links to, because we know what must be available at runtime. On the other hand, if one were to ship the BEAM itself to run in browsers via Wasm (if it was modified in such a way as to be possible), you'd also need to ship large amounts of bytecode for most applications, regardless of whether much of that bytecode is actually needed at runtime. Deployment has always been a pain point of the BEAM (and I'm speaking as someone who built the primary release tools for the Elixir ecosystem), Firefly aims to make deployment as simple as Go/Rust/etc. 5. I'd like to be able to take advantage of the fact that we use MLIR behind the scenes to explore using Firefly as a natural pairing with Elixir applications using Nx, by being able to more seamlessly integrate regular Elixir code with Nx-managed functions. > How does a non-bytecode version of Erlang/Elixir abstract-machine semantics, achieve these same guarantees? Is there an explicit reduction-counter being carried around in the emitted native code? In short, yes, we implement preemptive-scheduling the same way the BEAM does, using compiler-injected yield points based on a few criteria (a reduction counter is just one, some others are garbage collection and blocking I/O). > And also, there is no mention of disadvantages/constraints of using this system. It's pretty clear that you wouldn't be able to do hot reloading or dynamic trace-point insertion without the BEAM there to intermediate it. That's fine for some use-cases, but they should explicitly mention the trade-offs and target audience. The readme of the project certainly does this, but I agree it would have been good to include in the blog post. In any case, Firefly is still in early stages, so this isn't something anyone is using today. When we reach the point where we feel it is production ready, I can assure you I will be writing up a very detailed analysis of what it is ideally suited for, and what it is not - like you, I feel it is critically important to be clear about that.