Apple MacBook Pro 'Fastest Windows XP Notebook'?

rgraham writes "The Register has a great opening line in a recent article, "Want the fastest Windows XP Core Duo notebook? Then buy a Mac. According to benchmarks carried out by website GearLog, Apple's MacBook Pro running Windows XP is a better Adobe Photoshop rig than any other Core Duo laptop on the market." GearLog ran the same tests that were run by PC Magazine with the Mac coming out on top."

Comments

Re:AMD

[jonnythan]

AMD doesn't make any dual-core notebook chips...

The Reg sexed up our dossier

[saschasegan]

Just wanted to preemptively strike out and mention that the Reg "sexed up our dossier" a little, to use a British reference.

Over here at PC Mag/Gearlog (it's the same thing - Gearlog is the blog of PC Mag) we like to say that our tests show Apple makes a "fast" Windows machine, not "the fastest." As somebody else pointed out, while the MacBook squeaked out a win on the Photoshop test, it came in behind other Core Duo laptops on the Windows Media Encoder test. But the news in my mind isn't a one-second difference in this or that. It's that Apple's machines run Windows comparably to the best designed-for-Windows machines. That bodes very well for folks who want to have the best of both worlds by running both OSes natively.

We couldn't run 3DMark, Sysmark, etc. because of the missing video drivers - wouldn't have been fair. The Photoshop and Windows Media tests were the only ones of our standard benchmark suite we thought would generate results that made any proper sense, because they hit processor/disk/RAM rather than video.

Also, for the AMD fanboys, we haven't tested any AMD dual core notebooks yet, so we didn't have the data to compare those.

If you haven't already, read our original story: http://gearlog.com/blogs/gearlog/archive/2006/03/2 1/8212.aspx

Re:Best tool for the job

[TheRaven64]

Some parts of OS X are much slower than others. System calls are quite expensive (roughly 10x the cost on a conventional UNIX system), for example. The slowest part of the system I have found is the VM subsystem, which absolutely crawls. I wrote some fairly I/O intensive code with a number of back ends. The aio back end is about half the speed on OS X as on FreeBSD on similar hardware. The mmap backend is an order of magnitude slower on OS X than the aio back end, while they are both about the same speed on FreeBSD. This means that anything that causes page faults is going to slow the system down to a painful speed, which is why Mac users always recommend that you buy a lot of RAM.

Re:hmm is it released now

[jinushaun]

Here is the official Windows XP on Mac website: http://onmac.net/

The patch is available here: http://download.onmac.net/

Re:Best tool for the job

[pammon]

Some parts of OS X are much slower than others. System calls are quite expensive (roughly 10x the cost on a conventional UNIX system), for example

I'm not disputing this, but I'd like to provide some context so people aren't left with the impression that "Apple's programmers are st00pid n00bs." There's at least three decisions that negatively impact OS X's system call performance, but that provide wins in other areas.

1) Mach/FreeBSD system call disambiguation. OS X has to support both Mach and FreeBSD system calls through the same trap interface. Determining which you have isn't cheap, but the win is apparent - how many Mach messages per second does your conventional UNIX benchmark at? Features don't come for free. This is fixed overhead which will be especially apparent with "fast" system calls.

2) 4/4 memory split. A system call requires a context switch to and from the kernel's own address space. I'm not sure about other UNIX flavors, but Linux in particular (usually) maps the kernel's address space into each process with a 3/1 split, which is faster but has an obvious downside - 25% less address space for the process and 75% less for the kernel!

3) Dynamic library binding. OS X is unusual in that every library is always dynamically bound, which adds overhead for every call, but gives you all the benefits of non-static libraries (code sharing, security, etc.) Benchmarks often don't take this into account.

The slowest part of the system I have found is the VM subsystem, which absolutely crawls. I wrote some fairly I/O intensive code with a number of back ends.

There's a few things I've found that impact OS X's I/O negatively:

1) Spotlight wants to index any file you opened for writing and then closed. That's obviously going to incur a cost.

2) Unified buffer cache - cacheing reads in the VM system. For a linear read of a huge file, this only hurts; it can be turned off on a per descriptor basis, but code compiled naively for OS X won't have bothered to do that.

3) Bugs. There seems to be a bug where a program doing linear I/O can monopolize the I/O system, which improves performance for that process but decreases apparent responsiveness.