Hacker News new | comments | show | ask | jobs | submit login
Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode (github.com)
209 points by ghosthamlet 6 months ago | hide | past | web | favorite | 66 comments


Author is here.

We have no idea how this blog draft escaped into HN, but here it is a few years too late. The Gluon project https://github.com/kvakvs/gluonvm1 isn't live anymore, it was using C++ and it was stopped a couple years ago giving way to other experiments ( https://github.com/kvakvs/E4VM ) and finally to ErlangRT mentioned below https://github.com/kvakvs/ErlangRT

My talk with me explaining the whole thing on EUC 2017 (Stockholm) is here https://youtu.be/6NUPormxgw8?list=PLWbHc_FXPo2jAL3fm0YfN3nFV...

The new ErlangRT project in Rust is much more recent; clean strictly typed code with some 'unsafe'ties and a good PoC progress. But it also was stopped because the amount of work to do in it quickly grows but my free time doesn't grow at all.

This increased interest might actually make me rethink my priorities and look at it again.

It's great to hear interest in this area - the more places I can run Erlang/Elixir, the more likely I am to use it even in the places it can traditionally run (it's a more useful language to me if I can use the same codebase everywhere).

If you are looking to make an embedded focused VM, obviously ARM is the most useful target to run on.

By using C++ and Rust obviously ARM was on my mind, and I have plenty of test boards ranging from 192kb to hundreds MB of RAM to experiment with. It just never reached that stage.

The two main ideas were to be different implementation for large machines (ErlangRT) or to be small (E4VM and gluonvm1).

Is there a platform the BEAM doesn't currently target? I'm not aware of anything that isn't completely esoteric... You can run it on ARM currently.

BEAM has been in use for over 20 years in telephone systems running on insanely old and bizarre hardware. Is there a platform you have in mind besides ARM?

It is memory not CPU that is the main limitation. Under 20MB RAM you are entering a gray zone, where BEAM barely runs. You can keep removing modules from the standard library and optimising it fit into maybe 8MB RAM (as project GRISP did) but smaller than that BEAM VM would not even boot to shell.

I could be wrong, but I don't think BEAM really runs on microcontrollers. Erlang might be a good environment on the same sorts of micros (32 bit, dozens of KB of ram) MicroPython targets.


edit: it's a work in progress, but it's a start. Looks like the author is actively working on it.

If you'd like to update the post instead of removing it altogether we can put the link back, but we've gone with the GitHub repo for now.

The original gluonvm1 project link is fine, as in its description there are links to its successors. Thank you for caring!

were you ever able to feed in size savings back to Ericsson? Especially since OTP got relicensed?

This would mean huge refactoring, which i'm sure they'd never accept. The only way to go was to start something my own or fork. OTP team prefers changes which do not degrade performance, as I'm essentially optimising for size, while they optimise for speed and compatibility.

I'm curious whether you had in mind any kind of benchmarks (which have not been implemented) for checking size and/or performance differences...

For E4VM I engineered it so that my Huffman-compressed BEAM bytecode would be much smaller, at some reasonable performance cost. Something like 1:3..1:6 ratio, probably even better. The emulator code was also planned to be very limited, possibly the language will also become a subset of Erlang, to cut on the features. But there were no numbers, there was no definite goal how small I want it to be. Such talks begin when there is a project or a customer and a target to reach.

For ErlangRT the original idea was to reproduce some subset of existing Erlang/OTP emulator features and then optimize from there. It resembles Erlang/OTP data formats and data structures, so it would begin at 1:1 ratio or maybe a little worse like 1.1:1 or something because Rust incurs some costs for compound types where for C it was enough to have an integer.

Why Erlang in Rust? Ever thought about a no-std Actix clone?

How much std is used in actix? Is no-std a big project/possible refactor?

That would be a very different project. No I didn't think about making a no-std web server. At least I don't know what is the demand there, and who's willing to pay for it.

Didn't know your Erlang stuff was paid work. Lucky you!

Would Elixir be able to support this? If yes, then it could be a huge deal (atleast for me). Imagine writing a POS system's code in Elixir. That'd be very nice, although I understand at this point this is just wishful thinking.

I know of a company who implemented a POS in Elixir in Phoenix running in web kiosk mode. I don’t know any further details and probably couldn’t share them if I did but this scenarios has been done with BEAM.

Wow, that's cool. Would be very interested to keep track of the progress of that..

Seems like this will make it into Nerves fairly quickly.

Actually, in the article it's written, that it's supposed to run elixir amongst others.

Wow, I totally missed it because of the tiny font size. Thanks!

it looks there is also a more recent proof of concept work to implement the Erlang VM in Rust: https://github.com/kvakvs/ErlangRT

Cool subtitle :) lighthearted, and gives good overview of author's position: "Good news: I know what to do. Bad news: I have no clue how to Rust"

"Last commit was over 2 years ago" is a common phrase when it comes to Erlang.

Of course, I'd consider Erlang to be one of the best platforms in terms of stability. It's rare that they double back on old features.

Check out https://github.com/bettio/AtomVM which seems to be a similar project that's actively developed.

Is the art created from the same artist that did art for the book learnyousomeerlang.com?

I'm glad Erlang and Elixir are slowly getting popular and going into other spaces such as hardware apparently.

The technology for the art is called Wacom Bamboo and I was overdrawing the Erlang logo with some hand scribbles in Inkscape. In fact same technology seems to be used for the original LYSE book and I was using it to translate text in images in Russian translation for the LYSE book.

For Learn You Some Erlang, I used hand-made drawings that I would scan, and then trace over using either photoshop (initially) and then Illustrator (when I knew the book would go to print).

Is that de same technique as in learn you a haskell?

no idea, did not write that one.


We barely had FB and Sonar, to just get yet another example of how badly to name projects.


Honestly I have never heard of any of those and so long as they aren't too close in what their intended use is I don't see the issue. Worse case it can just be called GluonVM then you have no ambiguity as to what you're talking about. Naming can be a pain. The worst I've seen so far was the WAMP protocol we saw posted sometime back.

Gluon is also a language built on Rust: https://github.com/gluon-lang/gluon

Which I heard of for the first time only weeks ago and thought this was.

Also part of the name of a fictional weapon: http://combineoverwiki.net/wiki/Gluon_Gun

Gluon is also a freifunk project for mesh networking.


Wouldn't targeting GraalVM make sense, too?

No. Graal is huge, one of the biggest of all VM runtimes.

Gluon had the complete opposite goal. lua would be an idea for a small BEAM engine. It would also be much faster.

Probably not. VMs are not universal. Things designed for shared memory model, like say GCs, make sacrifices that would not do so good for isolated processes. So a custom unoptimized VM might make more sense than an architecturally unfit VM.

Could you elaborate please? Why do you think would it make sense?

It'd be great to see what a state-of-the-art optimising compiler can do for the performance of Erlang and Elixir.

Given the not-all-that-great improvement of a targeted attempt to speed up Erlang with HiPE, I wouldn't hold your breath for how well a non-targeted approach would go. Unfortunately, Erlang-the-language has several features that seem to be fundamentally slow, in that I've never seen any runtime that goes quickly with them. (A lot of memory copying, for one, even after being as clever as possible with optimizations on that front.)

(I no longer believe in the line that there are no slow languages. In practice, there seem to be, and languages in practice seem to plateau at certain performance levels no matter how much effort is put into them. Those who wish to argue are welcome to produce the fast-as-C-at-everything Javascript interpreter or some similar artifact and I will happily retract.)

Erlang is still a fine language and it's performance is well in line with several other popular languages; by no means would I say it is unusable. It's just that real engineers need to have clear understandings of the costs and benefits of their tools, which includes understanding not all languages have the same speed characteristics.

HiPE was done a long time ago, and I don't think it tried to use any particularly sophisticated techniques even at the time.

Modern compilation techniques such as powerful escape analysis and partial evaluation may be able to do something new. GraalVM runs Ruby about 10x faster than standard Ruby, for example.

"GraalVM runs Ruby about 10x faster than standard Ruby, for example."

Which puts it roughly up against the plateau I observe for dynamically-typed languages across the board, except LuaJIT (which AIUI compromises the dynamicness a bit to get there). Ruby is a great deal more than 10x slower than optimal (which is still roughly C, though keep an eye out on that as languages continue to challenge it).

Based on the way Erlang works, I wouldn't expect it to get much past two times faster than it already is no matter how much money is poured into it.

I remember hearing the line about how there are no slow languages, only slow implementations, back in the early 2000s, when we didn't have any implementations of dynamic scripting languages that had really had a lot of effort poured into them, by modern standards. In 2018, we have numerous such implementations with vast, vast amounts of work poured into them. They are faster than they used to be... and they are still meaningfully slower than optimal. (And eat about 10-20x times the RAM in the process.) Erlang doesn't do all the bad things that Python or Ruby do to make them slow, but it does add a lot of memory copying that Python and Ruby don't do, and which is probably not as reducible as you'd like no matter how you optimized it (the low-hanging fruit, after all, is already in current Erlang).

To be honest, if you like Erlang but you need the next step up in performance and are willing to lose a few guarantees to get there (a very common tradeoff in optimization, after all), the answer is Go, not waiting for a much faster Erlang. Go is significantly faster than Erlang, Go does not have Erlang's memory isolation, and these statements are deeply connected together, not just coincidence.

What about Common Lisp using SBLC? That's dynamically typed and amazingly fast.

LuaJIT is simply a very good optimizing JIT compiler. It's just as dynamic as Lua.

BEAM is a register-based bytecode VM, which is dramatically slower than native code. The fast JS implementations either don't bother with a bytecode VM (V8) or baseline compile to native after only a few iterations (WebKit) because bytecode VMs simply can't compete with a chunk of native code.

2018 MRI Ruby is ~14x faster than 2006 Ruby depending on how you measure. Neither Python nor Ruby have seen anywhere near the resources put into JS engines over the past 10 years.

Oracle dumped a ton of money into making the JVM support dynamic languages and now Graal is bringing full Java performance to both Ruby and Python.

It's not really inherent language design flaws that make it difficult to optimize Ruby and Python (they don't do anything "bad") but the community dependence on compatability, particular with C extensions. PyPy does a ton of crazy stuff to maintain compatability that then hurts performance, like faking reference counts etc.


Was `jerf` opining about "dynamically-typed languages" or just about "dynamic scripting languages"? It matters.

>> inherent language design flaws

Not "design flaws" but design goals -- Scripting languages are designed for gluing.

None of them had the research money that JavaScript has enjoyed though.

Also lets not forget C was quite slow in 8 and 16 bit systems, and it only became as fast thanks to the joy of UB and -O3.

>> … no slow languages, only slow implementations … dynamic scripting languages…

"Scripting languages are designed for gluing."


"Programming languages are compared against each other as though their designers intended them to be used for the exact same purpose - that just isn't so."


>> It's just that real engineers need to have clear understandings of the costs and benefits of their tools…

For example, real engineers read the FAQ.


1.4 What sort of problems is Erlang not particularly suitable for?

"Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."

While it would be nice this companys focus seems to be towards Erlang specifically so they may have their reasons not to have gone that route. Would be nice to hear what those reasons are for sure.

Dead link

Ot: please lessen the “DRAFT” stamp. It makes it very hard to read

This is outdated article draft which wasn't published a few years ago when it was fresh, and now it is outdated. It accidentally escaped and now is automatically posted on HN.

Agree, and another meta-comment would be to move to "MB" or "MiB", instead of using "Mb" to mean "mega byte", which is very confusing.

Use Firefox’s reading mode... solves issues like that easily. :-)

I just right click -> Adblock -> remove element

Mobile user here… It's even worse (I imagine), and unfixable from mobile Safari.

uBlock origin has a "zap" feature for this that I just discovered the other day.


Ooops It looks like that page you tried to explore went extinct, or you typed in the wrong address. Check the URL again or go back to our home page

I asked to unpublish it. Please read my top comment.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact