Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: JIT Compiler Support Might Be Added To GCC 4.9

  1. #1
    Join Date
    Jan 2007
    Posts
    15,138

    Default JIT Compiler Support Might Be Added To GCC 4.9

    Phoronix: JIT Compiler Support Might Be Added To GCC 4.9

    The recently announced just-in-time (JIT) compiler library using the GNU Compiler Collection might be added to the major GCC 4.9 release in 2014...

    http://www.phoronix.com/vr.php?view=MTQ4NDY

  2. #2
    Join Date
    Jan 2013
    Posts
    60

    Default

    Very interesting, one question though, would one be able to compile an entire program to bytecode, and make it architecture independant (similar to Java)? Assuming of course, that the code itself was designed to run on multiple architectures.

  3. #3
    Join Date
    Dec 2011
    Posts
    2,108

    Default

    Quote Originally Posted by j2723 View Post
    Very interesting, one question though, would one be able to compile an entire program to bytecode, and make it architecture independant (similar to Java)? Assuming of course, that the code itself was designed to run on multiple architectures.
    Maybe then everyone would have to have all the libraries and developer libraries installed.
    So even if it worked, it sounds like it would be hugely impractical.

  4. #4
    Join Date
    Jan 2013
    Posts
    60

    Default

    Yes, or one would also have to supply the bytecode-compiled libraries alongside the program (or statically linked into your bytecode program (and jitted at runtime as well)?).

  5. #5
    Join Date
    Sep 2012
    Posts
    358

    Default

    Quote Originally Posted by j2723 View Post
    Yes, or one would also have to supply the bytecode-compiled libraries alongside the program (or statically linked into your bytecode program (and jitted at runtime as well)?).
    Bytecode-compiled applications should work with native libraries.

  6. #6
    Join Date
    Feb 2008
    Posts
    213

    Default

    What about Parrot?

  7. #7
    Join Date
    Jan 2009
    Posts
    291

    Default

    I wonder if this would be covered by the runtime library exception...

  8. #8
    Join Date
    Apr 2008
    Posts
    181

    Default

    Quote Originally Posted by phoronix View Post
    Phoronix: JIT Compiler Support Might Be Added To GCC 4.9
    The recently announced just-in-time (JIT) compiler library using the GNU Compiler Collection might be added to the major GCC 4.9 release in 2014...
    http://www.phoronix.com/vr.php?view=MTQ4NDY
    @Michael:
    s/With LLVM has long supported JIT compilation, this is a first for GCC./While LLVM has long supported JIT compilation, this is a first for GCC./

  9. #9
    Join Date
    Apr 2008
    Posts
    181

    Default

    Quote Originally Posted by timofonic View Post
    What about Parrot?
    Well, they are in different markets.

    Parrot is targetted at dynamic language. Think Perl, Python and all the associated weirdness (their special type of closure, dynamically typed variables, etc.) It's good for stuff which don't really directly translate into machine code. (Well in the end, it's still executed by a CPU, but some of the quircks don't directly translate into machine code, but would have be handled by complex libraries).


    GCC's bytecode is very close to LLVM IR. It targets a completely different category of uses cases.
    Think PNaCl, think OpenCL.

    The idea is to compile a statically typed language which can be translated into machine code. But don't translate it imediately. Instead store intermediate representation, and compile it at the last moment, so you can target the specific local architecture. It's good for stuff which do translate 1:1 with machine code (think C) but you don't want to translate it until you know exactly which machine's code. (Typical use case: algorithm that you ship with a software to process data. But you don't know which exact SIMD extension the CPU has. So either you re-compile it several time, once for each type of SIMD [they it was done until now]. Or, you compile it to bytecode and let the JIT compile exactly for the sub version of SSE/AVX/whatever).

  10. #10
    Join Date
    Jan 2009
    Posts
    1,439

    Default

    Quote Originally Posted by DrYak View Post
    Well, they are in different markets.

    Parrot is targetted at dynamic language. Think Perl, Python and all the associated weirdness (their special type of closure, dynamically typed variables, etc.) It's good for stuff which don't really directly translate into machine code. (Well in the end, it's still executed by a CPU, but some of the quircks don't directly translate into machine code, but would have be handled by complex libraries).


    GCC's bytecode is very close to LLVM IR. It targets a completely different category of uses cases.
    Think PNaCl, think OpenCL.

    The idea is to compile a statically typed language which can be translated into machine code. But don't translate it imediately. Instead store intermediate representation, and compile it at the last moment, so you can target the specific local architecture. It's good for stuff which do translate 1:1 with machine code (think C) but you don't want to translate it until you know exactly which machine's code. (Typical use case: algorithm that you ship with a software to process data. But you don't know which exact SIMD extension the CPU has. So either you re-compile it several time, once for each type of SIMD [they it was done until now]. Or, you compile it to bytecode and let the JIT compile exactly for the sub version of SSE/AVX/whatever).
    Thanks for the great explanation.
    That sounds like a huge win for packagers.
    At a minimum they'd be able to get rid of the x32/x64 split and halve their repo size. Of course they'd still have to carry enough binaries to boot-strap the machine.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •