🚀 go-pugleaf

enseeg14@grenet.fr wrote:
|> (I primarily posted this to comp.lang.c++, but the conclusion of it
|>  make it fit to this ng -- unless I'm too ignorant about compiler
|>  optimization....)

|> A question arose during a flamewar on comp.lang.fortran, about compiler
|> optimization.

|> C has always been the language where _THE PROGRAMMER_ could make his
|> own optimization, but this style of programming is getting deprecated
|> according to most C++ who basically say "rely on the compiler, optimize
|> only as a last minute operation". But here I have an example of what
|> would be very unefficient in C/C++ compared to F90:

|> > for (i = 0 ; i < n ; i++) {
|> >    for (j = 0 ; j < n ; j++) {
|> >       a[i][j] = b[i][j] * c[i] ;
|> >    }
|> > }

|> > do j = 1,m
|> >   do i = 1, n
|> >     a (i,j) = b(i,j) * c(i)
|> >   enddo
|> > enddo 

|> The Fortran compiler can easy unroll the loop and take advantage of scalar
|> caches, and easily use vectorial registers, whereas the C compiler
|> can't even move the evaluation of c[i] out of the inner loop because
|> &c[i] could be == to &a[x][y] ............ That's the problem with
|> weak typin... I'm wondering if any of the "const" tweak would change
|> anything...

Const won't help, and the problem isn't typing, but potential aliasing.
Fortran basically says that the results are undefined if aliasing is
present, C/C++ doesn't.  (In this regard, one could very easily argue
that C/C++ is safer.  In fact *in* *this* *regard*, I think it is, in
that you get defined results even if the arrays overlap.)

If the compiler can determine that no aliasing is present, they can
optimize.  Typically, this would require intermodule flow analysis,
something that is not frequently done in either C/C++ or Fortran
(although I've heard rumors of a C++ compiler which does it).

|> Despite I'm really disgusted by Fortran, I must concede this and
|> since only few compilers do really perform all the optimizations you
|> see in the books, I don't know they could get sthng good out of this...

|> So, if we're obliged to barf (see note) in this case, could there be any kin
d
|> of C++ extension -- another one! -- to imporve this? 

There is a proposed extention to C which would do it, a sort of son of
noalias.  I don't know any of the details, but I'm sure that a question
in comp.std.c would reach people who did, or who could point you in the
right direction.

I don't know what the current stand is with regards to the proposed C
extensions, and their incorporation into C++.  The C standard is part of
C++ `by reference', but in fact, I think that this is only where there
is an explicit reference (e.g.: some of the libraries).  In addition, I
think that the version of the C standard included by reference is part
of the standard.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]