5 ms·

That's impressive how much performance can be added by simple (uhh, really not at all) compiler optimizations. Is it a language's maximum performance? Don't thi

That's impressive how much performance can be added by simple (uhh, really not at all) compiler optimizations. Is it a language's maximum performance? Don't think so. Look at javascript (V8) vs Ruby/Python performance. Somehow almost equivalent languages now playing in different leagues - the only differenct in time & money sent for optimizations

jlouis 13y ago
Note that Go is a language where it is well known how to optimize large parts of the runtime. The language design is sane, especially for execution speed. Ruby and JS are very expressive languages, but their design in semantics make a lot of optimizations nontrivial to carry out. In essence you need to figure out type information at runtime and then use another JIT pass on the code to make it run fast. This is way more complex than what you can do in a simple Go compiler. Note that a rather unoptimizing Go compiler produces code way faster than V8 or a Ruby interpreter has ever produced. This is what you can expect once your language design has few trouble spots w.r.t. optimizations.
ConceitedCode 13y ago
It helps that Go is a relatively new language and the easier optimizations are getting taken care of. I doubt we will see this much of a performance gain from another 1.* release. There are definitely significant improvements to come, but I don't believe it will be this substantial.
- enneff 13y ago
  I wouldn't be so sure. The compiler is still very simple by modern standards.
- cloudwizard 13y ago
  Rob Pike said that he believed that they could get similar performance enhancements in the next release. He was talking at Google I/O fireside chat on Go.
  - vanderZwan 13y ago
    I do expect the "bottlenecks" in Go programs to have shifted a bit thought.
- talloaktrees 13y ago
  They are still working with low hanging fruit. Brad Fitzpatrick mentioned his optimization method was to run the profile, and pick the thing on the top to work on.
  - kisielk 13y ago
    Isn't that the standard way to decide what to optimize? There's often not much gain to be had if you are optimizing things that are not the bottleneck.
pjmlp 13y ago
This is why young generations should learn about compiler design and that language != implementation. Sure the language semantics may outlaw certain types of optimizations (e.g. aliasing), but in the end nothing forbids having compilers, interpreters or JIT implementations for a given language. The current generation tends to think strong typing, dynamic, or a GC enabled language, requires a VM. This is what I think it is positive about Go's designer decision of using a native compiler as canonical implementation, as it shows these youngsters there are other ways to implement languages.
- nly 13y ago
  Some language features do preclude some optimizations. For example, once you have dynamic typing you'll typically need a butt load of engineering effort to generate the fastest possible numerical computation. Now that people seem to want to do everything from crypto to image processing in Javascript, projects like JägerMonkey, v8 (method JITs) and asm.js have cropped up that show this is still an unsolved problem in many respects. One could easily make the case that Javascript is, in fact, becoming less and less suitable for the web.
  - pjmlp 13y ago
    > Some language features do preclude some optimizations True, that is why I mentioned the aliasing problem, but that doesn't forbid a specific type implementation. > Now that people seem to want to do everything from crypto to image processing in Javascript, projects like JägerMonkey, v8 (method JITs) and asm.js have cropped up that show this is still an unsolved problem in many respects. The funny thing is that advanced JIT engines like Hotspot were actually developed for dynamic languages (Self). The good thing about JIT research for JavaScript is that it helps advancing the status of compilers for dynamic languages, even for AOT compilation scenarios I would say.
tsewlliw 13y ago
I think JS is actually a radically simpler language than either Python or Ruby. Lua is a much closer comparison, and its certainly got a nice interpreter and JIT available.
- StavrosK 13y ago
  > I think JS is actually a radically simpler language than either Python or Ruby. Why do you think that?
  - pkroll 13y ago
    I'm not familiar with Python, but Ruby SEEMS a whole lot more complicated than JavaScript, in syntax and how you can manipulate code.
    - StavrosK 13y ago
      I probably agree with you, I was just wondering if there was some more concrete justification.

jlouis 13y ago

Note that Go is a language where it is well known how to optimize large parts of the runtime. The language design is sane, especially for execution speed. Ruby and JS are very expressive languages, but their design in semantics make a lot of optimizations nontrivial to carry out. In essence you need to figure out type information at runtime and then use another JIT pass on the code to make it run fast. This is way more complex than what you can do in a simple Go compiler. Note that a rather unoptimizing Go compiler produces code way faster than V8 or a Ruby interpreter has ever produced. This is what you can expect once your language design has few trouble spots w.r.t. optimizations.

ConceitedCode 13y ago

It helps that Go is a relatively new language and the easier optimizations are getting taken care of. I doubt we will see this much of a performance gain from another 1.* release. There are definitely significant improvements to come, but I don't believe it will be this substantial.

enneff 13y ago
I wouldn't be so sure. The compiler is still very simple by modern standards.
cloudwizard 13y ago
Rob Pike said that he believed that they could get similar performance enhancements in the next release. He was talking at Google I/O fireside chat on Go.
- vanderZwan 13y ago
  I do expect the "bottlenecks" in Go programs to have shifted a bit thought.
talloaktrees 13y ago
They are still working with low hanging fruit. Brad Fitzpatrick mentioned his optimization method was to run the profile, and pick the thing on the top to work on.
- kisielk 13y ago
  Isn't that the standard way to decide what to optimize? There's often not much gain to be had if you are optimizing things that are not the bottleneck.

pjmlp 13y ago

This is why young generations should learn about compiler design and that language != implementation. Sure the language semantics may outlaw certain types of optimizations (e.g. aliasing), but in the end nothing forbids having compilers, interpreters or JIT implementations for a given language. The current generation tends to think strong typing, dynamic, or a GC enabled language, requires a VM. This is what I think it is positive about Go's designer decision of using a native compiler as canonical implementation, as it shows these youngsters there are other ways to implement languages.

nly 13y ago
Some language features do preclude some optimizations. For example, once you have dynamic typing you'll typically need a butt load of engineering effort to generate the fastest possible numerical computation. Now that people seem to want to do everything from crypto to image processing in Javascript, projects like JägerMonkey, v8 (method JITs) and asm.js have cropped up that show this is still an unsolved problem in many respects. One could easily make the case that Javascript is, in fact, becoming less and less suitable for the web.
- pjmlp 13y ago
  > Some language features do preclude some optimizations True, that is why I mentioned the aliasing problem, but that doesn't forbid a specific type implementation. > Now that people seem to want to do everything from crypto to image processing in Javascript, projects like JägerMonkey, v8 (method JITs) and asm.js have cropped up that show this is still an unsolved problem in many respects. The funny thing is that advanced JIT engines like Hotspot were actually developed for dynamic languages (Self). The good thing about JIT research for JavaScript is that it helps advancing the status of compilers for dynamic languages, even for AOT compilation scenarios I would say.

tsewlliw 13y ago

I think JS is actually a radically simpler language than either Python or Ruby. Lua is a much closer comparison, and its certainly got a nice interpreter and JIT available.

StavrosK 13y ago
> I think JS is actually a radically simpler language than either Python or Ruby. Why do you think that?
- pkroll 13y ago
  I'm not familiar with Python, but Ruby SEEMS a whole lot more complicated than JavaScript, in syntax and how you can manipulate code.
  - StavrosK 13y ago
    I probably agree with you, I was just wondering if there was some more concrete justification.