4 ms·

Escape analysis, dead code elimination, and function inlining are standard optimizations taught in an undergraduate compilers course. Go is cool, but I wouldn't

by hendzen 12y ago

Escape analysis, dead code elimination, and function inlining are standard optimizations taught in an undergraduate compilers course. Go is cool, but I wouldn't really cite those as justifications for why.

Nitramp 12y ago
Yes for dead code elimination and function inlining, not so sure about escape analysis. The author acknowledges that, but there's a detail in Go: it does the function inlining at compile time (unlike e.g. Java JITs), but still manages to inline across compilation units (unlike C++, modulo LTO). That's nice, and presumably what he wanted to point out. It's also nice that in Go, these things are very straight forward due to the overall simplicity of the system (unlike C++). The dead code elimination is just a supporting fact for why that's useful, and again works across compilation boundaries. I'm not sure about your assertion of escape analysis, at least Java JITs only learned that trick as of lately, and are still pretty bad at it. C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. This is an interesting pattern in Go, the longer one looks at it, the more you understand that it's a whole bunch of good decisions in various subsystems coming together.
- seanmcdirmid 12y ago
  > at least Java JITs only learned that trick as of lately, and are still pretty bad at it. Did the author claim that Go was faster than Java? As far as I can tell, the JITs are still kicking the Go compiler's butt on "effectiveness." > C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. Is the author really trying to explain why Go is faster than C++? > This is an interesting pattern in Go, the longer one looks at it, the more you understand that it's a whole bunch of good decisions in various subsystems coming together. One cannot validate these patterns yet because Go is still slower than the languages it supposedly innovates on in performance techniques.
  - stcredzero 12y ago
    Go is almost as fast as Java. Which is to say Go is respectably fast. They should get kudos in the language developer man hours metric. Considering how new they are, how few people have worked on the language, and the results achieved, the result can be counted as an accomplishment. It's a small and elegant way to achieve a particular pragmatic result. That always deserves respect in my book. (The JVM deserves it too for slightly different reasons.)
    - seanmcdirmid 12y ago
      There is a difference between gold stars and empirical results. Go is fine enough as a language, but it can't claim any performance crowns, you can't describe how go is faster than Java when it's not.
      - stcredzero 12y ago
        Go is fine enough as a language, but it can't claim any performance crowns, you can't describe how go is faster than Java when it's not. Did I miss something in the reading? I didn't see the claim that Go is faster than Java. Speed isn't everything, and the rabble that don't have the wherewithal to know that and that Java is quite a fast managed language don't matter. Take it from an old Smalltalker. (Who remembers the days when Smalltalk VMs were kicking the JVM's butt, but people still thought it was 1985.)
        seanmcdirmid 12y ago
        That is the weird part of the essay...they talk about why Go is faster than Java, without mentioning that it really isn't.
        stcredzero 12y ago
        [Citation Needed] Just re-read it. Again, I didn't see anyplace where it's actually said that Go is faster than Java. I can see many places where someone touchy and defensive might take it that way, however. Either the apparent knee-jerk reaction is a deliberate attempt to troll by creating a false argument, or it's simply a cringe worthy false argument worthy of a Picard meme.
- pcwalton 12y ago
  >　C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. Sure it is. Why not? C++ compilers don't usually do this because it doesn't help much—explicit memory management encourages people to not allocate unless necessary in the first place.
  - deleted 12y ago
    [deleted]
  - Nitramp 12y ago
    > Sure it is. Why not? Do you have a reference for that? I'd expect this to be hard, at linking time you no longer have the C++ source, so it's much harder to make such decisions.
    - pcwalton 12y ago
      You don't need the C++ source, just the IR. LLVM already removes mallocs if they are unused: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033017.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033017....
4ad 12y ago
This article explains a few reasons why Go is fast. This article doesn't claim it uses compiler optimization technology unavailable to other languages, nor does it claim it does anything novel. Go is fast, and this article makes a pretty good job explaining why. It makes no judgement on other languages, and all comparisons with other languages are only done to exemplify a particular feature of the Go implementation. This article also doesn't do any Go advocacy, it doesn't claim Go is superior to other languages because of these reasons, it just offers an explanation for some observed performance characteristics to anyone who is interested. Don't attack the article on what it is not. I also think out it's very dishonest to single out a few things form the article which you say don't matter (because they are "standard"), ignoring the most important bits. Go's real-world performance comes from it's value semantics. Yes, Java has one of the best JITs in the world, yet the very-unoptimized Go compiler blows it in real-life code just because of this.
- seanmcdirmid 12y ago
  The article is dishonest or uninformed, it is doing shady things like comparing boxed primitives in Java to unboxed primitives in Go, when Go has boxing and Java has unbowed primitives as well, what!? Like this crap: > Similar to Go, the Java int type consumes 4 bytes of memory to store this value. However, to use this value in a collection like a List or Map, the compiler must convert it into an Integer object. ... > So an integer in Java frequently looks more like this and consumes between 16 and 24 bytes of memory. > This is a Location type which holds the location of some object in three dimensional space. It is written in Go, so each Location consumes exactly 24 bytes of storage. We can use this type to construct an array type of 1,000 Locations, which consumes exactly 24,000 bytes of memory. You could have constructed an array of 3,000 ints in Java also for 24,000 + a header bytes of memory. Go has been around for 4+ years now. There compiler implementation is relatively behind where Java was at around 2000, but perhaps google isn't throwing that many resources at it....or dynamic adaptive compilation really does have an intrinsic advantage. Who knows...

by hendzen 12y ago

Nitramp 12y ago

Yes for dead code elimination and function inlining, not so sure about escape analysis. The author acknowledges that, but there's a detail in Go: it does the function inlining at compile time (unlike e.g. Java JITs), but still manages to inline across compilation units (unlike C++, modulo LTO). That's nice, and presumably what he wanted to point out. It's also nice that in Go, these things are very straight forward due to the overall simplicity of the system (unlike C++). The dead code elimination is just a supporting fact for why that's useful, and again works across compilation boundaries. I'm not sure about your assertion of escape analysis, at least Java JITs only learned that trick as of lately, and are still pretty bad at it. C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. This is an interesting pattern in Go, the longer one looks at it, the more you understand that it's a whole bunch of good decisions in various subsystems coming together.

seanmcdirmid 12y ago
> at least Java JITs only learned that trick as of lately, and are still pretty bad at it. Did the author claim that Go was faster than Java? As far as I can tell, the JITs are still kicking the Go compiler's butt on "effectiveness." > C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. Is the author really trying to explain why Go is faster than C++? > This is an interesting pattern in Go, the longer one looks at it, the more you understand that it's a whole bunch of good decisions in various subsystems coming together. One cannot validate these patterns yet because Go is still slower than the languages it supposedly innovates on in performance techniques.
- stcredzero 12y ago
  Go is almost as fast as Java. Which is to say Go is respectably fast. They should get kudos in the language developer man hours metric. Considering how new they are, how few people have worked on the language, and the results achieved, the result can be counted as an accomplishment. It's a small and elegant way to achieve a particular pragmatic result. That always deserves respect in my book. (The JVM deserves it too for slightly different reasons.)
  - seanmcdirmid 12y ago
    There is a difference between gold stars and empirical results. Go is fine enough as a language, but it can't claim any performance crowns, you can't describe how go is faster than Java when it's not.
    - stcredzero 12y ago
      Go is fine enough as a language, but it can't claim any performance crowns, you can't describe how go is faster than Java when it's not. Did I miss something in the reading? I didn't see the claim that Go is faster than Java. Speed isn't everything, and the rabble that don't have the wherewithal to know that and that Java is quite a fast managed language don't matter. Take it from an old Smalltalker. (Who remembers the days when Smalltalk VMs were kicking the JVM's butt, but people still thought it was 1985.)
      - seanmcdirmid 12y ago
        That is the weird part of the essay...they talk about why Go is faster than Java, without mentioning that it really isn't.
        stcredzero 12y ago
        [Citation Needed] Just re-read it. Again, I didn't see anyplace where it's actually said that Go is faster than Java. I can see many places where someone touchy and defensive might take it that way, however. Either the apparent knee-jerk reaction is a deliberate attempt to troll by creating a false argument, or it's simply a cringe worthy false argument worthy of a Picard meme.
pcwalton 12y ago
>　C++ again suffers from cross-compilation unit visibility; even if your LTO can detect an inlineable call, its AFAIK not possible at that time to move heap allocations to the stack. Sure it is. Why not? C++ compilers don't usually do this because it doesn't help much—explicit memory management encourages people to not allocate unless necessary in the first place.
- deleted 12y ago
  [deleted]
- Nitramp 12y ago
  > Sure it is. Why not? Do you have a reference for that? I'd expect this to be hard, at linking time you no longer have the C++ source, so it's much harder to make such decisions.
  - pcwalton 12y ago
    You don't need the C++ source, just the IR. LLVM already removes mallocs if they are unused: http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033017.html http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-July/033017....

4ad 12y ago

This article explains a few reasons why Go is fast. This article doesn't claim it uses compiler optimization technology unavailable to other languages, nor does it claim it does anything novel. Go is fast, and this article makes a pretty good job explaining why. It makes no judgement on other languages, and all comparisons with other languages are only done to exemplify a particular feature of the Go implementation. This article also doesn't do any Go advocacy, it doesn't claim Go is superior to other languages because of these reasons, it just offers an explanation for some observed performance characteristics to anyone who is interested. Don't attack the article on what it is not. I also think out it's very dishonest to single out a few things form the article which you say don't matter (because they are "standard"), ignoring the most important bits. Go's real-world performance comes from it's value semantics. Yes, Java has one of the best JITs in the world, yet the very-unoptimized Go compiler blows it in real-life code just because of this.

seanmcdirmid 12y ago
The article is dishonest or uninformed, it is doing shady things like comparing boxed primitives in Java to unboxed primitives in Go, when Go has boxing and Java has unbowed primitives as well, what!? Like this crap: > Similar to Go, the Java int type consumes 4 bytes of memory to store this value. However, to use this value in a collection like a List or Map, the compiler must convert it into an Integer object. ... > So an integer in Java frequently looks more like this and consumes between 16 and 24 bytes of memory. > This is a Location type which holds the location of some object in three dimensional space. It is written in Go, so each Location consumes exactly 24 bytes of storage. We can use this type to construct an array type of 1,000 Locations, which consumes exactly 24,000 bytes of memory. You could have constructed an array of 3,000 ints in Java also for 24,000 + a header bytes of memory. Go has been around for 4+ years now. There compiler implementation is relatively behind where Java was at around 2000, but perhaps google isn't throwing that many resources at it....or dynamic adaptive compilation really does have an intrinsic advantage. Who knows...