Path: utzoo!attcan!uunet!cs.utexas.edu!swrinde!mips!daver!zorch!mykes From: mykes@zorch.SF-Bay.ORG (Mike Schwartz) Newsgroups: comp.sys.amiga.advocacy Subject: Thad and me Message-ID: <1991Jan13.211613.7825@zorch.SF-Bay.ORG> Date: 13 Jan 91 21:16:13 GMT Organization: SF-Bay Public-Access Unix Lines: 135 Congrats, thad, I am now a convert. I think I will try to make all my programs run in 1K or less from now on! :) I like to multitask all the time, and the ONLY time I like to see the Amiga single task is in certain game products like Shadow of the Beast. However, my Amiga does have 4MB of RAM and if I can make ANY application I write use all 4MB and run orders of magnitude faster, I will. I will give you an example... I just finished a video game called Dick Tracy for the Sega Genesis. During development, I wrote about 20 software tools that did a lot of graphic and audio munging. I had one program in particular that had to build up a database of character-oriented graphics from dozens of 32K DPaint screens at a time. My first cut at the program read in ONE screen at a time and the program took more than 15 minutes to run on a 25MHz 68030 Amiga. Because I had to run this munger many times during development, I modified the program to read in ALL the DPaint screens it needed at once. The program then took under a minute. You would argue that the first technique was better because it would be more friendly with other Apps. I argue that the second was better because I (the user) did not have to wait and wait and wait. And even though my munger is a memory hog, I can still run CygnusEd with a meg of source files loaded into it, BaudBandit (a term program), and Dpaint. I could even run multiple copies of the munger at the same time, but benchmarks proved that running it serially was faster than running two at the same time. In your universe, I would wait. In mine, I wait as little as possible. There are limits to how much "single" tasking you want to do, but when you want to do something as fast as possible (granted at all costs), you think about dedicating as much of you machine as possible to the task IF IT IS NEEDED. I used the Devpac assembler to assemble the source code to Tracy. It is already written in optimized assembler language and has a few years of use under its belt in Europe. I disassembled the assembler (it is only 27K on disk) and found that they buffered their I/O in 10K chunks. I modified it to do 1MB chunks and gained an order of magnitude in speed increase. And on my 4MB Amiga, there is still 2.5Megs free while running the assembler, CED, ARexx and DMouse and whatever other TSR/INIT type programs I have in my startup-sequence. As far as Unix goes, you and I have a common friend in Jay Dresser. Jay works at Tymnet where they have a large Sun network. He is constantly telling me how his Sun is a single-tasking computer. I point out to him that Unix is a multitasking operating system, but he says despite this that what you get is effectively singletasking. He has a comparable Sun machine to my Amiga - 68030 with 8MB of RAM. He says that whenever he executes a command in a ] shell or depth arranges windows, the machine does not accept input for a long time (like 15 seconds). He says he likes the Amiga much better because you can resize a window and the response is zippy. As far as my personal experience with Unix goes, I have not used any GUI Unix systems, but my experience with Vax, the Well, Portal, and Zorch is that there are many times when I hit return at a prompt and have to wait for up to a minute, even if I do something as simple as an LS. I consider the speed that a machine responds to a user to be a critical factor in how user- friendly the machine is. From your most recent posting, we seem to agree on this point. I think that you are very used to Unix and in that environment, you are used to waiting a lot. You have to spawn compression/packing/unpacking type programs in the background just so you can have a command line to do something else while you wait. I submit that if you could dedicate your entire machine to the crunching process at hand that you wouldn't have to wait and that you would see things differently. By the way, as long as we are in a bragging contest, I have also had Amigas (plural) since 1985. Currently, I have only 80MB of hard disk at home, but at work, I use a network of 7 2500/030 machines with 1.2 GIG of hard disk. We had two programmers working on Tracy and we used RCS. After watching RCS take MINUTES at a time just to check out a file as the project got larger, I figured out that a simple batch file that did things more like VMS, where you keep the entire source file for each version (rather than diffs) is much more desireable. We all have huge hard disks (look at your system and those of other people who post to the net), so why not use 30 or 40 Meg to keep multiple versions (like 30 or 40 of every file) on disk at a time? Even if hard disk space finally starts to become limited, you can then start deleting the oldest backup copies that really have no use after a while anyway. The Amiga is a trivial machine to port Unix programs to. I see things like UUCP, EMacs, and other applications available. But when I compare EMacs to CED, performance wise, CED is faster in every aspect. The guys who ported EMacs to the Amiga should have (in my opinion) looked for ways to take advantage of the Amiga's ability to be fast. I do understand the need for the original microemacs to run on a 32K PDP-11 (or something like it) with multiple users on the system at the same time, but the Amiga can do a lot more than a PDP-11. I can give you more examples of programs that do things right and wrong on the Amiga. I got a program called Whereis which searches a hard disk for a file. I used it the other day to search for a file on a 100MB partition and it came up and chugged away for a few minutes, then started printing out the message "too few directory slots" over and over and finally choked. Then you can look at Quarterback, which is a hard disk backup program. It goes and builds a tree structure in RAM for the entire hard disk extremely fast. QB uses RAM in every way possible to gain speed. It takes about a half an hour to back up 100MB with it on to floppy disk. Does tar work this fast on the Amiga? One last program example supports my case quite well. Electronic Arts has recently gone into the Genesis game development business. They built a Mac II based cross development environment (I would prefer Amiga, but...). They use an assembler written by a friend of mine that REQUIRES 5MB of RAM to itself. The assembler is written to take advantage of all of the 5MB. It uses 1MB just for its hash table. It reads the entire source and each include file in with one big read and keeps it around for the second pass. It assembles a 500K source file (25,000 lines) in under 20 seconds on a 16 MHz 68020 Mac II. It uses NO linker since ANYTHING you would ever want to link with it could be assembled right in-line so fast that you wouldn't think of hesitating to do it. This kind of program, in any environment, is the current state of the art in software. The kind of program that I rave against is the kind that represented the state of the art in 1975. Computers are only going to get bigger and faster. As I said before, a 64MB (RAM) 68040 Amiga with 700MB hard disk will cost: Amiga 2000 $1500 68040 w/64MB $4500 700MB hard disk $2500 disk controller $300 These figures are rough estimates but are within a couple hundred dollars. A year or two down the road, the prices will be much lower (how much was a 700MB hard disk 2 years ago). Your typical Unix program ported (vanilla) to this machine will still do 2K buffered reads and writes. YUK. By the way, compare the price of the above configured Amiga today with what the same money will buy for Sun, Mac, PC, or 3B1. Right now, my 4MB Amiga is starting to seem less and less useful, since applications should be using more and more RAM as the state of the art improves. On a 64 MB machine, dedicating any less than 16 or 32 MB to some applications may seem weak. Amiga gives us the creative edge. To be creative, you need to be forward thinking to some degree. Think ahead Thad, not backward to what used to be good. Cheers! Mykes