[lug] Various Arch/Compiler Binaries living together

[Nate Duehr]

The compile-chain, kernel, and source for the applications would have to
support those additional CPU instructions.  Very few linux projects would
bother to take the time to write all that into their application, unless it
were a major number-cruncher application or something similar like video
tools.

So your quest for "scientific data" may not be there... because there's
probably very little code that will take advantage of the advanced CPU
instructions.  The compiler of course, is doing some of that with the
optimizations turned on... so there may be some benefit.

There was some semi-scientific data posted to various Debian lists a couple
of years ago where someone sat down and did a lot of testing.  It was in
response to whether or not Debian should include packages that if installed
would force rebuilds of downloaded software from source packages to match
your arch.  It was a silly idea... but the guy did do quite a bit of work
testing it, and the optimizations on anything non-heavy-number-crunching
showed to be not very useful.

Of course, some of this is intuitive... how often do you push your typical
desktop machine to 100% CPU and hold it there for extended periods of time
anymore?  It was a daily occurrence on P-I 75 and systems of that day and
age (and compiles of the kernel and monster programs don't count... I'm
talkin' end-user applications here...)... but now it's not typical for my
desktop machines to hit and stay at 100% CPU for more than a couple of
minutes a day when I'm not compiling.

The CPU speed wars will continue, but a P-III 450 isn't losing it's
usefulness at as rapid a pace as say my P-I 75 did years ago.  CPU power has
hit the "comfortable" range where most people are not upgrading due to that
as a major factor anymore, unless they're playing highly graphical 3D
environment online games or doing heavy mathmatical applications.  The
average joe wanting web surfing, e-mail, a little coding (hopefully... heh),
and viewing multimedia, isn't going to be too disappointed with older
P-III's, Durons, and Celerons -- and the P-IV, high end Athlons and Xeons
are serious overkill right now for most end-users.

Software will continue to bloat... er, um, add features, but the painful
need for more CPU cycles has started to be a thing of the past for most
applications.  Most machines get I/O bound to the hard disk subsystem long
before they run out of CPU these days.

One of the areas I'd like to see vendors work on is boot times.  Of course,
with Linux we rarely reboot... (GRIN)... but I'd love to see a super-fast
boot mode for standard BIOS's, and OS folks figure out new ingenious ways to
bring up the OS with the most used services first, get the user up and
running and then start ancillary services... X starting dead last on most
linux versions seems counterproductive to me... bring up everything X needs,
networking, etc... bring up X and let it get to thrashing around getting the
desktop environment up and painted, and then start other stuff.

Of course, we have control over this in linux... Windows OS folks get to see
the "please wait" screen and can't change it easily, if at all.

--
Nate, nate at natetech.com


> -----Original Message-----
> From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
> Behalf Of Timothy C. Klein
> Sent: Sunday, June 23, 2002 5:50 PM
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Various Arch/Compiler Binaries living together
>
>
> * Tom Tromey (tromey at redhat.com) wrote:
> > >>>>> "Ed" == Ed Hill <ed at eh3.com> writes:
> >
> > Ed> Since then, I've become convinced that fussing with
> > Ed> platform-specific compilation and optimization tweaks is almost
> > Ed> always a waste of time.
> >
> > Yeah, it is.  I think Red Hat compiles the kernel and glibc with
> > architecture-specific flags, but not anything else.  Unless the code
> > in question is very heavily used, the benefit is vanishingly small.
> >
>
> While I would not be overly surprised if you two are correct, I am not
> going to take your word for it :-)  If it is true, though, it would seem
> to imply the following:  the only difference between the i386 and
> Athlon/Pentium III/Pentium IV really boils down to clock speed (and I
> guess maybe memory bandwidth / cache size).  I am not sure I buy that.
> There *are* new, and more effiecent, instructions in the newer chips
> (3DNow, SSE, SSE2, MMX, etc..., to name those that have catchy names).
> So for the average application such things make no difference?
>
> Have any links to scientific analysis?
>
> Tim
> --
> ==============================================
> == Timothy Klein || teece at silverklein.net   ==
> == ---------------------------------------- ==
> == "Hello, World" 17 Errors, 31 Warnings... ==
> ==============================================
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
>