Path: utzoo!attcan!uunet!wuarchive!julius.cs.uiuc.edu!apple!portal!cup.portal.com!thad From: thad@cup.portal.com (Thad P Floryan) Newsgroups: comp.sys.amiga.advocacy Subject: Re: AMIGA Message-ID: <37927@cup.portal.com> Date: 12 Jan 91 16:52:28 GMT References: <1991Jan10.151816.13893@rice.edu> <1991Jan11.071410.16032@zorch.SF-Bay.ORG> <37883@cup.portal.com> <1991Jan12.092901.6922@zorch.SF-Bay.ORG> Organization: The Portal System (TM) Lines: 275 mykes@zorch.SF-Bay.ORG (Mike Schwartz) in <1991Jan12.092901.6922@zorch.SF-Bay.ORG> wrote some stuff with which I disagree. Before we tackle this point by point, I would like to comment that I'm no stranger to the Amiga having used them since mid-1985 and my systems are not exactly "small", to wit (typical): CLI6> avail Type Size In-Use Available Largest chip 515,864 176,096 339,768 338,608 fast 8,388,568 1,931,736 6,456,832 3,532,304 $C00 0 0 0 0 >16M 0 0 0 0 total 8,904,432 2,107,832 6,796,600 CLI6> cpu The CPU is a 68020 with a 68881 The video is NTSC and system clocking is from a GenLock CLI6> info v Mounted Disks: Unit Size Used Free Full Errs Status Name DH61: 45M 90312 7 99% 0 Read/Write SYS6B DH60: 45M 83535 8093 91% 0 Read/Write SYS6A DH50: 302M 313402 291486 51% 0 Read/Write SYS5 DH40: 47M 93995 851 99% 0 Read/Write SYS4 DH24: 26M 53239 9 99% 0 Read/Write SYS2E DH23: 50M 101243 5 99% 0 Read/Write SYS2D DH22: 50M 93533 7715 92% 0 Read/Write SYS2C DH21: 50M 100712 536 99% 0 Read/Write SYS2B DH20: 50M 101203 45 99% 0 Read/Write SYS2A DF2: 880K 971 787 55% 0 Read/Write UNIX-PC.1991.01 DF1: No disk present RAM: 793K 1585 0 100% 0 Read/Write RamDisk DF0: 880K 813 945 46% 0 Read Only SupraBoot CLI6> >>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. Nice how you cleverly avoid and evade the ISSUE. WHAT does reading a file with "one big read" have to do with properly sharing system resources (RAM) with the OTHER programs or tasks that are running? Even with the Amiga whose "stats" are shown at the beginning, I'm UNABLE to unpack into your beloved RAM some of the files I need to process, and I had to resort to gyrations I don't have to do with UNIX (specifically the system I mentioned previously). SCORE: AmigaDOS: 0 UNIX: 1 >>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? Because my data is larger than total memory. Are you for real? :-) SCORE: AmigaDOS: 0 UNIX: 2 >>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). Right, special consideration that AmigaDOS does not automatically provide but UNIX does. SCORE: AmigaDOS: 0 UNIX: 3 Why read all 30MB when, with intelligent and professional methods, I can read only the 2K or so that I may need in just a few milliseconds? And to read/write the entire 30MB file requires at least 60MB on the disk: 30 MB for the original file plus 30 MB more for the "new" copy being created during a rewrite before the old copy is deleted and the bitmap updated. And gawd knows what you've just done to disk fragmentation. SCORE: AmigaDOS: 0 UNIX: 4 >>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. I use sc (spreadsheet calculator, a Lotus-like clone) which is free and is distributed with source code for use on UNIX systems, and I didn't find any apparent limits to the number of cells. Plus, on UNIX, it will run with all the stuff I showed yesterday, and more. I don't feel strongly about things such as spreadsheets, so this one's a tie. :-) SCORE: AmigaDOS: 0.5 UNIX: 4.5 >>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): Oops. I lied. That specific 3B1 has only 3.5MB RAM. SCORE: AmigaDOS: 0.5 UNIX: 5.0 (Remember: I'm keeping score! :-) I doubt all this fits in RAM in your 4MB, which is why you need virtual memory. Aha. This time YOU lied. See the enclosed output of mapmem: Memory Allocation Total Memory = 3584 KBytes, 336K Kernel, 1708K Free (47.7%) 00000000: kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk 00040000: kkkkkkkkkkkkkkkkKKKK.T...T..T.TTT...T...d..TT.....d...TDDK.TkTT. 00080000: .KK.d..TD.K.....T.KKKKKKKKKd...t..Kkkkkkkkk.KK.K.d..t..KKKKKKKKK 000c0000: KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKd.tt.....D....tt.KKKKKKKK 00100000: KKKk.TK.K.KKK..d..t.KK..tK.K.KKKKKKKKKKKKkkkkkkkkkd.dKtDKdddsDd. 00140000: tttdK.dtDt..t....s...Dt.kt..d..tkkkd.ddtttD.DDDKkDDDd..ddddddsD. 00180000: .k.K.D.D.dsKttt...dttt..d.tttD.sK....ttD.t..DTs.K.t..T.KDTdd.tdD 001c0000: .t.KT..t.Dd..t.t.t....d....t.t.Kd.d...D.kt..D....t..K.....D.ddds 00200000: d.D..std..t...t...t.....st..tD...d................t..........ddd 00240000: .D...tk.D...d...d..dK.Dt.....d...T.....d.t.t.d...t...t..t.t..... 00280000: ..t...d.....K..........d.ttd.....Dt..D........t.K...tdd......... 002c0000: .D...D....tt.t......t......dd..d.dd...T...sD....t.d..k.......... 00300000: ........sD....k.dt.d..K.kKs..tD..dd............dd...........T.d. 00340000: ..stt..t....Dt.ttt.T....t.....s....dkdKKs..s.........k.d.td..KKK 00380000: 003c0000: k - kernel virtual memory K - kernel data space t - text segment (shared) d - data segment (private) s - stack segment (private) T - shared library text D - shared library data [m]=memory alloc map [p]=page alloc map [q,x]=exit [+,-]=screen forward/back SCORE: AmigaDOS: 0.5 UNIX: 6.0 (Remember: I'm keeping score! :-) 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). Not my machine. NeXT yes, Mac II with A/UX yes. Dunno about Sun. 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. Oh ho. Now I understand. You want single-tasking. Like MS-DOS, right? :-) SCORE: AmigaDOS: 0.5 UNIX: 6.0 You: -1 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. Nope. You should look at that list again. That's GNU EMACS, GNU gcc, and other GNU stuff running, along with all the Ethernet, StarLAN, HDB uucp, and multiple users logged on. Even with that kind of a load, I can unpack the 4.5 MB GNU EMACS compressed tar file to its 12.7 MB source, and compile and link everything to form a new version in about 55 minutes. SCORE: AmigaDOS: 0.5 UNIX: 7.0 You: -1 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. OK, you hate IBM-PCs (welcome to the club!) and you've just proved what I've been saying all along (in other newsgroups: '386 sucks dead bunnies through a straw, they're so slow). You've redeemed yourself! :-) SCORE: AmigaDOS: 0.5 UNIX: 8.0 You:0 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? Another anti-PC comment. Good! You're learning! :-) SCORE: AmigaDOS: 0.5 UNIX: 9.0 You:1 OK, let's tally up the score and round them just like the "Big Guys" do when they were trying to prove there were insufficient Amigas in the world to even consider porting "real" software to it: FINAL SCORE: AmigaDOS: 0.0 UNIX: 100 You: 0 Any more questions? :-) Thad P.S. Sure wish we had *.advocacy years ago. At least in THIS newsgroup it's known that everyone is sarcastic, punny, and up to no good! :-) P.P.S. And I hope no-one takes some of my satire (above) seriously; for years, fer crissakes, I've been one of the staunchest Amiga advocates and still am, but for professional work (as I detailed in another comp.sys.amiga.*) with the nature of my clients, we gotta go UNIX. And SVR4 on an Amiga platform is just fine with me! Thad Floryan [ thad@cup.portal.com ]