> I would imagine that just compiling ghostscript for i686 isn't enough;
> one would also have to recompile things it depends on (like libc) in
> order to really tell whether there was an improvement.

I do not think recompiling libc will make a noticible difference either; 
any time ghostscript spends in libc is essentially wasted.

> 
> In any case, if I go through the work to get the source RPMs to produce
> i586 and i686 code, does anyone know any particular reason why RedHat
> *wouldn't* accept that change into their source-base or whatever? 

Space in the distro. If you want to add versions 486, 586, 686, 786 and 
assorted AMD processors, disk space requirements will expand enormously.
Run procinfo on your system; here's the result on mine:
[summer@possum summer]$ procinfo
Linux 2.3.99-pre5 (root@possum) (gcc egcs-2.91.66) #34 1CPU 
[possum.Summerfield]

Memory:      Total        Used        Free      Shared     Buffers      
Cached
Mem:        190428      185520        4908           0       35916       
93272
Swap:       128480       43216       85264

Bootup: Thu Apr 20 15:07:15 2000    Load average: 0.02 0.06 0.02 1/111 910

user  :       9:27:52.22   5.2%  page in :127622816  disk 1:  2940464r  
635536w
nice  :   1d  1:16:28.74  13.8%  page out:  1832242  disk 2:  1873407r     
460w
system:       4:51:14.34   2.6%  swap in :   336640  disk 3:    46899r    
1892w
idle  :   6d  0:00:32.92  78.4%  swap out:   350623
uptime:   7d 15:36:08.21         context :110867739

irq  0:  66096822 timer                 irq  9:        72 acpi, aic7xxx
irq  1:    215199 keyboard              irq 10:   1954128 epic100
irq  2:         0 cascade [4]           irq 12:   3838482 PS/2 Mouse
irq  4:      1175 serial                irq 13:         1 fpu
irq  6:         5                       irq 14:   5430226 ide0
irq  7:         2                       irq 15:     48740 ide1
irq  8:         1 rtc

[summer@possum summer]$
 What would I benefit from a maby 5% improvement? Would I not be better 
replacing my CPU with something faster?

Almost nobody will recover the time spent recompiling software using more 
specific optimisations; only when the results are run on a lot of machines 
does it become economically viable.


-- 
Cheers
John Summerfield
http://os2.ami.com.au/os2/ for OS/2 support.
Configuration, networking, combined IBM ftpsites index.


-- 
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null

Reply via email to