Gentoo Archives: gentoo-user

From: Alan McKinnon <alan.mckinnon@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] lazy gcc switching
Date: Thu, 22 Jul 2010 09:07:35
Message-Id: 201007221009.29603.alan.mckinnon@gmail.com
In Reply to: Re: [gentoo-user] lazy gcc switching by Dale
1 On Thursday 22 July 2010 02:03:15 Dale wrote:
2 > Alan McKinnon wrote:
3 > > On Thursday 22 July 2010 00:18:05 Bill Longman wrote:
4 > >> On 07/21/2010 12:39 PM, Alan McKinnon wrote:
5 > >>> On Wednesday 21 July 2010 17:49:46 Bill Longman wrote:
6 > >>>> And to play devil's advocate, I'll chime in with my experience. The
7 > >>>> 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I
8 > >>>> recompiled all my packages after I upgraded to 4.4 and it was a
9 > >>>> noticeable difference.
10 > >>>>
11 > >>>> But, to make perfectly clear what Alan and Dale have stated
12 > >>>> previously, it is not a requirement to recompile anything. The
13 > >>>> binaries that are created still call the same system calls as they
14 > >>>> did before. The kernel still publishes them in the same locations.
15 > >>>> And to prove to yourself this is true, grab a statically linked
16 > >>>> binary, compiled for a stock standard i686, and run it on your
17 > >>>> machine.
18 > >>>
19 > >>> I'd love to be able to experience the speedups of gcc-4.4 and by rights
20 > >>> I should be able to - my last "rip gentoo apart and put it back
21 > >>> together again" stunt needed an emerge -e world to fix it all.
22 > >>>
23 > >>> But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5
24 > >>> has obliterated all that advantage several times over.....
25 > >>>
26 > >>> raster *really* needs to hurrry up now and release e17
27 > >>
28 > >> Might I suggest a small hardware upgrade:
29 > >> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F
30 > >> .cfm
31 > >
32 > > Might I submit that that will be a tad difficult to squeez into this:
33 > >
34 > > # dmidecode | grep -B3 "Product Name"
35 > > Handle 0x0100, DMI type 1, 27 bytes
36 > > System Information
37 > >
38 > > Manufacturer: Dell Inc.
39 > > Product Name: XPS M1530
40 > > :
41 > > :-)
42 >
43 > Heck, the mobo most likely cost more than your whole laptop. Froogle
44 > reports over $700.00 for that thing. O_O I wouldn't want the light
45 > bill for that thing tho. I would like to see foldingathome running on
46 > it. LOL Gkrellm would be fun to watch.
47
48 Looks like a quad cpu, each one dual core. I've got one of those in the Data
49 Centre next door and each core is running that new fancy hyper-threading that
50 actually works:
51
52 $ cat /proc/cpuinfo
53 ...
54 processor : 15
55 vendor_id : GenuineIntel
56 cpu family : 6
57 model : 26
58 model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz
59 stepping : 5
60 cpu MHz : 1596.000
61 cache size : 8192 KB
62
63 $ free
64 total used free shared buffers cached
65 Mem: 98996716 95962284 3034432 0 1855976 32633760
66 -/+ buffers/cache: 61472548 37524168
67 Swap: 4192956 0 4192956
68
69 $ top
70 top - 10:07:17 up 9 days, 10:01, 1 user, load average: 130.27, 134.99,
71 122.32
72 Tasks: 246 total, 1 running, 245 sleeping, 0 stopped, 0 zombie
73 Cpu(s): 18.9%us, 0.5%sy, 0.0%ni, 29.2%id, 51.2%wa, 0.0%hi, 0.2%si, 0.0%st
74 Mem: 98996716k total, 96184800k used, 2811916k free, 1856248k buffers
75 Swap: 4192956k total, 0k used, 4192956k free, 32848132k cached
76
77
78 The grunt this thing has is unbelievable. Check the load - and the box is
79 still completely responsive. It runs a database of traffic through all our
80 routers so customers can check their traffic graphs going back 45 days.
81
82 On the old hardware we used to have to pamper the bloody thing and do a
83 juggling act with all the insert scripts. It was always running two hours
84 behind (on a good day). With this new baby, we just let it rip and ram data in
85 as fast as we can get it. It now runs 90 seconds behind :-0
86
87 Sometimes gigantic amounts of grunt are just the thing you need.
88
89
90
91
92
93 --
94 alan dot mckinnon at gmail dot com

Replies

Subject Author
Re: [gentoo-user] lazy gcc switching Bill Longman <bill.longman@×××××.com>