Simon Taeter (Apr 13 2025 at 17:00): Simon Taeter (Apr 13 2025 at 17:00):Hello!
I've gained a huge interest in HVM2 and HVM3 which is able to fully parallelise any functional code. It is still fairly young tech but it is very promising.
I wonder weather you know about it and maybe even have some plans to targeting it in the future.
Thanks :)
Brendan Hansknecht (Apr 13 2025 at 17:35):I think Bend and HVM has come up before, but only lightly.
Brendan Hansknecht (Apr 13 2025 at 17:35):No plans to target it. I'm not sure it would make sense given how roc compiles with platforms and applications.
Brendan Hansknecht (Apr 13 2025 at 17:36):But I ultimately don't know much about it.
Anton (Apr 14 2025 at 08:43):I follow Victor Taelin on x, I'm very interested in the AI applications of the function generation he's working on :)
Magdiel Amor (Apr 22 2025 at 09:45):Do you also wonder why they got a lot of Mac minis? I do sometimes, I mean, there could have been other/better alternatives????
Anton (Apr 22 2025 at 09:47):He explained it here :)
Magdiel Amor (Apr 22 2025 at 10:01):Oh thanks will do with some explanation really.
Dries Frederickx (Apr 22 2025 at 14:07):What about MLIR? If I may ask.
Anton (Apr 22 2025 at 14:21):@Brendan Hansknecht probably knows all about that
Magdiel Amor (Apr 22 2025 at 15:05):Anton said:
He explained it here :)
Great, but even in his explanation he acknowledged an M3 will improve efficiency by about 30%
Perhaps, cost and efficiency as he says, not just efficiency.
Anton (Apr 22 2025 at 15:16):Indeed, efficiency results in lower cost due to lower power consumption.
Brendan Hansknecht (Apr 22 2025 at 15:35):Dries Frederickx said:
What about MLIR? If I may ask.
What's the actual question?
Brendan Hansknecht (Apr 22 2025 at 15:35):or I guess context
Anton (Apr 22 2025 at 15:36):What's the actual question?
Targeting MLIR for the Roc compiler I suppose
Dries Frederickx (Apr 22 2025 at 17:53):@Brendan Hansknecht If Roc could potentially act as an MLIR frontend/dialect.
Brendan Hansknecht (Apr 22 2025 at 18:12):Hmm....
Brendan Hansknecht (Apr 22 2025 at 18:13):I would not expect this to go well for the most part.
MLIR is written mostly in table gen and c++. It also generates a ton of c++. So you would be interfacing roc with that mess.
Brendan Hansknecht (Apr 22 2025 at 18:14):I know that mlir has a C api for generating nodes. That could be reasonable to interact with via Roc. So you could define an mlir compiler backend and then generate the mlir graph from roc. This would be the same as generating an mlir graph from python.
Brendan Hansknecht (Apr 22 2025 at 18:15):Of course mlir could be used to write roc compiler, but that is a fundamentally different question.
Brendan Hansknecht (Apr 22 2025 at 18:16):I don't think it would be reasonable to use roc to generate mlir dialects and passes. I think mlir is way too ingrained in c++ and simply making an interface for that would be way to complex. On top of that, you would also need a solution for the giant amount of generating c++ code that would require interaction.
Brendan Hansknecht (Apr 22 2025 at 18:17):With care and significant orchestration, maybe you could use table gen to define mlir dialects and roc to define the passes that run on dialects, but it would not be easy.
Dries Frederickx (Apr 22 2025 at 18:19):I see and also many thanks for the answer. This all just got me thinken since the whole Mojo/MAX thing is coming along. But it also got me looking at this "in-concept" project from @alexrp . Whis in my layman eyes seems like a whole clean slate that the MLIR/LLVM project presents. So I am just nudging and seeing what the current scopes are over all of these projects that all look so interesting. Even though it is far above my levels of understanding.
Dries Frederickx (Apr 22 2025 at 18:20):The graf core project, that is.
Last updated: Jun 16 2026 at 16:19 UTC