Path: utzoo!attcan!uunet!husc6!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth From: firth@sei.cmu.edu (Robert Firth) Newsgroups: comp.lang.c Subject: Re: Unnecessary Macros (was Re: Unn Message-ID: <7191@aw.sei.cmu.edu> Date: 28 Sep 88 16:33:26 GMT References: <70279@sun.uucp> <225800075@uxe.cso.uiuc.edu> Sender: netnews@sei.cmu.edu Reply-To: firth@bd.sei.cmu.edu (Robert Firth) Organization: Carnegie-Mellon University, SEI, Pgh, Pa Lines: 39 In article <23@datcon.UUCP> sar@datcon.co.uk (Simon A Reap) writes: [ suggesting the form z = square(x) + square(y)] >Maybe I'm missing the point, but why does a good old fashion function seem >to be out of the question. In article <225800075@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: >I certainly hope you aren't a programmer. The answer is blatently >obvious: calling overhead. Why in the would would anyone ever even >consider writing a function call to perform a single multiplication? This prompted me to collect some data. The machine is a MicroVax II running Ultrix, and the times are user time. (a) time for a simple inline single-precision multiplication of a static variable, ie "x := x*x": 5.74 usec (b) time for a simple call to an Assembler code "square" routine, with single-precision operands, operation, and result: 11.23 usec So the overhead is about 100%. Pretty bad. But how about this? (c) time for a simple inline 'C' multiplication with single-precision operands and result, but a double-precision operation 11.50 usec The question is, why would anyone ever even consider writing a function call? Answer: it is not only safer than the C code, it's faster. Unless you're lucky enough to have a newer compiler that junks the bogus floating point semantics.