Alex Gunnarson Comments - Answer Overflow

Alex Gunnarson

Posts Comments

MModular

•Created by Alex Gunnarson on 2/13/2024 in #questions

Lisp (or other languages) on top of Mojo?

Perfect! Thanks for sharing!

9 replies

MModular

•Created by Alex Gunnarson on 2/13/2024 in #questions

Lisp (or other languages) on top of Mojo?

Awesome! Figured that about Modular haha. They're solving the two-language problem, and proliferating languages is an explicit non-goal. But they do emphasize compatibility and, well, modularity, so hoping they expose their IR facilities.

9 replies

MModular

•Created by Alex Gunnarson on 2/13/2024 in #questions

Lisp (or other languages) on top of Mojo?

Perhaps so. Let me see if I can be more clear. Right now it's: Mojo -> Mojo MLIR -> other MLIR frontends like LLVM -> machine code Supporting transpilation is reasonably trivial, but debuggability suffers (e.g. source maps would be required, and the source language would always be "second class"): Arbitrary language -> Mojo -> Mojo MLIR -> ... I'm proposing: Arbitrary language -> Mojo MLIR -> ... Ostensibly, in this way the source language would benefit from all the MLIR tooling (stacktraces, debugging, etc.) while also benefitting from Mojo's custom performance-oriented MLIR passes. Does that make sense or is what I'm proposing not a reasonable way to achieve the goals I've outlined? Maybe I'm misunderstanding some part of the pipeline.

9 replies

MModular

•Created by Alex Gunnarson on 2/13/2024 in #questions

Lisp (or other languages) on top of Mojo?

Bumping this!

9 replies

MModular

•Created by Orwink on 2/16/2024 in #questions

If we talk about performance code, why is MLIR better than LLVM?

Awesome! I feel the same way!

15 replies

MModular

•Created by Xcur on 12/5/2023 in #questions

Mojo GPU Syntax or specific GPU stdlib data types?

Whatever Mojo ends up exposing syntatically, it's likely going to be a veneer over top of https://mlir.llvm.org/docs/Dialects/GPU/

4 replies

MModular

•Created by Orwink on 2/16/2024 in #questions

If we talk about performance code, why is MLIR better than LLVM?

That said, it's a considerable amount of work for an existing language to port over to MLIR, because they've already set up a pipeline of language-specific IR -> LLVM -> machine code and they'd need language-specific IR within MLIR -> LLVM + others -> machine code Essentially, whatever language-specific optimizations are being performed within a language's existing compiler would need to be ported to MLIR, which is extremely non-trivial. But for new languages there is only benefit, as MLIR provides a framework for performing language-specific optimizations (e.g. transpose(transpose(x)) -> x).

15 replies

MModular

•Created by Orwink on 2/16/2024 in #questions

If we talk about performance code, why is MLIR better than LLVM?

I would say MLIR is analogous to an "ubercompiler", and that yes, there's a case to be made that all languages should use it going forward.

15 replies

MModular

•Created by Orwink on 2/16/2024 in #questions

If we talk about performance code, why is MLIR better than LLVM?

I'm not sure I'd classify these kinds of optimizations as either niche or common. You can imagine these kinds of optimizations being applied all over the place outside of just linear-algebraic operations. But they're also not "standard" optimizations like loop unrolling or the like, which LLVM can perform (though arguably it's more straightforward in MLIR).

15 replies

MModular

•Created by Orwink on 2/16/2024 in #questions

If we talk about performance code, why is MLIR better than LLVM?

I'm not sure about what specific optimizations Mojo does (besides making all integers/floats SIMD dataypes), but I can speak to MLIR broadly. An example given in the MLIR docs (https://mlir.llvm.org/docs/Tutorials/Toy/Ch-3/) gives the following function:

def transpose_transpose(x) {
  return transpose(transpose(x));
}

def transpose_transpose(x) {
  return transpose(transpose(x));
}

and shows that a code (AST) transformation can be trivially defined for when transpose is called on transpose, such that the above can simply become:

def transpose_transpose(x) {
  return x;
}

def transpose_transpose(x) {
  return x;
}

This kind of optimization would be impossible in practice to achieve with LLVM, which only deals with very low-level operations.

15 replies

MModular