[gentoo-user] lazy gcc switching

[gentoo-user] lazy gcc switching

[fajfusio]

[-- Attachment #1: Type: text/html, Size: 620 bytes --]

Re: [gentoo-user] lazy gcc switching

[Alan McKinnon]

On Wednesday 21 July 2010 10:53:19 fajfusio@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

[Dale]

Alan McKinnon wrote:
> On Wednesday 21 July 2010 10:53:19 fajfusio@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

[Bill Longman]

On 07/21/2010 03:22 AM, Dale wrote:
> Alan McKinnon wrote:
>> On Wednesday 21 July 2010 10:53:19 fajfusio@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

[Alan McKinnon]

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

[Dale]

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

[Bill Longman]

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

[Walter Dnes]

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 houses<g>.  I don't run desktops, I run applications.  KDE/GNOME
represent a lot of why I left Windows in the first place.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-user] lazy gcc switching

[Alan McKinnon]

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

[Dale]

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

:-)  :-)

Re: [gentoo-user] lazy gcc switching

[Alan McKinnon]

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     shared    buffers     cached
Mem:      98996716   95962284    3034432          0    1855976   32633760
-/+ buffers/cache:   61472548   37524168
Swap:      4192956          0    4192956

$ 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

[Bill Longman]

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 hour....that would really add to my
numbers, (just past 1.5M last month). :-)

[gentoo-user] Re: lazy gcc switching

[walt]

On 07/21/2010 03:18 PM, Bill Longman wrote:

> Might I suggest a small hardware upgrade:
>
>   http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm

Hey, where's the parallel port for my Epson MX-80 printer?

[gentoo-user] Re: lazy gcc switching

[Grant Edwards]

On 2010-07-22, walt <w41ter@gmail.com> wrote:
> On 07/21/2010 03:18 PM, Bill Longman wrote:
>
>> Might I suggest a small hardware upgrade:
>>
>>   http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm
>
> Hey, where's the parallel port for my Epson MX-80 printer?

Ah, quit whining.  At least it has a serial port so you can hook up
your ASR-33 teletype.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm RELIGIOUS!!
                                  at               I love a man with
                              gmail.com            a HAIRPIECE!!  Equip me
                                                   with MISSILES!!

Re: [gentoo-user] Re: lazy gcc switching

[Bill Longman]

On 07/22/2010 12:49 PM, walt wrote:
> On 07/21/2010 03:18 PM, Bill Longman wrote:
> 
>> Might I suggest a small hardware upgrade:
>>
>>  
>> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm
>>
> 
> Hey, where's the parallel port for my Epson MX-80 printer?

You're aging yourself, Walt. Some of us have actually used these, let
alone know what they are.

And once Alan gets this puppy pried into his laptop chassis, I want to
see the power supply connector.

[gentoo-user] Re: lazy gcc switching

[walt]

On 07/22/2010 02:04 PM, Bill Longman wrote:
> On 07/22/2010 12:49 PM, walt wrote:
>> On 07/21/2010 03:18 PM, Bill Longman wrote:
>>
>>> Might I suggest a small hardware upgrade:
>>>
>>>
>>> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm
>>>
>>
>> Hey, where's the parallel port for my Epson MX-80 printer?
>
> You're aging yourself, Walt. Some of us have actually used these, let
> alone know what they are.

Okay, I was exaggerating, but only slightly.  My brother-in-law forcibly
took my Epson MX-100 away to an e-cycling place on the grounds that the
dust was aggravating his asthma.  This happened about three months ago,
no kidding.  (He forgot the parallel-port cable, though.)

[gentoo-user] Re: lazy gcc switching

[Grant Edwards]

On 2010-07-22, walt <w41ter@gmail.com> wrote:
> On 07/22/2010 02:04 PM, Bill Longman wrote:
>> On 07/22/2010 12:49 PM, walt wrote:
>>> On 07/21/2010 03:18 PM, Bill Longman wrote:
>>>
>>>> Might I suggest a small hardware upgrade:
>>>>
>>>> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.cfm
>>>
>>> Hey, where's the parallel port for my Epson MX-80 printer?
>>
>> You're aging yourself, Walt. Some of us have actually used these, let
>> alone know what they are.
>
> Okay, I was exaggerating, but only slightly.  My brother-in-law forcibly
> took my Epson MX-100 away to an e-cycling place on the grounds that the
> dust was aggravating his asthma.  This happened about three months ago,
> no kidding.  (He forgot the parallel-port cable, though.)

I still use a parallel port to connect to my HP laserjet 1300.  I
think the printer also has a USB port, but I had a parallel cable left
over from my Epson LQ-1500 (24 pins for extra high-frequency noise!).

-- 
Grant Edwards               grant.b.edwards        Yow! I'm pretending that
                                  at               we're all watching PHIL
                              gmail.com            SILVERS instead of RICARDO
                                                   MONTALBAN!

Re: [gentoo-user] Re: lazy gcc switching

[Alan McKinnon]

On Thursday 22 July 2010 23:04:03 Bill Longman wrote:
> On 07/22/2010 12:49 PM, walt wrote:
> > On 07/21/2010 03:18 PM, Bill Longman wrote:
> >> Might I suggest a small hardware upgrade:
> >> 
> >> 
> >> http://www.supermicro.com/Aplus/motherboard/Opteron6100/SR56x0/H8QGi-F.c
> >> fm
> > 
> > Hey, where's the parallel port for my Epson MX-80 printer?
> 
> You're aging yourself, Walt. Some of us have actually used these, let
> alone know what they are.

I had an MX-80 too! Used it for years. Then I sold it to my boss at the time 
for printing invoices and it's still running to this day (7 years later)

> And once Alan gets this puppy pried into his laptop chassis, I want to
> see the power supply connector.

Um, yeah, small problem with that. I went to chat to my facilities guys about 
the power needs. We have to book out power so the UPS doesn't complain (I 
blame it on the World Cup). His answer:

"You want HOW MANY fscking amps???!!!!!??? I have entire banking systems that 
use less than that!!!!"


-- 
alan dot mckinnon at gmail dot com