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


Groups > comp.lang.c > #111980

Re: C speed

From Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups comp.lang.c
Subject Re: C speed
Date 2017-06-11 21:23 +0100
Organization A noiseless patient Spider
Message-ID <87bmpue0jw.fsf@bsb.me.uk> (permalink)
References (1 earlier) <e1552280-01f0-b0d9-5c60-394e52acc035@verizon.net> <d0adc9cb-1b8d-4881-8db6-95474b2942a0@googlegroups.com> <ohh8tu$sbv$1@dont-email.me> <b1f00fa2-7ebd-484e-91bb-9c86457eefbf@googlegroups.com> <ohk6hu$j6g$1@dont-email.me>

Show all headers | View raw


David Brown <david.brown@hesbynett.no> writes:

> On 10/06/17 21:37, supercat@casperkitty.com wrote:
>> 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.
>
> Fair enough - it knows that the pointers point to the start of
> /subarrays/ of at least 1000 elements.  Does that make you feel
> better? The compiler can do the same kind of vectorisation.  Being a
> pointer to the /start/ of an array rather than some part in the middle
> of it makes no difference.

Is this always the case?  In languages were the compiler knows that the
pointer is to the start of an array (and this may be a pointer generated
internally -- the language may not have pointers as such) the compiler
may be able to assume things about alignment that could be helpful for
optimisation (particularly vectorisation).

<snip>
-- 
Ben.

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