Hi,
On Wed, Oct 23, 2002 at 11:07:49PM +0200, Diego Iastrubni wrote:
> ביום שני 21 אוקטובר 2002, 23:37, Eli Marmor כתב:
> > Yedidyah Bar-David wrote:
> > > This is not accurate.
> > > What these results mean is that the gcc optimizations for 586 and for
> > > 686 are not very different. The CPU itself might optimize things quite
> > > differently, with or without the help of the compiler.
> > > To see the difference between 586 and 686 you need to measure some
> > > activity (like konq startup) in both and divide the time by the Mhz.
> > > You will probably find that for most tests (like this one), the newer
> > > machine will be much slower, because most of the relevant hardware in
> > > the machine progressed much less than the CPU. E.g. in a 100Mhz 586
> > > you will probably find a disk that is 1.5 times slower (in access time,
> > > not throuput) than in a 400Mhz 686, so the 686 will come out 3 times
> > > slower per Mhz, if the measured activity is heavily dependant on the
> > > access time of the disk. The same is true (with different ratios) for
> > > disk throuput, RAM access and throuput, etc.
> who cares about it? I want my box to load in less time... lieave this bs to
> amd/intels/transmeta analists...
I generally agree - but I think, as others said, the most gain will be
from not linking/compiling features you do not need. And personally,
almost all the things I use regularly (X server, fvwm, xterms+bashes,
lynx) do not have enough features I do not need to make it worth
compiling them myself.
The biggest gain for me will probably be to read lynx's doc and find
how to make it not stop for two seconds every time it shows an error
message :-)
> >
> > The real news is not 586 vs. 686;
> > The real story is both vs. 386.
> not only, my question is: will I get more speed (less latency actually) if
> i"ll compile everything for 686?
>
> > And please don't argue with me (Ira - you too);
> > I responded to Diego.
> > I assume that his results are accurate.
> not too much, don't count on this.
>
> > And in any case, he didn't compare two different computers with
> > different disks/RAM/etc.;
> > He compared 386 performance with 586/686, ON THE SAME COMPUTER.
> > So there is no excuse for getting better results with the 386
> > compilation.
> > It's not the disk/RAM/etc.;
> > It's the CPU, stupid! ;-)
> or the s/w. Please have in mind that kde2.2.2 and kde3.1 are written very
> differently. In kde 2.2.2 the part that took the most time in "botting kde"
> was loading the window manager, while in kde3.1 was the peripherals phase
> (which took I think 4-6 secs while in kde2.2.2 1 sec)
>
> > If his results are right (Ira, please notice the word "if" and similar
> > words that were used in my previous message), then it means that no
> > progress has been achieved in the microprocessor industry for 15 years,
> > except for more and more Hertz's.
> again please read the message I sent you in private, you will see my point of
> view.
>
> I started gentooing my mdk after the last debate on gentoo in which Tzafrir
> proposed the same he proposing now: optimize 20% of the package which do 80%
> of the work and get almost the same results. Tzafrir: have you done it
> somewhere?
>
> (Next in list are glibc, which I will be cool to update, xfree, bash (if
> scripts handling getting faster on new version?). If anyone can comment on
If your scripts are posix-sh compliant, and do not need bashisms, you
might consider making /bin/sh a link to ash (now renamed to dash -
I think it was abandoned by upstream (netbsd?) and adopted by Debian).
It's much smaller than bash, depends on fewer libraries, and is faster
(mostly in load time - haven't checked runtime performance).
At least in Debian, it's an optional /bin/sh, and Debian makes sure
all their /bin/sh scripts will work with it (and any other POSIX shell).
A trivial demonstration of performance:
<didi@pinky> ~ 617 % :|awk 'END {for (i=0; i<100; i++) \
printf("bash -c \"echo %s > /dev/null\"\n", i)}' | time bash
^^^^
0.67user 0.46system 0:01.12elapsed 100%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (23430major+4842minor)pagefaults 0swaps
<didi@pinky> ~ 616 % :|awk 'END {for (i=0; i<100; i++) \
printf("ash -c \"echo %s > /dev/null\"\n", i)}' | time bash
^^^
0.28user 0.28system 0:00.55elapsed 101%CPU (0avgtext+0avgdata
0maxresident)k 0inputs+0outputs (10630major+3443minor)pagefaults 0swaps
(that is, about two times faster for 100 loads+builtin echos).
(And ash somehow squeezes another percent off my 300 Mhz Celeron :-)
Probably a rounding error in 'time')
(Yes. /usr/bin/time doesn't go above 100% - it's bash's time builtin).
BTW - I do not recommend ash as an interactive shell except of in
emergency. bash is far better.
One more thing: Xfree86 4.x is modular - you can decide which modules
to load in XF86Config. Don't load what you don't need and tell us
if you saved a significant amount of time.
> compiling srpms of those packages please post your observations).
>
> - diego
>
>
>
> ================================================================To unsubscribe, send
>mail to [EMAIL PROTECTED] with
> the word "unsubscribe" in the message body, e.g., run the command
> echo unsubscribe | mail [EMAIL PROTECTED]
Didi
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
