Path: utzoo!attcan!uunet!zaphod.mps.ohio-state.edu!usc!apple!portal!cup.portal.com!thad From: thad@cup.portal.com (Thad P Floryan) Newsgroups: comp.sys.amiga.advocacy Subject: Re: Thad and me Message-ID: <38017@cup.portal.com> Date: 14 Jan 91 06:37:42 GMT References: <1991Jan13.211613.7825@zorch.SF-Bay.ORG> Organization: The Portal System (TM) Lines: 234 mykes@zorch.SF-Bay.ORG (Mike Schwartz) in <1991Jan13.211613.7825@zorch.SF-Bay.ORG> writes: 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. :-) I appreciate your taking the time to respond, and I'm happy to read that you didn't take any of my posting as a personal attack. I fully appreciate the need for optimization and speed when appropriate. One of my favorite shockers is showing people some of my code on the PDP-10/DEC-20 systems where I'd do a "special" JRSTF telling the CPU the first part of the next instruction has "already been done" for entry into a loop simply to save 250nS ... but that 250nS saved DID add up to a lot in time-critical routines performed tens of thousands of times a day. 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. Aha! So that's where Jay is now. Gee, back when I became involved with ol' Tymshare Associates, there was only 1 computer in Palo Alto; the legacy now includes Tymnet (owned by British Telecom) and McDonnell Douglas Field Service. If he's running SunOS and X, then I understand his comments, but it sounds to me more like he's on a 3/50 or a 3/60 (for which his complaints are valid). 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. Then there's something "wrong" with the UNIX on those machines, since that's NOT my experience with UNIX on 680x0 platforms, only on 80x86 platforms. As a for-example, on the 3B1 there are several windowing environments from which one can choose: UA (User Agent, akin to SVR4's "FACE"), and MGR (Bellcore's window manager). All these are quite spiffy, and even my 68010 3B1 runs circles around 25MHz '386 systems running UNIX; you'll be able to see this for yourself at this year's West Coast Computer Faire at Moscone Center in San Francisco where, again, I'll have a 3B1 and a '386 both running UNIX in the same booth. And Amigas will probably be in an adjacent booth like at last year's show. 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. Not true! The ONLY reason I put those big jobs in the background is because I want a copy of the entire compile run as a batch log file via: nohup job & Besides, it's kinda boring looking at compiler output, so while the batch job is running I may choose to play a game or do other work. As I posted previously (months ago in comp.sys.amiga), my '020 Amiga is actually slower than my 3B1 doing those big jobs like uncompressng and unpacking the GNU EMACS tar file ... my suspicion is multi-tasking on the Amiga is not friendly with multiple processes all accessing the same HD. The DISKPERF runs show over 400Kbytes/sec on my Amiga systems so that's not the problem ... it has to be something to do with reading and writing the same HD from multiple processes. The only UNIX system I use that causes "waiting" is a Mac II running A/UX 2.0; the others are all relatively fast and I've never uttered "damn slow computer" for anything except our VAXes running VMS. 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 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. No argument. :-) The Amiga is a trivial machine to port Unix programs to. For "simple" programs, sure. But even with CBM's new A225 (TCP/IP) stuff, I don't see *.h files, socket libraries, etc. so how's one gonna port any networking utilities and applications? Just try a select() ! :-) And, on UNIX, one NEVER need worry about "stack" size, but on the Amiga it's the kiss of death and lunch with the guru if STACK isn't large enough. 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. Now here's where we disagree. GNU EMACS is more than fast enough; your CED may be faster. But the several reasons why I *MUST* use it include capabilitie s I need that simply are NOT in ANY other editor, plus I have EMACS on EVERY machine I use, so I don't have to waste time stumbling with different command sets. I use perhaps 4 or 5 different machines every day, and because EMACS is on all of them the transition is transparent. And note I'm *NOT* talking about microemacs but the full-fledged Stallman EMACS. I can give you more examples of programs that do things right and wrong on the Amiga. [...] 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? I didn't put all that RAM on my Amigas just to tax the power supply! :-) I, too, use QB and have no complaints about it. But, you're missing a VERY important point: a tar file I create on my HP9000/840 is readable on my Amiga and on my 3B1 and on other systems, and vice versa. I've now switched to "pax" which is the POSIX tar/cpio/pax program and, again, tapes and/or other archives created on ANY of my systems can be read and processed on all other (except for the #&#^%&$ VAXes running VMS, but that's a different story, and, yes, I know there's a DECUS TAR, but ...) There's even a "pax" for MS-DOS (and I've verified it works). PORTABILITY has, to me, become the number one single most important issue. 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. [...] 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. It's obvious your computing requirements differ from mine. I *need* to be doing batch-mode ftp's while uucp'ing while cnews'ing while gcc'ing while EMACS'ing while &tc. Let's step back for a second and look at this: the SAME type of machine is satisfying BOTH our needs! 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. What? Assembler code? Depends on your market. I've been in this "racket" for over 25 years and have seen a complete reversal of the "cost of computing" from when computers were expensive and software was cheap to the present inexpensive computers (relatively speaking) and expensive software. From my perspective software portability is the number one concern due to the costs. And I'm no stranger to assembly language; probably most of my code has been assembler, though now it's about 95% C (except for my code generators) simply for the portability and elimination of the need to re-invent the wheel on each new hardware platform. Computers are only going to get bigger and faster. Nope. They're gonna get smaller and faster! Probably the world's most powerful computer will be contained in a sphere the size of a basketball. [...] 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. WHY do you keep saying that? WHAT crap program does 2K buffered read and writes? None of which I'm aware. Are you sure you're not talking about MINIX or something? Even the standard tape programs on my systems use either 64K or 256K double-buffering to keep the tapes streaming. GNU EMACS on my 3B1 systems reads/writes huge files in what I call "carriage return time" (i.e. the operation is done by the time the CRT cursor returns to the left margin after I hit RETURN (even on the Amiga with mg2a)). I have NO complaints about speed, so I'm REALLY curious what system(s)/program(s) you've used that have given you such a negative impression of UNIX. 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. Sure hope you're running that 64MB RAM machine on a UPS! :-) Amiga gives us the creative edge. To be creative, you need to be forward thinking to some degree. Agreed. That's why it's frustrating to come head-to-head with obstinate people (not you) who cannot SEE the advantages of the Amiga solution compared to Macs or IBM-PCs. Think ahead Thad, not backward to what used to be good. Moi? :-) I never would have gotten "involved" with the Amiga at the time I did if I wasn't forward-thinking. And that's why I'm puzzled with what appears to be your fixation on massive amounts of RAM and single-tasking. One of the main advantages of the Amiga is its multi-tasking as I "flamed" a Mac-type in another thread in this newsgroup earlier today (re: "Try THAT on your stinking Apple!" :-) Thad P.S. I'm sure you're aware of this, but, if not, you CAN run a UNIX box in what's known as single-user mode if speed and resource utilization is a great concern. Typically the command to enter that mode is "shutdown" which will remove background daemons, kill all user's jobs, do a "telinit s", and prohibit new logins. But, as far as I'm concerned, single-tasking is for things like microwave ovens and process-control computers. Advocating multi-tasking IS forward- thinking. People Productivity is the issue ... I can get a LOT more real work done on a multi-tasking system than on a mono-tasking system. Thad Floryan [ thad@cup.portal.com ]