[HN Gopher] Static Basic Block Versioning
___________________________________________________________________
Static Basic Block Versioning
Author : matt_d
Score : 22 points
Date : 2024-11-02 17:28 UTC (5 hours ago)
(HTM) web link (drops.dagstuhl.de)
(TXT) w3m dump (drops.dagstuhl.de)
| 082349872349872 wrote:
| > _how to ensure the convergence of the algorithm when the
| specializations of the basic blocks are not based on profiled
| variable values_
|
| sounds like a good use for PGO? (profile guided optimisation)
| vkazanov wrote:
| Most modern jit compilers are using live profile data,
| especially the original basic block versioning technique which
| this article is based on.
|
| This particular algorithm tries to get rid of some the problems
| of the relatively simple PGO-like approach.
|
| Btw, authors report strikingly good results.
| DannyBee wrote:
| That's because the authors are reporting results for AOT
| scheme to c compilers.
|
| For languages more directly supported by llvm/gcc, they
| already do various kinds of function versioning and
| specialization.
|
| You would be highly unlikely to get 10% there from a magic
| bullet like this - in the end, there are no magic bullets.
| Just lots of hard work.
| voxl wrote:
| Mmm, my impression is you can get 90% there with
| significantly less effort then LLVM or GCC. A good register
| allocation strategy, some basic inlining, maybe peephole
| optimization? LLVM is fighting for 5-10% improvements on
| top of the big things
| quotemstr wrote:
| Or an ecosystem-wide shift away from AOT compilation.
|
| I feel like I'm living in that "one guy against huge crowd"
| meme. Everyone else is making more AOT, and all I can say,
| usually under my breath, is "Wait! Stop! You're giving up
| something valuable! JIT and GC are actually good!"
|
| (I know you can have AOT and GC, but people usually lump AOT
| and !GC together.)
|
| AOT optimizes startup performance. I haven't seen it optimize
| other metrics. Psychologically, we often gauge overall
| performance by startup performance, but it ain't necessarily
| so. I keep expecting the pendulum to swing from "AOT and manual
| memory management" back to "JIT and garbage collection",
| because I believe the latter has a much higher performance
| ceiling once we apply sufficient optimization elbow grease.
| I've been patient and I'll remain patient.
|
| But still. PGO is just a hack around the lack of a JIT, just
| like RCU is a hack around the lack of a GC, and I think it's
| due to well-known psychological biases that we haven't embraced
| more dynamism.
|
| How do we solve the startup problems with JIT systems? Better
| image support. _Nobody_ has really cracked this nut, but I
| think it 's important. Every GraalVM language should support,
| e.g., resuming from a heap dump.
| mshockwave wrote:
| I'm actually glad to see that restriction in their study,
| because there are many cases where you just can't / more
| difficult to use PGO. One of the most common reasons I ran into
| is that clients refuse to use it (no, I'm not even joking),
| either they don't know how to come up with a good training data
| (in which case they'll point at your nose shouting IT DOESN'T
| WORK!!) or they thought it's a stupid idea (again, not joking).
| You'll be amazed by some people's stubbornness
| Lerc wrote:
| I stumbled upon Maxime Chevalier-Boisvert's work ages ago and the
| BBV just seemed to make so much sense.
|
| Nice to see it being adopted more broadly.
___________________________________________________________________
(page generated 2024-11-02 23:00 UTC)