Subject | Re: [Firebird-Architect] "Large Address Aware" - giving 3-4 GB of virtual memory to 32bit FB |
---|---|
Author | Jim Starkey |
Post date | 2006-02-04T12:56:14Z |
Kirill S. Palagin wrote:
much benefit from more. About all Firebird can do is increase the size
of the page cache, but a cache only helps for frequently accessed
pages. As long as the cache size is small relative to the database,
true random access is going to result in same miss rate for a cache
increased by only 50%. Once the frequently referenced pages are cache
resident, increasing the size of a cache has rapidly diminishing returns.
In the long run, Firebird needs to use memory to avoid unnecessary
recomputations. One example is the compiled statement cache. Another
is performing more analysis at compile time to reduce execution time
overhead. Clearly neither of these is going to happen in 1.5 or 2.0.
A more practical perspective is to run 32 bit clients against 64 bit
servers. From a technology perspective, this is a no brainer, but it
does require more sophistication in the buld and install procedures than
are currently in place. Vulcan is architected to support combined 32/64
bit kits, but unless Paul Reeves's latest iteration of the build
procedure pulls a rabit out of the hat, we don't have the procedures in
place to build such kits.
But with specific regard to Microsoft, neither Vulcan nor Firebird 2
have short term plans to support Win64. While this is mostly due to the
inavailability in a usable 64 bit compiler during the development cycle,
my perception is that 64 bit Microsoft platforms are at least two years
behind 64 bit Linux. The inavailability of many drivers for 64 bit
Windows means that it is regard by many as not quite ready for prime
time. Finally, the server licensing terms for Server 2003 and beyond
make Microsoft as a server platform highly unattractive. Speaking as
the lead Vulcan developer, I have to say that the excruciatingly slow
development and deployment and miserable quality of the beta release of
64 bit WinXP left me quite unexcited.
>Hello everybody.Firebird doesn't take enough advantage of existing address space to get
>
>I would like to know FB1.5/2 is/planned to be "Large Address Aware"?
>Reasoning for that below.
>
>
>
much benefit from more. About all Firebird can do is increase the size
of the page cache, but a cache only helps for frequently accessed
pages. As long as the cache size is small relative to the database,
true random access is going to result in same miss rate for a cache
increased by only 50%. Once the frequently referenced pages are cache
resident, increasing the size of a cache has rapidly diminishing returns.
In the long run, Firebird needs to use memory to avoid unnecessary
recomputations. One example is the compiled statement cache. Another
is performing more analysis at compile time to reduce execution time
overhead. Clearly neither of these is going to happen in 1.5 or 2.0.
A more practical perspective is to run 32 bit clients against 64 bit
servers. From a technology perspective, this is a no brainer, but it
does require more sophistication in the buld and install procedures than
are currently in place. Vulcan is architected to support combined 32/64
bit kits, but unless Paul Reeves's latest iteration of the build
procedure pulls a rabit out of the hat, we don't have the procedures in
place to build such kits.
But with specific regard to Microsoft, neither Vulcan nor Firebird 2
have short term plans to support Win64. While this is mostly due to the
inavailability in a usable 64 bit compiler during the development cycle,
my perception is that 64 bit Microsoft platforms are at least two years
behind 64 bit Linux. The inavailability of many drivers for 64 bit
Windows means that it is regard by many as not quite ready for prime
time. Finally, the server licensing terms for Server 2003 and beyond
make Microsoft as a server platform highly unattractive. Speaking as
the lead Vulcan developer, I have to say that the excruciatingly slow
development and deployment and miserable quality of the beta release of
64 bit WinXP left me quite unexcited.