6 ms·

We've been complacent. Thus the old saying, "Intel giveth, Microsoft taketh away."[0] Engineers have known for a long time that we aren't as efficient as we co

We've been complacent. Thus the old saying, "Intel giveth, Microsoft taketh away."[0] Engineers have known for a long time that we aren't as efficient as we could be. [0] Not attempting to beat up on either of those companies.

overcast 8y ago
I don't know, Windows 10 seems to be faster on even older hardware. Upgrading from 7 to 10 makes the machine feel MUCH more responsive. Seems to bring life back to the old machines around here.
- gameswithgo 8y ago
  Maybe you are just feeling a machine without bloat vs one with lots of bloat that has built up for 3rd party software? At least one aspect of windows10 design will add input latency, which is the forced vsync in the windowing system.
  - overcast 8y ago
    Nope, fresh installs of Windows 7 definitely not nearly as responsive. Thousands of machines a year, Windows 10 is by far the fastest.
    - monocasa 8y ago
      Not sure why you're b eing downvoted. Windows 10 is the first release that Microsoft had really fully internalized the lessons learned from the whole Longhorn debacle. That is consumers aren't ever going to have 10Ghz processors.
ghaff 8y ago
We've also just optimized for features, time to market, and programming approaches that don't require the most highly-skilled and trained developers. You can change all that of course (and we do for some applications/situations) but you don't get significantly more efficient code for free. It probably takes longer to write and a lot of current developers probably can't do it.
- gameswithgo 8y ago
  >We've also just optimized for features, time to market, and programming approaches that don't require the most highly-skilled and trained developers We think we have been optimizing for those things, but I don't know that we actually have. Does Ruby/Python really help you get to market faster than would similar languages with static typing and compilers or JITs? (Kotlin, C#, F#, Nim, etc) There is research that suggests not, certainly I don't think the effect is large if it even exists. Many people use TypeScript because they feel it is a productivity boon over Javascript. We might one day leverage that and use the static types to compile TypeScript more efficient WASM or something, win win situation.
  - mrguyorama 8y ago
    If you're looking for efficiency, wouldn't the actual win be to just use less javascript?
    - gameswithgo 8y ago
      Yes, but typescript is a great way to ease people into that, since it is a superset of javascript which could be leveraged to AOT compile more efficient code. Also it is a very nice language!
  - jkabrg 8y ago
    It's not clear what he's referring to. It could be garbage collection, libraries, frameworks, optimizing compilers... - Garbage collection make performance unpredictable because of collection spikes. - If you use a big library, you now have to load the library, which is an extra time-sink. - Likewise for frameworks. - Optimizing compilers optimize the 80% of our programs that don't need optimizing, and under-optimize the 20% that do. (This is DJB's argument.) That might be what he's saying. He didn't say anything about dynamic vs. static typing. Also, there's a counter-argument to this, that writing non-garbage-collected code might result in security bugs (to do with memory management). And security is a non-functional requirement that some might say is more important than speed. It's hard to judge though; there are loads of requiremenets in software dev, and it's hard to balance them.
pacaro 8y ago
One irony of this expression is the role Intel played in making sure that as much of USB as possible had to go through the CPU
agumonkey 8y ago
do you have a list of things that are really in need of redesign ?
ryanmarsh 8y ago
I'm not a low level developer (whatever that means today). I've written a very minimal amount of production C. Everything else has been higher level languages. So I apologize in advance for my ignorance. Isn't the problem really memory bandwidth? Aren't most CPU cycles "wasted" on speculative execution while waiting on fetches from memory slower than CPU caches? Wouldn't a hardware model where all of the RAM (SRAM?) was on the CPU die (fabrication and DRAM clock speed aside) solve this problem and make everything an order of magnitude faster? What am I missing? Is this really the programmers fault? The CPU literally spends most of its time waiting on my instructions, not choking on them, so why is this my fault for being lazy?
- baybal2 8y ago
  >What am I missing? You are missing money... SRAM and wider data paths are expensive. You are totally right about that taking more logic into synchronous domain domain is an almost universal solution to getting more performance. The faster the chips become, the more IO gap becomes. Experienced MCU programmers know quite a number of algorithms that may run faster on "dumb" 100mhz MCUs than on a 20-cored Xeon, and are proud to show them off. Even when some of MCU cores may take like 6 cycles to do an arithmetic op, their strong side is that it will be taking them these 6 cycles to do that all and every time consistently, and that their memory runs synchronously. Say, in a 1000000 cycle loop, where every operation results in cache miss, Xeon will spend more time on a loop than a wimpy 100Mhz MCU that simply don't take any penalty on unpredictable, heavy on synchronous ops cope. Apple A11 is so fast for an ARM just because they choose the simplest, the surest, most direct, but also the most expensive way to scale performance: tons of SRAM and prefetch logic everywhere to reduce IO gap as much as possible.
- marcosdumay 8y ago
  Memory bandwidth is a problem. A large one. But saying that "most" CPU cycles are wasted to it is a huge overrate. I have read estimates that go as high as 1/3 of the CPU lost to it (sorry, no reference here), but even those were not usual.
- paulmd 8y ago
  20 MB of RAM should be enough for anybody! /s I was reading a thing a while back on here or Reddit where someone asked about an OS that ran entirely in cache, after all in principle a modern processor has more L3 than an original Unix minicomputer. Since many of the memory subsystems operate on the assumption that changes should be propagated to memory that you would still need to have RAM there even if you weren't really "using" it. There was a suggestion that since the bringup code begins entirely on-processor (before initializing RAM) that you could hack the Management Engine and keep running in that mode forever.
cm2187 8y ago
The modern version being, "Intel giveth, javascript and python taketh away".

overcast 8y ago

I don't know, Windows 10 seems to be faster on even older hardware. Upgrading from 7 to 10 makes the machine feel MUCH more responsive. Seems to bring life back to the old machines around here.

gameswithgo 8y ago
Maybe you are just feeling a machine without bloat vs one with lots of bloat that has built up for 3rd party software? At least one aspect of windows10 design will add input latency, which is the forced vsync in the windowing system.
- overcast 8y ago
  Nope, fresh installs of Windows 7 definitely not nearly as responsive. Thousands of machines a year, Windows 10 is by far the fastest.
  - monocasa 8y ago
    Not sure why you're b eing downvoted. Windows 10 is the first release that Microsoft had really fully internalized the lessons learned from the whole Longhorn debacle. That is consumers aren't ever going to have 10Ghz processors.

ghaff 8y ago

We've also just optimized for features, time to market, and programming approaches that don't require the most highly-skilled and trained developers. You can change all that of course (and we do for some applications/situations) but you don't get significantly more efficient code for free. It probably takes longer to write and a lot of current developers probably can't do it.

gameswithgo 8y ago
>We've also just optimized for features, time to market, and programming approaches that don't require the most highly-skilled and trained developers We think we have been optimizing for those things, but I don't know that we actually have. Does Ruby/Python really help you get to market faster than would similar languages with static typing and compilers or JITs? (Kotlin, C#, F#, Nim, etc) There is research that suggests not, certainly I don't think the effect is large if it even exists. Many people use TypeScript because they feel it is a productivity boon over Javascript. We might one day leverage that and use the static types to compile TypeScript more efficient WASM or something, win win situation.
- mrguyorama 8y ago
  If you're looking for efficiency, wouldn't the actual win be to just use less javascript?
  - gameswithgo 8y ago
    Yes, but typescript is a great way to ease people into that, since it is a superset of javascript which could be leveraged to AOT compile more efficient code. Also it is a very nice language!
- jkabrg 8y ago
  It's not clear what he's referring to. It could be garbage collection, libraries, frameworks, optimizing compilers... - Garbage collection make performance unpredictable because of collection spikes. - If you use a big library, you now have to load the library, which is an extra time-sink. - Likewise for frameworks. - Optimizing compilers optimize the 80% of our programs that don't need optimizing, and under-optimize the 20% that do. (This is DJB's argument.) That might be what he's saying. He didn't say anything about dynamic vs. static typing. Also, there's a counter-argument to this, that writing non-garbage-collected code might result in security bugs (to do with memory management). And security is a non-functional requirement that some might say is more important than speed. It's hard to judge though; there are loads of requiremenets in software dev, and it's hard to balance them.

pacaro 8y ago

One irony of this expression is the role Intel played in making sure that as much of USB as possible had to go through the CPU

agumonkey 8y ago

do you have a list of things that are really in need of redesign ?

ryanmarsh 8y ago

I'm not a low level developer (whatever that means today). I've written a very minimal amount of production C. Everything else has been higher level languages. So I apologize in advance for my ignorance. Isn't the problem really memory bandwidth? Aren't most CPU cycles "wasted" on speculative execution while waiting on fetches from memory slower than CPU caches? Wouldn't a hardware model where all of the RAM (SRAM?) was on the CPU die (fabrication and DRAM clock speed aside) solve this problem and make everything an order of magnitude faster? What am I missing? Is this really the programmers fault? The CPU literally spends most of its time waiting on my instructions, not choking on them, so why is this my fault for being lazy?

baybal2 8y ago
>What am I missing? You are missing money... SRAM and wider data paths are expensive. You are totally right about that taking more logic into synchronous domain domain is an almost universal solution to getting more performance. The faster the chips become, the more IO gap becomes. Experienced MCU programmers know quite a number of algorithms that may run faster on "dumb" 100mhz MCUs than on a 20-cored Xeon, and are proud to show them off. Even when some of MCU cores may take like 6 cycles to do an arithmetic op, their strong side is that it will be taking them these 6 cycles to do that all and every time consistently, and that their memory runs synchronously. Say, in a 1000000 cycle loop, where every operation results in cache miss, Xeon will spend more time on a loop than a wimpy 100Mhz MCU that simply don't take any penalty on unpredictable, heavy on synchronous ops cope. Apple A11 is so fast for an ARM just because they choose the simplest, the surest, most direct, but also the most expensive way to scale performance: tons of SRAM and prefetch logic everywhere to reduce IO gap as much as possible.
marcosdumay 8y ago
Memory bandwidth is a problem. A large one. But saying that "most" CPU cycles are wasted to it is a huge overrate. I have read estimates that go as high as 1/3 of the CPU lost to it (sorry, no reference here), but even those were not usual.
paulmd 8y ago
20 MB of RAM should be enough for anybody! /s I was reading a thing a while back on here or Reddit where someone asked about an OS that ran entirely in cache, after all in principle a modern processor has more L3 than an original Unix minicomputer. Since many of the memory subsystems operate on the assumption that changes should be propagated to memory that you would still need to have RAM there even if you weren't really "using" it. There was a suggestion that since the bringup code begins entirely on-processor (before initializing RAM) that you could hack the Management Engine and keep running in that mode forever.

cm2187 8y ago

The modern version being, "Intel giveth, javascript and python taketh away".