How Much Processing Power Does it Take to be Fast?
prog21.dadgum.com
prog21.dadgum.com
Now I have to work similarly hard just to get IE8's crappy JavaScript implementation to sort 1000 objects in under 33ms on a 3GHz machine. Sigh.
For even more extreme examples of performance within confines, see the excellent chronicle of Atari 2600 development, "Racing the Beam".
It's about how modern interpreted languages such as Ruby and Python are orders of magnitude faster than BASIC's such as found on typical 1980's systems.
2^((2009-1984) / 1.5) = 104031.915
He's accidentally demonstrated that we would expect a 1984 implementation of BASIC on modern hardware to be exactly as fast as modern Python.
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.
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.
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 :)
But this has changed. See also http://herbsutter.com/welcome-to-the-jungle/ .
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.
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.
Of course people get annoyed at these things, taking up "memory", "delaying" system start etc and get rid of them.
I/O just tends to be more expensive on Windows. Not only does the code have to deal with backwards compatibility, old drivers and tag alongs (anti-virus, backup), potentially obstinate hardware, and numerous other things but often the OS is supported for a long time. For example Windows XP uses a 10MB buffer cache, irrespective of how much RAM you really have. (Can be changed via registry, code changed in Vista.)
"Well spent"?
It's not like we have faster hardware but suddenly got dumber programmers.
Compared to the old games, where you could do only one thing, but you could do it fast.
Now you need to do this for menu options etc etc.
PS: Games often do this trading a little less accuracy in a single frame to enable low latency responses.
- Some form of sprites were the rule, not the exception. Albeit very hardware coupled, usually a fixed width and maybe unlimited height. Fixed # of sprites per line as well, or they'd just turn invisible.
- Tile based (character) graphics, so there's a lot of games that aren't bitmapped, but rather character or tile based. So think updating a 40x25 screen (eg) not a 320x200 screen.
- Palette (indirect) based graphics = some tricks for animation here.
- A hardware supported transparent color.
- Direct control of frame buffer pointer = lots of goodness.
- Interrupts based on raster position
- DMA for sound
Sometimes:
- Some control of modulus based scrolling (think starting bitwise horizontal and vertical for up to 8 bits) = easy tile based bit scrolling.
- Blitter (with boolean ops) - maybe.
- Planar graphics.
Still, we're lazy today. Lots o layers in between us the hardware.
I think the point is that the iPad is sluggish and it shouldn't be. 30 years ago people knew how to make something fast reacting with way less hardware behind it, somehow we've lost that and added complexity that doesn't really seem visible to the user.