6 ms·

I have to say that most bottlenecks are from lazy designs, not wimpy hardware. As a thought experiment, suppose parallel processing scaled easily without worryi

by tabtab 8y ago

I have to say that most bottlenecks are from lazy designs, not wimpy hardware. As a thought experiment, suppose parallel processing scaled easily without worrying about Amdahl's Law and similar bottlenecks. So then we put 128 cores into our computers. Software companies would eat up every single core eventually if there's no penalty for inefficient coding. They don't pay our electric bill, we do. It's kind of like freeways: the more you build, the more the traffic increases to fill them up again. It is "nice" to be able to slap components together like magic legos and/or a Dagwood Sandwich rather than smartly tune and coordinate everything, but doing such is often computationally inefficient. The speed of light will probably put a hard upper limit on this practice that no clever language or architecture can work around to a notable degree.

chubot 8y ago
Yes, a pithier way of saying this is: Software is a gas; it expands to fill its container - Nathan Myhrvold Bad performance isn't really a software design problem; it's an economics problem (ditto for security). You could speed up the browser by 2x now, or reduce it's memory usage by 2x, and websites would be exactly as slow after a few months. I'm not trying to be negative here, just stating an unfortunate systems dynamic.
- tabtab 8y ago
  I generally agree: it's about weighing trade-offs, and calling software companies "lazy" is perhaps an oversimplification. However, I do believe the speed of light and size of atoms puts an upper limit on the degree you can keep throwing hardware at the problem. We may continue to find tricks such as quantum computing, but I suspect it will get ever tougher. There's a theoretical limit to how small you squeeze data and to how fast it can transfer.
  - the8472 8y ago
    > We may continue to find tricks such as quantum computing Quantum computing does not magically speed up general purpose computing tasks. We only know a handful of algorithms where quantum computers provide algorithmic complexity reductions and even that that does not mean they necessarily calculate fast in terms of IPC, they just calculate previously intractable problems in reasonable timescales. TL;DR: you won't pop quantum GPUs/CPUs into your computer and suddenly get 50 times the framerates in DOOM.
    - jfoutz 8y ago
      Totally glib reply, but here it is. If I can represent screen state as quibits, and I have a whole lot of quibits, I can represent a game as a little list of player inputs. Set up an enormous superposition, and as players hit keys, collapse the next frame. The imaginary hardware could be super quick! TL;DR: yeah probably, but you never know.
      - deleted 8y ago
        [deleted]
    - tabtab 8y ago
      Some have suggested that certain common algorithms (or needs) can be rewritten into the types QC are good at. I'm not an expert so cannot confirm such. It may await new algorithm discoveries to answer anyhow.
  - TheCoelacanth 8y ago
    Software companies are lazy in exactly the same way that the entire rest of the economy is lazy. Companies in every industry try to cut costs as much as they can.
    - chubot 8y ago
      That's only half of it. Users choose software, and that includes developers when choosing programming languages / OSes / servers. We are "lazy" too. If you really cared about security without regard to any other property, you would probably be using DJB's software to serve your website and such. But you probably don't, because it doesn't have the features you want and you might not want to spend the time figuring out how to set it up.
- gone35 8y ago
  Bad performance isn't really a software design problem; it's an economics problem (ditto for security). Why do you say so?
  - saagarjha 8y ago
    It means that people haven't thrown enough {time, energy, money} at the problem.
    - Retra 8y ago
      I think the idea is that people stop optimizing for speed as soon as it gets "fast enough", and what "fast enough" means doesn't change at all if you make better tools and machines. Faster machines and tools only really matters to people who are trying to do things that are currently never fast enough to put into production.
    - chubot 8y ago
      Not quite.. see my sibling response. It's probably more accurate to say that some people have thrown a lot of time and energy at the problem. But the market does not value their software; we use slower and less secure alternatives. Slack is a great example. There are probably 99 other chat services that perform better than Slack. (Apparently it makes fans spin on laptops, which is kind of shocking for a chat app.) But the market doesn't necessarily care -- it values the features that Slack provides more. Part of it is a bad network effect. I care about speed, but I might have to use Slack because the people I want to talk to on Slack don't care about speed.
  - saltcured 8y ago
    Product developers make cost-benefit decisions all the time and much of the cost of slow or insecure software is externalized. A knee in the developer-visible cost-benefit curve represents the MVP everyone is so keen to release to market.
  - chubot 8y ago
    To be clearer, I would say that software is exactly as fast and secure as the market will bear. There is probably an economics term I can cite to explain this better, like some kind of equilibrium (I appreciate any help explaining this). But the sibling basically got it half-right -- software developers and designers are always making cost-benefit decisions. The other half of it is that consumers tend to choose features rather than security. The are ALREADY faster and more secure alternatives to every piece of software you use -- you just don't use them because they don't have the features you want! People vote with their feet, and what we end up with is not the fastest or most secure situation, because there are tradeoffs. This applies to developers too -- not just end users. I mean why do people choose Python, PHP, or JavaScript? There are faster languages out there. There are languages that could help you write more secure applications. But those languages have the features and library ecosystem we want, so we use them. ---- I'm one of those people who laments slow and insecure software. But doing my own open source project has kind of brought home the tradeoffs. I've been working for over 2 years on an open source Unix shell. It's written in Python [1], which is not exactly the right tool for the job. But if I wrote it in C or C++ or Rust, it would take 4 or 6 or 10 years. So unforunately it is too slow, but there's a tradeoff between being slow and being fast but not existing and nobody using it. (Although I have a plan to fix it, basically outlined in that blog post. Not sure how much effort it will take, but I think less than rewriting from scratch.) It's an economics problem -- if it doesn't have the features people already use, then they'll have to rewrite their software. Rewriting shell scripts costs a lot of money and it doesn't have a lot of advantages. It's more economical for one person/team to emulate bash in a new shell, than for the entire world to rewrite their scripts. This recent blog post has the same sentiment buried in there: https://apenwarr.ca/log/20180914 https://apenwarr.ca/log/20180914 XHTML didn't succeed because it's more economical for a single browser vendor to make a really complicated parsing algorithm than it is for every single person in the world to change how they write HTML. It's not like we don't KNOW how to design strict data formats, or we don't KNOW how to make secure software. (e.g. ask yourself why more people aren't using DJB's software.) It's matter of economics -- how much effort are the people making decisions willing to put in, and how much the market rewards them for it. We can certainly improve the situation by valuing secure and fast software, and that has happened in the past. Windows used to be an utter disaster security-wise, but Microsoft realized that it was more than the market would bear, and they changed their whole attitude toward security. Although if you want to be cynical, you can also say they made the "right" move to ship first and make things secure later :-( [1] http://www.oilshell.org/blog/2018/03/04.html http://www.oilshell.org/blog/2018/03/04.html
jayd16 8y ago
>It's kind of like freeways: the more you build, the more the traffic increases to fill them up again. I see this a lot. Is this a real phenomenon? Seems like an inevitability to me. Who would build a freeway they didn't expect people to use?
- Liskni_si 8y ago
  Yes, see https://en.wikipedia.org/wiki/Induced_demand https://en.wikipedia.org/wiki/Induced_demand

by tabtab 8y ago

chubot 8y ago

Yes, a pithier way of saying this is: Software is a gas; it expands to fill its container - Nathan Myhrvold Bad performance isn't really a software design problem; it's an economics problem (ditto for security). You could speed up the browser by 2x now, or reduce it's memory usage by 2x, and websites would be exactly as slow after a few months. I'm not trying to be negative here, just stating an unfortunate systems dynamic.

tabtab 8y ago
I generally agree: it's about weighing trade-offs, and calling software companies "lazy" is perhaps an oversimplification. However, I do believe the speed of light and size of atoms puts an upper limit on the degree you can keep throwing hardware at the problem. We may continue to find tricks such as quantum computing, but I suspect it will get ever tougher. There's a theoretical limit to how small you squeeze data and to how fast it can transfer.
- the8472 8y ago
  > We may continue to find tricks such as quantum computing Quantum computing does not magically speed up general purpose computing tasks. We only know a handful of algorithms where quantum computers provide algorithmic complexity reductions and even that that does not mean they necessarily calculate fast in terms of IPC, they just calculate previously intractable problems in reasonable timescales. TL;DR: you won't pop quantum GPUs/CPUs into your computer and suddenly get 50 times the framerates in DOOM.
  - jfoutz 8y ago
    Totally glib reply, but here it is. If I can represent screen state as quibits, and I have a whole lot of quibits, I can represent a game as a little list of player inputs. Set up an enormous superposition, and as players hit keys, collapse the next frame. The imaginary hardware could be super quick! TL;DR: yeah probably, but you never know.
    - deleted 8y ago
      [deleted]
  - tabtab 8y ago
    Some have suggested that certain common algorithms (or needs) can be rewritten into the types QC are good at. I'm not an expert so cannot confirm such. It may await new algorithm discoveries to answer anyhow.
- TheCoelacanth 8y ago
  Software companies are lazy in exactly the same way that the entire rest of the economy is lazy. Companies in every industry try to cut costs as much as they can.
  - chubot 8y ago
    That's only half of it. Users choose software, and that includes developers when choosing programming languages / OSes / servers. We are "lazy" too. If you really cared about security without regard to any other property, you would probably be using DJB's software to serve your website and such. But you probably don't, because it doesn't have the features you want and you might not want to spend the time figuring out how to set it up.
gone35 8y ago
Bad performance isn't really a software design problem; it's an economics problem (ditto for security). Why do you say so?
- saagarjha 8y ago
  It means that people haven't thrown enough {time, energy, money} at the problem.
  - Retra 8y ago
    I think the idea is that people stop optimizing for speed as soon as it gets "fast enough", and what "fast enough" means doesn't change at all if you make better tools and machines. Faster machines and tools only really matters to people who are trying to do things that are currently never fast enough to put into production.
  - chubot 8y ago
    Not quite.. see my sibling response. It's probably more accurate to say that some people have thrown a lot of time and energy at the problem. But the market does not value their software; we use slower and less secure alternatives. Slack is a great example. There are probably 99 other chat services that perform better than Slack. (Apparently it makes fans spin on laptops, which is kind of shocking for a chat app.) But the market doesn't necessarily care -- it values the features that Slack provides more. Part of it is a bad network effect. I care about speed, but I might have to use Slack because the people I want to talk to on Slack don't care about speed.
- saltcured 8y ago
  Product developers make cost-benefit decisions all the time and much of the cost of slow or insecure software is externalized. A knee in the developer-visible cost-benefit curve represents the MVP everyone is so keen to release to market.
- chubot 8y ago
  To be clearer, I would say that software is exactly as fast and secure as the market will bear. There is probably an economics term I can cite to explain this better, like some kind of equilibrium (I appreciate any help explaining this). But the sibling basically got it half-right -- software developers and designers are always making cost-benefit decisions. The other half of it is that consumers tend to choose features rather than security. The are ALREADY faster and more secure alternatives to every piece of software you use -- you just don't use them because they don't have the features you want! People vote with their feet, and what we end up with is not the fastest or most secure situation, because there are tradeoffs. This applies to developers too -- not just end users. I mean why do people choose Python, PHP, or JavaScript? There are faster languages out there. There are languages that could help you write more secure applications. But those languages have the features and library ecosystem we want, so we use them. ---- I'm one of those people who laments slow and insecure software. But doing my own open source project has kind of brought home the tradeoffs. I've been working for over 2 years on an open source Unix shell. It's written in Python [1], which is not exactly the right tool for the job. But if I wrote it in C or C++ or Rust, it would take 4 or 6 or 10 years. So unforunately it is too slow, but there's a tradeoff between being slow and being fast but not existing and nobody using it. (Although I have a plan to fix it, basically outlined in that blog post. Not sure how much effort it will take, but I think less than rewriting from scratch.) It's an economics problem -- if it doesn't have the features people already use, then they'll have to rewrite their software. Rewriting shell scripts costs a lot of money and it doesn't have a lot of advantages. It's more economical for one person/team to emulate bash in a new shell, than for the entire world to rewrite their scripts. This recent blog post has the same sentiment buried in there: https://apenwarr.ca/log/20180914 https://apenwarr.ca/log/20180914 XHTML didn't succeed because it's more economical for a single browser vendor to make a really complicated parsing algorithm than it is for every single person in the world to change how they write HTML. It's not like we don't KNOW how to design strict data formats, or we don't KNOW how to make secure software. (e.g. ask yourself why more people aren't using DJB's software.) It's matter of economics -- how much effort are the people making decisions willing to put in, and how much the market rewards them for it. We can certainly improve the situation by valuing secure and fast software, and that has happened in the past. Windows used to be an utter disaster security-wise, but Microsoft realized that it was more than the market would bear, and they changed their whole attitude toward security. Although if you want to be cynical, you can also say they made the "right" move to ship first and make things secure later :-( [1] http://www.oilshell.org/blog/2018/03/04.html http://www.oilshell.org/blog/2018/03/04.html

jayd16 8y ago

>It's kind of like freeways: the more you build, the more the traffic increases to fill them up again. I see this a lot. Is this a real phenomenon? Seems like an inevitability to me. Who would build a freeway they didn't expect people to use?

Liskni_si 8y ago
Yes, see https://en.wikipedia.org/wiki/Induced_demand https://en.wikipedia.org/wiki/Induced_demand