I'm pleased to say that given a hint from Tim Olson It would seem that my PB 3400c running system 8 has a radical performance problem with the Squeak VM unless Squeak or the user does one of the following: Remember official Apple rules state that long running CPU intensive tasks should throw up the Apple watch cursor, thus avoiding sleep/nap time according to rule 4. Since most normal Mac applications follow this rule they are not humbled. To examine how Squeak was humbled by the PowerManager I ran this benchmark: However Apple lets you indicate fake user activity using a system call to let the PowerManager know that activity that doesn't fit it's model of computer busy is going on. This call UpdateSystemActivity() is made with the constant UsrActivity which shows that general user activity is going on, please don't put the computer to sleep or nap it's very busy! Other constants are available but this seem more appropriate. To ensure the call is invoked frequently I placed it in sqMacWindow.c HandleEvents() which normally gets called about every 1/30 second, but when user activity stops it gets called every 1/2 seconds. This call rate change is a decision made by Squeak to reduce system call overhead, but what about the impact on foreground applications: my next exploration. To ensure we don't call the PowerManager on machines that don't support it good Macintosh hacking calls for a gestalt check, and some other checks, like so: New benchmarks gave me So what's the cost? Well for one, when Squeak is running we eat energy like mad and reduce battery life. But on the otherhand Morphic animations now run without irritating pauses. "Full speed ahead, damm the torpedeos." Now I wonder what Windows based laptops behave like? Are there Microsoft guidelines or in true hacker fashion does the user gets to set the Power Management policy based on Hardware options/abilities and his wants. For those who remember my note last Monday about calling SystemTask 30 times per second versus twice per second solving the performance problem, know that this result was contaminated with a behavior change. In my instrumented version of Squeak I was dumping data to a external log file in HandleEvents() and when it got called above a certain frequency per second the file I/O activity prevented the PowerManager from napping the CPU. Removing the file I/O dropped me back to the original behavior of napping regardless of the call frequency of SystemTask(). Much fun, without the ability to instrument the VM source code I would have never found the problem and perhaps passed off my Morphic animation pauses as issues with the GC running.
5000000 // (Time millisecondsToRun: [10 benchmark]) * 1000
in a loop and collect data on how slow it run from iteration to iteration to get the follow table of results using the 'official' VM1.22 running both on battery or A/C power.
5662000,5175000,4916000,4347000,4108000,3408000,3261000,
As you can see performance degrades, over a time of a minute or two(!), from a high of 5.6 million to a low of 1.1 million. As the computer grows 'less busy' the PowerManager pursues CPU stoppages to conserve power. My note from last Monday stated that SystemTask was taking 1.5 seconds to complete every other call or so when the machine was 'idle'. But of course Squeak is really running a aggressive bytecode benchmark. Other PowerBook owners are welcome to try this out and see how the PowerManager affects their measurements.
3156000,1886000,1327000,1250000,1239000,1176000
void PowerBookCheck(void) {
Also I needed to link in the MetroWerks PowerManager library to resolve glue code needed to call the manager. Early in the initialization I use PowerBookCheck() to set the global (ick) variable tapPowerManager which is used later on in the event loop to see if we can call UpdateSystemActivity().
long pmgrAttributes;
tapPowerManager = false;
if (! Gestalt(gestaltPowerMgrAttr, &pmgrAttributes))
if (pmgrAttributes & (1gestaltPMgrDispatchExists))
if (PMSelectorCount() >= 0x24)
tapPowerManager = true;
}
8561000,8333000,7886000
The numbers are far higher. My version of V1.22 is a good 50% faster than the official version. However I suspect the official version suffers from 'CPU napping' fairly quick, one CPU nap creeping into the benchmark would alter things. Testing on a 604e based 8600 shows equivalent benchmarks between mine and the official release, so the 'nap' issue alters any benchmark figures on the 3400c.
John Maloney was kind enough to point out that you can turn CPU power cycling off if you option click on the easy/custom slider on the PowerBook control panel. This feature then shows the checkbox to turn cycling on/off. This little feature has added power to my PowerBook. Sure wish they discussed it upfront.
Andrew C. Greenberg was kind enough to point out this problem is back with iBooks!!! So turn processor cycling off if you want better behavior at the expense of battery life. The change mentioned above was dropped from 2.9/2.8 so perhaps we'll consider adding it again...