GCC 4.4.0 testing

Fred Krogh · Posted: Tue Jul 07, 2009 7:09 pm Post subject:

I wasn't going to comment here, but I feel that has gone a little further than necessary. As one who likes the latest and greatest, I'm sympathetic to alex.blackbit, but his tone is more hostile than I'm used to seeing here. It seems to me that randomlychosen is asking a reasonable question that is likely to generate more results that may help those interested in efficiency in making a choice. I'd like to say welcome to the forums, and don't let one responder sour you on this experience.
Fred

LukynZ · Posted: Tue Jul 07, 2009 7:17 pm Post subject:

randomlychosen

Hi and welcome. I think you are on the good way, however I think the only one test - unrar - is not good for presentating, that gcc-4.4.0 is worse. Well I am using 4.3.3 and I don't need to try 4.4.0 to my entire system, howewer I think that u should post more tests, than unrar only. I believe that some things can be better and some worse. Another quiestion is, how is compiled your entire system and dependencies. I think it is interesting. I have no time to test it at the moment, maybe next week, but I am curious how real is performance diff against gcc 4.2 and 4.4. I think the binary size is not problem at this times....well until it is slower too. Then it is weird

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

By the way, unrar is damn slow... I got it a little bit faster with my core2duo with gcc-4.4.0 but 7z is still faster (for rar files).

alex.blackbit · Advocate Joined: 26 Jul 2005 Posts: 2397

Letharion · Veteran Joined: 13 Jun 2005 Posts: 1344 Location: Sweden

Hey randomlychosen.

a)
I don't care all that much however about improved performance, I enjoy simply being the bleeding edge. During the upgrade to 4.4/2.10 I learned about how glibc got stricter about what code it compiles and that's the reason packages failed. I had a learning experience. If my computer got faster, that's great, if it didn't, I can probably live with that.

b)
I did get some improved performance, _with_ graphite.
Made a short post about somewhere back.
I can report back that I have noticed no problems at all. No weird behavior or seg faults.

Decided not to post the results simply because 1) I was (and remain) a lazy bastard and 2) some tests failed. A few from the beginning, and a few more with 4.4/2.10.

I would however, be up to the task of "proving" that I got better results, if it makes you (or anyone else happier)
Please outline what sort of tests you'd like me to perform, and I shall do my best to do so, time permitting.

c)
While we are on the subject of getting the most performance out of our machines, this might interest people: http://ctuning.org/wiki/index.php/Main_Page

d)
Ofc 4.4 should be in the dist. This is gentoo, "The dist with the choices". No one has decided that anyone should use 4.4. Portage will probably happily allow you to build your programs with 2.95 if you ask it nicely. But for me personally running 4.4 is natural. Some people must make the dive into unknown water and see what's down there. I hope I'll make the time somewhere down the line to help others draw a map too.

randomlychosen · n00b Joined: 07 Jul 2009 Posts: 7

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

randomlychosen · n00b Joined: 07 Jul 2009 Posts: 7

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

Just recompiled gcc-4.4.0 from portage and wanted to recompil glibc which fails with :

loftwyr · Posted: Sun Jul 12, 2009 2:54 pm Post subject:

try simplifying your CFLAGS and see if by removing one or two it fixes it
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing.

Xake · Posted: Sun Jul 12, 2009 8:30 pm Post subject:

unK · l33t Joined: 06 Feb 2007 Posts: 769

glibc ebuild strips CFLAGS.
_________________
ncmpcpp - featureful ncurses based MPD client inspired by ncmpc

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

I have this :

loftwyr · Posted: Sun Jul 12, 2009 10:56 pm Post subject:

remove the tracer and tree-vectorize and see if it fixes it.
_________________
My emerge --info
Have you run revdep-rebuild lately? It's in gentoolkit and it's worth a shot if things don't work well.
Celebrating 5 years of Gentoo-ing.

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

What the right way in portage to remove (or add) flags for some part of the ebuild ?

devsk · Posted: Mon Jul 13, 2009 9:00 pm Post subject:

I can attest to what randomlychosen has to say. I have seen 4.4 produce larger and slower code than 4.2 (4.3 was slower and larger than 4.2 but only slightly). We all know this: latest is not always the greatest. Devs do go overboard some times and regressions are a reality of the software release cycles.

Its one of those things that get lost in the hardware upgrades. 2% here and 1% there, and it got lost in that 20% boost you got from latest hardware. Some folks still think 2.95 was the best gcc ever and I agree. It has gotten slower and fatter since then.

Gregoire · Apprentice Joined: 15 Apr 2006 Posts: 292

I wanted to retry 4.2.4 so I switched it from gcc-config and for some program I have those errors :

Letharion · Veteran Joined: 13 Jun 2005 Posts: 1344 Location: Sweden

wrc1944 · Posted: Mon Jul 27, 2009 2:05 pm Post subject:

I was wondering (I should know this :oops:

) about using gcc-4.4.1_pre9999. I have it installed, and the first time after I switched over I completely rebuilt the toolchain, then @system and then @world.

It's working great so far on one of my Gentoo testing installs, with kde-live. My question is: When I rebuild to the latest gcc pre9999, what is the recommended subsequent procedure?

Rebuild only the toolchain with the upgraded gcc?
Rebuild the toolchain and then also emerge -e @system?
Or, rebuild toolchain, then everything else with emerge -e @world?

Or it doesn't really matter- just rebuild nothing, and proceed normally with regular system/world updates.

What's everyone else using pre9999 doing after an update?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 7 3700x, 3.6GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
OpenRC Gentoo ~amd64 plasma, glibc-2.36-r7, gcc-13.2.1_p20230304
kernel-6.8.4 USE=experimental python3_11

Letharion · Veteran Joined: 13 Jun 2005 Posts: 1344 Location: Sweden

I'm not an expert, but I do this:

Neo2 · Apprentice Joined: 25 Sep 2006 Posts: 224 Location: Italy

There was a thread explaining why multiple merges are useless. wrc1944's situation is quite of a different kind though.
If I'm right, gcc-4.4.1_pre9999 means that you are using the gcc-4.4.x development line, thus you are recompiling gcc with the patches post-4.4.1 that should make up for the gcc-4.4.2 release. Now, the devel schedule of gcc is to have minor releases every two months after the branch release. That is:
day 1: gcc 4.4.0 is released
day 61: gcc 4.4.1 is released
day 121: gcc 4.4.2 is released
etc
The minor releases include only the bugfixes and regression fixes from the current branch versus the old ones (gcc 4.4 against gcc 4.3/4.2/...).
Unless you're a gcc developer or want to help testing, I strongly advise not to recompile gcc with the "live" snapshots. The reason is the very same reason the GCC developers decided to wait two months between minor releases, that is: avoid a lot of overhead in terms of packaging, testing and recompilation; accumulate work and push it out. If you look at a bugzilla "diff" of what has been fixed in gcc 4.4.1 against 4.4.0 you can see 43 bugs over two months, and most of them are very unlikely to be hit by the average user due to their corner case nature. I find the choice of pre9999 of little use (especially if one wants to recompile the whole world everytime) because unless using special compiler features, it is unlikely to have some application bug resolved due to bogus code generated by the previous compiler.
Apart from this, as logical deduction from the thread above, I'd stick with this: