I might surprise you

I don't think at that level often, but occasionally I wind up thinking about things at that level, particularly when I'm trying to figure out how to convince a database to do things my way. (Or while I'm figuring out why doing things my way wasn't as good as I hoped it would be.)

As for your example, you're right that shaving 20 MB off of the executable does not make it fit in cache. But that is ignoring the fact that while the overall application might be that large, most people don't use all of the application at the same time. Therefore the active set in the application that you're using has a chance of fitting in cache, and cutting its size by a third strongly improves that chance.

Furthermore even if the active set does not fit into cache, you've improved how much of it does. And this is still a win. Sure, you're going to have lots of waits while something is fetched into cache, but reducing the number of such waits increases performance.

You aren't going to get an order of magnitude improvement that way, but you might get several percent improvement. Of course loops not unrolled etc might cost you more than you could gain. You need to benchmark, benchmark, benchmark.

Another note. Apple is very aware that people notice startup time more than execution performance in interactive applications. Smaller executables might or might not run as fast, but they are likely to load faster. Thinking about it, this probably matters more to them than any possible speed gain/loss at runtime.

Cheers,
Ben

In my kernel tuning class (the week I met you in NYC) that was the mantra.

Performance it mostly a perceived phenomina, not a truly measured one, at least in the case of tuning a system for OTHER people.

So the 1st lesson to be learned was to lower expectations.

After that, true thoughput was typically ignored, in an attempt to reduce latency.
So it worked its way out, from CPU cache hits, to 2nd level memory, to disk, to network, etc.

Edit: I should have said worked its way in, from slowest to quickest. And the 1st should have been application design. That's because the items with the largest perceived benefit should be tuned 1st, not the other way around. Who cares if you shave a few milliseconds with a cache hit only to lose a few seconds in the application design side.

And as you stated, program startup was a HUGE issue with people, since interactive programs spens almost all their time waiting for people, with the exception of the startup time.

Which in turn really does not typically come into play on a multi-user system that has been running for a while. This is because the most common apps are already in memory (at least the primary working set) since a single app is really shared by all the users. Or at least is in the disk cache.

Post #214,555 by ben_tilly 7/12/05 8:48:30 PM Reply	I might surprise you I don't think at that level often, but occasionally I wind up thinking about things at that level, particularly when I'm trying to figure out how to convince a database to do things my way. (Or while I'm figuring out why doing things my way wasn't as good as I hoped it would be.) As for your example, you're right that shaving 20 MB off of the executable does not make it fit in cache. But that is ignoring the fact that while the overall application might be that large, most people don't use all of the application at the same time. Therefore the active set in the application that you're using has a chance of fitting in cache, and cutting its size by a third strongly improves that chance. Furthermore even if the active set does not fit into cache, you've improved how much of it does. And this is still a win. Sure, you're going to have lots of waits while something is fetched into cache, but reducing the number of such waits increases performance. You aren't going to get an order of magnitude improvement that way, but you might get several percent improvement. Of course loops not unrolled etc might cost you more than you could gain. You need to benchmark, benchmark, benchmark. Another note. Apple is very aware that people notice startup time more than execution performance in interactive applications. Smaller executables might or might not run as fast, but they are likely to load faster. Thinking about it, this probably matters more to them than any possible speed gain/loss at runtime. Cheers, Ben I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #214,557 by broomberg 7/12/05 9:03:33 PM 7/13/05 6:36:36 AM Reply	Latency latency latency In my kernel tuning class (the week I met you in NYC) that was the mantra. Performance it mostly a perceived phenomina, not a truly measured one, at least in the case of tuning a system for OTHER people. So the 1st lesson to be learned was to lower expectations. After that, true thoughput was typically ignored, in an attempt to reduce latency. So it worked its way out, from CPU cache hits, to 2nd level memory, to disk, to network, etc. Edit: I should have said worked its way in, from slowest to quickest. And the 1st should have been application design. That's because the items with the largest perceived benefit should be tuned 1st, not the other way around. Who cares if you shave a few milliseconds with a cache hit only to lose a few seconds in the application design side. And as you stated, program startup was a HUGE issue with people, since interactive programs spens almost all their time waiting for people, with the exception of the startup time. Which in turn really does not typically come into play on a multi-user system that has been running for a while. This is because the most common apps are already in memory (at least the primary working set) since a single app is really shared by all the users. Or at least is in the disk cache. Edited by broomberg July 13, 2005, 06:36:36 AM EDT Expand All History
Post #214,581 by ben_tilly 7/13/05 3:30:29 AM Reply	Note that most macs are single-user systems I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
Post #214,582 by broomberg 7/13/05 6:32:54 AM Reply	No argument

Welcome to IWETHEY!