home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / next / misc / 22941 < prev    next >
Encoding:
Text File  |  1992-12-11  |  6.8 KB  |  163 lines
  1. Newsgroups: comp.sys.next.misc
  2. Path: sparky!uunet!mcsun!Germany.EU.net!incom!orfeo!qb!vhs
  3. From: vhs@rhein-main.de (Volker Herminghaus-Shirai)
  4. Subject: Re: 100 Mips Intel NeXT.
  5. Message-ID: <1992Dec11.174053.943@qb.rhein-main.de>
  6. Sender: vhs@qb.rhein-main.de (Volker Herminghaus-Shirai)
  7. Reply-To: vhs@rhein-main.de
  8. References: <1992Dec10.090411.12142@ichips.intel.com>
  9. Date: Fri, 11 Dec 92 17:40:53 GMT
  10. Lines: 151
  11.  
  12. In article <1992Dec10.090411.12142@ichips.intel.com> lschultz@pdx255 (Leonard Schultz)  
  13. writes:
  14. > 
  15. > In article <1992Dec8.205422.746@qb.rhein-main.de> vhs@rhein-main.de writes:
  16. > 
  17. > >The 80x86 line is forever chained to an instruction set that blocks
  18. > >most possibilities to make use of modern technologies other than
  19. > >manufacturing processes. Going superscalar is a pain with CISCs, the
  20. > >same holds for superpipelined. Modern compilers work best with a lot of
  21. > >general purpose registers - the 80x86es have three or so, the rest has
  22. > >special functions.
  23. > 
  24. > Why is it a pain to go superscalar or superpipelined with CISCs, and
  25. > why is it easier with RISCs? 
  26.  
  27. The decoding takes too long with CISCs. This leads to late recognition of
  28. interdependencies between instructions in the pipeline. In order to
  29. prevent resulting trouble, you must either put much more silicon into the
  30. pipeline (a pain) or accept a general pipeline slowdown (also a pain).
  31. Also, especially with 80x86 code you have a whole bunch of self-modifying
  32. code running around mugging instructions that may already be in the
  33. pipeline. Therefore, additional silicon is needed again to make sure the
  34. code runs as expected (another pain).
  35.  
  36. > And what modern technologies are x86
  37. > machines barred from using?  I can't think of any.  From the diagram
  38. > in EE Times, the Pentium(tm) Processor looks superscalar to me.
  39.  
  40. Reasonable register allocation technologies used in compilers, for instance.
  41. The Pentium is almost superscalar, since it does have separate instruction
  42. pipelines, but unlike superscalar processors it does not have separate ALUs.
  43. That means at one point in the execution each instruction uses the same
  44. piece of hardware, while in other SS processors the instruction streams run
  45. fully in parallel. And I bet going superscalar *was* a pain.
  46.  
  47. > >If you compare benchmarks using the same compiler (gcc) on e.g. a
  48. > >SPARC and an 80x86 you'll see that the SPARC code gets about twice
  49. > >as fast when you turn optimization on, while the 80x86 only gets a ~5%
  50. > >performance fart (Tested on Dhrystone 2.1).
  51. > 
  52. > What the bleep does this prove?  That unoptimized x86 compilers are
  53. > more efficient than unoptimized sparc compilers?  Who cares?  Compare
  54. > SPECmarks on optimized code if you want to make a comparison for gcc.
  55.  
  56. It the bleep proves that it's damn hard to optimize 80x86 code. You
  57. won't get much of a performance gain. As I said we used identical
  58. compilers on both machines. Thus the unoptimized outputs stem from
  59. identical parse trees.
  60. If you compare based on standard benchmarks, don't compare even
  61. SPECmarks. At least let the manufacturer hand you SPECint92 and
  62. SPECf92p values separately (SPECmarks was 1989) and compare each
  63. single benchmark out of the complete suite to find out where the
  64. system performs well.
  65.  
  66. > >Intel has always been lagging around a year behind its competitors
  67. > >in performance. However, they have learned to announce very early
  68. > >and deliver bad versions of the chips early so they sometimes appear
  69. > >up-to-date. But if you compare the real-world availability dates of
  70. > >intel 80x86 chips with their RISC competitors, they're almost always
  71. > >a generation behind.
  72. > >
  73. > 
  74. > What product was announced early, in your opinion?
  75.  
  76. 386, each stage of the 486 (25, 33, 50, 66) except SX, and
  77. Pentium, and this is not only my opinion.
  78. In addition the early 386s were buggy in 32-bit multiply
  79. (M$ even rewrote their C library to enable it to be used
  80. on these faulty processors).
  81. The early 486s were buggy in the FP unit and somewhere else I don't
  82. remember. The 486/50 took an additional 6 months after they were
  83. finally delivered to get rid of a heat problem.
  84.  
  85. > >I would prefer NeXT to go with PA-RISC or, better yet, alpha (expensive
  86. > >though). Best compromise might be SPARC: High availability, multiple
  87. > >vendors, low price (much lower than 80x86es!) higher performance,
  88. > >pretty much iron out there alread, with much more to come.
  89. > 
  90. > Ah, from a sexy/horsepower point of view, we would all like to see this.
  91. > Wouldn't we?  But let's look at the realities of this, which NeXT must
  92. > face.  PA-RISC is a proprietary processor.  So if NeXT designs a system,
  93. > where are they going to buy the chips from?
  94.  
  95. Where is NeXT going to buy the Pentium if they design a Pentium-based one?
  96.  
  97. > And what about Alpha?
  98. > Unproven, expensive, not a mass-production levels, DEC unproven as a
  99. > CPU supplier.
  100.  
  101. They have been delivering 21064s (alphas) for months. At 150 MHz.
  102. What are you afraid of DEC as a chip supplier (other than to cut into
  103. intel's semi-monopoly).
  104.  
  105. > With all of NeXT's experiences with bad decisions (C-cube,
  106. > DSP, optical), why would they bet the farm on another?
  107.  
  108. Whew! So you think the DSP was a bad decision? Maybe because it's from
  109. Motorola? What's wrong with having a DSP?
  110.  
  111. > SPARC?  I guess it will have alot to do with what markets NeXT is
  112. > aiming for, and how many different architectures they want to support.
  113. > Remember, SPARC _systems_ are typically more expensive than x86 systems.
  114.  
  115. They are also a lot better equipped (i.e. the equivalent of a:
  116.     - local bus 32-bit SCSI
  117.     - local bus accelerated 32-bit graphics card
  118.     - local bus 32-bit ethernet board
  119.     - dual local bus 32-bit serial interfaces
  120.     - local bus 32-bit disk controller, sound input and
  121. most importantly, a
  122.     - local bus 32-bit wide keyboard interface!!! ;-)
  123.     - a decent boot prom that lets you fix hard disks etc. even
  124.       if you can't boot the O/S any more.
  125.  
  126. > And there are NO significant performace differences.
  127.  
  128. Whoooaaarr! That was a good one. Ever had a look at an SS-10? Or, even
  129. better from price-performance, an LX? And those are original Sun
  130. products, expect much lower prices from the clone makers soon.
  131.  
  132. > From NeXT's perspective, the best route for the near future is Intel.
  133. > If TTM (Time To Market) is important to NeXT (and I'm sure most of you
  134. > want your next NeXT workstation soon).
  135.  
  136. The Pentium is again delayed, this time until end 1993. Talk about time
  137. to market
  138.  
  139. > They already have the OS
  140. > running on x86 machines.  Why port to a different architecture even if
  141. > significant performance gains are there?
  142.  
  143. Because of these performance gains (among a *lot* of other reasons).
  144.  
  145. > As for the long term, NeXT has NDAs with many vendors.  They will make
  146.  
  147. Thus endeth your posting...?
  148.  
  149. > -- 
  150. > 
  151. > Len Schultz, lschultz@ichips.intel.com
  152. > Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
  153. > Hillsboro, Oregon 97124-6497
  154.  
  155.  
  156.     Volker
  157.  
  158. --
  159. Volker Herminghaus-Shirai (vhs@qb.rhein-main.de)
  160.  
  161. Looks good on the outside, but -
  162.     intel inside
  163.