You are not logged in.
All package will be recompiled against gcc 4.4 ?
Offline
All package will be recompiled against gcc 4.4 ?
Very doubtful... Maybe [core] might get a rebuild
Offline
Yeah, if you have a power hungry 4x quad-core, you can easily compile [extra] and whatnot from abs ![]()
Offline
Don't expect noticeable performance gains. Maybe a couple % at best. Of course, I've not tried GCC 4.4 yet, but this is generally the case -- people overestimate the amount of change new versions of toolchains bring. The only things related to compiling I've ever seen make a noticeable difference are handwritten ASM (in SOME specific cases, like x264), PGO (aka fprofiling), and LLVM.
Offline
I compiled gcc-4.4 with the new ppl support which is supposely what is suppose to make gcc-4.4 faster, and then I compiled my kernel with gcc-4.4 using the same .config I did with gcc-4.3, and the kernel grew about 4kb and it was unnoticably slower and less responsive (did several test) sadly. What a let down. ![]()
Last edited by Aprz (2009-04-23 07:19:22)
Offline
...the kernel grew about 4kb and it was unnoticably slower and less responsive (did several test) sadly. What a let down.
Perhaps it was noticeably faster? (
)
I imagine GNU is working hard on their compiler, given all the talk lately about ICC and performance, so it wouldn't surprise me that much if we begin seeing a lot of improvements in the near future (but don't take my word for it).
Dylon
Offline
You can try the llvm backend, maybe it is faster (it is available with a gcc frontend)
--Marenz
Offline
I compiled gcc-4.4 with the new ppl support which is supposely what is suppose to make gcc-4.4 faster, and then I compiled my kernel with gcc-4.4 using the same .config I did with gcc-4.3, and the kernel grew about 4kb and it was unnoticably slower and less responsive (did several test) sadly. What a let down.
The graphite optimizations (what ppl and cloog-ppl enable) do not even get turned on with -O3 so you need to add those flags manually. Maybe that will help improve speed.
Offline
Aprz wrote:I compiled gcc-4.4 with the new ppl support which is supposely what is suppose to make gcc-4.4 faster, and then I compiled my kernel with gcc-4.4 using the same .config I did with gcc-4.3, and the kernel grew about 4kb and it was unnoticably slower and less responsive (did several test) sadly. What a let down.
The graphite optimizations (what ppl and cloog-ppl enable) do not even get turned on with -O3 so you need to add those flags manually. Maybe that will help improve speed.
Heh, I do it with -O2. -O3 might forcefully inline too things which instead of speeding it up like intended would cause slow downs instead. In the kernel, there is an option to even let gcc decide whether it wants to uninline functions. This actually works great, the kernel load time doesn't change, but the overall responsiveness of the kernel improves.
Oh, and for some reason, I just cannot get icc to work on my computer. It is driving me crazy, but my computer is so wacked out anyhow and I am starting to get sloppy (like 80% of the computer was compiled/edited by me, haha, go FOSS!). I just got my boot time down to 11s bootchart on my crap hardware, managed to slash off 2s with static /dev (pretty much using mknod to create all my virtual devices). Playing around with that right now trying to figure out how to get damn xterm to work, haha... That's the only thing I haven't figured out yet with static /dev, but overall, it's great and I am very pleased with it. Hopefully it will be a once in a life time hassle for a 2s faster boot time, haha!
Last edited by Aprz (2009-04-24 07:24:08)
Offline
I just installed the new build tool chain including gcc from testing. I wanted to test it, so I built ffmpeg-svn which usually doesn't take long. It used 100% processor power over two cores. The build took at least five to six times longer than with the last gcc without changing any options. Yikes!
Offline
Hmmm..... python3 times.
Old toolchain:
real 3m42.523s
user 2m57.835s
sys 0m33.105sNew toolchain:
real 3m42.625s
user 2m57.842s
sys 0m33.188sSo I'd say dead heat... I also don't remember glibc being any slower at the start and end of the toolchain bootstrap, but I didn't time it. Maybe ffmpeg is exposing a bug in the new gcc?
Offline
I only ran one unscientific test when posted before and that was with ffmpeg-svn. Since I build it daily, I have a strong sense for how long it takes. Interestingly it seems to be only FFmpeg. I built x264-git to see if it was the ASM code that was bottlenecking it, and it doesn't seem like it. Every other test goes normally. The processor cores never get to 100% for long and everything seems fine. I'll bet that the FFmpeg people figure this out before the weeks end.
*** Note to self ***
Need caffeine before attempting smartness.
Offline