I'm well aware of this - e.g. process vs thread is just OS fundamentals. And yes, as an IIS guy, I'm well aware of the difference (say) between CGI applications and a multithreaded single process running on IIS.
Your app programming example is an example of application coding effort, not that an OS works 5x better. I wouldn't say that this is an OS feature - but a reflection of the quality of application code. I believe I'm getting nowhere here. People here seem to be amazed by their fabulous performance of their Macs, but haven't been able to work out why. And don't seem very curious either, which surprises me immensely. If I had such a computer I'd be spending my time reading everything I could to find out why this machine seems so much faster. Personally, I don't see any differences between my boxes here... Cheers Ken > -----Original Message----- > From: Ben Scott [mailto:mailvor...@gmail.com] > Sent: Saturday, 20 December 2008 8:58 AM > To: NT System Admin Issues > Subject: Re: OT - Anyone VM a Mac Leopard OS on a PC? > > 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/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
