7 ms·

I don't really understand how the author is managing to contradict the previous HN discussion. https://news.ycombinator.com/item?id=7301913 https://news.ycombi

by nemasu 13y ago

I don't really understand how the author is managing to contradict the previous HN discussion. https://news.ycombinator.com/item?id=7301913 https://news.ycombinator.com/item?id=7301913

dvanduzer 13y ago
The author of the (current title of) the post is presumably hinging the argument on the definition of 'expert' described in this video: http://www.youtube.com/watch?v=BKorP55Aqvg http://www.youtube.com/watch?v=BKorP55Aqvg
chris_overseas 13y ago
Well the previous discussion was centered around the same assembly implementation as this one. The only difference is, in the previous discussion the fastest C/C++ implementation was 1.1x slower than the assembly. In this current discussion, the author managed to write a C++ implementation that runs faster than the assembly version.
- nemasu 13y ago
  Okay, but as far as I can tell he changed the algorithm (recursive c++, pop/push to global array, etc) ... doesn't that kind of negate the argument unless you change it in the assembly version as well?
  - chris_overseas 13y ago
    True enough. That reinforces a couple of other points that tend to become apparent from these sorts of comparisons and benchmarks: 1) High level languages are easier to refactor and maintain than lower level languages (changing the algorithm in the assembly's a big job). 2) For performance, the algorithm used is almost always more important than the language you choose to implement it in. Both of those points back up the author's assertion, it's a shame he didn't specifically discuss them. I used to hand-code assembly (or generate it, eg "compiled bitmaps") back in the 8086 days. For many situations there were easy gains to be had that couldn't be achieved so easily in high level languages. These days I wouldn't dream of attempting it other than perhaps for vector code in an inner loop. I'd far rather spend the time profiling and optimising the algorithms and data structures because that's where the big gains are going to be. To go ahead and implement something in assembly when the algorithm clearly isn't yet optimal is perhaps fun but also kinda insane.

by nemasu 13y ago

I don't really understand how the author is managing to contradict the previous HN discussion. https://news.ycombinator.com/item?id=7301913 https://news.ycombinator.com/item?id=7301913

dvanduzer 13y ago

The author of the (current title of) the post is presumably hinging the argument on the definition of 'expert' described in this video: http://www.youtube.com/watch?v=BKorP55Aqvg http://www.youtube.com/watch?v=BKorP55Aqvg

chris_overseas 13y ago

Well the previous discussion was centered around the same assembly implementation as this one. The only difference is, in the previous discussion the fastest C/C++ implementation was 1.1x slower than the assembly. In this current discussion, the author managed to write a C++ implementation that runs faster than the assembly version.

nemasu 13y ago
Okay, but as far as I can tell he changed the algorithm (recursive c++, pop/push to global array, etc) ... doesn't that kind of negate the argument unless you change it in the assembly version as well?
- chris_overseas 13y ago
  True enough. That reinforces a couple of other points that tend to become apparent from these sorts of comparisons and benchmarks: 1) High level languages are easier to refactor and maintain than lower level languages (changing the algorithm in the assembly's a big job). 2) For performance, the algorithm used is almost always more important than the language you choose to implement it in. Both of those points back up the author's assertion, it's a shame he didn't specifically discuss them. I used to hand-code assembly (or generate it, eg "compiled bitmaps") back in the 8086 days. For many situations there were easy gains to be had that couldn't be achieved so easily in high level languages. These days I wouldn't dream of attempting it other than perhaps for vector code in an inner loop. I'd far rather spend the time profiling and optimising the algorithms and data structures because that's where the big gains are going to be. To go ahead and implement something in assembly when the algorithm clearly isn't yet optimal is perhaps fun but also kinda insane.