Author: Robert Hyatt
Date: 14:23:32 01/23/00
Go up one level in this thread
On January 23, 2000 at 14:05:41, Tom Kerrigan wrote: >On January 23, 2000 at 13:48:14, Robert Hyatt wrote: > >>there are good PC-based FORTRAN compilers. And in fact I did this. On a >>Cray cpu running at (back then about 80 megahertz (12.5ns clock cycle cray-1) >>we ran at over 20K nodes per second on a single CPU. I ran this on a 133mhz >>P5 and could not hit 100 nodes per second. > >Don't try to confuse people. > >You have said many times that CB used a lot of vectorized Cray assembly. >Expecting this to run reasonably fast on a PC is obviously stupid. > >The POWER3 processor is not significantly different from a PC processor. (Well, >it's probably significantly slower.) There is no reason why the DB software >wouldn't run well on a PC. > >-Tom Nope... back off when you don't know what you are talking about. I am talking about a pure FORTRAN program on the Cray, vs a pure FORTRAN program on a PC. Except that the fortran code was written knowing that it would be run on a Cray vector machine, and certain things would be handled very efficiently by the hardware. The assembly language wasn't in this context. We didn't do the assembly language until years after the fortran was done... and when I compare speeds between two machines, I don't use assembly to give one a big edge. As far as DB on a PC, I don't see any way to make it clearer. When you know of specific hardware features you will have access to (vector computing in my case, or parallel threads) then you design a program one way. When you don't have those features, you design a program another way. IE in a bitmap program, the FirstOne() operation is critical. I designed this code knowing that this would be in hardware on the Cray, and on other interesting architectures. For those that don't have this hardware, this approach has a problem. Ditto for PopulationCount(). Got it? Makes me go fast. Don't got it? I can do it with a loop or set of table lookups, but it hurts performance. Enough of those kinds of design decisions and a single sequential instruction stream begins to look pretty bad after you have been thinking of neat hardware solutions for 10 years. The old "think outside the box" idea. To become a hardware designer, a programmer would _definitely_ have to do a lot of "thinking outside the box" because the box he lives in was constrained by the kind of programming he was doing. For hardware design, it becomes a new discipline altogether. Same thing happens once you begin to think in terms of asynchronous threads of execution. Code looks different, and designs are different. In programming we have to work around architectural bottlenecks. In hardware design you design solutions to solve the bottleneck instead... although the solution might not work at all in a programming context...
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.