Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

BareFeats Pro Apps Benchmarks '09 MP

E

ekoe

macrumors member
Original poster
Mar 7, 2008
69
0
London, UK
http://www.barefeats.com/nehal04.html

Things seem to be looking up for the Nehalem MPs, at least according to BareFeats' new benchmarks on the pro apps.

This is reassuring to me because I've got the 2.26GHz Nehalem 8GB RAM on order and plan to install another 4GB RAM (2 x 2GB modules) for that 12GB 'sweet spot'. :)

Not intending to be confrontational, just curious... does this change any opinions among those who have knocked the Nehalem machines. BareFeats seems to be the benchmark everyone has been waiting to see.
 
Some people want to justify their purchase no matter what. If that means jumping to conclusions and ignoring all the evidence, then that's what they'll do.
 
Yea I just saw this morning and I'm very impressed of the 2.26ghz being faster than the 3.2ghz model. Also considering that 10.5.7 hasn't been released yet with the bettr driver support under leopard.
 
That is an interesting link. I'm surfing all the benchmarked sites this morning, so this is absolutely relevant.

Makes me wonder how the 2.66 octo makes any sense if the 2.26 is performing so competitively to the 2.93.

I have to say that as I was very sceptical of the 2.26 performance at first, it's looking like a serious choice as these benchmarks keep coming out. Overlaying the 2.8 and 3.2 (2008) machines performance graphs over the Nehalem's, there's a pretty obvious difference in the newer MPs.
 
ekoe said:
Not intending to be confrontational, just curious... does this change any opinions among those who have knocked the Nehalem machines. BareFeats seems to be the benchmark everyone has been waiting to see.
Click to expand...

I for one am not crazy about the new line of Mac Pros, call that knocking them if you wish . ;)

The new MPs are certainly decent machines, but a few design flaws, unimpressive performance gains and Apple's pricing and model policy are leaving a lot to be desired for me .

The benchmarks are nothing new, they seem to confirm what was known and speculated before.
A more thorough review can be found at macperformanceguide.com, btw..

So I for one don't think the new MPs are bollocks at all, but really not the dog's bollocks either.

Looking forward to Rev.B , Snow Leopard and optimized apps, though.
 
macperformanceguide.com seems to favor Photoshop and image editing, so it certainly is useful for those professionals looking at 2D work.

Since I work equally with 3D development, 2D sketching, multiple layer Photoshop files, and post processing, there is no single point benchmark to help me choose from this new Mac Pro lineup.

Hard for me to justify the octos in the 2.66 or 2.93 range, as I don't see any significant benefit over the 2.26 (percentage wise) unless I'm scrutinizing every 10 minutes of a work week.

I'm thinking that the entry octo 2.26 stocked with RAM is enough for now, and I'm trusting that Snow Leopard will liberate additional gains from the architecture.
 
MCHR said:
I'm trusting that Snow Leopard will liberate additional gains from the architecture.
Click to expand...

Please don't think this. I have been in contact with devs that are testing snow leopard and they're under NDA, but the gist of what they're saying is that Grand Central is a set of APIs for C and Ob-C that includes a threading framework and closures ('blocks'). This means that software must be explicitly rewritten to take advantage of it.

Please don't think your programs will become faster in Snow Leopard. Threading frameworks for C and Obj-C exist right now. They're not utilized because many problems are theoretically serial in nature, and it's never going to change. Other problems are theoretically parallelizable. However, the tools to utilize multiple cores have existed for decades. There is no reason to think that adding another (not even cross-platform) tool to the mix is going to magically encourage developers to update their code to multithreaded. If they have a reason to do it, they could do it today. If they haven't done it today, there's a reason for that, and it ain't APIs.

Snow Leopard isn't even going to update Cocoa to be thread safe.

You're going to be very disappointed if this is what you think.

PS, OpenCL requires explicit code calls as well.

[edit: Mods, don't delete me, this part is not under NDA and it's info that is available around the web].
 
mason.kramer said:
Please don't think your programs will become faster in Snow Leopard.
Click to expand...

No, I wasn't implying that. Rather, any gains possible are yet to be determined, or identified as where they will improve. That's part of the speculation, I suppose. I only hope we see some advantage.

From your perspective (without getting into any NDA territory), do you see this new architecture enabling significant gains as we go forward with it? I do understand that software apps are lagging, etc. etc. What do you see from your vantage point as a developer?

Reason being is that I'm about ready to pull the trigger on a new machine. .
 
Wow, those Nehalem machines are smokin' - at 12GB RAM. I'm amazed how severely penalized they became at 16GB and 8GB, at least in the AE benchmark.
 
MCHR said:
No, I wasn't implying that. Rather, any gains possible are yet to be determined, or identified as where they will improve. That's part of the speculation, I suppose. I only hope we see some advantage.

From your perspective (without getting into any NDA territory), do you see this new architecture enabling significant gains as we go forward with it? I do understand that software apps are lagging, etc. etc. What do you see from your vantage point as a developer?

Reason being is that I'm about ready to pull the trigger on a new machine. .
Click to expand...

I don't have first hand experience with Grand Central, but no, I don't think so. For programs that are only designed for Mac OS, G.C. style blocks might be a syntactically easy way to achieve parallelization for certain functions. Anything that is trivial to parallelize in the sense of not needing to be redesigned can be done using OpenMP (a cross platform, open standard). Anything that is hard about parallelization (retooling an algorithm or designing a new one) will remain hard in Snow Leopard. The computer can't do your thinking for you, yet.

Most major pieces of software that do heavy duty processing are cross platform. Think Adobe, 3D rendering, etc. Apple's first party Logic and FCP are the main exceptions to this rule.

No company besides Apple is going to use Grand Central to parallelize code that is meant for cross-platform consumption: it would mean twice the work.

AFAICT the main reason Apple is doing this is because they're trying to keep Obj-C up-to-date. Obj-C is basically Apple's baby at this point, no one uses it or develops with it for other platforms, but Apple practically requires it now that they're letting Carbon die in the 64-bit transition.
 
I find the amateur benchmarks being done to date to be less than helpful.

For example, in this latest Barefeets review, why do we have such a good selection of machines being compared on the After Effects benchmark, but only a small set of machines being compared on the Photoshop benchmark. Is this laziness, or are these test results being pulled from different times/sources? ;)

More information needs to be provided by the benchmarker to explain this kind of stuff to have any credibility.

Also, there seems to be a lot of emphasis on comparing the 09's to the 08's... a lot of us couldn't care less about this... we are trying to make a decision on which of the new models will best suit our workload given the crazy difference in pricing between various models. A smart buyer will only buy enough machine to do the job given the current price structure, but none of the benchmarks to date have been very helpful in determining this. :mad:

Sadly, the most useful benchmarks have come from forum members here on this forum.
 
Well, I have been trying to get information, and spent the last several hours collating, comparing and determining what "size" machine will be the most appropriate.

From disparate website, benchmarks, and sources, it seems that the 2.26 does indeed best the 2.8 in nearly every category, with only a few standouts or early benchmarks favoring the 2.8. With increased amounts of memory in the 2009 machines, it's certainly becoming obvious that these machines were underrated during their initial comparisons, all cost disussions aside.

Though Geekbench is only one metric to determine performance, here are two charts overlayed to show the Harpertown family and the Nehalem family performance. These aren't edited to eliminate the earlier 2.66 processors, so these charts are straight from primatelabs:

macpro.jpg


Seems to me that there's conclusive evidence that the 2.26 range is at least midpoint in last year's 3.2, and only goes up from there. Of course, this is only one test.

Here are some numbers comparing the 2.26 to the 2.8 in other categories. No, these are not scientific, but I believe they indicate a trend.


l


comparing 2.8 with 2.26 machines, single apps bold text indicates best performance

CS3 Photoshop 140% 2.8

CS4 Photoshop 113% 2.8

iTunes 105% 2.8



comparing 2.8 with 2.26 machines multi apps

cinebench single 102% 2.8

cinebench multi 118% 2.26
multitasking 129% 2.26

final cut 113% 2.26

final cut dual 125% 2.26

The following five tests with 12Gb ram in the 2.26 (2009) machine. referenced from Barefeats:

Photoshop CS4 110% 2.26
(in 2009 2.26)
compressor 153% 2.26

after effects 110% 2.26


cinebench big 103% 2.8

cinebench big 106% 2.26


CNET reviews

final cut 114 2.26

multimedia multitask 129% 2.26

cinebench 118% 2.26
iTunes encoding 105% 2.8

Last point of comparison:

Note: cinebench claims to test processor speed, showing a 12% increase in speed over the 2.8 from 2008

Digital Arts Online 16 minutes, 26 seconds (2.26)
34 minutes, 32 seconds (2.8)

Increase 210%


Link here
 
mason.kramer said:
No company besides Apple is going to use Grand Central to parallelize code that is meant for cross-platform consumption: it would mean twice the work.

AFAICT the main reason Apple is doing this is because they're trying to keep Obj-C up-to-date. Obj-C is basically Apple's baby at this point, no one uses it or develops with it for other platforms, but Apple practically requires it now that they're letting Carbon die in the 64-bit transition.
Click to expand...

Please excuse my ignorance, and educate me if possible;)

Don't other vendors, for instance Adobe, already have to create different versions of their software for Apple vs. Windows? I thought that they could use which ever language they prefer to code their applications, as long as they link in the appropriate libraries e.g. Framework, AppKit, Cocoa? Use of the new API for Grand Central is not limited to Objective-C?

Also, isn't the 64 bit architecture coming going to be different for Windows vs. Apple + Linux? Or is that handled at the compiler level?

I think I've wandered off into the weeds on this one, but since I'm lost I can't see where I went astray!
 
Boneoh said:
Please excuse my ignorance, and educate me if possible;)

Don't other vendors, for instance Adobe, already have to create different versions of their software for Apple vs. Windows? I thought that they could use which ever language they prefer to code their applications, as long as they link in the appropriate libraries e.g. Framework, AppKit, Cocoa? Use of the new API for Grand Central is not limited to Objective-C?

Also, isn't the 64 bit architecture coming going to be different for Windows vs. Apple + Linux? Or is that handled at the compiler level?

I think I've wandered off into the weeds on this one, but since I'm lost I can't see where I went astray!
Click to expand...
Most of the code for most projects is the same on every platform. Only a few parts of the code must change for each platform. These are the parts of the code that utilize platform specific libraries. These are typically libraries that are provided by the OS for the purposes of building a GUI and leveraging OS built-in features. In Mac OS there are two major libraries and these are Carbon and Cocoa.

Cocoa is an API for using features of the Mac OS with Objective C. These include things like Mac windows, sheets, dialog boxes, and text fields. If you notice, most apps on Mac OS have the same exact looking windows and text fields. That's because the apps are built with Cocoa and Carbon. (The C++ equivalent feature is Carbon). Apple is not updating Carbon to work with a 64 bit address space. This effectively means that Carbon is no longer supported. Adobe's suite is written in C++ and calls Carbon API's on the Mac OS to handle the GUI. They are in the process of rewriting the code to use the Cocoa APIs using Objective C. 90% of the code will remain as C++ and just the stuff that must be written in Ob-C will be written in that language. Companies don't like to duplicate their code base - it's very expensive, in fact, code is the chief cost of any software firm.

You can't use Cocoa with C++, and you can't use Carbon with 64 bit.

Maybe I don't understand the question about 64 bit vs 32. Many libraries are address space agnostic and don't care what bit system you're using. Some, particularly fundamental libraries, care very much about that. Cocoa is such a library: there is 64 bit Cocoa and 32 bit Cocoa and they aren't interchangeable.
 
Yes, I understand most of what you've posted. I'm a software guy, just new to Mac programming. So Carbon is going away, and Apple has consolidated to Cocoa. Seems to make sense from their point of view, cost wise. I guess my confusion is around C++ not being able to use the Cocoa libraries.

It seems that some of my confusion is how they code the cross platform apps. So basically it is just the gui and o/s specific stuff that is different, and the main heart of the code is the same.

My question about 64 bit is related to Photoshop, in that the 64 bit is available under Windows not OS X. This probably has to do with Cocoa being the only 64 bit library on OS X, rather than differences in implementation of 64 bit architecture between Windows vs. OS X + Linux. I'm struggling to find the article that I recently read that describes these differences. If i find it I will post a link.

Thanks!
 
blinkfrog said:
It is a pity barefeats ignore audioapps.
Click to expand...

Agree, I want to see Logic Pro and Pro Tools on there, maybe some other apps too like Reason and Live.

I already know that Pro Tools doesn't like the new nehalems, and Digi are notorious at taking an age to update their software.

With the Q6700 being on offer at the moment I'm gonna build a cheap quad core hackintosh and that hope future software and hardware updates let me use audio apps on a mac desktop again.

P.S. Although I'm waiting for hard evidence (but there is some anecdotal evidence) I have a strong feeling that Logic Pro isn't performing too well on the new Mac Pros, otherwise Apple would have put benchmarks up on the Mac Pro page, they have for all other recent updates.

Also I find it a little odd that alot of the benchmarks on these forums are comparing the 08 octo 2.8 to the 09 octo 2.26, when the the octo 2.8 was the standard model in 08, the quad was a BTO downgrade. And price wise (in the UK at least) the 08 octo 2.8 was actually cheaper than the 09 quad 2.66. And for those that have been lucky enough to get a refurb 08 octo 2.8 in the UK, they've got them for about £1000 cheaper than the 09 octo 2.26.
 
Boneoh said:
My question about 64 bit is related to Photoshop, in that the 64 bit is available under Windows not OS X. This probably has to do with Cocoa being the only 64 bit library on OS X, rather than differences in implementation of 64 bit architecture between Windows vs. OS X + Linux.
Click to expand...
Exactly. There was a big stink, oh, I don't know, a few years ago maybe, when Adobe announced that CS4 would be 64 bit in Windows and 32 bit in Mac OS. The reason was that they would have to spend a dev cycle redoing it all in Cocoa in order to get it to 64 bits on the Mac. In Windows, I guess they'd been working on the transition for a while.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back