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."

38 of 296 comments (clear)

  1. Multi-processors by BlueMonk · · Score: 4, Interesting

    The way I see it, multi-processor systems need to become more commonplace in the PC world. I don't know why they haven't. Is it a cost issue? My assumption is that's how the G4 performs so well, based on the fact that the multi-threading is what gave the program its edge.

    1. Re:Multi-processors by swb · · Score: 5, Informative

      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.

    2. Re:Multi-processors by Proc6 · · Score: 4, Interesting

      As a user of exclusively dual CPU PC's since the P2-300, I have decided I will switch to HyperThreaded single CPUs now that the 3ghz HT is out. People dont understand the benefit of dual untill they use one for awhile. Even a dual 500Mhz PC is far smoother and more productive in general than a single 2.4Ghz proc, unless all you do is play games. On a single proc PC, using one application that requires some CPU attention just brings the whole machine to it's knees. If you haven't seen it yet, check out Tom's Hardware video showing HT vs non-HT head-to-head. It's really enlightened alot of friends and family as to the value of 2 CPUs or HT vs 1. Well worth the extra cost, though I am patiently waiting for the 3Ghz to drop from its excessive $650 for just the CPU.

      --

      I'm Rick James with mod points biatch!

    3. Re:Multi-processors by hcdejong · · Score: 4, Insightful

      Could it be that there's also an element of laziness on the programmers' part? I expect it to be easier to write an application that expects to run on one processor (you don't need to worry about dividing tasks over multiple processors to optimize performance) than a multi-processing app.

      And, who really tries to optimize performance today? IMO many programmers expect Moore's Law to take care of the performance increase (relative to the previous release of their program). I rarely see a version n+1 of an application that's faster than version n was on the same hardware.

    4. Re:Multi-processors by vidarh · · Score: 3, Insightful
      Of course that is based on the fact that most apps are single threaded apps that won't manage to hog more than one CPU at a time. If SMP or HT becomes the common way of increasing speed at some point, then more applications will be heavily threaded and able to exploit this.

      Essentially, the effect you're mentioning could be handled on a single CPU machine simply by running a scheduler that guarantee that no process will get any more than every second timeslice, or similar, penalizing single threded applications.

    5. Re:Multi-processors by Eccles · · Score: 3, Insightful

      Could it be that there's also an element of laziness on the programmers' part?

      It's not laziness, it's priorities. Optimization is low priority in programming; if there's other things that need to be done, they need to be done first. And hardware optimization comes even lower on the priority meter, especially hardware that only a few users have, and especially hardware that will at most give you a 2x speed-up.

      --
      Ooh, a sarcasm detector. Oh, that's a real useful invention.
    6. Re:Multi-processors by hcdejong · · Score: 3, Interesting

      Good point. The question is then, why is speed such a low priority when the #1 argument to buy a new PC is that 'it's faster', and the #1 comparison statistic (useless or not) is the processor speed?

  2. Incredible! by gazbo · · Score: 3, Funny
    Man writes fast code on Mac for doing a single task; wannabe journalist extrapolates this to figure that Mac's are faster than PCs.

    Stay tuned for next week when we take the existence of bikini waxes to show that George W Bush is a paedophile.

    1. Re:Incredible! by JanneM · · Score: 3, Insightful

      Of course, there is no saying what speed increase a PC would get with a similarily optimized dedicated app for the same task. This proves nothing either way.

      --
      Trust the Computer. The Computer is your friend.
    2. Re:Incredible! by Anonymous Coward · · Score: 5, Interesting

      Macs are faster in most algorithms with source available.

      Typically the PowerPC (seen in most of the the www.top500.org list of fastest clusters) trounces Intel and even AMD at almost every benchmark.

      Not just the 10 famous benchmarks as part of the composite in ByteMark , but at many other things such as the RC5 contest.

      according to the RC5 benchmarks AMD is far slower than dual cpu macintoshes (half as fast). (source available for cor rc5 loops for most
      processors)

      The Mac Dual 1 Ghz g4 is faster than all existing dual AMD motherboards in RC5 benchmark by almost 100%.

      21,129,654 RC5 keyrate for dual 1 Ghz g4 system ! And Now apple sells dual 1.25 Ghz stock and this week a 1.45 Ghz which would be even faster.

      A dual 1800+ AMD MP get only HALF as many as a Mac! 10,807,034 rc5 keys !

      Funny "Mhz myth" there showing itself I guess... Apple now is selling even FASTER machines than that one I mentioned made over one year ago, but with smaller caches and less fast read-write ram (it
      now uses DDR on newest boxes).

      The mac I mentioned uses a 2 MB L3 cache and no amd mp dual cpu boards I know about have any L3 cache at all, so maybe that is why some common macs are
      over twice as fast, its not just altivec meager tweaks to rc5. AMD have similar , but less mazing vector ops.

      The Pentium 4 takes many cycles (over 7?) to do a simple left shift. That is why the Pentium is MUCH slower than even the AMD or Mac.

      Most modern CPUs can do a left integer shift in 1 cycle, any barrel position, not 7 slow cycles.

      (Shifting is used a lot in decryption, encryption, graphics processing and many things).

      Another reason the mac might be over twice as fast as an amd dual mp board is not just the 2MB l3 cache but the fact that mac can read and write to
      a cold page of memory simulatneously FASTER than any AMD MP designs which are biased for linear access and streaming. Many memory scatter
      benchmarks show this too. Apples newest DDR-RAM machines might not offer this feature though.

      True, RC5 fits in primary cache of most machines, though interrupt services need larger caches depending on interrupt designs and load for the rest of the OS.

      The RC5 benchmarks are never run with interrupts off, they use real world overhead.

      The Macs made since september also can RAPIDLY service every pci slot almost simultaneously one 32 byte cacheline each if needed. How can it do that ? Three cool features of modern PCI :

      * out-of-order completion
      * address bus streaming
      * intervention

      Out-of-order completion allows the memory controller to optimize the data bus efficiency by transferring whichever data is ready, rather than having to pass data across the bus in the order the transactions were posted on the bus. This means that a fast DDR SDRAM read can pass a slow PCI read, potentially enabling the processor to do more before it has to wait on the PCI data.

      Address-bus streaming allows a single master on the bus to issue multiple address transactions back-to-back. This means that a single master can post addresses at the rate of one every two clocks, rather than one every three clocks, as it is in the 60x bus protocol.

      Intervention is a cache-coherency optimization that improves performance for dual-processor systems. If one processor modifies some data, that data first gets stored only in that processor's cache. If the other processor then wants that data, it needs to get the new modified values. In previous systems, the first processor must write the modified data to memory and then the second processor can read the correct values from memory. With intervention, the first processor sends the data directly to the second processor, reducing latency by a factor of ten or more.

      ALtivec is not usually the reason a mac performs better than Intel in benchmarks of properly compiled code, because the famous set of 10 algorithms in ByteMark were not using ANY altivec instructions.

      And the AMD bests the Intel at Rc5 mainly from integer features.

      I laugh when pc people try to dismiss the fastest machine (Macs) by claiming Altivec "cheating" all the time. The mac people should be the ones to call foul when Intel was cuaght PAYING adobe to slow down filters in one version of Photoshop to artificially make the Pentium MMX 166 Mhz look faster. They got caught paying big bucks. Adobe replied that it was an unfortunate side effect of adding optimization for MMX and not keeping the code efficient in the non MMX case as it was before. HA!

      Almost every pc person likes to use benchmarks that use lots of assembly for intel (Quake, etc), but shy away from benchmarks that offer source code in ANSI C.

      I knew the mac handled RAW better than PCs and this news is no surprise to me.

    3. Re:Incredible! by Nugget · · Score: 5, Insightful

      I don't mean to rain on your enthusiasm and I sure don't intend to imply that I dislike Macs. I'm typing this up on my PowerBook.

      Using RC5 as a benchmark is only relevant insofar as you want to compare RC5 processing speeds. There RC5 algorithm, as well as the specific implementation found in dnetc, contain many aspects which make the results you obtain insightful for general use. You simply cannot compare RC5 rates and hope to extrapolate or project them into general processor comparisons.

      The RC5 algorithm relies heavily on bitwise rotates (left, if you're curious, ROTL) which is an operation that is not commonly found anywhere outside the world of RC5. This instruction is so underused, in fact, that many x86 architectures (AMD's K6 for instance) have taken to simply emulating the ROTL operation and eliminating true hardware support. This is why some conventionally powerful platforms (such as Sparc and Alpha based systems) do abysmally in RC5 as compared to x86 platforms containing a hardware ROTL implementation.

      Then again, this level of detail is probably lost on someone trying to compare a 1GHz G4 against an "AMD motherboard". AMD has made quite a number of CPUs in the past few years and their range of performance on RC5 is very broad. At one time, the AMD K5 was, in fact, the best-performing architecture in RC5 with the most keys per clock. AMD doesn't make any motherboards as far as I know.

      The core of dnetc is also small and lean, often fitting entirely in L2 cache on many architectures. This means that dnetc does not adequately (if at all) exercise memory bus bandwidth. The cores also tend to be hand-tuned assembly, so they aren't as likely to exercise a processor's speculative execution routines. RC5 uses absolutely zero floating point math, also an uncommon scenario and not representative of many apps you would traditionally think of when you think of apps which require strong CPUs to perform well.

      Many people enjoy having machines which perform well at RC5 and generate impressive distributed.net stats. Consequently, RC5 shows up as a metric in a great number of reviews and analyses on architectures and CPUs. I'm tickled whenever I see it and I think it's a great addition to any CPU review. However, it's not valid to try to make the claim that RC5 performance rates mean anything more than RC5 performance rates.

      Moo!

    4. Re:Incredible! by BWJones · · Score: 4, Informative

      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.
    5. Re:Incredible! by acidblood · · Score: 3, Informative
      I won't comment on your entire post, but given that you were quite misinformed about the whole RC5 issue, I bet you are just a very uninformed karma whore.

      Let's start...

      Macs are faster in most algorithms with source available.

      Uhh... I cannot even start to debunk this. Probably because I don't get what you mean, except that you were whoring for karma with the open-source crowd.

      Not just the 10 famous benchmarks as part of the composite in ByteMark , but at many other things such as the RC5 contest.

      Never heard of them. How about the industry-standard SPEC benchmarks? Oh, wait, Macs are twice as slow when compared to Pentium IIIs with the same clock speed, IIRC. Apple is so ashamed of the processors they use, you won't see a single SPEC benchmark published by Apple.

      according to the RC5 benchmarks AMD is far slower than dual cpu macintoshes (half as fast).

      I have covered that extensively on the Slashnet forum with DCTI. To make a long story short, the rotate operations (not bit shifts) were made available on the Altivec instruction set, and MMX/SSE2 doesn't have them. Observe that these useless (for the most part) instructions are only provide on the x86 and PowerPC ISAs, all other major CPU architectures do not offer these instructions. The more I think about it, the more it seems Apple was going for ultimate RC5 performance by including these rotate operations on Altivec -- so they could have at least one benchmark they'd always be ahead of everyone else, as long as they can keep their clock speed within 33-50% of x86 processors (that's 2-3 times less, if you haven't realized).

      The Pentium 4 takes many cycles (over 7?) to do a simple left shift.

      Wrong, only 4 cycles.

      Another reason the mac might be over twice as fast as an amd dual mp board is not just the 2MB l3 cache but the fact that mac can read and write to a cold page of memory simulatneously FASTER than any AMD MP designs which are biased for linear access and streaming. Many memory scatter
      benchmarks show this too. Apples newest DDR-RAM machines might not offer this feature though.

      This has to be the worse piece of BS I have ever read on my life.

      Intervention is a cache-coherency optimization that improves performance for dual-processor systems. If one processor modifies some data, that data first gets stored only in that processor's cache. If the other processor then wants that data, it needs to get the new modified values. In previous systems, the first processor must write the modified data to memory and then the second processor can read the correct values from memory. With intervention, the first processor sends the data directly to the second processor, reducing latency by a factor of ten or more.

      This is where you have shown how you don't understand anything you're talking about. This cache-snooping protocol is a feature of the Athlon (I doubt the Macs have it), and it is valid for the whole range of memory and not only the PCI bus -- which probably is marked as uncacheable in the MTRR so reads and writes are not cached, you obviously don't want that for I/O data.

      Quit the karma whoring, troll.
      --

      Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/

  3. who would have thought... by BlowChunx · · Score: 4, Insightful

    that a multi-threaded app that utilized Altivec would beat a single thread that relied solely on the FPU to do the work...

    I mean this is not rocket science! You would get similar results on most any machine using SSE2/MMX and hyper threading (perhaps...).

    1. Re:who would have thought... by jo_ham · · Score: 4, Insightful

      I think the point is that we had an article trashing the Mac for image processing because it was so slow at RAW processing. This appears to have fixed that problem, so there's no reason not to use a Mac in digital photography work now.

    2. Re:who would have thought... by Gropo · · Score: 4, Interesting
      You would get similar results on most any machine using SSE2/MMX and hyper threading (perhaps...)
      What baffles me is that the distributed.net clients have never apparently taken advantage of x86 SIMD cores. You'd think that they would take advantage of whatever they could code for within these clients, as they far outnumber the MacOS clients, and the goal is to unlock an encrytion algorithm, not benchmark CPU's.

      Rather than indicating that the distributed.net team would rather see PowerPC 74xx systems triumph in the key-crunching race, it would indicate that MMX/SSE2 are a royal pain in the ass to leverage unless you're coding/decoding pretty specifically what they were designed to code/decode - though IANAC++P...
      --
      I hate Grammar Nazi's
  4. Re:Isn't this pointless? by bpbond · · Score: 3, Interesting

    No. See the many, many other discussion on /., ArsTechnica, etc., about G4 vector processing capabilities. This and laptops are the (only) areas where the G4 remains competitive or better than the P4.

    --
    "Science is a tribute to what we can know although we are fallible" -Jacob Bronowski
  5. and again /. fires off the flame/zealot war by mousehouse · · Score: 3, Insightful

    argh... i absolutely loathe these mine's bigger and faster things... it's like a boy's pissing contest time-and-time again. this empty article blown up doesn't help! although i must add that it proves that decent programming skills _on_any_cpu_ helps build a fast program...

  6. Biased... by Justen · · Score: 5, Insightful

    The reality is that these "benchmarks" are, in all actuality, never really objective. The benchmarks from a few weeks ago were likely done by somebody who is less than a fan of the PowerPC G4 chip. The results from this article were written by someone who writes software for Windows and has decided to write a clean program for the G4 chip with its Altivec engine. Kudos to him.

    The reality remains that benchmarks prove little.

    People who are in love with Macintosh have, throughout history, had the speed card in their deck. At this particular time, many would argue they don't. (Many would argue they do...)

    People whoa re in love with other platforms, hardware and software, like their platforms for specific reasons, as well. Speed may be one of them.

    But, I think, deep down, Mac users are attached to the platform for more than just speed. It's the efficiency of the operating system, the attention to detail, the clean interface, the simple plug-and-play, the good support, the Apple iLife products...

    It's all in the eye of the beholder.

    jrbd

    1. Re:Biased... by milbybw · · Score: 3, Interesting

      Actually the original review was done by a Mac fan. While his benchmarks do not necessarily mean anything in a general sense (i.e. is a PC or Mac faster), they do have relevance in his specific situation. For the task of converting RAW images, his testing showed that PC's were faster. Many commented that it was due to poorly written software on the Mac, but that did not change the fact that if you wanted to do that task, you could do it faster on a PC. Now the situation may have changed (probably has). I would imagine that the original review will be updated with this new software for the Mac. Unfortunately it won't change the poor performace of reading the photos from the media...

    2. Re:Biased... by Anonymous Coward · · Score: 3, Informative
      Thank you for realizing the most important thing to most mac users, it's not the fact that they're fast machines, it's that they're GOOD machines.

      Not only is the hardware of decent quality, but it runs all the software I want. I get the commercial packages such as office and cubase vst, and I can also drop to a terminal and apt-get basic unix packages, courtesy of fink.

      I'm posting this from a dual 1ghz g4 with 15K SCSI drives. It's a fast machine, but more importantly, it's a good machine.

  7. 3DNow! by turgid · · Score: 4, Insightful

    So, PCs have 3DNow!, SSE and SSE2 depending on what processor you have. I have observed factor-of-ten speed-ups of certain code using hand-crafted 3DNow! vs. GCC floating-point. I wonder how fast his algorithm would be if implemented in 3Dnow! or SSE? I bet my rusty old K6-2/500 could put in a reasonable showing at his benchmark.

    1. Re:3DNow! by caveat · · Score: 4, Informative

      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
    2. Re:3DNow! by UberLame · · Score: 4, Informative

      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.
  8. Hardly a fair comparison by wiggys · · Score: 5, Interesting
    "Prelimenary tests indicate the Mac may be faster than PCs in RAW image conversion afterall."

    Hang on a moment. The last Mac vs PC test was conducted fairly - Photoshop on a Mac vs Photoshop on a PC. Using nearly-identical software the clear answer was that the fastest PC today was faster than the fastest Mac.

    Now someone writes more efficient code for the Mac, then tries to claim that Macs are somehow quicker than PCs? Talk about an unfair test - that's like that's like writing a pi calculator in BASIC for the PC and seeing how quickly it can calculate 1m decimal places on a 2ghz P4, then writing one in assembler for a Mac classic. If the Mac classic wins, does that mean the Mac* is faster at calculating pi than a PC?

    * Macs in general

    --

    Sorry, but my karma just ran over your dogma.

    1. Re:Hardly a fair comparison by overunderunderdone · · Score: 3, Informative

      Hang on a moment. The last Mac vs PC test was conducted fairly - Photoshop on a Mac vs Photoshop on a PC.

      No, you didn't read the article - it conducted tests using several different pieces of software but not one of them was Photoshop, although one was a third party photoshop plug-in. The tests were very narrowly focussed for a specific set of tasks of vital interest to professional digital photographers but of very little interest to anybody else.

      The complaint at the time was that all of the software used was originally written for the PC and ported to the Mac. To use your analogy: In the original article the pi calculator was written in assembly for the PC but in basic for the Mac and the Mac suffered from that. Despite the MHz gap this was counterintuitive to those who follow this kind of issue because it was exactly the kind of specialized task where the PowerPC's superior vector/SIMD performance should have (and was assumed to) MORE than compensated for it's slower clock speed. Still it's a perfectly fair test because if you're interested in doing that task and this is the only software to do it with it doesn't matter to you WHY one system is faster than the other, only that it IS.

      NOW, however as a follow up on the original story & controversy /. is pointing out that MacBibble has rewritten it's Mac version to take full advantage of the PowerPC's multithreading & Altivec processing and that it is much faster than it was before and therefore that one little task of interest only to professional photographers the Mac is back in the running as the fastest tool for that particular job.

      A fair criticism of /. (though not of Rob Galbraith) would be that they are trying to imply that these very narrow and specific benchmarks are indicative of general processor performance or general vector performance when that is not the case. In the first story the implication was that the PowerPC's one advantage had ceased to exist when that was not necessarily the case. In the second story the implication was that the PowerPC's one advantage was a general one and not tied to very specific computing tasks. In slashdots defense - RTA, the /. crowd should be assumed to be technically inclined and able to pay attention to such details and to care about them.

  9. When will people realise... by Nexum · · Score: 5, Insightful

    OK, I'm a techie and graphic designer (yes, rare).

    When will people realise that raw speed, although useful to deisgners and artists, is NOT the be all and end all of which platform is preferable for this industry.

    The main reason why macs are so dominant in publishing and art is becasue of the old (true) cliche - it just works. Designers are generally NOT a technical people, they think with the other side of their brain all day long, and technology confuses them, so even if a PC goes 20% faster at some filters, if they can't figure out problems with DLL's, conflicts, registry problems and having to reinstall Windows every 9 months then what is the better system for them?

    How about usability and workflow (please comment on these only if you've used both machines (Win & OS X) in a demanding and very time specific industry to a large extent) - OS X hands down, allows me to ignore the fact that I am using very advanced technology that's incredibly advanced and *do my job*.

    This allows me (and hundreds of thousands of others) to get a much bigger performance boost out of my work than a faster processor.

    What are the productivity gains of perfect networking, great UI, better support for FireWire, BlueTooth, Wireless stuff etc etc etc.? It's not quantifiable but it is much more important than slightly faster processors, so lets just stop the whole thing there.

    So in brief, processor speed important (and nice to see the Mac keeping up in one area) but not so important it outweighs the other thousand reasons design professionals use Macs.

    -Nex

    --

    This sig has been deprecated.
  10. Re:Isn't this pointless? by AssFace · · Score: 3, Interesting

    as I understand the PC has faster hardware in the sense that American cars have more horsepower - they just throw a ton of power at the problem and don't worry about the effeciency.
    The Mac has the ability to do some cool wider pipline stuff and specialized vector processing - but you need to design stuff especially for it - otherwise it isn't as efficient and you lose to the big block Intel/AMD family.

    I think the Playstation2 had this problem at first - it is *highly* optimized for vector processing and the first bit of releases for it hadn't taken full advantage of that.

    If I can come up with a scenerio that is useful to me where I really *need* a mac, I'd consider it - but at this point, they are simply cute as hell and that is about it.

    --

    There are some odd things afoot now, in the Villa Straylight.
  11. The speed of the hardware is irrelevant... by Junior+J.+Junior+III · · Score: 3, Insightful

    Unless the people coding the software take advantage of it. That's what I got out of the whole thing.

    --
    You see? You see? Your stupid minds! Stupid! Stupid!
  12. Re:So what? by splateagle · · Score: 3, Insightful

    same could be said of any /. post that doesn't match your specific interest set.

    point is that it's tech related and of interest to plenty of /.ers so that's why it's here, if you're not interested I suggest you read something else.

  13. Re:The mac is fastest at RC5 and tons of routines. by MonTemplar · · Score: 3, Funny

    -1, Pointless Willy-waving.

    --
    -MT.
  14. Re:Hardly a fair comparison - LIAR Mac faster in C by wiggys · · Score: 3, Funny
    Adode was caught taking large cache bribes

    cache bribes? How much did Intel give them, 64K or more?

    --

    Sorry, but my karma just ran over your dogma.

  15. jeezopetes by bdowne01 · · Score: 5, Insightful

    I'm really getting tired of the whole Mac vs. PC war being based on speed.

    I'm not really sure how many times it has to be said, but a great number of Mac users don't use Macs because they're faster. In fact, let me say it again:

    It's not about speed

    I really can't believe that with the Slashdot community--being so "in tune" with corporate ploys and runaway marketing tactics--still fall for the MHz propaganda, and the speed benchmarks that accompany it.

    Since when is the most important thing about a computer the speed? Granted, if you're playing BitchBlaster 2023 that requires a GeForce9000 Mx2+3.144 video card, maybe.

    But I'm not sure if people noticed: Most Mac people aren't die-hard gamers. Macs aren't great gaming platforms anyway. They're for people that do work with their computers and rely on them.

    These people care not about the absolute speed of their Mac, rather, they care that it works every time that it is booted and that the end-user experience is much more pleasant than someone using something like Windows XP.

    So please, people of Slashdot--I know you have above average intelligence:

    It's not about speed.

    --
    -brain
  16. It's All In The Interpretation by Dr.+Wu · · Score: 3, Insightful

    I honestly don't pay much attention to side-by-side comparisons, unless the systems themselves are significantly similar. To me, comparing an Apple to a PC is akin to doing a comparison between an Xbox and a PS2. Both systems will outperform the other when using certain tests, while in other cases they will be similar.

    It all comes down to a combination of hardware and software, and it's relatively easy to skew the results either way using these factors. So getting an unbiased test is going to be very unlikely, even in the best of conditions.

    My motto is, if it works for you, go with it.

    Dr. Wu

  17. Adobe Photoshop 7.0.x AltiVecCore Update plug-in by tholomyes · · Score: 4, Informative

    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
  18. Sweet Mother of God by wazzzup · · Score: 5, Insightful

    Will this never end?

    I love Macs, I've used them exclusively for over 10 years now and don't see myself switching anytime soon. Given that...

    To Mac zealots:
    PC are faster than Macs. Get over it. Yes the PPC chip is more elegant and efficient but it runs slow (relative to Intel). Good Altivec applications are few and far between and don't really apply to the day-to-day home and business user. If the PPC 970 comes out this summer, then maybe Macs will again TEMPORARILY hold the speed crown but until then, PC are faster by using brute force. If sheer computing performance is your #1 requirement, then a PC should be your choice. If you're poor and only have $400 to make sure your child has a computer, then a PC is your only choice. Don't even start by saying with that money you could buy some 1997 era Mac either. Please.

    To PC zealots:
    The overall user experience on an OS X system outweighs the fact that Win XP may idle faster when running Word. In those applications that can take advantage of vector processing, Altivec is far superior to 3DNow and SSE. Plus, I see a lot of complaining about the program was written explicitly for the Mac so the comparison is unfair. Welcome to our world. Most software written to support hardware (scanners, cameras, etc.) is a blatant PC port of a hastily written "good enough" POS program. Plus, Mac laptops have better battery life AND get the full desktop chip, not some crippled "mobile" version designed to prevent penile burns and 20 minute battery life.

    Personally, I'll take elegant and efficient any day. Quite frankly, I'm glad the PPC has temporarily lagged behind. It's forced Apple to really tighten up things to keep competitive and it shows. This might not have happened if the processor would make up for any code bloat and inefficiency. Look at Safari - 3MB download. Look at OS X speed from 10.0 to 10.2. Phenomenal. When the 970 comes around, OS X should theoretically run like a champ.

  19. Who Cares? by TheRaven64 · · Score: 5, Interesting

    I have a 1.33GHz Athlon. I have a CPU usage graph sitting in my system tray. My CPU usage almost never goes above 20% (exceptions: Compiling and encoding oggs, which will use 100% CPU however fast your CPU is). On a new Mac, a lot of the GUI related CPU load is shunted to the GPU, and PPC chips do run faster than x86 chips per MHz (This was never in dispute. The dispute is that a 1GHz PPC can outperform a 3GHz x86, which stretches even my 'will-to-believe'). So, If I upgrade to a new Mac with Dual 1.42GHz CPUs I get

    1. A faster CPU
    2. A spare CPU
    3. A much nicer OS (I currently dual boot Win2K and FreeBSD. Win2k is less hastle than BSD, BSD is more powerful, but requires occasional tweaking.)
    4. A better all-round system. The CPU is not everything. Firewire 800, 802.11g, Bluetooth etc all add to the system
    5. A computer that's been designed, rather than agregated, as the PC was.

    And the reason I'm still using a PC? Cost. At the moment, my 18-month old system really isn't slow enough to justify upgrading it.

    --
    I am TheRaven on Soylent News
  20. Re:RAW format by Daniel+Joannidi · · Score: 3, Insightful

    Digital Photographers enjoy the RAW format over JPEG or TIFF for several reasons. A good analogy is to consider a RAW file as a digital negative, or a JPEG or TIFF as a color slide.

    RAW images contain more information from the camera - they're unprocessed, like a digital negative. JPEG's will have much of the same information, and with a low compression ratio will often have similar 'quality'. When you bring these into Photoshop and try to modify or play with the pictures, a RAW file will give you more information to fiddle with.

    Rob Galbraith explains this in greater detail
    I've included some relevant quotes below:
    Because RAW photos are mostly unprocessed in the camera, the white balance, hue, contrast, sharpening and exposure settings can be overridden in software after the fact. All but exposure can be overridden completely; that is, the resulting processed photo will look exactly as if the photo was shot on the correct settings in the camera in the first place. Most RAW file processing apps, with most RAW file formats, allow for great underexposure recovery: shoot the picture at ISO 200, underexpose by 2 stops, use the magical software exposure compensation control to brighten the picture 2 stops, and in most respects the processed photo will resemble an ISO 800 photo straight out of the camera.
    (snip)
    So, another measure of image quality is the ability to fix white balance, exposure and other errors after the fact, in a manner that is vastly more effective, and quicker, than what could be accomplished in Photoshop with a JPEG or standard TIFF. RAW allows news photographers to continue to shoot colour negative in effect, with the same sort of latitude for various types of technical errors, instead of having to switch to the more unforgiving colour slide, which is what JPEG or standard TIFF conceptually. This analogy isn't perfect, because unlike colour negative film, which doesn't offer the same overall quality of color slide, RAW photos inherently offer better quality than JPEG or standard TIFF.