kurt@tc.fluke.COM (Kurt Guntheroth) (08/07/87)
I agree. The best optimizing compilers are now better than the best human-coded assembly language for program more than a few hundred lines long. We should be spending our collective time writing better compilers rather than recoding in assembler. By the way, the best compilers are better than humans now because they do things to the code that are considered bad style for a human-maintainable assembler source, like reusing the same storage location for different variables, storing the same quantity in different locations/registers during the program run, moving code around, etc. By the way, it is hard to optimize c very highly because of things like pointers and lax type checking. In principle, the best-possible object code from a pascal program will be tighter than the best-possible object code from a c program doing the same thing. The tricks c uses to permit a relatively crummy compiler to produce decent code hobble a really good compiler. And now an anecdote. I once worked for a small computer manufacturer you've never heard of. We had a sales rep in California who thought he was the hottest thing ever to invoke an assembler. He had a customer who neeeded a large hierarchical database sorted every day. Unfortunate thing was, the sort took about 30 hours to crunch the day's data. This guy used an undocumented and difficult to use entry point to the operating system to permit him to code an in-memory sort in (sort of) microcode. He managed to get the sort down to 15 hours. During this time I was working on a standard sort for our new database. My bosses said "call this guy up, he knows everything about sorting." Well, to make a long story sort (uh, short), he was using an O(n squared) sort. In 2 weeks I coded a completely general purpose merge sort in the structured assembler that substituted for a programming language. I sorted this guy's database in about an hour and a half. So what's the big deal about assembler? Algorithms and tuning is where it's at. Kurt Guntheroth
doug@edge.UUCP (Doug Pardee) (08/12/87)
> The best optimizing compilers are now better than the best > human-coded assembly language for program more than a few hundred lines > long. I'm afraid this is a statement which has nothing to back it up. It's easy to say things like this, but it is like the current fad of rating computers via a single figure like MIPS. There is no one "best" language and no one "best" compiler, not even if we limit ourselves to one specific area of appication. The choice of programming language is always one of compromise. Also, I'm getting weary of hearing tales of how "there exists somewhere" a fancy-shmancy compiler that is better than assembler, and therefore we should code in that compiler's language even though that compiler isn't available to us and we're stuck with using some terribly inefficient compiler like PCC. "Optimization by association", perhaps? [To be fair, the posting that I'm quoting made no such comment.] > the best compilers are > better than humans now because they do things to the code that are > considered bad style for a human-maintainable assembler source, like reusing > the same storage location for different variables, storing the same quantity > in different locations/registers during the program run, moving code around, True, but even if you happen to have such a compiler available to you, those optimizations are peanuts compared with what a good assembly implementation can often achieve. Sometimes an application is not a perfect fit for any available high level language. The result is that the code is "made to fit" some available language, and that usually sends efficiency down the drain. An example might make it clearer: suppose you're programming an application which does a lot of string processing, and the languages you have available are C and FORTRAN. Neither C nor FORTRAN provide any way for you to access whatever string-processing instructions are built into your computer; you end up either manhandling each byte or calling numerous subroutines. > By the way, it is hard to optimize c very highly because of things like > pointers and lax type checking. In principle, the best-possible object code > from a pascal program will be tighter than the best-possible object code > from a c program doing the same thing. The tricks c uses to permit a > relatively crummy compiler to produce decent code hobble a really good > compiler. Right on! But this is also one of the significant reasons for the higher efficiency of assembly code: the assembly programmer knows precisely (it says here) what the aliasing effects of pointer usage will be, which is something that he would have to somehow communicate to a compiler. > [story of bad sort algorithm recoded in assembler doubling the speed, but > being beaten another tenfold by a good sort algorithm coded in assembler]. > So what's the big deal about assembler? Algorithms and tuning is > where it's at. I absolutely agree, algorithms are critically important. A mediocre implementation of a good algorithm is almost always going to beat a good implementation of a mediocre algorithm. But seriously, does it happen very often that time pressures force you to being implementation while you're still turning up even better algorithms? I've had it happen a couple of times, but usually I reach a limit, where I've found the most effective algorithm that I'm likely to find. Bad algorithm choices stem from programmer laziness, not time shortage. Besides, it just isn't true that assembly language programming takes a lot longer than high level language programming. Sure, for someone who doesn't *know* assembler it does :-) And for those applications which are a "natural" for an available high-level language. But for many applications it's just as quick or even quicker to code in assembly language. If the only tool you know how to use is a hammer, everything looks like a nail. But it takes a lot of hammer bashing to drive a screw into a piece of wood. Getting a bigger and more effective hammer helps, but it still isn't as quick (and clean) as using a screwdriver. [Which isn't to say you should use a screwdriver to pound nails...] -- Doug Pardee, Edge Computer Corp; ihnp4!mot!edge!doug, seismo!ism780c!edge!doug
ken@argus.UUCP (08/18/87)
In article <900@edge.UUCP>, doug@edge.UUCP (Doug Pardee) writes: > which does a lot of string processing, and the languages you have available > are C and FORTRAN. Neither C nor FORTRAN provide any way for you to access > whatever string-processing instructions are built into your computer; you > end up either manhandling each byte or calling numerous subroutines. Try to pick a language that is more suitable to string processing. REXX and SNOBOL for example (personal preference is REXX). Kenneth Ng: Post office: NJIT - CCCC, Newark New Jersey 07102 uucp !ihnp4!allegra!bellcore!argus!ken *** NOT ken@bellcore.uucp *** bitnet(prefered) ken@orion.bitnet