5 ms·

This is the laziest argument ever made. Hardware is continuing to improve in performance, it's just that the gains are focused on things like power efficiency

This is the laziest argument ever made. Hardware is continuing to improve in performance, it's just that the gains are focused on things like power efficiency rather than brute force. Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. If you want to live in some grim world where everything is shit and nothing will ever get fixed, knock yourself out, but the truth of the matter is there's relentless and significant improvements being made across the board.

mpweiher 10y ago
> JavaScript engines, to use but one example, are consistently getting faster. JavaScript is your example for efficient software? Hmm... The only thing happening with JavaScript is trying to optimize away all the incredible inefficiency of the original design, at tremendous expense. And the reason we are doing this in the first place is that we are now re-implementing all sorts of desktop software in JavaScript...typically at least an order of magnitude bigger and slower. So thanks for making my point for me. EDIT: And I am sorry that you perceive my message as "grim". I personally find it hopeful, because we have massive untapped power lurking in the machines we already have, no Intel-provided improvements needed.
- pcwalton 10y ago
  JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive source of inefficiency compared to, say, PHP. Not to mention the rose-colored glasses we see the past in: folks back in the '90s used to work day in and day out with VB6 (or even interpreted Java) apps.
  - candiodari 10y ago
    Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.
    - pcwalton 10y ago
      > Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
      - candiodari 10y ago
        Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...
  - mpweiher 10y ago
    > JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
- gm-conspiracy 10y ago
  I agree with you and disagree with parent. Remember the original Blackberry 950? https://en.wikipedia.org/wiki/BlackBerry_950 https://en.wikipedia.org/wiki/BlackBerry_950 It was a 80386 w/ 512KB of SRAM and 4MB of storage, and it ran on a single AA battery for days. ..or a VAX/11? 32-bits in 1997: https://en.wikipedia.org/wiki/VAX#Processor_architecture https://en.wikipedia.org/wiki/VAX#Processor_architecture
  - gm-conspiracy 10y ago
    meant 1977.
- astrodust 10y ago
  JavaScript is surprisingly fast and can easily outperform Ruby, Python, and PHP. It can at times keep up with or exceed Java, which is extremely popular. How many gigawatt-hours of power are spent on an annual basis to run trashy, completely unoptimized PHP scripts? But okay, blame JavaScript. Sure, you can piss all over JavaScript for having been shitty and slow, but it's not like that any longer. A lot of people worked very hard to dig it out of that ditch it was born in and make it into something that performs well. It does everything Java promised and a whole lot more. This is not the world anyone predicted would happen. > ...we are now re-implementing all sorts of desktop software in JavaScript... Have you stopped to ask yourself why? It's cross-platform. It's ubiquitous. It's fast enough. Name another language that's as effortless to get started with, that's as insanely portable, that can be distributed easily through innumerable delivery channels. Java? Nope. C++? Hardly. C? Not really. It's easy to sit in an armchair and bitch about how crappy things are, how much "power" we have lurking in these machines, and yet do nothing to tap into it. What language do you use most frequently? What improvements could be made to that? No language is at its performance peak, not even long-time performance champions like C++ or C. There's still tons of room for compiler optimizations, for new libraries that better vectorize things, for better design patterns that make use of multiple cores better. This is all at the language level as well. What about kernel issues? Linux is far from flawless. BSD could us improvements. That's not to say there aren't people working to make these things better, to push performance. If these things are hard, that's the answer to why things aren't improving to your satisfaction.
  - flukus 10y ago
    > Sure, you can piss all over JavaScript for having been shitty and slow, but it's not like that any longer. A lot of people worked very hard to dig it out of that ditch it was born in and make it into something that performs well. And yet electron apps are still shitty and slow. Funny how you only compare javascript to languages that have always performed poorly on desktops and not something apps are actually built in, like c/c++/c#.
    - astrodust 10y ago
      The original versions of things built with NodeWebKit and Electron were unbearably slow, it's true, but they've come a long way. If you want to build a cross-platform desktop application with any of C, C++ or C# knock yourself out. Someone using Electron will have good-enough prototype within weeks while you're still working on your build process. Where you can focus on one OS you can get better results with a pure C++, Objective-C, or Swift result, but when going cross-platform it massively complicates things. Today JavaScript is a pretty good answer to that problem, and performance is adequate enough people are willing to pay the price in terms of footprint. Software that exists but is suboptimal is better than software that doesn't exist but is hypothetically better. If you don't like those applications and think you can knock out something better in C++, by all means, but you've got quite a hill to climb. Microsoft Visual Code, as one example was written deliberately using Electron even though Microsoft obviously has some amazingly talented C++ people who can build cross-platform applications: Microsoft Office and a compiler. I don't think they took that decision lightly.
usrusr 10y ago
> JavaScript engines, to use but one example, are consistently getting faster. When was the last time you where really impressed with https://arewefastyet.com/ https://arewefastyet.com/ ? Recent improvements are looking more like stragglers catching up with the state of the art than like the state of the art improving much. This is a very good thing, but it is not consistently getting faster. More like "getting more consistently fast". Good, but not the same. Actually it seems to be the exact same pattern of approaching a wall as we see (and lament) with desktop CPUs.
anexprogrammer 10y ago
Rather missing the point that we've replaced much native software with thin clients running JS in a browser or pretending to be an app. Whether it needs to be or not. For many reasons - multi device support, convenience, data harvesting, lock in. Performance isn't something we generally get now everything becomes network constrained rather than CPU or IO. So yeah it's being fixed because it has to be, because it's a terrible experience in comparison. I don't deny that often the convenience far outweighs the loss of performance and latency. You can't avoid the fact it's heavily skewed the market against those needing native power on the desktop. If you're doing things that need that, the last 5 years have been rather underwhelming progress wise.
flukus 10y ago
> Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. That's the point. We've seen hardware improve but we've had a net loss of performance because a lot of stuff has moved to web apps and other "higher level" languages.
josteink 10y ago
> JavaScript engines, to use but one example, are consistently getting faster. And now people write basic user-space tools in Javascript instead of C, with a basic 100 libraries bolted on as dependencies, where only 0.1% of the code is ever used, but you'll also need to boot the JS runtime before any of this code even runs. Guess which tool is faster. The C one or the JS one? I'm not saying "Do everything in C" (I'm rather in the opposite camp), but he does have a quite valid argument there.

mpweiher 10y ago

> JavaScript engines, to use but one example, are consistently getting faster. JavaScript is your example for efficient software? Hmm... The only thing happening with JavaScript is trying to optimize away all the incredible inefficiency of the original design, at tremendous expense. And the reason we are doing this in the first place is that we are now re-implementing all sorts of desktop software in JavaScript...typically at least an order of magnitude bigger and slower. So thanks for making my point for me. EDIT: And I am sorry that you perceive my message as "grim". I personally find it hopeful, because we have massive untapped power lurking in the machines we already have, no Intel-provided improvements needed.

pcwalton 10y ago
JS is quite a bit faster than, say, idiomatic Objective-C. Or Java run through Dalvik. Personally, I don't see why everyone focuses on JavaScript as a massive source of inefficiency compared to, say, PHP. Not to mention the rose-colored glasses we see the past in: folks back in the '90s used to work day in and day out with VB6 (or even interpreted Java) apps.
- candiodari 10y ago
  Comparing browser games with Dalvik games on 1/4th the cpu/gpu as on my desktop, I feel obliged to point out: Nope. Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Javascript does not match Java in speed, not regular java, nor Dalvik. Comparing node.js apps with PHP apps, it doesn't match PHP performance either.
  - pcwalton 10y ago
    > Now this may be that browsers just suck at graphics, or at games in general. Perhaps. Does it matter ? No. Yes, it does, because I'm talking about JavaScript. Not about the entire browser graphics stack (which, by the way, is architecturally better than that of Android). > Javascript does not match Java in speed, not regular java, nor Dalvik. No, Dalvik is slow compared to JS. Its trace based architecture is roughly on par with JS engines in 2009. > Comparing node.js apps with PHP apps, it doesn't match PHP performance either. Zend doesn't even have a JIT.
    - candiodari 10y ago
      Well, that may be true, and a big plus for the developers of those systems, but if the results aren't there, what's the point ? Even if it's browser APIs rather than directly the language/interpreters ...
- mpweiher 10y ago
  > JS is quite a bit faster than, say, idiomatic Objective-C. (a) That depends hugely on what you consider "idiomatic" Objective-C and (b) yeah, that's kind of my point. If you write Objective-C in the style that is currently popular and propagated, treating it as a unified programming language like JS, Java or Smalltalk, you're going to be slow. In my book[1], I show how easy it is to be slower not just than JS or Java, but even slower than a byte-coded Smalltalk interpreter or Ruby. And the sad part is that it's not even particularly expressive! On the other hand, I also show how you can use the original Objective-C style, let's call it "Software-ICs", to create an XML parser faster than libxml and with a much nicer interface, or a Postscript interpreter that uses Objective-C objects as Postscript objects and is still faster than Adobe's interpreter (written in C) for most basic language stuff like arithmetic and loops (it doesn't do the graphics itself, so comparing those numbers would be pointless). In fact, said Postscript interpreter, written in Objective-C, is faster at arithmetic than the "bad" Objective-C style, while doing automatic arithmetic promotion, so being safer. The "Software-IC" style for Objective-C involves fast components written in C connected at the architectural level by dynamic messaging. It is highly idiomatic, convenient, fun and fast as hell. Interestingly, variations of that basic style are being rediscovered these days by the people doing "imperative shell, functional core". See for example Gary Bernhard's talk[2] and then tell me that the final picture doesn't look almost exactly like the pictures Cox drew of Software-ICs (and remember that Cox also said that (a) messaging didn't have to be synchronous and (b) the implementation language for the Software ICs didn't matter much). The Unix tools are also very similar, with fast components written in C connected at the architectural level with pipes. This is also the reason why I think my Objective-Smalltalk language[3] actually has a good chance of enabling very fast programs despite the very high level of abstraction it is aiming for. Being able to pick an appropriate interconnection style and fast components is the key to fast software. Back to the original point, we are leaving orders of magnitude of performance on the table, quite frequently for no particular reason. And as I wrote elsewhere, I actually think this current point we have reached is good for software and for software people, because we can get that performance quite easily by writing decent code, and writing decent code is starting to matter more again. Just like I think the end of Moore's law might finally break the stranglehold Intel has had on hardware architecture, so innovative architectures (remember the Transputer[4]?) have a chance and aren't clobbered by Intel's next fab-step. Speaking of innovative hardware architecture, has there been any new news on the Mill? Interesting times. Anyway, I didn't bring up JavaScript, this problem is everywhere. I just thought that bringing it up as a counterpoint was...humorous. [1] Did I mention my book? g https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-OS-Performance-Tuning-Cocoa-Cocoa-Touch-Objective-C-and-Swift/PGM161424.html https://www.pearsonhighered.com/program/Weiher-i-OS-and-mac-... [2] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries [3] http://objective.st/ http://objective.st/ [4] https://en.wikipedia.org/wiki/Transputer https://en.wikipedia.org/wiki/Transputer
gm-conspiracy 10y ago
I agree with you and disagree with parent. Remember the original Blackberry 950? https://en.wikipedia.org/wiki/BlackBerry_950 https://en.wikipedia.org/wiki/BlackBerry_950 It was a 80386 w/ 512KB of SRAM and 4MB of storage, and it ran on a single AA battery for days. ..or a VAX/11? 32-bits in 1997: https://en.wikipedia.org/wiki/VAX#Processor_architecture https://en.wikipedia.org/wiki/VAX#Processor_architecture
- gm-conspiracy 10y ago
  meant 1977.
astrodust 10y ago
JavaScript is surprisingly fast and can easily outperform Ruby, Python, and PHP. It can at times keep up with or exceed Java, which is extremely popular. How many gigawatt-hours of power are spent on an annual basis to run trashy, completely unoptimized PHP scripts? But okay, blame JavaScript. Sure, you can piss all over JavaScript for having been shitty and slow, but it's not like that any longer. A lot of people worked very hard to dig it out of that ditch it was born in and make it into something that performs well. It does everything Java promised and a whole lot more. This is not the world anyone predicted would happen. > ...we are now re-implementing all sorts of desktop software in JavaScript... Have you stopped to ask yourself why? It's cross-platform. It's ubiquitous. It's fast enough. Name another language that's as effortless to get started with, that's as insanely portable, that can be distributed easily through innumerable delivery channels. Java? Nope. C++? Hardly. C? Not really. It's easy to sit in an armchair and bitch about how crappy things are, how much "power" we have lurking in these machines, and yet do nothing to tap into it. What language do you use most frequently? What improvements could be made to that? No language is at its performance peak, not even long-time performance champions like C++ or C. There's still tons of room for compiler optimizations, for new libraries that better vectorize things, for better design patterns that make use of multiple cores better. This is all at the language level as well. What about kernel issues? Linux is far from flawless. BSD could us improvements. That's not to say there aren't people working to make these things better, to push performance. If these things are hard, that's the answer to why things aren't improving to your satisfaction.
- flukus 10y ago
  > Sure, you can piss all over JavaScript for having been shitty and slow, but it's not like that any longer. A lot of people worked very hard to dig it out of that ditch it was born in and make it into something that performs well. And yet electron apps are still shitty and slow. Funny how you only compare javascript to languages that have always performed poorly on desktops and not something apps are actually built in, like c/c++/c#.
  - astrodust 10y ago
    The original versions of things built with NodeWebKit and Electron were unbearably slow, it's true, but they've come a long way. If you want to build a cross-platform desktop application with any of C, C++ or C# knock yourself out. Someone using Electron will have good-enough prototype within weeks while you're still working on your build process. Where you can focus on one OS you can get better results with a pure C++, Objective-C, or Swift result, but when going cross-platform it massively complicates things. Today JavaScript is a pretty good answer to that problem, and performance is adequate enough people are willing to pay the price in terms of footprint. Software that exists but is suboptimal is better than software that doesn't exist but is hypothetically better. If you don't like those applications and think you can knock out something better in C++, by all means, but you've got quite a hill to climb. Microsoft Visual Code, as one example was written deliberately using Electron even though Microsoft obviously has some amazingly talented C++ people who can build cross-platform applications: Microsoft Office and a compiler. I don't think they took that decision lightly.

usrusr 10y ago

> JavaScript engines, to use but one example, are consistently getting faster. When was the last time you where really impressed with https://arewefastyet.com/ https://arewefastyet.com/ ? Recent improvements are looking more like stragglers catching up with the state of the art than like the state of the art improving much. This is a very good thing, but it is not consistently getting faster. More like "getting more consistently fast". Good, but not the same. Actually it seems to be the exact same pattern of approaching a wall as we see (and lament) with desktop CPUs.

anexprogrammer 10y ago

Rather missing the point that we've replaced much native software with thin clients running JS in a browser or pretending to be an app. Whether it needs to be or not. For many reasons - multi device support, convenience, data harvesting, lock in. Performance isn't something we generally get now everything becomes network constrained rather than CPU or IO. So yeah it's being fixed because it has to be, because it's a terrible experience in comparison. I don't deny that often the convenience far outweighs the loss of performance and latency. You can't avoid the fact it's heavily skewed the market against those needing native power on the desktop. If you're doing things that need that, the last 5 years have been rather underwhelming progress wise.

flukus 10y ago

> Likewise, software continues to improve in performance: JavaScript engines, to use but one example, are consistently getting faster. That's the point. We've seen hardware improve but we've had a net loss of performance because a lot of stuff has moved to web apps and other "higher level" languages.

josteink 10y ago

> JavaScript engines, to use but one example, are consistently getting faster. And now people write basic user-space tools in Javascript instead of C, with a basic 100 libraries bolted on as dependencies, where only 0.1% of the code is ever used, but you'll also need to boot the JS runtime before any of this code even runs. Guess which tool is faster. The C one or the JS one? I'm not saying "Do everything in C" (I'm rather in the opposite camp), but he does have a quite valid argument there.