4 ms·
> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out. Be more specific.
by Dewie3 11y ago
> I think there is a bunch of bloat in software compilation which the plan9/Go people were wise to stamp out.
Be more specific.
- andrewchambers 11y agolinux kernel takes 20 minutes to build on my workstation, a plan9 kernel takes something tiny like 60 seconds on a raspberry pi. This is due to a few reasons. 1. Plan9 C does not allow headers to include more headers, this speeds up compilation, as there is far less useless preprocessor churn. 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. 3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on. The whole Go compiler builds from source for me before the gcc configure script has completed.
- Dewie3 11y ago1) seems like a language fault and not a compiler fault. 2) heavy optimisation is not "bloat". 3) "seems like bloat" is a too vague argument. Fine enough point about them supposedly not removing useless features.
- deleted 11y ago[deleted]
- pcwalton 11y ago> 2. Plan9 C/Go does not do heavy optimisation, but does a decent job. That's not good enough for Rust. > 3. The system has less code overall, something like 1 million lines of code for something like gcc seems like bloat to me, They don't remove useless features and dated features as fast as they pile it on. Those GCC optimizations matter. You simply cannot get away with competitive performance with an AST-to-assembly plus peephole optimizations on the assembly anymore. SROA, SCCP, loop invariant code motion, algebraic identities, vectorization, aggressive alias analysis, etc. are all very important.
- andrewchambers 11y agoImo compilers should only optimize specific functions which are known to be a code hotspot.
- Dewie3 11y agoWell in that case... if you consider optimizing non-hotspots as "bloat"(?) then you are coming at this from a whole other viewpoint than most of us who have embraced optimizing compilers. :-)
- pcwalton 11y agoThat will result in very poorly-performing code. I liked DannyBee's quote (paraphrased): "Most applications have flat profiles. They have flat profiles because people have spent a lot of time optimizing them."
- andrewchambers 11y agoThere are times squeezing every last bit of performance is great. I am saying is in general there is no need to run -O3 on a 500 line function which is run once at initialization compared to a compute kernel. Our compilers and languages don't have the granularity to specify this currently. I do want more specialized optimization tools however. Things like automatic super optimizers [1] which can be targeted by programmers with special directives. [1] http://theory.stanford.edu/~sbansal/superoptimizer.html http://theory.stanford.edu/~sbansal/superoptimizer.html
- e12e 11y agoAccording to a quick google search, both gcc, clang and msvc allow turning off/on optimizations at a function level, via #pragma/attributes?
- andrewchambers 11y agointeresting!