Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ncar!ico!ism780c!haddock!suitti From: suitti@haddock.ima.isc.com (Stephen Uitti) Newsgroups: comp.arch Subject: Re: Double Width Integer Multiplication and Division Message-ID: <13943@haddock.ima.isc.com> Date: 5 Jul 89 20:51:56 GMT References: <1046@aber-cs.UUCP> <1380@l.cc.purdue.edu> Reply-To: suitti@haddock.ima.isc.com (Stephen Uitti) Organization: Interactive Systems, Boston Lines: 120 In article <1380@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: (and various others wrote:) >[1] You are not supposed to write assembler programs on a RISC >machine. The compilers have sophisticated algorithms to generate >"optimal" multiplication/division out of simpler instructions. >> I find this attitude arrogant. Neither you nor anyone else knows what >> complicated operations I want to do. Still, I haven't needed to learn an assembly language just to make some operation faster for over five years. The machine I have on my desk is four times faster than the machine I used to share with 35 people at a time (a VAX 780). It has as much disk space (and much more for me). It has more RAM (9 MB vs 4 or 8). It runs the same operating system, though it has improved capabilities (bitmapped screen, other local devices). The reason i can have it on my desk is that it costs 35 times less than the old VAX. Cost of ownership is also lower in similar proportion. >You do not understand. A very good optimizing compiler (and I have not >seen one) can do a better job of doing a particular complex operation than >I can, PROVIDED that I want to do that operation. The current gcc output is OK, but i can do better. I can generally do minimally 20% better than any compiler. If my original idea maps well to the hardware, but not to the compiler, then speedups can be an order of magnitude. Then again, in one case, the compiler writer provided a long divide, and i was able to speed it up by 15% or so. Three points: Computers are getting real fast, so coding for speed is not required as often (which means code will tend to get sloppier, which means that our throughput will not increase as fast as our machine speeds... of course, i tend not to write that much stuff that needs to run for very long). Compilers do not code as well as a trained human can (this will probably always be true - on the other hand, compilers do their work faster than humans, and this will also continue to be true.) Any non-trivial piece of work can be improved on with the addition of more work and attention (the more complex the problem or system, the more that can be gained by additional attention). >In most cases, I do not need run-time profiling; I know my algorithms. Profiling often turns up surprises. One graphics application looked to be I/O bound. Profiling showed that significant time was being spent converting bitmaps. An algorithmic change yielded a factor of ten speed improvement. Since no similar improvement could be made with the addition of assembler, none was added (it was tried, but it didn't help that much, was a lot of work to finish since there were so many possible high-use paths, and it made the application non-portable). I've also used profiling for interactive programs to reduce the time to respond to the user. It turned out that the program was performing a floating point calculation that could be precomputed into a small table which could compiled into the program. It just wasn't known how slow the floating point was on the machine in question. >What is there to know? I have not seen a computer instruction set where >the user instructions >are anywhere near as complicated as Fortran or C. The VAX instruction set is pretty complex. There are 16 registers, some have various dedicated purposes (stack, frame, temporaries for bcopy, etc.). There are lots of addressing modes. There are simply lots of instructions, and one needs to know many of them. Then you have to learn the local syscalls... Fortunately, UNIX tends to be pretty good here. Most OS's are pretty complex. Try opening a file under VMS... It can be hard, especially for a novice, to get started. Fortran and C are pretty complex, but one doesn't need to know that much to get started. Further, there are structures that allow readable representations, which allows the user to write maintainable code (it doesn't mean he'll do it, but at least he can). Of course, then there's portability. How long will your current machine last? How long do you want to use your program? Chances are, by the time you upgrade your machine, you'll have forgotten how your program worked. Of course, you could just buy a CDC 6600 and hang onto it for a quarter century. Then you could just retire. >BTW, I find the IEEE standard frequently a pain; I would prefer >the option of having unnormalized floating point when I want it. Not all machines give you this capability. One architecture i worked with recently had entries for many instructions stating that if you somehow managed to feed this instruction an unnormalized value that it would either produce an incorrect result or a floating point exception. Given that all floating point instructions produced normalized results on this machine, it was hard to imagine how you'd get into a such a situation. There are apparently good reasons for hardware types to restrict the use of the hardware. Most of them are probably speed and cost. The main problem that i've had with the IEEE standard is that it specifies more precision than my home computer really had the power to support. That's changed. I bought a faster computer. My C64 died... and a good thing too - i'd still be in the dark ages. >I am not saying that these HLLs may not save time. I use them myself. But >they are not adequate. They are not complete. They do not have the ability >to accommodate simple extensions. I have yet to see a C compiler without hooks to allow assembly language access. Some have in-line capability. Some have function call and separate compilation capability. Some have both. Most Fortrans, and even COBOLs i've seen have similar capability. I don't see a problem with this. I assume you aren't talking about interpreted BASIC... What i'd like to see in language support is more extensive libraries. UNIX comes with all sort of neat libraries for C. People have had various Fortran libraries for a long time. Yet, i still constantly write and rewrite time/date parsing functions, misc database-like routines, etc. With a rich library of code and proper documentation, even assembler can be reasonable to deal with. Of course, now we're getting way off the beaten comp.arch track... Stephen.