[ltp] two questions -- 600E / X / RAM

[Tim Prince]

On Thursday 18 April 2002 06:05, Tino Keitel wrote:
> On Thu, Apr 18, 2002 at 08:33:04 -0400, Tod Harter wrote:
> > I think even on the fastest machines KDE can sometimes seem a bit slow.
> > Same for Gnome. The fact is, despite all RMS and these guys protestations
> > to the contrary, commercial software vendors like MS have a huge
> > advantage in performance tuning their stuff.
In my experience, Windows installations always get loaded up to where they 
are slower than linux.  My wife's XP screen comes up reasonably fast, but 
it's several minutes longer until Outlook Express is able to come up, and 
we've got an untypically minimal Windows with 320MB RAM.  In order to run 
Windows in a comparable environment to linux, you must have an antivirus and 
a firewall running from boot time, and there's no way Windows can be fast.  
My employer counts on that to improve demand for new boxes on the desktop.
> >
> > For instance MS VC++ 6.x generates machine code that is between 130% and
> > 200% more efficient than GCC 2.9.x does. 
Who cares?  On my benchmarks, gcc-3.1 code is running 20% faster than MSVC6.
>That means that even with code
> > that is identical in basic efficiency, Windows will be almost 2x as zippy
> > on any given hardware. 
I've never seen more than a 2% advantage running gcc built code on Windows, 
compared with linux, and that's only where the more frequent interrupts in 
linux are reducing the effectiveness of cache.  Much of what I do on both 
linux and Windows runs up to twice as fast on linux, due to the 
inefficiencies of emulating pipes and pthreads on Windows, and the other 
OS-dependent mechanisms involved in MPI.
>Drivers are almost always better for windws as
> > well, since vendors actually care about it.
>
> Forget about almost always stable drivers in Windows :), BUT: Yeah, we
> really need a good optimizing multi-pass C/C++ compiler for Linux-x86, but
> GCC is focussed on multi-platform compatibility. I read that the recently
> released Intel C++ compiler produces code that is 300% faster on the
> average. 
That would be the average of vectorizable code; not a universal occurrence in 
C++. Or, did someone add an extra zero by mistake?  You could compare the 
SPEC results; icc is highly optimized for them, so the margin of superiority 
of icc there is likely to be more than "average," by any reasonable 
definition.
>Unfortunately, the shared libraries compiled with the Intel
> compiler won't work with executables compiled with GCC. You must recompile
> your whole C++ stuff to use it, which is hard since there are source code
> incompatibilties between GCC and Intel C++. 
You must be talking about past versions of those compilers (I hope).  Both 
the g++ and the Intel C++ developers have been working hard to conform to the 
same standards.  You can't say that for MSVC. 
 C++ mangling and linkage are inherently non-portable; unless the OS has a 
well enough supported common ABI, you won't find mixtures of g++ .o files and 
others playing well, except with extern "C" linkage.  You can see that I'm a 
g77 fan (!)

>
> > In addition OSS projects just don't focus on speed and efficiency. 
That's an unfair generalization.  MS has begun to talk about bringing MSVC 
code up to similar performance against competing compilers (gcc).  People are 
noticing the difference.

-- 
Tim Prince

----- The Linux ThinkPad mailing list -----
The linux-thinkpad mailing list home page is at:
http://www.bm-soft.com/~bm/tp_mailing.html