[ODE] Re: ODE (and mainly OPCODE) for 64bits
Barog at pineapple-interactive.com
Thu Jan 20 14:21:07 MST 2005
The memory in OPCODE last time I checked was allocated as a large chunk
so the base+offset system will work fine as will the offset system I
suggested. As long as you aren't referencing too many nodes that is of
Using 4bytes (or less) is also nicer for the cache, doubling the size of
the pointer or index means you aren't getting as many nodes to your
cache space and thus slowing the system down.
Simon Barratt, Lead Developer, Pineapple Interactive Ltd
e: barog at pineapple-interactive.com
t: +44 (0) 1274 480185
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org] On Behalf Of
Sent: 20 January 2005 13:31
To: ode at q12.org
Subject: [ODE] Re: ODE (and mainly OPCODE) for 64bits
that's what I was wondering.
But maybe it would be a good compromize, even in speed:
- this would occurs ONLY when on a 64bits system (32bits system keep
- those systems are faster than 32bits ones => so, dispite of the 8
bytes/pointers waste, it may be faster to use opcode in a 64bits than in
a 32bits => it will allow to compile the entire application in 64bits,
and so, the general performances will be greater
making a kind of basepointer (64bits) + offset (32bits) won't work in a
64bits system, as all memory segments may be mapped everywhere within
the 64bits space.
I haven't look deep into opcode, so, I may be wrong, and you allocate
memory by yourself (the base+offset may work if you allocate all your
needed memory at once, and you are sure that the segment fits in a
32bits space (I believe it fits! ;)))
Selon Pierre Terdiman <pierre.terdiman at novodex.com>:
> > Well, I don't know, but it misses a typedef inside ICE:
> > for pointers...
> > Actually in the code, pointers may be casted into udword, which are
> > In a 64bits AMD64 architecture, pointers are 8 bytes...
> > So, the warnings we see at compile time.
> > I have no time to investigate more, and to add the pointer typedef
> > (and I
> > don't know if it is possible to make it fit into actual sctuctures)
> > If Pierre wants, I can cooperate with him for that port... (if it is
> > not longer than 2 or 3 evenings...)
> As far as I'm concerned, storing an 8-bytes pointer within the Opcode
> structures is just not an option. The whole point was to save some
> memory, I obviously don't want to waste it now, especially to store
> So, porting Opcode to 64-bits isn't as simple as changing the pointer
> To do that correctly you have to replace all the pointers with (32
> bit) indices, and give the collision code access to the base pointer
> (64 bit) so that it can recreate the correct addresses at runtime
> (which might be a small performance hit).
> Well, feel free to do it but I don't have time for this.
> - Pierre
ODE mailing list
ODE at q12.org
More information about the ODE