OpenCL - why are there any pointers at all?

Article: Introduction to OpenCL
By: Rob Thorpe (rthorpe.delete@this.robertthorpeconsulting.com), December 17, 2010 10:03 am
Room: Moderated Discussions
Richard Cownie (tich@pobox.com) on 12/17/10 wrote:
---------------------------
>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.

Yes, I know that.

>>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.

What I said was "the strength reduction you mention".

If a set of array operations happen within a function then any reasonable optimizing compiler can perform strength reduction so that the creation of each relevant pointer is only done once. In this case pointers aren't an advance over arrays. But, that wasn't what we were talking about.

What you were suggesting is that a compiler could provide strength reduction across functions. It could replace the passing of a pointer to the start of an array and an index with the passing of just one pointer. I'm not aware of any compiler that can do that.

Some compilers that provide inlining can do it for inlined functions, but that's all AFAIK.

I don't expect it's a very common problem.

>>>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.

That's what I meant by saying "bounded" and "immiscible". In languages with arrays the programmer must make sure that two array variables aren't the same array. But, once that has been dealt with there is no possibility that the arrays overlap.

>>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.

As I understand it OpenCL isn't for the matrix & vector sort of things, not for big programs full of complex data structures.
< 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 avocado?