4 ms·

I'm intrigued by the one law (unless I missed something) that he says definitely no longer applies: > Wirth's Law > Software performance gets slower faster th

I'm intrigued by the one law (unless I missed something) that he says definitely no longer applies: > Wirth's Law > Software performance gets slower faster than hardware speed gets faster. > This law was formulated by Niklaus Wirth during the days of mainframes and seemed to work for them. However, for networked microprocessors and parallel computing, the law no longer seems to hold. Certainly it holds for some things. My first computer (late 1970s) started up in less than a second. A decade later I had to wait perhaps 20 seconds. Today waiting a full minute for a computer to get to a usable state is not at all unusual. On the other hand, we have Google, which, in a fraction of a second, can do things undreamed of only a few years ago. This leads to what I think is an interesting line of inquiry. What kids of software does this law still apply to? Why does it apply there and not elsewhere? And what can we do about it?

pjmlp 13y ago
It applies to the bloat in software development nowadays with layers on top of layers that seldom add any real value to the product.
- seanmcdirmid 13y ago
  That is definitely the myth, where is the non-anecdotal evidence that this statement is actually true?
  - mpweiher 13y ago
    "Spending Moore's Dividend" was a 2009 CACM article (paywalled): http://cacm.acm.org/magazines/2009/5/24648-spending-moores-dividend/fulltext http://cacm.acm.org/magazines/2009/5/24648-spending-moores-d... Microsoft Research has a version of the article (not exactly identical): http://research.microsoft.com/pubs/70581/tr-2008-69.pdf http://research.microsoft.com/pubs/70581/tr-2008-69.pdf I also discuss this in my (unfinished) book, with lots of data: http://www.amazon.com/Objective-C-Performance-Tuning-Developers-Library/dp/0321842847 http://www.amazon.com/Objective-C-Performance-Tuning-Develop... The whole book is / will be (well, the manuscript is) full of examples of techniques that are 2x, 10x or even 100x slower than necessary, but now "recommended practice", often for no discernible benefit.
    - seanmcdirmid 13y ago
      Nothing in the Larus article states that extra software overhead is just wasted without any real benefit; we do get benefits from it: * Increased functionality * Increased programmer productivity (programmers are often more scarce than available CPU cycles) * The bottlenecks have changed The thesis being challenged in grandparent (pjmlp): > It applies to the bloat in software development nowadays with layers on top of layers that seldom add any real value to the product. implies that we are just being wasteful for no real benefit, but we are obviously getting more functionality in or writing more software via increased programmer productivity. Now that power is more of an issue for mobile, we are seeing programmers be more thrifty again, but that is not without a cost in productivity.
  - pjmlp 13y ago
    For example: - Compiling to a VM + JIT instead of AOT compilation - Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly - Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions Just a few examples out of my head.
    - seanmcdirmid 13y ago
      > Compiling to a VM + JIT instead of AOT compilation Sun tried this and the code actually got slower. > Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly Flexibility to run on a VM is a huge time saver. > Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions Cheaper (less skilled) programmers means more code can get written (for better or worse).
      - pjmlp 13y ago
        > Sun tried this and the code actually got slower. Who is speaking about Java here? Optimizing compilers for other languages are a proof that AOT compilation at the end wins. > Flexibility to run on a VM is a huge time saver. Of course it is, we just don't need the huge amount of layers the current VM cakes have. Software needs to go to the gym. > Cheaper (less skilled) programmers means more code can get written (for better or worse). Ergo less quality that leads to software bloat like Wirth states.
        seanmcdirmid 13y ago
        Your original point was that the layers served no value, but you are agreeing that they do serve value, just not the value that you particularly appreciate. Worse is better. At least better than nothing.
renox 13y ago
>Certainly it holds for some things. Two points: 1) at one point in time, I triple booted between Windows, BeOS (yes it's a long time ago) and Linux: Linux and Windows booted far slowly than BeOS (don't remember exactly but it was >1min while BeOS was 14sec) and afterwards felt less responsive than BeOS.. BeOS is dead though (yes, I know about Haiku). 2) Buy a SSD and you won't have to wait anymore 'a full minute' to have your computer in an usable state..

pjmlp 13y ago

It applies to the bloat in software development nowadays with layers on top of layers that seldom add any real value to the product.

seanmcdirmid 13y ago
That is definitely the myth, where is the non-anecdotal evidence that this statement is actually true?
- mpweiher 13y ago
  "Spending Moore's Dividend" was a 2009 CACM article (paywalled): http://cacm.acm.org/magazines/2009/5/24648-spending-moores-dividend/fulltext http://cacm.acm.org/magazines/2009/5/24648-spending-moores-d... Microsoft Research has a version of the article (not exactly identical): http://research.microsoft.com/pubs/70581/tr-2008-69.pdf http://research.microsoft.com/pubs/70581/tr-2008-69.pdf I also discuss this in my (unfinished) book, with lots of data: http://www.amazon.com/Objective-C-Performance-Tuning-Developers-Library/dp/0321842847 http://www.amazon.com/Objective-C-Performance-Tuning-Develop... The whole book is / will be (well, the manuscript is) full of examples of techniques that are 2x, 10x or even 100x slower than necessary, but now "recommended practice", often for no discernible benefit.
  - seanmcdirmid 13y ago
    Nothing in the Larus article states that extra software overhead is just wasted without any real benefit; we do get benefits from it: * Increased functionality * Increased programmer productivity (programmers are often more scarce than available CPU cycles) * The bottlenecks have changed The thesis being challenged in grandparent (pjmlp): > It applies to the bloat in software development nowadays with layers on top of layers that seldom add any real value to the product. implies that we are just being wasteful for no real benefit, but we are obviously getting more functionality in or writing more software via increased programmer productivity. Now that power is more of an issue for mobile, we are seeing programmers be more thrifty again, but that is not without a cost in productivity.
- pjmlp 13y ago
  For example: - Compiling to a VM + JIT instead of AOT compilation - Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly - Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions Just a few examples out of my head.
  - seanmcdirmid 13y ago
    > Compiling to a VM + JIT instead of AOT compilation Sun tried this and the code actually got slower. > Running a programming language VM with an OS agnostic runtime, on a OS VM running on a hypervisor, instead of running the said programming language VM on top of the hypervisor directly Flexibility to run on a VM is a huge time saver. > Use of data structures and algorithms that take much more memory and are slower, because many developers lack proper knowledge to use the right ones and use whatever first result comes on their IDE completion suggestions Cheaper (less skilled) programmers means more code can get written (for better or worse).
    - pjmlp 13y ago
      > Sun tried this and the code actually got slower. Who is speaking about Java here? Optimizing compilers for other languages are a proof that AOT compilation at the end wins. > Flexibility to run on a VM is a huge time saver. Of course it is, we just don't need the huge amount of layers the current VM cakes have. Software needs to go to the gym. > Cheaper (less skilled) programmers means more code can get written (for better or worse). Ergo less quality that leads to software bloat like Wirth states.
      - seanmcdirmid 13y ago
        Your original point was that the layers served no value, but you are agreeing that they do serve value, just not the value that you particularly appreciate. Worse is better. At least better than nothing.

renox 13y ago

>Certainly it holds for some things. Two points: 1) at one point in time, I triple booted between Windows, BeOS (yes it's a long time ago) and Linux: Linux and Windows booted far slowly than BeOS (don't remember exactly but it was >1min while BeOS was 14sec) and afterwards felt less responsive than BeOS.. BeOS is dead though (yes, I know about Haiku). 2) Buy a SSD and you won't have to wait anymore 'a full minute' to have your computer in an usable state..