Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Still wrong

Author: Robert Hyatt

Date: 21:20:46 10/26/01

Go up one level in this thread


On October 26, 2001 at 23:36:15, Eugene Nalimov wrote:

>On October 26, 2001 at 22:33:47, Robert Hyatt wrote:
>
>>On October 26, 2001 at 21:43:35, Tom Kerrigan wrote:
>>
>>>On October 26, 2001 at 21:19:11, Robert Hyatt wrote:
>>>
>>>>>"The floating point unit has 32 32-bit non windowed registers, which must be
>>>>>saved on a per-context basis"
>>>>
>>>>Memory fails as age increases, apparently.  :)
>>>
>>>Maybe FPUs are studied in a semester of comp org that you didn't teach.
>>
>>Actually FPUS really aren't touched on in a one-semester architecture
>>course.  With pipelines, cache, memory management, plus a few specific
>>architectures, time runs out pretty quickly.
>>
>>
>>>
>>>>There is only _one_ data path _into_ the CPU.  I was originally talking about
>>>>the 64 bit chunks that can flow into the cpu from outside.  And that is a
>>>>real bottleneck on Intel boxes, still.  IE you can't possible load
>>>>instructions, int data, and fp data, fast enough if you have to use memory.
>>>>And the classic SPEC benchmarks tend to stream data like crazy...
>>>
>>>This is going off on a tangent; Intel's decision to use a 64-bit FSB is almost
>>>certainly based on price/performance goals and not the bitiness of any processor
>>>internals. The FSB is 64-bit, the L2 bus is 256-bit, the SSE datapaths are
>>>128-bit, the x87 FPU is 64-bit (I believe), the core is 32-bit... all design
>>>decisions determined by any number of factors. It would have been a small amount
>>>of work to make the P4 a 64-bit chip instead of a 32-bit chip; this wasn't done
>>>almost certainly because the need for 64-bit is too small to justify a new
>>>instruction set. Or they didn't want the P4 to compete directly with the Itanic
>>>(and kick it in the nuts). AMD seems pretty happy to go the 64-bit route with
>>>x86-64 and minimal changes to the Athlon design.
>>>
>>>-Tom
>>
>>In any case, I still believe the _driving_ force for 64 bit machines is not
>>memory, since I still don't see any > 4gig machines lying around.  But I do
>>see a lot of people comparing FP performance to choose their next
>>high-performance workstation.  The best example here is still the Cray.  With
>>a 32 bit address bus, but a huge data path.  Ditto for comparing the processors
>>made by everybody, to the intel X86.  Everybody has done 64 bit processors,
>>but hardly any go beyond 2^32 address lines.  Seems to me that it is for
>>reasons other than address space, based on that...
>
>I believe that 64-bit CPUs are going to mainline now *exclusively* due to the
>need of the large address space. Falling memory prices, as well as increased CPU
>power (it allows you to run large databases on your cheap Windows/*nix boxes)
>created that demand.
>
>You can easily increase bus throughtput without increasing "bittness" of the
>integer part of CPU. As Tom pointed, P6 bus already goes behind 32 bits, so it's
>possible just to make it wider without changing instruction set, modifying any
>software, etc. That will take care of the bandwith all those FP applications
>want. But please notice that both main x86 players are going to 64 bits,
>including full 64-bit addresses. Yes, in the first implementations there will be
>less real address lines, but the potential is there.
>
>And I bet that in 2-3 years you'll notice that 4Gb is not enough, even for
>Crafty. You'll be able to fill 4Gb hash table in several seconds. Plus you'll
>need memory for the 6-man decompression tables...
>
>Eugene


From that perspective, the xeon is already enough.  36 gigs total.  I'll bet
nobody has >4 gigs on a "workstation" for at _least_ a few more years... and
by "nobody" I mean "average power user"...

Personally, I want 64 bits for a _totally_ different reason, of course, and
it has nothing to do with floating point at all. :)



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.