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

Groups > comp.lang.c > #59752 > unrolled thread

Array operations in C

Back to article view | Back to comp.lang.c

Contents

  Array operations in C beliavsky@aol.com - 2015-04-07 06:06 -0700
    Re: Array operations in C Bartc <bc@freeuk.com> - 2015-04-07 15:10 +0100
      Re: Array operations in C Bartc <bc@freeuk.com> - 2015-04-07 16:24 +0100
        Re: Array operations in C Steve Thompson <stevet810@gmail.com> - 2015-04-09 00:35 +0000
      Re: Array operations in C fir <profesor.fir@gmail.com> - 2015-04-08 07:48 -0700
    Re: Array operations in C Tim Prince <tprince@computer.org> - 2015-04-07 10:30 -0400
    Array operations in C asetofsymbols@gmail.com - 2015-04-07 08:00 -0700
      Array operations in C asetofsymbols@gmail.com - 2015-04-07 08:09 -0700
        Array operations in C asetofsymbols@gmail.com - 2015-04-07 08:36 -0700
          Array operations in C asetofsymbols@gmail.com - 2015-04-07 08:58 -0700
          Array operations in C asetofsymbols@gmail.com - 2015-04-08 00:16 -0700
            Array operations in C asetofsymbols@gmail.com - 2015-04-08 01:30 -0700
            Re: Array operations in C Tim Prince <tprince@computer.org> - 2015-04-08 08:59 -0400

#59752 — Array operations in C

According to the article

http://www.hpcwire.com/2015/04/06/compilers-and-more-the-past-present-and-future-of-parallel-loops/
April 6, 2015
Compilers and More: The Past, Present and Future of Parallel Loops
by Michael Wolfe

Intel C and C++ now support array operations such as the following:

r[0:n] = 0;
for( int j = 0; j < ncols; ++j )
  r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];

What is the chance that such operations become part of standard C and are implemented in gcc?

[toc] | [next] | [standalone]

#59754

On 07/04/2015 14:06, beliavsky@aol.com wrote:
> According to the article
>
> http://www.hpcwire.com/2015/04/06/compilers-and-more-the-past-present-and-future-of-parallel-loops/
> April 6, 2015
> Compilers and More: The Past, Present and Future of Parallel Loops
> by Michael Wolfe
>
> Intel C and C++ now support array operations such as the following:
>
> r[0:n] = 0;
> for( int j = 0; j < ncols; ++j )
>    r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];
>
> What is the chance that such operations become part of standard C and are implemented in gcc?

Small.

But, assuming that r[0:n] means n elements of r starting from r[0], 
these map very easily to a normal loop:

  r[0:n] = 0;

becomes:

  for (k=0; k<n; ++k)
     r[k] = 0;

which can probably be reduced to some macro if you like doing that. Your 
second example similarly becomes:

  for( int j = 0; j < ncols; ++j )
    for (k=0; k<n; ++k)
       r[k] += a[rowndx[k]+j] * v[colndx[rowndx[k]+j]];

So while there's a fairly straightforward workaround, having such an 
array op doesn't buy much. Unless you have a trickier example?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59760

On 07/04/2015 15:10, Bartc wrote:
> On 07/04/2015 14:06, beliavsky@aol.com wrote:

>> Intel C and C++ now support array operations such as the following:
>>
>> r[0:n] = 0;
>> for( int j = 0; j < ncols; ++j )
>>    r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];
>>
>> What is the chance that such operations become part of standard C and
>> are implemented in gcc?
>
> Small.
>
> But, assuming that r[0:n] means n elements of r starting from r[0],
> these map very easily to a normal loop:
>
>   r[0:n] = 0;
>
> becomes:
>
>   for (k=0; k<n; ++k)
>      r[k] = 0;

A general slice such as r[a:len] is slightly trickier:

     for (k=a; k<(a+len); ++k)
        r[k] = 0;

So it starts to have more value (although an apt macro can take care of 
that too). But perhaps somewhat more useful is being able to operate on 
the entire array:

       r[:] = 0; // or some such syntax

this is harder to implement conventionally because there needs to be a 
way of picking up the length, and for dynamic arrays this is not stored 
anywhere it can be grabbed automatically.

Maybe Intel C (and was that Intel C++ too?) have sorted that, however 
then it becomes a far more fundamental change to the language than more 
concise syntax. In other words, it's never going to happen! (Maybe in 
C++, but there apparently anything goes.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59881

On Tue, Apr 07, 2015 at 04:24:34PM +0100, Bartc wrote:
> On 07/04/2015 15:10, Bartc wrote:
> >On 07/04/2015 14:06, beliavsky@aol.com wrote:
> 
> >>Intel C and C++ now support array operations such as the following:
> >>
> >>r[0:n] = 0;
> >>for( int j = 0; j < ncols; ++j )
> >>   r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];
> >>
> >>What is the chance that such operations become part of standard C and
> >>are implemented in gcc?
> >
> >Small.
> >
> >But, assuming that r[0:n] means n elements of r starting from r[0],
> >these map very easily to a normal loop:
> >
> >  r[0:n] = 0;
> >
> >becomes:
> >
> >  for (k=0; k<n; ++k)
> >     r[k] = 0;
> 
> A general slice such as r[a:len] is slightly trickier:
> 
>     for (k=a; k<(a+len); ++k)
>        r[k] = 0;
> 
> So it starts to have more value (although an apt macro can take care of 
> that too). But perhaps somewhat more useful is being able to operate on 
> the entire array:
> 
>       r[:] = 0; // or some such syntax
> 
> this is harder to implement conventionally because there needs to be a 
> way of picking up the length, and for dynamic arrays this is not stored 
> anywhere it can be grabbed automatically.
> 
> Maybe Intel C (and was that Intel C++ too?) have sorted that, however 
> then it becomes a far more fundamental change to the language than more 
> concise syntax. In other words, it's never going to happen! (Maybe in 
> C++, but there apparently anything goes.)

Perhaps.  But it seems obvious to me that parallel programming will
become the norm rather than the exception and it is reasonable to
suggest that languages will naturally adjust to that paradigm as much
as they are able.  What that portends for C is another matter.

OpenMP and such are only half of the (potential) solution.  Exploiting
parallelism among cooperating nodes is the other half of the equation
and that remains difficult.  Perhaps a multi-node shared/virtual
memory system will emerge that is analogous to today's hardware
assisted VM systems, including a largely transparent message-passing
architecture.  It would be very convenient to address local and
foreign threads transparently, but the basic problem of latency would
seem to make that fundamentally problematic.




Regards,

Steve Thompson

-- 
"If I had a nickel for every time some idiot called me about a
computer problem that turned out to be user error, I would be able to
retire and spend the rest of my days cultivating clues in my backyard
hillside garden."  -- MysteryDog in 24hoursupport.helpdesk.

[toc] | [prev] | [next] | [standalone]

#59822

W dniu wtorek, 7 kwietnia 2015 16:10:25 UTC+2 użytkownik Bart napisał:
> On 07/04/2015 14:06, beliavsky@aol.com wrote:
> > According to the article
> >
> > http://www.hpcwire.com/2015/04/06/compilers-and-more-the-past-present-and-future-of-parallel-loops/
> > April 6, 2015
> > Compilers and More: The Past, Present and Future of Parallel Loops
> > by Michael Wolfe
> >
> > Intel C and C++ now support array operations such as the following:
> >
> > r[0:n] = 0;
> > for( int j = 0; j < ncols; ++j )
> >    r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];
> >
> > What is the chance that such operations become part of standard C and are implemented in gcc?
> 
> Small.
> 
> But, assuming that r[0:n] means n elements of r starting from r[0], 
> these map very easily to a normal loop:
> 
>   r[0:n] = 0;
> 
> becomes:
> 
>   for (k=0; k<n; ++k)
>      r[k] = 0;
> 
> which can probably be reduced to some macro if you like doing that. Your 
> second example similarly becomes:
> 
>   for( int j = 0; j < ncols; ++j )
>     for (k=0; k<n; ++k)
>        r[k] += a[rowndx[k]+j] * v[colndx[rowndx[k]+j]];
> 
> So while there's a fairly straightforward workaround, having such an 
> array op doesn't buy much. Unless you have a trickier example?
> 


ye thats nothing impressive here 
in my propositions to c2 i considered bigger changes :
(copy from december 2014 posts here
(i think it may be alled array arithmetic and it is probably usefull though some decisions here to take are clear but some not)


W dniu środa, 17 grudnia 2014 22:35:08 UTC+1 użytkownik fir napisał: 
> W dniu środa, 17 grudnia 2014 15:43:31 UTC+1 użytkownik fir napisał: 
> > W dniu środa, 17 grudnia 2014 14:58:22 UTC+1 użytkownik fir napisał: 
> > 
> > ps i was trying to find my notes on this 
> > form form bu cannot find, but found 9when repeating the theme of c2 improvements this one 
> > 
> > if(a,b,c == d,e,f) g, h = h, g; 
> > 
> > this is extended support for ad hoc 'tuples' or what to call it in english 
> 
> this looks nice because is guite natural 
> 
> a,b,c,d = b,c,a,d 
> maps for example on SSE shuffle etc 
> 
> some more generalisations seem also 
> natural (though maybe less) 
> (will wrote in array form but tuples should be treated just the same) 
>  assume most of this this arrays are n-length vectors 
> (like 4-vectors0 
> 
> a[] = b[]    //memcopy 
> 
> c[] = a[]/d[] //4-div 
> and so on 
> 
> c[] = a[], b[] 
>  // memcopy with placing b[] after a[] 
> 
> 
> c[1,4,5,7] 
> - is a 4-vector c[1], c[4], c[5], c[7],; 
> //may say it is duplicate syntax but this is important for me to show that a[4,6] syntax is for some reason natural for 2-vector tuple not to confuse with other meaning 
> 
> now some confusion what to chose when multiply by not the same length vectors 
> 
> a[] * 2 
>  //handy seem to multiply each a[i] by 2 
> 
> a[] = a[] * 2,3 
>  // probably it could be the a[] 8 repeating pattern of 2,3,2,3,2,3,2,3... 
> though im not 100% sure as to this 
> 
> in opposite direction can go opposite 
> (not to waste the syntax) 
> and here 
> 
> float d = 5*n[] 
> 
> treat it as 5*n[0]*n[1]*n[2]*n[3]; 
> like +n[] would be sum of all 
> 
> int sum_even, sum_odd = (0,0) + n[]; 
> 
> 
> not sure if this is 100% suitable for c bur this is avaliable option to go 
> 
> some more can be done also, this way, some may be more natural other more arbitrary 

probably when ommittin [] this vector arithmetic would look better, though its strong need to bear in mind what is a vector what is a scalar and what is a shorter vector, also comma should be weaker than arithmetic 

float a[] = 1,2,3,4; 
float b[] = 3, 5; 
float c = 6; 

float d = c + a * b 

would be: 48 <-  6 + 1*3 + 2*5 + 3*3 + 4*5 

b * a + c 

would be 
(3,5) * (1,2,3,4) + 6 

15, 16 <- 3*1*3+6, 5*2*4+6 

not quite sure if those left side version of 2-vector and 4-vector should look like that, (muls even, muls odds) as this seem a bit unclear, 
think most usable version of vector aruthmetic should be used, this seem usable, 
also maybe worth considering commutative version with some pseudo-operators of populate, reduce, 

(1,2,3) * (1,2,3,4,5,6,7,8,9) 

[toc] | [prev] | [next] | [standalone]

#59756

On 4/7/2015 9:06 AM, beliavsky@aol.com wrote:
> According to the article
> 
> http://www.hpcwire.com/2015/04/06/compilers-and-more-the-past-present-and-future-of-parallel-loops/
> April 6, 2015
> Compilers and More: The Past, Present and Future of Parallel Loops
> by Michael Wolfe
> 
> Intel C and C++ now support array operations such as the following:
> 
> r[0:n] = 0;
> for( int j = 0; j < ncols; ++j )
>   r[0:n] += a[rowndx[0:n]+j] * v[colndx[rowndx[0:n]+j]];
> 
> What is the chance that such operations become part of standard C and are implemented in gcc?
> 
gcc 5.0 has a more than 50% implementation of -fcilkplus.  It's probably
a chicken-and-egg question whether this gcc implementation will become
somewhat useful, and whether the implied vectorization pragmas will
become available for plain C99.  Even if these did happen, I suppose the
other response about slim chance of C or C++ standardization would be
accurate.

[toc] | [prev] | [next] | [standalone]

#59758

I suppose that code means:

for(i=0;i<n;++i) r[i] = 0; 
for( int j = 0; j < ncols; ++j ) 
  for(i=0;i<n;++i)
  r[i] += a[rowndx[i]+j] * v[colndx[rowndx[i]+j]];


But it is as above or
for(i=
 for(j= etc?

But for me the min For loop
assumes this aspect: 

i:0..n!r[i]=0;
i,j:0..n,ncols!
  r[i]+= a[rowndx[i]+j] * v[colndx[rowndx[i]+j]];

[toc] | [prev] | [next] | [standalone]

#59759

i+0..n!r[i]=0; 
i,j+0..n,ncols! 
  r[i]+= a[rowndx[i]+j] * v[colndx[rowndx[i]+j]];

Above is wrong because i and
j has to have their increment
or decrement

The min for loop it is this:
F(i=0; i<n; ++i)
  F(j=0; j<ncols; ++j)
  r[i]+= a[rowndx[i]+j] * v[colndx[rowndx[i]+j]];

[toc] | [prev] | [next] | [standalone]

#59763

this whould be the min for loop
and its generalization...

i=0|i<n|++i|
r[i]=j=0|j<ncol|++j|+|a[rowndx[i]+j] * v[colndx[rowndx[i]+j]]);


i=0|i<3|++i|a[i]=7;
would mean: 
a[0]=7; a[1]=7; a[2]=7;

b=j=0|j<3|++j|+|a[j];
would mean:
b=a[0]+a[1]+a[2];

b=j=0|j<3|++j|*|a[j];
would mean:
b=a[0]*a[1]*a[2];

Etc

[toc] | [prev] | [next] | [standalone]

#59767

i=0|i<3|++i|a[i]=7; 
would mean: 
a[0]=7; a[1]=7; a[2]=7;

i=0|i<3|++i|j=0|j<1|++j|a[i][j]=3+j; 
would mean: 
a[0][0]=3; a[0][1]=4;
a[1][0]=3; a[1][1]=4;
a[2][0]=3; a[2][1]=4;

i=0,j=0|i<3|++i,++j|a[i][j]=3+j;
would mean: 
a[0][0]=3; a[1][1]=4;
a[2][2]=5; 

[toc] | [prev] | [next] | [standalone]

#59793

It is enough only one condition for
start one for end and one for
operator

this would be the min for loop 
and its generalization... 

[i=0;i<3;]a[i]=7; 
would mean: 
a[0]=7; a[1]=7; a[2]=7; 

[i=0;i<3;]a[2-i]=7; 
would mean: 
a[2]=7; a[1]=7; a[0]=7; 

b=[j=0;j<3;+]a[j]; 
would mean: 
b=a[0]+a[1]+a[2]; 

b=[j=0;j<3;+]a[j]^[j=0;j<3;+]b[j]
would mean: 
b=a[0]+a[1]+a[2]^b[0]+b[1]+b[2];

[i=0;i<N;]
  [j=0;j<i;] a(i,j)=i+j;
would mean: 
for(i=0;i<N;++i)
  for(j=0;j<i;++j) a(i,j)=i+j;

[i=0, j=0; i<3;] a(i,j)=i+j;
would mean:
for(i=0, j=0; i<3; ++i, ++j)
         a(i,j)=i+j;

[i=0;i<n;]r[i]=[j=0;j<ncol;+]

a[rowndx[i]+j] * v[colndx[rowndx[i]+j]]); 

is there some for loop this can 
not represent?

Nobody has seen how other language
build loops? 

[toc] | [prev] | [next] | [standalone]

#59795

In some code there is s=s->next
as increment...

It is enough only one condition for 
start one for end, one for increment
[or next] one for operator

this would be the min for loop 
and its generalization... 

[i=0;i<3;++i;]a[i]=7; 
would mean: 
a[0]=7; a[1]=7; a[2]=7; 

[i=0;i<3; ++i;]a[2-i]=7; 
would mean: 
a[2]=7; a[1]=7; a[0]=7; 

b=[j=0;j<3;++j;+] a[j]; 
would mean: 
b=a[0]+a[1]+a[2]; 


b=[j=0;j<3;++j;+]a[j]^[k=0;k<3;++k;+]b[k]
would mean: 
b=a[0]+a[1]+a[2]^b[0]+b[1]+b[2]; 

[i=0;i<N;++i;]
  [j=0;j<i; ++j;] a(i,j)=i+j; 
would mean: 
for(i=0;i<N;++i) 
  for(j=0;j<i;++j) a(i,j)=i+j; 

[i=0, j=0; i<3; ++i,++j;]
    a(i,j)=i+j; 
would mean: 
for(i=0, j=0; i<3; ++i, ++j) 
         a(i,j)=i+j; 

[i=0;i<n;++i;]
  r[i]=[j=0;j<ncol;++j;+]
a[rowndx[i]+j] * v[colndx[rowndx[i]+j]]); 

[toc] | [prev] | [next] | [standalone]

#59814

On 4/8/2015 3:16 AM, asetofsymbols@gmail.com wrote:

> 
> Nobody has seen how other language
> build loops? 
> 

Yes, cilkplus notation already is at variance with other languages (e.g.
modula, Fortran) to the extent that it causes programming mistakes.
That was one of the reasons PL/I lost popularity.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web