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


Groups > comp.lang.c > #111994

Re: C speed

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>

Show all headers | View raw


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


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