You guys may want to take a look at this comment on another article of ours for some really interesting info on the NT kernel:

http://neosmart.net/blog/2008/shipping-seven-is-a-fraud/#comment-160264

Also, as for the scalability of the Vista-era NT kernel, I disagree. On the most recent Top500 list, Windows scored the highest efficiency rating on the list for x86 hardware:

http://blogs.technet.com/windowsserver/archive/2008/06/18/windows-hpc-deputs-in-the-top-25-fastest-supercomputers-in-the-world-what-more-do-i-need-to-say.aspx

Moreover, the OS X kernel is available in 64-bit flavor:
http://www.apple.com/macosx/technology/64bit.html

The ULE scheduler was designed for FreeBSD and obviously may need some tweaks for it to become a viable replacement for the OS X scheduler currently in use in Leopard & Co., but it’s not as-drastic of a change as you’re suggesting.

FreeBSD isn’t a server OS – it’s an OS for everyone and everything. It’s the fastest *nix I’ve used to date as a desktop (though I freely admit the experience was subjective as I hadn’t been given the chance to benchmark it) and everyone will testify to its performance on the server-field of course.

Windows 98 == DOS plus a nice gui
WinNT, W2k, WinXP, Vista are a completely different line of development

So you see even with Vista the scheduler scales like crap. And so does Mac OS X, because it’s designed for the desktop.

—

Rather nonsense, you cannot exchange a scheduler in a _completely_ different kernel. You have to take care of your OS-facilities and this would be a matter of some years.

More 64 bit for example, the kernel of Mac OS X _is_ 32 bit. So if you’re using more than 4G of memory you have to use with something similar to PAE. Last not least SCHED_ULE in FreeBSD 7 isn’t the best for UP-systems and you will gain the most performance with many cores only in database and server-area. Remember? Mac OS X _is_ an OS for the desktop.

So maybe this is a nice dream of some Apple-users, but in reality it’s just a lack of knowledge about the operating system of choice.

We’re still pretty far away from operating systems and hardware that can convert sequential, single-threaded code into multi-threaded code that can be executed on multiple cores (though many universities have projects along those lines, but it’s no easy task) and it’s highly unlikely that’s what Apple has in mind.

Most likely Apple will be adding some sort of easy multi-threading functionality to XCode akin to what’s available in C# and the .NET Framework right now; that is to say, a line of code to start a new thread, a line of code to synchronize threads, etc. but developers still have to decide where those lines will go.

The balancing of CPU vs GPU performances is mentioned in the article as one of the more-compelling reasons behind our belief that Apple will be using ULE or something similar – it’s the only scheduler out there (to the best of our knowledge) that can handle multiple cores of different capabilities and speeds on a single computer. If Apple embraces ULE, then they don’t even need to worry about that question – the new thread scheduler would take care of it for them.

In the NYT blog, Jobs describes it as a “breakthrough.” For their platform, maybe. He makes it sound as though the rest of the industry has ignored this issue, which is ridiculous (but the usual RDF in action around those that don’t follow this field closely). If anything, it’s *Apple* that is late to this party. The truth is that they *have* to revamp OS X to remain competitive as CPU performance is now increased by adding cores instead of MHz.