[Beowulf] Stroustrup regarding multicore

[Robert G. Brown]

On Tue, 26 Aug 2008, Kyle Spaans wrote:

> (DISCLAIMER: I'm still very much a novice programmer, and I can count the 10's of lines of C code
> that I've written on my two hands.)
>
> I've been trying to understand this very debate for a couple of months now, ever since some, uhh,
> "experienced" (:P) aquaintaces of mine discussed the advantages of Fortran over C for work with
> multidimensional data. At first I didn't understand it at all. Something about array indexing
> and size?
>
> I've been using Fortran 90 (_always_ IMPLICIT NONE, sane variable names, modules, never written a
> GOTO statement in my life, etc) for about 8 months now on my co-op work term. I can see how easy it
> is to create and dynamically allocate arrays of any dimension. I'm not too sure how it's working
> under the hood just yet, but I've heard that Fortran arrays carry around a little bit of extra
> metadata about the size of the array?

So do some implementations of arrays in C -- see the GSL "gsl_matrix"
type and so on.  These libraries make a matrix "object" that is a struct
with this missing metadata, a pointer to the actual vector, and possibly
a **pointer for the packed directly accessible matrix.  The advantages
is that it is easy to write code to act on matrix objects.  The
disadvantage is that it isn't quite as straightforward or efficient as
just allocating your own matrices directly, especially if one uses only
provided get/set routines to access the contents of matrix elements.

> Either way, I've recently started writing Conway's Game of Life in C, as an exercise. I needed to
> figure out how to dynamically allocate a 2D array. I found an answer on the comp.lang.c FAQ[1].
> It's not terribly complex, but it seems to me like it's more involved than with Fortran.

Most people who code in C -- in my experience, at least -- rapidly
decide to write a numerical-recipes-like
**create_matrix()/**free_matrix() routine that can be used to create
matrices with arbitrary stride and cast to various types.  Or they get
to be like me, where in ordinary code I just do it inline, especially if
I'm only allocating a handful of matrices this way.

> And if it came to an array of dimension >> 3, wouldn't that be a lot of array indicies and deferences
> to calculate as the dimensions added up. That's assuming you go with option 1 from the FAQ. Option
> 2 looks more reasonable to me.  But couldn't this explain at least part of Fortran's "advantage"?

I actually for grins wrote a "tensor" package that would -- and still
will, if anybody wants it -- allocate up to a *********pointer of any
user defined stride, type void so it can be cast.  However, I myself
don't generally use tensors of this high rank any more.  I was hoping to
contribute it to the GSL, which has a matrix type but lacks higher rank
tensors altogether (which is a bit of a problem for the friendly E&M or
general relativity folks, or the nuclear physics folks with their
perpetual angular momentum sums over incoming and exiting particle
channels).  Of course the physics code for most of the latter is all in
Fortran, and this may well be part of the reason why.

But seriously, allocating arbitrary tensor-referenced structs or
typedefs is part of the FUN of coding in C.  In C you do indeed have to
do a lot of this "yourself" but you have complete CONTROL over it where
you do, and things that one cannot even conceive of in Fortran code
become conceivable in C.

This leaves aside how wise they are.  Pointers are power, but they
require discipline and responsibility too, or you'll end up with code
that is impossible to debug.  Oh, and the other thing about dynamic
allocation is you'd better learn equally fast to correctly dynamically
free or you'll leak memory like a sieve.  With matrices allocated by the
one alloc and address repacking, it is pretty easy -- free the base
address of the matrix data vector and free the vector of pointers.  With
matrices allocated by looping mallocs, each row has to be separately
freed, followed by freeing the vector of pointers.

Used right, they make code MORE readable, not less, sometimes at the
cost of a bit of speed or sometimes not.

   rgb

>
> [1] http://c-faq.com/aryptr/dynmuldimary.html
> _______________________________________________
> Beowulf mailing list, Beowulf at beowulf.org
> To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
>

-- 
Robert G. Brown                            Phone(cell): 1-919-280-8443
Duke University Physics Dept, Box 90305
Durham, N.C. 27708-0305
Web: http://www.phy.duke.edu/~rgb
Book of Lilith Website: http://www.phy.duke.edu/~rgb/Lilith/Lilith.php
Lulu Bookstore: http://stores.lulu.com/store.php?fAcctID=877977