On Wed, 2005-08-10 at 11:37 -0400, Tom Lane wrote:
> "Luke Lonergan" <LLonergan@greenplum.com> writes:
> > Yes, I think one thing we've learned is that there are important parts
> > of the code, those that are in the data path (COPY, sort, spill to
> > disk, etc) that are in dire need of optimization. For instance, the
> > fgetc() pattern should be banned everywhere in the data path.
>
> this discussion
> seems to presume that raw speed on Intel platforms is the only thing
> that matters. We have a few other concerns. Portability, readability,
> maintainability, and correctness all trump platform-specific
> optimizations.
I am interested in the general principle here, not this specific case.
As you know, I have raised the need for specific hardware tuning in
certain critical areas on a number of occasions. I very much respect the
need for all of the other aspects of code quality mentioned.
Pipeline parallelism is a feature of all modern CPUs since the Pentium,
not just Intel's. I think judicious exploitation of hardware features
that are common to multiple hardware architectures would be of
considerable benefit to everybody. We do already exploit some common
hardware tuning recommendations, such as buffer word alignment, but not
others such as false sharing avoidance and pipeline parallelism of key
loops. (There may be others...)
I say "judicious" because I do not presume that I am the judge ... but I
hope that judgements in these areas can fall towards the side of greater
performance as often as possible. Hardware and OS do exist, much as I
would prefer the simplicity of life in a layered IT architecture.
Best Regards, Simon Riggs
