Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!sdd.hp.com!wuarchive!uunet!mcsun!hp4nl!charon!dik From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.arch Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <3438@charon.cwi.nl> Date: 3 May 91 00:59:30 GMT References: <3423@charon.cwi.nl> <11602@mentor.cc.purdue.edu> <1991Apr30.163153.18568@midway.uchicago.edu> Sender: news@cwi.nl Organization: CWI, Amsterdam Lines: 27 In article <1991Apr30.163153.18568@midway.uchicago.edu> rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: > > Comments on Cyber 205, page faults, etc. > > For just about all fluids > codes, we found virtual memory to be essentially worthless. For > out of core codes, we had to manage I/O by hand, and about all > virtual memory did for us was to enable us to create blocks of > virtual storage that we could move things in and out of "by hand" True enough. VM is great for the instruction stream and for small pieces of data. It is a bother when you are using large datasets. (The same holds for cache.) But this is not so much an architecture problem as well as an OS/ compiler problem. You ought to be able to specify what parts of the data should not be managed through VM (with probably some refinement with respect to cache management). Whatever the replacement algorithm is you will always see some codes (and they are not so uncommon) that trample all over memory in a way that was not predicted. As an example: solving a large linear system that does not fit in memory. The standard algorithms only lead to page thrashing. A colleague of mine once tried a 1000x1000 system on a 1 Mword 205 using standard algorithms. Result: turn around time approx. 9 hours. CPU time 3 minutes? (probably less.) There are algorithms that can do better, but they need to know the page size and the replacement algorithm. When applying such an algorithm we got it down to a turn around time of 3 minutes. -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl