search

exaloop / codon

A high-performance, zero-overhead, extensible Python compiler using LLVM
https://docs.exaloop.io/codon
Other
14.9k stars 510 forks source link

Upstreaming OpenMP changes discussion #368

Open seanfarley opened 1 year ago

seanfarley commented 1 year ago

This is just an attempt to start a discussion about what it would take to upstream the changes (or perhaps some another solution) for codon.

arshajii commented 1 year ago

Hi @seanfarley -- do you mean https://github.com/exaloop/openmp? If so, then the best way to upstream what Codon needs would probably be to support using a custom memory allocator. Our current changes add hooks to register allocated memory with the GC, but a better and more general approach would be to just support custom allocation -- I'd imagine this would be useful for other projects using OpenMP as well!

seanfarley commented 1 year ago

Yep, that's exactly what I mean :-) Is this something that Codon plans on doing (sending patches upstream)?

lilothar commented 1 year ago

Coincidentally, when I was using Codon for research, I also encountered similar problems. There are two issues worth discussing. The first one is the support of multi-threading, whether to use openmp as a benchmark, or whether we should implement a thread pool by ourselves. Solution, provide python native async model, the second is to use bdwgc or implement a memory allocator (such as BFC) to manage memory by ourselves, as @arshajii said, if you implement the memory allocator yourself, you can also use the general openmp.

lilothar commented 1 year ago

In some scenarios, the customized openmp will conflict with the openmp of other systems, which is a problem I am facing in the scenario

seanfarley commented 1 year ago

In some scenarios, the customized openmp will conflict with the openmp of other systems, which is a problem I am facing in the scenario

This happened to me as well and is precisely why I opened an issue on it :-)