On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis <kilon.al...@gmail.com> 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
