[Bug r2506] freelist_t does not support 64-bit compilations

[knightly]

A bug has been reported by Pugget <a href="http://forum.simutrans.com/index.php?topic=2405.msg24070#msg24070">here</a>, and I have found the cause of it (please see my explanation lower in that thread).

Although for the time being Simutrans Standards doesn't seem to request 4-bytes memory pieces from freelist_t, it is still safer to fix it and make freelist_t 64-bit compliant.

Thank you very much for your attention.

[prissi]

As new is called quite often, and for million of objects, another check as well a granularity of 8 is not desired. Maybe rather init the first enry with (const void *)-1, this should give a memory error when accessing it.

[jamespetts]

If it just generates a memory error, doesn't that just change the nature of the problem rather than solving it?

[prissi]

I just put 4 Byte entries to 8 Byte for the time being in freelist; it should work for experimental too.

[jamespetts]

Thank you very much :-)

[knightly]

@ Prissi

I don't know if this will work or not, but how about adding a static const variable to freelist_t :

   static const uint8 min_size = (uint8) ( sizeof(freelist_t*) >> 2 );

and then use this in

   size = max( min_size, size );

I guess when someone tries to compile a 64-bit version, sizeof(freelist_t*) will return 8 during compile time. In this way, 32-bit version can still use 4-byte memory pieces.

[prissi]

I am neutral on this, as it will be very unlikely that I will use 4 byte pieces via new (since this will impact chaching quite bad ... ) So this can be used too.

[jamespetts]

In either event, all of this should be behind an #ifdef for 64-but, shouldn't it?

[prissi]

No; proper C code should do without that. The part that would need a different structure are the data of treeobj and grund_t and palnquadrat_t, as they consume much memory and an misalignment is wasted memory. Unfourtunately this is very much architecture and compilerdependent. It is currently optimized for GCC 3.x 32bit on windows; any other compiler wastes usually some space.

Furthermore in the foreseeable future there will be no official 64bit release, due to the disadvantages of using 64bit. (Of course only for plattforms that does not require 64bit. But most of them are only workstations or higher ... )

[jamespetts]

Prissi,

when I tried to use it with Simutrans-Experimental, I got a freelist error when I loaded Pak128...

[knightly]

Thanks for considering my suggestion, Prissi.

I am neutral on this, as it will be very unlikely that I will use 4 byte pieces via new (since this will impact chaching quite bad ... ) So this can be used too.

May I know why using 4-byte memory pieces will impact caching badly?

[jamespetts]

Prissi,

aha, thank you - the latest change now makes it work. Very helpful!

[prissi]

@Knightly
Any quantity that is scattered in four byte block around the memory is bad, since most processors need to read 16Byte block at least to get a single bit. Thus arrays are much much needed for performance, if there is not a *very* good reason to do otherwise. The objects on the map are not acessed too often, and moreover some of them are even multiples of 16Bytes. Moreover, as there are millions of them, no other option is left.

BTW: Standard malloc will at least return a 16Byte chunk ...

[knightly]

I see. Thanks a lot for your explanation, Prissi