Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #111935

Re: C speed

Show all headers | View raw

On Saturday, June 10, 2017 at 12:09:48 PM UTC-5, David Brown wrote:
> On 10/06/17 01:21, supercat wrote:
> >      void test(double arr1[], double arr2[], double scale)
> >      {
> >        for (int i=0; i<1000; i++)
> >          arr1[i] = arr2[i] * scale;
> >      }
> The compiler /does/ know that arr1 and arr2 point to the start of arrays 
> of at least 1000 elements.  If they did not do so, the rest of the code 
> would be undefined behaviour - and the compiler knows you did not write 
> undefined behaviour.

How does it know that, exactly?  The declaration is equivalent to:

     void test(double *arr1, double *arr2, double scale)

and the pointers are allowed to point at arbitrary locations within any
array of doubles large enough to have 1000 accessible items at and beyond
the indicated addresses.
 
> This is a fine example of the advantages of C's undefined behaviour concept.

It may be a fine example of something, but I'm not sure I'd call it any kind
of "advantage".  If any compiler writer would optimize on the basis of it
having undefined behavior, I'd say it's an example of why C should have
an explicit syntax to indicate that something is the start of an array.
While most such functions would not typically be used to duplicate a growing
pattern, nothing in the Standard would prohibit the function as written from
being used for that purpose.

> (And you can use "restrict" if you want to tell the compiler that they 
> are independent arrays.)

That would require what would generally be needless code duplication to
handle the situation where code needs to scale an array "in place".  While there may be some systems where a loop using the same source and destination
pointer could be faster than one using separate pointers to the same object,
on many systems the same machine code should be usable for both purposes.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: C speed "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-09 18:58 -0400
  Re: C speed supercat@casperkitty.com - 2017-06-09 16:21 -0700
    Re: C speed David Brown <david.brown@hesbynett.no> - 2017-06-10 19:09 +0200
      Re: C speed supercat@casperkitty.com - 2017-06-10 12:37 -0700
        Re: C speed David Brown <david.brown@hesbynett.no> - 2017-06-11 21:47 +0200
          Re: C speed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-11 21:23 +0100
            Re: C speed supercat@casperkitty.com - 2017-06-11 13:33 -0700
              Re: C speed Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-11 23:47 +0100
            Re: C speed David Brown <david.brown@hesbynett.no> - 2017-06-12 09:12 +0200
          Re: C speed supercat@casperkitty.com - 2017-06-11 13:30 -0700
            Re: C speed David Brown <david.brown@hesbynett.no> - 2017-06-12 09:15 +0200
              Re: C speed supercat@casperkitty.com - 2017-06-12 07:14 -0700

csiph-web