Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!think!yale!cmcl2!lanl!lambda!jlg From: jlg@lambda.UUCP (Jim Giles) Newsgroups: comp.lang.misc Subject: Re: JLG's flogging of horses (was Re: Relationship between C and C++) Message-ID: <14329@lambda.UUCP> Date: 10 Apr 90 23:44:26 GMT References: Lines: 25 From article , by peter@ficc.uu.net (Peter da Silva): > [...] > Better to write your code portably and take a small performance hit, so you can > go to a new machine tomorrow and quadruple your speed. That mightn't be very > satisfying for manic crystalography freaks, but it pays the bills. Finally! Something I can, in general, agree with. My own opinion is that code should be written in an abstract language and the implementation language only chosen after consideration of the aims of software and the nature of the algorithm. A subset of the implementation language should be chosen which is as portable as possible and you should stick to that subset until the time comes to meet performance requirements. NOW - is the time to consider non-portable features (and only if you carefully document the use and make it clear how to port it). However, to pretend that sophisticated users _don't_ ever do this last step is silly. Perhaps _most_ of the programmer-time spent on large scientific code consists of this last category. Either optimizing on a new system or converting from the old one (two processes which overlap so much as to be seen as one) occupies a _lot_ of time in scientific computing. No surprise, few other computer uses run for multiple days (weeks) - and the people who pay for the computer time for such runs are quite eager to shave 2% here and 3% there. J. Giles