[TUHS] block operations in editors, was My EuroBSDcon talk
scj at yaccman.com
Wed Sep 18 14:47:47 AEST 2019
This is one of my pet peeves. "Random Access" memory is far from
random when you look at the time it takes to do the accesses. With
modern memories, accessing a column can be 20 to 40x slower than
accessing a row. This is particularly irritating when doing AI
training, where training reuses 4-d tensors transposed, a very painful
In FORTRAN days, I once used a vector package in which you described a
vector by giving the first element, the second element, and a count.
So you could describe rows, columns, a matrix diagonal, and even rows
and columns from back to front. Fortran passed arguments by address,
which made the whole thing easy and fast.
----- Original Message -----
From: "Doug McIlroy" <doug at cs.dartmouth.edu>
To:<tuhs at tuhs.org>, <jnc at mercury.lcs.mit.edu>
Sent:Tue, 17 Sep 2019 13:31:52 -0400
Subject:Re: [TUHS] block operations in editors, was My EuroBSDcon talk
Noel Chiappa wrote:
> > From: Doug McIlroy
> > the absence of multidemensional arrays in C.
>?? From the 'C Reference Manual' (no date, but circa 'Typesetter
C'), pg. 11:
> "If the unadorned declarator D would specify an n-dimensional array
> the declarator D[in+1] yields an (n+1)-dimensional array"
>I'm not sure if I've _ever_ used one, but they are there.
Yes, C allows arrays of arrays, and I've used them aplenty.
However an "n-dimensional array" has one favored dimension,
out of which you can slice an array of lower dimension. For
example, you can pass a row of a 2D array to a function of a
1D variable, but you can't pass a column. That asymmetry
underlies my assertion. In Python, by contrast, n-dimensional
arrays can be sliced on any dimension.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS