[Octave-bug-tracker] [bug #59840] repmat and repelem slower than needed, faster implimentation suggested

[Nicholas Jankowski]

Follow-up Comment #11, bug #59840 (project octave):

I haven't seen significant changes to repmat or repelem in some time.  Note
that when I helped write Octave's repelem a few years ago, the main focus was
creating a compatible implementation, catching all of the corner cases.  I did
some small optimizations around small inputs, and avoided adding the overhead
of repmat calls for obvious reasons, but didn't do extensive speed tests.
There was, and still is, an existing Octave-only function called repelems that
only does 1D repeats and only works on numeric arrays, but as a compiled
function it's much faster. A lot of Octave code still uses it over repelem
because of the speed difference. 

The extensive look into problem-size algorithm choice is generally useful.  We
ran into a similar discussion trying to decide on the appropriate algorithm
for 2D triangulation (see delaunayn bug #60818).  It turns out one algorithm
was faster up to complexity X, another kron-based one was better beyond that
but resulted in much higher memory use to the point where a number of places
it was faster couldn't be completed due to OOM issues. Some lightweight
algorithm selection routine could be generally useful. But memory footprint of
the approach really should be part of that consideration as well and would
require machine specific knowledge.  (maybe OOM is less of an issue here,
though since the output is intended to be a multiple in size of the input, if
any intermediates don't exceed this significantly)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59840>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/