Hi, Lang As a starter using LLVM JIT to improve OLAP execution engine performance, I'm very glad to hear that. I can't find some useful document help me get start to use the new ORC JIT API quickly. Only can find some examples how to use it, but don't know the internal from low level, and very blurred to design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT more easy to adoption. Big thanks. Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org> 于2020年1月17日周五 下午11:38写道：> Thank you for creating weekly updates, they will be quite useful, since > previously ORC development seemed rather opaque. > > One thing that will be useful (and was done to some extent with ORCv1) is > to expose ORCv2's API via C-compatible bindings such that code from > languages other than C++ (Rust for me) can effectively use it, including > things such as the equivalent of -march=native and introspection such that > the supported SIMD widths can be detected. I'm planning on using ORC to > compile shaders for Kazan, the GPU driver that I'm writing for > libre-riscv's hybrid cpu/gpu. > > Jacob Lifshay > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Guang-Nan He -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200118/19ee4708/attachment.html>
Hi All, Ok -- sounds like there's enough interest to keep going with these status updates. You can expect update #2 in a couple of days. :) Nice idea! - might even be worth spinning up a separate channel on the> Discord for the JIT?Seems reasonable to me. There has been a lot of JIT discussion in #llvm -- it might be nice to move it to a #jit channel to maximize the signal-to-noise ratio. My use case for ORC is an expression-evaluator library I'm working on> called JitCat (www.jitcat.org)... >Sounds very cool! I'm for the most part just a lowly user of ORC but I try to contribute here> and there when I can. Mostly by nagging about COFF support through bug > reports ;-).Anything you can contribute (bug reports included) is very welcome. Debugging and development for Windows is *extra* welcome, since I don't have a windows box to develop or test with. One thing that will be useful (and was done to some extent with ORCv1) is> to expose ORCv2's API via C-compatible bindings such that code from > languages other than C++ (Rust for me) can effectively use it, including > things such as the equivalent of -march=native and introspection such that > the supported SIMD widths can be detected. I'm planning on using ORC to > compile shaders for Kazan, the GPU driver that I'm writing for > libre-riscv's hybrid cpu/gpu.That's a really good point. And timely: We need an ORCv2 C API before we can kill off ORCv1. We should use http://llvm.org/PR31103 to track this (hopefully we can finally close it). If you're interested in this work please CC yourself on that bug. There are two approaches we can take to C bindings for ORCv2. The first one I'll call "wrap LLJIT", and it's pretty much what it sounds like: We provide an API for initializing an LLJITBuilder, and accessing methods in the resulting LLJIT object. This would provide a similar level of functionality to the ExecutionEngine bindings, and also enable basic lazy compilation. The second approach would be to wrap the lower level APIs (ExecutionSession, MaterializationUnit, etc.) to allow clients to build their own JIT instances in C. These approaches aren't mutually exclusive, and the best way forward is probably to start with the first approach, then add elements from the second over time. Any volunteers to work on this? I need to finish the new initializer work before I can tackle this, so I might be a while yet. As a starter using LLVM JIT to improve OLAP execution engine performance,> I'm very glad to hear that. I can't find some useful document help me get > start to use the new ORC JIT API quickly. Only can find some examples how > to use it, but don't know the internal from low level, and very blurred to > design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT > more easy to adoption.Ok. Which tutorials have you been following? If possible, could you write some notes on where you got stuck, or where the design was difficult to follow? That will help us determine where the documentation and tutorials could most benefit from improvement. -- Lang. On Fri, Jan 17, 2020 at 11:35 PM guangnan he <gnhe2009 at gmail.com> wrote:> Hi, Lang > As a starter using LLVM JIT to improve OLAP execution engine performance, > I'm very glad to hear that. I can't find some useful document help me get > start to use the new ORC JIT API quickly. Only can find some examples how > to use it, but don't know the internal from low level, and very blurred to > design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT > more easy to adoption. > Big thanks. > > > > > Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org> 于2020年1月17日周五 > 下午11:38写道： > >> Thank you for creating weekly updates, they will be quite useful, since >> previously ORC development seemed rather opaque. >> >> One thing that will be useful (and was done to some extent with ORCv1) is >> to expose ORCv2's API via C-compatible bindings such that code from >> languages other than C++ (Rust for me) can effectively use it, including >> things such as the equivalent of -march=native and introspection such that >> the supported SIMD widths can be detected. I'm planning on using ORC to >> compile shaders for Kazan, the GPU driver that I'm writing for >> libre-riscv's hybrid cpu/gpu. >> >> Jacob Lifshay >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > > -- > Guang-Nan He > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/dc0a3f3f/attachment.html>
On Tue, Jan 21, 2020, 13:16 Lang Hames <lhames at gmail.com> wrote:> Hi All, > > Ok -- sounds like there's enough interest to keep going with these status > updates. You can expect update #2 in a couple of days. :) >Yay! One thing that will be useful (and was done to some extent with ORCv1) is>> to expose ORCv2's API via C-compatible bindings ... > > > That's a really good point. And timely: We need an ORCv2 C API before we > can kill off ORCv1. We should use http://llvm.org/PR31103 to track this > (hopefully we can finally close it). If you're interested in this work > please CC yourself on that bug. >Added myself.> > There are two approaches we can take to C bindings for ORCv2. The first > one I'll call "wrap LLJIT", and it's pretty much what it sounds like: We > provide an API for initializing an LLJITBuilder, and accessing methods in > the resulting LLJIT object. This would provide a similar level of > functionality to the ExecutionEngine bindings, and also enable basic lazy > compilation. The second approach would be to wrap the lower level APIs > (ExecutionSession, MaterializationUnit, etc.) to allow clients to build > their own JIT instances in C. These approaches aren't mutually exclusive, > and the best way forward is probably to start with the first approach, then > add elements from the second over time. > > Any volunteers to work on this? I need to finish the new initializer work > before I can tackle this, so I might be a while yet. >Sorry, I'm currently working on the frontend for our shader compiler, I won't get to the parts that need LLVM for at least a month or so. However, once I'm there, I can help out some with creating the C bindings. Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/997c78c9/attachment.html>
I appreciate the weekly updates very much - thanks Lang! Everything I know about the ORCV2 JIT I learned from Lang's 2018 LLVM-Dev talk. There is sample code scattered throughout the talk that I've watched over and over again to piece together our JIT. There On Tue, Jan 21, 2020 at 4:16 PM Lang Hames <lhames at gmail.com> wrote:> Hi All, > > Ok -- sounds like there's enough interest to keep going with these status > updates. You can expect update #2 in a couple of days. :) > > Nice idea! - might even be worth spinning up a separate channel on the >> Discord for the JIT? > > > Seems reasonable to me. There has been a lot of JIT discussion in #llvm -- > it might be nice to move it to a #jit channel to maximize the > signal-to-noise ratio. > > My use case for ORC is an expression-evaluator library I'm working on >> called JitCat (www.jitcat.org)... >> > > Sounds very cool! > > I'm for the most part just a lowly user of ORC but I try to contribute >> here and there when I can. Mostly by nagging about COFF support through bug >> reports ;-). > > > Anything you can contribute (bug reports included) is very welcome. > Debugging and development for Windows is *extra* welcome, since I don't > have a windows box to develop or test with. > > One thing that will be useful (and was done to some extent with ORCv1) is >> to expose ORCv2's API via C-compatible bindings such that code from >> languages other than C++ (Rust for me) can effectively use it, including >> things such as the equivalent of -march=native and introspection such that >> the supported SIMD widths can be detected. I'm planning on using ORC to >> compile shaders for Kazan, the GPU driver that I'm writing for >> libre-riscv's hybrid cpu/gpu. > > > That's a really good point. And timely: We need an ORCv2 C API before we > can kill off ORCv1. We should use http://llvm.org/PR31103 to track this > (hopefully we can finally close it). If you're interested in this work > please CC yourself on that bug. > > There are two approaches we can take to C bindings for ORCv2. The first > one I'll call "wrap LLJIT", and it's pretty much what it sounds like: We > provide an API for initializing an LLJITBuilder, and accessing methods in > the resulting LLJIT object. This would provide a similar level of > functionality to the ExecutionEngine bindings, and also enable basic lazy > compilation. The second approach would be to wrap the lower level APIs > (ExecutionSession, MaterializationUnit, etc.) to allow clients to build > their own JIT instances in C. These approaches aren't mutually exclusive, > and the best way forward is probably to start with the first approach, then > add elements from the second over time. > > Any volunteers to work on this? I need to finish the new initializer work > before I can tackle this, so I might be a while yet. > > As a starter using LLVM JIT to improve OLAP execution engine performance, >> I'm very glad to hear that. I can't find some useful document help me get >> start to use the new ORC JIT API quickly. Only can find some examples how >> to use it, but don't know the internal from low level, and very blurred to >> design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT >> more easy to adoption. > > > Ok. Which tutorials have you been following? If possible, could you write > some notes on where you got stuck, or where the design was difficult to > follow? That will help us determine where the documentation and tutorials > could most benefit from improvement. > > -- Lang. > > On Fri, Jan 17, 2020 at 11:35 PM guangnan he <gnhe2009 at gmail.com> wrote: > >> Hi, Lang >> As a starter using LLVM JIT to improve OLAP execution engine performance, >> I'm very glad to hear that. I can't find some useful document help me get >> start to use the new ORC JIT API quickly. Only can find some examples how >> to use it, but don't know the internal from low level, and very blurred to >> design a clearly JIT toolset. Hope more tutorials add in and help ORC JIT >> more easy to adoption. >> Big thanks. >> >> >> >> >> Jacob Lifshay via llvm-dev <llvm-dev at lists.llvm.org> 于2020年1月17日周五 >> 下午11:38写道： >> >>> Thank you for creating weekly updates, they will be quite useful, since >>> previously ORC development seemed rather opaque. >>> >>> One thing that will be useful (and was done to some extent with ORCv1) >>> is to expose ORCv2's API via C-compatible bindings such that code from >>> languages other than C++ (Rust for me) can effectively use it, including >>> things such as the equivalent of -march=native and introspection such that >>> the supported SIMD widths can be detected. I'm planning on using ORC to >>> compile shaders for Kazan, the GPU driver that I'm writing for >>> libre-riscv's hybrid cpu/gpu. >>> >>> Jacob Lifshay >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >> >> >> -- >> Guang-Nan He >> >>-- Christian Schafmeister Professor, Chemistry Department Temple University -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200121/112d54b6/attachment.html>