3 ms·

I recently had a class project where we had similar issues. Being lazy students, we just let it perform slower for matrices of the wrong size; what is a good wa

• dpe82 15y ago
  Usually you just pad the rows a bit.
  • tikhonj 15y ago
    And now I feel silly for not having thought of that :)
    • dpe82 15y ago
      Happens to all of us. :) I remember the first time I saw an image data struct that specified bits per pixel, image width and then also had bytes per row. I was a bit perplexed about why you'd store bytes per row if you could just compute it from bpp and width. Turns out you can fix/avoid a lot of performance issues if you can pad the data, so it's good practice to always save the number of bytes per row and use that in your mallocs/copies/iterators/etc.
      • ssp 15y ago
        For images, one of the main reasons to have separate bytes-per-row (usually called stride or pitch) is that it allows you to have sub-images that use the same data and stride as the parent image, but a different width and height.
        • dpe82 15y ago
          Well, that too of course. :)
• buff-a 15y ago
  You pad the rows manually. Then you start loading bigger chunks of data at a time. Then you start issuing prefetch instructions with compiler intrinsics or inline assembly. Then you ask "why am I dealing with this at all?" and use Intel's math libraries. And finally you use Octave or Matlab. Unless you are a nutter like me, in which case you hand-roll everything in assembly.