Re: Part 1 of 3: Micro economics 101 (was: Code density ...)

"John Mashey" <old_systems_guy@xxxxxxxxx> writes:
>This thread is filled with *fantasies* about cheap/fast/timely VAXen,
>because the issue isn't (just) what's technically feasible, it's what
>you can do that's cost-competitive and time-to-market competitive.

Well, my impression was that you made a claim about technical
feasibility.

>Alternatively, if your volumes happen to be 5,000,000, you could spend
>$500M on development, and still only have an engineering cost/chip of
>$100.

But if you average revenue per chip is only $100, you are still in the
red.

>INTEL AND AMD CAN MAKE FAST X86S BECAUSE THEY HAVE VOLUME.
>
>Anne&Lynn Wheelers' post a while ago pointed at VAX unit volumes, which
>as of 1987 had MicroVAX II (a very successful product) having shipped
>65,000 units over 1985-1987.

8051s have volume in terms of pieces, too. However, what eventually
counts is total revenue. Some percentage of that can be spent on
development. A quick search gave the following numbers:

year revenue
AMD 1998 $2,542,141,000
DEC 1994 $13,500,000,000

Ok, both companies were not just in the CPU business, so they could
not spend all of their development money on CPU development, but if
the CPU was essential for DEC systems, I would expect DEC to be able
to spend at least as much money on CPU development as AMD.

Now AMD managed to finance the development of the K5, K6 (including
aquiring Nexgen), and K7.

One other thing worth noting is that in the last decade or so, once a
company has developed a good core, it can be used for a very long
time, with just shrinks and some (sometimes major) tweaking; examples
of this are the P6 core (released 1995) that is the basis of the
Pentium M, and the K7 core (1999?) that is the basis of the K8 core of
the Athlon 64 and Opteron. This may or may not reduce the development
costs per year.

>SEMICONDUCTOR COMPANIES, SYSTEMS COMPANIES, AND FABS

Similarly, fabs have to be financed from revenue. AMD could afford
fabs, so if having a fab was essential for DEC, then they should have
been able to afford one, too; they did afford one for a long time, but
eventually gave up on it; apparently other things were more essential.
But that was long after the VAX.

>In any case, there is a tradeoff between owning a fab ($$$) and getting
>higher clock rate, and not owning the fab, and being less able to tune
>designs.

How much does this affect the clock rate?

[DEC]
>However, in the 1980s, they never had more than about 100 VLSI CPU
>designers,

How does this compare to AMD?

>The problem that DEC faced was that their VAX cash cow was under
>attack, and they simply couldn't figure out how to keep the VAX
>competitive, first in the technical markets [versus PA RISC, SPARC, and
>MIPS], and then in commercial [PA RISC].

Maybe the VAX's problem was that it was in a market where binary
compatibility was not as important as for the 386 market.

>The ISA difference between VAX and Alpha was such that the NVAX team
>had to spend a lot more effort on micro-architecture, wheras the Alpha
>team could spend that effort on aggressive implementation, such that
>the MHz difference was something like 80-90MHz for NVAX/NVAX+, and up
>to 200Mhz for 21064. Around 1992, modulo maybe a year difference in
>software, that gave numbers like:
>
>SGI DEC DEC
>Crimson VAX7000/610 DEC7000/610
>MIPS VAX Alpha
>R4000 NVAX 21064
>1.3M 1.3M 1.68M # transistors
>184 mm^2 237 mm^2 234 mm^2 # size
>1.0 micron .75 micron .75 micron # process
>2-metal 3-metal 3-metal # metals
>1MB L2 4MB L2 4MB L2 # L2
>100Mhz 90MHz 182Mhz # clock rate
>
>61 34 95 # SPECint89
>78 58 244 # SPECfp89

Well, I would have liked to add a 486 column, but www.spec.org no
longer shows SPEC89 results, but apparently they were lower than
those of the NVAX.

Anyway, let's look at current CPUs and results:

CPU Power5 SPARC64 V Itanium 2 Athlon64-FX57 Pentium 4
System/Board [1] [2] [3] [4] [5]
clock (MHz) 1900 2160 1600 2800 3800
L2 cache 1920KB 4MB 256KB 1MB 2MB
L3 cache 36MB 9MB
cint2000base 1398 1456 1590 1745 1793
cint2000peak 1452 1594 1590 1929 1815
cfp2000base 2576 1808 2712 2086 1976
cfp2000peak 2702 2139 2712 2261 1984

[1] IBM eServer p5 570
[2] Fujitsu Primepower900
[3] HP Integrity rx4640-8
[4] ASUS A8N-SLI Deluxe
[5] Dell Precision Workstation 380

So while in 1992, the 386 implementations were not technically
competetive with the RISCs, nowadays they are (to be exact, the
Athlon64-FX57 results are in AMD64 mode; the other set of results for
that chip is better for SPECint, worse for SPECfp).

BTW, how much volume does Fujitsu have with their SPARC64 V machines?
How can they afford the development? And why does Sun not license
these CPUs? And how does Sun survive with CPUs that are technically
as competetive as the VAXen were in 1992? And if Sun can, why
couldn't DEC?

- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@xxxxxxxxxxxxxxxxxxxxxxxxxx Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
.

Relevant Pages

  • Re: VAX Spare Parts
    ... > Does anyone know what how many VAX sites are still out there? ... and some which speciallize in DEC CPU Upgrades... ... Digitask Consultants, Inc. - online store - USA ... Digital Surplus - Alphaserver CPU Upgrades - USA ...
    (comp.os.vms)
  • Re: Why was VAX abandonned ?
    ... >> As far as I know, DEC never rented VAX or Alpha that way. ... > can't charge by cpu runtime. ... This is due to the VMS ... They had been used to charging usage out to other ...
    (comp.os.vms)
  • Re: VAX - bringt das Verlagern der SWAP/PAGE Dateien Punkte?
    ... CPU-Zeit in Anspruch. ... Anwendungen zeigen z.B. eine hohe I/O-Last mit relativ wenig CPU. ... Ich habe auch schon mit einem einzelnen Prozess auf einer VAX die CPU zu 90% ... MONITOR/PROCESS zeigt ...
    (de.comp.os.vms)
  • Re: hpijs-ppds update appears stalled in "preparation"
    ... sitting there not using any cpu any longer. ... just kill it? ... can't afford to have my printing messed up. ...
    (Ubuntu)
  • Re: Could a PC do this?
    ... >>VAX would be far faster than a MicroVAX II. ... From the perspective of the CPU, if the emulation is correct, what's ... that allows it to be much faster than any silicon based VAX CPU ever ...
    (comp.os.vms)
Loading