Re: Free UNIX for non-commerical use.

From: Uli Link (Ulrich--nO--(dot)-sPAM--Link_at_Epost.de)
Date: 07/29/03


Date: Tue, 29 Jul 2003 00:39:36 +0200


> > Don't agree: the optimization of the GCC has become much better:
> > in 9 out of 10 times the GCC produces faster binaries than vendor
compilers
> > Perhaps not, if you will tune every single object, and put a lot of
#pragma
> > in your source to keep the vendor compilers from producing invalid code.
> > On AIX IBM's xlc build faster common-mode bins, but if you mind peak
> > performance, you should try the GCC 3.x and the cpu-specific
optimizations.
> > Never got working binaries from any GNU code with xlc and "-O5".
> > GCC's results were up to 10% faster on PowerPC, with greater difference
for
> > float compared to integer.
> > Same for Solaris x86, SCO and NCR's MP-RAS.
> > A great time-saver of the GCC is the fix of bugs in the O/S include
headers.
>
> I have never yet seen gcc 3.2 or previous generate faster code than
> Sun's C compiler. I've seen improvements up to 10* by switching to
> Sun's cc, depending on the code. Thats with specific cpu/architecture
> selection and high optimization selected for both gcc and cc,
> compiling plain C code.
>
Don't have written that this is valid for Solaris on Sparc, but I've never
seen a factor of ten on the E450 I've compared GCC 2.95.2 and Sun's Workshop
4 a few years ago.
It is maybe??? possible to write code leading to such extreme results, but
you could never expect such factor in real life. Not even with the code for
SPECint and SPECfp which no commercial vendor will ignore.
If you can build the Apache/SSL/PHP4 running 10times as fast as the GCC
build I will do the packaging for you.
But Sun will make the next version slower, since no one buys new hw anymore
;-)

> >
> > Another question is the productivity of an integrated dev environment
and
> > the turn-around-times.
> > The tools from Sun are much more comfortable but tend to bring elder
> > machines to the knees.
>
> Please explain how a GUI will make me faster than a commandline, and
> what a "turn around time" is.

Debugging with multiple source windows is a great help. Syntax colouring
too.
Navigation in big projects with hundreds of objects a visual source browser
is no luxury.
Agree that editing with vi is faster than anything else. But most of the
time programmers are thinking or searching, not typing. Just my 2ct. I'm
more an admin for programmers than a programmer.

Turn around is the time from starting the preprocessor till finish of the
linker or a fatal error.
This is the time the programmer waits for the results.

---
Uli


Relevant Pages

  • Re: Free UNIX for non-commerical use.
    ... >> in your source to keep the vendor compilers from producing invalid code. ... > I have never yet seen gcc 3.2 or previous generate faster code than ... SPECint and SPECfp which no commercial vendor will ignore. ... time programmers are thinking or searching, ...
    (comp.unix.solaris)
  • Re: Free UNIX for non-commerical use.
    ... >> in your source to keep the vendor compilers from producing invalid code. ... > I have never yet seen gcc 3.2 or previous generate faster code than ... SPECint and SPECfp which no commercial vendor will ignore. ... time programmers are thinking or searching, ...
    (comp.sys.hp.hpux)
  • Re: Free UNIX for non-commerical use.
    ... >> in your source to keep the vendor compilers from producing invalid code. ... > I have never yet seen gcc 3.2 or previous generate faster code than ... SPECint and SPECfp which no commercial vendor will ignore. ... time programmers are thinking or searching, ...
    (comp.unix.tru64)
  • Re: Free UNIX for non-commerical use.
    ... >> in your source to keep the vendor compilers from producing invalid code. ... > I have never yet seen gcc 3.2 or previous generate faster code than ... SPECint and SPECfp which no commercial vendor will ignore. ... time programmers are thinking or searching, ...
    (comp.unix.aix)
  • Re: Free UNIX for non-commerical use.
    ... >> in your source to keep the vendor compilers from producing invalid code. ... > I have never yet seen gcc 3.2 or previous generate faster code than ... SPECint and SPECfp which no commercial vendor will ignore. ... time programmers are thinking or searching, ...
    (comp.sys.sgi.admin)