"PBACAD::M_PAPRZYCKI"@UTPB.PB.UTEXAS.EDU (02/06/91)
In one of the recently received messages I found he following passage: The first point I would make is that `efficiency' is very much less important to me than coding clarity. I am quite prepared to sacrifice half my CPU time if it makes the code easier to maintain. I probably have a idea, what Steven is talking about, however I am not sure if this strong a statement is an appropriate one. It seems to me that nobody wants to do anything in parallel if his/hers problem does not require A LOT of time, or cen be an important part of the problem, which itself requires A LOT of time, or ..... These are simple lessons that follow from Amdahls Law, and as far as I remember are known under the name: Amdahl's Effect. Even more general, parallelization MAKES SENSE only for really LARGE problems. If this is the case, then I really have problems with simple claims like: I can sacrifice half of my CPU time, to make my code looking nice. I would like to see when you try to tell this to somebody, who is running an application that takes about 12 hours to complete. I do not believe that such a person will be happy with the message: "I could have run your program in 3 hours, but I wanted your program to look beautifully, so it requires 6 hours." Summary: One should be very cautious in deciding what one wants to sacrifice. Marcin
barmar@think.com (Barry Margolin) (02/07/91)
In article <12935@hubcap.clemson.edu> "PBACAD::M_PAPRZYCKI"@UTPB.PB.UTEXAS.EDU writes: >In one of the recently received messages I found he following passage: > The first point I would make is that `efficiency' is very much less > important to me than coding clarity. I am quite prepared to sacrifice > half my CPU time if it makes the code easier to maintain. ... >"I could have run your program in 3 hours, but I wanted your program >to look beautifully, so it requires 6 hours." >Summary: > One should be very cautious in deciding what one wants to > sacrifice. How about: "I could have run your program in 3 hours, but it would have taken me an extra month of programming and debugging, and it would have added time to the development of future enhancements, so it requires 6 hours." Program clarity is not just an esthetic quality, it directly affects programmer productivity. Of course, in the supercomputer business, the location of the line between fast enough and too slow is different from the regular computer industry. However, even a supercomputer program merely has to be significantly faster than a comparable program on a conventional computer. So, if the program would have taken days to run on a conventional computer, the difference between 6 hours and 3 hours may not be significant. Squeezing every last microsecond is most often necessary when similar machines or programs are competing. For instance, it's important for us to have a faster FFT than our competitors, because potential customers can compare them head-to-head. But if we have a capability that our competitors lack, its precise speed isn't as important; customers will make decisions simply based on the usefulness of the feature. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
john%ghostwheel.unm.edu@ariel.unm.edu (John Prentice) (02/08/91)
[Editted for length.] In article <12971@hubcap.clemson.edu> think!barmar@think.com (Barry Margolin) writes: >In article <12935@hubcap.clemson.edu> "PBACAD::M_PAPRZYCKI"@UTPB.PB.UTEXAS.EDU writes: >> The first point I would make is that `efficiency' is very much less >> important to me than coding clarity. I am quite prepared to sacrifice >> half my CPU time if it makes the code easier to maintain. > >How about: "I could have run your program in 3 hours,....so it requires 6 >hours." Program clarity is not just an esthetic quality, it directly >affects programmer productivity. I would tend to think this question of balancing speed against clarity is a rather obvious one. Common sense tells you pretty much whether you need speed at the expense of clarity, etc... What is there to argue about? For the applications we work on for example, our serial codes take hundreds of hours of Cray Y-MP time for each calculation. It is well worth our time to convert them. We have other codes that take hours of Cray time, but it is not worth it to us to convert them to parallel systems because that takes time and these codes aren't worth it in terms of their cost to run. Our experience has been, if you need speed bad enough to consider porting to ANY supercomputer (and in particular parallel ones), you know about it! The choice is obvious in such cases. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) (02/09/91)
Even in the supercomputer biz, there is much to be said for putting rapid development and maintainability ahead of raw performance for many applications. Some of my colleagues in the where-do-I-drill biz use APL as a modelling tool for seismic and signal processing. APL offers significant aid in understanding algorithms, and has more inherent parallelism than you can shake a stick at. They would get a peachy APL model of something, and then decide to run it against a small real dataset, say around 13 giganumbers. Swell. Let's wait 6 months until a Cray Fortran guru becomes available, and until we have a week or so explain what this APL stuff does, and how that would work in Fortran. THEN, we can run the model on the real data on the Cray. We took a different approach -- we wrote a very quick and dirty APL to C compiler, which, in spite of the crummy quality of code it produced for the Cray (This was PCC - the new one is reputed to be lots better), ran only a few times slower than the best Fortran code they had produced in the shop. Furthermore, they could run the models the same day, rather than 6 months later. Now, do you think they cared about a factor of two delay, compared to a 6 month delay? Also, maintainability issues come back to haunt when you want to enhance code -- really tweaked code is HARD to enhance unless you take as much care in keeping it maintainable as you would if that was your primary goal. It might also reduce portability -- runs fine on the Cray, sucks on the Connection Machine. Apologies for the length of this sermon/tirade. Bob Bernecky Snake Island Research Inc.