Slashdot Mirror
Mac vs. PC Digital Photography Comparison Redux
Macmurph writes "Bibble Labs has released a lightning fast version of the RAW image convertor, MacBibble. According to MacBibble creator, Eric Hyman, "MacBibble 3.x is almost 10 times faster than the manufacturers software when converting RAW files under OSX.". Prelimenary tests indicate the Mac may be faster than PCs in RAW image conversion afterall. This calls into question the relevance of the the hotly debated article Rob Galbraith posted just 3 weeks ago and discussed here on Slashdot. Two thumbs up for the PowerPC G4's AltiVec vector processing engine, now being put to work in MacBibble."
I've always thought that exploiting parallelism would be the next step after we hit some kind of practical performance wall in desktop systems. However, I've been saying that for 7 years and the wall just keeps moving, although I kind of think its gotten a little closer.
It's probably a question of economics more than anything else. A 2 CPU system for most end-user applications probably delivers less percentage increase in performance than its percentage increase in cost right now. But up till now its been cheaper to replace a single CPU with a faster single CPU than to invest more upfront in a multi-CPU system -- you have to keep it longer, which means you fall farther behind the current performance curve.
If it became 'standard' to have them, OS and App vendors would be able to deliver a performance jump out of 2 CPUs through better parallelism that would outweigh the increased hardware costs associated.
In the PC world, there's also the historical problem of lack of mainstream OS support for multiple CPUs -- I can't remember if XP consumer even supports it, now that I think about it -- which creates that chicken-and-egg problem. NT4 was a highly marginal 'consumer' OS, Win2k had more reach but still not what the 9x series had and XP adoption has been slower due to people just keeping PCs longer.
I've had a dual CPU system at home for 3 years and I'm not entirely sure I'd replace it with another one once I looked at the economics of it. The biggest single benefit I can think of is that it doesn't bottleneck the way a single CPU can when a single process pigs out at 100%, I still have a nearly-idle CPU to work with -- which is the problem with 2 CPUs, one's nearly idle.
If you've read this far you might be interested to note this plug-in from Adobe that "enhances the reliability of Adobe® Photoshop® 7.0.x software running on a Mac OS X system that uses the G4 processor" from a couple of days ago.
No word on whether this gives the PS on G4s any kind of speed boost, though.
When did the future switch from being a promise to a threat? -C. Palahniuk
Actually, this shows the results of system specific optimizations. For instance, molecular modeling code optimized for my old SGI Octane was rippin fast. Much faster than on any other platform I could find. However, code not optimized for the SGI platform was just as fast on Intel or PowerPC. Now, that said, the G4 does have something called Altivec, and code optimized for this can be unbelieveably fast. Optimized BLAST libraries are faster on my dual G4 than anything I have ever used including some big SGI iron.
The trick is getting programmers to take the time and effort to optimize for specific platforms. This takes time and money to write quality code, but in the era of Microsoft timeline driven products, quality software code is harder to come by.
Visit Jonesblog and say hello.
yeah, but IIRC AltiVec is a much cleaner, better implementation of a VPU than the x86 flavors (do they still share the FP registers a la MMX?) - so its code is still probably going to be faster than SSE optimized code (on a specialized black hole simulation that one of my former professors uses, i've seen a >20x speedup with good AltiVec code).
Facts do not cease to exist because they are ignored. - Aldous Huxley
Apple provides a very nice, extremely easy to use Altivec library. It requires writing no assembly code, and I believe it even resorts back to non-Altivec means of execution if a program written using the library is executed on a G3. So, for instance, in Altivec, you can write things like:
result = vec_add( aVector, someOtherVector );
and it works properly regardless of what sort of vector you've chosen to use for aVector.
I've yet to see anything similar for 3D Now or SSE/SSE2. Everything I've seen for them is either a library that is too application specific (like a premade image recognition library), or requires using assembly and a compiler newer than VC++ 6.0 (maybe only SSE2 really requires that).
Apple also provides a bunch of other libraries, like vDSP (I'm sure AMD and Intel provide an equivelent), and BLAS (this is a somewhat standardized library across platforms. My recall is that there is a SSE/SSE2 version, but Intel charges money for it, instead of giving it out for free), and in general, they make it easier for Apple developers to take advantage of Altivec than Intel does SSE2 or AMD does 3D Now. Unfortuntaly, a lot of developers want to maintain only one code base across all platforms, so they won't use the Apple provided tools (there are free unoptimized versions of BLAS for every platform though, so developers should at least use that so they can't get speed benefit on platforms that provide it), which sucks because GCC also sucks for speed, so people using vendor supplied compilers on other platforms (like Intel's on Windows or Linux, SGI's on Irix, Sun's on Solaris) get a nice speed boost that would require hand assembly optimization to get on a G4.
I'm a loser baby, so why don't you kill me.