Path: utzoo!attcan!uunet!dg-rtp!dgcad!aeras!sun!newstop!sun-barr!decwrl!mips!sgi!karsh@trifolium.esd.sgi.com From: karsh@trifolium.esd.sgi.com (Bruce Karsh) Newsgroups: comp.arch Subject: Re: It looks like he's at it again! Message-ID: <63692@sgi.sgi.com> Date: 10 Jul 90 12:56:47 GMT References: <2328@l.cc.purdue.edu> <1990Jul10.072443.4844@cs.UAlberta.CA> Sender: karsh@trifolium.esd.sgi.com Reply-To: karsh@trifolium.sgi.com (Bruce Karsh) Distribution: comp.arch Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 99 In article <1990Jul10.072443.4844@cs.UAlberta.CA> cdshaw@cs.UAlberta.CA (Chris Shaw) writes: >The problem is, Herman, you're one of the very few people who are interested >in these well-known "reasonable instructions". Just because a subject isn't currently fashonable, doesn't mean it isn't important. In computer science, it's often the most important areas that are least fashonable. (Why is that?) >Anybody who gripes about the slowness of his machine, and who can afford to >spend the substantial amount of time it takes to tweak code for the last drop >of CPU power is dealing with programs that are pretty small. >Usually. Ah, the Computer Science Religion again. It's blasphemy to talk about using assembly code to speed up programs. The anger and the insults in the responses one receives when one suggests using assembler is really a phenomenon. Could it be that the anger and the name-calling is because the anti-assembly forces don't really have a good case - just a set of beliefs? Where's the evidence that "Anybody who gripes about the slowness of his machine and who can afford to spend the substantial amount of time it takes to tweak code is usually dealing with programs that are pretty small"? And even if they are small, so what. Small programs are important too. Another reason might be that it's economically important to make something run faster. If you can solve a computationally intense problem twice as fast, you may need only purchase half as many computers. Often it's reasonable to spend a day or two speeding up the critical parts of a program so that you don't have to buy more computers. A couple of days of programmer's time is expensive, but not as expensive as buying twice as many computers. Yet another reason might be that you want to sell the program to a very large market. Customers don't like to wait for answers. If you plan on selling a few hundred thousand copies of a program, it may be worth spending a couple of days to make the slow parts fast. You can use a few day's of programmers time or you can waste hundreds of thousands of end-user's time. Which makes more sense? >The basic problem with assembly coding by hand vs assembly coding by compiler >is that IT DOESN'T SCALE. There are extremely limited application areas where >coding by hand is much faster, and you, Herman, live in one. Perhaps they are extremely limited, but they are sometimes economically important. Some examples: Graphics Rendering Seismic Deconvolution Audio Signal Processing Business Record Sorting These are economically important application areas who's viability absolutely depends on getting as much speed out of the system as possible. >Just because you >have purple lenses on your glasses doesn't mean the world is purple. Just >because you can code for speed better than your compiler can doesn't mean >that more than a tiny minority "out there" can do the same. The number of programmers who can do it isn't what's important. What's important is the number of customers for the results of the work. If people prefer the faster systems enough to purchase them more than slower systems, then the optimization is worthwhile. (Provided that there's enough demand for the product to justify the extra couple of days of optimization)> >Plus assembler is a nightmare unless one of three things is true: > 1: The project is performed by 1 person. > 2: The project is small (less than 5000 lines) > 3: All modules adhere strictly to a call-return convention. >In other words, you can do it, but it's extremely hard work if you're building >something non-trivial. Anywhere up to 1000 lines of code is trivial. Sure it's hard work. But we're professionals and we're supposed to work hard if there's a benefit to doing so. >Besides you're still going to suff a drop in productivity vs HLL's. But let's not confuse programmer productivity vs end-user productivity. When I purchase a software product, I'm not impressed by the fact that the programmers didn't have to work hard to write it. I'm impressed if it enables me to accomplish my objectives efficiently. Often I think many programmers don't care at all how long things take. If you don't believe this, just watch a Unix workstation boot. Ten million instructions per second, and it still takes minutes to boot. >You brought up the example of computer chess recently. The fact of the matter >is that unless you are an international chess master, the program Deep Thought >will beat you. Why did I mention this? Well, the major reason Deep Thought >beats excellent chess people is because of its specialized hardware. The >program operates by a well-known brute force algorithm. My main point is that >Deep Thought would be useless if the program relied on some set of greasy >assembler tweaks on some two-bit general purpose CPU. Commercially viable chess programs rely on sets of greasy assembler tweaks on some eight bit general purpose CPU's. Bruce Karsh karsh@sgi.com