[Octave-bug-tracker] [bug #60928] Performance of sort unexpectedly slow for DIM=2

[Michael Leitner]

Follow-up Comment #16, bug #60928 (project octave):

Well done. I would think that the purpose of the code would perhaps be still
more obvious if the for-loop over j would be written as two loops, the inner
(j1) counting up to stride, the outer (j2) counting up to
dv.numel()/(ns*stride), and forming offset just as offset=j1+j2*ns*stride. Or
rather incrementing j2 by ns*stride, going up to dv.numel(), and having
offset=j1+j2. 

Disregarding that, you could try whether it is even worth it having the
special case for stride==1. According to your timing data, sorting along the
first dimension with the special-case code is about 10% faster than for the
other dimensions (no special case). It is quite plausible that also for the
non-optimized path sorting along the first dimension is fastest, so if the
special case gives in the end only, say, 3% added efficiency, it is
questionable whether it is worth the complication. The difference is that in
the non special case, the data are copied from the in-array into a buffer,
sorted there, and copied into the out-array, while in the special case they
are directly copied into the out-array and sorted there. 

    _______________________________________________________

Reply to this item at:

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

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