undefined | Better HN

0 pointsDannyBee10y ago0 comments

The problem with the path they've taken is it has a finite end.

This is why, when they compare it to v8/etc, it's kind of funny. They all have the same curve.

Basically all of these things, all of them, end up with roughly the same deficiencies once you cherry pick the low hanging fruit[1], and then they stall out, and get replaced a few years later when someone decides thing X can't do the job, and they need to write a new one. None of them ever get to a truly good state.

Rinse, wash, repeat.

The only thing these things make real progress, is by doing what LLVM did - someone works on it for years.

Let me quote a former colleague at IBM - "there is no secret silver bullet to really good compilers, it's just a lot of long hard work". If you keep resetting that hard work every couple years, that seems ... silly.

TL;DR If you really believe they've totally gotten everywhere they need to be in 3 months, i've got a bridge to sell you

[1] For example, good loop vectorization and SLP vectorization is hard.

0 comments

nadav25610y ago

Danny, you mentioned loop and SLP vectorization. One thing that bothered me while watching the development of the SLP and Loop vectorizers over the last two years was that developers who cared about SPEC added functionality that increased compile time. I remember one change that added a second phase that scans the entire IR in the SLP vectorizer to get a 1.4% win in one of the SPEC programs. I hoped the FTL project would be able to enable the vectorizers, but to my disappointment the vectorizers are too slow to justify the boost on javascript workloads.

j / k navigate · click thread line to collapse