OpenCL - why are there any pointers at all?

Article: Introduction to OpenCL
By: Richard Cownie (tich.delete@this.pobox.com), December 17, 2010 9:13 am
Room: Moderated Discussions
Rob Thorpe (rthorpe@robertthorpeconsulting.com) on 12/17/10 wrote:
---------------------------

>I agree with you that pointers are less efficient in that situation. I doubt that
>optimizing compilers would provide the strength reduction you mention, though I suppose they may I haven't heard of it.

It's a common optimization that has been around at least
since the early 1980s. If there's a loop which contains
many address calculations, e.g.

for (j = 0; j < n; ++j) {
elementAddr = baseAddr + j*elementSize;
... access the element at address elementAddr
}

then many, perhaps most, compilers are smart enough
to generate the same sequence of values like this

elementAddr = baseAddr
for (j = 0; j < n; ++j) {
elementAddr += elementSize;
...
}

which takes the loading of baseAddr out of the loop,
and strength-reduces the multiplication to an addition.

>But, I doubt this case is really very common.

It's extremely common in any vector/matrix code, i.e.
a lot of floating-point stuff.

>>And C programmers have been writing
>>"while (*dst++ = *src++);"
>>for 35 years or so and you're just going to tick them
>>needlessly if you take that away for no good reason.
>
>I don't think it's needless. In fact I think your piece of traditional C demonstrates the problem.
>
>Let's say I have a function that takes two arrays and returns a third. In a language
>without pointers those arrays are bounded objects, they're immiscible.

Except actually, they aren't. If you pass in arrays
A, B, and C, then you can't assume that they're
non-overlapping, because you might call it as Foo(a, a, b)
or even Foo(a, a, a). You can only make the not-so-useful
assumption that different indexes refer to distinct
elements. Or to put it another way, that two array
parameters are either identical or disjoint.

>But, with
>C pointers they aren't, one array may overlap another.

Yes, but as noted above, you've let about 90% of the
cat out of the bag already by allowing arrays to be
passed as parameters. So the benefit of hanging on to
the end of the cat's tail is questionable.

>But, compilers can't ignore the problem. If the compiler has several pointers
>in a function then it can't make many assumptions about them. It must prove things
>about them. That requires alias analysis to work at the module level at least,
>though it would be better at the whole-program level. Any alias analysis system
>has to be conservative, so if only a particularly strange set of inputs would give
>aliased pointers it still has to emit code that assumes pointers can alias.

I don't really have a dog in this fight. There are
benfits and costs to allowing pointer variables and
pointer arithmetic. I'd guess it probably comes down
to how complex your data structures need to be: if you're
just dealing with 1D/2D/3D vectors and matrices, then
you can manage without pointers without excessive
confusion, and a suitably restrictive language with a
suitably smart compiler may be able to do well. On the
other hand, if your app can benefit from complex data
structures - trees, hashtables, priority queues,
graphs - then I'm sure the benefit of allowing programmers
to express those with pointers will outweigh the cost
of making it hard for the compiler to figure out what's
going on. I'm a data-structure guy myself rather than
a numerical-analysis guy, so I gravitate to languages
which let you get down and dirty with pointers and bit-
manipulation.

>>Also, I haven't looked at OpenCL in detail, but if it
>>has type-casts as well as pointer variables, then for all
>>intents and purposes it *does* have dynamic allocation -
>>just declare char BigBuf[BIGBUFSIZE] and then write your
>>own functions to malloc() and free() from that buffer.
>>Though probably in most cases you'd want a more complex
>>system that would allow you to allocate from the different
>>classes of OpenCL memory rather than treating it all the
>>same.
>
>Yes, that's true.

I took a quick look, and it seems that OpenCL does have
lots of type-conversion primitives, certainly enough
to coerce a char* to be interpreted as a Foo*

< Previous Post in ThreadNext Post in Thread >
TopicPosted ByDate
OpenCL article onlineDavid Kanter2010/12/09 02:44 AM
  OpenCL article onlineXN2010/12/09 06:33 AM
    OpenCL article onlineDavid Kanter2010/12/09 01:54 PM
  OpenCL article onlineanon2010/12/09 02:33 PM
    OpenCL article onlineDavid Kanter2010/12/09 02:38 PM
      OpenCL article onlineIan Ameline2010/12/09 03:47 PM
      OpenCL article onlineAnon2010/12/09 08:27 PM
        OpenCL article onlineDavid Kanter2010/12/09 10:58 PM
  Performance portabilityBryan Catanzaro2010/12/10 12:43 PM
    Performance portabilityltcommander.data2010/12/10 07:11 PM
      It is difficult to runtime optimize away the difference between a CPU and GPUMark Roulo2010/12/10 07:50 PM
        It is difficult to runtime optimize away the difference between a CPU and GPUhobold2010/12/11 03:35 AM
          It is difficult to runtime optimize away the difference between a CPU and GPUMark Roulo2010/12/12 01:20 PM
            It is difficult to runtime optimize away the difference between a CPU and GPUhobold2010/12/12 03:31 PM
              It is difficult to runtime optimize away the difference between a CPU and GPUanon2010/12/12 04:24 PM
                It is difficult to runtime optimize away the difference between a CPU and GPUhobold2010/12/13 03:44 AM
        Specially when the language provides almost no hardware abstraction (NT)EduardoS2010/12/11 10:53 AM
    Performance portabilityWainwright2010/12/11 03:44 PM
      Performance portabilityEduardoS2010/12/11 03:57 PM
        Performance portabilityWainwright2010/12/11 04:02 PM
          Performance portabilityEduardoS2010/12/11 08:20 PM
            Performance portabilityWainwright2010/12/12 02:22 AM
      Performance portabilityDavid Kanter2010/12/11 05:53 PM
        Performance portabilityEduardoS2010/12/11 08:23 PM
          Performance portabilityDavid Kanter2010/12/11 09:06 PM
            Performance portabilityWainwright2010/12/12 02:26 AM
            Performance portabilityEduardoS2010/12/12 09:04 AM
  OpenCL article onlineAlan Commike2010/12/14 01:01 PM
  OpenCL - why are there any pointers at all?Rob Thorpe2010/12/16 03:45 AM
    OpenCL - why are there any pointers at all?EduardoS2010/12/16 01:51 PM
      OpenCL - why are there any pointers at all?Rob Thorpe2010/12/17 03:19 AM
        OpenCL - why are there any pointers at all?Richard Cownie2010/12/17 07:02 AM
          OpenCL - why are there any pointers at all?Rob Thorpe2010/12/17 08:29 AM
            OpenCL - why are there any pointers at all?Richard Cownie2010/12/17 09:13 AM
              OpenCL - why are there any pointers at all?Rob Thorpe2010/12/17 10:03 AM
                OpenCL - why are there any pointers at all?Richard Cownie2010/12/17 10:53 AM
                  OpenCL - why are there any pointers at all?Rob Thorpe2010/12/17 11:19 AM
                    OpenCL - why are there any pointers at all?Richard Cownie2010/12/17 11:51 AM
                OpenCL - why are there any pointers at all?hobold2010/12/17 11:06 AM
          OpenCL - why are there any pointers at all?EduardoS2010/12/18 07:58 AM
            OpenCL - why are there any pointers at all?anon2010/12/18 10:27 AM
            OpenCL - why are there any pointers at all?BorisG2010/12/18 10:33 AM
              OpenCL - why are there any pointers at all?Richard Cownie2010/12/18 02:39 PM
  OpenCL article onlineEmil Briggs2010/12/19 06:40 AM
Reply to this Topic
Name:
Email:
Topic:
Body: No Text
How do you spell green?