[Mono-dev] How To Convince Mono To Allocate Big Arrays
Luis F. Ortiz
LuisOrtiz at Verizon.Net
Thu May 8 11:05:37 EDT 2008
On May 8, 2008, at 9:32 AM, Jonathan Pryor wrote:
> On Thu, 2008-05-08 at 08:45 -0300, Rodrigo Kumpera wrote:
>> We want to keep changes to a minimum
> Understandable.
>
>> and we want to keep default array size 32bits.
> This I still don't understand. The implication is that the only way
> to
> get 64-bit arrays on 64-bit platforms is to install your own mono, and
> not use any prebuilt RPMs (as -- presumably -- the prebuilt RPMs would
> use the default array size of 32bits).
>
> Why would we want to do this? Do 64-bit arrays have a performance
> cost
> that would show up in real apps (and not just benchmarks)?
Jon, for what it is worth, on 64 bit platforms, the additional fixed
costs are the
doubling of the size of the array lengths and bounds "suffix" to the
array,
which is peanuts, and additional computation time for validating the
64 array
dimensions, which is slightly more expensive.
The 64 bit array extensions as I implemented them also have a cost for
32 bit arrays,
because you now need to fetch a 64 bit word for the array length for
doing bounds checking,
and you need to check to see that the 64 bit length can be validly
converted to a 32 bit length
and throw an exception if that is not the case when using the 32 bit
length property. The
additional exception throwing logic is the biggest cost JITed code-
wise. I am not aware of
any impact on code size for 32 bit vs 64 bit indexing itself.
Those is the biggest costs imposed. Both are necessary if you are to
avoid bizarre breakage.
Are they killers for mono embedders? I don't know.
/Ortiz/Luis
More information about the Mono-devel-list
mailing list