Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #111980
| 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> |
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
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