GCC's JIT Library Could Soon Be Around 5x Faster
David Malcom, the developer at Red Hat who has been spearheading the work on libgccjit, is making some progress on speeding up this embeddedable JIT compiler for the GNU Compiler Collection.
Malcom on Monday posted sixteen new patches under an "RFC" flag for embedding the as and ld components inside the GCC driver and into libgccjit. He explained, "I'm experimenting with ways of optimizing libgccjit, and the following patch kit (touching both gcc and binutils) achieves a 5x speedup of [a test benchmark] on this x86_64 box (Fedora 20)...gcc's backend code emits .s files, and libgccjit currently use pex to invoke the gcc driver to turn it from .s to a .so file (which in turn invokes "as" and "ld"). These invocations dominate the time take by libgccjit, so the patch series attempts to time them, and to move them in-process; doing so largely eliminates the cost of them."
The code in its current state isn't ready for merging, but will hopefully be all set with offering some very sizable GCC JIT compiler performance improvements by the time GCC 6.1 rolls around in 2016.
Malcom on Monday posted sixteen new patches under an "RFC" flag for embedding the as and ld components inside the GCC driver and into libgccjit. He explained, "I'm experimenting with ways of optimizing libgccjit, and the following patch kit (touching both gcc and binutils) achieves a 5x speedup of [a test benchmark] on this x86_64 box (Fedora 20)...gcc's backend code emits .s files, and libgccjit currently use pex to invoke the gcc driver to turn it from .s to a .so file (which in turn invokes "as" and "ld"). These invocations dominate the time take by libgccjit, so the patch series attempts to time them, and to move them in-process; doing so largely eliminates the cost of them."
The code in its current state isn't ready for merging, but will hopefully be all set with offering some very sizable GCC JIT compiler performance improvements by the time GCC 6.1 rolls around in 2016.
1 Comment