Author: Robert Hyatt
Date: 12:26:06 11/13/97
Go up one level in this thread
On November 13, 1997 at 14:15:35, Ernst A. Heinz wrote: >On November 13, 1997 at 13:49:48, Robert Hyatt wrote: >> >>B.T. Fraise had a 533mhz alpha running on ICC. He was getting around >>150K >>nodes per second with Crafty, which he runs there as "Data". Jason used >>a >>plain vanilla DEC alpha/500mhz in Paris, and we were getting around 250K >>nodes per second. He compared that machine to a P6/200 using the same >>OS (NT) and was getting around 80K. So the /500 gave us 250/80 speedup >>which is a factor of 3.1 >> >>Data went from 80K to 150K, which was less than 2.0 speedup. Even >>worse, >>on his alpha, we saw *dramatic* speed variations, from 40K to 150K, >>running >>the *same* test position multiple times. It seems that there is some >>cache >>condition that can be badly broken, or *something*. Because we did not >>see >>this wild fluctuation on the Digital machines. >> >>main point of all this is that a cheap alpha might be a "cheap alpha". >>We >>need some data to compare all of these machines, and find out why some >>are >>dogs and others are vipers. > >If Fraise uses Linux and "gcc" --> mystery solved! > >DEC's compilers and optimizers that power DEC Unix and also Visual C++ >for Windows/NT on Alpha produce *much* better code than "gcc". >Especially >the new ones that already allow for dedicated EV56 tuning. > I agree up to a point. But Joel Rivat and I ran on the first 21164 machine he got over there and we used both compilers that were available, the Digital compiler for unix and GCC. Joel ran faster with gcc. I broke even as I recall. From internal comments of the compiler group at DEC, the unix and MSVC compilers are the same on the "back-end"... I'd buy 10% for example, because msvc for the PC produces code 10% faster than gcc for linux... roughly, although the Pentium Compiler Group is closing this gap quickly. But this was almost a factor of 2x. I can't buy GCC being that bad... >Furthermore, "Crafty" seems to be quite memory-bound which makes it much >more sensitive to inferior/superior L3 cache and main memory design as >for latency and throughput. The AlphaStation 500 that Crafty ran on in >Paris featured 2MB L3 cache and 256MB of fast SDRAM. What does Fraise >have? > >As for the speed differences between multiple program invocations, I >stand >by my earlier conclusion that it is related to "bad" mapping of VM pages >to >physical memory pages resulting in subsequent L1 I-cache thrashing. We >see >this phenomenon for "DarkThought" on *all* Alpha-based systems up to now >-- including the cooled 767MHz speed demon we ran on in Paris. > >=Ernst= very possible, although I don't understand why we don't. IE I believe jason reported at worst he saw a 10% variation, and usually not that much. This is a known problem when using a virtual addressing system, since caching is done with respect to real memory (on some architectures, on other architectures virtual memory is cached which totally solves this and also makes the machine run a bit faster too since cache hits bypass the memory management hardware). maybe unix needs a new hook into the memory management part of the kernel that says "give me contiguous real memory pages mapped into contiguous virtual addresses so I can have optimal cache mapping." Not done at present, but it is possible...
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.