[Beowulf] Stroustrup regarding multicore

[Robert G. Brown]

On Tue, 26 Aug 2008, Perry E. Metzger wrote:

> Ah. You're not talking about using a C array as a C array any
> more. You're talking about using it as a data structure to represent an
> arbitrary matrix structure. In that case you will find C programmers
> doing all sorts of games, of course, and I don't disagree with you.

:-)

>> And finally there is the convolution of this problem with structs,
>> especially dynamically allocated structs with unusual index ranges.
>
> Not sure what you mean by that.

See "all sorts of games" above...:-)

> One can also play games with incrementing the pointers because believe
> it or not, C will let you do that, at which point indexing 0 is an
> error. You can also use negative indexes that way. NOT NOT NOT a
> recommended idea. Much better to use an inline function and a wee bit
> of imagination, or (in C++) to overload the [] operator.

Yeah, I've looked at a lot of (other people's) code where they access
vector elements etc by incrementing pointers -- there are examples in
K&R of the same -- but I've always thought that this was the best way in
the known C universe to write totally obfuscated code.  Well, except for
using the ?  : ternary conditional operator and if(a=b) constructs,
where the latter is almost always a bug... so if it is intentional it is
just evil;-)

When doing vector arithmetic in C I like using vector and matrix
(fortran-like) syntax and using pointers to make matrices/tensors that
precisely match the problem, instead of accepting any sort of 0
convention on array indexing, when it matters.

Where it doesn't, of course I just pop out an int a[10].  Since malloc
is expensive (especially malloc of big blocks where the kernel might
have to do some work to free up the space) I tend to use malloc for
global and persistent variables, ideally where I only rarely have to
free them and reallocate the space.  I imagine most C programmers
eventually develop a feel for what is expensive and what is cheap, and
where optimization matters (inside core loops) and where it doesn't
(nearly anywhere else, unless milliseconds matter to you).  After all,
modern computers execute megainstructions per millisecond, which means
small efficiencies in serial one-pass code aren't worth the time it
takes to type them in, amortized over a human lifetime of use.

    rgb

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