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.
> 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.
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.
> 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.
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.)
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.
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.)
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.
A blog post talking about why to use Go...for performance...and here is how it is better than Java about performance, even though it's not really better than Java. I don't care about Java, my language of choice is C#, but this smacks of the worst kind of anti-logic promotion. It seems to be quite endemic in the Go community also.
Again, is this a deliberate troll, or is it intellectual sloppiness? The post talks about why Go is fast. There are memory footprint comparisons. AFAICT, There are no language speed comparisons.
There is only text that a genuinely touchy and defensive person or a troll might misconstrue. Did someone steal seanmcdirmid's HN password?
If one talks about why Go is fast, and then compares techniques against other languages ANYWAYS, what the heck is the reader supposed to think? In an academic paper, this would be torpedoed right away: you aren't allowed to take the 5th if you want to beg the question.
If one talks about why Go is fast, and then compares techniques against other languages ANYWAYS, what the heck is the reader supposed to think?
That a short discussion of language feature implementation techniques is provided as a point of comparison with regards to different types of overheads?
In an academic paper, this would be torpedoed right away
Well, since I read "this" in the context of this sentence as an assertion imagined by you and unsupported by facts, then yes, you are obviously right. That would be torpedoed. Note that it's not a product of who you thought it was.
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.