On Mon, Aug 21, 2006 at 10:23:16AM -0400, Douglas McNaught wrote: > [EMAIL PROTECTED] writes: > > I believe the answer is no. No or few 64-bit optimization possibilities > > have been chased down, probably because some or many of these would: > > 1) require significant re-architecture > > 2) reduce the performance in a 32-bit world > Honestly, I think the main "optimizations" happen automatically: the > compiler uses the extra registers (if present) and pointers in LP64 > mode are automatically 64-bit, which allows much larger memory areas. > That's probably 95% of the win right there. What other > "optimizations" need doing?
Compilers are getting smarter, but having code profiled, and hand tuned for 32-bits does not automatically get compiled with a 64-bit compiler, to code that has been profile, and hand tuned for 64-bit. An example of this is in how algorithms are implemented. For Intel-style processors at least, using array offsets is cheaper than using many pointers. For 64-bit processors, 32-bit array offsets would use less memory. For re-architecture, the first thing that came to mind was Datum increasing in size. Copy by value instead of allocating a pointer, and passing the pointer. The pointer will be 64-bits, so Datum could support 64-bits as well. Tom caught this, but he did point out what I missed. This would only benefit data types that are 64-bits in length, which are still likely uncommon (most people would use serial, not bigserial). Has anybody taken any of the 64-bit processor optimization manuals, and walked through it, cross referencing it against bottleneck programs in PostgreSQL? To counter this, I suggest to you that most every attempt to optimize PostgreSQL for performance reasons, likely considered variations in algorithms measured on a 32-bit processor, finally selecting the version that was simplest, and best performing, on a 32-bit processor. This is normal evolution for a piece of software. It is naturally optimized for the processor that is most used by the users. I'm not the expert on the matter. I don't see evidence that anybody has taken this route though. > People have been running PG with big databases on 64-bit iron for > years; don't you think any glaring infelicities would have been > addressed? I doubt there are 'glaring infelicities'. I doubt any changes required to provide a noticeable speed improvement would be one liners. They will not be obvious. They will require a complete understanding of the many architectural differences between common 32-bit processors, and common 64-bit processors. Few have this information in their head. I don't. I suspect that anybody who claims that the only difference is the amount of addressable memory, and the number of registers doesn't. :-) > > It's a question that only half interests me. As with most projects, I > > don't think the projects are ready to re-architect for this > > purpose. > What re-architecting would be needed? I'm asking that it be admitted that it has not been looked at. Not seriously. Nor is this unique to PostgreSQL. I expect the performance for Linux applications in general to slowly improve on 64-bit processors as more and more people begin to use it. I recall a few threads on other mailing lists where the primary developers admitted to not having ready access to a 64-bit machine. Until they do, the chance that these applications are hand-tuned for 64-bit is unlikely. I'm not claiming that I have the answers. I am claiming that a few of you share this weakness, and that an assumption that PostgreSQL is designed for 64-bit would be incorrect. :-) Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __________________________ . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them... http://mark.mielke.cc/ ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend