Article View: comp.unix.cray
Article #324Re: Compilation of gcc/g++ on ymp-el?
From: James W. Adams
Date: Tue, 27 Jun 1995 00:00
Date: Tue, 27 Jun 1995 00:00
46 lines
2932 bytes
2932 bytes
In article <3selil$hpf@fly.HiWAAY.net>,
Mark Justin Cecil <mjc@nuance.com> wrote:
>toby@hobbes.nas.nasa.gov (Toby E. Harness) writes:
>
>>mjc@nuance.com (Mark Justin Cecil) writes:
>>;
>>; No one I know of has ever compiled gcc on a Cray of any type.
>>;
>>; We have been over this a hundred times... Unless you just want
>>; to use the preprocessor only, porting GCC is pointless. The Cray
>>; folks have spent a LOT of time and money building a really good
>>; C compiler, and I have doubts as to whether the UNIX/GNU community
>>; could ever put in enough time to approach its effectiveness.
>
>>hmmm, I don't know about that. I'd wager SUN has put more hours into their
>>C compiler than CRI into theirs, and gcc out-performs SUN's. ('Course,
>>there is much more interest in SUNs in the "UNIX/GNU community" than in
>>CRI systems.) But, whatever ...
>
>I'd bet not. But, regardless of the time spent, you won't find a group
>of people that understand how to compile fast code on a Cray better than the
>compilers people at Cray.
With this sort of argument by authority, we should all be using IBM
mainframes. Seriously, on at least one PVP machine (CONVEX C38xx) on
which both GCC and CONVEX C are available, GCC outperforms CONVEX C on
certain types of highly scalar code segments, and can be used to
advantage when profile-optimizing some codes. The reasons have less to
do with compiler designers understanding how to exploit the architecture
than with the tradeoffs inherent in optimization for vector
architectures, together with the somewhat more conservative approach to
optimization required to assure numerical accuracy when compiling
dusty-deck codes. There are cases where the more aggressive, riskier
optimizations of GCC are acceptable, and may provide a useful
alternative to hand-coded assembly language, if used with due caution.
Having a variety of tools from which to choose is almost always an
advantage, even where one may clearly be superior in most cases.
--
James W. Adams Medical Center Computing
Box 512, HSC jwa2n@virginia.edu
University of Virginia
Charlottesville, VA 22908
Technical Details
Message-ID:
<DAupv2.H8n@murdoch.acc.Virginia.EDU>Path:
arc1-ca.pugleaf.net!unknown!not-for-mailReferences:
<3scf6b$h4g@news.duke.edu> <3sci7n$jtd@drogheda.nuance.com> <DALort.Bpx@cnn.nas.nasa.gov> <3selil$hpf@fly.HiWAAY.net>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f65d0,9306ff1bcb6e8b71 X-Google-Attributes: gidf65d0,public X-Google-Thread: 10eb55,95341354f73a82f6 X-Google-Attributes: gid10eb55,public From: jwa2n@galen.med.Virginia.EDU (James W. Adams) Subject: Re: Compilation of gcc/g++ on ymp-el? Date: 1995/06/27 Message-ID: <DAupv2.H8n@murdoch.acc.Virginia.EDU> X-Deja-AN: 105131185 sender: usenet@murdoch.acc.Virginia.EDU x-nntp-posting-host: galen.med.virginia.edu references: <3scf6b$h4g@news.duke.edu> <3sci7n$jtd@drogheda.nuance.com> <DALort.Bpx@cnn.nas.nasa.gov> <3selil$hpf@fly.HiWAAY.net> organization: University of Virginia newsgroups: comp.unix.cray,gnu.gcc