5 ms·

I'm a big fan of writing simple, portable code that is structured enough to let the compiler optimize it to perfection. If you do it right, a naive A' * B multi

I'm a big fan of writing simple, portable code that is structured enough to let the compiler optimize it to perfection. If you do it right, a naive A' * B multiplier can be within 20% of BLAS performance, at least for non-huge matrices. Now, when you need that code on some embedded platform or for emscripten or whatever, it'll just work and be really tiny too.

PeCaN 8y ago
Unfortunately, matrix multiplication is the kind of thing where you often need it to be fast and scale to huge matrices. I like simple code as much as the next guy, but occasionally you do need to write fast code.
ummonk 8y ago
It's the huge matrices where performance matters, and a naive multiplier for that will use memory rather inefficiently.
- svantana 8y ago
  > It's the huge matrices where performance matters I wouldn't say that, just look at CGI where a lot of effort is spent making fast 4x4 matrix multiplies. But yeah, a general matrix mult needs to scale, but a lot of the time you know what size you will run and you can optimize for that.
ziotom78 8y ago
Except that, when you are writing scientific code to solve a large linear problem, like a weather model or asupernova simulation, the difference between some naïve code and a heavily optimized one can be ten hours against ten days...
- carlmr 8y ago
  If it's within 20% of BLAS performance it shouldn't be the difference between ten hours and ten days. That must be something else then.
  - ziotom78 8y ago
    The figure "20%" alone means nothing. You are probably meaning, "20% in this specific benchmark with "non-huge matrices" (as said by the OP). Algorithms can show wildly different performance when run on small-scale and large-scale inputs.
    - carlmr 8y ago
      Well then you have to still test it if it's still 20% or not. I haven't written the code, I just think you shouldn't have to resort to hyperbole (ten hours, ten days) if the comment above doesn't warrant it.
EpicEng 8y ago
In my experience, the people who leave comments like yours are the ones who don't often have to solve real performance problems. The compiler can't do it all (and, specifically, won't help you in the case the article discusses), and those who write code used in performance sensitive applications and/or libs used by literally millions of people have to know this stuff. Where do those people learn when they're starting out if everyone tells them to "stop thinking stupid, your compiler is smarter than you"? I for one am glad they spend a lot of time thinking about it so that you don't have to and can instead spend your time opining on forums about premature optimization.
- svantana 8y ago
  Speculative ad hominem aside, the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code. It's not trivial and can include a lot of trial and error and looking at assembly. But once you learn these tricks, code can be clean, portable and performant, I would say that's a win.
  - EpicEng 8y ago
    > Speculative ad hominem aside I can only judge you by what you say here. Obviously I don't know you, but what other choice do I have? In my experience, those who rely on their tools to do everything for them are useless when things go sideways. > the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code No, the point is that comments like yours serve little purpose. No one is suggesting that you should roll your own lib for matrix math in every situation. However, if you _understand_ what happens behind the scenes you write better code and can more easily diagnose performance issues. The problem with "don't worry about it" type responses is that sometimes you _do_ end up having to worry about it, and now you're not equipped to solve the problem. Hell, you may not even know that there is a problem to begin with because you have no idea what the runtime characteristics of your algorithm _should_ be. Maybe you'll have to write some code like this someday. How would you know if your algorithm is performing well? Perhaps you think your 10 hour run is totally acceptible... until someone who read this article and has some experience comes by. They laugh at the absurd performance and spend a bit of time making it 60% faster _because they know how this stuff works_. There's a lot of value in learning how things work, and "premature optimization" responses like you see all over SO are worthless.
deleted 8y ago
[deleted]

PeCaN 8y ago

Unfortunately, matrix multiplication is the kind of thing where you often need it to be fast and scale to huge matrices. I like simple code as much as the next guy, but occasionally you do need to write fast code.

ummonk 8y ago

It's the huge matrices where performance matters, and a naive multiplier for that will use memory rather inefficiently.

svantana 8y ago
> It's the huge matrices where performance matters I wouldn't say that, just look at CGI where a lot of effort is spent making fast 4x4 matrix multiplies. But yeah, a general matrix mult needs to scale, but a lot of the time you know what size you will run and you can optimize for that.

ziotom78 8y ago

Except that, when you are writing scientific code to solve a large linear problem, like a weather model or asupernova simulation, the difference between some naïve code and a heavily optimized one can be ten hours against ten days...

carlmr 8y ago
If it's within 20% of BLAS performance it shouldn't be the difference between ten hours and ten days. That must be something else then.
- ziotom78 8y ago
  The figure "20%" alone means nothing. You are probably meaning, "20% in this specific benchmark with "non-huge matrices" (as said by the OP). Algorithms can show wildly different performance when run on small-scale and large-scale inputs.
  - carlmr 8y ago
    Well then you have to still test it if it's still 20% or not. I haven't written the code, I just think you shouldn't have to resort to hyperbole (ten hours, ten days) if the comment above doesn't warrant it.

EpicEng 8y ago

In my experience, the people who leave comments like yours are the ones who don't often have to solve real performance problems. The compiler can't do it all (and, specifically, won't help you in the case the article discusses), and those who write code used in performance sensitive applications and/or libs used by literally millions of people have to know this stuff. Where do those people learn when they're starting out if everyone tells them to "stop thinking stupid, your compiler is smarter than you"? I for one am glad they spend a lot of time thinking about it so that you don't have to and can instead spend your time opining on forums about premature optimization.

svantana 8y ago
Speculative ad hominem aside, the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code. It's not trivial and can include a lot of trial and error and looking at assembly. But once you learn these tricks, code can be clean, portable and performant, I would say that's a win.
- EpicEng 8y ago
  > Speculative ad hominem aside I can only judge you by what you say here. Obviously I don't know you, but what other choice do I have? In my experience, those who rely on their tools to do everything for them are useless when things go sideways. > the point in this case was to learn to write code so that good compilers can output performant SIMD-heavy code No, the point is that comments like yours serve little purpose. No one is suggesting that you should roll your own lib for matrix math in every situation. However, if you _understand_ what happens behind the scenes you write better code and can more easily diagnose performance issues. The problem with "don't worry about it" type responses is that sometimes you _do_ end up having to worry about it, and now you're not equipped to solve the problem. Hell, you may not even know that there is a problem to begin with because you have no idea what the runtime characteristics of your algorithm _should_ be. Maybe you'll have to write some code like this someday. How would you know if your algorithm is performing well? Perhaps you think your 10 hour run is totally acceptible... until someone who read this article and has some experience comes by. They laugh at the absurd performance and spend a bit of time making it 60% faster _because they know how this stuff works_. There's a lot of value in learning how things work, and "premature optimization" responses like you see all over SO are worthless.

deleted 8y ago

[deleted]