This definitely is the correct approach.
Actually, Daniel van Ham Colchete may not be as "all wet" as some
around here think. We've had previous data that shows that pg can
become CPU bound (see previous posts by Josh Berkus and others
regarding CPU overhead in what should be IO bound tasks).
In addition, we know that x86 compatible 64b implementations differ
enough between AMD and Intel products that it sometimes shows on benches.
Evidence outside the DBMS arena supports the hypothesis that recent
CPUs are needing more hand-holding and product specific compiling,
not less, compared to their previous versions.
Side Note: I wonder what if anything pg could gain from using SWAR
instructions (SSE*, MMX, etc)?
I'd say the fairest attitude is to do everything we can to support
having the proper experiments done w/o presuming the results.
Ron Peacetree
At 10:47 AM 12/11/2006, Chris Browne wrote:
In order to prove what you want to prove, you need to run the
benchmarks all on Gentoo, where you run with 4 categorizations:
1. Where you run PostgreSQL and GLIBC without any processor-specific
optimizations
2. Where you run PostgreSQL and GLIBC with all relevant
processor-specific optimizations
3. Where you run PostgreSQL with, and GLIBC without
processor-specific optimizations
4. Where you run PostgreSQL without, and GLIBC with processor-specific
optimizations
That would allow one to clearly distinguish which optimizations are
particularly relevant.
> I'm not saying that Gentoo is faster than FC6. I just want to prove
> that if you compile your software to make better use of your
> processor, it will run faster.
>
> It might take a few days because I'm pretty busy right now at my
> job.
I expect that you'll discover, if you actually do these tests, that
this belief is fairly much nonsense.
- Modern CPUs do a huge amount of on-CPU self-tuning.
- CPU features that could have a material effect tend to be unusable
when compiling general purpose libraries and applications. GCC
doesn't generate MMX-like instructions.
- Database application performance tends to be I/O driven.
- When database application performance *isn't* I/O driven, it is
likely to be driven by cache management, which compiler options
won't affect.
