Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #111994
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: C speed |
| Date | 2017-06-12 09:12 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <ohlem4$vhq$1@dont-email.me> (permalink) |
| References | (2 earlier) <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> <87bmpue0jw.fsf@bsb.me.uk> |
On 11/06/17 22:23, Ben Bacarisse wrote:
> 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).
>
I'd be loath to say it is /always/ the case - but I think it is likely
to be so in most cases in C. I suppose a compiler could give an array a
larger alignment than an element of an array, but it seems unlikely in
practice - certainly not for doubles. It may be that sometimes it will
know that the real array is at higher alignment - but the compiler will
not know that merely from knowing a pointer is to the start of the array.
If you want to tell the compiler more about alignment to help
vectorisation, there are standard C methods (such as using unions or
_Alignas), and implementation-specific methods (such as gcc's aligned
attribute) that are probably much more useful when you are targeting
specific types of optimisation.
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