Dual Xeon Linux vs. dual G5 : Where can I find direct speed comparison?

[Jim Kroger]

It it hype or has apple blown away the x86 world?

Any pointers most appreciated.

Thanks
Jim

[digitaleon]

To comp.os.linux, comp.sys.mac.advocacy and comp.sys.mac.system
subscribers,

> From: Jim Kroger <jimkkREMOVEME@umich.edu>,

> It it hype or has apple blown away the x86 world?
>
> Any pointers most appreciated.

Aside from the hotly-debated SPEC performance comparisons on Apple's
site and the not-so-hotly-debated application performance comparisons
at the same location, nowhere as yet.

Apple has been quoting CPU2000 SPECint and CPU2000 SPECfp benchmark
results on their site @ [url]www.apple.com/powermac/performance[/url]. These
benchmarks have been both criticised as being misleading and hailed as
being _more_ accurate than the benchmarks from Dell, in both cases for
the same reasons and with good points all around.

As yet, Apple's results have not been submitted to SPEC.

During the WWDC keynote, five different applications were demonstrated
on both the PowerMac and the Xeon (which had Windows XP, rather than
RedHat Linux) in which the PowerMac put the boot through the Xeon in
performance, and application-specific benchmarks are also available on
Apple's site. Most of these utilise FP and SIMD processing more than
integer processing, and of course score higher results on the G5.

The performance of these applications was backed up by representatives
from the vendors whose applications these were, which lends some
legitimacy to them, in addition to the fact that SPEC benchmarks have,
at least in my eyes, proven themselves to be not unreliable, but not
reliable either.

When results come in, we will doubtlessly be the first to hear of them.

digitaleon.

[Heywood Mogroot]

digitaleon <this.is@fake.address> wrote in message news:<Vq2dnSG9VNzzFmOjRTvU2Q@giganews.com>...

> To comp.os.linux, comp.sys.mac.advocacy and comp.sys.mac.system
> subscribers,
>

> > From: Jim Kroger <jimkkREMOVEME@umich.edu>,

>

> > It it hype or has apple blown away the x86 world?
> >
> > Any pointers most appreciated.

>
> Aside from the hotly-debated SPEC performance comparisons on Apple's
> site and the not-so-hotly-debated application performance comparisons
> at the same location, nowhere as yet.

yes, the footnote to the "world's fastest PC" claim is on SPEC2000
*and* "professional apps".

=Heywood=

[Heywood Mogroot]

Jim Kroger <jimkkREMOVEME@umich.edu> wrote in message news:<jimkkREMOVEME-0B7A01.23203128062003@visonmassif.rs.itd.umich.edu >...

> It it hype or has apple blown away the x86 world?

Both!

> Any pointers most appreciated.

What you get with the 1.8Ghz tower:

Features common with Intel's latest & greatest desktop motherboard:
o Dual-channel PC-3200 DRAM (DDR-400)
o 1Gbit onboard ethernet
o 8x AGP
o Dual Serial ATA (not sure what RAID levels are supported)
o Onboard 5.1 audio with optical in/out

Features in common with AMD's Opteron platform:

o 64-bit CPU architecture / expandable over 4GB
o PCI-X

New Features not available on x86 yet:

o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
the memory controller (the current leading intel desktop, the 875P,
manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
CPU has its own interface to the memory controller, unlike the dual
Xeon systems, which have to share a single 533Mhz FSB interface.

o Onboard support for 802.11g, 1394b


As far as benchmarks outside of the keynote, there was this one:

First 10 frames of Adobe After Effects "Night Flight" script:

Dual 2.66 GHz Pentium Xeon: 1.2 min/frame
Dual 2.0 Ghz G5: 0.6 min/frame

[url]www.macintouch.com/g5reader.html#jun27[/url]

While we'll know more about the relative performance of the new G5's,
the one comforting thing is that Intel itself really doesn't have
anything lined up, motherboard-wise, to compete with it until sometime
next year.

(this is something of a rarity to catch Intel so flat-footed;
traditionally they have maintained a 6-12 month lead on Apple).

AMD, on the other hand, will soon have competitive systems in the
workstation market segment, eg. from the NVIDIA nForce3 boards, and
from its "Clawhammer" CPU launch later this summer.

=Heywood=

[Seebs]

In article <flippo-E843C3.06313729062003@news.central.cox.net>,
flip <flippo@mac.com> wrote:

>That is, unless you're willing to believe the Presidents of Adobe,
>Wolfram, Luxology, and several other apps who presided over side-by-side
>tests where the G5 kicked a P4's butt halfway to the moon.

Wolfram I would believe. Adobe? You must be kidding me; believing something
because Adobe said it would be just plain stupid.

-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / [email]seebs@plethora.net[/email]
[url]http://www.seebs.net/log/[/url] - YA blog. [url]http://www.seebs.net/[/url] - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: [url]http://www.plethora.net/[/url]

[flip]

In article <seeker1-929275.10415329062003@news.comcast.giganews.com>,
Seeker1 <seeker1@mac.com> wrote:

> > During the WWDC keynote, five different applications were demonstrated
> > on both the PowerMac and the Xeon (which had Windows XP, rather than
> > RedHat Linux) in which the PowerMac put the boot through the Xeon in
> > performance, and application-specific benchmarks are also available on
> > Apple's site. Most of these utilise FP and SIMD processing more than
> > integer processing, and of course score higher results on the G5.
> >
> > The performance of these applications was backed up by representatives
> > from the vendors whose applications these were, which lends some
> > legitimacy to them, in addition to the fact that SPEC benchmarks have,
> > at least in my eyes, proven themselves to be not unreliable, but not
> > reliable either.

>
> My guess would be that Apple chose five applications that were:
>
> 1. floating-point intensive (since the G5 does much better on that than
> integer)

Mathematica? Yes.

Photoshop? I don't think so. I think it's all integer.

> 2. highly SMP-aware (since this is key for their duals)

True.

> 3. very Altivec-enabled (since this is where the G5 shines)

True.

> 4. very memory-intensive (since now the shoe is on the other foot, and
> Apple is actually AHEAD in memory access speed)

Not necessarily. Mathematica is more computation intensive than memory
intensive, I would suspect.

>
> So, I don't think there was anything misleading about that part of the
> presentation, but one should realize they cherry-picked applications
> where they knew the G5 would shine. I don't view that as a distortion,
> since many people use those applications. However, not all applications
> will show this level of benefit.

That's true. HOWEVER, the items above describe exactly the way that
CPU-intensive apps should be coded. Anyone with an app that could use FP
but who tries to do it in INT should be shot. Anyone with a CPU
intensive app who doesn't make it SMP-aware (multithreaded should be
sufficient) and use Altivec where appropriate doesn't deserve to be in
the business.

Fortunately, the majority of very CPU-intensive apps meet those criteria
- on the Mac, at least.

[Heywood Mogroot]

flip <flippo@mac.com> wrote in message news:<flippo-E843C3.06313729062003@news.central.cox.net>...

> In article <CptLa.126$1H5.2814@newsfeed.avtel.net>,
> "John" <nospam@nospam.com> wrote:
>

> > Jim Kroger wrote:

> > > It it hype or has apple blown away the x86 world?

> >
> > The usual hype. When independent testing is done in a couple of months
> > the world will know that Apple once again pulled one.
> >
> >
> >

>
> That is, unless you're willing to believe the Presidents of Adobe,
> Wolfram, Luxology, and several other apps who presided over side-by-side
> tests where the G5 kicked a P4's butt halfway to the moon.

I'm not entirely convinced that the dual Xeon systems were the fastest
P4 desktop systems available last week for those particular apps.

A 3.0 GHz P4 with its 800Mhz FSB might be somewhat more performant on
those bandwidth-intensive apps (I get 4.7GB/s with the SSE2 tests on
this Canterwood system).

Still, 4.7GB/s is pretty shitty compared to the dual 2.0Ghz's 16.0GB/s
theoretical peak b/w. 3x the b/w for just twice the price!

Plus we Apple proponents shouldn't ignore AMD's new Opteron platform,
even if everybody in x86 land apparently is.

=Heywood=

[foo]

On 29 Jun 2003 12:28:56 -0700, [email]imouttahere@mac.com[/email] (Heywood Mogroot)
wrote:

>Still, 4.7GB/s is pretty shitty compared to the dual 2.0Ghz's 16.0GB/s
>theoretical peak b/w. 3x the b/w for just twice the price!

You get 4.7GB/s measured performance on the PC. What's your measured
performance on the G5?

Oh. I thought so. Well, let us know when you can get a number -
until then, "theory" isn't very interesting.

[Steve Bellenot]

In article <flippo-5B6E1C.13032629062003@news.central.cox.net>,
flip <flippo@mac.com> wrote:

>In article <seeker1-929275.10415329062003@news.comcast.giganews.com>,
> Seeker1 <seeker1@mac.com> wrote:

>> My guess would be that Apple chose five applications that were:

>> 4. very memory-intensive (since now the shoe is on the other foot, and
>> Apple is actually AHEAD in memory access speed)

>
>Not necessarily. Mathematica is more computation intensive than memory
>intensive, I would suspect.

Symbolic computations can/often have immediate calculations which require
lots of memory. A trivial example would be computing a binomial
coefficient 200 choose 100 = 200!/(100!)^2 by multiplying the factorials
out and doing the long division. By the way, this is also an example
of an integer calculation in Mathematica. The stuff below is maple,
but the idea is the same:

> binomial(200,100);

90548514656103281165404177077484163874504589675413 336841320

> factorial(200);

78865786736479050355236321393218506229513597768717 3263294742533244359449963\
40334292030428401198462390417721213891963883025764 279024263710506192662\
49528299311134628572707633172373969889439224456214 516642402540332918641\
31227428294853277524242407573903240321257405579568 660226031904170324062\
35170085879617892222278962370389737472000000000000 000000000000000000000\
0000000000000000

> factorial(100)^2;

87097824890894800794165901619444858655697206439408 4013421593253624337999634\
65833258779670963327549206446903807622196074763642 894114359201905739606\
77507881394607489905331729758013432992987184764607 375889434313483382966\
80151515628085416269176619573749317345360351959449 600000000000000000000\
0000000000000000000000000000

--
[url]http://www.math.fsu.edu/~bellenot[/url]
bellenot <At/> math.fsu.edu
+1.850.644.7189 (4053fax)

[Vareck Bostrom]

In article <flippo-5B6E1C.13032629062003@news.central.cox.net>,
flip <flippo@mac.com> wrote:

> In article <seeker1-929275.10415329062003@news.comcast.giganews.com>,
> Seeker1 <seeker1@mac.com> wrote:
>

> > > During the WWDC keynote, five different applications were demonstrated
> > > on both the PowerMac and the Xeon (which had Windows XP, rather than
> > > RedHat Linux) in which the PowerMac put the boot through the Xeon in
> > > performance, and application-specific benchmarks are also available on
> > > Apple's site. Most of these utilise FP and SIMD processing more than
> > > integer processing, and of course score higher results on the G5.
> > >
> > > The performance of these applications was backed up by representatives
> > > from the vendors whose applications these were, which lends some
> > > legitimacy to them, in addition to the fact that SPEC benchmarks have,
> > > at least in my eyes, proven themselves to be not unreliable, but not
> > > reliable either.

> >
> > My guess would be that Apple chose five applications that were:
> >
> > 1. floating-point intensive (since the G5 does much better on that than
> > integer)

>
> Mathematica? Yes.

Mathematica tends to need to do computations to arbitrary precision and
as such will most likely be using integer math to do it. The strong
showing by Mathematica is particularly impressive to me.

>
> Photoshop? I don't think so. I think it's all integer.
>

> > 2. highly SMP-aware (since this is key for their duals)

>
> True.
>

> > 3. very Altivec-enabled (since this is where the G5 shines)

>
> True.
>

> > 4. very memory-intensive (since now the shoe is on the other foot, and
> > Apple is actually AHEAD in memory access speed)

>
> Not necessarily. Mathematica is more computation intensive than memory
> intensive, I would suspect.
>

> >
> > So, I don't think there was anything misleading about that part of the
> > presentation, but one should realize they cherry-picked applications
> > where they knew the G5 would shine. I don't view that as a distortion,
> > since many people use those applications. However, not all applications
> > will show this level of benefit.

>
> That's true. HOWEVER, the items above describe exactly the way that
> CPU-intensive apps should be coded. Anyone with an app that could use FP
> but who tries to do it in INT should be shot. Anyone with a CPU
> intensive app who doesn't make it SMP-aware (multithreaded should be
> sufficient) and use Altivec where appropriate doesn't deserve to be in
> the business.
>
> Fortunately, the majority of very CPU-intensive apps meet those criteria
> - on the Mac, at least.

[Jerry Gardner]

Arturo Pérez wrote:

> Well, one could argue that only the above type of applications need the
> benefit. After all, the current shipping PowerMacs are more than capable
> of supporting applications that (to negate the above).

These types of demos/benchmarks always seem to focus on application
performance, and the applications chosen always seem to be the same.

What I never see is a comparison of the relative performance of the two
operating systems in question here: OS X and Windows XP. After all, we
spend a lot of time interacting with the operating system during the course
of our work with our machines, so why not compare the performance of the OS
as well?

Probably the reason this isn't done is because such comparisons are more
subjective. With something like Photoshop, one can say that the G5 applied
a certain filter in x seconds, while the dual Xeon did it in y seconds.
Hence, a direct comparison is possible. With an OS, this isn't as easy to
measure.

In my experience, OS X is nowhere near as responsive as Windows XP (*). I
have nothing against the Mac, in fact I own an 867 MHz Quicksilver G4. I
wish OS X were as responsive as XP, but just looking at the way OS X is
built, I can see why it's so sluggish.

The way Quartz composites 2D, 3D, and media to a composite buffer, runs it
all through the OpenGL pipeline, flattens it, and finally writes it to the
video card is time consuming. The 2D stuff all seems to be based on a PDF
imaging model, which I'm sure adds to the overhead. Even Quartz Extreme,
which optimizes this by doing some of the work on the graphics card, still
eats up processor time. All this results in slow scrolling windows, slow
window opens and closes, etc.

(*) My WindowsXP system running on a 400MHz P3 is much more responsive than
my 867 MHz G4 running OS X 10.2.6.

--
Jerry Gardner
[email]jg2-usenet@gardnerclan.net[/email]

[Seebs]

In article <flippo-5B6E1C.13032629062003@news.central.cox.net>,
flip <flippo@mac.com> wrote:

>That's true. HOWEVER, the items above describe exactly the way that
>CPU-intensive apps should be coded. Anyone with an app that could use FP
>but who tries to do it in INT should be shot.

How quickly times change!

>Anyone with a CPU
>intensive app who doesn't make it SMP-aware (multithreaded should be
>sufficient) and use Altivec where appropriate doesn't deserve to be in
>the business.

Multithreading doesn't necessarily buy you much for SMP. Many CPU-intensive
apps simply don't parallelize well.

Note also that many CPU-intensive apps can't use Altivec, because Altivec
is low-precision.

-s
--
Copyright 2003, all wrongs reversed. Peter Seebach / [email]seebs@plethora.net[/email]
[url]http://www.seebs.net/log/[/url] - YA blog. [url]http://www.seebs.net/[/url] - homepage.
C/Unix wizard, pro-commerce radical, spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: [url]http://www.plethora.net/[/url]

[David Wang]

In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

> Jim Kroger <jimkkREMOVEME@umich.edu> wrote in message news:<jimkkREMOVEME-0B7A01.23203128062003@visonmassif.rs.itd.umich.edu >...

>> It it hype or has apple blown away the x86 world?

> New Features not available on x86 yet:

> o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
> the memory controller (the current leading intel desktop, the 875P,
> manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
> CPU has its own interface to the memory controller, unlike the dual
> Xeon systems, which have to share a single 533Mhz FSB interface.

Please check again. The hypertransport interface is not between the
CPU and the memory controller. The hypertransport interface connects
between the memory/system controller and a quasi south-bridge I/O
controller.

The 6.4 GB/s is a "peak" data rate, if either the 875P or the PPC970's
companion chip can support 4.7 GB/s sustained bandwidth, then that would
be very impressive. However, I have not seen anything close to that
figure when using McCalpin's STREAM.


--
davewang202(at)yahoo(dot)com

[Vareck Bostrom]

In article <bdnpbd$cho$1@grapevine.wam.umd.edu>,
David Wang <foo@bar.invalid> wrote:

> In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

> > Jim Kroger <jimkkREMOVEME@umich.edu> wrote in message
> > news:<jimkkREMOVEME-0B7A01.23203128062003@visonmassif.rs.itd.umich.edu >...

> >> It it hype or has apple blown away the x86 world?

>

> > New Features not available on x86 yet:

>

> > o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
> > the memory controller (the current leading intel desktop, the 875P,
> > manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
> > CPU has its own interface to the memory controller, unlike the dual
> > Xeon systems, which have to share a single 533Mhz FSB interface.

>
> Please check again. The hypertransport interface is not between the
> CPU and the memory controller. The hypertransport interface connects
> between the memory/system controller and a quasi south-bridge I/O
> controller.

What is the bus between the CPU and memory controller?

>
> The 6.4 GB/s is a "peak" data rate, if either the 875P or the PPC970's
> companion chip can support 4.7 GB/s sustained bandwidth, then that would
> be very impressive. However, I have not seen anything close to that
> figure when using McCalpin's STREAM.

[Erick Bryce Wong]

Steve Bellenot <bellenot@math.fsu.edu> wrote:

>flip <flippo@mac.com> wrote:

>> Seeker1 <seeker1@mac.com> wrote:

>>> My guess would be that Apple chose five applications that were:

>

>>> 4. very memory-intensive (since now the shoe is on the other foot, and
>>> Apple is actually AHEAD in memory access speed)

>>
>>Not necessarily. Mathematica is more computation intensive than memory
>>intensive, I would suspect.

>
>Symbolic computations can/often have immediate calculations which require
>lots of memory. A trivial example would be computing a binomial
>coefficient 200 choose 100 = 200!/(100!)^2 by multiplying the factorials
>out and doing the long division. By the way, this is also an example
>of an integer calculation in Mathematica. The stuff below is maple,
>but the idea is the same:

>> binomial(200,100);

> 90548514656103281165404177077484163874504589675413 336841320

Point taken, but kind of a bad example :). Maple, like any sensible system,
doesn't compute the factorials for integer binomial coefficients. Instead,
it computes binomial(200,i) incrementally for i from 1 to 100, each time
multiplying by a single rational (using iquo to avoid unnecessary gcd
computations). So at no stage of binomial(200,100) does the intermediate
result exceed the answer :).

-- Erick

[Jim Kroger]

In article <bdnqgo$eo4$1@morgoth.sfu.ca>,
[email]erick@sfu.ca[/email] (Erick Bryce Wong) wrote:

> Steve Bellenot <bellenot@math.fsu.edu> wrote:

> >flip <flippo@mac.com> wrote:

> >> Seeker1 <seeker1@mac.com> wrote:
> >>> My guess would be that Apple chose five applications that were:

> >

> >>> 4. very memory-intensive (since now the shoe is on the other foot, and
> >>> Apple is actually AHEAD in memory access speed)
> >>
> >>Not necessarily. Mathematica is more computation intensive than memory
> >>intensive, I would suspect.

> >
> >Symbolic computations can/often have immediate calculations which require
> >lots of memory. A trivial example would be computing a binomial
> >coefficient 200 choose 100 = 200!/(100!)^2 by multiplying the factorials
> >out and doing the long division. By the way, this is also an example
> >of an integer calculation in Mathematica. The stuff below is maple,
> >but the idea is the same:

> >> binomial(200,100);

> > 90548514656103281165404177077484163874504589675413 336841320

>
> Point taken, but kind of a bad example :). Maple, like any sensible system,
> doesn't compute the factorials for integer binomial coefficients. Instead,
> it computes binomial(200,i) incrementally for i from 1 to 100, each time
> multiplying by a single rational (using iquo to avoid unnecessary gcd
> computations). So at no stage of binomial(200,100) does the intermediate
> result exceed the answer :).
>
> -- Erick

What?

[Jim Kroger]

In article <dd5de929.0306291128.4f394084@posting.google.com >,
[email]imouttahere@mac.com[/email] (Heywood Mogroot) wrote:

> Plus we Apple proponents shouldn't ignore AMD's new Opteron platform,
> even if everybody in x86 land apparently is.
>
> =Heywood=

And that's very curious to me.


Jim

[Heywood Mogroot]

David Wang <foo@bar.invalid> wrote in message news:<bdnpbd$cho$1@grapevine.wam.umd.edu>...

> In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

> > Jim Kroger <jimkkREMOVEME@umich.edu> wrote in message news:<jimkkREMOVEME-0B7A01.23203128062003@visonmassif.rs.itd.umich.edu >...

> >> It it hype or has apple blown away the x86 world?

>

> > New Features not available on x86 yet:

>

> > o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
> > the memory controller (the current leading intel desktop, the 875P,
> > manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
> > CPU has its own interface to the memory controller, unlike the dual
> > Xeon systems, which have to share a single 533Mhz FSB interface.

>
> Please check again. The hypertransport interface is not between the
> CPU and the memory controller.

yes, this makes more sense. Apple does list a 64-bit "bi-directional"
/ dual 32-bit unidirectional DDR FSB running at 1/4 the CPU speed.

This sounds like IBM's Elastic I/O...

> The hypertransport interface connects
> between the memory/system controller and a quasi south-bridge I/O
> controller.

yes, this makes more sense, very little PPC-specific stuff once you
get to the memory controller.

> The 6.4 GB/s is a "peak" data rate, if either the 875P or the PPC970's
> companion chip can support 4.7 GB/s sustained bandwidth, then that would
> be very impressive. However, I have not seen anything close to that
> figure when using McCalpin's STREAM.

I was using SiSandra's memory bandwidth tests, which uses SSE2
apparently.

=Heywood=

[David Wang]

In comp.sys.mac.advocacy Vareck Bostrom <bostrov@mac.com> wrote:

> David Wang <foo@bar.invalid> wrote:

>> In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

>> > Jim Kroger <jimkkREMOVEME@umich.edu> wrote in message
>> > news:<jimkkREMOVEME-0B7A01.23203128062003@visonmassif.rs.itd.umich.edu >...
>> >> It it hype or has apple blown away the x86 world?

>>

>> > New Features not available on x86 yet:

>>

>> > o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
>> > the memory controller (the current leading intel desktop, the 875P,
>> > manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
>> > CPU has its own interface to the memory controller, unlike the dual
>> > Xeon systems, which have to share a single 533Mhz FSB interface.

>>
>> Please check again. The hypertransport interface is not between the
>> CPU and the memory controller. The hypertransport interface connects
>> between the memory/system controller and a quasi south-bridge I/O
>> controller.

> What is the bus between the CPU and memory controller?

Elastic I/O, inherited from the Power4 lineage. A wavepipelined
interface with built in skew cancellation circuitry.

Some information may be found here in an article I wrote right
after Microprocessor Forum. I meant to do a part 2, but the
numerous delays means that I would end up doing a post release
product analysis rather than a pre-release technical analysis
of what the PPC970 sustem architecture must look like.

[url]http://www.realworldtech.com/page.cfm?ArticleID=RWT011303183140[/url]

Hypertransport is more of a peripheral to peripheral interconnect,
except that AMD added the cache coherency aspect to it, so Opteron
actually uses ccHT, a cache coherent version of Hypertransport.

Apple has a PowerMac G5 "technology overview" that describes the role
that Hypertransport plays in its system. It seems clear that
Hypretransport is used as the the connection from the northbridge
to the rest of the world.

[url]http://a352.g.akamai.net/7/352/51/e93ca6b90038b4/www.apple.com/powermac/pdf/PowerMacG5_TO_062303.pdf[/url]

Page 11.


--
davewang202(at)yahoo(dot)com

[David Wang]

In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

> David Wang <foo@bar.invalid> wrote in message news:<bdnpbd$cho$1@grapevine.wam.umd.edu>...

>> In comp.sys.mac.advocacy Heywood Mogroot <imouttahere@mac.com> wrote:

>> > New Features not available on x86 yet:

>> > o Dedicated 900Mhz (6.4GB/s) HyperTransport interface between CPU and
>> > the memory controller (the current leading intel desktop, the 875P,
>> > manages just 4.7GB/s in real bandwidth). For dual G5 systems, *each*
>> > CPU has its own interface to the memory controller, unlike the dual
>> > Xeon systems, which have to share a single 533Mhz FSB interface.

>>
>> Please check again. The hypertransport interface is not between the
>> CPU and the memory controller.

> yes, this makes more sense. Apple does list a 64-bit "bi-directional"
> / dual 32-bit unidirectional DDR FSB running at 1/4 the CPU speed.

> This sounds like IBM's Elastic I/O...

It is Elastic I/O.

[url]http://www.realworldtech.com/page.cfm?ArticleID=RWT011303183140[/url]

I did refer to "900 MHz" in the article, which ofcourse should be
900 mbps. 1/9 of the bits goes to the packet protocol overhead.

"64 bit bi-directional" bus? I'm not sure what's 64 bit and
bidirectional in there. The PCI-X bus? It's a bit removed from
the CPU interface...

>> The hypertransport interface connects
>> between the memory/system controller and a quasi south-bridge I/O
>> controller.

> yes, this makes more sense, very little PPC-specific stuff once you
> get to the memory controller.

Apple could *almost* use stock AMD64/Opteron controllers, except
AMD64/Opteron needs an AGP port in its southbridge chipset (the
CPU contains the AGP-less northbridge)

It would be interesting if Apple did use an AMD chipset later.
There'd be 2 AGP ports. One in the northbridge, one in the
southbridge.

>> The 6.4 GB/s is a "peak" data rate, if either the 875P or the PPC970's
>> companion chip can support 4.7 GB/s sustained bandwidth, then that would
>> be very impressive. However, I have not seen anything close to that
>> figure when using McCalpin's STREAM.

> I was using SiSandra's memory bandwidth tests, which uses SSE2
> apparently.

It would be very difficult for a PPC970 system to match that bandwidth,
since much of that "4.7 GB/s" is probably just streaming prefetched
reads. PPC970's read bandwidth is capped at 1/2 of the total bandwidth,
since the ports are unidirectional.

I haven't seen any 875P results for McCalpin's stream. I am guesssing
that it would report somewhere between 3.2 and 3.6 GB/s. If you can
run the stock STREAM, and report the results to McCalpin, you can
be (in)famous.

[url]www.cs.virginia.edu/stream/[/url]

--
davewang202(at)yahoo(dot)com