Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
Many people understand simple specs, and performance changes in a subsystems. What they don't understand is those effects on the whole system. The Subsystems speed may have a very small impact on the real world performance. This is why you hear things like Apple increases the speed of their bus from 66 MHz to 100 MHz (a 50% improvement) and in the real world, users see a 5% performance gain. Apple isn't defrauding anyone -- people just don't get what the numbers mean. Things are far worse in the Intel world, because you have many more wannabe techies that care about things that are irrelevant. Let's explore what I mean in more detail.
Performance -
Step 1
Let's say I want to compare one Application -- like running Photoshop, Opening an Image, doing a filter (or two), saving the file, and quitting. Here is how the time component of that might break down:
It takes a certain percentage of your time to do each high level thing -- like loading Photoshop, Opening a file, doing the filter, saving and quitting. The total time is your real world performance. If I made opening a file 100 times faster, it may have little (or no) significant difference on your workflow -- because the majority of your time is spent filtering. There is much more to this than meets the eye.
Step 2
Let's keep breaking things down into more and more detail. Users think of steps like "load, open, filter", but computer engineers often think more at the different subsystems. Let's jump into a few of the logical areas (like load and filter) and see how the engineering elements might break down in timing.
From a engineers point of view, the function of "loading" or "filtering" can break down into the following groups, Processing, Drive (I/O), memory and toolbox (MacOS calls).
(Of course this breakdown detail is arbitrary. We can keep going until we are looking at what individual instructions are taking the most time in processor, or what area or metric of the drive performance is most important, and so on. But for explanation purposes this high level view is good enough).
Notice that for loading the image, most of the time may be spent doing one thing (like drive access) but in a filter there is likely little drive access, and a lot more time is being spent accessing memory (where the image is stored) and of course processing it. Different functions have dramatically different usage models of the computer, and they stress different subsystems differently. So improving one subsystem may have no noticable performance increase if you aren't using those things a lot, or if they are not the bottleneck (what is taking most of your time).
Step 3
Now we will pretend that Apple just doubled the speed of the systems bus (which should improve how long it takes to access memory). Here would be the simulated results.
When doing a load (running something from disk), a 100% improvement on BUS speed may only make a 5% difference on the total time. Memory access was twice as fast (there was no duping of any one) but memory was only one of many things that were going on (and not the costly one in this case). In fact, for speeding up the load part of the function, what Apple really needed to do is speed up the drive access -- a doubling of that performance would have been far more noticeable -- probably more like a 40% speed increase instead of 5%.
Of course remember that each of these items can be further broken down. What is drive access? It is the sum of the time it takes the I/O port (say SCSI, IDE or FireWire) to transfer the data -- as well as the time it takes the drive to find, access and send the data to the I/O port. Drives themselves have many metrics like access time, transfer rates, latency and so on. All these functions can keep getting broken down further and further, or in different ways depending on what you are trying to measure.
Doubling the memory bus may have had a nominal effect on loading Photoshop (say 5%), but it will have had a far bigger effect (say 15 - 20% improvement) on doing a Photoshop filter. The Photoshop filter is far more likely to be memory bound (waiting for the processor bus) than loading was. So if you are spending all your time doing filters, that memory bus improvement could be a far bigger gain to you.
Step 4
Now lets really go hog wild. Lets double the performance of the processor and imagine what the real world results would be (looking at the highest level user functions again).
If we double the processor performance we know it will help some things far more than others. Like it is likely to help the Photoshop filter a whole lot (since it is processor bound -- i.e. doing a lot of processing) -- while loading, opening, saving and quitting will see far less gains. The total gain for doubling the processor performance may only make a 20 - 25% performance boost overall (for this specific test). Of course if you were spending hours just running filters (or doing anything that was very processor intensive and not stressing the other subsystems) then this performance increase would be far more dramatic.
Conclusion
Of course the point to all this is that tuning a few of the right things can have a far larger effect than tuning many of the wrong things -- the trick is not to have better specs -- but have better of a few key specs (for what you are doing). Unless you are an engineer and work on this stuff, you may never know what is the bottleneck (where does your computer spend most of it's time) -- and this stuff does change a little Application to Application.
I hope this helps you learn a bit more about speed, and how dependent speed is on what you are doing. If you are loading all the time (accessing the disk), then you should really be paying more getting a fast hard drive. If you are spending all your time processing, then the faster processor will pay off. Your gains in each case will be dependent on what you do -- and that varies for everyone.
Each of these areas can be broken down more and more. There is a near infinite amount of metrics for measuring performance. Engineers keep doing this to see what areas are the bottlenecks and need the speed improvements. But just because a company radically improves something does not mean that it will effect you at all -- though odds are that it will be a big gain for someone!
There are diminishing returns on speed improvements. If it takes you 50 seconds to do something (20 seconds of that is processing), and someone were to double your processor speed you would see a nice 20% improvement. But even if they were to offer a processor that was 1,000 times faster, that would likely only mean that your real world performance would improve by 38% or so. So 1,000 times faster was really only twice the improvement (for you) than doubling the performance is. Certainly that performance gain (extra 18%) would be nice -- but it was not revolutionary. What happened is the bottleneck shifted -- what was taking most of your time (the bottleneck) was not improved. Improving any one area, without improving the others just moves the slow spots around. We started out with about 40% of our time spent in processing -- but once we reduced that, improvements in that area became insignificant -- it was the other areas that needed the improvement.
So what you should learn from all this is that your system (computer) is not as fast as the fastest component -- your performance is likely more dependent on the slowest one. The bottlenecks and the balance of the whole system are what count.
This is part of the difference between the Mac and the PC and many measurements.
PC advocates (techno-wannabe's) often get real excited about performance improvements ANY area -- whether that area matters or not. So they brag about faster busses when their machines were not memory bound! The spec looks great, "Now with a 133 MHz bus" -- but the real world should read "Now less than 5% faster". Then PC advocates ignore the slow spots and the worst parts of their machines -- like piping sound through an ISA bus (which can take up to 30 or 40% of their total I/O budget). You want to really speed up the PC, or make it better, free it from the things that are really holding it back, like ISA slots, antiquated Instruction Set, or Windows -- the bottlenecks. Instead they will keep getting excited about things that don't matter that much (or that often) -- "Now with a 200 MHz bus". Yawn. That is why I brush off many PC advocates and specs -- they keep getting excited about some things that make almost no difference and only sound good to people who don't know any better.
Mac advocates care (more often) about real world results. The fastest whatever may not matter. I could design a system that was balanced and keep improving the slowest components, and make a far bigger difference on the real world that just keep dramatically speeding up the fastest components. Since Macs are by far better balanced and engineered systems (and Apple keeps eliminating the old and bad parts) this is why the specs may imply one thing (like MHz and Memory Bus and all those metrics) -- and yet the real world may say something completely different!
|
