3 ms·

We're thinking about adding an abstraction layer over C code that will allow to switch between NIF and port backends. Ports have their limitations so you won't

by mspanc 8y ago

We're thinking about adding an abstraction layer over C code that will allow to switch between NIF and port backends. Ports have their limitations so you won't be able to use them e.g. for passing GPU buffers but they will do the job for many other cases. Anyway even with NIFs we delegate to them only code that cannot be written in Elixir or it really makes no sense to keep it in Elixir e.g. in performance reasons. Even if 30% of the framework will be in C it's way easier to manage 30% of C code than 100% of C code. Moreover, all the hard stuff, such as parallelism, being able to inspect running state of the VM, ability to spread app over cluster, I/O scalability, being multiplatform etc. comes out of the box with BEAM VM. There are many things that are give the point of using Erlang VM even if part of the code is in C and is potentially dangerous.

sidkshatriya 8y ago
Thanks for your reply. The BEAM VM is amazing (and I'm a fan of Elixir) but I'm trying to see what benefit you're getting out of BEAM if you're using NIFs. Because the moment you use NIFs then your VM can crash (without recourse to the various recovery mechanisms of the BEAM) just like, say, a Golang executable. If you used Golang you would also get parallelism, I/O scalablity, multiplaform capability... all the things you list as advantages for BEAM. The only thing that BEAM is giving you "extra" vs, say, Golang is the ability to spread your app over a cluster easily. But again, I'm sure you can achieve that with some sort of a load distributer if you used Golang on multiple machines. Also with Golang it is easy to do CPU intensive tasks because its "closer" to the metal. So I guess what I'm saying is that for your specific use case (that involves a lot of media related CPU intensive work like video/audio processing) I wonder if the BEAM VM will give you that many advantages. With Golang in this case I think you can get the scalability, reliability as your current setup with one big advantage: better performance. But this is just my ~5 min view of the subject...
- elcritch 8y ago
  Not the OP, but it strikes me that at some level it becomes a personal preference alongside the technical benefits. Though regarding error handling and NIFs, Erlang/OTP manages high reliability not just through local OTP mechanisms, but also through the clustering. It’s a fundamental part of the OTP ethos and something that would need to be “bolted on” in Go. That and the introspection tools are pretty great!
- mspanc 8y ago
  Hello, I evaluated Go at the very beginning and after making proof of concept I decided to stay with Elixir. One of the reasons was that Go has garbage collector that can "stop the world" which is really not acceptable in some low-latency applications. BEAM VM does GC per erlang process. Secondly, significant chunk of such framework is about interoperability with C as there're tons of libraries we're going to wrap around. cgo essentially requires developer to reimplement in definition of every single structure and function we're going to ever use. It's a massive overhead (not in sense of computational overhead but time spent). NIFs are way simpler, there just regular C code you can link with libraries without any overhead. Remember that in such framework we're going to do quite o lot of pointer arithmetic and having plain C code is a huge advantage. All that together allows us to have greater flexibility on how to design C layer. cgo binds us to a particular solution that is not really well designed. With Elixir we can even write C code in Rust as was suggested in another comment. Please remind that what is really computationally expensive will be often written in C/C++ anyway or done by GPU. Framework does not add that much overhead in macro scale, it's often just a glue and abstraction layer. And finally, if you read our goals, we clearly state that if we have to make a tradeoff, we put reliability over performance. The motivation to start Membrane was that while designing broadcasting systems we struggled to achieve true 24/7 availability with existing frameworks. You can't compare 20+ years of Erlang development in this area with Go. I mean both maturity of the VM, as well as battle-tested design patterns, built-in supervision, hot upgrades and so on. Go is cool, trendy and has very loyal user base but it's not free of caveats.
  - mspanc 8y ago
    Moreover, while one can say that all of these differences are not that important, there're clear differences in the language: Elixir has metaprogramming, you can easily achieve a lot of stuff in the compile time via macros, go lacks generics and good versioning and interface for plugins most probably would have needed to be written using reflections. Elixir looks just way more modern.
  - sidkshatriya 8y ago
    Thanks again for your detailed response. I was curious to know why you choose BEAM because Golang vs BEAM is often a genuinely confusing option. Thanks for your insights on NIFs. Additionally, as someone in this thread has already pointed out, it is also a matter of taste and preference on choosing Elixir over Golang. A point about Elixir macros -- I think you will find that while macros increase your productivity, they make debugging the code a bit more difficult. Wish your project best of luck. The website looks slick!

by mspanc 8y ago

sidkshatriya 8y ago

Thanks for your reply. The BEAM VM is amazing (and I'm a fan of Elixir) but I'm trying to see what benefit you're getting out of BEAM if you're using NIFs. Because the moment you use NIFs then your VM can crash (without recourse to the various recovery mechanisms of the BEAM) just like, say, a Golang executable. If you used Golang you would also get parallelism, I/O scalablity, multiplaform capability... all the things you list as advantages for BEAM. The only thing that BEAM is giving you "extra" vs, say, Golang is the ability to spread your app over a cluster easily. But again, I'm sure you can achieve that with some sort of a load distributer if you used Golang on multiple machines. Also with Golang it is easy to do CPU intensive tasks because its "closer" to the metal. So I guess what I'm saying is that for your specific use case (that involves a lot of media related CPU intensive work like video/audio processing) I wonder if the BEAM VM will give you that many advantages. With Golang in this case I think you can get the scalability, reliability as your current setup with one big advantage: better performance. But this is just my ~5 min view of the subject...

elcritch 8y ago
Not the OP, but it strikes me that at some level it becomes a personal preference alongside the technical benefits. Though regarding error handling and NIFs, Erlang/OTP manages high reliability not just through local OTP mechanisms, but also through the clustering. It’s a fundamental part of the OTP ethos and something that would need to be “bolted on” in Go. That and the introspection tools are pretty great!
mspanc 8y ago
Hello, I evaluated Go at the very beginning and after making proof of concept I decided to stay with Elixir. One of the reasons was that Go has garbage collector that can "stop the world" which is really not acceptable in some low-latency applications. BEAM VM does GC per erlang process. Secondly, significant chunk of such framework is about interoperability with C as there're tons of libraries we're going to wrap around. cgo essentially requires developer to reimplement in definition of every single structure and function we're going to ever use. It's a massive overhead (not in sense of computational overhead but time spent). NIFs are way simpler, there just regular C code you can link with libraries without any overhead. Remember that in such framework we're going to do quite o lot of pointer arithmetic and having plain C code is a huge advantage. All that together allows us to have greater flexibility on how to design C layer. cgo binds us to a particular solution that is not really well designed. With Elixir we can even write C code in Rust as was suggested in another comment. Please remind that what is really computationally expensive will be often written in C/C++ anyway or done by GPU. Framework does not add that much overhead in macro scale, it's often just a glue and abstraction layer. And finally, if you read our goals, we clearly state that if we have to make a tradeoff, we put reliability over performance. The motivation to start Membrane was that while designing broadcasting systems we struggled to achieve true 24/7 availability with existing frameworks. You can't compare 20+ years of Erlang development in this area with Go. I mean both maturity of the VM, as well as battle-tested design patterns, built-in supervision, hot upgrades and so on. Go is cool, trendy and has very loyal user base but it's not free of caveats.
- mspanc 8y ago
  Moreover, while one can say that all of these differences are not that important, there're clear differences in the language: Elixir has metaprogramming, you can easily achieve a lot of stuff in the compile time via macros, go lacks generics and good versioning and interface for plugins most probably would have needed to be written using reflections. Elixir looks just way more modern.
- sidkshatriya 8y ago
  Thanks again for your detailed response. I was curious to know why you choose BEAM because Golang vs BEAM is often a genuinely confusing option. Thanks for your insights on NIFs. Additionally, as someone in this thread has already pointed out, it is also a matter of taste and preference on choosing Elixir over Golang. A point about Elixir macros -- I think you will find that while macros increase your productivity, they make debugging the code a bit more difficult. Wish your project best of luck. The website looks slick!