3 ms·

> I originally missed your point about "multiples of" That wasn't my point, but the claim of the poster I was replying to, and it was exactly this claim that

> I originally missed your point about "multiples of" That wasn't my point, but the claim of the poster I was replying to, and it was exactly this claim that I think is unsupportable. Has some software gotten faster? Sure. But mostly software has a gotten slower and the rarer cases of software getting faster have been outpaced significantly by HW. > You want examples where software has sped up at a rate faster than hardware "several multiples": that in some/many areas software has improved performance by several multiples of the improvement in hardware performance over the last 20 years > [JavaScript] JIT compilers have improved The original JITs were done in the late 80s early 90s. And their practical impact is far less then the claimed impact. http://blog.metaobject.com/2015/10/jitterdammerung.html http://blog.metaobject.com/2015/10/jitterdammerung.html As an example the Cog VM is a JIT for Squeak. They claim a 5x speedup in bytecodes/s. Nice. However the naive bytecode interpreter, in C, on commodity hardware in 1999 (Pentium/400) was 45 times faster than the one microcoded on a Xerox Dorado in 1984, which was a high-end, custom-built ECL machine costing many hundred thousands of dollars. (19m bytecodes/s vs. 400k bytecodes/s). So 5x for software, at least 45x for hardware. And the hardware kept improving afterward, nowadays at least another 10x. > [compilers] Parsing isn't as simple as it seems [..] Parsing is not where the time goes. > 2005-era swift running faster Swift generally has not gotten faster at all. I refer you back to Proebsting's Law and the evidence gathered in the paper: optimizer (=software) improvements achieve in decades what hardware achieves/achieved in a year. There are several researchers that say optimization has run out of steam. https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf https://www.youtube.com/watch?v=r-TLSBdHe1A https://www.youtube.com/watch?v=r-TLSBdHe1A (the difference between -O2 and -O3 is just noise) > Big-O notation should speak for itself It usually does not. Many if not most improvements in Big-O these days are purely theoretical findings that have no practical impact on the software people actually run. I remember when I was studying that "interior point methods" were making a big splash, because they were the first linear optimization algorithms that had polynomial complexity, whereas the Simplex algorithm is NP-hard. I don't know what the current state is, but at the time the reaction was a big shrug. Why? Although Simplex is NP-hard, it typically runs in linear or close to linear time and is thus much, much faster than the interior point methods. Similar for recent findings of slightly improved multiplication algorithms. The n required for the asymptotic complexity to overcome the overheads is so large that the results are theoretical. > FFT The Wikipedia link you provided goes to algorithms from the 1960s and 1940s, so not sure how applicable that is to the question of "has software performance improvement in the last 20 years outpaced hardware improvement by multiples?". Are you perchance answering a completely different question? > [H264/H265] I'm talking specifically about SW implementations Right, and the improvements in SW implementations don't begin to reach the improvement that comes from moving significant parts to dedicated hardware. And yes, you have to modify the software to actually talk to the hardware, but you're not seriously trying to argue that this means this is a software improvement??

MayeulC 6y ago
Another example recently cropped on HN: https://news.ycombinator.com/item?id=24544232 https://news.ycombinator.com/item?id=24544232 > Parsing is not where the time goes. Not with the current algorithms. But let's agree to put this argument to a rest. I generally agree with you that 1. Current software practices are wasteful, and it's getting worse 2. According to 1. most performance improvements can be attributed to HW gains. I originally just wanted to point out that this was true in general, but that there were exceptions, and that hot paths are optimized. Other tendencies are at play, though, such as the end of dennard's scaling. I tend to agree with https://news.ycombinator.com/item?id=24515035 https://news.ycombinator.com/item?id=24515035 and to achieve future gains, we might need tighter coupling between HW and SW evolution, as general-purpose processors might not continue to improve as much. Feel free to disagree, this is conjecture. > And yes, you have to modify the software to actually talk to the hardware, but you're not seriously trying to argue that this means this is a software improvement?? My point was more or less the same as the one made in the previously linked article: HW changes have made some SW faster, other comparatively slower. These two do not exist in isolated bubbles. I'm talking of off-the-shelf HW, obviously. HW gets to pick which algorithms are considered "efficient".
- mpweiher 6y ago
  > Parsing [current algorithms] Recursive descent has been around forever, the Wikipedia[1] page mentions a reference from 1975[2]. What recent advances have there been in parsing performance? > 1. Current software practices are wasteful, and it's getting worse > 2. According to 1. most performance improvements can be attributed to HW gains. Agreed. 3. Even when there were advances in software performance, they were outpaced by HW improvements, certainly typically and almost invariably. [1] https://en.wikipedia.org/wiki/Recursive_descent_parser#References https://en.wikipedia.org/wiki/Recursive_descent_parser#Refer... [2] https://archive.org/details/recursiveprogram0000burg https://archive.org/details/recursiveprogram0000burg

MayeulC 6y ago

Another example recently cropped on HN: https://news.ycombinator.com/item?id=24544232 https://news.ycombinator.com/item?id=24544232 > Parsing is not where the time goes. Not with the current algorithms. But let's agree to put this argument to a rest. I generally agree with you that 1. Current software practices are wasteful, and it's getting worse 2. According to 1. most performance improvements can be attributed to HW gains. I originally just wanted to point out that this was true in general, but that there were exceptions, and that hot paths are optimized. Other tendencies are at play, though, such as the end of dennard's scaling. I tend to agree with https://news.ycombinator.com/item?id=24515035 https://news.ycombinator.com/item?id=24515035 and to achieve future gains, we might need tighter coupling between HW and SW evolution, as general-purpose processors might not continue to improve as much. Feel free to disagree, this is conjecture. > And yes, you have to modify the software to actually talk to the hardware, but you're not seriously trying to argue that this means this is a software improvement?? My point was more or less the same as the one made in the previously linked article: HW changes have made some SW faster, other comparatively slower. These two do not exist in isolated bubbles. I'm talking of off-the-shelf HW, obviously. HW gets to pick which algorithms are considered "efficient".

mpweiher 6y ago
> Parsing [current algorithms] Recursive descent has been around forever, the Wikipedia[1] page mentions a reference from 1975[2]. What recent advances have there been in parsing performance? > 1. Current software practices are wasteful, and it's getting worse > 2. According to 1. most performance improvements can be attributed to HW gains. Agreed. 3. Even when there were advances in software performance, they were outpaced by HW improvements, certainly typically and almost invariably. [1] https://en.wikipedia.org/wiki/Recursive_descent_parser#References https://en.wikipedia.org/wiki/Recursive_descent_parser#Refer... [2] https://archive.org/details/recursiveprogram0000burg https://archive.org/details/recursiveprogram0000burg