News for hackers. Stuff that matters.
Re:Gluon – A configurable and small virtual machine which ru... by kvakvs on Tuesday June 12, 2018 @10:16AM (#17293423)
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.
Re:Gluon – A configurable and small virtual machine which ru... by sa2ajj on Tuesday June 12, 2018 @02:49PM (#17296595)
I'm curious whether you had in mind any kind of benchmarks (which have not been implemented) for checking size and/or performance differences...
Re:Gluon – A configurable and small virtual machine which ru... by kvakvs on Tuesday June 12, 2018 @05:34PM (#17298247)
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.