undefined | Better HN

0 pointswolfgke7y ago0 comments

> As I understood it, and as far as I can remember, the Mill AOT compiler has an easier job than that. The generic image already contains the parallelized instructions, the AOT just has to split those who are too wide for the given CPU.

In my opinion, this just moves the problem on a meta level. For the EPIC instructions of Itanium, one could encode multiple (parallel) instructions into one VLIW instruction. It was a huge problem to parallelize existing, say, C or C++ code so that this capability could be used. The fact that such a "smart compiler" turned out so hard to write was one of the things that broke Itanium's neck.

I openly have no idea by what magic a "sufficiently smart compiler" that can create such a "generic image [that] already contains the parallelized instructions" suddenly appears. How is it possible that compilers can suddenly parallelize the program, which turned out to be nigh impossible for the Itanium?!

0 comments

1 comments · 1 top-level

magicalhippo7y ago

It's been too long since I watched the videos, so unfortunately I don't remember the specifics. For reference, here's[1] the relevant one on the compiler aspect.

I do seem to recall that they seemingly had studied the failures of Itanium, and supposedly designed their architecture to not fall into the same pitfalls as with the EPIC/Itanium.

One aspect I recall is that while they have VLIW, different operations within the (compound) instruction are issued in such a way that lets them be interdependent. Like, a single VLIW instruction could have an add and a multiply, where the result of the add is used as input for the multiplication. So while the operations are grouped in a single instruction, they're not executed strictly in parallel. There's a lot of other aspects too, that's just the one I remember.

But yeah, really curious to know how that pudding will turn out.

[1]: https://www.youtube.com/watch?v=D7GDTZ45TRw

j / k navigate · click thread line to collapse