From 703708114190820834 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,109af18a94b8a35c X-Google-Attributes: gid109fba,public X-Google-Thread: f78e5,e5cae9ffbf1dd57e X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-10-13 02:41:52 PST Xref: sparky comp.std.c++:1376 comp.lang.c++:14918 Path: sparky!uunet!mcsun!uknet!stl!bnrgate!bcrka451!bcrki65!sjm From: sjm@bcrki65.bnr.ca (Stuart MacMartin) Newsgroups: comp.std.c++,comp.lang.c++ Subject: Re: The concept of templates considered ill designed Message-ID: <1992Oct13.143129.20733@bcrka451.bnr.ca> Date: 13 Oct 92 14:31:29 GMT References: <1992Oct7.170351.16316@genghis.borland.com> <1992Oct11.133704.5600@ucc.su.OZ.AU> Sender: 5E00 Corkstown News Server Organization: Bell-Northern Research Ltd., Ottawa, Canada Lines: 37 In article <1992Oct11.133704.5600@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes: >In article osoelgaultier+@CMU.EDU (Stefan Monnier) writes: >> >>Every advance in languages has been associated with an increased overhead: >>from assembler to C, from C to C++: every time you switch to a higher level >>language you lose some speed. >> > > Not true! (Many examples provided) Some additional points: 1. I have seen assembler code that was written because the routine was expected to be time critical. The code looked good on the surface, but saved all registers at the start and restored them all at the end. This used up so much time that an equivalent routine I wrote in FORTRAN ran 20% faster without even using any optimization options on the compiler. 2. RISC processors exacerbate this problem of writing efficient code. It really is true that the compiler may know how to handle most programming constructs better than you do. 3. Advances in languages allow us to use more appropriate data structures and algorithms for the same amount of development time. For this reason, the program written in the higher level language using those advances in languages is sometimes orders of magnitude faster than the one written in the lower level language. 4. Sometimes speed is not as much an issue as being able to write the functionality in the first place. Stuart -- : Stuart MacMartin email: sjm@bnr.ca : : Bell-Northern Research phone: (613) 763-5625 : : PO Box 3511, Stn C, Ottawa, K1Y-4H7, CANADA Standard disclaimers apply. :