Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

github.com

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#61

Post by igouy »

igouy wrote: post #52
jerf wrote: post #27

Earlier quoted context omitted.

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…

>> 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. http://erlang.org/faq/introduction.html#idp32118672

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."

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#62

Post by kvakvs »

MrBuddyCasino wrote: post #60
kvakvs wrote: post #26

Greetings! 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 wh…

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

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#63

Post by kvakvs »

sa2ajj wrote: post #58
kvakvs wrote: post #44

Earlier quoted context omitted.

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#64

Post by kvakvs »

rubyn00bie wrote: post #54
rkangel wrote: post #33

Earlier quoted context omitted.

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.

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#65

Post by marci »

baobrien wrote: post #59
rubyn00bie wrote: post #54

Earlier quoted context omitted.

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?

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.

https://github.com/bettio/AtomVM

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

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#66

Post by jashmatthews »

jerf wrote: post #41
chrisseaton wrote: post #30

Earlier quoted context omitted.

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…

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#67

Post by mononcqc »

rs86 wrote: post #55
mononcqc wrote: post #48

Earlier quoted context omitted.

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#68

Post by igouy »

jashmatthews wrote: post #66
jerf wrote: post #41

Earlier quoted context omitted.

"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…

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…

>> SBCL

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.

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#69

Post by MrBuddyCasino »

kvakvs wrote: post #62
MrBuddyCasino wrote: post #60

Earlier quoted context omitted.

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

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!

Re: Gluon – A configurable and small virtual machine which runs Erlang BEAM bytecode

#70

Post by hayd »

MrBuddyCasino wrote: post #60
kvakvs wrote: post #26

Greetings! 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 wh…

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?
Post reply on HN