Announcement

Collapse
No announcement yet.

JIT Compiler Support Might Be Added To GCC 4.9

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        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)?).

        Comment


        • #5
          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.

          Comment


          • #6
            What about Parrot?

            Comment


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

              Comment


              • #8
                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./

                Comment


                • #9
                  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).

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Originally posted by liam View Post
                      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.
                      Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
                      Last edited by JS987; 10-15-2013, 05:59 AM.

                      Comment


                      • #12
                        Originally posted by JS987 View Post
                        Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
                        Presumably they would only need to be jitted once then stored as binaries.

                        Comment


                        • #13
                          Originally posted by liam View Post
                          Presumably they would only need to be jitted once then stored as binaries.
                          It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.

                          Comment


                          • #14
                            Originally posted by JS987 View Post
                            It should be possible to compile bytecode to native executable or library during installation of application or library, but that library doesn't seem to target such case.
                            I'm sure I'm missing something but that seems trivial. Perhaps it's something they intend to add shortly?

                            Comment


                            • #15
                              Originally posted by JS987 View Post
                              Complete applications with libraries shouldn't be JIT compiled because they will suffer from same problems like Java ones - slow start-up, high memory usage.
                              Slower to start up the first time sure (assuming they're caching the binary), but High Memory consumption isn't going to happen. Excessive memory consumption is a language design issue related to things like how much metadata you're carrying around, whether the code is garbage collected or not, otherwise it's just pointer sizes and how much stuff is being optimized out... So no the memory consumption should be about the same as it is now not higher.

                              Comment

                              Working...
                              X