5 ms·

To exploit the advantages of the JVM. Can you imagine letting the jvm handle GC and JIT for you?

by chuhnk 15y ago

uriel 15y ago
Standard Go doesn't need JIT, it is all compiled to native code already.
justincormack 15y ago
Compiled Go is roughly the same performance as Java, so no I cant see a big win here. Sure there is some work needed on Go optimisation and GC.
- uriel 15y ago
  Also, there still plenty of low hanging fruit to optimize in Go, both in the compilers and GC, so surpassing Java wont be hard. And Go's memory usage is already magnitude orders better than Java.
  - lukesandberg 15y ago
    I think its somewhat naive to think that it won't be hard to surpass the JVM. The JVM is a highly tuned piece of software especially when it comes to GC i think it will probably take Go a while to surpass the JVM with respect to that, similarly for compilation though it is a little apples to oranges due to the JIT.
    - burgerbrain 15y ago
      A staticly typed language compiled to native code surpassing the JVM? That's not naive, that is commonplace... GC is the only sticky factor here.
      - lemming 15y ago
        No, it's not commonplace. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... Only 4 languages are faster than Java 6, two of which almost no-one uses. Java generally loses on memory use, but not on performance these days.
        burgerbrain 15y ago
        First off, I have personally seen, as justincormack describes, compiled Go as it currently exists being roughly comparable to Java, as it currently exists. I haven't burned much time looking around, but I was unable to find what version of Go they were using, or even what compiler for it (there are two major ones, with dramatic performance differences). Furthermore, it is a fact that Go at it's current maturity does little real optimization. Regardless of how "commonplace" languages beating Java may or may not be, Go should stand a very solid chance of doing it, provided it continues to see love. anyway, Java also loses handily on startup times, and only wins in runtime speeds against statically typed languages compiling to native code that lack the same tier of backing. Notice that one of the languages that beats Java is C++, possibly the single ugliest language in actual use. Practically a worse case scenario for a language developer but I don't think there has ever been a point in history which it doesn't cream Java. Hobbyist languages, which I would classify most of the languages on that list as (well, the ones that are even commonly compiled to native code in the first place...) will rarely compete with mature enterprise backed languages, but when you weight by funding, compiled languages clean house. Continued development of systems such as LLVM which blur the distinction between the two will only serve to improve the situation. aside: I find their Fortran statistic suspect as well. In my professional experience a well designed Fortran program will kick C's ass nearly every time. At least in scientific computing applications anyway.
        igouy 15y ago
        >>I don't think there has ever been a point in history which it [C++] doesn't cream Java<< Still waiting for that faster C++ fannkuch-redux program (and still waiting for a C fannkuch-redux program that uses multi core). http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... >>when you weight by funding<< Please show total $$$ amounts spent on the development of each programming language over the last several decades - so we can weight by funding. (Should funding for Plan 9 compilers be accounted as funding for Go? Should funding for GCC compilers be accounted as funding for GCCGO?) >>I find their Fortran statistic suspect as well ... At least in scientific computing...<< When you don't look, you won't find - http://shootout.alioth.debian.org/u64q/performance.php?test=nbody http://shootout.alioth.debian.org/u64q/performance.php?test=... http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u64q/performance.php?test=...
    - uriel 15y ago
      > I think its somewhat naive to think that it won't be hard to surpass the JVM. Go already surpasses the JVM in many areas, for example it has magnitude orders lower memory usage, and even in performance it already beats it in quite a few benchmarks, see: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u64/benchmark.php?test=all... And this is without the simple optimizations that are coming soon to Go, and even after that Go still will be able to improve performance greatly without too much effort.

To exploit the advantages of the JVM. Can you imagine letting the jvm handle GC and JIT for you?

by chuhnk 15y ago

To exploit the advantages of the JVM. Can you imagine letting the jvm handle GC and JIT for you?

uriel 15y ago

Standard Go doesn't need JIT, it is all compiled to native code already.

justincormack 15y ago

Compiled Go is roughly the same performance as Java, so no I cant see a big win here. Sure there is some work needed on Go optimisation and GC.

uriel 15y ago
Also, there still plenty of low hanging fruit to optimize in Go, both in the compilers and GC, so surpassing Java wont be hard. And Go's memory usage is already magnitude orders better than Java.
- lukesandberg 15y ago
  I think its somewhat naive to think that it won't be hard to surpass the JVM. The JVM is a highly tuned piece of software especially when it comes to GC i think it will probably take Go a while to surpass the JVM with respect to that, similarly for compilation though it is a little apples to oranges due to the JIT.
  - burgerbrain 15y ago
    A staticly typed language compiled to native code surpassing the JVM? That's not naive, that is commonplace... GC is the only sticky factor here.
    - lemming 15y ago
      No, it's not commonplace. http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... Only 4 languages are faster than Java 6, two of which almost no-one uses. Java generally loses on memory use, but not on performance these days.
      - burgerbrain 15y ago
        First off, I have personally seen, as justincormack describes, compiled Go as it currently exists being roughly comparable to Java, as it currently exists. I haven't burned much time looking around, but I was unable to find what version of Go they were using, or even what compiler for it (there are two major ones, with dramatic performance differences). Furthermore, it is a fact that Go at it's current maturity does little real optimization. Regardless of how "commonplace" languages beating Java may or may not be, Go should stand a very solid chance of doing it, provided it continues to see love. anyway, Java also loses handily on startup times, and only wins in runtime speeds against statically typed languages compiling to native code that lack the same tier of backing. Notice that one of the languages that beats Java is C++, possibly the single ugliest language in actual use. Practically a worse case scenario for a language developer but I don't think there has ever been a point in history which it doesn't cream Java. Hobbyist languages, which I would classify most of the languages on that list as (well, the ones that are even commonly compiled to native code in the first place...) will rarely compete with mature enterprise backed languages, but when you weight by funding, compiled languages clean house. Continued development of systems such as LLVM which blur the distinction between the two will only serve to improve the situation. aside: I find their Fortran statistic suspect as well. In my professional experience a well designed Fortran program will kick C's ass nearly every time. At least in scientific computing applications anyway.
        igouy 15y ago
        >>I don't think there has ever been a point in history which it [C++] doesn't cream Java<< Still waiting for that faster C++ fannkuch-redux program (and still waiting for a C fannkuch-redux program that uses multi core). http://shootout.alioth.debian.org/u64q/benchmark.php?test=fannkuchredux&lang=all http://shootout.alioth.debian.org/u64q/benchmark.php?test=fa... >>when you weight by funding<< Please show total $$$ amounts spent on the development of each programming language over the last several decades - so we can weight by funding. (Should funding for Plan 9 compilers be accounted as funding for Go? Should funding for GCC compilers be accounted as funding for GCCGO?) >>I find their Fortran statistic suspect as well ... At least in scientific computing...<< When you don't look, you won't find - http://shootout.alioth.debian.org/u64q/performance.php?test=nbody http://shootout.alioth.debian.org/u64q/performance.php?test=... http://shootout.alioth.debian.org/u64q/performance.php?test=spectralnorm http://shootout.alioth.debian.org/u64q/performance.php?test=...
  - uriel 15y ago
    > I think its somewhat naive to think that it won't be hard to surpass the JVM. Go already surpasses the JVM in many areas, for example it has magnitude orders lower memory usage, and even in performance it already beats it in quite a few benchmarks, see: http://shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=go&lang2=java http://shootout.alioth.debian.org/u64/benchmark.php?test=all... And this is without the simple optimizations that are coming soon to Go, and even after that Go still will be able to improve performance greatly without too much effort.