#micron p60
18 messages in this thread
James,
ALR was charging $400 for the 386sx module and something kile $2K for
the 486 module. Yes, the 486 upgrade was a joke. You did not
anything near real 486 class integer performance with it (more like a
cached 386DX/25), though the floating point performance was not bad
compared to real 486DX/25's. The 386sx module was not such a bad deal
at the time. You got performance near the bottom of the 386sx pack
with it. The worst "feature" of that machine was the 5MB motherboard
memory limit. Any additional memory had to go on an 8MHz ISA card.
I think the P24T will surprise a lot of people when and if anybody
ever benchmarks the thing. A machine so equipped will run at full
Pentium speed as long as it is hitting the internal cache(s?). I
also think the P24T will get floating point performance close to that
of a real Pentium. Even the ALR Powerflex 486 upgrade gave near
normal 486DX performance on floating point. Floating point
performance and memory bandwidth are usually fairly independent.
The main reason I am skeptical about the Alpha et al is that the
differentials in performance between these RISC chips and the Pentium
are not that great. The fellow was saying his Alpha was 2.4-3.5
times faster than his 486DX2/66 on heavily floating point stuff.
Since the Pentium is easily twice as fast as the 486 on fp, that
means his alpha is only 1.2-1.8 times faster than the Pentium. If
you can get two pentiums for the price of one Alpha, and rendering is
your prime concern, then why not get the two Pentiums? If one
computer goes down, you still hav another. And what about the 90 MHz
Pentium that is due out any month now?
I guess the DEC is a premium enough machine to justify the price
diffential. But if I were buying a Pentium now, I'd keep upgradable
CPU modules low on the list of value added features.
Bailey
Who says that the Alpha is 2.4-3.5 times faster than a 486DX2/66? If this is
true I will change my name to Groucha Marx.
Seriously guys, I honestly think that this chat is getting kind of subjective.
After all, anyone have actually seen an Alpha box running? What is the source
of all this "informal" tests?
I feel like you are building a "air castle" on this one.
Ana:
>> If this is true I will change my name to Groucha Marx.
Great! Then we can let you in our group of the rest of the brothers! <g>
I will be a pleasure, Harpo! However, I think that, this time, I will continue
with my _original name_ 🙂
Margaret Dumont /krazy images
<G>
I wondered if anyone was going to pick up on that
one…..Uh….heh..heh….that just leaves the Good Looking One…Hmmmmmm….I
wooonnder who that could be? <BG>
Murph-O
Ana,
Jeff Bowermaster reported here that, when running raytracing benchmarks on code
he recompiled for Alpha on his 150MHz AXP, that it was running 2.4-3.5 times
faster than on his 486DX2/66.
I was going to try to keep my opinions to myself and not rag on Alpha (and RISC
processor's in general) too much. However, now that I've been challenged, I
must speak out<G>!
In the December issue of BYTE, they reviewed two Alpha machines from DEC, The
DEC 3000 Model 300, and the DECPC AXP 150. The model 300 is their low-end Unix
box (64bit external data path and 256K cache) and the DEPCPC AXP is (was?)
there high-end EISA NT file server box (128bit external data path and 512K
cache). Both use the 150MHz AXP chip. Here are the performance figures they
got for them, relative to an NEC 60MHz Pentium machine (index 1.0):
Test MODEL 300 DECPC AXP 150
Numeric Sort 0.82 1.28
String sort 1.59 2.45
Bitfield 2.12 2.5
Emulated floating point 0.99 1.17
Simple floating point 1.00 1.81
Trancendental
floating pont 1.57 1.16
As you can see, even on these low-level benchmarks, the Alpha machines are not
conistantly way-superior to Pentium, especially on floating point, which is
contrary to what most people think.
Also, in PC Mag, of April '93, there is a bar chart on page 138 comparing
various processor's SPECin92 and SPECfp92 marks.
Processor SPECint92 SPECfp92
486DX2/66 32 16
Pentium/66 65 57
Alpha/150 74 126
R4400/(75/150) 82 86
So, at least according to the SPECmarks, the Alpha and R4400 have no super huge
advantage. I think the fact that we are seeing only about a 2X improvement
running 3DS on Pentium instead of 486 indicates that 3DS is really less
floating point bound that everybody had thought (otherwise we would have seen a
3X type improvment). Therefore, since Pentium is closer to the Alpha chips on
integer performance, we will not see these huge increases in performance when
running even natively compiled 3DS on Alpha.
I once personally ran a POV-based benchmark on a 486DX2/66 and several
previous-generation RISC machines (R3000, SPARC2, and Intergraph C400) and the
DX2/66 was just barely beaten by the C400, tied the R3000, and clobbered the
SPARC2. All of these machines had SPECfp92 numbers about double that of the
486, but their integer performances were about the same or worse.
The RISC chips are really good at running benchmarks and code that has been
profiled to generate "hints" for the compiler. I remember when Digital Review
tested the Sparc10, and found the performance on SPECmarks only about 50% as
good as what Sun had claimed. They said they found out they had been using the
compiler "hints" for the wrong version of the compiler. The re-compiled the
with the correct "hints" and got the numbers Sun had claimed. The reported
this in a matter of course fashion, not at all indicating any bewilderment at
the lunacy of the situation!
How often do you have compiler hints for what you are doing in the real world?
These RISC chip designers are always talking about the optimizing the "average"
case. How often is anything that is really important "average"? While RISC
chips like the PPC do static branch prediction (e.g., that the backward branch
is always taken), the Pentium has a branch target cache (remembers which
branches were taken before and which were not). It is therefore able to profile
the code in real time, on the fly, in hardware while it is executing in it's
real-life environment!
Bailey
Thanks for this Valuable information Bailey.
Murph'
This is getting really wierd, if not ridiculous!
I mean we're arguing about a machine (AXP) that doesn't even have commercial
software of the type we need (3d animation) compiled for it, and extrapolating
judgments based on what some guy recompiled a raytracing routine for. What do
you know about his recompiling? I just can't feel right forming an objective
opinion based on one person's benchmark.
Also, I guess RISC processors aren't really that great, and SGI's really can't
render that much faster than 486's, and that SGI's don't really dominate the
high-end animation market because they really can't render faster and produce
more (I hate to say this on the 3DS forum, because 3DS is SUPER DOOPER, I love
it, and it does great things for me). As far as I (and many others, including
those who use 3DS and PC's AS WELL AS SGI's and Wavefront, SoftImage, whatever)
concerned, current crop RISC processors outperform 486's and Pentiums. If
you're going to take the Sparc2 or lame assed R3000 as an example, why don't
you compare them with a 386 or somehting? No animation firm in it's right mind
would use processors that outdated in a production environment!!!
Bailey, if you were faced with the hypothetical situtation of having an
excellent animation package ported to both the Pentium and the AXP (including
any speed processor they come up with, let's be fair, now), you mean to tell me
that for an AXP that costs perhaps $500 to $2000 more than a comparable pentium
you'd rather buy the pentium and have a slower machine?
I'd say double rendering speed is a huge major big deal on any platform, and I
would invest in the faster system if it was within my price range. I
personally couldn't give a sh*t about SpecFP and SpecINT and whatever numbers,
twice as fast is twice as fast!
Forgive me if I missed the thrust of your post, or took it the wrong way, but
RISC (SGI in particular) based animations system still off more than PC based
animation systems (computers and software), and it really irritates me when
people try and minimize or discount or claim this isn't so.
John Tissavary (La Luna cie)
John,
Comparing brand X rendering software running on an R4400 vs. brand Y running on
a Pentium is not a good way to compare the R4400 vs. the Pentium. Comparing
POV-Ray running on an AXP vs. POV-Ray running on a 486DX2/66 (the same source
code compiled for each machine) is a good way to compare the AXP vs. the
486DX2/66. POV is designed to be platform independent. There are happy POV
users on Mac, Amiga, Sun, PowerRISC, etc. The only way Jeff could have
possibly messed up the compilation is if he compiled it -O0 or something like
that, which I doubt he did. However, I doubt he bothered to run his test case
through the profiler then give the "hints" generated by the profiler to the
compiler so it could generate an executable optimized for running that
particular test case. This is what the RISC vendors do with Specmarks and other
industry standard benchmarks.
From his 2.4 to 3.5 times faster than the 486DX2/66 figures I interpolated that
the AXP is 1.3 to 1.4 times faster than Pentium by giving the Pentium a very
conservative 1.8-2.5 advantage over the 486.
Back when I ran my own POV benchark against Sparc2 and R3000, the R3000 was,
except for the then brand spanking new R4000 Crimson (at around $80-100K), all
that SGI had.
The reason the high end software runs on SGI is that SGI has delivered heavy
duty graphics platforms for years. You don't see SoftImage et al running on an
HP9000 do you? That's because the graphics people have been running/are
running/will be running SGI, not HP. It's not because the PA-RISC/99MHz
couldn't render faster than the R4400.
I'm not pooh-poohing SGI or any other high-end machine. You don't see anything
like the SGI memory bus or Extreme graphics for PCs. I'm just saying that if
rendering program Z runs N/M faster on machine X than on machine Y, then there
is a good chance that 3DS will probably render N/M faster on machine X than on
machine Y if it were compiled for machine X and machine Y.
Bailey
I see you point a little more clearly now, and will take Jeff's test into
serious consideration. I would still like to see some other comparisons. I
just find it hard to believe the 3DS renderer is less FPU intensive than people
bleieve, because I have heard from Gary, and others at Adesk that it is very
FPU intensive. Could it be that POV Ray is less FPU intensive (don't know,
just throwing that out…)?
cheers on the good point,
John Tissavary (La Luna cie)
John,
Re: how FP bound is 3D?
The only thing I can thing of is to look at the experiences people have had
with the Weitek Abacus and the Pentium.
The 486 verion of the Weitek Abacus (the 4167) was supposedly about
twice as fast as the 486DX's FPU for floating point, but, if I
remember correctly, using a 4167 with 3DSR2 gave about a 30%
improvement, according to the R2 manual, over a 486DX by itelf.
The Pentium/66 runs 486 targeted integer code about 1.8 times faster
than a 486DX2/66. It runs 486 targeted floating point stuff around 3
times as fast. People are seeing around a 2X improvement rendering
under R3 on Pentium/66 vs a 486DX2/66. Since 2 is closer to 1.8 than
it is to 3, my feeling is that, 3DS is more Integer bound than FP
bound on the Pentium.
I think what we are seeing is that somewhere between the 486 and the
Pentium, the floating point performance has improved to the point
where it is no longer the limiting factor.
I think the Cyrix M1 is supposedly better at integer than the Pentium,
but no better at floating point than a juiced-up 486. I think as
long as the FPU is good enough to reduce the FP bottleneck some, then
it's superior integer performance may give it an edge over the
Pentium when rendering, even if it's FP performance is not nearly as
good as Pentium. I'm really not sure though. I guess we'll find out
for sure some day.
Bailey
Interesting thoughts. I don't know enough about 3DS rendering engine or CPU's,
but you're right… we'll see!
cheers,
John Tissavary (La Luna cie)
POV isn't a "perfect" benchmark tools due to its "high portability" which can
only come in detriment of efficiency. While CPU's get faster and faster,
software engineering is getting slower and slower. It's like a bunch of fat
cats napping in a rat infested barn. Get rid of the mice and the cats will have
to run for the food again. We're getting to a point where CPU performance is
going from double each year to double each 3 to 4 years. This will get worse
before it gets better as the next break through is at least a decade away. We
will, hopefully, see better coding due to this fact. Coding, more than any
magic these CPU's can pool off is much more crucial in determining a better
system performance.
Another point to make is that when one talks about floating point intensive
applications, it's usually forgotten that a great deal of time is spent doing
house keeping work (moving, branching, calling, pushing, poping, etc). All this
goes on almost as much as real floating point calculation. Regardless how
efficient a CPU is when it comes to doing math, the code generated by compilers
waste a very long time with poor house keeping code. The only way to get around
this is to know profoundly how the system works and think ahead of the
compiler. I see less and less people able to do that. People leaving schools
today know all about object orientation, classing, subclassing, and all kinds
of the "hipe" of the day but have no clue what is under the hood.
You may drive your father's oldsmobile safely not knowing what's under the
hood, but you ought to know how that V12 Ferrari engine is doing at 12,000 rpm
if you want to take the most out of it (in fact, if you don't, you won't even
be able to move it).
Geee… 'nough lecturing… <g>
Did you read Hal Hardenburg's article on CPU and memory advances in a recent
issue of Dr Dobbs? He's always on target.
Yep. I read it and I loved it. This goes right along with my nick name (Grumpy
Old Man). <g>
Gus:
>> my nick name (Grumpy Old Man)
That's Grumpy Young Man, sonny! <g>
Gus,
I agree that POV isn't a perfect benchmarking tool. However, I think that
while 3DS's critical areas have probably been hand optimized for the 486, that
when it is ported to other CPUs there will probably be little or no hand
optimization. The likelihood of cpu specific hand optimization goes down with
each new cpu they support. I think this will be a trend in software. Before,
applications ran on just one platform, or maybe just PC and Mac. The critical
loops could be hand optimized for x86 or 68K. But now, they will be running on
PC, Mac, PPC, Alpha, MIPS, etc. and nobody will have time to optimize them.
Another reason they won't be hand optimized is that it is so difficult to write
optimized assembly for the new RISC chips. The old rules don't apply anymore,
and there are so many new rules with every new chip that only a compiler can
keep track of them.
The same sort of thing is even true of a 486. Just a few days ago, I found
out, to my horror, that, on a 486,
dec cx
jnz @@looptop
is almost twice as fast as
loop @@looptop
Yes, when I was in school three years ago, all they talked mostly hype. The one
thing you forgot to mention was "layers". In school they kept saying, "layers
are good." In industry, I've found that layers are bad because they make
things slow.
Bailey
Bailey,
>> The worst
"feature" of that machine was the 5MB motherboard memory limit <<
Actually you forgot that the memory between 640K and 1MB was also _NOT_
accessable!!! Small inconvience…..NOT!
>> the ALR Powerflex 486 upgrad <<
I seem to remembers something about this unit too…Hmmmm maybe the powerflex
also restricted upper memory access.
>> If you can get two pentiums for
the price of one Alpha, and rendering is your prime concern, then why not get
the two Pentiums? If one computer goes down, you still hav another. And what
about the 90 MHz Pentium that is due out any month now? <<
BINGO! That was my original problem with the "upgrade" "Deal"!
Money!……Why Waste it!….Film at 11!
>> But if I were buying a Pentium now, I'd keep upgradable CPU
modules low on the list of value added features. <<
I agree 100%
Murph'