Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!ames!dftsrv!drax!buck From: buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) Newsgroups: comp.benchmarks Subject: Re: Next diatribe on benchmarking Message-ID: <4090@dftsrv.gsfc.nasa.gov> Date: 4 Dec 90 19:04:27 GMT References: <7636@eos.arc.nasa.gov> Sender: news@dftsrv.gsfc.nasa.gov Reply-To: buck@drax.UUCP (Loren (Buck) Buchanan) Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center Lines: 40 Thanks eugene for another eye opening discussion of a current problem. A difficult to implement, but useful benchmark would be one which would show the speed of processing at various levels of memory (cache, main, and virtual). Note that for some computers there may be more than one level of each kind of memory. The result of such a benchmark would not be a single number, but a set of numbers which when plotted would look something like this: t ____.....--------''''''''''''''' i / m / e / / ____.....------''''' / / / __...----''''' problem size The mostly horizontal portions are where the problem is mostly contained within the limits of that level of memory, and the mostly vertical portion is where thrashing starts to occur. A second benchmark would be one that would involve multiprocessing, and interprocess communication along with the change in problem size to measure the effect of various levels of memory. Another independent dimension to the above is the division between data and instruction caching (sp?). It would would of course be easiest to write a benchmark that would be able to cache the entire program, and let the data be thrashed, but ... well you get the idea. B Cing U Buck Loren Buchanan | buck@drax.gsfc.nasa.gov | #include CSC, 1100 West St. | ...!ames!dftsrv!drax!buck | typedef int by Laurel, MD 20707 | (301) 497-2531 | void where_prohibited(by law){} Phone tag, America's fastest growing business sport. Brought to you by Super Global Mega Corp .com