3 ms·

If you can live without such luxuries as an operating system, libraries, and drivers then you too can write software as efficient as Defender! But resources are

If you can live without such luxuries as an operating system, libraries, and drivers then you too can write software as efficient as Defender! But resources are well spent on abstraction, most of the time.

Lagged2Death 15y ago
But is it mere abstraction that causes me (to take a completely random example) to wait on Windows so often, when I've got so many GHz and so many GB at my disposal? I think it's more likely to be a matter of priorities. It's more important to ship your PC software than it is to expend the effort required to make it slick and responsive. On non-PC platforms (like the iPad) that's not true; the platform's relative simplicity and responsiveness is a big selling point, so it's crucial to be fast and slick to fit in.
- kjhughes 15y ago
  Right. I didn't have time to write a short program, so I wrote a long one instead.
  - gcp 15y ago
    I think this is entirely backwards. Programs don't get necessarily slower with length. Or faster for lack of it. I didn't have time to write a program that handles all corner cases without losing responsiveness at any point, so I just wrote the simplest thing that mostly worked. It's true that over-complication is the bane of good performance, but lets not pretend it is, or ever was, easy to get great performance.
    - ajuc 15y ago
      > It's true that over-complication is the bane of good performance, but lets not pretend it is, or ever was, easy to get great performance. It's easier to overcomplicate things, than it is to keep things simple. Especially when there are changes to specification(which means always :)). And often performance comes as a bonus, when we simplify things. So I think GP had it right. Recently I've noticed in my code (ok, friend pointed it out to me), that I often leave too general code mixed with code with specific assumptions. Like - at first I've assumed nothing, so code was general, but more complicated than neccesary. Then I've learnt a few things, made more assumptions to get what I need faster, but I've left the general parts of code in place (maybe I'll need them later, besides more general == better, right?), even thought I could replace them with simpler and shorter and faster code, if I rethought these parts with new asumptions. So code is more complicated than it's needed, and won't work in general case anyway, and depending where somebody starts reading the code, he will think differently about what he can assume about data. Friend had replaced 2 instances of NumberAssigner class, synchronised between threads, with two instances of private int variables, and removed NumberAssigner class altogether :)
    - kjhughes 15y ago
      It's not backwards at all. Understand that the allusion to concise letter writing speaks to more than literal lexical length; it speaks to the effort required to optimize expression. And none of this pretends that "it is, or ever was, easy to get great performance."
- wladimir 15y ago
  Agree that it is completely a matter of priorities. With hardware generations succeeding each other every few years, much faster every time, there was hardly reason to optimize everything. Bolting on new features was the highest priority. But this has changed. See also http://herbsutter.com/welcome-to-the-jungle/ http://herbsutter.com/welcome-to-the-jungle/ .
- drzaiusapelord 15y ago
  >when I've got so many GHz and so many GB at my disposal? Because like most laptop and desktop users youre IO bound by your slow mechanical spinning disk. My desktops at work at home and my laptop all have SSD's now. I have a level of responsiveness that's very close to what I get with an ipad or my transformer. Don't blame the software, blame the hardware. You can't really compare flash-based storage to mechanical storage. A lot of the "bloaty" OS's really aren't. Its the damn mechanical storage. I mean, there's literally a mechanical arm that roams around spinning platters. You can't compare that to electrons dancing on flash media.
  - Lagged2Death 15y ago
    I'm aware of the mechanical I/O bottleneck, and I'd love to have SSDs in the machines I use, but funds do not permit. But I doubt that's the whole story. The first time I type "Ctrl-F" in a VS2010 session, the disk thrashes and there's a noticeable delay of a couple of seconds before the Find tool loads. The delay is so bad that keystrokes are lost; if I not-particularly-quickly type "Ctrl-F mystring", the find tool searches for "tring." I'm sure an SSD could improve that situation, but the real issue here isn't that the disk is slow, it's that the software is causing disk access where none should be necessary. I'm sure there are reasons behind it; the find tool is a module in a modular system, it's not hanging around when it's not needed, it makes a smooth fit with the rest of the framework that was used to build VS2010, etc. But the end result, the end user experience, is worse than it was in older, simpler versions of the product. (In this particular way, it's actually worse than a DOS-era editor, running on far more severely bottlenecked hardware, was 20 years ago.) The find tool was probably built in whatever was the most straightforward way to get it to fit into the horrendously complicated system (VS2010 on Windows) it's a part of, and no effort (or not enough effort) was expended to make it any better than that. This is just one example that struck me today. There are plenty of other situations where a Windows machine full of Windows apps will cause the user to wait in situations that shouldn't require waiting. You can classify them as I/O bottlenecks, and that's not wrong, but I think it's missing the point. Everyone knows there's an I/O bottleneck there; when you develop code, you're supposed to bear that in mind. But backwards compatibility and shipping the damn thing are more important than optimizing, and that goes for Windows itself and all the components thereof as well. The stuff we write today has to accommodate the foolish-in-retrospect decisions of yesterday.
- stonemetal 15y ago
  Maybe, maybe not. There are exactly two hardware configurations for Ipads(and less than a dozen if you consider iPhones as well). The abstractions in the OS can be much thinner and more specialized to what is required to get good performance out of the hardware. For the PC there is much larger variation so the abstraction layers have more ground to cover. Though I have to agree with you, it seems performance is rather low on the feature list.
  - aaronblohowiak 15y ago
    What about the simulator?
- dedward 15y ago
  no flamewars.... this must have spmethingj to do with windows giant mess of libraries and backwards comatabilities. my mac is running the same os install, cloned, upgraded, moved to newer gear ( but older than anyone i know hardware wise... the point being its not a fresh insall by any means... its years older than its hardware). it does have an intel ssd i stuck in there..... but it boots to fully useable in abou 10 seconds and shuts down (not sleep or hibernate) in less than 2 seconds. so.... i only used the macas an example because its what im using rught now. i know what part of the speed comes from the ssd... but the rest, is it just lack of backwards compatability and a simpler design? attention to detail? dunno.... but it rarely makes me wait for anything except stuff like compiling or number crunching, both of those being sets of unique cases where then amount of hardware neededto not have them interrupt your workflow is variable.
- smackfu 15y ago
  Windows is slow because of the spinning disk. That's why simply replacing it with an SSD gives such dramatic speed improvements.
- extension 15y ago
  Abstraction can be very expensive. You wouldn't have to wait on your Windows app if it didn't have to share memory and storage with other apps. Web sites spend a few orders of magnitude in performance in order to abstract out operating systems, low-level programming, hardware form factors, physical proximity, deployment, and a host of other things.
  - Lagged2Death 15y ago
    The sort of delays I'm speaking of happen even with no other applications running. Windows itself is probably the most demanding software system on many PCs.
    - extension 15y ago
      Just the capability to share memory with other apps is what requires the sacrifice in efficiency. It means that apps can't control what and when parts of themselves are paged out to disk. If they could, they might only page out infrequently used data, as opposed to data that needs to be available quickly for responsiveness.
GregBuchholz 15y ago
"Well spent"? http://lambda-the-ultimate.org/node/4436 http://lambda-the-ultimate.org/node/4436

Lagged2Death 15y ago

But is it mere abstraction that causes me (to take a completely random example) to wait on Windows so often, when I've got so many GHz and so many GB at my disposal? I think it's more likely to be a matter of priorities. It's more important to ship your PC software than it is to expend the effort required to make it slick and responsive. On non-PC platforms (like the iPad) that's not true; the platform's relative simplicity and responsiveness is a big selling point, so it's crucial to be fast and slick to fit in.

kjhughes 15y ago
Right. I didn't have time to write a short program, so I wrote a long one instead.
- gcp 15y ago
  I think this is entirely backwards. Programs don't get necessarily slower with length. Or faster for lack of it. I didn't have time to write a program that handles all corner cases without losing responsiveness at any point, so I just wrote the simplest thing that mostly worked. It's true that over-complication is the bane of good performance, but lets not pretend it is, or ever was, easy to get great performance.
  - ajuc 15y ago
    > It's true that over-complication is the bane of good performance, but lets not pretend it is, or ever was, easy to get great performance. It's easier to overcomplicate things, than it is to keep things simple. Especially when there are changes to specification(which means always :)). And often performance comes as a bonus, when we simplify things. So I think GP had it right. Recently I've noticed in my code (ok, friend pointed it out to me), that I often leave too general code mixed with code with specific assumptions. Like - at first I've assumed nothing, so code was general, but more complicated than neccesary. Then I've learnt a few things, made more assumptions to get what I need faster, but I've left the general parts of code in place (maybe I'll need them later, besides more general == better, right?), even thought I could replace them with simpler and shorter and faster code, if I rethought these parts with new asumptions. So code is more complicated than it's needed, and won't work in general case anyway, and depending where somebody starts reading the code, he will think differently about what he can assume about data. Friend had replaced 2 instances of NumberAssigner class, synchronised between threads, with two instances of private int variables, and removed NumberAssigner class altogether :)
  - kjhughes 15y ago
    It's not backwards at all. Understand that the allusion to concise letter writing speaks to more than literal lexical length; it speaks to the effort required to optimize expression. And none of this pretends that "it is, or ever was, easy to get great performance."
wladimir 15y ago
Agree that it is completely a matter of priorities. With hardware generations succeeding each other every few years, much faster every time, there was hardly reason to optimize everything. Bolting on new features was the highest priority. But this has changed. See also http://herbsutter.com/welcome-to-the-jungle/ http://herbsutter.com/welcome-to-the-jungle/ .
drzaiusapelord 15y ago
>when I've got so many GHz and so many GB at my disposal? Because like most laptop and desktop users youre IO bound by your slow mechanical spinning disk. My desktops at work at home and my laptop all have SSD's now. I have a level of responsiveness that's very close to what I get with an ipad or my transformer. Don't blame the software, blame the hardware. You can't really compare flash-based storage to mechanical storage. A lot of the "bloaty" OS's really aren't. Its the damn mechanical storage. I mean, there's literally a mechanical arm that roams around spinning platters. You can't compare that to electrons dancing on flash media.
- Lagged2Death 15y ago
  I'm aware of the mechanical I/O bottleneck, and I'd love to have SSDs in the machines I use, but funds do not permit. But I doubt that's the whole story. The first time I type "Ctrl-F" in a VS2010 session, the disk thrashes and there's a noticeable delay of a couple of seconds before the Find tool loads. The delay is so bad that keystrokes are lost; if I not-particularly-quickly type "Ctrl-F mystring", the find tool searches for "tring." I'm sure an SSD could improve that situation, but the real issue here isn't that the disk is slow, it's that the software is causing disk access where none should be necessary. I'm sure there are reasons behind it; the find tool is a module in a modular system, it's not hanging around when it's not needed, it makes a smooth fit with the rest of the framework that was used to build VS2010, etc. But the end result, the end user experience, is worse than it was in older, simpler versions of the product. (In this particular way, it's actually worse than a DOS-era editor, running on far more severely bottlenecked hardware, was 20 years ago.) The find tool was probably built in whatever was the most straightforward way to get it to fit into the horrendously complicated system (VS2010 on Windows) it's a part of, and no effort (or not enough effort) was expended to make it any better than that. This is just one example that struck me today. There are plenty of other situations where a Windows machine full of Windows apps will cause the user to wait in situations that shouldn't require waiting. You can classify them as I/O bottlenecks, and that's not wrong, but I think it's missing the point. Everyone knows there's an I/O bottleneck there; when you develop code, you're supposed to bear that in mind. But backwards compatibility and shipping the damn thing are more important than optimizing, and that goes for Windows itself and all the components thereof as well. The stuff we write today has to accommodate the foolish-in-retrospect decisions of yesterday.
stonemetal 15y ago
Maybe, maybe not. There are exactly two hardware configurations for Ipads(and less than a dozen if you consider iPhones as well). The abstractions in the OS can be much thinner and more specialized to what is required to get good performance out of the hardware. For the PC there is much larger variation so the abstraction layers have more ground to cover. Though I have to agree with you, it seems performance is rather low on the feature list.
- aaronblohowiak 15y ago
  What about the simulator?
dedward 15y ago
no flamewars.... this must have spmethingj to do with windows giant mess of libraries and backwards comatabilities. my mac is running the same os install, cloned, upgraded, moved to newer gear ( but older than anyone i know hardware wise... the point being its not a fresh insall by any means... its years older than its hardware). it does have an intel ssd i stuck in there..... but it boots to fully useable in abou 10 seconds and shuts down (not sleep or hibernate) in less than 2 seconds. so.... i only used the macas an example because its what im using rught now. i know what part of the speed comes from the ssd... but the rest, is it just lack of backwards compatability and a simpler design? attention to detail? dunno.... but it rarely makes me wait for anything except stuff like compiling or number crunching, both of those being sets of unique cases where then amount of hardware neededto not have them interrupt your workflow is variable.
smackfu 15y ago
Windows is slow because of the spinning disk. That's why simply replacing it with an SSD gives such dramatic speed improvements.
extension 15y ago
Abstraction can be very expensive. You wouldn't have to wait on your Windows app if it didn't have to share memory and storage with other apps. Web sites spend a few orders of magnitude in performance in order to abstract out operating systems, low-level programming, hardware form factors, physical proximity, deployment, and a host of other things.
- Lagged2Death 15y ago
  The sort of delays I'm speaking of happen even with no other applications running. Windows itself is probably the most demanding software system on many PCs.
  - extension 15y ago
    Just the capability to share memory with other apps is what requires the sacrifice in efficiency. It means that apps can't control what and when parts of themselves are paged out to disk. If they could, they might only page out infrequently used data, as opposed to data that needs to be available quickly for responsiveness.

GregBuchholz 15y ago

"Well spent"? http://lambda-the-ultimate.org/node/4436 http://lambda-the-ultimate.org/node/4436