[HN Gopher] Type-Based Optimizations in the JIT
___________________________________________________________________
Type-Based Optimizations in the JIT
Author : seanclayton
Score : 69 points
Date : 2022-04-26 16:16 UTC (6 hours ago)
(HTM) web link (www.erlang.org)
(TXT) w3m dump (www.erlang.org)
| spinningslate wrote:
| 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.
| tiffanyh wrote:
| 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
| jlouis wrote:
| 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.
| nickjj wrote:
| Is the BEAM's byte code interpreter comparable to something
| like opcache with PHP?
|
| [0]: https://www.php.net/manual/en/intro.opcache.php
| kaba0 wrote:
| 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?
| alberth wrote:
| Did WhatsApp/FB ever release their static type tool?
|
| All the FB blog posts from 2020 I find are broken links now.
| moelf wrote:
| 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
___________________________________________________________________
(page generated 2022-04-26 23:00 UTC)