On Fri, Dec 19, 2008 at 12:48 AM, Ken Schaefer <k...@adopenstatic.com> wrote: > Whilst the OS is different, there isn't that much difference in memory > management algorithms and CPU > schedulers. It's the same basic research and theory that goes into that > fundamental level stuff.
I know there are *huge* differences in scheduler and memory manage between different releases of the Linux kernel. It also has radically difference performance characteristics vs. BSD or Solaris. I don't know much about the Windows kernel, but I have a hard time believing it performs the same as Mach+BSD+Apple, when even BSD vs Linux yield different performance characteristics. Keep in mind that I'm not saying "bad", I'm just saying "different". A lot of things are six-of-one, half-dozen-of-the-other, so as long as the application developer/compiler knows which trade-offs were made, it all equalizes in the end. But if an application has been tuned and optimized for one platform, and then less attention is paid to the other platform, there's a very good chance that the application will work better on one platform than the other. Indeed, in years past, many Adobe apps were developed on the Mac and then ported to Windows, and they had a reputation for this very problem. I don't know if that still holds true, but it might well explain the reported behavior. But again, to go back to your original point, without a scientific, methodical investigation, we'll never know *why* the OP is seeing this behavior. > On top of that there are bigger differences - approaches to building OS > functionality. Yup! And how the application interacts with all that matters, too. > The filter code is from Adobe in both cases, and the actual work is done by > the CPU, with stuff stored in RAM, and rendered by a GPU. I don't know anything about Adobe's filters, and how they might make demands on CPU, memory, I/O, system calls, etc. But how an application utilizes the OS can make a huge difference. For example: On Unix, the overhead to start a new process is comparatively low compared to NT. NT uses a model of even more lightweight threads, but within relatively heavy processes. Many Unix apps implement multi-processing simply by calling fork() frequently, and do fine. But if you bring that app over to NT without adjusting for the differences, you'll get abysmal performance, and *from the exact same source code*. The Apache web server had this very problem with its first NT porting attempts. Point being: We're not comparing apples and apples. We're not even sure what kind of fruit we are comparing. :) -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
