Path: utzoo!attcan!uunet!cs.utexas.edu!uwm.edu!bionet!ames!vsi1!zorch!mykes From: mykes@zorch.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.advocacy Subject: Re: AMIGA Message-ID: <1991Jan12.092901.6922@zorch.SF-Bay.ORG> Date: 12 Jan 91 09:29:01 GMT References: <1991Jan10.151816.13893@rice.edu> <1991Jan11.071410.16032@zorch.SF-Bay.ORG> <37883@cup.portal.com> Organization: SF-Bay Public-Access Unix Lines: 184 >>From vsi1!apple!portal!cup.portal.com!thad Sat Jan 12 00:13:08 PST 1991 >>Article: 49 of comp.sys.amiga.advocacy >>Path: zorch!vsi1!apple!portal!cup.portal.com!thad >>From: thad@cup.portal.com (Thad P Floryan) >>Newsgroups: comp.sys.amiga.advocacy >>Subject: Re: AMIGA >>Message-ID: <37883@cup.portal.com> >>Date: 11 Jan 91 15:30:52 GMT >>References: <1991Jan10.082327.7378@rice.edu> >> <1991Jan10.095304.16900@mintaka.lcs.mit.edu> >> <1991Jan10.151816.13893@rice.edu> >> <1991Jan11.071410.16032@zorch.SF-Bay.ORG> >>Organization: The Portal System (TM) >>Lines: 89 >> >>mykes@zorch.SF-Bay.ORG (Mike Schwartz) >>in <1991Jan11.071410.16032@zorch.SF-Bay.ORG> writes: >> >> [...] >> Once you start writing software for the machine, you learn to NOT >> buffer your reads and writes... You see, the machine has PLENTY of >> RAM available when the system is running and you can just read() >> virtually any file into RAM all at once. I can't stand to use some of >> these Unix applications that have been ported to the Amiga because >> they do buffer their I/O (seems like on a 12MB Unix machine there is >> not enough RAM to put a large source file and the OS in RAM at the >> same time :( When I run a program that does one BIG read, it is so >> fast. When I run a program that reads a small chunk at a time, it is >> orders of magnitude slower. You just don't have to waste time that >> should be spent focusing on what the application needs to do. >> >>Your post is a joke, right? You start bringing in fully RAM-resident files >>and you're gonna blow all the other tasks right out of the water due to lack >>of memory. >> Sorry, no joke intended. On a 4MB (5 including chip) with a floppy sized RAD:, you still have 3MB of RAM left over. Most AMIGA applications do just as I say you should. Consider 99% of the program editors. They all read 100% of your source files into RAM. Doing this in ONE BIG READ IS AN ORDER OF MAGNITUDE FASTER than reading in 2K chunks. Why not read it in ONE CHUNK like CygnusEd does so it will be as fast as possible. I can name you a bunch more programs that also do big reads: DPaint, Devpac Assembler, AudioMaster, and so on and so on. >>Seems you don't understand the concept of "buffering." Buffering is meant to >>be an intermediate holding-area between memory and the disk(s) to facilitate >>optimal data transfer. >> >>Only with poorly-designed software systems have I seen an application, such as >>a spreadsheet, require all its data to be in memory. Now suppose I've used all >>RAM and need to add one more row? Guru city on a non-MMU, non-SVR4 Amiga. >> The common solution is to add more RAM or to dedicate more of your existing RAM (i.e. remove RAM disks, kill programs, etc.) so the spreadsheet (or whatever fits). I would hate to see a 4MB spreadsheet paged out to disk. The recalculation time would be soooooooooo sloooooooow. Why do you want to make a fast machine do things slowly? The machine is built for speed (like 25 DMA channels standard feature), so why not make it perform? >>Or suppose I'm processing receivables, payables, tax statements, etc. all of >>which may reside in 30MB data files. No way is any "reasonable" system going >>to have sufficient RAM available (though I've seen some VAX systems with a >>64MB RAM disk and 256MB main memory :-). >> Obviously an application that generates more data than you have RAM for or one that is designed to work on database applications needs special consideration. But consider this. Before this year ('91) ends, you will see Amigas with 68040's and 64MB of RAM, so your 30MB data file WILL fit in RAM and if your database program DID read the whole thing in, you would only have to wait about 15 seconds for the disk load and would have a program that is zippy in response instead of one that makes you wait a second or more each time you access a record. By the way, a 25 MHz 64MB 68040 Amiga with 700MB hard drive will cost less than $10,000 (ouch). >>There are well-documented and widespread programming algorithms (index files, >>as one for-instance) to permit handling essentially unlimited amounts of data, >>and PROFESSIONAL products use those techniques. Toy products, like dinky >>200x1000 spreadsheets, will suffer you their RAM-resident requirements. I use SuperPlan. It has a limit of 2K by 4K cells. I make some large spreadsheets (a few thousand cells for a stock market charting template) and have not problem fitting them in memory while I do a file transfer in the background in a term program, my editor, and DPaint at the same time. I do highly recommend the spreadsheet, it has a LOT of features and is VERY professional. It does support links between spreadsheets in RAM and on hard disk, so you can make spreadsheets larger than those that fit in RAM out of 2+ files. >> >>And your comment: >> >> I can't stand to use some of these Unix applications that have been >> ported to the Amiga because they do buffer their I/O (seems like on a >> 12MB Unix machine there is not enough RAM to put a large source file >> and the OS in RAM at the same time. >> >>doesn't hold water. The system whose "ps -ef" is shown below sports only 4MB >>RAM, 300MB HD, and is a 68010-based demand-paged virtual-memory system which, >>in some respects, operates MUCH faster than my 68020/68881 Amigas doing things >>such as uncompressing and unpacking 4.5MB tar files (to 12.7MB source) and >>compiling GNU EMACS (FYI it's a 3B1): >> >> thadlabs ksh 24989/24990> date >> Fri Jan 11 07:17:56 PST 1991 >> thadlabs ksh 24989/24990> ps -ef >> UID PID PPID C STIME TTY TIME COMMAND >> root 0 0255 Nov 12 ? 84202:58 swapper >> root 1 0 3 Nov 12 ? 4:50 init >> root 2 0 3 Nov 12 ? 0:02 pagedaemon >> root 3 0 3 Nov 12 ? 131:29 windaemon >> thad 24271 1 3 Jan 9 w1 0:11 ksh >> root 1703 1 3 Dec 17 ? 0:01 uugetty >> root 183 1 3 Nov 12 001 0:01 uugetty >> listen 24989 204 3 Jan 9 p0 0:00 sl >> thad 24990 24989 18 Jan 9 p0 0:18 ksh >> root 117 1 3 Nov 12 ? 0:00 telnetd >> root 97 1 3 Nov 12 ? 0:00 rasdaemon >> root 119 1 3 Nov 12 ? 0:00 ftpd >> root 121 1 3 Nov 12 ? 33:10 rwhod >> root 123 1 3 Nov 12 ? 0:00 fingerd >> thad 26546 24271 3 03:11:51 w1 0:17 emacs >> root 159 1 3 Nov 12 w3 4:14 ph >> root 166 1 3 Nov 12 w4 0:07 wmgr >> root 172 1 12 Nov 12 w5 104:09 smgr >> root 184 1 3 Nov 12 ? 0:00 uugetty >> root 179 1 3 Nov 12 ? 4:47 loadavgd >> root 185 1 3 Nov 12 ? 0:00 uugetty >> lp 17314 1 3 Jan 1 ? 0:01 lpsched >> thad 26575 24990187 07:17:58 p0 0:03 ps >> listen 204 1 3 Nov 12 ? 0:03 listen >> thad 24285 1 8 Jan 9 w1 43:29 sysinfo >> root 24248 1 3 Jan 9 ? 0:00 rexecd >> root 24259 1 3 Jan 9 ? 0:00 rlogind >> uucp 26580 1 25 07:18:03 w5 0:00 uusched >> root 24337 1 3 Jan 9 ? 0:00 rshd >> uucp 26581 1 21 07:18:03 w5 0:00 uuxqt >> thadlabs ksh 24989/24990> >> >> >>Thad Floryan [ thad@cup.portal.com ] >> I doubt all this fits in RAM in your 4MB, which is why you need virtual memory. Virtual memory sucks for a lot of reasons (it also has benefits). Disk access is slower than RAM access, especially when you start talking about 68030 and up machines. In a graphic user interface system (like the Amiga and many Unix systems support), the simple depth arrangement of a window can cause ALL of the other windows to require their programs to be paged in just to refresh the window). It must be horrible to see a machine stutter as it refreshes its windows (due to waiting for disk access). I would think it would be MUCH faster to run SO many programs not in parallel, but in serial. I have no doubt that the amount of time required to do all the tasks would be less that way since the work that the computer would be doing would be RAM intensive instead of disk intensive (swapping). There are some cases when you want to look at the displays of more than one program at once, and if virtual memory is required to handle your WORST cases, it is beneficial. An operating system that makes your typical case your WORST case needs help. I bet on a 4MB Amiga, you could run 2 copies of all those programs listed in your PS (the programs need to be compiled/ported to Amiga) without requiring virtual memory. I bet you'd even have a Meg or 2 to spare. If you CAN use RAM, you should, particularly if you want PERFORMANCE. I once took a typical source file from my Amiga and put it on your typical state of the art PC (386 with 2MB RAM, big hard disk). I loaded it up into Brief, which is supposed to be the state of the art in program editors for the PC and has a price tag high enough that you expect great things from it. Well, it started to read my file and after about 10 seconds, it printed a blinking message in the lower left corner of the screen: "paging...". This occured for another half a minute and then it put me in edit mode. I hit the end key on the cursor pad and I went through the "paging..." sequence again for 30 seconds again, and finally I was at the end of file. Now the source file was less than 100K on the Amiga (about 5000 lines). The same files loads into a 2MB Amiga in less than 1 second in CygnusEd. A good example of how you can slow a machine down with virtual memory. Of course the PC is so limited in RAM that you have to inplement virtual memory (over and over again) when you write programs that need to deal with large amounts of data. Who needs it? Cheers! Mykes