|
But on the overall, based of the documents and information provided here, and what I think I managed to understand about them: it is not surprising some want to start the deprecation of C from RVA (some would even start its deprecation from the core specs to free some machine instruction encoding space). It is a bit like compilers: 90% of the complexity/size is for 30% of the code optimization speed gain, which has mostly a significant and pertinent impact in specific work loads on our modern hardware. Basically it is "better" (since you get rid of 90% of the complexity/size of compilers) to combine pure assembly coding with less complex/bigger compilers ("10%") (and look at dav[12]d, not to mention ffmpeg, here the main issue is feature creep of ISO C new things and GCC extensions... and abuse of the nasm pre-preprocessor). For instance, with bzip2, with cproc/qbe (zero assembly though), I get 70% of the speed of modern gcc/clang. But what's really worrying: I talked (I think it was here on HN a long time ago) to one of TheHeavyThing assembly coders, and he said that with a brutal and naive hand-compilation of the corresponding C code, he got 15-20% faster than the best compiler could provide at the time on gzip compression. Something is up here, and I already did mention dav[1]d and ffmpeg. We are in a 101 case of 'compromise', and here, it seems the more I read about it the more I think we are facing a case of 'benefits are not worth it in the end', well the apparent 'competent' people who are in the sauce seems to agree more and more about it, through the infos I have been getting from HN. As for the 'compilation' benchmarks provided here, we know gcc/clang are heavily x86-64 oriented, namely goes into optimizations which should favor 'C' like machine instructions (destination register same than some source register), so the 1-2% "real" speed increase from some documents provided here sounds more like the real neutral/overall thing to me. |