4 ms·
I'm excited about generics that gives you a tradeoff between monomorphization and "everything is a pointer". The "everything is a pointer" approach, like Haskel
by klodolph 5y ago
I'm excited about generics that gives you a tradeoff between monomorphization and "everything is a pointer". The "everything is a pointer" approach, like Haskell, is incredibly inefficient wrt execution time and memory usage, the "monomorphize everything" approach can explode your code size surprisingly fast.
I wouldn't be surprised if we get some control over monomorphization down the line, but if Go started with the monomorphization approach, it would be impossible to back out of it because it would cause performance regressions. Starting with the shape stenciling approach means that introducing monomorphization later can give you a performance improvement.
I'm not trying to predict whether we'll get monomorphization at some future point in Go, but I'm just saying that at least the door is open.
- zozbot234 5y agoYes, they seem to have shipped a MVP first, which is a sensible approach. Controlling the extent of monomorphization requires changes in how the code is written, so if they had offered that exclusively it would've been a pitfall to existing users. By boxing everything, they keep their MVP closer to the previously idiomatic interface{} pattern.
- qznc 5y agoA hybrid approach would be monomorphization for native types like int and pointers for records. C# is doing that if I remember correctly.
- Ar-Curunir 5y agoIMO that's a bad trade-off for many performance-sensitive applications, since it means that you can't rely on newtypes and structs for correctness.
- tines 5y agoHaskell does monomorphization as well. See https://reasonablypolymorphic.com/blog/specialization/ https://reasonablypolymorphic.com/blog/specialization/
- SomeCallMeTim 5y ago> "monomorphize everything" approach can explode your code size surprisingly fast. It can in the naive implementation. Early C++ was famous for code bloat and (apparently) hasn't shaken that outdated impression. In practice, monomorphization of templates hasn't been a serious issue in C++ for a long time. The compiler and linker technologies have advanced significantly.
- asdfasgasdgasdg 5y ago> Early C++ was famous for code bloat and (apparently) hasn't shaken that outdated impression. It's not an outdated impression. C++ generics can and do interact very poorly with inlining and other language features to cause extremely large binary sizes, especially if you do anything complex inside them. They also harm compilation performance since each copy of the generic code needs to be optimized. Generics in C++ are reasonably efficient when there is relatively little code generated per generic, but when this is not true, they can be a problem.
- titzer 5y ago> The compiler and linker technologies have advanced significantly. AFAICT the linker de-duplicates identical pieces of machine code. You still can get multi-megabyte object files for every source file. I used to work on V8. Almost every .o is 3+MB. Times hundreds, plus bigger ones, it's more than a gigabyte of object files for a single build. That's absurd. Not V8's fault--stupid C++ compilation and linking model.
- rowanG077 5y agoWhy is a speed part of the Go language contract but footprint of the executable is not? I, for one, would be quite miffed if an update of the Go compiler would mean an application would no longer fit on my mcu. That is worse then the application running slower.
- gbear605 5y agoIdeally it could be a compiler flag. Even more ideally, you could tell your compiler what the max size you want is and then it would optimize for the best speed at a given executable footprint.
- masklinn 5y ago> Why is a speed part of the Go language contract but footprint of the executable is not? Because footprint of the executable has pretty literally never been, Go has always had deficient DCE and generated huge executables.
- rowanG077 5y agoIt also generates pretty slow executables. That doesn't invalidate the point.