Re: Circular references (was Re: [Algorithms] Reference counting hell... whatis a good paradigm.)

[Pierre T. <p.t...@wa...>]

BTW...

As I wrote before, one key advantage of IDs over pointers is that you can
move some resources in ram without invalidating the relations/links between
two objects. The way you reorganize the memory layout depends on your
runtime access patterns - as explained here once by Ville Miettinen IIRC, I
think the Umbra guys use "accessors" for this. (which sounds quite difficult
to avoid as soon as you use lazy evaluation all over the place)

Now, the whole point of the reorganization is to become cache-friendly, so I
guess this should be very efficient on PS2 according to your claims. And
since you just can't do it with pointers (at least not in such an automatic
way), IDs may finally well be the cache-friendly way :)

The little piece of code responsible for the ID-to-pointer translation is
not the problem IMO. This is exactly the same indirection (in my scheme) as
the one involved in virtual methods VS non-virtual ones. This is the same
overhead as well : virtually free on all modern computers. If it's not the
case on PS2, then I'm very happy not to program on PS2...

Pierre

----- Original Message -----
From: <Christer_Ericson@Playstation.sony.com>
To: <gda...@li...>
Sent: Wednesday, December 27, 2000 11:53 PM
Subject: Re: Circular references (was Re: [Algorithms] Reference counting
hell... whatis a good paradigm.)


>
>
> Gil Gribb wrote:
>
> >> Jim Offerman wrote:
> >> >The overhead of using smart pointers or id<->pointer mappings is
> becoming
> >> >negligiable these days ...
> >>
> >> Careful, not everyone on here targets (Intel-based) PCs.
> >>
> >> While your statement might be true for a PC sporting a CPU with a large
> L2
> >> cache, it can (read will) be quite detrimental on, say, a PS2 that
> doesn't
> >> have one.
> >
> >Well, you offer no alternative. As I have pointed out pointers simply
> don't
> >work for game entity cross references. I have a constant time scheme that
> >takes perhaps a dozen cycles, and it has exactly the same cache behaviour
> as
> >a pointers. Not much is going on today, so I will show a detailed
example.
>
>
> I merely meant to point out that on e.g. the PS2, hardly any memory
> accesses
> are "negligible". As it only has an 8K 2-way associative data cache, you
> really should go to great lengths to avoid ever reading outside the cache
> (by making use of the 16K scratchpad RAM, using tight data structures,
> etc).
>
> This drastically conflicts with programming a PC with a large L2-cache
> and has serious repercussions on how you design things.
>
> I'm sure this is one reason why we initially heard lots of PC developers
> complain about how hard the PS2 was to program for.
>
> I didn't mean to comment on the smart pointers vs. ID-to-pointer issue
> at all. Just to point out that on the PS2 any level of memory indirection
> can be quite expensive and should be avoided (if possible, of course).
>
> Of course, there will always be things such as time-memory trade-offs,
> but thinking about how to stay in cache should be the #1 thing in a
> PS2 programmer's mind.
>
>
> I'm not really at liberty to discuss the PS2 hardware further here (due to
> NDAs and all that crap), but the above info is all available on the net,
> at e.g.
>
> http://www.anarchists.co.uk/html/isscc.html
>
> for anyone who is interested in more detail.
>
>
> Christer Ericson
> SCEA, Santa Monica
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list