Slashdot Mirror
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."
Now all I want to know is which is faster: Photoshop on XP or OSX?
That will have to wait until next year, sine Adobe has stated that the Intel version of Photoshop for MacOS X won't be available until next year.
Jumpstart the tartan drive.
AMD doesn't make any dual-core notebook chips...
AMD will release their Turion64 X2 dual core processor pretty soon. But I am impressed with the Intel CoreDuo. It does not seem to be (and is not) the POS that their first "dual core" processor was.
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
I'm Sascha Segan. Who are you?
Current Core Duo (Yonah) is 32-bits only.
AMD will be releasing 25W Dual-Core Turions in May, running with DDR2 memory (which will save a few Watts over DDR memory).
Yonah is 31W (TDP, actual power consumption is lower. Same goes for AMD of course.). AMD includes half of a northbridge on their processor as well.
Of course, AMD's 25W Turion X2s only come in 1.6GHz and 1.8GHz variants. The 2.0GHz and 2.2GHz versions are 35W, but still comparable in power consumption to Yonah. The interesting thing is that this is at 90nm. If AMD has any of the hi-speed, low-power-consumption features of IBM's 65mn process, then next year could be very interesting however.
Doesn't negate the fact that Intel was there first, nor that AMD isn't overtaking them but merely having a competitive offering in the mobile arena.
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.
I am TheRaven on Soylent News
Here is the official Windows XP on Mac website: http://onmac.net/
The patch is available here: http://download.onmac.net/
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.