Type-Based Optimizations in the JIT

https://www.erlang.org/blog/type-based-optimizations-in-the-jit/

by seanclayton • 4 years ago

137 36 4 years ago

erlang.org

alberth• 4 years ago

Did WhatsApp/FB ever release their static type tool?

All the FB blog posts from 2020 I find are broken links now.

DylanSp• 4 years ago

I'm also curious about this, I haven't heard anything in a while.

di4na2• 4 years ago

Maybe but they don't use it.

Internal politics changed the track they used to something more sustainable. Kinda.

ramchip• 4 years ago

Yes, kinda: https://github.com/WhatsApp/erlt

spinningslate• 4 years ago

The performance work in Erlang at the moment is really exciting. It's easy to get sniffy about it and say the JVM/CLR/whatever has has JITing for years. True. But then performance has never been the Erlang standout: that would be concurrency and robustness.

The JIT is bringing BEAM languages up the rankings on performance. It may have a way to go to get to JVM level, and might not ever get there. But it's on a really encouraging trajectory.

And none of that compromises the concurrency and robustness story, where it still stands at the forefront of production-quality capability with a single, well-designed approach that's well-implemented and impressively scalable.

The care that has gone into Erlang's evolution (including the BEAM VM) is nicely illustrated by this para in the blog:

The embedded type information is versioned so that we can continue to improve the type-based optimizations in every OTP release. The loader will ignore versions it does not recognize so that the module can still be loaded without the type-based optimizations.

I'm not claiming that's unique among VMs (don't know, probably not) but it does nicely illustrate diligence on the part of the core team.

With Elixir adding some sparkle as an alternative BEAM language, it's a great time to be part of the Erlang community. Chapeau to the core team and community.

tiffanyh2• 4 years ago

I don't want this to come across as snarky or unappreciative but note that JIT work on Erlang has been under active develop since at least 2014 (8 years) [0] if not earlier.

The current JIT provides about 25% improvement while other languages like PHP have sen a near 200% improvement during that same timeframe.

I also realize that Erlang is extremely difficult to increase performance of due to the very nature of it vs other languages.

[0] https://llvm.org/devmtg/2014-04/PDFs/Talks/drejhammar.pdf

jlouis3• 4 years ago

PHP is the language which would implement a loop by pushing a byte offset to a stack and seek in the file at the end of the loop. Massive improvement if you had a disk cache.

It's all relative to where you come from. The byte code interpreter of BEAM is very close to a poor man's JIT. It has some op-fusion, and uses threaded code. So gaining efficiency will require lot of work.

kaba03• 4 years ago

Adding to that, wouldn’t adding Erlang’s unique features to the JVM be easier than the other way around? Especially with GraalVM’s unique approach that manages to elevate Ruby’s performance far higher than any other runtime?

derefr4• 4 years ago

but note that JIT work on Erlang has been under active develop since at least 2014

Kind of, but that work (BEAM JIT, HiPE, etc.) was done by third-party academic researchers and then contributed to Erlang, where it languished, because none of the core developers were academic researchers with the knowledge to improve or even really change what had been contributed. HiPE was disabled in Erlang 22 simply because some new instructions were added and nobody knew how to extend HiPE with support for them. You might call this previous work "false starts" at optimization.

The work going on since Erlang 24, however, is being done in-tree by the core maintainers themselves. It will stick around, and be gradually improved upon.

Alongside this work, comes a number of recent features in the last few Erlang releases, all with the specific aim of supporting performance-oriented code — e.g. atomic counters, persistent_term, ETS high-read-concurrency improvements, etc.

Basically, the Erlang devs have seemingly shifted from their previous "enterprise embedded use-case enablement" posture, more toward a "high-performance OLTP use-case enablement" posture.

jjtheblunt• 4 years ago

PHP have <seen> a near 200% improvement

perhaps because PHP's implementation was grotesquely wasteful?

moelf• 4 years ago

every other week there's a post about JIT, LLVM, etc. (either like this or more commonly in Python where people show it improving 5x or whatever)

whenever I see it, it makes me feel like Julia-lang really did a good job picking the approach and technology all the way back in 2010

rad_gruchalski• 4 years ago

First Erlang version was released in 1986, LLVM 2003.

chrisseaton• 4 years ago

I don't think that's quite what they mean - Julia was specifically designed to be compiled. LLVM is a tech it uses, but it could use any compiler backend. It's the design that's amenable to compilation that's the important bit.

https://dl.acm.org/doi/pdf/10.1145/3276490

Type-Based Optimizations in the JIT

Related Stories