4 ms·

Cool stuff. It's nice to have a somewhat mainstream language using its own backend instead of llvm. You can in fact get pretty far by tailoring your compiler to

by obl 8y ago

Cool stuff. It's nice to have a somewhat mainstream language using its own backend instead of llvm. You can in fact get pretty far by tailoring your compiler to your specific needs. You end up with much less code, it's also easier to make it fast. You do cut yourself of from the more advanced optimizations simply for man-hour reasons. I'm guessing it's a trade off they are willing to make. I have to say that I really dislike the kind of large pattern matching they added for the hash table clear. C compilers do that as well for e.g. memset/copy or bit rotate instructions. IME it's really brittle and would be more beneficial as some kind of a lint ("you could replace this bunch of code by a call to clear()"). It makes the code simpler and won't inexplicably slow down next time someone does a tautological refactoring.

bcaa7f3a8bbc 8y ago
Note: Go has a GCC implementation which is actively maintained. I've seen some computational-intensive code received a ~10% performance boost thanks to the heavy wizardry of code generation in GCC in past years (but, see also: masklinn's comments). Once gccgo implements Go 1.11, it may be a good idea to run the benchmark and get some new numbers.
- mseepgood 8y ago
  > Note: Go has a GCC implementation which is actively maintained. They are also actively working on a third, llvm based implementation: https://go.googlesource.com/gollvm/ https://go.googlesource.com/gollvm/
dilap 8y ago
Go actually doesn't have any other way to clear a map!
- tedeh 8y ago
  ... but they made one (runtime only) for that particular use case if I understood the slides correctly, and that is the optimization.
  - dilap 8y ago
    yep, that's right. but it's not accessible to user code, so this isn't something that could be handled by a linter (as suggested by GP). i'm actually happy with the situation. there is literally only one way to clear a map, and it is fast.
- stcredzero 8y ago
  Go actually doesn't have any other way to clear a map! Which, actually, is brilliant design! Now, I can find all map clearings with one operation. (I need to implement that syntactic search/rewrite tool I miss from Smalltalk.)
  - apta 8y ago
    How is not having map.clear() a brilliant design?
    - stcredzero 8y ago
      In a large project, you'll have all ways of doing any given thing represented in a code base. Reducing that number down to 1 means that searching for all occurrences is reduced to 1 operation. If you are working on a large project, searching for usages/senders/occurrences is one of the most common tasks that you do. In fact, using escape analysis of the same kind used for "Extract Method" refactorings, you can even catch clearing interspersed with other code in the for-range loop. A 50%+ reduction in programmer work is nothing to be sneezed at.
bitwize 8y ago
No. They should have used LLVM. Go is a crippled language because it lacks generics and generalized higher-order types. The stated reasons for this are to make the compiler easier to implement. Maybe they wouldn't have had such implementation difficulties if they had just gone with the compiler backend the industry has standardized on, freeing up developer resources to make Go a language suitable for big development tasks and competitive with C++, C#, etc.
- cdoxsey 8y ago
  Generics are a design problem not an implementation problem. If folks agreed on a design finding resources to get them added wouldn't be hard. Not sure what you're trying to imply with your last sentence, but Go is used by many companies large and small for big development tasks. I work for a company where most of the backend systems are written in Go.
- ovao 8y ago
  That's not an accurate summary of the reasoning. It's not just the complexity it adds to the compiler, but to the type system in general, and to the complexity it may bring to user code. The Go team is not against adding generics, and there have been proposals for them. They have simply not landed on a proposal that they feel is a strong fit for the language.

by obl 8y ago

bcaa7f3a8bbc 8y ago

Note: Go has a GCC implementation which is actively maintained. I've seen some computational-intensive code received a ~10% performance boost thanks to the heavy wizardry of code generation in GCC in past years (but, see also: masklinn's comments). Once gccgo implements Go 1.11, it may be a good idea to run the benchmark and get some new numbers.

mseepgood 8y ago
> Note: Go has a GCC implementation which is actively maintained. They are also actively working on a third, llvm based implementation: https://go.googlesource.com/gollvm/ https://go.googlesource.com/gollvm/

dilap 8y ago

Go actually doesn't have any other way to clear a map!

tedeh 8y ago
... but they made one (runtime only) for that particular use case if I understood the slides correctly, and that is the optimization.
- dilap 8y ago
  yep, that's right. but it's not accessible to user code, so this isn't something that could be handled by a linter (as suggested by GP). i'm actually happy with the situation. there is literally only one way to clear a map, and it is fast.
stcredzero 8y ago
Go actually doesn't have any other way to clear a map! Which, actually, is brilliant design! Now, I can find all map clearings with one operation. (I need to implement that syntactic search/rewrite tool I miss from Smalltalk.)
- apta 8y ago
  How is not having map.clear() a brilliant design?
  - stcredzero 8y ago
    In a large project, you'll have all ways of doing any given thing represented in a code base. Reducing that number down to 1 means that searching for all occurrences is reduced to 1 operation. If you are working on a large project, searching for usages/senders/occurrences is one of the most common tasks that you do. In fact, using escape analysis of the same kind used for "Extract Method" refactorings, you can even catch clearing interspersed with other code in the for-range loop. A 50%+ reduction in programmer work is nothing to be sneezed at.

bitwize 8y ago

No. They should have used LLVM. Go is a crippled language because it lacks generics and generalized higher-order types. The stated reasons for this are to make the compiler easier to implement. Maybe they wouldn't have had such implementation difficulties if they had just gone with the compiler backend the industry has standardized on, freeing up developer resources to make Go a language suitable for big development tasks and competitive with C++, C#, etc.

cdoxsey 8y ago
Generics are a design problem not an implementation problem. If folks agreed on a design finding resources to get them added wouldn't be hard. Not sure what you're trying to imply with your last sentence, but Go is used by many companies large and small for big development tasks. I work for a company where most of the backend systems are written in Go.
ovao 8y ago
That's not an accurate summary of the reasoning. It's not just the complexity it adds to the compiler, but to the type system in general, and to the complexity it may bring to user code. The Go team is not against adding generics, and there have been proposals for them. They have simply not landed on a proposal that they feel is a strong fit for the language.