Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!cmcl2!lanl!jlg From: jlg@lanl.ARPA (Jim Giles) Newsgroups: net.arch Subject: Re: VERY LARGE main memories Message-ID: <7148@lanl.ARPA> Date: Fri, 5-Sep-86 17:49:18 EDT Article-I.D.: lanl.7148 Posted: Fri Sep 5 17:49:18 1986 Date-Received: Fri, 5-Sep-86 22:11:05 EDT References: <1130@bu-cs.bu-cs.BU.EDU> <7144@lanl.ARPA> Reply-To: jlg@a.UUCP (Jim Giles) Organization: Los Alamos National Laboratory Lines: 47 In article <7144@lanl.ARPA> jlg@a.UUCP (Jim Giles) writes: >The task of zeroing memory on the Cray 2 with 256MW (=2GB) should take >less than 5-10 seconds. You must remember that a one MIP machine is >pathetically slow compared to a Cray (at least for vector operations >like zeroing memory, searching, sorting, and many scientific >applications). > I made a slight error (by an order of magnitude) - The Cray 2 should take about .5 to 1.0 seconds to clear all its memory. It seems that large memory machines are obviously desireable. In lattice guage theory a single lattice could easily use all the Cray 2 memory. 3-d hydro codes also use enormous ammounts of memory. Furthermore, applications like these make frequent references to the entire data structure (ie. the whole array is updated every single time-step). The desirability of paging for such machines is not so obvious. Consider a code which updates a large array on each step through a loop (each time-step). If the central memory is too small to hold the entire array and you have a virtual memory scheme, some part of the array will get swapped out on each time step. Most likely, it will be the least recently used page that gets swapped - the very one that you will need first on the subsequent time step! You are now in a situation of chasing you tail around memory - losing time all the while. Without virtual memory though, your code can anticipate the problem by initializing asynchronous I/O long before it needs to use the data. And, since it's not driven by page faults, you can select only a particular part of the array to be swapped - thus minimizing I/O. This kind of programming effort is somewhat unfasionable these days, but it's exactly the sort of thing that most programmers that use these big machines immediately do. They bought the machine because the critical issue was SPEED - and anything that reduces this speed (like virtual memory) is to be shunned. (Cyber 205 users usually turn off the virtual memory when they need speed, Crays don't even have virtual memory.) On the other hand, a small memory - single user machine (like my SUN workstation) should never be built without virtual memory. The desirability of a feature should always be driven entirely be the purpose of the machine. J. Giles Los Alamos