From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
Subject: Re: 100 Mips Intel NeXT.
Reply-To: vhs@rhein-main.de
Date: Fri, 11 Dec 92 17:40:53 GMT

In article <1992Dec10.090411.12142@ichips.intel.com> lschultz@pdx255 (Leonard Schultz)  
writes:
> 
> In article <1992Dec8.205422.746@qb.rhein-main.de> vhs@rhein-main.de writes:
> 
> >The 80x86 line is forever chained to an instruction set that blocks
> >most possibilities to make use of modern technologies other than
> >manufacturing processes. Going superscalar is a pain with CISCs, the
> >same holds for superpipelined. Modern compilers work best with a lot of
> >general purpose registers - the 80x86es have three or so, the rest has
> >special functions.
> 
> Why is it a pain to go superscalar or superpipelined with CISCs, and
> why is it easier with RISCs? 

The decoding takes too long with CISCs. This leads to late recognition of
interdependencies between instructions in the pipeline. In order to
prevent resulting trouble, you must either put much more silicon into the
pipeline (a pain) or accept a general pipeline slowdown (also a pain).
Also, especially with 80x86 code you have a whole bunch of self-modifying
code running around mugging instructions that may already be in the
pipeline. Therefore, additional silicon is needed again to make sure the
code runs as expected (another pain).

> And what modern technologies are x86
> machines barred from using?  I can't think of any.  From the diagram
> in EE Times, the Pentium(tm) Processor looks superscalar to me.

Reasonable register allocation technologies used in compilers, for instance.
The Pentium is almost superscalar, since it does have separate instruction
pipelines, but unlike superscalar processors it does not have separate ALUs.
That means at one point in the execution each instruction uses the same
piece of hardware, while in other SS processors the instruction streams run
fully in parallel. And I bet going superscalar *was* a pain.

> >If you compare benchmarks using the same compiler (gcc) on e.g. a
> >SPARC and an 80x86 you'll see that the SPARC code gets about twice
> >as fast when you turn optimization on, while the 80x86 only gets a ~5%
> >performance fart (Tested on Dhrystone 2.1).
> 
> What the bleep does this prove?  That unoptimized x86 compilers are
> more efficient than unoptimized sparc compilers?  Who cares?  Compare
> SPECmarks on optimized code if you want to make a comparison for gcc.

It the bleep proves that it's damn hard to optimize 80x86 code. You
won't get much of a performance gain. As I said we used identical
compilers on both machines. Thus the unoptimized outputs stem from
identical parse trees.
If you compare based on standard benchmarks, don't compare even
SPECmarks. At least let the manufacturer hand you SPECint92 and
SPECf92p values separately (SPECmarks was 1989) and compare each
single benchmark out of the complete suite to find out where the
system performs well.

> >Intel has always been lagging around a year behind its competitors
> >in performance. However, they have learned to announce very early
> >and deliver bad versions of the chips early so they sometimes appear
> >up-to-date. But if you compare the real-world availability dates of
> >intel 80x86 chips with their RISC competitors, they're almost always
> >a generation behind.
> >
> 
> What product was announced early, in your opinion?

386, each stage of the 486 (25, 33, 50, 66) except SX, and
Pentium, and this is not only my opinion.
In addition the early 386s were buggy in 32-bit multiply
(M$ even rewrote their C library to enable it to be used
on these faulty processors).
The early 486s were buggy in the FP unit and somewhere else I don't
remember. The 486/50 took an additional 6 months after they were
finally delivered to get rid of a heat problem.

> >I would prefer NeXT to go with PA-RISC or, better yet, alpha (expensive
> >though). Best compromise might be SPARC: High availability, multiple
> >vendors, low price (much lower than 80x86es!) higher performance,
> >pretty much iron out there alread, with much more to come.
> 
> Ah, from a sexy/horsepower point of view, we would all like to see this.
> Wouldn't we?  But let's look at the realities of this, which NeXT must
> face.  PA-RISC is a proprietary processor.  So if NeXT designs a system,
> where are they going to buy the chips from?

Where is NeXT going to buy the Pentium if they design a Pentium-based one?

> And what about Alpha?
> Unproven, expensive, not a mass-production levels, DEC unproven as a
> CPU supplier.

They have been delivering 21064s (alphas) for months. At 150 MHz.
What are you afraid of DEC as a chip supplier (other than to cut into
intel's semi-monopoly).

> With all of NeXT's experiences with bad decisions (C-cube,
> DSP, optical), why would they bet the farm on another?

Whew! So you think the DSP was a bad decision? Maybe because it's from
Motorola? What's wrong with having a DSP?

> SPARC?  I guess it will have alot to do with what markets NeXT is
> aiming for, and how many different architectures they want to support.
> Remember, SPARC _systems_ are typically more expensive than x86 systems.

They are also a lot better equipped (i.e. the equivalent of a:
	- local bus 32-bit SCSI
	- local bus accelerated 32-bit graphics card
	- local bus 32-bit ethernet board
	- dual local bus 32-bit serial interfaces
	- local bus 32-bit disk controller, sound input and
most importantly, a
	- local bus 32-bit wide keyboard interface!!! ;-)
	- a decent boot prom that lets you fix hard disks etc. even
	  if you can't boot the O/S any more.

> And there are NO significant performace differences.

Whoooaaarr! That was a good one. Ever had a look at an SS-10? Or, even
better from price-performance, an LX? And those are original Sun
products, expect much lower prices from the clone makers soon.

> From NeXT's perspective, the best route for the near future is Intel.
> If TTM (Time To Market) is important to NeXT (and I'm sure most of you
> want your next NeXT workstation soon).

The Pentium is again delayed, this time until end 1993. Talk about time
to market

> They already have the OS
> running on x86 machines.  Why port to a different architecture even if
> significant performance gains are there?

Because of these performance gains (among a *lot* of other reasons).

> As for the long term, NeXT has NDAs with many vendors.  They will make

Thus endeth your posting...?

> -- 
> 
> Len Schultz, lschultz@ichips.intel.com
> Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
> Hillsboro, Oregon 97124-6497


	Volker

--
Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)

Looks good on the outside, but -
	intel inside
Newsgroups: comp.sys.next.misc