Author: Robert Hyatt
Date: 18:01:29 07/11/03
Go up one level in this thread
On July 10, 2003 at 23:03:46, Vincent Diepeveen wrote:
>On July 10, 2003 at 22:14:55, Dann Corbit wrote:
>
>>On July 10, 2003 at 17:17:14, Tom Kerrigan wrote:
>>
>>>On July 10, 2003 at 07:11:02, Peter McKenzie wrote:
>>>
>>>>Noticed this over at OS news, I've only read the first page but it looks
>>>>reasonably well written. Probably not at a terribly high level but interesting
>>>>anyway.
>>>>
>>>>http://www.osnews.com/story.php?news_id=3997
>>>>
>>>>Hope it doesn't fuel the fires too much....
>>>>
>>>>Peter
>>>
>>>More or less accurate... Probably one of the most balanced article I've seen
>>>that addresses RISC vs. x86.
>>
>>Pure fairy-land, IMO.
>>
>>Sure, you can make a RISC CPU run like the wind. But what are you going to run
>>on it, and what software development tools are available for it?
>>
>>Why is the Itanic sinking? It's not a bad chip. Because it discared 20 years
>>of development efforts.
>
>Why do you say itanic is a RISC cpu?
>
>it's executing 2 bundles a cycle. So it's doing 6 instructions a clock.
>
>In short it is far away from RISC IMHO.
>
>For me RISC is something that is using simple instructions and not much
>constraints and executing 1 instruction a cycle.
"simple instructions" is not a part of RISC. The basic idea is that
first, there are two classes of instructions. one class that reads/writes
RAM, and the other class which operates on data that is only in registers.
That requirement is there for speed, since RAM has variable latency depending
on what is going on at the instant the CPU needs data. That design goes back
to the days of CDC and Cray.
One instruction a cycle is _definitely_ not a RISC attribute. It is preferred
that one instruction take only one cycle to execute, but executing multiple
instructions per clock is simply called super-scalar, and a RISC architecture
can be super-scalar or not, but it is still RISC.
Simple instructions are out as well. That was an "early RISC" characteristic,
but it went away quickly. IE I can't call "sqrt()" a simple instruction, yet
FP instruction sets certainly include one. Original suns didn't have int
multiply/divide. Now they do. The "simple" part of risc instruction sets is
the limit on accessing memory to a small class of instructions, such as load/
store on the sparc. That eliminates instructions like TTBS (translate and
test byte string) on the vax, which can't be done using only registers.
>
>the complexity of the itanium chip is that they that it by no means can be
>called a RISC cpu.
What does "complexity of the chip" have to do with "RISC"? The Cray is a
RISC architecture. It is pretty "complex".
>
>Any OoO cpu i would argue is not RISC either.
I don't see why that matters.
>
>>Some RISC chips will go into ultra-expensive workstations that will perform
>>marginally better than some off-the-shelf AMD 64 bit chips at a horrible
>>price/performance ratio.
>
>>The cost of a CPU is a function of:
>>Development costs/total sales volume + {some marketing goo/misc}.
>>IOW:
>> You sell ten thousand chips --> it better have been cheap to design.
>> You sell ten million chips --> you can spend millions in development.
>
>I would argue it is more like:
>
>R = long term investment risk company is willing to take (you invest money
>hoping to get it back)
>B = size of the company (intel will always invest more in a cpu than AMD at the
> moment)
>E = earnings a cpu
>P = production costs a cpu
>G = guessed amount of cpu's you can sell from it within x years
>M = the risk you are willing to invest into a cpu in case you can
> within x years get a monopoly seemingly at that market segment
>C = costs you make anyway to keep alive a design department
>
>Consideration to do it : R+B+M+P*G - G*E > C
>
>>RISC is totally impractical. Even wonderful designs like the Alpha chip go
>>nowhere. Since the TRAGIC decision by IBM to choose the Intel chip, there has
>>been no turning back. The only reason Intel will ever look over their own
>>shoulder is because they jumped off their own train tracks.
>>
>>I am sure that they will have an x86 compatible 64 bit CPU once they come to
>>their senses. They already started to develop one, some time ago.
>
>100% sureness. I had confirmation by carefully picking questions i asked to
>intel marketing department managers.
>
>Biggest considerations to chose for x86-64:
> - they can use something that works great free from royalties
> - if both them and amd use x86-64 then they got a > 50% chance to win the
> race and to work out in the highend market all the manufacturers. No one
> will be able to beat intel or AMD in the long run and intels chances as we
> know must be estimated pretty high here to do well
> - when they produce a chip they directly will look great in contradiction
> to AMD which now suffers from windows not working yet for x86-64.
> - they can look to opteron and simply learn from that and produce something
> better. So at one point in future they're making a REAL good chance to
> beat the opteron.
> - if they make something equal to opteron then intel can produce the chip
>cheaper simply as they have proven so far to have the better process technology.
>the only disturbing factor will be that ibm builds the 0.09 opteron factory.
>intels 0.09 will be ready long before that one from ibm (that gets then owned on
>the paper by AMD after signing a contract).
>
>IBM isn't away.
>
>Apart from that ibm has power4 too.
>
>Knowing ibm builds cheap clusters (yes i had zero effort to put that through my
>throat because clusters *are* cheap compared to supercomputers) then the opteron
>chip is going to annihilate all the other supercomputers of course.
>
>Note that there isn't an itanium solution yet that supports openMP at > 64
>processors.
>
>Apart from that the madisons are delayed delayed and either their compiler is
>bugged or the chip itself has same problem like the 1 Ghz and 0.9 Ghz 0.18
>mckinley had (intel had clocked it too high).
>
>Best regards,
>Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.