Re: Apple defends tests

[DrBoom]

"Neil Gould" > wrote in message >...

[...]

> I don't know how you get from $1400 to $3000 by adding a case, video card,
> RAM, HD and OS. Much less what the top-end G5 is likely to go for. Has
> anyone seen prices yet?

Prices are posted on Apple's web site.

Here's a Dell quote:

Dell Precision™ Workstation 450 Desktop

Dual Intel® Xeon™ Processor, 3.06GHz, 512K Cache
1GB,DDR266 SDRAM Memory,NECC (2 DIMMS)
Microsoft® Windows® XP Professional with Media using NTFS
120GB 7200RPM IDE Hard Drive with DataBurst Cache™
(2nd) 120GB 7200RPM IDE Hard Drive with DataBurst Cache™
4X DVD+RW/+R with Roxio® Easy CD Creator and DVD decode
nVidia, Quadro NVS 280, 64MB, dual monitor DVI or VGA capable
56K,v.92 data/fax modem,PCI
Dell UltraSharp™ 1702FP 17 inch Flat Panel Monitor (17.0 inch vis)
Enhanced Performance, USB (8 Hot Keys)
USB,Logitech,2 button OPTICAL w/ scroll
1394 Controller Card

120GB is the biggest option from Dell. Machine comes with
3 year warranty.

.... and an Apple quote:

Dual 2GHz PowerPC G5
1GB DDR400 SDRAM (PC3200) - 2x512
2x250GB Serial ATA - 7200rpm
ATI Radeon 9600 Pro
Apple Studio Display (17" flat panel)
56k V.92 internal modem
SuperDrive (DVD-R/CD-RW)
Apple Keyboard & Apple Mouse - U.S. English
Mac OS X - U.S. English
APP for Power Mac (3 year extended warranty)

Throw away the lame mouse from the Mac, spend $30 on a real
rodent.

The two systems are roughly comparable -- the Mac has
FireWire800 (which may mean something someday) and
larger (and probably faster) hard drives.

Prices? [drumroll]

Dell: $4,749.00
Apple: $4,722.00 (plus real mouse)

Yeah, huge premium.

You can jigger the options around so one is a little cheaper
than the other for roughly equivalent systems, but they're
in the same ballpark. I doubt this is an accident -- Apple
marketing people are perfectly capable of doing quotes on
Dell's website.

-DrBoom

[Scott Reams]

The Dell is a workstation... which if you start comparing workstations, the
G5 is no longer the first to 64bit nor is it the fastest "personal"
computer.

-S




"DrBoom" > wrote in message
om...
> "Neil Gould" > wrote in message
>...
>
> [...]
>
> > I don't know how you get from $1400 to $3000 by adding a case, video
card,
> > RAM, HD and OS. Much less what the top-end G5 is likely to go for. Has
> > anyone seen prices yet?
>
> Prices are posted on Apple's web site.
>
> Here's a Dell quote:
>
> Dell PrecisionT Workstation 450 Desktop
>
> Dual Intel® XeonT Processor, 3.06GHz, 512K Cache
> 1GB,DDR266 SDRAM Memory,NECC (2 DIMMS)
> Microsoft® Windows® XP Professional with Media using NTFS
> 120GB 7200RPM IDE Hard Drive with DataBurst CacheT
> (2nd) 120GB 7200RPM IDE Hard Drive with DataBurst CacheT
> 4X DVD+RW/+R with Roxio® Easy CD Creator and DVD decode
> nVidia, Quadro NVS 280, 64MB, dual monitor DVI or VGA capable
> 56K,v.92 data/fax modem,PCI
> Dell UltraSharpT 1702FP 17 inch Flat Panel Monitor (17.0 inch vis)
> Enhanced Performance, USB (8 Hot Keys)
> USB,Logitech,2 button OPTICAL w/ scroll
> 1394 Controller Card
>
> 120GB is the biggest option from Dell. Machine comes with
> 3 year warranty.
>
> ... and an Apple quote:
>
> Dual 2GHz PowerPC G5
> 1GB DDR400 SDRAM (PC3200) - 2x512
> 2x250GB Serial ATA - 7200rpm
> ATI Radeon 9600 Pro
> Apple Studio Display (17" flat panel)
> 56k V.92 internal modem
> SuperDrive (DVD-R/CD-RW)
> Apple Keyboard & Apple Mouse - U.S. English
> Mac OS X - U.S. English
> APP for Power Mac (3 year extended warranty)
>
> Throw away the lame mouse from the Mac, spend $30 on a real
> rodent.
>
> The two systems are roughly comparable -- the Mac has
> FireWire800 (which may mean something someday) and
> larger (and probably faster) hard drives.
>
> Prices? [drumroll]
>
> Dell: $4,749.00
> Apple: $4,722.00 (plus real mouse)
>
> Yeah, huge premium.
>
> You can jigger the options around so one is a little cheaper
> than the other for roughly equivalent systems, but they're
> in the same ballpark. I doubt this is an accident -- Apple
> marketing people are perfectly capable of doing quotes on
> Dell's website.
>
> -DrBoom

[Musikboy]

In article >, Scott
Reams > wrote:

> The Dell is a workstation... which if you start comparing workstations, the
> G5 is no longer the first to 64bit nor is it the fastest "personal"
> computer.
>
> -S
you know waht scott? your wintel can beat up my macintosh ok? You win.
you have the most powerful computer in all the world and for all we
know in all the universe. ok, you happy? chicks probbaly dig you
because of the power of that huge computer. now can we get back to
making some freakin music please?

[Scott Reams]

> > The Dell is a workstation... which if you start comparing workstations,
the
> > G5 is no longer the first to 64bit nor is it the fastest "personal"
> > computer.

> you know waht scott? your wintel can beat up my macintosh ok?

Don't take this the wrong way. This has nothing to do with one being better
than the other. The G5 could turn out to be the fastest system on the
planet... and that would be great. The issue here is Apple's marketing,
which comes off as deceptive to potential switchers in the PC world. There
are better ways to appeal to those not already using Apple computers. Being
straight up is one of those ways.

-S

[Scott Reams]

> Besides, what is the difference between "Workstation" and "Personal
Computer"
> other than what the vendor decided to call it?

That is exactly my point. What is the difference? If there is no difference
besides the name... then Apple's claim to be first to 64bit is incorrect.
Their claim to the fastest personal computer is also suspect because there
are a number of personal computer/workstation CPUs missing from their tests.

Regardless of whether one can find a way to justify it... it leaves a bad
taste in the mouth of those who might have considered switching to Apple. My
point is only that Apple could have won over a whole lot more people with an
approach that at least appeared to be respectable.

-S

[Scott Dorsey]

Scott Reams > wrote:
>Don't take this the wrong way. This has nothing to do with one being better
>than the other. The G5 could turn out to be the fastest system on the
>planet... and that would be great. The issue here is Apple's marketing,
>which comes off as deceptive to potential switchers in the PC world. There
>are better ways to appeal to those not already using Apple computers. Being
>straight up is one of those ways.

Deceptive marketing through benchmarks has been the order of the day in
the computer industry since T.J. Watson's era. Why does Apple's latest
foray into doubtful benchmarks surprise you? The PC folks do the same
thing, as do most of the workstation vendors.

Who believes numbers from the manufacturer? Next thing you know, you will
be believing the response plots on microphone data sheets (which are almost
always artificially smoothed, and occasionally totally made up).
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

Scott Reams > wrote:
>> Besides, what is the difference between "Workstation" and "Personal
>Computer"
>> other than what the vendor decided to call it?
>
>That is exactly my point. What is the difference? If there is no difference
>besides the name... then Apple's claim to be first to 64bit is incorrect.
>Their claim to the fastest personal computer is also suspect because there
>are a number of personal computer/workstation CPUs missing from their tests.

I used to have a Cyber 830 that I didn't have to share with anyone. Does
that count as a 64-bit personal computer? That was, well, it was a long
time ago.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Reams]

Just to be clear...

It's all about perception. PC users see it as an attempted deception. It
would have been wiser on Apple's part to find a bunch of benchmarks in which
the G5 clearly excels (hopefully benchmarks unlike SPEC where one can go
find much better scores than Apple's for P4 on the official SPEC site... and
no scores for G5)... and avoid other benchmarks. That's typically what the
"PC Folks" are up to when trying to make their stuff look good.

I had much less of a problem with Apple when they were showing the G4 to be
faster than other CPUs by using very specific Adobe Photoshop benchmarks.
That's just selective benchmarking. As long as you aren't a review site,
that method seems at least somewhat honest to me.

-S

"Scott Dorsey" > wrote in message
...
> Scott Reams > wrote:
> >Don't take this the wrong way. This has nothing to do with one being
better
> >than the other. The G5 could turn out to be the fastest system on the
> >planet... and that would be great. The issue here is Apple's marketing,
> >which comes off as deceptive to potential switchers in the PC world.
There
> >are better ways to appeal to those not already using Apple computers.
Being
> >straight up is one of those ways.
>
> Deceptive marketing through benchmarks has been the order of the day in
> the computer industry since T.J. Watson's era. Why does Apple's latest
> foray into doubtful benchmarks surprise you? The PC folks do the same
> thing, as do most of the workstation vendors.
>
> Who believes numbers from the manufacturer? Next thing you know, you will
> be believing the response plots on microphone data sheets (which are
almost
> always artificially smoothed, and occasionally totally made up).
> --scott
> --
> "C'est un Nagra. C'est suisse, et tres, tres precis."

[reddred]

"Scott Dorsey" > wrote in message
...
> reddred > wrote:
> >
> >If you start splitting the head of hair, Linux isn't Unix, BSD isn't
Unix,
> >there's really only one Unix anyway... off and on, it seems that the
> >important thing is that it's not Windows.
>
> Linux is Unix. Every single one of the kernal calls in the v7 manual is
> in Linux (which the exception of two that got dropped after v7 and didn't
> even appear in v/32).
>
> BSD is so Unix that AT&T sued the Regents over distribution of their
source
> code.

*Just to note that said code was removed a long time ago.

>Oh yes, and every one of the kernal calls in the v7 manual is in Linux,
> with those two exceptions.
>
> Now it's true that the v7 kernal, the BSD kernal, and the SysV kernal are
> radically different from one another, but they all have supersets of the
> same interface to the applications code, which makes the all Unix.
>

I have trouble accepting that this issue boils down to interface
compatability, when the philosophies of all of the above are indeed
radically different. And there are obviously legal differences. If an OS
meets the proprietary spec, it doesn't mean they want to be called 'Unix'.

> Mach and VMS don't have the same interfaces from the kernal at all, even
> though they have compatibility libraries which allow you to make those
> system calls to an intermediate layer and have them work.
>

Which is probably a good thing, I agree. But the main difference here,
technically is microkernal vs. monolithic. That's something that still has a
decent technological definition. Unix doesn't anymore.

I guess what I was getting at is, what are people supposed to call Unix-like
systems?
'Loose-collection-of-mostly-posix-compliant-bits-of-operating-systems-that-a
ct-like-unix-but-arent'?

Zdnet will never print an article called 'Apple - keeping Mach alive' but
they will call MacOS 'Unix' over and over. The integration at kernel-level
of Apple's Mach with BSD clouds the issue even further. I guess it's not
written in stone, but I'm not sure where the motivation would come from to
change it at this point, so for all practical purposes it remains
'Unix-like'.

> >I imagine the switch to the Unix filesystem was more of a compatability
> >decision than one based on desire for an elegant solution. They need to
> >establish that, and it was a good move from that point of view. It might
not
> >have been what I would have done either, but overall OSX turned out
pretty
> >well.
>
> The problem is that you get compatibility with other 4.2ish filesystems,
> but you get reduced compatibility with older Macs.

A problem for us, but not for Jobs & co...

>And the wacky way of
> implementing legacy fileystem interfaces with calls that make two files
> appear as one is kind of ugly to say the least,

Probably not high on the list of Apple's priorities, because it's one of
those problems they want to go away as quickly and as profitably as
possible.

>and reminiscent of some
> of the nasty kludges used to make VMS and Unix machines talk.

Got any horror stories?

jb

[R Krizman]

<< I didn't miss a party, did I? I was tracking horns all day...
--
Dave Martin >><BR><BR>

Music, baaah.

-R

[Scott Reams]

Sigh.

This particular issue in this particular thread has nothing to do with one
being better than the other.

When the G5 is available for testing, it may or may not turn out to be a
better performer audio-wise than other systems... and that is, indeed, one
important consideration. If it weren't... people wouldn't bother buying
multi-card PT HD systems. There's a reason you choose an HD3 over an HD2.

-S


"R Krizman" > wrote in message
...
> Scott wrote:
>
> << Don't take this the wrong way. This has nothing to do with one being
better
> than the other. >><BR><BR>
>
> Exactly my point.
>
> Thank you.
>
> -R

[Scott Dorsey]

Scott Reams > wrote:
>
>It's all about perception. PC users see it as an attempted deception. It
>would have been wiser on Apple's part to find a bunch of benchmarks in which
>the G5 clearly excels (hopefully benchmarks unlike SPEC where one can go
>find much better scores than Apple's for P4 on the official SPEC site... and
>no scores for G5)... and avoid other benchmarks. That's typically what the
>"PC Folks" are up to when trying to make their stuff look good.

And PC users don't see it as an attempted deception when PC manufacturer
A shows numbers twice as good as manufacturer B, and they buy the machine
from manufacturer A and runs their applications more slowly?

I think you are unfairly blaming Apple for something common to the whole
industry.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

reddred > wrote:
>"Scott Dorsey" > wrote in message
>>
>> Now it's true that the v7 kernal, the BSD kernal, and the SysV kernal are
>> radically different from one another, but they all have supersets of the
>> same interface to the applications code, which makes the all Unix.
>>
>
>I have trouble accepting that this issue boils down to interface
>compatability, when the philosophies of all of the above are indeed
>radically different. And there are obviously legal differences. If an OS
>meets the proprietary spec, it doesn't mean they want to be called 'Unix'.

That has become the difference between "Unix" and other things. Unix supplies
a "POSIX-Compliant" (whatever that really means now) interface between the
kernal and the appliction level.

>> Mach and VMS don't have the same interfaces from the kernal at all, even
>> though they have compatibility libraries which allow you to make those
>> system calls to an intermediate layer and have them work.
>>
>
>Which is probably a good thing, I agree. But the main difference here,
>technically is microkernal vs. monolithic. That's something that still has a
>decent technological definition. Unix doesn't anymore.

No. VMS is a huge monolithic lump. It has an additional layer of junk
between the kernal and the application available in order to fake a POSIX
application interface. It's not a microkernal, but it's not Unix either.

>I guess what I was getting at is, what are people supposed to call Unix-like
>systems?
>'Loose-collection-of-mostly-posix-compliant-bits-of-operating-systems-that-a
>ct-like-unix-but-arent'?

Unix-like. Xinu is Unix-like. Minix is Unix-like.

>Zdnet will never print an article called 'Apple - keeping Mach alive' but
>they will call MacOS 'Unix' over and over. The integration at kernel-level
>of Apple's Mach with BSD clouds the issue even further. I guess it's not
>written in stone, but I'm not sure where the motivation would come from to
>change it at this point, so for all practical purposes it remains
>'Unix-like'.

Unix-like is okay. But saying it's Unix isn't to my mind.

>>and reminiscent of some
>> of the nasty kludges used to make VMS and Unix machines talk.
>
>Got any horror stories?

Lots and lots. The thing is that VMS has a dual-fork filesystem as well
if you want to think about it that way. There is formatting information
stored in the directory along with each file. So you can have a text file
that is a STREAM_LF file, or is a variable-record-length file with 80 column
maximum length records, and they seem the same from the user perspective but
they are different.

This is because the operating system itself has a lot of database stuff
built into it, so you can just open up a file and say it's an ISAM or KSAM
database file and all of the database stuff gets done for you.

But now when you NFS mount that file from a Unix box, all of the information
is lost. You take that ISAM file and use ftp to copy it over to another
machine, and all of a sudden the OS thinks it's a STREAM_LF file and you
need to go in and tweak the format parameters by hand to make them match.

The VMS filesystem is really amazing for commercial database applications,
and it's really a shame to see it going away in favor of lowest common
denominator heirarchical filesystems like the 4.2 and NT filesystems.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Justin Ulysses Morse]

Scott Reams > wrote:

> What I'm saying is... the performance gap between G5 and G4 is pretty
> substantial. How long will it be before the G5 CPU appears in the more
> consumer-oriented eMacs and iMacs? The performance gap between eMac/iMac and
> Power MAC will be much larger than the performance gap between a $3000 PC
> and a sub-$1000 PC. At least for a while.

Absolutely. But remember, this product was only just announced and it
won't even be available til August. We have to know there's a team of
uber-geeks working round the clock on a G5 iMac shaped like a stalk of
wheat and a blazing new pocket-sized powerbook made of solid plutonium
with a 26" inflatable video screen as we speak. I bet there'll be a G5
iBook that's visually indistinguishable from an eyeshadow compact
that'll sell for $199. Maybe they won't be out til October. Who
knows.

ulysses


> "Justin Ulysses Morse" > wrote in message
> ...
> > Scott Reams > wrote:
> >
> > > This is generally because PC users know they don't have to spend
> anywhere
> > > near workstation prices to get near-workstation performance. $1000 will
> get
> > > you something that is in high-end Athlon/P4/G5 territory. Apple users
> expect
> > > to pay a premium... and so they will. Apple has no direct competition to
> > > keep prices down, and devoted Apple users are unlikely to switch.
> >
> > You're comparing prices on Apples that aren't even out yet to prices on
> > P4 machines that are less than state of the art. Prices on both
> > platforms plummet in the first couple of months they're available.
> > Yes, the current flagship Apple is usually upwards of $3000 but if you
> > price out THE fastest P4 you can get, you'll find yourself in the same
> > ballpark. 3.2GHz P4 processors alone are over $700 right now.
> > Regardless of how a 2GHz G5 compares to a 3.2GHz P4, they're both at a
> > premium because they're new. Put two of those $700 P4 processors into
> > a case as badass as the G5, fill it up with a superdrive, OS, and all
> > the other finesse and you'll find yourself in the general neighborhood
> > of thirty benjamins. Likewise, when the dual 3GHz G5 is released, the
> > price of the dual-2G will drop.
> >
> > ulysses
>
>

[Brian Tankersley]

Being as objective as I know how, I really believe the Apple numbers are
simply more deceptive than anything I've seen from another PC
manufatcurer. Ever.

Seriously, the x86 PC world is (IMO) overly benchmark oriented. It's an
obsession. But as such, it's also highly scrutinized. If Dell, Compaq,
etc or even Nvidia, ATI, Intel, AMD had posted numbers that were so
obviously skewed *to that severity*, they would be laughed off of the PC
map at least as badly as Apple.

Believe me or not, as you choose, but Apple is getting no more grief
from the community than any other company would for this degree of
jivishness on the numbers, given such a milestone product introduction.
..

Regards,
Brian T

Scott Dorsey wrote:

>And PC users don't see it as an attempted deception when PC manufacturer
>A shows numbers twice as good as manufacturer B, and they buy the machine
>from manufacturer A and runs their applications more slowly?
>
>I think you are unfairly blaming Apple for something common to the whole
>industry.
>--scott
>
>
>
>

[Hal Laurent]

"Scott Dorsey" > wrote in message
...
> reddred > wrote:

> The thing is that VMS has a dual-fork filesystem as well
> if you want to think about it that way. There is formatting information
> stored in the directory along with each file. So you can have a text file
> that is a STREAM_LF file, or is a variable-record-length file with 80
column
> maximum length records, and they seem the same from the user perspective
but
> they are different.

If I recall correctly (and it's been quite a number of years since I did
VMS programming), a VMS directory doesn't have much more than the name
and dates of a file. I believe the record format and other information is
stored
in the file header in INDEXF.SYS.

Hal Laurent
Baltimore, Maryland

[Scott Dorsey]

In article >,
Hal Laurent > wrote:
>
>"Scott Dorsey" > wrote in message
...
>> reddred > wrote:
>
>> The thing is that VMS has a dual-fork filesystem as well
>> if you want to think about it that way. There is formatting information
>> stored in the directory along with each file. So you can have a text file
>> that is a STREAM_LF file, or is a variable-record-length file with 80
>column
>> maximum length records, and they seem the same from the user perspective
>but
>> they are different.
>
>If I recall correctly (and it's been quite a number of years since I did
>VMS programming), a VMS directory doesn't have much more than the name
>and dates of a file. I believe the record format and other information is
>stored
>in the file header in INDEXF.SYS.

Yes, this is how it's done.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Kurt Albershardt]

reddred wrote:
>
>> Now it's true that the v7 kernal, the BSD kernal, and the SysV kernal are
>> radically different from one another, but they all have supersets of the
>> same interface to the applications code, which makes the all Unix.
>
> I have trouble accepting that this issue boils down to interface
> compatability, when the philosophies of all of the above are indeed
> radically different. And there are obviously legal differences. If an OS
> meets the proprietary spec, it doesn't mean they want to be called 'Unix'.
> ...
> I guess what I was getting at is, what are people supposed to call Unix-like
> systems?
> 'Loose-collection-of-mostly-posix-compliant-bits-of-operating-systems-that-a
> ct-like-unix-but-arent'?

I usually refer to them as *nix or unices (small 'U')

[reddred]

"Scott Dorsey" > wrote in message
...
> reddred > wrote:

> >Zdnet will never print an article called 'Apple - keeping Mach alive' but
> >they will call MacOS 'Unix' over and over. The integration at
kernel-level
> >of Apple's Mach with BSD clouds the issue even further. I guess it's not
> >written in stone, but I'm not sure where the motivation would come from
to
> >change it at this point, so for all practical purposes it remains
> >'Unix-like'.
>
> Unix-like is okay. But saying it's Unix isn't to my mind.
>

The Open Group doesn't even want people to say 'Unix-like', but a lot of
people agree with you. To people outside of the field though, I think saying
'Unix' is becoming like saying 'Xerox'.

> >>and reminiscent of some
> >> of the nasty kludges used to make VMS and Unix machines talk.

> But now when you NFS mount that file from a Unix box, all of the
information
> is lost. You take that ISAM file and use ftp to copy it over to another
> machine, and all of a sudden the OS thinks it's a STREAM_LF file and you
> need to go in and tweak the format parameters by hand to make them match.
>

That's relevant to the problems with doing any file system involving some
kind of metadata at this point.

> The VMS filesystem is really amazing for commercial database applications,
> and it's really a shame to see it going away in favor of lowest common
> denominator heirarchical filesystems like the 4.2 and NT filesystems.

Shame about DEC in general. But then, they had standards issues as well -
and standards are almost always the lcd. Hopefully it just gets better over
time.

jb

[Scott Dorsey]

reddred > wrote:
>"Scott Dorsey" > wrote in message
>>
>> Unix-like is okay. But saying it's Unix isn't to my mind.
>>
>The Open Group doesn't even want people to say 'Unix-like', but a lot of
>people agree with you. To people outside of the field though, I think saying
>'Unix' is becoming like saying 'Xerox'.

That doesn't sound very open of them to me.

>> >>and reminiscent of some
>> >> of the nasty kludges used to make VMS and Unix machines talk.
>
>> But now when you NFS mount that file from a Unix box, all of the
>information
>> is lost. You take that ISAM file and use ftp to copy it over to another
>> machine, and all of a sudden the OS thinks it's a STREAM_LF file and you
>> need to go in and tweak the format parameters by hand to make them match.
>
>That's relevant to the problems with doing any file system involving some
>kind of metadata at this point.

Right, unless everybody is using the same metadata and there is some way
of transferring it along with the file. In an all-DEC environment, you
can share files with the Vaxcluster software instead of NFS, and you can
copy files around through DECNET rather than FTP, and all of the out of
band information is preserved. The problme comes when you are using
filesystems with metadata in a world in which it's not preserved (which
was the big nightmare working with MacOS in a PC world too).

>> The VMS filesystem is really amazing for commercial database applications,
>> and it's really a shame to see it going away in favor of lowest common
>> denominator heirarchical filesystems like the 4.2 and NT filesystems.
>
>Shame about DEC in general. But then, they had standards issues as well -
>and standards are almost always the lcd. Hopefully it just gets better over
>time.

Everybody did. In the case of DEC and IBM, they started using something
when there was no agreed-upon standard, and then when the standard arrived,
they had too much of an entrenched infrastructure to change over. IBM is
only now moving over en-mass to ASCII, in spite of the fact that they
started with the 360/44 which had ASCII manipulation instructions (which they
later dropped since nobody ever used them).
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Jonas Eckerman]

> The VMS filesystem is really amazing for commercial database
> applications, and it's really a shame to see it going away in favor of
> lowest common denominator heirarchical filesystems like the 4.2 and NT
> filesystems.

NTFS supports multiple datastreams in one file, so to store a VMS file on
NTFS you should be able to store that extra data in one of the non primary
data streams.

The problem when copying from a VMS system to NTF is of course still there
unless you find a transfer method that correctly does this in both
directions.

I do hope some good protocols will some day evolve that actually let's me
copy files containing as much as possible with the two file systems
invlolved (like putting the extended attributes from HPFS in a non primary
stream on NTFS). Today I can't even transfer files reliably between
computers using the same filesystem without sometimes loosing information.
:-/

Regards
/Jonas

[Kurt Albershardt]

Jonas Eckerman wrote:
>> The VMS filesystem is really amazing for commercial database
>> applications, and it's really a shame to see it going away in favor of
>> lowest common denominator heirarchical filesystems like the 4.2 and NT
>> filesystems.
>
>
> NTFS supports multiple datastreams in one file, so to store a VMS file on
> NTFS you should be able to store that extra data in one of the non primary
> data streams.

Given the DEC/VMS origins of the original NT development team, one can
understand this.


For those who aren't familiar with it, I recommend Hans Reiser's
whitepapers. Interesting stuff, even if you don't intend to use
reiserfs http://www.namesys.com/

[R Krizman]

<< Rick wrote:

> Music, baaah.


Dave said "horns". <g>


Chris
>>


I see your point.

Okay, back to the bean counting.

-R

[Dave Martin]

"R Krizman" > wrote in message
...
> << Rick wrote:
>
> > Music, baaah.
> Dave said "horns". <g>
> Chris

> I see your point.
>
> Okay, back to the bean counting.
>
(As the Mad Hatter said to the March Hare, "But they were the very best
horns.... "

Unfortunately, with horn players attached...

--
Dave Martin
Java Jive Studio
Nashville, TN
www.javajivestudio.com

[Glenn Booth]

Hi,

In message >, Scott
Reams > writes
>> Deceptive marketing through benchmarks has been the order of the day in
>> the computer industry since T.J. Watson's era. Why does Apple's latest
>> foray into doubtful benchmarks surprise you? The PC folks do the same
>> thing, as do most of the workstation vendors.
>
>Not to the same degree. I challenge you or anyone else to give a specific
>example.

Take a look at

http://slashdot.org/articles/03/05/15/0620209.shtml?tid=152&tid=185&tid=1
37

I'm not trying to rise to your challenge, but I know for a fact that
benchmark cheating in the PC marketplace is rife. Check out the recent
battle between ATi and nVidia, documented on www.theregister.com, over
the 3DMark 2003 benchmark suite. I've been seeing this **** for years. I
even know one (now defunct) PC system builder that would swap out the
cache chips on hard drives before submitting systems for magazine
reviews, to screw a few extra benchmark points of out of them. Needless
to say, the customers would never see those bigger cache chips in their
systems.
--
Regards,
Glenn Booth

[R Krizman]

<< As the Mad Hatter said to the March Hare, "But they were the very best
horns.... "

Unfortunately, with horn players attached...

--
Dave Martin >><BR><BR>

That's true, it's really unfair to blame the horns.

-R

[Scott Reams]

> Honestly, it's well past the time that your professional practice be
> announced in a .sig file so that readers can keep your comments in
> contect, much as they do with Fletcher, Jay F., Jay K., etc.
>
> You build and vend DAW's based on non-Apple hardware. Your bread and
> butter bias is understandable and would serve you better if placed right
> up front.

The DAW "business" is certainly not my bread and butter. There really isn't
much money in it. That said... by bias favors the most capable machine
available, whether it be PC, Mac, or Sun workstation. The only reason the
systems I build at this particular moment have Athlon CPUs is because my
research has found them to perform best at this particular moment.

-S

[Brian Tankersley]

That's true. It actually hurt Nvidia's cred in the gaming community.
Apple is getting no more flak than anybody else would for taking the
same, extreme "liberties" in their benchmarks. Like I said before, the
PC community is benchmark obsessed. Therefore, the scrutiny is extreme.
I don't think Apple has had to play by the same rules in the Apple
community, so this level of reaction seems like a shocker to them. It's
not. It's completely normal in the PC community. And that atmosphere
does make for generally more credible benchmarks,

Brian T

Scott Reams wrote:

>An interesting example... but really one that just proves the point. NVidia
>was hammered by the industry for this by everyone
>
>
>

[EggHd]

<< That's true. It actually hurt Nvidia's cred in the gaming community. >>

Is the Nvidia and Radion (sp) video cards pretty much equal?



---------------------------------------
"I know enough to know I don't know enough"

[LeBaron & Alrich]

R Krizman > wrote:

> << As the Mad Hatter said to the March Hare, "But they were the very best
> horns.... "

> Unfortunately, with horn players attached...

> --
> Dave Martin >><BR><BR>

> That's true, it's really unfair to blame the horns.

Right, it's the rhinoceros that's dangerous, nevermind his horn.

--
ha

[nuke]

Nahh, Apple's most likely completely used to the situation. It spans back to
the days of the SE30, then the MacII-FX, the first generation PowerPC systems,
the first G3, the intro of Altivec. All of these systems were top performers in
their day, compared to anything in the x86 world.

The reality is you can't list a benchmark without someone saying, "yeah but..."


With the complexity of today's computers, it's really difficult to answer the
question, "How fast is it?" The answer will always start, "depends on what you
do with it."

So when it is your stage, you show it the way you see it. Doesn't really matter
what you say or do, someone will **** and moan about it.

But the test methods are all completely disclosed, it's not like they ran in
and laid claim to baseless figures. You can argue it until the cows come home,
but the only thing you can come away with is that the G5 is pretty darn fast.

<< Apple is getting no more flak than anybody else would for taking the
same, extreme "liberties" in their benchmarks. Like I said before, the
PC community is benchmark obsessed. Therefore, the scrutiny is extreme.
I don't think Apple has had to play by the same rules in the Apple
community, so this level of reaction seems like a shocker to them. It's
not. It's completely normal in the PC community. >><BR><BR>

--
Dr. Nuketopia
Sorry, no e-Mail.
Spam forgeries have resulted in thousands of faked bounces to my address.

[Glenn Booth]

Hi,

In message >, EggHd
> writes
><< That's true. It actually hurt Nvidia's cred in the gaming community. >>
>
>Is the Nvidia and Radion (sp) video cards pretty much equal?

My take is frankly, if you're main interest is audio, then any
difference doesn't matter one iota. The 'fight' was over 3D performance,
which is where a very vocal small minority makes a very loud noise over
performance, because they can't stand to have a friend with a 'faster'
system than they have.

It matters only for games. In 'real' apps (the ones people earn money
with in the audio world) most of us should pay far more attention to
driver stability and compatibility than 3D benchmark performance.

If you run 3D Studio Max, Lightwave or Maya for a living, then ignore
the above comment, and read the feedback on their respective forums
about performance, then choose. If you want to run Quake, then does the
difference between 140 and 150 frames per second really matter?

FWIW, the new Radeon 9800 and the newest nVidia top spec chips are both
killers in 3D, but you can dry your hair with the fans on those boards,
so IMO, they don't make a great choice for a DAW. Too damned noisy, and
bus greedy. Better to go for a card with good 2D performance, good
compatibility, well behaved drivers and good image quality, preferably
with passive cooling. Then put a killer 3D card in your gaming rig, or
buy an X-box. Caveat: I work for Matrox. We don't really do gaming
cards, but I might just be biased anyway ;-)

>"I know enough to know I don't know enough"

I'm gonna steal this sig one day :-)

--
Regards,
Glenn Booth

[Scott Reams]

> Nahh, Apple's most likely completely used to the situation. It spans back
to
> the days of the SE30, then the MacII-FX, the first generation PowerPC
systems,
> the first G3, the intro of Altivec. All of these systems were top
performers in
> their day, compared to anything in the x86 world.
>
> The reality is you can't list a benchmark without someone saying, "yeah
but..."

Of course... but you will see certain situations where the response is much
louder than it is in other situations... and it is usually because the
methods are more than just a little questionable. Intel, AMD, and everybody
else have been posting benchmark results for some time and getting responses
here and there... but it all pales in comparison to the responses you get
when you go as far as Apple and NVidia did (even if NVidia did what they did
in response to a benchmark that was questionable in the first place). If
Intel, AMD, Dell, Sun, or anyone else had posted benchmarks in a similar
fashion as Apple did, they would have been torn apart. It doesn't matter who
it is.

-S

[Glenn Booth]

Hi,

In message >, Scott Reams
> writes
>> Nahh, Apple's most likely completely used to the situation. It spans back
>to
>> the days of the SE30, then the MacII-FX, the first generation PowerPC
>systems,
>> the first G3, the intro of Altivec. All of these systems were top
>performers in
>> their day, compared to anything in the x86 world.
>>
>> The reality is you can't list a benchmark without someone saying, "yeah
>but..."
>
>Of course... but you will see certain situations where the response is much
>louder than it is in other situations... and it is usually because the
>methods are more than just a little questionable. Intel, AMD, and everybody
>else have been posting benchmark results for some time and getting responses
>here and there... but it all pales in comparison to the responses you get
>when you go as far as Apple and NVidia did (even if NVidia did what they did
>in response to a benchmark that was questionable in the first place). If
>Intel, AMD, Dell, Sun, or anyone else had posted benchmarks in a similar
>fashion as Apple did, they would have been torn apart. It doesn't matter who
>it is.

You're right...it doesn't matter who it is, and it shouldn't. If the
vendors would get the engineers to concentrate on running real
application software well, rather than concentrating resources on
running benchmark software 'A' faster than competitor 'X' runs it, we
(the customers) might be better off.

Unfortunately, the marketing department is probably holding the pay
checks for those very engineers, and reviews based on benchmarks make
for cheap exposure, so the whole strategy depends on having to be seen
to be winning. The reviewer wins too. (S)he clicks on the 'run' command
for the publishing house's favourite benchmark suite, and in 20 minutes
(or so) bang, there's a half page of pretty graphs for next month's
magazine or web page. Much easier than firing up a bunch of complicated
applications and making subjective comments about how they run. You can
look deeper, and learn more, but many reviewers don't, and quite a lot
of them can't.

--
Regards,
Glenn Booth

[Kurt Albershardt]

nuke wrote:

> Nahh, Apple's most likely completely used to the situation. It spans back to
> the days of the SE30, then the MacII-FX, the first generation PowerPC systems,
> the first G3, the intro of Altivec. All of these systems were top performers in
> their day, compared to anything in the x86 world.

I have clear memories of those first PPC 601-based Macs and they were
hardly "top performers in their day" even in the Mac world.

[Musikboy]

In article >, Scott
Reams > wrote:

> > Honestly, it's well past the time that your professional practice be
> > announced in a .sig file so that readers can keep your comments in
> > contect, much as they do with Fletcher, Jay F., Jay K., etc.
> >
> > You build and vend DAW's based on non-Apple hardware. Your bread and
> > butter bias is understandable and would serve you better if placed right
> > up front.
>
> The DAW "business" is certainly not my bread and butter. There really isn't
> much money in it. That said... by bias favors the most capable machine
> available, whether it be PC, Mac, or Sun workstation. The only reason the
> systems I build at this particular moment have Athlon CPUs is because my
> research has found them to perform best at this particular moment.
>
> -S
>
Scott, you just keep on digging the hole deeper and deeper.

[nuke]

>I have clear memories of those first PPC 601-based Macs and they were
>hardly "top performers in their day" even in the Mac world.

They were indeed, for some things.

At the time, I was grinding numbers and the PPC-601 soundly smoked the crap out
of any of the available pentii of the day.

Then the P-Pro came out, and it was best of the heap.

Then the G3 came out and it was better for a lot of stuff then Pent-pro, II and
III. By then I was grinding numbers for chromosome analysis and we tried both.
The G3 could just toast the Pentia by a severe margin in that particular
application. We would have gladly switched platforms at the time, since it was
all $100K a seat vertical market stuff anyway.

Then the clock speeds began to go up as AMD and Intel fought each other and the
G4 lagged behind except on stuff you could put into vector format for SIMD
processing and it still smoked P3/P4 at twice the clockspeed.

Now we get the G5, which I think at least closes the gap. Likely, it's probably
going to run ahead on some stuff and a bit behind on other stuff. But it looks
like it is all in the same ballpark. So what does it matter?

FWIW, I'm still using a much slower Mac because me, the human, is faster using
it.



--
Dr. Nuketopia
Sorry, no e-Mail.
Spam forgeries have resulted in thousands of faked bounces to my address.

[Scott Reams]

> Then the clock speeds began to go up as AMD and Intel fought each other
and the
> G4 lagged behind except on stuff you could put into vector format for SIMD
> processing and it still smoked P3/P4 at twice the clockspeed.

How did it compare when the scales were evened out and the code also
supported the SSE and SSE2 SIMD sets?

> Now we get the G5, which I think at least closes the gap.

That does look likely.

> Likely, it's probably
> going to run ahead on some stuff and a bit behind on other stuff. But it
looks
> like it is all in the same ballpark.

Yep.

-S

[Kurt Albershardt]

nuke wrote:

>> I have clear memories of those first PPC 601-based Macs and they were
>> hardly "top performers in their day" even in the Mac world.
>
> They were indeed, for some things.
>
> At the time, I was grinding numbers and the PPC-601 soundly smoked the crap out
> of any of the available pentii of the day.


Mighta been the early OS ports or some sort of internal bandwidth issue
then, because they (6100s as I recall) were dog slow at database and
office stuff we were integrating to.


About two years later, we started using the DEC PC's with Alpha 233
cards in them and they smoked the crap out of all sorts of things...

[nuke]

>How did it compare when the scales were evened out and the code also
>supported the SSE and SSE2 SIMD sets?

SSE was a complete ****ing joke compared to the vector engine in the G4. No
kidding. It resoundingly smoked the intel family on best-case optimized code
that applied well to this kind of processing.

Like BLAST and the other protein folding number cruncher applications out
there, they run killer on alti-vec. The only challenge is feeding them with
data.


--
Dr. Nuketopia
Sorry, no e-Mail.
Spam forgeries have resulted in thousands of faked bounces to my address.

[nuke]

>Mighta been the early OS ports or some sort of internal bandwidth issue
>
>then, because they (6100s as I recall) were dog slow at database and
>office stuff we were integrating to.

The 6100 had some quirks, the 8100's were much better.

MS Office in particular sucked due to the way they applications were built.
(look up p-code someday).

>About two years later, we started using the DEC PC's with Alpha 233
>cards in them and they smoked the crap out of all sorts of things...

Yup, we had a couple of them at one job. That NT re-compiler thing was pretty
weird.


--
Dr. Nuketopia
Sorry, no e-Mail.
Spam forgeries have resulted in thousands of faked bounces to my address.

[Scott Reams]

> SSE was a complete ****ing joke compared to the vector engine in the G4.
No
> kidding. It resoundingly smoked the intel family on best-case optimized
code
> that applied well to this kind of processing.

Interesting. Did this include SSE2?

How about AMD CPUs?

-S

[Brian Tankersley]

Yeah, that's right. When an Altivec app can pretty much own the whole
machine, it is very much superior technology to SSE2 and 3DNow! The
original SSE was more marketing than legitimate go-juice.

If you take a look at the non-Altivec version vs the Altivec version of
the Distributed.net RC5 client, it's astounding. Altivec improves
performance by about 250%. Nowhere, on no app, does SSE2 come close to
that boost, AFAIK.

But it does seem to me that Altivec does not play nice at all on the
current Macs in multitasking scenarios. Seems like the restricted FSB
bandwidth and memory speeds, plus the way the G4 registers are designed
creates pretty horrific inefficiencies in many cases. Thus, relatively
minor improvement was realized on DAWs and plugins, where the scenario
is inherently multitasking in a big way.

If the G5 can overcome those issues, Altivec could finally have a big
impact of DAWs. Without improved Altivec when multitasking, the G5 will
still be a big boost for the Mac and bring + / - parity with Wintel
world. With Altivec running like it should, G5 could actually prove to
be a worldbeater. Unfortunately, I'm not too optomistic that
IBM/Apple/OSX/compilers/developers will all line up to make it so.
Brilliant technology, with mediocre realworld success to date for the
most part, certainly for DAWs.

Regards,
Brian T


nuke wrote:

>>How did it compare when the scales were evened out and the code also
>>supported the SSE and SSE2 SIMD sets?
>>
>>
>
>SSE was a complete ****ing joke compared to the vector engine in the G4. No
>kidding. It resoundingly smoked the intel family on best-case optimized code
>that applied well to this kind of processing.
>
>Like BLAST and the other protein folding number cruncher applications out
>there, they run killer on alti-vec. The only challenge is feeding them with
>data.
>
>
>--
>Dr. Nuketopia
>Sorry, no e-Mail.
>Spam forgeries have resulted in thousands of faked bounces to my address.
>
>

[Scott Reams]

> Yeah, that's right. When an Altivec app can pretty much own the whole
> machine, it is very much superior technology to SSE2 and 3DNow! The
> original SSE was more marketing than legitimate go-juice.

Interesting, then, that Waves was able to get far, far more out of SSE than
out of Altivec in their optimizations.

> If you take a look at the non-Altivec version vs the Altivec version of
> the Distributed.net RC5 client, it's astounding. Altivec improves
> performance by about 250%. Nowhere, on no app, does SSE2 come close to
> that boost, AFAIK.

It does seem, however, that this is a one-of-a-kind example. I haven't seen
anything besides this one thing show such a disparity.

> But it does seem to me that Altivec does not play nice at all on the
> current Macs in multitasking scenarios. Seems like the restricted FSB
> bandwidth and memory speeds, plus the way the G4 registers are designed
> creates pretty horrific inefficiencies in many cases. Thus, relatively
> minor improvement was realized on DAWs and plugins, where the scenario
> is inherently multitasking in a big way.
>
> If the G5 can overcome those issues, Altivec could finally have a big
> impact of DAWs.

Perhaps... but I don't think the Distributed.net results can be used as
evidence of that. If there was more evidence to be seen, I might believe it.

> Without improved Altivec when multitasking, the G5 will
> still be a big boost for the Mac and bring + / - parity with Wintel
> world. With Altivec running like it should, G5 could actually prove to
> be a worldbeater.

Hmmm... running like it should? What evidence do we have to determine how it
should run?

-S

[Scott Reams]

I just did a quick search through the distributed.net FAQ.

They mention that the fact that PowerPC and some Intel CPUs score well is
because they impliment 32-bit rotate functions in hardware. (who knows how
much, if at all, this particular thing would benefit an audio plugin).
Interestingly... the P4 dropped this capability... and so all of the
"modern" Intel CPUs fell way behind at that point.

I think we have a freak case here that relies very heavily on a very
specific set of circumstances.

-S

"Brian Tankersley" > wrote in message
...
> Yeah, that's right. When an Altivec app can pretty much own the whole
> machine, it is very much superior technology to SSE2 and 3DNow! The
> original SSE was more marketing than legitimate go-juice.
>
> If you take a look at the non-Altivec version vs the Altivec version of
> the Distributed.net RC5 client, it's astounding. Altivec improves
> performance by about 250%. Nowhere, on no app, does SSE2 come close to
> that boost, AFAIK.
>
> But it does seem to me that Altivec does not play nice at all on the
> current Macs in multitasking scenarios. Seems like the restricted FSB
> bandwidth and memory speeds, plus the way the G4 registers are designed
> creates pretty horrific inefficiencies in many cases. Thus, relatively
> minor improvement was realized on DAWs and plugins, where the scenario
> is inherently multitasking in a big way.
>
> If the G5 can overcome those issues, Altivec could finally have a big
> impact of DAWs. Without improved Altivec when multitasking, the G5 will
> still be a big boost for the Mac and bring + / - parity with Wintel
> world. With Altivec running like it should, G5 could actually prove to
> be a worldbeater. Unfortunately, I'm not too optomistic that
> IBM/Apple/OSX/compilers/developers will all line up to make it so.
> Brilliant technology, with mediocre realworld success to date for the
> most part, certainly for DAWs.
>
> Regards,
> Brian T
>
>
> nuke wrote:
>
> >>How did it compare when the scales were evened out and the code also
> >>supported the SSE and SSE2 SIMD sets?
> >>
> >>
> >
> >SSE was a complete ****ing joke compared to the vector engine in the G4.
No
> >kidding. It resoundingly smoked the intel family on best-case optimized
code
> >that applied well to this kind of processing.
> >
> >Like BLAST and the other protein folding number cruncher applications out
> >there, they run killer on alti-vec. The only challenge is feeding them
with
> >data.
> >
> >
> >--
> >Dr. Nuketopia
> >Sorry, no e-Mail.
> >Spam forgeries have resulted in thousands of faked bounces to my address.
> >
> >
>

[Musikboy]

In article >, Scott
Reams > wrote:

> > Yeah, that's right. When an Altivec app can pretty much own the whole
> > machine, it is very much superior technology to SSE2 and 3DNow! The
> > original SSE was more marketing than legitimate go-juice.
>
> Interesting, then, that Waves was able to get far, far more out of SSE than
> out of Altivec in their optimizations.
Because according to scott reams nothing that says the G4's were better
could possibly be true.
> > If you take a look at the non-Altivec version vs the Altivec version of
> > the Distributed.net RC5 client, it's astounding. Altivec improves
> > performance by about 250%. Nowhere, on no app, does SSE2 come close to
> > that boost, AFAIK.
>
> It does seem, however, that this is a one-of-a-kind example. I haven't seen
> anything besides this one thing show such a disparity.
Because according to scott reams nothing that says the G4's were better
could possibly be true.
> > But it does seem to me that Altivec does not play nice at all on the
> > current Macs in multitasking scenarios. Seems like the restricted FSB
> > bandwidth and memory speeds, plus the way the G4 registers are designed
> > creates pretty horrific inefficiencies in many cases. Thus, relatively
> > minor improvement was realized on DAWs and plugins, where the scenario
> > is inherently multitasking in a big way.
> >
> > If the G5 can overcome those issues, Altivec could finally have a big
> > impact of DAWs.
>
> Perhaps... but I don't think the Distributed.net results can be used as
> evidence of that. If there was more evidence to be seen, I might believe it.
Because according to scott reams nothing that says the G5's were better
could possibly be true.
> > Without improved Altivec when multitasking, the G5 will
> > still be a big boost for the Mac and bring + / - parity with Wintel
> > world. With Altivec running like it should, G5 could actually prove to
> > be a worldbeater.
>
> Hmmm... running like it should? What evidence do we have to determine how it
> should run?
>
> -S
Because according to scott reams nothing that says the G5's were better
could possibly be true.

you're a hell of an open minded guy there scott

[Musikboy]

In article >, Scott
Reams > wrote:

> I just did a quick search through the distributed.net FAQ.
>
> They mention that the fact that PowerPC and some Intel CPUs score well is
> because they impliment 32-bit rotate functions in hardware. (who knows how
> much, if at all, this particular thing would benefit an audio plugin).
> Interestingly... the P4 dropped this capability... and so all of the
> "modern" Intel CPUs fell way behind at that point.
>
> I think we have a freak case here that relies very heavily on a very
> specific set of circumstances.
>
> -S
Because according to scott reams if anything apple scores better ever
its a freak case. because scott is so open minded.
> "Brian Tankersley" > wrote in message
> ...
> > Yeah, that's right. When an Altivec app can pretty much own the whole
> > machine, it is very much superior technology to SSE2 and 3DNow! The
> > original SSE was more marketing than legitimate go-juice.
> >
> > If you take a look at the non-Altivec version vs the Altivec version of
> > the Distributed.net RC5 client, it's astounding. Altivec improves
> > performance by about 250%. Nowhere, on no app, does SSE2 come close to
> > that boost, AFAIK.
> >
> > But it does seem to me that Altivec does not play nice at all on the
> > current Macs in multitasking scenarios. Seems like the restricted FSB
> > bandwidth and memory speeds, plus the way the G4 registers are designed
> > creates pretty horrific inefficiencies in many cases. Thus, relatively
> > minor improvement was realized on DAWs and plugins, where the scenario
> > is inherently multitasking in a big way.
> >
> > If the G5 can overcome those issues, Altivec could finally have a big
> > impact of DAWs. Without improved Altivec when multitasking, the G5 will
> > still be a big boost for the Mac and bring + / - parity with Wintel
> > world. With Altivec running like it should, G5 could actually prove to
> > be a worldbeater. Unfortunately, I'm not too optomistic that
> > IBM/Apple/OSX/compilers/developers will all line up to make it so.
> > Brilliant technology, with mediocre realworld success to date for the
> > most part, certainly for DAWs.
> >
> > Regards,
> > Brian T
> >
> >
> > nuke wrote:
> >
> > >>How did it compare when the scales were evened out and the code also
> > >>supported the SSE and SSE2 SIMD sets?
> > >>
> > >>
> > >
> > >SSE was a complete ****ing joke compared to the vector engine in the G4.
> No
> > >kidding. It resoundingly smoked the intel family on best-case optimized
> code
> > >that applied well to this kind of processing.
> > >
> > >Like BLAST and the other protein folding number cruncher applications out
> > >there, they run killer on alti-vec. The only challenge is feeding them
> with
> > >data.
> > >
> > >
> > >--
> > >Dr. Nuketopia
> > >Sorry, no e-Mail.
> > >Spam forgeries have resulted in thousands of faked bounces to my address.
> > >
> > >
> >
>
>

[Scott Reams]

> > It does seem, however, that this is a one-of-a-kind example. I haven't
seen
> > anything besides this one thing show such a disparity.
> Because according to scott reams nothing that says the G4's were better
> could possibly be true.

It's true. The fact that it is the only example is what brings the question.
If you have other examples, please share them.


> > Perhaps... but I don't think the Distributed.net results can be used as
> > evidence of that. If there was more evidence to be seen, I might believe
it.
> Because according to scott reams nothing that says the G5's were better
> could possibly be true.

Nothing says either way yet. The systems aren't available. My point was that
I don't think Altivec will save the day from what I've seen. The G5 itself
could save the day, however.

> > Hmmm... running like it should? What evidence do we have to determine
how it
> > should run?
>
> Because according to scott reams nothing that says the G5's were better
> could possibly be true.

Because, unlike yourself, I need more than one solitary piece of evidence to
draw a conclusion. It doesn't matter of it's a G5, a P5, or a BMW M5.
Also... unlike yourself, I don't believe anything any manufacturer claims
about an unreleased product.

> you're a hell of an open minded guy there scott

Sure am. You might try it one day.

:)

-S

[Scott Reams]

> > I just did a quick search through the distributed.net FAQ.
> >
> > They mention that the fact that PowerPC and some Intel CPUs score well
is
> > because they impliment 32-bit rotate functions in hardware. (who knows
how
> > much, if at all, this particular thing would benefit an audio plugin).
> > Interestingly... the P4 dropped this capability... and so all of the
> > "modern" Intel CPUs fell way behind at that point.
> >
> > I think we have a freak case here that relies very heavily on a very
> > specific set of circumstances.

> Because according to scott reams if anything apple scores better ever
> its a freak case. because scott is so open minded.

Because... unlike yourself... one solitary piece of evidence -is- a freak
case until there is at least one more piece of evidence to confirm it as
meaningful. You might try being more thorough when trying to understand
performance... and not lean on -any- singular piece of evidence to draw
conclusions from.

You'll get there some day. I believe in you, MusikGuitarboy.

:)

-S

[david]

In article >, Brian Tankersley
> wrote:

> Unfortunately, I'm not too optomistic that
> IBM/Apple/OSX/compilers/developers will all line up to make it so.
> Brilliant technology, with mediocre realworld success to date for the
> most part, certainly for DAWs.



Mediocre realworld success for DAW's? Huh??





David Correia
Celebration Sound
Warren, Rhode Island


www.CelebrationSound.com

[Brian Tankersley]

Oh screw it, dude. You are so full of crap I just cannot deal with it
any more. It seems to me you just posted a huge, complex, self-indulgent
equivelent of "nanee-nanee-boo-boo". Why, oh why, do I do this to
myself? I do not have time to deal with this pointlessness. I already
vowed to never check the Sonar forum again. Here I am, sucked into the
insanity yet again here on RAP.

Next....over.....done. No kidding, never again will I subject myself to
the aggravation of interaction with you. At this point, I don't even
care who's right. In fact, you can be right. Yes, you are completely
right and know pretty much everything there is to know. OK?

Rock on, dude, and enjoy your life greatly.

Regards,
Brian T

Scott Reams wrote:

>>We've been over this before and I just don't have the energy to do it
>>all again. But OTOH, the inconsistency in your assessment begs for
>>
>>
>comment.
>
>
>>Does a Waves plugin ever get to "own" the whole machine? Read my post
>>again about Altivec and multitasking.
>>
>>
>
>The test results I'm referring to regarding Waves plugins involved testing
>one plugin at a time and measuring CPU usage. There is no multitasking going
>on in the benchmark. The plugin "owns" the machine in these tests.
>
>
>
>>I pointed out that Altivec has
>>seen marginal results on DAWs for that reason. OTOH, Altivec yeilds very
>>good results on Altiverb (notice the name) which just happens to prefer
>>to "own" a whole machine, with many Mac users basically dedicating a
>>machine to it, pretty much stand alone.
>>
>>
>
>How can we come to any conclusions with a plugin that is a) not available
>for any platform other than Mac, and b) not available in a non-Altivec
>optimized version. There is no baseline to compare to... and no way to
>decide what Altivec's impact is.
>
>
>
>>And I reach my conclusions based upon a number of sources. Some hard
>>facts, some totally subjective personal impressions built up over time,
>>and all points in between. I've seen Photoshop filters,
>>
>>
>
>Be specific... and point out what leads you to the conclusion that Altivec
>was meaningfully involved in the result.
>
>
>
>>the RC5 client,
>>Logic,
>>
>>
>
>Specifically?
>
>You said yourself that I back up what I say with numbers when I can. All I'm
>asking is the same of you.
>
>
>
>>a handful of audio plugins and a few other apps in the
>>before/after Altivec cases.
>>
>>
>
>Specifically?
>
>
>
>>Frankly Scott, you continue the habit of
>>giving much greater credence to your own presumptions than those of
>>others, which is only human nature I suppose.
>>
>>
>
>I present specifics when I can... and use those specifics to form opinions.
>I would happily invite any specifics you can provide that might help shape
>my opinion. You know that's how my mind works. If you want to convince me of
>something... show me. Your mentions of Logic and Photoshop are a bit
>nebulous.
>
>
>
>>Why do you presume that it is SSE/SSE2 or Altivec alone that are wholly
>>or primarily responsible for the improvement in Waves code that was
>>ported from TDM/Moto 56K origins?
>>
>>
>
>I don't. I just remember what I was told by the Waves staff regarding their
>take on Altivec and what it was doing for them.
>
>I'll also reiterate... these plugins were benchmarked one at a time... no
>multitasking. Pure CPU usage per-plugin. The rift between the performance of
>the Altivec-enabled Waves plugins and the SSE/SSE2/3dNow! enabled plugins
>was gargantuan, and still is. The Waves plugs on the Mac side had -no-
>Altivec optimizations before 3.5... and hardly gained when optimizations
>were added. You'd think, from your own statements, that Altivec should have
>saved the day... unless of course Waves' programmers are incompetent. :)
>
>
>
>>A major piece of this whole thread was the lame compilers Apple chose
>>for the P4. It's been beaten to death here. The vast difference in the
>>disparate P4 Spec scores between Apple and everybody else was the
>>compilers, and that's not just about SSE2, my man.
>>
>>
>
>Of course not. I'm not discussing that at this point.
>
>
>
>>What if Waves, being
>>new to releasing x86 based plugins at rev 1.0 once upon a time, just
>>picked a crappy compiler, did a poor job of porting, etc, etc, and a big
>>part of the improvement was simply cleaning up the code and using a
>>newer/better compiler? What if hitting the SSE2 Enable switch in the
>>compiler was good for about 30-40%? Could be. Can you prove otherwise?
>>Do you think the Waves PR Dept was going to say, "Hey, the original
>>Native port kinda sucked, plus we used a lame compiler", even if they
>>really did?
>>
>>
>
>My point, again... pre-3.5 Waves plugins on Mac took no advantage of
>Altivec. 3.5 and beyond does take advantage, and Waves had 1.5 years to
>figure it out. Waves 3.5 plugins are hardly an improvement on Apple systems
>over previous versions. Do you think this is because Waves didn't understand
>Altivec? Or could it be that this is the most one can expect from Altivec
>when optimizing audio plugins? There must be -some- explanation Waves
>couldn't get much more out of the Apple systems. Is, perhaps, RC5 the -only-
>benchmark in existence where the G4 blows Intel and AMD away? Show me
>otherwise. Show me it isn't a fluke. I'm open to that.
>
>
>
>>So you appear to have cranked some circular logic into your assessment
>>methodologies. Altivec *alone* (the only change in the RC5 client),
>>yielded about 250%. But you say that's likely a "one-of-a-kind"
>>scenario. Why you come to that conclusion, I don't know. But fine. Can
>>you give us chapter and verse details on other cases where SSE or SSE2
>>*alone* has yielded the same >200% that you quote in the article? You
>>mention evidence. Cool. Bring it.
>>
>>
>
>Can you give a single specific example besides RC5 of a G4 blowing away a
>modern PC... regardless of how much impact Altivec had? If Altivec can
>provide a 250% improvement to something besides RC5, where is the example?
>Where is there a single cross-platform audio plugin running more efficiently
>on G4 than P4/Athlon to support your theory? -Somebody- must have figured
>out how to get the magic out of Altivec in the audio world by now if it is
>there to be had. Who has?
>
>
>
>>Demonstrate with hard facts and figures that your own ">200%
>>improvement" quote on the Waves website is due, as you have said, to
>>SIMD instructions being employed
>>
>>
>
>I never claimed that improvement was due to SIMD. My point is that if Waves
>has optimized as best they can using SSE/SSE2/3dNow!/Altivec... along with
>whatever else... why aren't the G4s performing far better than the Intel/AMD
>systems as they do in the RC5 benchark? Could it be that the RC5 results are
>one of a kind? All I want to see is one other example... hopefully one that
>relates to audio. One cross-platform plugin. That's all.
>
>
>
>>AND that similar improvements can be
>>found in enough other specific, well documented cases to assure that
>>yours is a reasonable assumption and cannot be a "one-of-a-kind" case.
>>Just to be clear, your quote is: " Interesting, then, that Waves was
>>able to get far, far more out of SSE than out of Altivec in their
>>optimizations." Pure presumption on your part, by your own standards. So
>>I suggest you post according to the standards you place on others.
>>
>>We await your facts and figures.
>>
>>
>
>I await yours. I've seen RC5... and I've seen some casual mention of
>Photoshop filters and Logic Performance. I think I've delivered a bit more
>than that. Show me something else. I am honestly interested.
>
>-S
>
>
>
>

[Brian Tankersley]

Altivec, not Macs. Read carefully what I said. Ask Logic users how much
difference Altivec made in the realworld on their DAW. Not a lot,
unfortunately.

Brian T

david wrote:

>In article >, Brian Tankersley
> wrote:
>
>
>
>>Unfortunately, I'm not too optomistic that
>>IBM/Apple/OSX/compilers/developers will all line up to make it so.
>>Brilliant technology, with mediocre realworld success to date for the
>>most part, certainly for DAWs.
>>
>>
>
>
>
>Mediocre realworld success for DAW's? Huh??
>
>
>
>
>
>David Correia
>Celebration Sound
>Warren, Rhode Island
>

>www.CelebrationSound.com
>
>

[Scott Reams]

Yawn

"Musikboy" > wrote in message
.. .
> In article >, Scott Reams
> > wrote:
>
> snip
> >
> > I await yours. I've seen RC5... and I've seen some casual mention of
> > Photoshop filters and Logic Performance. I think I've delivered a bit
more
> > than that. Show me something else. I am honestly interested.
> >
> > -S
> >
> >
> Listen scott, if albert einstein and carl sagan came back from the dead
> and told you that mac's were faster you would say the same thing
> because you are ultimately biased and want to sell you services amking
> and setting up inferior PC daws which rule the amatuer world btw (more
> digi 001's live in PC's than mac's) but just dont cut it in the real
> pro world.

[Scott Reams]

Brian,

It's unfortunate you see it that way.

You are pressing me to put up the numbers... which, as you know, is
something I've been doing for some time.

I am asking you to do the same. I know you are a smart person... and I know
you probably have good reason for coming to the conclusions you do. I just
want you to show me the specifics. nothing wrong with that.

Oh well.

-S

"Brian Tankersley" > wrote in message
...
> Oh screw it, dude. You are so full of crap I just cannot deal with it
> any more. It seems to me you just posted a huge, complex, self-indulgent
> equivelent of "nanee-nanee-boo-boo". Why, oh why, do I do this to
> myself? I do not have time to deal with this pointlessness. I already
> vowed to never check the Sonar forum again. Here I am, sucked into the
> insanity yet again here on RAP.
>
> Next....over.....done. No kidding, never again will I subject myself to
> the aggravation of interaction with you. At this point, I don't even
> care who's right. In fact, you can be right. Yes, you are completely
> right and know pretty much everything there is to know. OK?
>
> Rock on, dude, and enjoy your life greatly.
>
> Regards,
> Brian T
>
> Scott Reams wrote:
>
> >>We've been over this before and I just don't have the energy to do it
> >>all again. But OTOH, the inconsistency in your assessment begs for
> >>
> >>
> >comment.
> >
> >
> >>Does a Waves plugin ever get to "own" the whole machine? Read my post
> >>again about Altivec and multitasking.
> >>
> >>
> >
> >The test results I'm referring to regarding Waves plugins involved
testing
> >one plugin at a time and measuring CPU usage. There is no multitasking
going
> >on in the benchmark. The plugin "owns" the machine in these tests.
> >
> >
> >
> >>I pointed out that Altivec has
> >>seen marginal results on DAWs for that reason. OTOH, Altivec yeilds very
> >>good results on Altiverb (notice the name) which just happens to prefer
> >>to "own" a whole machine, with many Mac users basically dedicating a
> >>machine to it, pretty much stand alone.
> >>
> >>
> >
> >How can we come to any conclusions with a plugin that is a) not available
> >for any platform other than Mac, and b) not available in a non-Altivec
> >optimized version. There is no baseline to compare to... and no way to
> >decide what Altivec's impact is.
> >
> >
> >
> >>And I reach my conclusions based upon a number of sources. Some hard
> >>facts, some totally subjective personal impressions built up over time,
> >>and all points in between. I've seen Photoshop filters,
> >>
> >>
> >
> >Be specific... and point out what leads you to the conclusion that
Altivec
> >was meaningfully involved in the result.
> >
> >
> >
> >>the RC5 client,
> >>Logic,
> >>
> >>
> >
> >Specifically?
> >
> >You said yourself that I back up what I say with numbers when I can. All
I'm
> >asking is the same of you.
> >
> >
> >
> >>a handful of audio plugins and a few other apps in the
> >>before/after Altivec cases.
> >>
> >>
> >
> >Specifically?
> >
> >
> >
> >>Frankly Scott, you continue the habit of
> >>giving much greater credence to your own presumptions than those of
> >>others, which is only human nature I suppose.
> >>
> >>
> >
> >I present specifics when I can... and use those specifics to form
opinions.
> >I would happily invite any specifics you can provide that might help
shape
> >my opinion. You know that's how my mind works. If you want to convince me
of
> >something... show me. Your mentions of Logic and Photoshop are a bit
> >nebulous.
> >
> >
> >
> >>Why do you presume that it is SSE/SSE2 or Altivec alone that are wholly
> >>or primarily responsible for the improvement in Waves code that was
> >>ported from TDM/Moto 56K origins?
> >>
> >>
> >
> >I don't. I just remember what I was told by the Waves staff regarding
their
> >take on Altivec and what it was doing for them.
> >
> >I'll also reiterate... these plugins were benchmarked one at a time... no
> >multitasking. Pure CPU usage per-plugin. The rift between the performance
of
> >the Altivec-enabled Waves plugins and the SSE/SSE2/3dNow! enabled plugins
> >was gargantuan, and still is. The Waves plugs on the Mac side had -no-
> >Altivec optimizations before 3.5... and hardly gained when optimizations
> >were added. You'd think, from your own statements, that Altivec should
have
> >saved the day... unless of course Waves' programmers are incompetent. :)
> >
> >
> >
> >>A major piece of this whole thread was the lame compilers Apple chose
> >>for the P4. It's been beaten to death here. The vast difference in the
> >>disparate P4 Spec scores between Apple and everybody else was the
> >>compilers, and that's not just about SSE2, my man.
> >>
> >>
> >
> >Of course not. I'm not discussing that at this point.
> >
> >
> >
> >>What if Waves, being
> >>new to releasing x86 based plugins at rev 1.0 once upon a time, just
> >>picked a crappy compiler, did a poor job of porting, etc, etc, and a big
> >>part of the improvement was simply cleaning up the code and using a
> >>newer/better compiler? What if hitting the SSE2 Enable switch in the
> >>compiler was good for about 30-40%? Could be. Can you prove otherwise?
> >>Do you think the Waves PR Dept was going to say, "Hey, the original
> >>Native port kinda sucked, plus we used a lame compiler", even if they
> >>really did?
> >>
> >>
> >
> >My point, again... pre-3.5 Waves plugins on Mac took no advantage of
> >Altivec. 3.5 and beyond does take advantage, and Waves had 1.5 years to
> >figure it out. Waves 3.5 plugins are hardly an improvement on Apple
systems
> >over previous versions. Do you think this is because Waves didn't
understand
> >Altivec? Or could it be that this is the most one can expect from Altivec
> >when optimizing audio plugins? There must be -some- explanation Waves
> >couldn't get much more out of the Apple systems. Is, perhaps, RC5
the -only-
> >benchmark in existence where the G4 blows Intel and AMD away? Show me
> >otherwise. Show me it isn't a fluke. I'm open to that.
> >
> >
> >
> >>So you appear to have cranked some circular logic into your assessment
> >>methodologies. Altivec *alone* (the only change in the RC5 client),
> >>yielded about 250%. But you say that's likely a "one-of-a-kind"
> >>scenario. Why you come to that conclusion, I don't know. But fine. Can
> >>you give us chapter and verse details on other cases where SSE or SSE2
> >>*alone* has yielded the same >200% that you quote in the article? You
> >>mention evidence. Cool. Bring it.
> >>
> >>
> >
> >Can you give a single specific example besides RC5 of a G4 blowing away a
> >modern PC... regardless of how much impact Altivec had? If Altivec can
> >provide a 250% improvement to something besides RC5, where is the
example?
> >Where is there a single cross-platform audio plugin running more
efficiently
> >on G4 than P4/Athlon to support your theory? -Somebody- must have figured
> >out how to get the magic out of Altivec in the audio world by now if it
is
> >there to be had. Who has?
> >
> >
> >
> >>Demonstrate with hard facts and figures that your own ">200%
> >>improvement" quote on the Waves website is due, as you have said, to
> >>SIMD instructions being employed
> >>
> >>
> >
> >I never claimed that improvement was due to SIMD. My point is that if
Waves
> >has optimized as best they can using SSE/SSE2/3dNow!/Altivec... along
with
> >whatever else... why aren't the G4s performing far better than the
Intel/AMD
> >systems as they do in the RC5 benchark? Could it be that the RC5 results
are
> >one of a kind? All I want to see is one other example... hopefully one
that
> >relates to audio. One cross-platform plugin. That's all.
> >
> >
> >
> >>AND that similar improvements can be
> >>found in enough other specific, well documented cases to assure that
> >>yours is a reasonable assumption and cannot be a "one-of-a-kind" case.
> >>Just to be clear, your quote is: " Interesting, then, that Waves was
> >>able to get far, far more out of SSE than out of Altivec in their
> >>optimizations." Pure presumption on your part, by your own standards. So
> >>I suggest you post according to the standards you place on others.
> >>
> >>We await your facts and figures.
> >>
> >>
> >
> >I await yours. I've seen RC5... and I've seen some casual mention of
> >Photoshop filters and Logic Performance. I think I've delivered a bit
more
> >than that. Show me something else. I am honestly interested.
> >
> >-S
> >
> >
> >
> >
>

[Steve Carroll]

In article >,
"Scott Reams" > wrote:

> Brian,
>
> It's unfortunate you see it that way.
>
> You are pressing me to put up the numbers... which, as you know, is
> something I've been doing for some time.
>
> I am asking you to do the same. I know you are a smart person... and I know
> you probably have good reason for coming to the conclusions you do. I just
> want you to show me the specifics. nothing wrong with that.
>
> Oh well.
>
> -S

If you're really interested,(you have claimed you are) in such numbers,
it'll only take a few minutes on the web to come up with examples of
Altivec's abilities. Contrary to your claim, it's not a one time 'fluke'.

Steve

[Scott Reams]

> If you're really interested,(you have claimed you are) in such numbers,
> it'll only take a few minutes on the web to come up with examples of
> Altivec's abilities. Contrary to your claim, it's not a one time 'fluke'.

I have looked up quite a few examples... but have seen no other case where
Altivec provided a 250% improvement that catapulted G4 performance beyond
any other CPU. I am happy to be wrong about this... but I haven't seen an
example. Just people saying it isn't a fluke.

Assume moment that I simply am not able to find the examples you speak of...
and point them out. I am open to any information on this as long as it can
be found.

-S

[LeBaron & Alrich]

Scott Reams > wrote:

> Because... unlike yourself... one solitary piece of evidence -is- a freak
> case until there is at least one more piece of evidence to confirm it as
> meaningful.

I just posted a link to a NASA tst of the G5. I found it interesting,
though as usual, it may not mean squat to a DAW. I try to restrain
laminar airflow calcs in my music. <g> See "NASA Tests Apple G5" in this
forum. Or not. Whatever.

--
hank alrich * secret mountain
audio recording * music production * sound reinforcement
"If laughter is the best medicine let's take a double dose"

[LeBaron & Alrich]

david > wrote:

> In article >, Brian Tankersley
> > wrote:

> > Unfortunately, I'm not too optomistic that
> > IBM/Apple/OSX/compilers/developers will all line up to make it so.
> > Brilliant technology, with mediocre realworld success to date for the
> > most part, certainly for DAWs.

> Mediocre realworld success for DAW's? Huh??

On the one hand, PT on the Mac rules the market; on the other hand,
Brian's rig completely outstrips any known PT rig in terms of
simultaneous hardware I/O, number of tracks, plugin instantiation, etc.
It's that old "Well, he can't sing for **** but his face is everywhere"
versus "Man, how come nobody has ever heard of _this_ guy, who sings
loops barrel rolls around the rest of the pack??"

--
hank alrich * secret mountain
audio recording * music production * sound reinforcement
"If laughter is the best medicine let's take a double dose"

[Scott Reams]

Yeah... I read that one. Very interesting article.

I actually emailed Craig (the author) with some questions about his methods
and found a detailed reply this morning. Nice guy.

-S

"LeBaron & Alrich" > wrote in message
...
> Scott Reams > wrote:
>
> > Because... unlike yourself... one solitary piece of evidence -is- a
freak
> > case until there is at least one more piece of evidence to confirm it as
> > meaningful.
>
> I just posted a link to a NASA tst of the G5. I found it interesting,
> though as usual, it may not mean squat to a DAW. I try to restrain
> laminar airflow calcs in my music. <g> See "NASA Tests Apple G5" in this
> forum. Or not. Whatever.
>
> --
> hank alrich * secret mountain
> audio recording * music production * sound reinforcement
> "If laughter is the best medicine let's take a double dose"

[Scott Dorsey]

LeBaron & Alrich > wrote:
>Scott Reams > wrote:
>
>> Because... unlike yourself... one solitary piece of evidence -is- a freak
>> case until there is at least one more piece of evidence to confirm it as
>> meaningful.
>
>I just posted a link to a NASA tst of the G5. I found it interesting,
>though as usual, it may not mean squat to a DAW. I try to restrain
>laminar airflow calcs in my music. <g> See "NASA Tests Apple G5" in this
>forum. Or not. Whatever.

CFD jobs are funny, because they are basically the same calculations over
and over again. They parallelize really well, and they can really fill up
a vector pipe very efficiently. They also have a lot of integer stuff going
on, more so than an FFT for example. So it's a little different than most
audio jobs.

Most of the NASA CFD guys are going to large arrays of Linux machines, just
because the bang for the buck is so good and since the jobs parallelize
so well, they can take advantage of large arrays of cheap machines. This is
harder with audio jobs.

But the general discussions about floating point speed and vector pipe
performance are pretty relevant.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Jonas Eckerman]

> I have looked up quite a few examples... but have seen no other case
> where Altivec provided a 250% improvement that catapulted G4
> performance beyond any other CPU.

You might be interested in the following link, from another (new)
RAP thread:
http://members.cox.net/craig.hunter/g5/

While it is headlined as a benchmark of the G5, they do provide floating
point benchmarks for G4, G5 and P4 (with and without using AltiVec for G4
and G5).

Also note that they've only compiled and optimized the code for G4 and P4
as they don't, yet, have a Fortran compiler that compiles for G5.

Some numbers:

P4 2.66GHz Scalar: 255 MFLOPS, 0.096 MFLOPS/MHz
G4 1.25GHz Scalar: 129 MFLOPS, 0.103 MFLOPS/MHz
G5 2GHz, Scalar: 254 MFLOPS, 0.127 MFLOPS/MHz

G4 1.25GHz Vector: 1612 MFLOPS, 1.290 MFLOPS/MHz
G5 2GHz Vector: 2755 MFLOPS, 1.378 MFLOPS/MHz

To me it seems that AltiVec gave an *enormous* improvement in this
application (the jet noise prediction tool Jet3D).

I can't vouch for the validity or integrity of the test. I just thought it
fit well in this thread.

Regards
/Jonas

[Scott Reams]

Right.

I read that and found it interesting. Even had a conversation with the
author about his methods.

> To me it seems that AltiVec gave an *enormous* improvement in this
> application (the jet noise prediction tool Jet3D).

It is a bit tough to draw a conclusion here... as the "vector" version was
run on the Altivec machines only. The "scalar" version may not be directly
comparable because the code is so much different. I'm also curious as to
whether or not the "vector" version would run on an SSE/SSE2-enabled machine
if so coded. The author doesn't say. Time was only spent coding the vector
version for Altivec.

If Altivec-enabled CPUs are the only ones capable of running a vector
version under any circumstances, then the numbers are quite valid... but
does that translate to audio? It's an interesting question. I'd like to see
someone take advantage of it (this should be possible even on a G4) if this
is the case.

It is all interesting... but does raise questions.

-S


"Jonas Eckerman" > wrote in message
...
> > I have looked up quite a few examples... but have seen no other case
> > where Altivec provided a 250% improvement that catapulted G4
> > performance beyond any other CPU.
>
> You might be interested in the following link, from another (new)
> RAP thread:
> http://members.cox.net/craig.hunter/g5/
>
> While it is headlined as a benchmark of the G5, they do provide floating
> point benchmarks for G4, G5 and P4 (with and without using AltiVec for G4
> and G5).
>
> Also note that they've only compiled and optimized the code for G4 and P4
> as they don't, yet, have a Fortran compiler that compiles for G5.
>
> Some numbers:
>
> P4 2.66GHz Scalar: 255 MFLOPS, 0.096 MFLOPS/MHz
> G4 1.25GHz Scalar: 129 MFLOPS, 0.103 MFLOPS/MHz
> G5 2GHz, Scalar: 254 MFLOPS, 0.127 MFLOPS/MHz
>
> G4 1.25GHz Vector: 1612 MFLOPS, 1.290 MFLOPS/MHz
> G5 2GHz Vector: 2755 MFLOPS, 1.378 MFLOPS/MHz
>
> To me it seems that AltiVec gave an *enormous* improvement in this
> application (the jet noise prediction tool Jet3D).
>
> I can't vouch for the validity or integrity of the test. I just thought it
> fit well in this thread.
>
> Regards
> /Jonas
>

[Jonas Eckerman]

> I guess real world success isn't measured in number of installed
> systems in pro studios.

Are you saying that all those systems are coded for the AltiVec instruction
set?

/Jonas

[nuke]

>Interesting. Did this include SSE2?
>
>How about AMD CPUs?
>
>-S

Yes and yes.

Trashed them all, using best case, most optimized code on all platforms. The
G4 family vector engine is pretty darn good.

The only way to grind it any faster was to spend (a lot) more money on
bigger-iron hardware.


--
Dr. Nuketopia
Sorry, no e-Mail.
Spam forgeries have resulted in thousands of faked bounces to my address.

[Scott Reams]

> Trashed them all, using best case, most optimized code on all platforms.
The
> G4 family vector engine is pretty darn good.

What I'm seeing so far seems to support this...

The question is, can the vector engine be utilized in an audio
environment... and if so, why hasn't it been?

-S

[Musikboy]

In article >, Scott Reams
> wrote:

> > Trashed them all, using best case, most optimized code on all platforms.
> The
> > G4 family vector engine is pretty darn good.
>
> What I'm seeing so far seems to support this...
>
> The question is, can the vector engine be utilized in an audio
> environment... and if so, why hasn't it been?
>
> -S
>
>
Ummm hello it has been. logic uses it thats how you can get so many of
it's plugins going. i think DP uses it. I even think pro tools le uses
it. a lot of games have to have a G4 bcause of the altivec engine.

[Scott Reams]

BTW...

My point was this:

If the vector engine gives such huge gains in specific scenarios (RC5, the
NASA tests)... and if the same gains are possible in the audio world... any
Altivec-enabled CPU should be hands-down the highest performing out there in
this field.

-S

"Musikboy" > wrote in message
.. .
> In article >, Scott Reams
> > wrote:
>
> > > Trashed them all, using best case, most optimized code on all
platforms.
> > The
> > > G4 family vector engine is pretty darn good.
> >
> > What I'm seeing so far seems to support this...
> >
> > The question is, can the vector engine be utilized in an audio
> > environment... and if so, why hasn't it been?
> >
> > -S
> >
> >
> Ummm hello it has been. logic uses it thats how you can get so many of
> it's plugins going. i think DP uses it. I even think pro tools le uses
> it. a lot of games have to have a G4 bcause of the altivec engine.

[Neil Gould]

Hi,

"LeBaron & Alrich" > wrote:
>
> I just posted a link to a NASA tst of the G5. I found it interesting,
> though as usual, it may not mean squat to a DAW. I try to restrain
> laminar airflow calcs in my music. <g> See "NASA Tests Apple G5" in this
> forum. Or not. Whatever.
>
I did find certain aspects of the NASA test curious. For example, in
specifying the P4 systems, neither motherboard was identified, nor were
other systemic issues such as the chipset. It reflects the notion of those
that do such tests that P4s are "generic" and comparable, which is far
from the truth of the matter.

The conclusion that I drew from the tests is that NASA may be able to
justify replacing their G4s with G5s, but, they could more easily justify
dumping all of their Macs for 3.x GHz P4s, which are hardly exotic.
Curious that the author didn't arrive at the same conclusion.

Neil

[Scott Dorsey]

Scott Reams > wrote:
>
>If the vector engine gives such huge gains in specific scenarios (RC5, the
>NASA tests)... and if the same gains are possible in the audio world... any
>Altivec-enabled CPU should be hands-down the highest performing out there in
>this field.

It depends entirely on how well the vector pipe gets used.

At my undergrad school, they were using a Cyber 850 vector machine to run
big cobol jobs for administrative MIS work. Needless to say the performance
was not very good because it just wasn't designed for that.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Reams]

> The conclusion that I drew from the tests is that NASA may be able to
> justify replacing their G4s with G5s, but, they could more easily justify
> dumping all of their Macs for 3.x GHz P4s, which are hardly exotic.
> Curious that the author didn't arrive at the same conclusion.

I tend to agree in a broader sense... but if you take a good look at the
article, you'll see that the author is showing that this particular code,
when specifically coded for Altivec, runs far, far better on an
Altivec-enabled CPU than anything else (nearly 10x faster). If all the code
NASA ever ran was the same code they used in this test... and if no further
optimizations were available for non-Altivec systems... then the obvious
choice would be to use an Apple system.

That said... I think the truth has a wider scope... and that if you factor
in everything NASA does with these systems, the gap probably disappears.

-S

[Jay - atldigi]

In article >, "Scott
Reams" > wrote:


> when specifically coded for Altivec, runs far, far better on an
> Altivec-enabled CPU than anything else (nearly 10x faster). If all the
> code
> NASA ever ran was the same code they used in this test... and if no
> further
> optimizations were available for non-Altivec systems... then the obvious
> choice would be to use an Apple system.
>
> That said... I think the truth has a wider scope... and that if you
> factor
> in everything NASA does with these systems, the gap probably disappears.


I expect NASA would have different machines for different tasks, so they
could happily get the G5s for this task and other departments could get
whatever works best for them. In the past it was sometimes said that
it's tough to have both PCs and Macs in one place, but that's long
outdated. It's not difficult to support both and network all the
machines if you want to (Nasa may have reason to keep some machines off
the network). I've seen it done many times without problems - except for
careless users that create problems no matter what machine you give them.

--
Jay Frigoletto
Mastersuite
Los Angeles
www.promastering.com