Le 02/03/2016 11:07, Ben Coman a écrit :
On Mon, Feb 29, 2016 at 7:44 AM, Thierry Goubier
<thierry.goub...@gmail.com> wrote:
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).
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
