Thanks Mikhail and Manuel for the reactions! Mikhail, thanks for the tip on xmalloc, will take a look if that can help clean up the plugin code.
Manuel, 0) Yes, we hope to make it faster! 1) Initially coding within GCC would have been too intimidating, but I think i've started to get a feel for the system and porting the compiler to some sort of C++ module might be a good long term to strategy to avoid drift as GCC internal evolve. I'm not sure exactly where it would fit in however- I don't think it could be described with the machine description language. There is alot of complexity involved in handling things like addressable local variables, which have to be allocated as unit length arrays so that we can pass around a reference to them. Would it be possible to write a backend that generates code from Gimple and not RTL? 2) I'm hoping we can get within 10-20% slowdown. However, the ultimate goal is to be include "native" code in Renjin's auto parallelization feature, which operates more on the level of aSQL query planner than at the instruction level, which would lead to a net speedup. That's the working hypothesis at least. I'm planning on doing a round of benchmarking in the next 1-2 months along with a comparison of the assembly generated by GCC on one hand for a given source, and the assembly ultimately generated by the JVM's JIT compiler. 3) Good to know! Is this right the mailing list to ask questions about some of the internal structure? The GCC Internals manual is very useful, and the source provides a lot of answers, but sometimes I run into questions, for example, on how exactly UNORDERED_EXPR is defined, or how to access the byte offset for COMPONENT_REF expression when field names vary. Best, Alex On Mon, Feb 1, 2016 at 10:25 PM, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > On 01/02/16 12:34, Bertram, Alexander wrote: >> >> I wanted to share a project we've been working on for sometime within >> the context of Renjin, >> a new interpreter for the R language running on the JVM. >> >> We basically needed a way to compile C and Fortran code to JVM >> classes, and for the last year or two we've been working on tool chain >> that's composed of a GCC plugin which dumps Gimple trees out to a JSON >> file, and a Java program which reads the JSON and compiles it to Java >> classfiles. > > > This sounds interesting! (R is so slow) > > 1) Wouldn't it be better to directly compile to Java bytecode? I think GJC > was able to do that in the past, but I'm not sure how bit-rotted that code > is by now. https://gcc.gnu.org/ml/gcc/2000-02/msg00161.html It may be a more > robust solution in the long run. > > 2) The reason that R uses so much C and Fortran code is because when > compiled, that code is much faster than R. How much is lost by compiling and > running in JVM? > > 3) Gimple is not completely target independent, but I think we would like to > move towards that direction, so reporting bugs about that with specific > testcases may be helpful. Of course, a JVM target would make this concern > irrelevant. > >> Anyway, using the GCC plugin interface has been terrific, and the >> gimple trees have been great to work with! > > > Please, note that the plugin API is mainly driven by its users. If you want > to see improvements, don't hesitate to propose patches. > > Cheers, > > Manuel. > -- Alex Bertram Technical Director bedatadriven Web: http://bedatadriven.com Email: a...@bedatadriven.com Tel. Nederlands: +31(0)647205388 Skype: akbertram
