This is a very interesting at a time when we're seeing what we can replace C++ with. (yes, rusticles, I know rust exists)
I think go is mostly used to replace Python and Java & co.
And yet, it's worse than both.
The Go Compiler Needs to Be Smarter
51–60 of 119 posts
Re: The Go Compiler Needs to Be Smarter
#52Earlier quoted context omitted.
> Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't existed among actual C implementations (outside of maybe Plan 9) for decades now. It's yet more suckless idiocy Have you considered that this Go opinion might not be “idiocy” but desirable qualities in some use cases? It seems quite inappropriate to bash on Go for realising a vision that solves such a use case, in turn…
> Ruby or Python for for having a very dynamic object model and method calling/message passing, witch results in non-optimisable call paths because they have to be resolved every single time. The Ruby implementations don't really do that. They use "inline caches" so this lookup normally only happens once per call-site.
If there's only one backing type being looked up. If there's more than one, the inline cache thrashs like they're saying.
Re: The Go Compiler Needs to Be Smarter
#53Earlier quoted context omitted.
But can't the compiler work that bit out? Source code is for humans. Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" and then let the compiler observe "var x is only used twice, so let's optimize that lifetime..."
> Source code is for humans The reason why making the scope as local as possible is important is for humans , not compilers. > Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" Why would humans care about how much scratch space is needed? That's for the compiler to know.
> Why would humans care about how much scratch space is needed?
In some contexts, it's important. For instance, each thread within the Linux kernel has a very limited fixed-size stack space (used to be 4K bytes, IIRC it's been increased to 8K and then 16K), which resides in physical memory (cannot be swapped out or lazily allocated). Avoiding large stack frames is necessary.
Re: The Go Compiler Needs to Be Smarter
#54Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…
Indeed. My impression was that go was meant not to "produce the quickest code" but to "produce the code the quickest". The compile speed is one huge use case.
Re: The Go Compiler Needs to Be Smarter
#55Earlier quoted context omitted.
> Source code is for humans The reason why making the scope as local as possible is important is for humans , not compilers. > Put all the vars at the top to tell the humans "here's all the scratch space I'll be needing in this block" Why would humans care about how much scratch space is needed? That's for the compiler to know.
> Why would humans care about how much scratch space is needed? In some contexts, it's important. For instance, each thread within the Linux kernel has a very limited fixed-size stack space (used to be 4K bytes, IIRC it's been increased to 8K and then 16K), which resides in physical memory (cannot be swapped out or lazily allocated). Avoiding large stack frames is necessary.
1. That's a rare use case
2. There are ways of measuring that without hampering readability. I mean, are programmers supposed to add all the variables' sizes up in their head??
Re: The Go Compiler Needs to Be Smarter
#56Earlier quoted context omitted.
> Ruby or Python for for having a very dynamic object model and method calling/message passing, witch results in non-optimisable call paths because they have to be resolved every single time. The Ruby implementations don't really do that. They use "inline caches" so this lookup normally only happens once per call-site.
If there's only one backing type being looked up. If there's more than one, the inline cache thrashs like they're saying.
JRuby has had polymorphic inline caches for like a decade and CRuby will actually cache multiple types in the method cache as long as they cache the same method since https://github.com/ruby/ruby/pull/2583
Re: The Go Compiler Needs to Be Smarter
#57Go mostly has been only picking up easy wins so far. I haven't seen any attempt to go further than that. Which is fair strategy for first few years since everything comes with a cost. But, people now expect to see more obviously specially the more it's being compared to more sophisticated languages and compilers.
> But, people now expect to see more obviously [..] I don't. I mean, yay for improvements, but it's already working great for my usecases.
What are your usecases, if you don't mind me asking? I am considering replacing our HTTP-heavy processes currently written in C++ with Go. However, after reading this thread I'm not so sure. Compilation time isn't that big of an issue for us, but having a simpler way of doing networking would be a win. I can't tell if that ease of use would be trumped by poor performance.
Re: The Go Compiler Needs to Be Smarter
#58Earlier quoted context omitted.
That seems rather unwarranted attempt at vilification of the language, worded in an odd way: if something sucks, it's bad, so suckless would actually be positive? But why? What's Go done to you? A few if err != nil { ... } statements too many?
Look up suckless. It has a specific meaning and history.
Right, but OC still called it "suckless idiocy"...
Also not sure how Go sacrifices utility and friendliness to end-users...
Re: The Go Compiler Needs to Be Smarter
#59Sure, if your goal is to build a compiler that outputs the fastest possible code. If your goal is to apply the "principle of least surprise" to the generated machine code, then that eliminates or constrains most interesting optimizations, including procedure inlining, dead code elision, and compile-time evaluation. Go is a "principle of least surprise" language, based on a vision of simplicity for C that hasn't exist…
For the popcnt example, I think that, if a compiler takes it upon itself to detect, at runtime, whether the CPU supports it, it also should make sure it does so reasonably efficiently. After all, the reason this was added must have been because it’s faster than a hand-coded version.
The alternative of doing neither would be fine to, and could better fit that “principle of least surprise”, but, of course, also would leave more low-level work to do for go programmers.
Re: The Go Compiler Needs to Be Smarter
#60> In less fanciful languages like C or C++, the programmer needs to check what the processor supports themselves.
I think by now most C++ compilers can target multiple combinations of feature flags and select a supported code path during program startup. The Intel compiler could do it years ago, but the resulting code was crippled on AMD CPUs.