Lang Hames via llvm-dev
2020-Oct-06 02:29 UTC
[llvm-dev] LLVM Developers Meeting JIT BoF -- Request for Topics of Interest
Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the mailing lists. It looks like we'll have an opportunity to set up impromptu meet-ups too (see https://www.youtube.com/watch?v=Qpbefagv6Ts) so if you want to do a deeper dive on a topic area we can set one or more of those up -- just let me know in this thread. Topics so far: A very brief status update on OrcV2 and JITLink. Future / Potential use-cases for the JIT. -- LLDB, the Swift interpreter, REPLs. Compile time improvements -- Experimenting with / performance-testing custom JIT pipelines (any volunteers?) -- Compile-time improvements for the existing pipeline. This is probably a broad community project, but JIT users might have interesting workloads / results to contribute. -- Hiding compile times with concurrency. Profiling, Debugging, PGO -- Profiling and Debugging support (especially via JITLink) -- How do we integrate PGO (any volunteers to experiment with this?) Reoptimization -- What it is. -- Any volunteers to start working on API design and experiments? -- Is resource management a problem (do we need to free unoptimized code) and if so how do we make it safe? I'll add another of my own topics in here: Documentation -- What would make life better for Orc beginners? -- What would make life better for Orc experts? -- What would make it easier for you to contribute to Orc? -- Any volunteers to help with the documentation effort? Looking forward to seeing you all on Thursday. -- Lang. On Fri, Oct 2, 2020 at 11:21 AM Andres Freund <andres at anarazel.de> wrote:> Hi, > > On 2020-10-02 10:44:43 -0700, Lang Hames wrote: > > Sounds good to me. I think there are two sub-topics here: > > (1) JIT specifics. E.g. What default optimization pipelines should we > > provide in the JIT? The standard 0/1/2/3/s options, or would it make > sense > > to develop something JIT specific? > > Yea. I've some hopes for "new PM" making it easier to have maintainable > and customizable pipelines. I've not played around with it too much - > largely because there's no C API last time I checked. > > > > > (2) General compile time improvements. Everyone will benefit from compile > > time improvements, but JIT clients are likely to be extra sensitive to > it. > > Have we identified any problem areas or redundancies that would be of > > interest to the broader LLVM community, and that we could solicit help in > > fixing. > > I'd guess that some of the things that can be done to significantly > improve JIT performance aren't generally applicable to most other uses > of LLVM. E.g. the overhead of redoing the same analyses for code gen is > mostly an issue on higher optimization levels, and I assume that a large > portion of e.g. clang users using -O3 will do LTO. Where a split between > optimization and code gen seems necessary in number of cases. > > > > > Possibly also related to LLJIT design - having LLJIT first generate > > > minimally optimized code and then, while that is in use, doing > optimization > > > and optimized codegen concurrently, would be neat. It feels like that'd > > > fit well into LLJIT, given that it already provides things like > > > background compile threads. > > > > > > Absolutely. Supporting this use-case was one of the motivations for the > > concurrency support in OrcV2. It's doable at the moment, but it requires > a > > fair bit of manual work on the client's part. Implementation and API > design > > in this area seem like good topics. > > Cool. > > Greetings, > > Andres Freund >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201005/c086ea90/attachment.html>
Gaier, Bjoern via llvm-dev
2020-Oct-06 05:55 UTC
[llvm-dev] LLVM Developers Meeting JIT BoF -- Request for Topics of Interest
Hey Lang, Not surprising I guess – but lately I’m much interested into MaterializationUnit and MaterializationResponsibility xD Not only because I’m total stuck there again, but also because I wonder what is possible with it besides from what I failed to do. I know that this might be to much for the BoF, but might be nice for the documentation. Kind greetings Björn From: Lang Hames <lhames at gmail.com> Sent: 06 October 2020 04:29 To: Andres Freund <andres at anarazel.de> Cc: Praveen Velliengiri <praveenvelliengiri at gmail.com>; LLVM Developers Mailing List <llvm-dev at lists.llvm.org>; David Blaikie <dblaikie at gmail.com>; Geoff Levner <glevner at gmail.com>; Christian Schafmeister <meister at temple.edu>; Stefan Gränitz <stefan.graenitz at gmail.com>; guangnan he <gnhe2009 at gmail.com>; Jacob Lifshay <programmerjake at gmail.com>; Gaier, Bjoern <Bjoern.Gaier at horiba.com>; Jared Wyles <jared.wyles at gmail.com>; Vivien Millet <vivien.millet at gmail.com>; Chris Bieneman <beanz at apple.com> Subject: Re: LLVM Developers Meeting JIT BoF -- Request for Topics of Interest Hi All, I've listed the current topics of interest below, along with some notes on each. We only have 30 minutes so we'll barely scratch the surface of these during the BoF itself. My main aims are for you to meet each other, identify potential areas of collaboration, identify things that I can do to unblock you, and get the ball rolling on some conversations that we can continue on the mailing lists. It looks like we'll have an opportunity to set up impromptu meet-ups too (see https://www.youtube.com/watch?v=Qpbefagv6Ts) so if you want to do a deeper dive on a topic area we can set one or more of those up -- just let me know in this thread. Topics so far: A very brief status update on OrcV2 and JITLink. Future / Potential use-cases for the JIT. -- LLDB, the Swift interpreter, REPLs. Compile time improvements -- Experimenting with / performance-testing custom JIT pipelines (any volunteers?) -- Compile-time improvements for the existing pipeline. This is probably a broad community project, but JIT users might have interesting workloads / results to contribute. -- Hiding compile times with concurrency. Profiling, Debugging, PGO -- Profiling and Debugging support (especially via JITLink) -- How do we integrate PGO (any volunteers to experiment with this?) Reoptimization -- What it is. -- Any volunteers to start working on API design and experiments? -- Is resource management a problem (do we need to free unoptimized code) and if so how do we make it safe? I'll add another of my own topics in here: Documentation -- What would make life better for Orc beginners? -- What would make life better for Orc experts? -- What would make it easier for you to contribute to Orc? -- Any volunteers to help with the documentation effort? Looking forward to seeing you all on Thursday. -- Lang. On Fri, Oct 2, 2020 at 11:21 AM Andres Freund <andres at anarazel.de<mailto:andres at anarazel.de>> wrote: Hi, On 2020-10-02 10:44:43 -0700, Lang Hames wrote:> Sounds good to me. I think there are two sub-topics here: > (1) JIT specifics. E.g. What default optimization pipelines should we > provide in the JIT? The standard 0/1/2/3/s options, or would it make sense > to develop something JIT specific?Yea. I've some hopes for "new PM" making it easier to have maintainable and customizable pipelines. I've not played around with it too much - largely because there's no C API last time I checked.> (2) General compile time improvements. Everyone will benefit from compile > time improvements, but JIT clients are likely to be extra sensitive to it. > Have we identified any problem areas or redundancies that would be of > interest to the broader LLVM community, and that we could solicit help in > fixing.I'd guess that some of the things that can be done to significantly improve JIT performance aren't generally applicable to most other uses of LLVM. E.g. the overhead of redoing the same analyses for code gen is mostly an issue on higher optimization levels, and I assume that a large portion of e.g. clang users using -O3 will do LTO. Where a split between optimization and code gen seems necessary in number of cases.> > Possibly also related to LLJIT design - having LLJIT first generate > > minimally optimized code and then, while that is in use, doing optimization > > and optimized codegen concurrently, would be neat. It feels like that'd > > fit well into LLJIT, given that it already provides things like > > background compile threads. > > > Absolutely. Supporting this use-case was one of the motivations for the > concurrency support in OrcV2. It's doable at the moment, but it requires a > fair bit of manual work on the client's part. Implementation and API design > in this area seem like good topics.Cool. Greetings, Andres Freund Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Junichi Tajika, Ergin Cansiz. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/6f7c95e6/attachment.html>
Lang Hames via llvm-dev
2020-Oct-06 22:26 UTC
[llvm-dev] LLVM Developers Meeting JIT BoF -- Request for Topics of Interest
Hi Bjoern, Not surprising I guess – but lately I’m much interested into> MaterializationUnit and MaterializationResponsibility xDThey're very central APIs. I'm happy to answer questions on them during the BoF, though we probably can't go in to great detail. Any discussion will help identify ways to improve the documentation though. Alex Denisov has set up a JIT Compilers community page for the Virtual Dev Meeting: https://whova.com/portal/webapp/llvm_202010/CommunityBoard/topic/406390/ . I'll be checking that periodically for discussion (~10am to 6pm PDT). Praveen has proposed a meet up for JIT clients during the coffee break tomorrow -- I'll be there for that if anyone wants to drop in. I'm also happy to schedule Zoom meetings for more detailed discussions for other topics. If anyone wants to propose one in the community page above -- I'll be free from 10am to 6pm PDT tomorrow and Thursday (outside the BoF itself). -- Lang. On Mon, Oct 5, 2020 at 10:55 PM Gaier, Bjoern <Bjoern.Gaier at horiba.com> wrote:> Hey Lang, > > > > Not surprising I guess – but lately I’m much interested into MaterializationUnit > and MaterializationResponsibility xD > > Not only because I’m total stuck there again, but also because I wonder > what is possible with it besides from what I failed to do. > > > > I know that this might be to much for the BoF, but might be nice for the > documentation. > > > > Kind greetings > > Björn > > > > *From:* Lang Hames <lhames at gmail.com> > *Sent:* 06 October 2020 04:29 > *To:* Andres Freund <andres at anarazel.de> > *Cc:* Praveen Velliengiri <praveenvelliengiri at gmail.com>; LLVM Developers > Mailing List <llvm-dev at lists.llvm.org>; David Blaikie <dblaikie at gmail.com>; > Geoff Levner <glevner at gmail.com>; Christian Schafmeister < > meister at temple.edu>; Stefan Gränitz <stefan.graenitz at gmail.com>; guangnan > he <gnhe2009 at gmail.com>; Jacob Lifshay <programmerjake at gmail.com>; Gaier, > Bjoern <Bjoern.Gaier at horiba.com>; Jared Wyles <jared.wyles at gmail.com>; > Vivien Millet <vivien.millet at gmail.com>; Chris Bieneman <beanz at apple.com> > *Subject:* Re: LLVM Developers Meeting JIT BoF -- Request for Topics of > Interest > > > > Hi All, > > > > I've listed the current topics of interest below, along with some notes on > each. We only have 30 minutes so we'll barely scratch the surface of these > during the BoF itself. My main aims are for you to meet each other, > identify potential areas of collaboration, identify things that I can do to > unblock you, and get the ball rolling on some conversations that we can > continue on the mailing lists. It looks like we'll have an opportunity to > set up impromptu meet-ups too (see > https://www.youtube.com/watch?v=Qpbefagv6Ts) so if you want to do a > deeper dive on a topic area we can set one or more of those up -- just let > me know in this thread. > > > > Topics so far: > > > > A very brief status update on OrcV2 and JITLink. > > > > Future / Potential use-cases for the JIT. > > -- LLDB, the Swift interpreter, REPLs. > > > > Compile time improvements > > -- Experimenting with / performance-testing custom JIT pipelines (any > volunteers?) > > -- Compile-time improvements for the existing pipeline. This is probably > a broad community project, but JIT users might have interesting workloads / > results to contribute. > > -- Hiding compile times with concurrency. > > > > Profiling, Debugging, PGO > > -- Profiling and Debugging support (especially via JITLink) > > -- How do we integrate PGO (any volunteers to experiment with this?) > > > > Reoptimization > > -- What it is. > > -- Any volunteers to start working on API design and experiments? > > -- Is resource management a problem (do we need to free unoptimized > code) and if so how do we make it safe? > > > > I'll add another of my own topics in here: > > > > Documentation > > -- What would make life better for Orc beginners? > > -- What would make life better for Orc experts? > > -- What would make it easier for you to contribute to Orc? > > -- Any volunteers to help with the documentation effort? > > > > Looking forward to seeing you all on Thursday. > > > > -- Lang. > > > > On Fri, Oct 2, 2020 at 11:21 AM Andres Freund <andres at anarazel.de> wrote: > > Hi, > > On 2020-10-02 10:44:43 -0700, Lang Hames wrote: > > Sounds good to me. I think there are two sub-topics here: > > (1) JIT specifics. E.g. What default optimization pipelines should we > > provide in the JIT? The standard 0/1/2/3/s options, or would it make > sense > > to develop something JIT specific? > > Yea. I've some hopes for "new PM" making it easier to have maintainable > and customizable pipelines. I've not played around with it too much - > largely because there's no C API last time I checked. > > > > > (2) General compile time improvements. Everyone will benefit from compile > > time improvements, but JIT clients are likely to be extra sensitive to > it. > > Have we identified any problem areas or redundancies that would be of > > interest to the broader LLVM community, and that we could solicit help in > > fixing. > > I'd guess that some of the things that can be done to significantly > improve JIT performance aren't generally applicable to most other uses > of LLVM. E.g. the overhead of redoing the same analyses for code gen is > mostly an issue on higher optimization levels, and I assume that a large > portion of e.g. clang users using -O3 will do LTO. Where a split between > optimization and code gen seems necessary in number of cases. > > > > > Possibly also related to LLJIT design - having LLJIT first generate > > > minimally optimized code and then, while that is in use, doing > optimization > > > and optimized codegen concurrently, would be neat. It feels like that'd > > > fit well into LLJIT, given that it already provides things like > > > background compile threads. > > > > > > Absolutely. Supporting this use-case was one of the motivations for the > > concurrency support in OrcV2. It's doable at the moment, but it requires > a > > fair bit of manual work on the client's part. Implementation and API > design > > in this area seem like good topics. > > Cool. > > Greetings, > > Andres Freund > > Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, > USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert > Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Junichi Tajika, Ergin > Cansiz. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20201006/d48e1a88/attachment.html>