lunuxcaffe; logo contest - mystery font

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Wed Nov 10 17:21:24 UTC 2004


On Wed, Nov 10, 2004 at 12:07:08PM -0500, cbbrowne-HInyCGIudOg at public.gmane.org wrote:
> If your system is so overloaded that the performance differences coming
> from running a more highly optimized version of "mount" is necessary in
> order for it not to fall down into a steaming cauldron of molten
> silicon, then running GCC to recompile things, which is considerably
> MORE expensive than running them, would clearly push you over into
> "meltdown mode."
> 
> I would see value in recompiling GLIBC with customized options.  I would
> see value in recompiling XFree86 in a "tuned" manner, and perhaps Emacs,
> if you're doing a lot of that.

An optimized kernel makes some sense, which is why kernels for different
cpu types are provided.  And for somethings like openssl which has
assembly optimizations for different cpu types, you build a version for
each cpu that it makes a difference for, and load the right one.
Debian's libssl package has different cpu types in it on i386 which the
dynamic loader auto selects at runtime.

Some programs like mplayer and such have different code paths for
different cpus which they select at runtime (as far as possible).

It seems the key cpu optimizations are actually done with hand coded
assemble, not with gcc cpu type optimizations which hardly make a
difference.

> If Nat Friedman's "GNU Rope" project (akin to Sun's "cords" tool
> <http://www.advogato.org/article/660.html>) had continued, that might be
> of merit.  You might get value out of running "strip" on all of your
> binaries; that's cheap, and would have some impact.

Well Debian by policy strips binaries unless there is a good reason not
to.  I thought everyone did that.

> But recompiling everything on the system?  Total fool's errand,
> particularly if the point is to do so with GCC, which is _not_ one of
> the world's fastest C compilers.  

GCC could certainly be improved a lot in the optimization category
(which it appears 3.4 is moving towards creating a better framework for
doing).

> And if you're running "near to capacity," the sheer cost of running GCC
> makes it a definite "fool's errand."

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list