Re: [gentoo-user] lazy gcc switching
On Thursday 22 July 2010 02:03:15 Dale wrote: Alan McKinnon wrote: On Thursday 22 July 2010 00:18:05 Bill Longman wrote: On 07/21/2010 12:39 PM, Alan McKinnon wrote: On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 Might I suggest a small hardware upgrade: http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F .cfm Might I submit that that will be a tad difficult to squeez into this: # dmidecode | grep -B3 Product Name Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: XPS M1530 : :-) Heck, the mobo most likely cost more than your whole laptop. Froogle reports over $700.00 for that thing. O_O I wouldn't want the light bill for that thing tho. I would like to see foldingathome running on it. LOL Gkrellm would be fun to watch. Looks like a quad cpu, each one dual core. I've got one of those in the Data Centre next door and each core is running that new fancy hyper-threading that actually works: $ cat /proc/cpuinfo ... processor : 15 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU X5570 @ 2.93GHz stepping: 5 cpu MHz : 1596.000 cache size : 8192 KB $ free total used free sharedbuffers cached Mem: 98996716 959622843034432 01855976 32633760 -/+ buffers/cache: 61472548 37524168 Swap: 4192956 04192956 $ top top - 10:07:17 up 9 days, 10:01, 1 user, load average: 130.27, 134.99, 122.32 Tasks: 246 total, 1 running, 245 sleeping, 0 stopped, 0 zombie 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 Mem: 98996716k total, 96184800k used, 2811916k free, 1856248k buffers Swap: 4192956k total,0k used, 4192956k free, 32848132k cached The grunt this thing has is unbelievable. Check the load - and the box is still completely responsive. It runs a database of traffic through all our routers so customers can check their traffic graphs going back 45 days. On the old hardware we used to have to pamper the bloody thing and do a juggling act with all the insert scripts. It was always running two hours behind (on a good day). With this new baby, we just let it rip and ram data in as fast as we can get it. It now runs 90 seconds behind :-0 Sometimes gigantic amounts of grunt are just the thing you need. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] lazy gcc switching
On 07/22/2010 01:09 AM, Alan McKinnon wrote: Looks like a quad cpu, each one dual core. I've got one of those in the Data Centre next door and each core is running that new fancy hyper-threading that actually works: It's quad CPU TWELVE core. Just putting four CPUs into the thing will cost a small mortgage. Consider that the current 6-core 8000-series CPUs cost about 3k $US, the Magny-Cours will bring a well-spring of cash flowing out your pocketbook. But, yeah, that would be amazing to see how many proteins you could fold in an hourthat would really add to my numbers, (just past 1.5M last month). :-)
Re: [gentoo-user] lazy gcc switching
On Wednesday 21 July 2010 10:53:19 fajfu...@wp.pl wrote: Hi I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't want to rebuild any package now. As time goes on my packages will be compiled with new version. I hope that after a few month there will be only a number of packages not compiled with a new gcc. Then I want to recompile them on demand including libtool if necessary. Do you think my plan have a chance to succeed. Yes. Why do you think you would even need to get into a long compile? Have you been reading that GCC Upgrade Guide at gentoo.org? You know, the one that is so flat out wrong on so many levels? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] lazy gcc switching
Alan McKinnon wrote: On Wednesday 21 July 2010 10:53:19 fajfu...@wp.pl wrote: Hi I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't want to rebuild any package now. As time goes on my packages will be compiled with new version. I hope that after a few month there will be only a number of packages not compiled with a new gcc. Then I want to recompile them on demand including libtool if necessary. Do you think my plan have a chance to succeed. Yes. Why do you think you would even need to get into a long compile? Have you been reading that GCC Upgrade Guide at gentoo.org? You know, the one that is so flat out wrong on so many levels? I recently upgraded my gcc and I must confess, I did do a emerge -e system. Is it needed, nope. OP, Alan is correct on this. You don't really need to re-emerge everything. If, like me, you want to be on the safe side, just do a emerge -e system and let the rest recompile as you update. Another good thing about this way, if this version of gcc causes you trouble, you can downgrade and only have to re-emerge system. ;-) I did upgrade gcc once and had serious issues with it. Wouldn't compile a kernel, programs crashing and other weird things. After a downgrade, all went back to normal. The only thing worse than a emerge -e world is having to do it twice. LOL Dale :-) :-)
Re: [gentoo-user] lazy gcc switching
On 07/21/2010 03:22 AM, Dale wrote: Alan McKinnon wrote: On Wednesday 21 July 2010 10:53:19 fajfu...@wp.pl wrote: Hi I've just switched to gcc 4.3.4 from 4.1.2 using gcc-config tool. I don't want to rebuild any package now. As time goes on my packages will be compiled with new version. I hope that after a few month there will be only a number of packages not compiled with a new gcc. Then I want to recompile them on demand including libtool if necessary. Do you think my plan have a chance to succeed. Yes. Why do you think you would even need to get into a long compile? Have you been reading that GCC Upgrade Guide at gentoo.org? You know, the one that is so flat out wrong on so many levels? I recently upgraded my gcc and I must confess, I did do a emerge -e system. Is it needed, nope. OP, Alan is correct on this. You don't really need to re-emerge everything. If, like me, you want to be on the safe side, just do a emerge -e system and let the rest recompile as you update. Another good thing about this way, if this version of gcc causes you trouble, you can downgrade and only have to re-emerge system. ;-) I did upgrade gcc once and had serious issues with it. Wouldn't compile a kernel, programs crashing and other weird things. After a downgrade, all went back to normal. The only thing worse than a emerge -e world is having to do it twice. LOL And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a *noticeable* difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine.
Re: [gentoo-user] lazy gcc switching
On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] lazy gcc switching
Alan McKinnon wrote: On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 My last KDE upgrade made KDE a little faster here as well. It won't be as fast as e17 tho. Since I upgraded gcc a little before that, I wasn't sure if it was gcc building better code or KDE got rid of some garbage. It is a little faster tho. I suspect gcc. When as larger programs ever got faster? I'm sure they added code to KDE, not taking code away. ;-) Dale :-) :-)
Re: [gentoo-user] lazy gcc switching
On 07/21/2010 12:39 PM, Alan McKinnon wrote: On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 Might I suggest a small hardware upgrade: http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm
Re: [gentoo-user] lazy gcc switching
On Wed, Jul 21, 2010 at 03:36:33PM -0500, Dale wrote My last KDE upgrade made KDE a little faster here as well. It won't be as fast as e17 tho. Since I upgraded gcc a little before that, I wasn't sure if it was gcc building better code or KDE got rid of some garbage. It is a little faster tho. I suspect gcc. When as larger programs ever got faster? I'm sure they added code to KDE, not taking code away. ;-) I have a neutral attitude in the KDE/GNOME battle... the pox on both your housesg. I don't run desktops, I run applications. KDE/GNOME represent a lot of why I left Windows in the first place. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] lazy gcc switching
On Thursday 22 July 2010 00:18:05 Bill Longman wrote: On 07/21/2010 12:39 PM, Alan McKinnon wrote: On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 Might I suggest a small hardware upgrade: http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm Might I submit that that will be a tad difficult to squeez into this: # dmidecode | grep -B3 Product Name Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: XPS M1530 :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] lazy gcc switching
Alan McKinnon wrote: On Thursday 22 July 2010 00:18:05 Bill Longman wrote: On 07/21/2010 12:39 PM, Alan McKinnon wrote: On Wednesday 21 July 2010 17:49:46 Bill Longman wrote: And to play devil's advocate, I'll chime in with my experience. The 4.4 GCC, at least on AMD CPUs, creates noticeably faster code. I recompiled all my packages after I upgraded to 4.4 and it was a noticeable difference. But, to make perfectly clear what Alan and Dale have stated previously, it is not a requirement to recompile anything. The binaries that are created still call the same system calls as they did before. The kernel still publishes them in the same locations. And to prove to yourself this is true, grab a statically linked binary, compiled for a stock standard i686, and run it on your machine. I'd love to be able to experience the speedups of gcc-4.4 and by rights I should be able to - my last rip gentoo apart and put it back together again stunt needed an emerge -e world to fix it all. But, and this is the bit that makes me cry, the slowdown from KDE-4.4.5 has obliterated all that advantage several times over. raster *really* needs to hurrry up now and release e17 Might I suggest a small hardware upgrade: http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm Might I submit that that will be a tad difficult to squeez into this: # dmidecode | grep -B3 Product Name Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: Dell Inc. Product Name: XPS M1530 :-) Heck, the mobo most likely cost more than your whole laptop. Froogle reports over $700.00 for that thing. O_O I wouldn't want the light bill for that thing tho. I would like to see foldingathome running on it. LOL Gkrellm would be fun to watch. Dale :-) :-)
