Slashdot Mirror
Apple's G5 Speeds Challenged
An anonymous reader was the first of a seemingly infinite stream of people to submit a URL to an argument that makes the case that the G5 isn't quite what Apple wants you to think of it. The evidence? Apple's own press material. Worth a read.
I watched the video. (http://stream.apple.akadns.net/ - requires QuickTime). Now, I'm sure there's many ways you could tweak the benchmarks and so forth but the Photoshop and Mathematica benchmarks rocked. The G5 was 2x faster than the Xeon.
I used to get involved doing benchmarking back in the good old days of Whetstone when I worked on supercomputers. Every manufacturer had a different nasty tweak to the compilers that were pulled out only when it was time to do benchmarks for a customer. The mantra then as now was: the best benchmark is the app you want to run (since most buyers of supercomputers write their own apps, porting them for a benchmark was a possibility).
The G5's may not be the hottest thing on the planet but they're close enough to get Apple back in the ball game. Nice systems architecture, nice case and the claim is they're quiet as well. Oh, and don't forget you can put in 8GB of RAM. Now even OS X doesn't need to swap :-)
The 1GHz backplane is the real news. No processor benchmark test really takes into account the total real speed of the system when running applications.
The fast backplane will speed up IO, which is a common bottleneck. 1GHz for a PC backplane is huge. The only machine I had seen a 1GHz backplane in so far is a HP-UX server. It cost wayyy more than $2000 or even $3000.
I really believe that with this new chip alliance with IBM Apple will finally be able to put that "the OS is really cool, but PCs are always faster" stuff behind them.
Yesterday was a good day for apple.
It seems to me that if somebody wanted to use an inferior product, the first thing they'd do is develop a thick skin and at a minimum ignore the criticism being lobbed at their platform of choice. That, or choose to adopt something that seems to work better for the majority so that they don't have to feel left out all the time; obviously when you get to the point of chewing out people who are trying to show you why your choice is flawed it's become a popularity contest for you already (competing, not computing).
Try not. Do or do not, there is no try.
-- Dr. Spock, stardate 2822-3.
Absolutely correct. I was somewhat bemused by all the hoopla yesterday about the G5 and it's 'speed'. I need to know how it will run programs that I will use. I don't run benchmark software very often. =)
I'm not a graphic artist, so Photoshop is unimportant to me. I don't render video, or manipulate sound, so that's not for me. I actually mostly use my home comp for games, the internet, watching movies and listening to music. Maybe it was optimistic of me to think that I was going to find a Mac that would fit my needs, but with all the hype about the G5, I thought I would finally have some reason to be interested in Macs. Does anybody have any numbers for any other programs other than Photoshop? At least some fps in Quake 3? (I don't play it, but it's a good game benchmark)
[SIG] It's like putting a moose in the blender -- a recipe for disaster!
And ironically, the problem is that they didn't benchmark differently enough: Apple used GCC to compile SPEC on the P4 and Xeon, as well as on the G5.
While this eliminates one variable from the comparison, it also eliminates a hefty percentage from the SPEC numbers one can get with Intel's compiler.
Database applications are the biggies, followed by cad/cgi. These also happen to be the applications which essentially pay the bills to may companies, so signifigant gains in processing can greatly impact profits.
You think that I'm crazy, you should see this guy!
Database applications dont have the database running on the client machine. They have it running on the oracle cluster or mainframe in the back room. The client side wouldn't need 2G of memory. And nobody in their right mind is going to run their DB server off of a client box.
I would say CAD only pays the bills at an engineering or architecture firm, and I think the best CAD packages are currently for PC. While the new apple box certainly opens the door up to porting to Apple, the lag time before Intel comes out with 64 bit proccessors wont be long enough for significant entrenchmant.
Actually, the practice originally comes from a tactic that store owners used to keep their cashiers honest.
If the product is $10, then they could just make change for $20 out of their pocket, i.e., hand the customer back a $10 bill and stuff the $20 in their pocket.
Of course cashiers would conveniently "forget" to stuff that $20 back into the drawer.
But if the product is $9.95, then they have to open up the drawer to get a nickel out.
When you add up that most customers would be like at least 2-3 items, products priced at $9.95 and $19.95 would cause the cashiers to *have* to make change out of the drawer, thus keeping them honest.
Little known fact, but it's true.
My journal has hot
gcc produces inferior code on both platforms. Intel's C compiler kicks the shit out of gcc, and likewise metrowerks C and IBM's C compiler kick the shit out of gcc too.
gcc's x86 backend has had a lot more work than the ppc backend.
It would be interesting to see intel's C on x86 vs IBM's C on PPC. Compare chips and compiler writers with one stone :)
If they would have just taken Gcc "out of the box" and benchmarked what you said would have been true. But they heavily optimised gcc by adding G5-specific code (from IBM's compiler? I hope IBM hasn't stolen it from someone else ;) and specific "lax" malloc() routines etc...
The guy may, or may not be a troll. However, the sheer amount hate mail, and the level of it, was stunning. What kind of people write stuff like that? Very few of them even attempted to address the guys points, and those that did made a hash job of it (nobody uses int math? wtf?)
Did you notice how almost all of the hatemail was addressing him in the third person?
He went onto a discussion board somewhere about the post (probably MacNN, probably one of the worst reputation Mac websites in terms of brainpower) and just cherry picked the comments he could take apart easily.
It's not like he actually *got* that hatemail. He didn't even post an email address with the article.
Isn't it funny how you can bend things to make you look favorable - just like Apple may have done?
Was not my experience, actually... With gcc-3.2.x (the 3.3 is, supposedly, even better for SSE2/MMX2) on Windows (under Cygwin) I produced an executable, that worked slightly better than that produced by Intel's compiler (a lot of double-precision math).
Both of them were about 4 times faster, than the binary produced by the Visual C compiler -- from Microsoft.
YMMV, of course...
In Soviet Washington the swamp drains you.
actualy, if you read the source, you would notice a few things tweaked in the linux kernel (talking about 2.4.20ish kernels)
/*
/* /* This decides where the kernel will search for a free chunk of vm
to quote linux/include/asm-i386/page.h:
* This handles the memory map.. We could make this a config
* option, but too many people screw it up, and too few need
* it.
*
* A __PAGE_OFFSET of 0xC0000000 means that the kernel has
* a virtual address space of one gigabyte, which limits the
* amount of physical memory you can use to about 950MB.
*
* If you want more physical memory than this then see the CONFIG_HIGHMEM4G
* and CONFIG_HIGHMEM64G options in the kernel configuration.
*/
This is speaking about kernel memory limit, which leaves you with up to 3 gigabytes of space for user processes. That is the default, if tweaked, you can get it up higher to 3.5gigabytes... but that limits the kernel to about 500megabytes.
There are _other_ issues, when dealing with single processes, if your code staticaly allocates memory , like...
int foo[1000][1000];
the system normaly uses brk(); to allocate the memory.. this is done from the bottom up.. but if you use mmap(); to grab memory, it comes from the top down.
in include/asm-i386/processor.h there is another parameter that tweaks the memory used for mmap();
* User space process size: 3GB (default).
*/
#define TASK_SIZE (PAGE_OFFSET)
* space during mmap's.
*/
#define TASK_UNMAPPED_BASE (TASK_SIZE / 3)
this limits brk(); to the first gig of memory.. which causes some of my users's fortran code to blow up.
thankfully glibc is smart, and will brk() from the bottom if it runs out of mmap space. so i just tuned TASK_UNMAPPED_BASE to be TASK_SIZE - 0x40000000 for my cluster nodes. now I can use up to 2gig of memory for a single fortran process.
gcc produces inferior code on both platforms. Intel's C compiler kicks the shit out of gcc, and likewise metrowerks C and IBM's C compiler kick the shit out of gcc too.
:)
not necessarily. we've production code that is 8x faster on x86 w/gcc than intel's icc 7.0. we're in discussion with their engineers about why. that blew my mind, though.
just a note, so you don't take it for granted