JasonB (no@spam.com) on 8/25/09 wrote:
---------------------------

>As I've said before:
>
>1. That cost will be present in the parallel processing case as well,

Sure. But you're talking about the difference between
the two cases being 1000x. And I'm saying it's probably
more like 10x or 20x. Because the data has to move around
in both cases. It probably has to move several extra
times in my approach. And if the difference turns out to
be 50x, then I'll need 500uS granules instead of your 10uS
granules. And that would be just fine for what I'm
doing (though smaller/quicker is better, obviously).

>2. It can be a free lunch if there is enough computation between accesses
>and the predictors work well enough that the latency is completely hidden.

My view of performance is that programs move data around,
and that's what costs the time. ALU operations these days
are mostly free. I'm pretty sure that's the right way
to analyze the app I work on. For some well-tuned
compute-intensive kernels you can get a working set in
registers and/or L1 cache and run for a while in compute-
bound rather than memory-bound mode. But that's not
the normal case.

One thing I didn't mention yet is that copying the data
can sometimes reveal more parallelism. Compare to
register renaming.

>There's no issue with the data structures in the serial >case.

I can't make sense of that. Choosing a good data
structure for each algorithm is the main way to optimize
code (serial or parallel).

>I would suggest that trying to do anything remotely complicated with programmers
>that don't have a clue is a bad idea.

And I would agree with you 110%. But it's the normal case,
as well as being the particular case I have to deal with.

>As I mentioned above, the handful of const methods that we have that return pointers
>to things only return const pointers, thereby ensuring constness is transitive.
>The logic behind it is that if you're asking an object for a pointer to something,
>chances are the "something" should be thought of as part of the state of that object,
>and therefore if the object is const, the pointer should be as well.

Probably a reasonable view. But then we're back to trying
to enforce subtle rules across a large codebase, which
just doesn't fly in the culture I'm in.

>I would consider a whole mess of classes returning pointers to all sorts of other
>classes to be a sign of poor encapsulation,

Definitely. But it is what it is, ripping it up and
starting again is not an option for me, nor for most
projects.