Le 29/02/2016 00:32, Ben Coman a écrit :
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.
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
