mykes@zorch.SF-Bay.ORG (Mike Schwartz) (01/14/91)
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
thad@cup.portal.com (Thad P Floryan) (01/14/91)
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 ]jms@tardis.Tymnet.COM (Joe Smith) (01/22/91)
In article <38017@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: mykes@zorch.SF-Bay.ORG (Mike Schwartz) > 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. >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). A few years ago Tymnet decided that having a Sun-3/50 on everyone's desk was a great idea. Unfortunately we're talking about a 15MHz 68020 with no swap disk and only 4 meg RAM. Running SunOS-4.0.3 with less than 10 megs is a big lose - swapping over a busy Ethernet takes forever. A little old A2000 with a 7MHz 68000 and 1 meg RAM ran rings around such Suns, even when the Amiga was running off of floppies. Just another example of how a completely memory-resident window manager system will always outperform a swappable window manager system. -- Joe Smith (408)922-6220 | SMTP: jms@tardis.tymnet.com or jms@gemini.tymnet.com BT Tymnet Tech Services | UUCP: ...!{ames,pyramid}!oliveb!tymix!tardis!jms PO Box 49019, MS-C51 | BIX: smithjoe | CA license plate: "POPJ P," (PDP-10) San Jose, CA 95161-9019 | humorous dislaimer: "My Amiga 3000 speaks for me."
peter@sugar.hackercorp.com (Peter da Silva) (01/24/91)
In article <1453@tardis.Tymnet.COM> jms@tardis.Tymnet.COM (Joe Smith) writes: > Just another example of how a completely memory-resident window manager > system will always outperform a swappable window manager system. At the bottom line, user interfaces are basically a real-time problem. The more so the more complex the UI. Oh, sure, there's no hard deadline... but the longer you take the less productive the user will be. And real-time and virtual memory fit together like George Bush and Saddam Hussein. (apropos of the eternal Mac-bashing thread, cooperative multitasking hasn't been state of the art in real-time even on micros since the late '70s) -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.