Release

[Lisandro Dalcin]

On 9/25/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
>     Please explain in detail.

Well, this article explains strict aliasing in some detail (just in
case you does not know the details)

http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

In the particular case of PETSc, if I understand correctly, the
designed object's struct inheritance based in the current PETSCHEADER
approach will not make it possible to enable strict aliasing rules.
For the compiler, PetscObject and Vec are different types of objects,
so if you do

PetscObject o = (PetscObject)v;

you are breacking strict aliasing rules, using o->comm and v->comm to
access the vector communicator could possibly fail with aggresive
compiler optimization.

How to solve this?? Well, I followed the approach in Python 3.0 for
defining the base object header for derived objects. In the case of
PETSc, this amounts to the following:

#define PETSCHEADERBASE \
  PetscCookie    cookie;
  MPI_Comm       comm;
  char*                prefix;
  char*                type_name;
  /* etc ....*/

struct _p_PetscObject {
  PETSCHEADERBASE
};

#define PETSCHEADER(ObjectOps) \
  struct _p_PetscObject header;
  ObjectOps                   *ops;

And now the Vec struct is declared as before:

struct _p_Vec {
  PETSCHEADER(struct _VecOps);
  /* etc ... */
};

Now, there is no way to access things like cookie/comm/prefix fro a
Vec, for doing it you need to cast to PetscObject. This removes the
possibility of accesing 'comm' or 'prefix' though pointers of
different types. As a side effect, you need to always cast to
PetscObject to get comm/prefix/type_name (by far the more commonly
accessed members when implementing Vec/Mat/KSP etc...)

I'm started this work at home, I do not have the code here at my
office right now, but I could remove almost all the warnings related
to strict aliasing in 'src/sys' and 'src

> > I have also some problems when calling PetscObjectQueryFunction, >
>    Yes this function pointer casting stuff is a royal pain and ugly.

Perhaps I can find better way of doing this using a macro.

>
>   Might be easier to just rewrite everything in C++. :-)
>

Well, having error handling based on C++ exceptions is really
tempting. But C++ polymorphism would make it easier to derive specific
implementations of objects, and using smart pointer would help for the
automatic reference counting of owned objects, and a lot of more good
things. BUT... the PETSc way of doing polimorphism is a bit more
powerful than the C++ virtual table. That is, each object instance
have its own table of functions pointers, and you can freely replace
it in a object by object base (and done in some MatConvert() calls).
Of course, a C++ implementation could still use tables of function
pointer, and dispatching code based on that table.

All this would require a lot, lot of redesing and work. :)

BTW, Could you please teach me some easy way of replacing in PETSc
source code the following:

'something>comm'    by   '((PetscObject)something)->comm'

I never found the time to learn regular expresions and 'sed'  :-(.



>
>   Barry
>
> > In case
> > you want me to continue this work, I will need a bit of help in a few
> > places related to low-level calls related to sockets and sys calls.
> >
> >
>
>


-- 
Lisandro Dalcín
---------------
Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
PTLC - Güemes 3450, (3000) Santa Fe, Argentina
Tel/Fax: +54-(0)342-451.1594