you could change the subject line to continue this discussion for other reasons, but for this particular work on plan 9, it's not worth getting into a discussion of aspects of belief in particular C implementations. (just to add a contrasting data point, at my previous employment we had examples of important scientific code on power where gcc compiled faster(!) and compiled vastly faster code than xlc, for instance.) it doesn't matter. it isn't relevant to this plan 9 project, so i think there's not much point in spending time on it here, at least once we've satisfactorily explained why it doesn't matter. compilers are programs. once you know or can guess what another program does that's clever in your case, you can do it too (subject perhaps to patents). in fact, you can often do it simpler and better because you can work out what really made the difference in the earlier case, or (better) deal with it at a higher level of abstraction.
improving qc/9c code on power/power64 is likely to happen in the course of this project, where needed to make the kernel and plan 9-specific applications run better. it probably isn't worth the effort (at least for the current project) to do that for arbitrary scientific code, and is certainly outside the scope of the agreed specification of the project. speaking of higher levels of abstraction: given some scientific code i've seen (before this, nothing to do with the things running on Blue Gene), i'd observe that fixing some of the algorithms used (which is compiler and platform independent activity) will often yield much bigger results than (say) compiling it with gcc, xlc, xlf, etc. you'd be amazed (or perhaps not) how naive some of the code can be. then there's the bigger question about which language to use to produce much faster code easily, and i'd hazard a moderately informed guess that C is not the language of choice for a lot of that. again, that's outside the scope of our project.
