3.4.5 is available, has been, so has many older versions.  They are  
keeping current with Nekoware.  4.x is available, obviously less  
supported but it's there.  Using gmake to do distributed builds for  
both compilers makes me laugh a little because gmake and gcc are  
married together for optimization.  Gcc may be portable but on non-x86  
it's slower from my experience versus commercial compilers such as  
MIPSpro or Sun Studio. (MIPS and SPARC)  You cite build times using  
gmake and gcc on x86 versus gmake and spro on x86, while not taking  
into account that SPARC still exists, still is supported, still runs  
current versions of OpenSolaris and has more optimizations than gcc on  
SPARC.  MIPS is a good example, for some of these features such as  
sse2/3/4/ssse3/mmx/3dnow etc are not available, such as on PowerPC  
where the only real optimization was Altivec.  Try using mplayer using  
gcc on IRIX/MIPS then try the port to MIPSpro compilers on IRIX/MIPS,  
the aforementioned result on many machines was sluggish performance,  
inability to handle the most basic of playback due to large overhead  
and nasty workarounds.  GCC is a nasty workaround in itself, it may be  
cross-platform but it serves no benefit for key applications which  
require the optimization.  See KDE on older SPARC machines, or any  
SPARC machine for that matter, there's a demand for KDE on SPARC but  
GCC has in the past proven at least on Solaris/OpenSolaris to be less  
than ideal in terms of optimization.  Blame the developers if you  
like, but then explain why spro for example results in much more  
pleasant experience for the user.  For x86, perhaps it's fine, and I  
don't disagree with that, but I certainly want alternatives to be  
around, to put pressure on the gnu people to continue to innovate on  
all platforms regardless.  They need a few lessons.

James
On Apr 28, 2008, at 12:29 AM, Bob Friesenhahn wrote:

> On Sun, 27 Apr 2008, James Cornell wrote:
>
>> Is for KDE and X.org, maybe not Inkscape but trust me on this.   
>> Especially for SPARC systems it means everything.  If you've ever  
>> used GCC on IRIX/MIPS you'd know how convoluted and slow it is for  
>> non-x86 architectures.  For x86 it's still suffering for large  
>> packages such as KDE.  Don't believe me, then try the old KDE  
>> blastwave package and then try KDE 4 from spec using Spro.  I  
>> wouldn't call it an abstraction either, libtool and gcc toolchain  
>> is just pure garbage with too much complexity within itself and the  
>> licensing future is scary.
>
> These are interesting statements.  GCC on IRIX/MIPS (at least your  
> apparent experience of it) is so old as to not even be considered.   
> I find that GCC compiles much faster than the Sun compiler for x86:
>
> GCC 4.2.3:
> gmake -j 4  86.56s user 3.93s system 310% cpu 29.189 total
>
> Sun Studio 12:
> gmake -j 4  187.54s user 11.86s system 302% cpu 1:05.90 total
>
> The above builds are both using libtool, which you describe as "pure  
> garbage".
>
> As for the Sun compiler on SPARC, I must agree.  With the Sun  
> compiler, an old 1.2GHz SPARC CPU can stand up and sing like a 2.4GHz
> Intel CPU when fed code which was tuned for GCC.
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/desktop-discuss/attachments/20080428/c2a93727/attachment.html>

Reply via email to