Author: Robert Hyatt
Date: 13:37:50 10/27/01
Go up one level in this thread
On October 27, 2001 at 00:44:58, Eugene Nalimov wrote: >On October 27, 2001 at 00:20:46, Robert Hyatt wrote: > >>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"... > >First: why "workstation"? There are servers, too. I agree with you -- on the >workstation necessity for 64 bits is much less. But we have clients who need >large memory on the workstations. > >Second: 36 are not *linear* address space. Do you remember 80286? In theory it >could have 8k segments, each 64k in size -- 2**29 bytes total. Nevertheless >everybody was happy when 386 came out. Not because of extra 3 bits, but because >address space was linar. I realize how the Intel kludge works for 36 gigs. However, for "filesystem cache" that works just fine. For a single program, I completely agree with you. > >And third: right now we are working with a team that is running database on >128Gb Itanium system. > >Eugene No doubt. But again, the point, does such a very small niche market drive uprocessor development toward 64 bits? Or did the prior 64 bit development enable larger memory address spaces as an "effect" of the development, rather than as a "cause" of it? > >>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.