As promised, I am following up my “Fun with Windows (on a PPC Mac!)” post with the results of some performance testing I recently did, pitting the same Windows apps against each other, one time running on a virtual Windows machine on a PPC Mac, and then again on actual physical PC. This post reveals the results!
The machines in question? On the Mac side, I used a Power Macintosh 7300/200, featuring a 200 MHz PowerPC604e processor and running Windows 3.1 in the SoftWindows 3 emulator.
On the PC side, I used a custom build machine featuring a 100 MHz 486DX4 processor and running Windows for Workgroups 3.11. Both environments have the Win32s subsystem installed, and the PC further benefits from having 32-bit file access enabled.
To test raw performance, I settled on the CPU intensive task of image decoding, and used the same four images, abyss.jpg, arnold.jpg, beertree.jpg and shark.jpg as my test images. These images weigh in at 1080×1070, 380×500, 700×869 and 740×622 respectively – quite a respectable workout for the Windows of the day.
For image viewers, I used ACDSee/16 v2.2, LView/16 v3.1, WinJPEG/16 v2.2, LviewPro/32 v1.D2 and finally, IrfanView/32 v2.05.
In all cases, I loaded the image viewer program first, so that program load time was not a factor, and then timed the amount of time it took from image selection in the File->Open dialog to image display on the screen.
As I went into these tests, I honestly expected the results to be roughly the same. I had a 200 MHz CPU emulating a 486, an operation that I suspected would run at around the equivalent of a 100 MHz 486, and a real world 100 MHz 486. Hopefully, the performance would be reasonably similar.
So how did they fare in the actual testing? Here are the results:
As you can see, the real world 486 ran rings around the emulated 486, even while running the slightly heavier Windows for Workgroups (”heavier” relative to the emulated machine’s Windows 3.1).
What is more, my initial expectation of rough performance equality was wildly wrong. Even at 200 MHz, the emulated 486 performed at no more than a third of the speed of the real 100 MHz 486, with results often clocking in at as low as a quarter of the speed of the real 486. That is 6x to 8x performance hit for emulation, much worse than the 2x I expected.
Finally, and as we have seen in the past, program design was SO important in those days of limited CPU horsepower. In general, the 32 bit applications performed almost twice as fast as their 16 bit counterparts, but one such counterpart, ACDSee/16, always kept pace with, and occasionally exceeded, the performance of its mightier 32 bit peers. This has to reflect superior program design – ACDSee/16 clearly features the most optimized algorithm of the set, leading to its stellar performance.
So, there you have. Head to head, the same Windows apps competing on an emulated 486 and on a real 486. The results in summary: the performance of the 200 MHz emulated 486 was about a sixth of the performance of the 100 MHz real 486. Now you know!