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.