mjones@stdc01.UUCP (Michael Jones) (08/29/90)
I was browsing through a copy of "Unix World" last night while
my wife shopped for Greeting Cards. In the darkly-tinted "rumor
pages" section, I saw a bold caption (something like):
"IBM RS/6000 Floating-Point Performance Overstated"
My eyes focused on the paragraph below. My heart raced. Had IBM
lied about the RS/6000 FPU? Is the ATTACK OF THE KILLER MICROS
nothing more than an advertising campaign?
(pause here to develop the right level of excitement)
The story gave a brief overview of RS/6000 performance measured
by the Nelson benchmarks, including the following (paraphrased):
...Integer speed was comparable to the i468, but floating-
point performance was less than the 486. Neal Nelson said
that "the floating-point benchmark was performed using the
Awk language, and perhaps IBM has a slower Awk than ..."
Aha! Slower when running _Awk_ floating-point code! AAAAARRGGH!
Perhaps they have recoded LINPAK in Awk? How can they publish
this kind of thing? Even though there are different audiences,
nobody deserves to be told that the RS/6000 is slow at FP code
because Awk can't turn n-Mflops.
They went on to disclose that the full details of the complete
benchmark process will be published as a feature article in
next month's issue. Some rumor this turned out to be. It was
a teaser for next month's zero-content article.
--
-- Michael T. Jones Email: ...!{uunet,mcnc}!rti!stdc01!mjones --
-- The wise man will pursue Paper: 3101-H Aileen Drive, Raleigh NC 27606 --
-- excellence in all things Voice: W:(919)361-3800 and H:(919)851-7979 --davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (08/30/90)
In article <631@stdc01.UUCP> mjones@stdc01.UUCP (Michael Jones) writes: [ Neal Norman said the 486 was faster than the RS6000 for fp in awk! ] | They went on to disclose that the full details of the complete | benchmark process will be published as a feature article in | next month's issue. Some rumor this turned out to be. It was | a teaser for next month's zero-content article. Don't you think it's important to have a global optimizing awk compiler? Do you realize how many sites run huge awk programs to do their finite element analysis, and how important a vectorizing awk is to them? Do you realize that I'm laughing so hard at the thought of people getting ready to followup to this that I'm dripping tears in my keyboard? Sorry, It's been a long day, I needed a laugh, and the thought of people bracing themselves to write scathing denunciations was too much to resist. I think you're over reacting to an incomplete data set about the test conditions, and I hope you didn't read the first sentence of my reply and take that too seriously, also. Seriously: I have talked to Neal Norman, I have compared his results to mine for certain machines and seen similar things, and I've been developing my suite since 1970 (MULTICS vs GECOS (sic)). I don't think he's lost his mind, and I'm pretty sure there's a good reason for doing it that way. I haven't looked up the article you mention, but we had a good talk about selection of benchmarks to prevent vectorization *for testing scalar performance* some years ago at UNIforum, so I can believe that for testing some particular thing he may well have used awk. I doubt that he was looking for max fp performance on that test, though. Let's wait for the whole story. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) VMS is a text-only adventure game. If you win you can use unix.
dhinds@portia.Stanford.EDU (David Hinds) (08/31/90)
In article <2475@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes: >In article <631@stdc01.UUCP> mjones@stdc01.UUCP (Michael Jones) writes: > >[ Neal Norman said the 486 was faster than the RS6000 for fp in awk! ] > > I haven't looked up the article you mention, but we had a good talk >about selection of benchmarks to prevent vectorization *for testing >scalar performance* some years ago at UNIforum, so I can believe that >for testing some particular thing he may well have used awk. I doubt >that he was looking for max fp performance on that test, though. Let's >wait for the whole story. > The mini-pre-review says that an HP Vectra 486 is 20% faster than an IBM RS6000-320 on integer and FP calculations. To explain the results, the article quotes the benchmarkers as saying that this could either mean IBM has a slow awk, or it has slow FP. This definitely implies that their ultimate measure of FP performance was awk. I tried running some tests on a 320 yesterday, to compare it with our SGI 4D/240 system. On some Fortran float-intensive code, the 320 was marginally faster than the 25 MHz R3000/3010 in single precision, and nuch (2X) faster in double precision. On some C mixed but mostly integer code, the R3000 came out a bit faster. This system still had old pre- release software, so the compilers may have improved. C seems like a tricky choice of language for FP comparison, given the differences in implementations as to promotion of single to double precision. K&R says that floats should be promoted to double in all expressions, but ANSI says they don't have to. This makes a big difference on my SGI code, but I don't know what the IBM compiler was doing. -David Hinds dhinds@popserver.stanford.edu
colin@array.UUCP (Colin Plumb) (08/31/90)
There was a discussion of the Neal Nelson benchamrks here a few months back, and I recall the consensus was that they're a bunch of grade-school programming and generally pretty useless. I'll go by SPECmarks. Any tricks that will get "artificially" high performance on them will probably give the same results on my code. There are other things than uniprocessing speed worth measuring, but few of them are characterised well enough to be comparable across sites. -- -Colin