I think I was clear to restrict what I was looking for.
Just difference between -mnocona and -mcore2 flags of respective versions
of gcc.
I understand that 4.1 gcc has no speed optimization and only 4.2 onwards
optimization came in picture.
Thanks for pointing out role of glibc in this case.
I know, I am not doing benchmarking of applications I am using by compiling them in two gcc versions, running benchmarking scripts.
But, thats the reason I go out asking gcc community what are their
experiences.
There are many reasons latest gcc doesn't come in many linux distro
just because it requires testing, bug fixing and amount of resources/developers/testers available to migrate distro to new gcc. But, I am
just doing it because I want to take advantage of optimization provided
in gcc 4.3.2. I understand there is risk, but I am taking it.
--- On Sun, 12/28/08, Tim Prince <TimothyPrince@xxxxxxxxxxxxx> wrote:
> From: Tim Prince <TimothyPrince@xxxxxxxxxxxxx>
> Subject: Re: core2 flag for arch on gcc 4.3.2
> To: tomgogh20@xxxxxxxxx
> Cc: tprince@xxxxxxxxxxxx, gcc-help@xxxxxxxxxxx
> Date: Sunday, December 28, 2008, 9:46 AM
> tom gogh wrote:
> > Hi Tim,
> > sorry for not making it clear.
> > I am building Gentoo 2008.0 and gcc supported is 4.1.2
> which only
> > supports -mnocona for core 2 duo processor.
> > By migrating to gcc 4.3.2 I will get tunning for core
> 2 with flag
> > -mcore2 but, it involves going to unsupported gcc for
> Gentoo.
> > So, I want to know what is the difference between
> -mnocona flag of gcc
> > versus -mcore2 flag of gcc 4.3.2. Is it worth in terms
> of speed
> > optimization?
> >
> You're still being unclear. If you mean rebuilding an
> entire distro with
> an up to date compiler, there may be reasons why it
> hasn't been done
> already. If you don't have any idea what kernel or
> glibc operations you
> want to speed up, and how to measure it, and can't
> define what you mean by
> worth while, I have no qualification to make that
> determination for you.
> You give the impression that you haven't even compared
> the performance of
> the compilers on applications which matter to you, or
> haven't even thought
> about which applications matter. gcc has made great
> advances since 4.1,
> not only in optimizing for current CPU types, but in
> supporting OpenMP,
> auto-vectorization, and current language standards.
> Some of the more critical glibc operations are hand coded
> with inline asm,
> so as to prevent gcc optimization from helping out. If you
> choose not to
> use an up to date memcpy(), for example, you can make it
> perform much
> better by discarding the old glibc source and compiling C
> source with an
> up to date gcc. I don't know whether your gentoo uses
> up to date glibc,
> but I would doubt it, if the recommended gcc is so old.
