Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Luminal – Open-source, search-based GPU compiler

github.com

Post reply on HN
Print view View original

21–30 of 70 posts

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#21

Post by jakestevens2 »

UncleOxidant wrote: post #19
jakestevens2 wrote: post #14

Earlier quoted context omitted.

Your description is exactly right. We create a search space of all possible kernels and find the best ones based on runtime. The best heuristic is no heuristic. This obviously creates a combinatorial problem that we mitigate with smarter search. The kernels are run on the computer the compiler is running on. Since runtime is our gold standard it will search for the best configuration for your hardware target. As long…

How long does this typically take? It sounds time consuming. Also, it seems like this could be similar to doing a GA?

You can also set a time budget for how long you'd like the search to run for to avoid wasting time on diminishing returns.

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#25

Post by matthewjgunton »

UncleOxidant wrote: post #22

When you say (in the video) that you can target more exotic hardware, what about things FGPA accelerators (maybe taking advantage of TVM's FPGA backend)? Also, what about CUDA alternatives like ROCm?

Yup. We are totally hardware agnostic

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#26

Post by jafioti »

efnx wrote: post #23

Cool! How is this project different from the tuning process in TVM?

basically autotuning on steroids. instead of searching single dimensions of optimization (tile sizing, etc.) we search through full algebraic rewrites (like rewriting softmax to online softmax) and various loop / tiling structures in the same unified search space.

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#27

Post by matthewjgunton »

matthewjgunton wrote: post #25
UncleOxidant wrote: post #22

When you say (in the video) that you can target more exotic hardware, what about things FGPA accelerators (maybe taking advantage of TVM's FPGA backend)? Also, what about CUDA alternatives like ROCm?

Yup. We are totally hardware agnostic

i should add this also applies to the language too. we currently support Metal (Apple's language) and CUDA, with extensions planned for others

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#28

Post by helltone »

I have a background in program analysis, but I'm less familiar with the kind of kernels you are optimising.

- Can you give some more insight on why 12 ops suffice for representing your input program?

- With such a small number of ops, isn't your search space full of repeat patterns? I understand the will to have no predefined heuristics, but it seems that learning some heuristics/patterns would massively help reduce the space.

Re: Show HN: Luminal – Open-source, search-based GPU compiler

#29

Post by jafioti »

helltone wrote: post #28

I have a background in program analysis, but I'm less familiar with the kind of kernels you are optimising. - Can you give some more insight on why 12 ops suffice for representing your input program? - With such a small number of ops, isn't your search space full of repeat patterns? I understand the will to have no predefined heuristics, but it seems that learning some heuristics/patterns would massively help reduce…

we're just optimizing linear algebra, which is mostly made up of patterns of simple ops. for instance, matmul is just broadcasted multiply -> sum reduce.

the search does common subexpression elimination by default. if two patterns are unioned in the search space, it applies that union to every occurrence of that pattern at the same time, so using e-graphs it helps keep the search space smaller.

Post reply on HN