Was that from intel?
My impression--pieced together piecemeal from various sources--is that
'structure of arrays' was a design pattern and meme that arose in the late 90s
to early 2000s in the world of game development, and which was itself
ultimately a derivative of the earlier columnar stores--from at least the 70s,
if not earlier--which were common in finance for representing time-series tick
data, often in APL!
This pattern of columnar storage can better be seen as a special case of
_transposition_ of multidimensional data--that is dyadic |:--rearranging axes
such that common access patterns exhibit greater spatial locality wrt ravel
order (which is how arrays are generally represented in memory).
And this is why the view of one particular axis ordering which places short
axes at the end as an 'inefficient abstraction' is really naive. Locality is
an important aspect of optimisation, but locality is a property of accesses,
not of data structures, and in some cases what you call 'array of structures'
really is more efficient.
But really, the issue of transposition and columnarity is a bit of a giveaway:
these are all patterns that apply to _tabular_ data. Whereas the
distinguishing feature of 'objects'--_particularly_ in languages like j, which
are prototype-based--is their _heterogeneity_. They are good at modeling
nonuniform data in a way which may be harder with arrays. (I still don't know
a more space-efficient representation for graphs than an adjacency matrix.)
I prefer, then, to think of 'array spaces'. Any portion of an array space may
be realised at any given time by a named array; by a cell of an array; by an
intermediate array; by a function; by a cache; etc. A locale/object is a
flexible mechanism that is commonly used to hold some realisations of some
portions of some array spaces (among other things). That is a point of
flexibility and modularity, not performance!
And I will note that I would be somewhat surprised were any foundational
tenets of j's design were founded in performance. I expect it was just a
happy accident (or, perhaps, something a bit deeper than that, but not by
much) that arrays turned out to be fast.
And, again, it is surely a mistake to think that arrays will always be faster
than pointer-chasing. It is contextual. (I will avow that an array-oriented
language will _encourage_ array-oriented approaches, which may be faster than
the alternative where both are feasible.) To give one relevant, recent
example, I gave up on trying to represent bounding volume hierarchies in a way
consumable by I. (though some improvements to I.'s implementation are in the
pipeline, as a result of that, so it was not a complete waste). I would be
genuinely curious to know if somebody is able to come up with a good
array-oriented BVH construction.
-E
On Fri, 20 May 2022, Raul Miller wrote:
On Fri, May 20, 2022 at 1:29 PM Don Guinn <dongu...@gmail.com> wrote:
Just a thought. The management of numbered locales is not very efficient. A
while back I created several thousand locales as an object test. I went to
delete all of them and it took forever.
Right.
My understanding was that J's locales were designed to roughly
correspond with intel's "Structure of Arrays" abstraction.
As I understand it, Ken Iverson did not see much use for the popular
but inefficient abstractions which would roughly correspond with
intel's "Array of Structures" abstraction (with "objects being similar
to structures, but heavier).
In other words, for code where execution time is a bottleneck, the
purpose of J's locales should be thought of as being more analogous
(for example) to the purpose of Java's namespaces than the purpose of
Java's object system.
--
Raul
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
