A new idea for a project: WarpSpeed (a C inliner)
Locked
A new idea for a project: WarpSpeed (a C inliner)
 
|
So now that AsmJit is gone , I had a new idea for a project and I wanted your opinion on this if you think it will be useful for the community, I call it WarpSpeed. I was thinking it would still be cool to have some kind of library that will help us boost the speed of pharo . So I was thinking about a C inliner which is far easier than an Assembly inliner (see AsmJIT) I also found TinyC http://bellard.org/tcc/ which is as you guessed a tiny c compiler 100kbs in size which i can include with a pharo image to allow me to dynamically compile inlined C code inside the pharo image so even pharo users without a C compiler installed can benefit from it . That means that if something does not perform as fast as you want you could mix C code with pharo code , I am thinking passing the C source code as a string or even having the C code in a separate file, and then dynamically call the TinyC compiler, compile it to shared library and load if via UFFI back to pharo. TinyC is very fast so compilation of the code should be as fast if not faster than compiling pharo code. Looks easy enough to do for a small project by me with the condition there are people really interested into something like this. TinyC is licensed as LGPL but I can make it fall back to other compilers as well if ones want to close the source. How it sounds as an idea ? |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
On 26/02/16 20:30, Dimitris Chloupis wrote:
> I was thinking it would still be cool to have some kind of library that > will help us boost the speed of pharo . So I was thinking about a C > inliner which is far easier than an Assembly inliner (see AsmJIT) I also > found TinyC The first thing to test is if TinyC is actually faster than Pharo. Stephan |
|
|
> On 28 Feb 2016, at 02:04, Stephan Eggermont <[hidden email]> wrote: > > On 26/02/16 20:30, Dimitris Chloupis wrote: >> I was thinking it would still be cool to have some kind of library that >> will help us boost the speed of pharo . So I was thinking about a C >> inliner which is far easier than an Assembly inliner (see AsmJIT) I also >> found TinyC > > The first thing to test is if TinyC is actually faster than Pharo. yes! but it can be a nice addition to gain part of what is lost with the removal of ASMJIT (not that anyone was using it, but well... :P) > > Stephan > > > |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
In reply to this post by Stephan Eggermont-3
Hello, There are a few big problems. In short, if the FFI call is going to do quite some computation (at least a few millisecond), assuming tinyC has performance similar to gcc or llvm, you may get faster, if the FFI call is going to do very little (calling Math.abs() for example as Pharo has no primitive for abs), the overhead of the call is going to be too big. Maybe you can make your runtime with C worth it, but for example it's clear that if you write tiny methods in C for reusability / modularity of your code and you bind each tiny method to the smalltalk runtime, using those tiny methods one by one is not going to be worth it. However, if you write a merge sort or another algorithm fully in C and do a single call to the algorithm to sort a collection, on large collection and large collections only, it's going to be worth it. In details, the main problems are: - the Smalltalk stack has specific constraints, like hand-written stack page management to support heavy stack manipulation (setting sender of a context from the image). Hence, a C stack cannot just grow inside the Smalltalk stack as in other languages directly integrated to C. The way FFI tackles this problem is by using the interpreter C stack to execute C code. This is problematic as the runtime needs to switch from assembly runtime (Smalltalk method generated from the jit) to C runtime for the FFI call and then switch back, which induces overhead in jitted code, i.e., performance critical code. Maybe you could change the way the jitted code activates C code by checking the stack size needed by the dynamic lib API and if there is enough room on the smalltalk stack, then call it on the Smalltalk stack, though it creates other problems (what if garbage collection happens from another native thread while the FFI call is performed in non blocking FFI ?). - you need to convert types between Smalltalk to C at each call inducing FFI call overhead or makes the C code aware of your data structures which you have to support for those Smalltalk data structure yourself and induces some overhead in the C runtime. In Smalltalk/X, the C runtime is directly integrated in the Smalltalk runtime. You can ask Jan Vrany how he does it. But I think he doesn't have our hand written stack management (I am not 100% sure). 2016-02-28 2:04 GMT+01:00 Stephan Eggermont <[hidden email]>: On 26/02/16 20:30, Dimitris Chloupis wrote: |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
On 28-02-16 10:17, Clément Bera wrote:
> assuming tinyC has performance similar to gcc > or llvm, you may get faster, It does not. On the website they compare to -O1 speed and then are already twice as slow Stephan |
|
|
In reply to this post by kilon.alios
On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis
<[hidden email]> wrote: > So now that AsmJit is gone , I had a new idea for a project and I wanted > your opinion on this if you think it will be useful for the community, I > call it WarpSpeed. > > I was thinking it would still be cool to have some kind of library that will > help us boost the speed of pharo . So I was thinking about a C inliner > which is far easier than an Assembly inliner (see AsmJIT) I also found > TinyC > > http://bellard.org/tcc/ > > which is as you guessed a tiny c compiler 100kbs in size which i can > include with a pharo image to allow me to dynamically compile inlined C code > inside the pharo image so even pharo users without a C compiler installed > can benefit from it . > > That means that if something does not perform as fast as you want you could > mix C code with pharo code , I am thinking passing the C source code as a > string or even having the C code in a separate file, and then dynamically > call the TinyC compiler, compile it to shared library and load if via UFFI > back to pharo. TinyC is very fast so compilation of the code should be as > fast if not faster than compiling pharo code. > > Looks easy enough to do for a small project by me with the condition there > are people really interested into something like this. TinyC is licensed as > LGPL but I can make it fall back to other compilers as well if ones want to > close the source. > > How it sounds as an idea ? I've thought about something similar myself, and also looked at tcc. I think its a really interesting idea, but you need to treat it as an *experiment* for learning. Whether its ultimately useful to the community will depend on a lot of things in implementation (I see Clement indicates some difficulties). But maybe tcc is not the right backend. [1] says "Note: I am no longer working on TCC", the last release dates wehre 2009 & 2013, and [2] indicates it tcc may be a dead end. What would be *really* interesting is, given we have a good infrastructure to compile Smalltalk to bytecode, investigate some new constructs to compile to SPIR-V [3]. The specification [4] and execution/memory model [5] have recently been released. It would be nice if someone more competent than myself could skim and advise on the feasibility of such an idea. This presentation [6] starting p38 says SPIRV presents an "opportunity to unleash innovation: Domain Specific Languages..." which is typically considered a strength of Smalltalk. p40 says "Compiler split in two, Front end compiler emits SPIR-V portable binary offline (that would be us), then SPIR-V is compiled to machine-specific binary by driver online (that would be just passing the SPIR-V to the GPU driver). [7] Perhaps interesting to see what people are trying in some other languages... * A bytecode translator like is being tried for Python [A], since SPIR-V is * End-user tools for working with SPIR-V, disassembling, analysing, debugging, optimising it, for Go[B] and Python[C]. The opportunity in producing tools for working with SPIR-V is you draw people in for the tool, and they get a side-exposure to our environment, (which of course they then fall in love with.) [1] http://bellard.org/tcc/ [2] http://www.landley.net/code/tinycc/ [3] https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation [4] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf [5] https://www.khronos.org/registry/spir-v/specs/1.0/SPIR-V-execution-and-memory-model.pdf [6] http://vulkan-tutorial.com/assets/Khronos-Vulkan-GDC-Mar15.pdf [7] http://benedictgaster.org/wp-content/uploads/2012/08/building_700_languages_spirv.pdf [A] https://github.com/cheery/spirthon/blob/master/DEV.md [B] https://github.com/andreas-jonsson/spirv [C] https://github.com/kristerw/spirv-tools |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
In reply to this post by Clément Béra
TinyC has not similar perfomance to gcc and clang, its actually slower as Stephan already mentioned.
Thats the price one has to pay for the much smaller compiler, it loses a lot of optimisations. Clement from what you saying its clear my idea would not work at all, the advantage of tinyC is that is 10 times faster than gcc and clang for compilation but the FFI overheads would kill performance indeed. And if the code becomes much larger it does not make sense to use a C inliner as it would be cleaner and easier to just keep the C code separate. Ben TinyC has been abandoned by the original author but it is now even more actively developed because several people have stepped in his place , its git repo can be found here http://repo.or.cz/w/tinycc.git its not near as actively developed as gcc or clang of course but its not inactive either. Anyway this is obviously a ton more work than I am willing to invest and with no real benefit, so thanks for opening my eyes. Back to something far more simple. |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
In reply to this post by Ben Coman
Le 29/02/2016 00:32, Ben Coman a écrit :
> On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis > <[hidden email]> wrote: >> So now that AsmJit is gone , I had a new idea for a project and I wanted >> your opinion on this if you think it will be useful for the community, I >> call it WarpSpeed. >> >> I was thinking it would still be cool to have some kind of library that will >> help us boost the speed of pharo . So I was thinking about a C inliner >> which is far easier than an Assembly inliner (see AsmJIT) I also found >> TinyC >> >> http://bellard.org/tcc/ >> >> which is as you guessed a tiny c compiler 100kbs in size which i can >> include with a pharo image to allow me to dynamically compile inlined C code >> inside the pharo image so even pharo users without a C compiler installed >> can benefit from it . >> >> That means that if something does not perform as fast as you want you could >> mix C code with pharo code , I am thinking passing the C source code as a >> string or even having the C code in a separate file, and then dynamically >> call the TinyC compiler, compile it to shared library and load if via UFFI >> back to pharo. TinyC is very fast so compilation of the code should be as >> fast if not faster than compiling pharo code. >> >> Looks easy enough to do for a small project by me with the condition there >> are people really interested into something like this. TinyC is licensed as >> LGPL but I can make it fall back to other compilers as well if ones want to >> close the source. >> >> How it sounds as an idea ? > > I've thought about something similar myself, and also looked at tcc. > I think its a really interesting idea, but you need to treat it as an > *experiment* for learning. Whether its ultimately useful to the > community will depend on a lot of things in implementation (I see > Clement indicates some difficulties). > > But maybe tcc is not the right backend. [1] says "Note: I am no longer > working on TCC", the last release dates wehre 2009 & 2013, and [2] > indicates it tcc may be a dead end. > > What would be *really* interesting is, given we have a good > infrastructure to compile Smalltalk to bytecode, investigate some new > constructs to compile to SPIR-V [3]. The specification [4] and > execution/memory model [5] have recently been released. It would be > nice if someone more competent than myself could skim and advise on > the feasibility of such an idea. SPIR-V format is similar to the LLVM-IR and it is quite hard to generate for a language like Smalltalk. Typed operations, SSA, Phi nodes, etc... You get extremely high performance this way, but it is a lot of work. > This presentation [6] starting p38 says SPIRV presents an "opportunity > to unleash innovation: Domain Specific Languages..." which is > typically considered a strength of Smalltalk. p40 says "Compiler split > in two, Front end compiler emits SPIR-V portable binary offline (that > would be us), then SPIR-V is compiled to machine-specific binary by > driver online (that would be just passing the SPIR-V to the GPU > driver). [7] Yes, this is certainly where SPIR-V is interesting: all OpenCL devices would carry a SPIR-V back-end compiler. > Perhaps interesting to see what people are trying in some other languages... > * A bytecode translator like is being tried for Python [A], since SPIR-V is > * End-user tools for working with SPIR-V, disassembling, analysing, > debugging, optimising it, for Go[B] and Python[C]. > > The opportunity in producing tools for working with SPIR-V is you draw > people in for the tool, and they get a side-exposure to our > environment, (which of course they then fall in love with.) The opportunity is more like a compiler infrastructure you'll be writing. If well written, yes, it could be an interesting artefact (training, teaching compilation). Thierry > > [1] http://bellard.org/tcc/ > [2] http://www.landley.net/code/tinycc/ > [3] https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation > [4] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf > [5] https://www.khronos.org/registry/spir-v/specs/1.0/SPIR-V-execution-and-memory-model.pdf > [6] > http://vulkan-tutorial.com/assets/Khronos-Vulkan-GDC-Mar15.pdf > [7] http://benedictgaster.org/wp-content/uploads/2012/08/building_700_languages_spirv.pdf > > > [A] https://github.com/cheery/spirthon/blob/master/DEV.md > [B] https://github.com/andreas-jonsson/spirv > [C] https://github.com/kristerw/spirv-tools > > |
|
|
On Mon, Feb 29, 2016 at 7:44 AM, Thierry Goubier
<[hidden email]> wrote: > Le 29/02/2016 00:32, Ben Coman a écrit : >> >> On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis >> <[hidden email]> wrote: >>> >>> So now that AsmJit is gone , I had a new idea for a project and I wanted >>> your opinion on this if you think it will be useful for the community, I >>> call it WarpSpeed. >>> >>> I was thinking it would still be cool to have some kind of library that >>> will >>> help us boost the speed of pharo . So I was thinking about a C inliner >>> which is far easier than an Assembly inliner (see AsmJIT) I also found >>> TinyC >>> >>> http://bellard.org/tcc/ >>> >>> which is as you guessed a tiny c compiler 100kbs in size which i can >>> include with a pharo image to allow me to dynamically compile inlined C >>> code >>> inside the pharo image so even pharo users without a C compiler installed >>> can benefit from it . >>> >>> That means that if something does not perform as fast as you want you >>> could >>> mix C code with pharo code , I am thinking passing the C source code as a >>> string or even having the C code in a separate file, and then dynamically >>> call the TinyC compiler, compile it to shared library and load if via >>> UFFI >>> back to pharo. TinyC is very fast so compilation of the code should be as >>> fast if not faster than compiling pharo code. >>> >>> Looks easy enough to do for a small project by me with the condition >>> there >>> are people really interested into something like this. TinyC is licensed >>> as >>> LGPL but I can make it fall back to other compilers as well if ones want >>> to >>> close the source. >>> >>> How it sounds as an idea ? >> >> >> I've thought about something similar myself, and also looked at tcc. >> I think its a really interesting idea, but you need to treat it as an >> *experiment* for learning. Whether its ultimately useful to the >> community will depend on a lot of things in implementation (I see >> Clement indicates some difficulties). >> >> But maybe tcc is not the right backend. [1] says "Note: I am no longer >> working on TCC", the last release dates wehre 2009 & 2013, and [2] >> indicates it tcc may be a dead end. >> >> What would be *really* interesting is, given we have a good >> infrastructure to compile Smalltalk to bytecode, investigate some new >> constructs to compile to SPIR-V [3]. The specification [4] and >> execution/memory model [5] have recently been released. It would be >> nice if someone more competent than myself could skim and advise on >> the feasibility of such an idea. > > > SPIR-V format is similar to the LLVM-IR and it is quite hard to generate for > a language like Smalltalk. Typed operations, SSA, Phi nodes, etc... You get > extremely high performance this way, but it is a lot of work. > >> This presentation [6] starting p38 says SPIRV presents an "opportunity >> to unleash innovation: Domain Specific Languages..." which is >> typically considered a strength of Smalltalk. p40 says "Compiler split >> in two, Front end compiler emits SPIR-V portable binary offline (that >> would be us), then SPIR-V is compiled to machine-specific binary by >> driver online (that would be just passing the SPIR-V to the GPU >> driver). [7] > > > Yes, this is certainly where SPIR-V is interesting: all OpenCL devices would > carry a SPIR-V back-end compiler. > >> Perhaps interesting to see what people are trying in some other >> languages... >> * A bytecode translator like is being tried for Python [A], since SPIR-V >> is >> * End-user tools for working with SPIR-V, disassembling, analysing, >> debugging, optimising it, for Go[B] and Python[C]. >> >> The opportunity in producing tools for working with SPIR-V is you draw >> people in for the tool, and they get a side-exposure to our >> environment, (which of course they then fall in love with.) > The opportunity is more like a compiler infrastructure you'll be writing. If > well written, yes, it could be an interesting artefact (training, teaching > compilation). Back to Dimitris' original question, I wonder that the potential speed benefit comes not so much from using "C", but from leveraging a large body of work on optimizing passes at the lower level. I found a tutorial [1] to produce a toy language "Kaleidoscope" that generates LLVM IR such that "by the end of the tutorial, we’ll have written a bit less than 1000 lines of code. With this small amount of code, we’ll have built up a very reasonable compiler for a non-trivial language including a hand-written lexer, parser, AST, as well as code generation support with a JIT compiler." As well as a C++ version, there is also an OCaml version of the tutorial [2], which makes me wonder what a Pharo version of the tutorial would look like. This seems like a reasonable level for a student project. Know any students keen to try? [1] http://llvm.org/docs/tutorial/LangImpl1.html [2] http://llvm.org/docs/tutorial/index.html [3] http://llvm.org/docs/tutorial/PharoLangImpl1.html The project outline might be... 1. Implement Kaleidoscope via the existing C++ tutorial 2. In Pharo, write a minimal FFI interface to LLVM 3. Re-implement the Kaleidoscope tutorial in Pharo in its simplest form, following the existing tutorial's philosophy "to make this tutorial maximally understandable and hackable, we choose to implement everything in C++ instead of using lexer and parser generators" - matching the existing tutorial as close as possible to ease acceptance to... 4. Submit Pharo version of Kaleidoscope tutorial for inclusion on the LLVM site [3]. This would provide a showcase of Pharo to a group we'd probably never get a look in from**. In particularly where section 3.5 says "code generation to LLVM doesn’t really get us much, except that we can look at the *pretty* IR calls" , we could demonstrate the ease of extending our Inspector with custom views, versus their textual presentation. 5. Revise the tutorial to make optimal use of our built in AST infrastructure. I naively wonder if it could be possible or beneficial for Slang to generate LLVM IR directly and cherry pick optimisation passes, with the ability to use in-image tools to review before & after transformation of each pass, rather than generating C first and only getting the final result. ** We operate in an attention scarcity economy. Saying "come and look at this great Thing we've got" is often not enough. It helps to be able to say "this Thung your interested in, here's another way to look at it (using Thing.)" Perhaps there's even an outside chance to snag passing interest from random LLVM guys in our Cog/Spur/Sista JIT technology. cheers -ben |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
That does not change the fact that you will have a FFI overhead.
For example pyOpenGL 2 was implemented using the Python C API as a wrapper to OpenGL pyOpenGL3 was implemented using ctypes, the official FFI of python (cpython in particular) . Version 3 is 2 to 3 times slower than version 2. But then a FFI also has much lower maintenance cost which is the reason why they moved to a FFI implementations. Its really a difficult problem to solve and there is no blue pill solution. In my case I dont need to because Unreal has already a nice visual scripting language but I want to use Pharo with Unreal. FFI is not an option since unreal builds its own executables and I dont want to hack the engine even though its open source. So I even considered making my own language on top of pharo that will compile to C++. But obviously that is a very big effort and would mean sacrificing a lot of nice things about pharo syntax. So now I fall back to my initial "lazy" solution of shared memory files. Share memory between Pharo and Unreal , let those two process communicate via the share memory and then save the shared memory to a file so I don't lose live state. Relative easy to do since OS already support and provide such functionality. The pro: is that you can still use Pharo as it is and have access to any C++ functionality the con: you have to do all the manual work of mapping Pharo messages to C++ functionality, both at pharo but mainly at the C++ side. However your post made me wonder if I can still invent a programming language like LLVM IR, something that will be basically a protocol of communication between Pharo and C++ and even support onboard features of Unreal like GC, reflection, hot code reloading, blueprints , game editor etc. It looks like that will be the direction I will be going afterall. Seems much simpler, easier and practical than anything else. |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
In reply to this post by Ben Coman
Le 02/03/2016 11:07, Ben Coman a écrit :
> On Mon, Feb 29, 2016 at 7:44 AM, Thierry Goubier > <[hidden email]> wrote: >> Le 29/02/2016 00:32, Ben Coman a écrit : >>> >>> On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis >>> <[hidden email]> wrote: >>>> >>>> So now that AsmJit is gone , I had a new idea for a project and I wanted >>>> your opinion on this if you think it will be useful for the community, I >>>> call it WarpSpeed. >>>> >>>> I was thinking it would still be cool to have some kind of library that >>>> will >>>> help us boost the speed of pharo . So I was thinking about a C inliner >>>> which is far easier than an Assembly inliner (see AsmJIT) I also found >>>> TinyC >>>> >>>> http://bellard.org/tcc/ >>>> >>>> which is as you guessed a tiny c compiler 100kbs in size which i can >>>> include with a pharo image to allow me to dynamically compile inlined C >>>> code >>>> inside the pharo image so even pharo users without a C compiler installed >>>> can benefit from it . >>>> >>>> That means that if something does not perform as fast as you want you >>>> could >>>> mix C code with pharo code , I am thinking passing the C source code as a >>>> string or even having the C code in a separate file, and then dynamically >>>> call the TinyC compiler, compile it to shared library and load if via >>>> UFFI >>>> back to pharo. TinyC is very fast so compilation of the code should be as >>>> fast if not faster than compiling pharo code. >>>> >>>> Looks easy enough to do for a small project by me with the condition >>>> there >>>> are people really interested into something like this. TinyC is licensed >>>> as >>>> LGPL but I can make it fall back to other compilers as well if ones want >>>> to >>>> close the source. >>>> >>>> How it sounds as an idea ? >>> >>> >>> I've thought about something similar myself, and also looked at tcc. >>> I think its a really interesting idea, but you need to treat it as an >>> *experiment* for learning. Whether its ultimately useful to the >>> community will depend on a lot of things in implementation (I see >>> Clement indicates some difficulties). >>> >>> But maybe tcc is not the right backend. [1] says "Note: I am no longer >>> working on TCC", the last release dates wehre 2009 & 2013, and [2] >>> indicates it tcc may be a dead end. >>> >>> What would be *really* interesting is, given we have a good >>> infrastructure to compile Smalltalk to bytecode, investigate some new >>> constructs to compile to SPIR-V [3]. The specification [4] and >>> execution/memory model [5] have recently been released. It would be >>> nice if someone more competent than myself could skim and advise on >>> the feasibility of such an idea. >> >> >> SPIR-V format is similar to the LLVM-IR and it is quite hard to generate for >> a language like Smalltalk. Typed operations, SSA, Phi nodes, etc... You get >> extremely high performance this way, but it is a lot of work. >> >>> This presentation [6] starting p38 says SPIRV presents an "opportunity >>> to unleash innovation: Domain Specific Languages..." which is >>> typically considered a strength of Smalltalk. p40 says "Compiler split >>> in two, Front end compiler emits SPIR-V portable binary offline (that >>> would be us), then SPIR-V is compiled to machine-specific binary by >>> driver online (that would be just passing the SPIR-V to the GPU >>> driver). [7] >> >> >> Yes, this is certainly where SPIR-V is interesting: all OpenCL devices would >> carry a SPIR-V back-end compiler. >> >>> Perhaps interesting to see what people are trying in some other >>> languages... >>> * A bytecode translator like is being tried for Python [A], since SPIR-V >>> is >>> * End-user tools for working with SPIR-V, disassembling, analysing, >>> debugging, optimising it, for Go[B] and Python[C]. >>> >>> The opportunity in producing tools for working with SPIR-V is you draw >>> people in for the tool, and they get a side-exposure to our >>> environment, (which of course they then fall in love with.) > > >> The opportunity is more like a compiler infrastructure you'll be writing. If >> well written, yes, it could be an interesting artefact (training, teaching >> compilation). > > Back to Dimitris' original question, I wonder that the potential speed > benefit comes not so much from using "C", but from leveraging a large > body of work on optimizing passes at the lower level. I found a > tutorial [1] to produce a toy language "Kaleidoscope" that generates > LLVM IR such that "by the end of the tutorial, we’ll have written a > bit less than 1000 lines of code. With this small amount of code, > we’ll have built up a very reasonable compiler for a non-trivial > language including a hand-written lexer, parser, AST, as well as code > generation support with a JIT compiler." What is costly in the Pharo space is the fact that Kaleidoscope rely on the LLVM C++ infrastructure to generate the IR. And this linking to C++ code and classes is hard to do. Generating .ll files are however Ok, and then everything can be done on the command line. However, the IR is complex in itself, and not very obvious in places (vectors, types), and you have to cope with the Phi instructions and block / temporary naming / declarations and all... It represent in the end quite a significant amount of code (I have it for my R compiler work but it's company property). I tried to make it faster to build a representation of the LLVM-IR via SmaCC (build a parser of LLVM-IR to get the automatic generation of the nodes) but, after spending a week on it, I could not get a parser without conflicts, so I implemented it by hand instead. Long term, I think the LLVM-IR parser is a better investment, but I don't have anymore the time for it. After that, all llvm tools are command line, so just OSProcess like interface is good enough. > As well as a C++ version, there is also an OCaml version of the > tutorial [2], which makes me wonder what a Pharo version of the > tutorial would look like. This seems like a reasonable level for a > student project. Know any students keen to try? > > [1] http://llvm.org/docs/tutorial/LangImpl1.html > [2] http://llvm.org/docs/tutorial/index.html > [3] http://llvm.org/docs/tutorial/PharoLangImpl1.html > > > The project outline might be... > > 1. Implement Kaleidoscope via the existing C++ tutorial > > 2. In Pharo, write a minimal FFI interface to LLVM > > 3. Re-implement the Kaleidoscope tutorial in Pharo in its simplest > form, following the existing tutorial's philosophy "to make this > tutorial maximally understandable and hackable, we choose to implement > everything in C++ instead of using lexer and parser generators" - > matching the existing tutorial as close as possible to ease acceptance > to... > > 4. Submit Pharo version of Kaleidoscope tutorial for inclusion on the > LLVM site [3]. This would provide a showcase of Pharo to a group we'd > probably never get a look in from**. In particularly where section > 3.5 says "code generation to LLVM doesn’t really get us much, except > that we can look at the *pretty* IR calls" , we could demonstrate the > ease of extending our Inspector with custom views, versus their > textual presentation. Yes, this could be interesting. As far as the compiler and LLVM community goes, they are certainly interested by interesting results coming from our community, especially if we challenge boundaries: compilation of dynamic languages is a difficult and important subject, as well as targetting heterogeneous hardware. The guys I work with presented their work [1] at the LLVM devroom at this year's FOSDEM, and I'll go to CGO[2] in two weeks time. > 5. Revise the tutorial to make optimal use of our built in AST infrastructure. > > > I naively wonder if it could be possible or beneficial for Slang to > generate LLVM IR directly and cherry pick optimisation passes, with > the ability to use in-image tools to review before & after > transformation of each pass, rather than generating C first and only > getting the final result. I do think it could be interesting. I've worked a few years with compilers writing C as their back-end target and finding it really painfull to produce certain types of code structures. > ** We operate in an attention scarcity economy. Saying "come and look > at this great Thing we've got" is often not enough. It helps to be > able to say "this Thung your interested in, here's another way to look > at it (using Thing.)" Perhaps there's even an outside chance to snag > passing interest from random LLVM guys in our Cog/Spur/Sista JIT > technology. Thierry [1] https://fosdem.org/2016/schedule/event/llvm_dataflow/ [2] http://cgo.org/cgo2016/ > > cheers -ben > > |
|
|
On Wed, Mar 2, 2016 at 6:20 PM, Thierry Goubier
<[hidden email]> wrote: > Le 02/03/2016 11:07, Ben Coman a écrit : >> >> Back to Dimitris' original question, I wonder that the potential speed >> benefit comes not so much from using "C", but from leveraging a large >> body of work on optimizing passes at the lower level. I found a >> tutorial [1] to produce a toy language "Kaleidoscope" that generates >> LLVM IR such that "by the end of the tutorial, we’ll have written a >> bit less than 1000 lines of code. With this small amount of code, >> we’ll have built up a very reasonable compiler for a non-trivial >> language including a hand-written lexer, parser, AST, as well as code >> generation support with a JIT compiler." > > > What is costly in the Pharo space is the fact that Kaleidoscope rely on the > LLVM C++ infrastructure to generate the IR. And this linking to C++ code and > classes is hard to do. Are you referring only to FFI interfacing versus C++ name mangling, for which "the C bindings in include/llvm-c should help a lot, since most languages have strong support for interfacing with C.[A]" or something more? [A] http://llvm.org/releases/3.1/docs/FAQ.html cheers -ben |
Re: A new idea for a project: WarpSpeed (a C inliner)
|
|
Le 02/03/2016 20:21, Ben Coman a écrit :
> On Wed, Mar 2, 2016 at 6:20 PM, Thierry Goubier > <[hidden email]> wrote: >> Le 02/03/2016 11:07, Ben Coman a écrit : >>> >>> Back to Dimitris' original question, I wonder that the potential speed >>> benefit comes not so much from using "C", but from leveraging a large >>> body of work on optimizing passes at the lower level. I found a >>> tutorial [1] to produce a toy language "Kaleidoscope" that generates >>> LLVM IR such that "by the end of the tutorial, we’ll have written a >>> bit less than 1000 lines of code. With this small amount of code, >>> we’ll have built up a very reasonable compiler for a non-trivial >>> language including a hand-written lexer, parser, AST, as well as code >>> generation support with a JIT compiler." >> >> >> What is costly in the Pharo space is the fact that Kaleidoscope rely on the >> LLVM C++ infrastructure to generate the IR. And this linking to C++ code and >> classes is hard to do. > > Are you referring only to FFI interfacing versus C++ name mangling, > for which "the C bindings in include/llvm-c should help a lot, since > most languages have strong support for interfacing with C.[A]" or > something more? No, just the fact that the IR is quite complex (have a look into the llvm IR reference), so you use a context and a builder (Builder.CreateFAdd) in the C++ code (and I think the Ocaml llvm module is probably large since it recreates the structure). The naming scheme of LLVM is quite complex and unobvious as well (the %0, %1, etc...) with strange rules biting you if you don't number the same way as LLVM does when you use its API. Thierry > [A] http://llvm.org/releases/3.1/docs/FAQ.html > > cheers -ben > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |