tokenrove

It's been a little while since I looked at it, but I recall that much less state had to be saved in an Erlang process switch in the usual case; I seem to recall it can be done in a handful of instructions in many cases. Go of course has to save a bunch of registers much as you'd have to do in any native context switch.

Edited to add: it can be useful to look at that part of the BEAM disassembled in objdump or gdb, to appreciate it, since it's hard to tell how much work is happening with all those macros.

Comment · 6 years ago

I've worked a bunch in both, and Go really doesn't compare; you can't judge based on watching a talk. I find it much, much easier to write safe, robust code in Erlang, and operationally, you have so much more power to inspect the state of the BEAM. Another key BEAM thing is the process heap, which amounts to region allocation when used carefully. The reduction mechanism used for scheduling processes, though crude, is also still much lighter-weight than Go's approach.

On the other hand, Erlang is a weird language and a weird environment, that takes a lot of time to really understand, so I understand why it's never going to "win", and golang tools and the runtime will continue to improve. YMMV.

Comment · 6 years ago

No, it was the need for this on Windows that made Citrix all its money.

Comment · 7 years ago

Hobbyists move first. Speaking of nostalgia, I'm sure you remember when people would mention they were moving to Linux and were laughed at — Windows, Solaris, AIX, HP-UX, and so on were the serious server OSes.

Comment · 7 years ago

I think your statement goes too far. In my experience, it's very difficult to do lightweight threading on the JVM anywhere near the performance of the BEAM, as well as region allocation in the style used by high-performance Erlang programs. I think a comparison is unfair. The BEAM definitely sucks for compute-oriented tasks, but it's an immense amount of work to make a JVM-based program compete in the areas where it's good.

Comment · 7 years ago

https://www.sqlite.org/malloc.html is a welcome contrast to the typical behavior you're describing, but I agree that such measures are rare. (and, not an application: though it provides the mechanisms for applications to follow its lead.)

Comment · 7 years ago

Our team is developing brand new hardware to do high-performance neural network and deep learning inference. We're remote-first, senior people trying to raise the bar on high-performance and low-energy AI hardware.

We have interesting problems in the domains of optimizing compilers, graph algorithms, computer architecture, and machine learning. Candidates with experience working with performance-sensitive systems preferred.

Comment · 7 years ago

Please reach out directly at [email protected].

Comment · 7 years ago

Comment · 7 years ago

Reading code is essential to growth as a programmer. I do it all the time, often for pleasure. But reading snippets without context, like you're suggesting, is a common source of bugs in my experience.

So often when working on a legacy codebase, I'll track down a bug to some bit of code that makes no sense, and then search for that code and find it on Stack Overflow or similar. Even examples from documentation can be dangerous taken out of context; I can think of numerous times I encountered this with snippets that had been copied directly from MSDN without understanding.

Given that poorly-understood code reuse was implicated in many of our industry's greatest disasters, maybe the legality isn't what our concern should be here.

Comment · 8 years ago

Yep, seems to be pitch class notation with T and E replaced with a and b. People interested in this kind of orthogonality should definitely check out Introduction to Post Tonal Theory by Joseph Straus. Even outside of the serial contexts people traditionally associate with that notation, there are interesting things that can be done with it.

Comment · 8 years ago

Note that the claims in that abstract were retracted because the authors messed up when benchmarking. Note the changed title and abstract here: https://cseweb.ucsd.edu/~lerner/papers/fp-printing-popl16.pd...

Comment · 9 years ago

Yeah, I should have finished this article when it was still fresh. Hardware always seems to catch up with codegen from the '70s.

(Thanks for the excellent paper reference.)