makela@tukki.jyu.fi (Otto J. Makela) (04/30/89)
In article <2333@rpi.edu>, fargo@pawl.rpi.edu (Irwin M. Fargo) says: |[...] C programs are NEVER going to run faster than Assembler |programs on the SAME machine. I am all for portability, but fast portability. |In my opinion, as software techniques become more and more refined, we will |be able to create more powerful optimizing compilers for less money. I can |envision a day (a day quite some time away) when a compiler will be able to |create compiled code that runs only marginally slower than the same Assembler |program. If anything, I feel THAT is something we should shoot for. If we |can reach that goal, then the trade-off between portability and speed will |become almost unnecessary. | |Thank you and happy hunting! Actually: Ethan M. Young | ____ [| SB <] "Travel IS life" Internet: fargo@pawl.rpi.edu | /__ -=|??<=- - Irwin M. Fargo Bitnet (??): usergac0@rpitsmts.bitnet |/ ARGO : 3000 years of regression from the year 4990 Just a comment on the claim that C programs are never going to run faster than the same programs written in assembler... This is true, in principle. However, the clou is the phrase "same program". Most of the time the assembler programmer does things in a more straightforward way, making for simpler algorithms (I know, I'm one...). Things like DOS's lack of buffering etc. can cause severe problems. Examples from DOS: * SORT is veeery slow. A C-written program which uses the C library's built- in buffering can easily be 2-3 times faster than the original * actually, anything that reads from stdin and writes to stdout (which are then redirected) can be made a lot faster with added buffering * the speed of reading from a file to a buffer can differ drastically depending if the file position and the buffer have the same parity, ie. if the file position and buffer are both even/odd or if they are not The point I'm trying to make here is that portability is not the only reason to program in a high-level language. The ready-made libraries, the more complex control and data structures make life easier for the programmer. It is of course possible to make very fast programs in assembler, but it does require lots of effort and special expertise (for example, are you aware that optimizing multiply operations to shifts can be SLOWER on 8088-based machines since the 8088 is so bus-bound ?). The motto is: "No Pain, No Gain." Most of the programs I write are written in C, with speed critical and system dependent parts done in assembler. The C package I use includes a very good interface macro package for calling assembler from C and vice versa. This would seem to be the ideal solution while waiting for the optimal C compiler... Sorry for the long-windedness. As this has nothing to do with ibm.pc, I'm directing the followups to comp.lang.misc -- too bad there is no talk.programming :-) ... Otto J. Makela (with poetic license to kill), University of Jyvaskyla InterNet: makela@tukki.jyu.fi, BitNet: MAKELA_OTTO_@FINJYU.BITNET BBS: +358 41 211 562 (V.22bis/V.22/V.21, 24h/d), Phone: +358 41 613 847 Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE
boyne@hplvli.HP.COM (Art Boyne) (05/03/89)
davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) writes: > Having coded some fairly large (20-100k line) programs in >various languages, assembler isn't going to make a big difference in >speed or size over a reasonable C (or other) compiler. With a good >algorithm for the job you should see less than 2:1 in speed and 20% in >size (based on recoding a few critical routines). Wouldn't it be nice if this were really true for all of us. I work in the Motorola 68000 world, not the Intel 80x86 world, and I have yet to see a C compiler that I can't beat 2:1 in total code size and up to 8:1 in speed in tight loops when coding in assembler. I just finished recoding about 2200 lines of C into about 2400 lines of assembler, and these were the numbers I got. This was for an IEEE-488.2-conformant GPIB driver. If you ask me why I rewrote it - because I had performance goals 4x what the C compiler would give me. Art Boyne, boyne@hplvla.hp.com
wolfordj@ihlpy.ATT.COM (452is-Wolford) (05/05/89)
From article <360013@hplvli.HP.COM>, by boyne@hplvli.HP.COM (Art Boyne): > davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr) writes: >> Having coded some fairly large (20-100k line) programs in I think you better look again. What C compiler are you using, sounds better than anything I have ever seen or herd of or you need to look at your assembly language skills. > > Wouldn't it be nice if this were really true for all of us. I work > in the Motorola 68000 world, not the Intel 80x86 world, and I have > yet to see a C compiler that I can't beat 2:1 in total code size and up > to 8:1 in speed in tight loops when coding in assembler. I just finished >..... > > Art Boyne, boyne@hplvla.hp.com Totally agree. Many times I write a program in C or PASCAL and then run a performance analyzer on it and then write several of the critical routines in assembly. I get a good 2:1 (atleast if not more) code size reduction and many times > 10 times the performance. I have System V C, Green Hills C, BSD C, Micro Soft C, Turbo C, MANX's AZTEC C,... BSD "pc" compiler and Turbo PASCAL. But then I started programing in "assembly". I know Z80, VAX ASM, 3B2 ASM, 8080/8085, 8086, 80186, 80286 assembly, all of these I can make "smoke" a "C" compiler performance. Don't get me wrong I like to work in "C", and it is the language of choice when I want to write a program to run on several diff. computers, but it does not take much effort to partial compile a few of the critical routines and then modify the insides. Jeff Wolford att!iwsag!jww att!ihlpa!wolfordj harvard-+ | ucbvax--+---- att --+ iwsag!jww | decvax--+
todd@stiatl.UUCP (Todd Merriman) (05/05/89)
>If you ask me why I rewrote it - because I had performance >goals 4x what the C compiler would give me. > Speed is almost never the *only* criteria in the choice of languages. ...!gatech!stiatl!todd Todd Merriman * 404-377-TOFU * Atlanta, GA
waynec@hpnmdla.HP.COM (Wayne Cannon) (05/13/89)
Re: Optimizing Compilers vs Assembly Programming for Performance As long as C has been around, it is still in its youth when it comes to optimization. I was really disappointed in the sloppy code (both speed and space) generated by the C compilers from several UNIXs (UNICES?) and DOS (pre MS C 5.0) only three years ago compared with a locally written compiler for a non-standard ALGOL-like language. Now that C has become an almost universally used language and not just a language for UNIX hackers and students, companies are willing to invest real resources into optimizing compilers for C. Until just a few years ago, most C compilers were designed for portability (or simply ported from portable C compilers!), not efficiency. FORTRAN is one of a very few languages with truly excellent optimizing compilers. A good optimizing compiler can beat assembly programming, and it has been shown in several challenges between programmers -- one of which was written up several years back regarding a challenge sponsored by some folks at IBM. Numerous experienced FORTRAN and assembly programmers were given the same problem to solve. The FORTRAN programmers beat the assembly programmers every time in terms of execution speed. However, given the code generated by the FORTRAN compiler, the assembly programmers were able to improve upon the code by about 10%. The examination of the differences indicated that the high-level programmers' were able to concentrate more on algorithmic efficiencies at every implementation level and were not as distracted by implementation details as the assembly language programmers. Many assembly programmers challenge this and invoke incantations of initial PDL designs, macro-packages, and subroutine re-use which simply goes to make my point (they are simply lifting themselves up toward high-level language programming by doing so). The best programmers use all the tools they have to do the best job, including assembly language reprogramming of critical sections of code if other factors permit. I am not sure that optimization in today's C compilers are yet up to the level that FORTRAN attained, but I am convinced that we will be there again soon.
mcdonald@uxe.cso.uiuc.edu (05/15/89)
>I am not sure that optimization in today's C compilers are yet up >to the level that FORTRAN attained, but I am convinced that we >will be there again soon. I would not be so sure. In fact, it is almost certainly impossible. The presence of pointers in C and the lack of prohibition on overlapping array subsection function arguments prevent certain optimizations that are standard in Fortran. Doug McDonald
phil@ux1.cso.uiuc.edu (05/16/89)
> portable C compilers!), not efficiency. FORTRAN is one of a very > few languages with truly excellent optimizing compilers. > > A good optimizing compiler can beat assembly programming, and it > has been shown in several challenges between programmers -- one > of which was written up several years back regarding a challenge > sponsored by some folks at IBM. Numerous experienced FORTRAN and > assembly programmers were given the same problem to solve. The > FORTRAN programmers beat the assembly programmers every time in > terms of execution speed. However, given the code generated by > the FORTRAN compiler, the assembly programmers were able to > improve upon the code by about 10%. This sounds like a case of bad assembler programmers. There are lots of them around. In fact MOST programmers are probably bad assembler programmers. If the programmer wrote slower code the first time then improved it upon seeing the compiler code, then there must be something wrong. Actually I was in a similar situation when writing a Mandelbrot program on an IBM 370 mainframe. I compiled the program with the maximum optimization, yet found absolutely pathetic code generated for the main iterative loop. I recoded in assembler and got several times speedup. I did all the calculations in registers, whereas the compiler had at least two cases of storing a number and loading it back again INTO THE SAME REGISTER and it didn't even need the number again. The optimization could have been a whole lot better. I have heard that VAX/VMS Fortran is well optimized but have no way to verify that myself. I do agree with the idea of writing the main structure of a program in a high level language, and putting the heavy duty computation parts, or the sneaky system access parts, in assembler. I also consider it important to highly document the interface between these parts so that if the program is ported to another machine type, there is a reasonable chance to implement the assembler parts on the other machine as well. > The examination of the differences indicated that the high-level > programmers' were able to concentrate more on algorithmic > efficiencies at every implementation level and were not as > distracted by implementation details as the assembly language > programmers. Many assembly programmers challenge this and invoke > incantations of initial PDL designs, macro-packages, and > subroutine re-use which simply goes to make my point (they are > simply lifting themselves up toward high-level language > programming by doing so). The best programmers use all the tools > they have to do the best job, including assembly language > reprogramming of critical sections of code if other factors > permit. That depends on how much assembler program one has done. On the PC this will be the case for me for a while still. On the IBM 370 mainframe, the implementation details are trivial for me, as I have written well over 2000 programs or general purpose subroutines entirely in assembler. --phil
boyne@hplvli.HP.COM (Art Boyne) (05/17/89)
phil@ux1.cso.uiuc.edu writes: > (uncredited) >> portable C compilers!), not efficiency. FORTRAN is one of a very >> few languages with truly excellent optimizing compilers. Years ago, the guy at Purdue University who supported all the compilers and assembler (all written in assembler!) for the main computer center told me that the CDC 6000 series FTN compiler with maximum optimization would produce only about 10-20% more code than a GOOD assembly language programmer - this was considered excellent. I have yet to see a C compiler match this. >> A good optimizing compiler can beat assembly programming, and it >> has been shown in several challenges between programmers -- one >> of which was written up several years back regarding a challenge ^^^^^^^^^^^^^ About the time when certain companies had TV ads claiming to train you as a programmer in 60 days ?? :-) >> sponsored by some folks at IBM. Numerous experienced FORTRAN and >> assembly programmers were given the same problem to solve. The >> FORTRAN programmers beat the assembly programmers every time in >> terms of execution speed. However, given the code generated by >> the FORTRAN compiler, the assembly programmers were able to >> improve upon the code by about 10%. > >This sounds like a case of bad assembler programmers. There are lots of >them around. In fact MOST programmers are probably bad assembler programmers. I have to agree: most programmers *are* bad assembler programmers, probably, especially these days, due to lack of experience - when was the last time *you* wrote more than a couple hundred lines of assembler. Also, it seems to take a different mind set to efficiently program in assembler compared to high level languages. Looking at the code produced by students, professors, and colleagues over the last 19 years leaves me convinced that few people can really think well in assembler. One thing in defense of the compilers though: we humans tend to miss some tricks from time to time. Compilers, once programmed to look for them, do them *every* time. Art Boyne, boyne@hplvla.hp.com
bcw@rti.UUCP (Bruce Wright) (05/18/89)
In article <360014@hplvli.HP.COM>, boyne@hplvli.HP.COM (Art Boyne) writes: > phil@ux1.cso.uiuc.edu writes: > > Years ago, the guy at Purdue University who supported all the compilers > and assembler (all written in assembler!) for the main computer center > told me that the CDC 6000 series FTN compiler with maximum optimization > would produce only about 10-20% more code than a GOOD assembly language > programmer - this was considered excellent. I have yet to see a C > compiler match this. Ah, memories of undergraduate days using FTN on a CDC 6600.... a really great machine in its day .... but I digress. The CDC 6000 series had a rather strange architecture - in some ways somewhat RISC-like (plus ca change, plus c'est la meme chose). Each word was 60 bits, and instructions could be 15 or 30 bits but could not cross a word boundary. One of the compiler's main problems would be re-arranging code to fill each 60-bit word completely to avoid having to insert PASS (no-operation) instructions (a problem similar to the delayed branch problem on many RISC machines). Programming the 6000 in assembler would be possible but somewhat disorienting for most assembler programmers. Bruce C. Wright
boyne@hplvli.HP.COM (Art Boyne) (05/19/89)
bcw@rti.UUCP (Bruce Wright) writes: >The CDC 6000 series had a rather strange architecture - in some ways >somewhat RISC-like (plus ca change, plus c'est la meme chose). Each >word was 60 bits, and instructions could be 15 or 30 bits but could not ^^^^^^^^ XJ (exchange jump) was a 60-bit instruction. >cross a word boundary. One of the compiler's main problems would be >re-arranging code to fill each 60-bit word completely to avoid having >to insert PASS (no-operation) instructions (a problem similar to the ^^^^ Actually, the opcode was NO & was called a no-op or pass instruction. >delayed branch problem on many RISC machines). Programming the 6000 >in assembler would be possible but somewhat disorienting for most >assembler programmers. You forgot to mention that instructions on the CDC 6000 series had different execution times depending on which part of the 60-bit word they were in. This was because prefetch occurred in the middle of the 60-bit word. Branch instructions were best stored in the upper 30 bits to avoid the prefetch. I did systems programming for the Purdue University Computing Center while I was a student there, supporting a localized version of the CDC Algol compiler (written in assembler), among other things. Graded the assembly language class, too - while I was taking it, what a kick! The professor stopped competing with me on code size & execution time halfway through the semester. Art Boyne, boyne@hplvla.hp.com
gph@hpsemc.HP.COM (Paul Houtz) (05/20/89)
I think the original point of this posting was someone trying to put forward the rediculous idea that you should use assembler instead of a high level language? Sort of like using a spoon to cultivate a cornfield. Look. Code size reductions are becoming less and less important anywhere on computers. 99% of all computer code is not performance bottlenecked. If you decide to use assembler for all your coding becuase it is faster, it's like buying a Farrari 308 GTS so that you can get your speed up to 120 MPH between stoplights on the El Camino Real. You just aren't going to get where you are going ANY faster. Use a high level language and write good, straightforward code, and don't worry so much about performance. Then, analyze the code at run-time, and figure out where the bottle necks are. You can then really leverage a small amount of time re-coding those bottle necks in assembler, if necessary. Does it make sense to code a routine in assembler so that it runs blindingly fast, if all it does is block on a terminal I/O operation?
boyne@hplvli.HP.COM (Art Boyne) (05/22/89)
gph@hpsemc.HP.COM (Paul Houtz) writes: >I think the original point of this posting was someone trying to put forward >the ridiculous idea that you should use assembler instead of a high level >language? > > Sort of like using a spoon to cultivate a cornfield. > > Look. Code size reductions are becoming less and less important anywhere > on computers. Ah, I can see that multi-megabyte HP-PA machines have spoiled you forever. Have you no sympathy for those of us who still use 8051's with 256 bytes of RAM and 4K of ROM? > 99% of all computer code is not performance bottlenecked. Well, probably 90+%, anyway. But I'm the guy they assign the other 10-% to, because I *do* know how to use assembly code effectively, and most other programmers prefer not to get their hands dirty. > Use a high level language and write good, straightforward code, and don't > worry so much about performance. Obviously the attitude too many OS people have taken on too many systems. Anyway, try telling that to my boss who set performance goals for me. > Then, analyze the code at run-time, and figure out where the bottle necks > are. You can then really leverage a small amount of time re-coding those > bottle necks in assembler, if necessary. True. > Does it make sense to code a routine in assembler so that it runs blindingly > fast, if all it does is block on a terminal I/O operation? Sometimes *YES*!!! For a real-life example: integrating voltmeters are typically slow. One could argue "Why put a lot of effort into GP-IB performance when the voltmeter will take many milliseconds to take a reading?" Reason: because GP-IB bandwidth is a shared resource between many instruments, and performance-conscious users want to maximize throughput by sending groups of commands quickly to many instruments, then letting them parse/execute in parallel. A slow handshaker on the GP-IB slows the whole test system down. Besides, who says that there is a terminal out there on the end of that line you are talking about. Perhaps there is a PC wanting to talk long distance at 9600+ baud. You slow him down and you are costing him real $$. Art Boyne, boyne@hplvla.hp.com
rick@NRC.COM (Rick Wagner) (05/23/89)
In article <31672@sri-unix.SRI.COM> bcw@rti.UUCP (Bruce Wright) writes: >... Programming the 6000 >in assembler would be possible but somewhat disorienting for most >assembler programmers. > > Bruce C. Wright Yeah, but it was lots of fun; especially when you had to start taking into account the multi-processor (two F.P. divide units, two F.P. add units) starting with the 6600's, then the semi-vector design of the later Cyber 170's. I was able to beat FTN in writting a vector coded SQRT() function in assembly, but not by much. - Rick Wagner -- =============================================================================== Rick Wagner Network Research Corp. rick@nrc.com rick@nrcvax.UUCP 2380 North Rose Ave. (805) 485-2700 FAX: (805) 485-8204 Oxnard, CA 93030 Don't hate yourself in the morning, sleep 'till noon.
shapiro@rb-dc1.UUCP (Mike Shapiro) (05/23/89)
In article <2971@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes: ... Programming the [CDC] 6000 >in assembler would be possible but somewhat disorienting for most >assembler programmers. ... Ah, but it was fun for us doing all sorts of strange things on that machine. For example, at Purdue on educational leave from Bell Telephone Labs, I did much of the first port of SNOBOL4, from the IBM 360 to the CDC 6500. SNOBOL4 was written entirely in a "portable" assembly language. To implement it, I had to write many macros and runtime routines. (For credit, R. Stockton Gaines did some of the initial work.) [Reference: my chapter in Ralph Griswold's book on the macro implementation of SNOBOL4.] I also did "word processing" on it (before the phrase was invented) and even printed my dissertation on an electrostatic "dot matrix" printer, using a typesetting package I wrote on the CDC. Regarding assembler vs HLL, I have vague memories of professor Maury Halstead telling us in one of our classes of some early research (by the Navy at NEL, perhaps?) that made the breakpoint between assembler and higher level language (like Neliac or Jovial) at around 400 lines. Above that size, programmers of assembly language couldn't keep track of the program organization as well as a compiler and would tend to produce strung-out code. Does anybody have references to this type of research? As I recall, it was done in the early 1960s. -- Michael Shapiro, Encore Computer Corporation (formerly Gould/GSD) 15378 Avenue of Science, San Diego, CA 92128 (619)485-0910 UUCP: shapiro@rb-dc1
boyne@hplvli.HP.COM (Art Boyne) (05/24/89)
shapiro@rb-dc1.UUCP (Mike Shapiro) writes: >Ah, but it was fun for us doing all sorts of strange things on (the CDC) >machine. For example, at Purdue on educational leave from Bell >Telephone Labs, I did much of the first port of SNOBOL4, from the IBM >360 to the CDC 6500. SNOBOL4 was written entirely in a "portable" >assembly language. To implement it, I had to write many macros and >runtime routines. (For credit, R. Stockton Gaines did some of the >initial work.) [Reference: my chapter in Ralph Griswold's book on the >macro implementation of SNOBOL4.] Ah, yes. I remember it well from my Purdue days. Only recently did I finally throw away a source listing of that SNOBOL4 port, and I think I still have it on a 7-track CDC tape. If anyone wants to see a rather different language, look at SNOBOL4. It was part of one-semester class at Purdue, along with ALGOL-60. Art Boyne, boyne@hplvla.hp.com
las) (05/27/89)
In article <8090024@hpsemc.HP.COM> gph@hpsemc.HP.COM (Paul Houtz) writes: [Regarding the proposition that assembly language is always preferable to high-level language for reasons of efficiency] } Sort of like using a spoon to cultivate a cornfield. } 99% of all computer code is not performance bottlenecked. If you decide } to use assembler for all your coding becuase it is faster, it's like buying } a Farrari 308 GTS so that you can get your speed up to 120 MPH between } stoplights on the El Camino Real. You just aren't going to get where you } are going ANY faster. } Use a high level language and write good, straightforward code, and don't } worry so much about performance. } Then, analyze the code at run-time, and figure out where the bottle necks } are. You can then really leverage a small amount of time re-coding those } bottle necks in assembler, if necessary. Listen you! Let's not have anymore of these reasoned, sensible proposals. This is a religious issue to be persued with utmost ferocity. If there's not as much bloodletting in this group as there is in Beruit, we are not living our faith. And don't let me catch you employing any more disarming humor! Next thing you know, someone may adopt a conciliatory tone and then where will we be? If you can't say something cruel, offensive, self-serving, or at least, mean-spirited, then don't say it! regards, Larry -- Signed: Larry A. Shurr (cbema!las@att.ATT.COM or att!cbema!las) Clever signature, Wonderful wit, Outdo the others, Be a big hit! - Burma Shave (With apologies to the real thing. The above represents my views only.) (Please note my mailing address. Mail sent directly to cbnews doesn't make it.)