From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <d6b99e23c34adcc6cc3697f97342c10c@terzarima.net>
To: 9fans@9fans.net
From: Charles Forsyth <forsyth@terzarima.net>
Date: Thu, 31 Jul 2008 23:03:19 +0100
In-Reply-To: <5226573422c5744e5de8f3b806169834@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] Plan 9 on Blue Gene
Topicbox-Message-UUID: f940a5bc-ead3-11e9-9d60-3106f5b1d025

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.