English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] 32 bit floats, SSE instructions
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-06-08 (19:16)
From: Brandon J. Van Every <vanevery@i...>
Subject: RE: [Caml-list] 32 bit floats, SSE instructions
Jon Harrop
> Brandon J. Van Every wrote:
> > [SoA is performed]
> > 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.

What utter nonsense!  You ever written a 3D device driver?  You do *not*
engineer your most basic data structures for infinite flexibility.
Almost nobody has the luxury of defining things so abastractly that they
can switch SoA for AoS whenever they like.  It's a highly invasive
change of programming model.

The experiment of SoA has been tried in the 3D graphics industry and
found wanting.  All the HW is AoS.  The SoA methodology is possible with
the 3D APIs.  As one poster hinted, it's probably borne of the software
rendering era mentality.  I distinctly recall when the DirectX 5.0 guys
were implementing those features, shortly after the OpenGL guys did
IIRC.  That would have been a 1997 timeframe.  They were thinking how
"neat" it would all be.  Seen from the vantage of 2004, it all gave way
to AoS and programmable shaders.  All your data for one vertex or one
pixel at a time.

> 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

Oh, the 'only' algorithms.  Crikey.  You ever written a 3D graphics
pipeline???  You think it's all based on handing over some huge matrix
that could jolly well be in whatever order?  Get real.  The vast
majority of 3D graphics processing is accept / reject testing.  You want
your data here, now, so you can decide what to do with it.  So you can
retire it once you're done deciding, and not have it pollute your cache
any further.

Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
                                - Ed Mckenzie
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.693 / Virus Database: 454 - Release Date: 5/31/2004

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