Re: Linux: PAE or x64

On 15 December 2010 14:13, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> You're misreading poor Magnus.  He didn't offer any 'justification'
> regarding why there isn't a Win64 port.  He simply was pointing out, for
> those who assume every 'real' tool must be 64bit, that a 32bit PG is
> still a very viable and useful tool.  The reason there isn't a Win64
> port has everything to do with no one being interested enough to work on
> it, *because* PG runs decently as a 32bit app.  If you'd like to work on
> it, or pay someone to, I'm sure you'd find many in the community who
> would love to see it happen and might even be able to help.

Actually, there is a 64-bit port for windows now. I don't think I
misrepresented Magnus - the post suggested that the then-lack of a
64-bit windows port wasn't a pressing issue, and that various
technical considerations *partially* justified there not being one at
the time (the word size of binaries, and more importantly PG's
architecture). It's an assessment that I agreed with.

>> Perhaps it wasn't stressed too much, but
>> certainly it was treated as a greater than negligible issue:
>
> Compared to the costs of PAE?  The memory overhead is *well* worth it.
> Let's try to keep this in context here.

I wasn't making any comparison. Magnus's post didn't mention PAE, and
had nothing to do with it, but I just thought I'd draw attention to
where the idea probably originally came from. However, it's worth
noting that PAE still limits each individual process to a 32-bit
address space, so PG disproportionately benefits from it (at least for
high-concurrency use cases, which are the use cases where PG excels
generally).

What Magnus said is supported (albeit sort of weakly) by this:
http://msdn.microsoft.com/en-us/library/ee418798(v=vs.85).aspx

"When you compile applications as 64-bit, the calculations get more
complicated. A 64-bit program uses 64-bit pointers, and its
instructions are slightly larger, so the memory requirement is
slightly increased. This can cause a slight drop in performance. On
the other hand, having twice as many registers and having the ability
to do 64-bit integer calculations in a single instruction will often
more than compensate. The net result is that a 64-bit application
might run slightly slower than the same application compiled as
32-bit, but it will often run slightly faster."

--
Regards,
Peter Geoghegan