[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  
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.


More information about the Mono-devel-list mailing list