IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New 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.
Collapse Edited by broomberg July 13, 2005, 06:36:36 AM EDT
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.

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.
New 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)
New No argument
     Why Apple moved to Intel - (admin) - (18)
         Nice article. Thanks. - (Another Scott) - (1)
             Size == Speed - (ChrisR)
         I'm not a programmerbloke, but... - (pwhysall) - (15)
             Obviously you are not a programmer :-P - (ben_tilly) - (14)
                 Re: Obviously you are not a programmer :-P - (pwhysall) - (1)
                     Everything winds up in cache - (ben_tilly)
                 But neither are you, at least not that low a level - (broomberg) - (11)
                     I might surprise you - (ben_tilly) - (3)
                         Latency latency latency - (broomberg) - (2)
                             Note that most macs are single-user systems -NT - (ben_tilly) - (1)
                                 No argument -NT - (broomberg)
                     Our perl programmers think that way all the time - (tuberculosis) - (6)
                         Please reread, I changed it - (broomberg) - (5)
                             We have a lot of levels of caching - (tuberculosis) - (4)
                                 Agreed - (broomberg) - (3)
                                     Ahhh, cogs click into place. - (folkert) - (2)
                                         It's helpful to remember just what "load average" means. - (static) - (1)
                                             yea, That is a good analogy... - (folkert)

I have seen them...
47 ms