>>heh, not quite :) gcc, gdb, and everything else gnu puts out works faster
>>and for gcc creates smalelr executables than anything SCO or any commercial
>>co. would try to put out.
>That's simply not true. Anytime you create a benchmark, you can create
>a test case that you will win. However, I have consistently found that
>the Optimizing C Compiler (icc) that's now provided with the OpenServer 5
>development system will create binaries that will simply pounce those
>produced by GCC for raw computational speed.
obviously you haven't built gcc-2.7.0 with an i586 target.
i've had major success with warning flexibility and performance with
5 different programs that range from networking, cpu intensive,
and terminal interface beses. The terminal and networking stuff is about
the same, but the two cpu intensive progs give a consistant 4% real-time
advantage, on a machine with no other users of course.
Quote:>I posted the dhrystones here once before from some of my tests. The reality
>is that GCC is an amazing compiler, but a compiler built to be portable
>simply doesn't know as many "tricks of the chip" as a compiler built by
>the people that build the chips.
Yes, you can parse a little bit faster if you don't use a yacc generated
parser like gcc does to remain portable. I do remember gcc-2.6.3's compile
times was a bit faster thatn the sco3.2v4 compiler, but alas gcc-2.7.0
compile time is (if i remember right) 3% slower thatn the sco compiler,
although the sco compiler doesn't generate 586 instructions and i doubt it
even generates 486 instructions since it must work for all pcs...
However, not necessarily with runtime output, if you have the optimizing/post
processing tools no trick can be unimplimentable unless the portible
programmer forgets it. Just because something is portable doesn't mean
it will always lack system specific performance, this is the case with
compilers since you will always get the same instructional format that
you can optimize system dependelty after you lex and yacc.
Quote:>The GNU tools certainly have a purpose in life. Without a consistent
>set of tools for the 20 or so UNIXen that I use, my life would be hell.
>The ability to do cross development and embedded systems is way cool.
>Stating that they will trounce all vendor tools across the board is
>>co. would try to put out. And I'm not convinced by your mail that OpenServer 5
>>libraries do not have references to /lib/libc.a.
>Oh. They do. But that's OK, becuase OpenServer 5 PROVIDES /lib/libc.a,
>the headers, all the other libraries, and a linker. See the READMEs from
>my GNU distribution for OpenServer 5. There's a custom-installable package
>that gives you everything you need.
Oh. They don't! you just said they provide a /lib/libc.a which has it's
own headers which were probably used when they compiled the librpc.a and the
rest of the libraries, so they have references to the sytem dependednt
/lib/libc.a which means you must link with it and thus You cannot use
glib's /usr/local/lib/libc.a with sco librpc.a ...
Quote:>It works. Really.
>>the truck of money is loaded but it aint goin' nowhere.
>Well, go get the keys. You're going to need them. I'll wait through
>lunch if I need to. :-)