Subject | RE: [Firebird-Architect] "Large Address Aware" - giving 3-4 GB of virtual memory to 32bit FB |
---|---|
Author | Kirill S. Palagin |
Post date | 2006-02-04T21:13:24Z |
Given current state of affairs with IB I have to go after low hanging
fruits, i.e. increase page cache to highest allowed by IB/FB/Ya.
With specific respect to Windows, IMO, drivers are available for hardware
that is important on the server side.
Where can I read more about lack of usable compiler for Win64?
Thanks a lot for your explanation and for sharing your expertise in
Architect and Devel - some pieces are eye-opening.
WBR,
KP.
fruits, i.e. increase page cache to highest allowed by IB/FB/Ya.
With specific respect to Windows, IMO, drivers are available for hardware
that is important on the server side.
Where can I read more about lack of usable compiler for Win64?
Thanks a lot for your explanation and for sharing your expertise in
Architect and Devel - some pieces are eye-opening.
WBR,
KP.
> -----Original Message-----
> From: Jim Starkey [mailto:jas@...]
> Sent: Saturday, February 04, 2006 3:56 PM
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] "Large Address Aware" -
> giving 3-4 GB of virtual memory to 32bit FB
>
> Kirill S. Palagin wrote:
>
> >Hello everybody.
> >
> >I would like to know FB1.5/2 is/planned to be "Large Address Aware"?
> >Reasoning for that below.
> >
> >
> >
> Firebird doesn't take enough advantage of existing address
> space to get 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.
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>