On Tuesday 08 June 2004 06:27, Brandon J. Van Every wrote:
> At the cost of inverting almost everyone's software architecture.

If you've hardcoded your routines to a particular way of accessing memory then 
that's hardly INRIA's fault. Even if it is with C macros, you should have 
structured your code so that your data structures could be changed later.

> This 
> is ridiculous / stupid in the real world.  It's also baloney on
> theoretical grounds: for just how many problems do you think it's worth
> destrying memory coherence by putting structure elements very far apart
> in memory?

Storing a matrix in transpose format is hardly going to "destroy" coherence. 
The only algorithms which would be significantly affected are those for which 
accesses are to (x_i, y_i, z_i) for random "i" rather than to (x_i, x_i+1, 
x_i+2) in which case (assuming the random accesses aren't to <cache sized 
regions) the performance must necessarily suffer regardless of the data 
structure. For sequential algorithms over sequences of any reasonable size, 
the performance will be virtually the same.

> SoA might make sense if a language implementation did it totally behind
> the scenes, presenting a seemingly AoS interface to programmers.

I think it should be done in a library, not in the language.

Cheers,
Jon.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners