[Beowulf] Teaching Scientific Computation (looking for the perfect text)
Joe Landman
landman at scalableinformatics.com
Tue Nov 20 18:17:12 EST 2007
Robert G. Brown wrote:
>>> So, I'm thinking about reworking the class to favor C, and fearing 3
>>> weeks of pointer and addressing hell. For those of you who teach
>>
>> Its actually not that painful. I was able to walk through it in one
>> session, explaining what the symbols mean, how to read them, and then
>> showing them in use for a heat diffusion problem in 2D (breaking up a
>> large array into panels).
>
> Indeed, if you combine pointers with a "here's how the computer REALLY
> works, kids" lecture so that you help them visualize memory and maybe
My first two lectures were on that. Bytes? We don't need no steenkeen
bytes! Cache lines is where its at, yessiree.
One of my favorite examples of showing them that memory is not a "big
honking chunk O ram" is creating an array, and using two loops to walk
through it, then interchanging the order of the loops. Same memory
access, one just takes, well, a little bit longer than the other.
I sort of hid the pointer stuff in the matrix setup anyway, and then I
roll it out. It's not too painful, and as long as you talk about it
carefully, they seem to get it (or at least not struggle with it).
> give them a simplified overview of "assembloid" -- a ten instruction
> assember that does nothing but load, store,
> add/subtract/multiply/divide, compare (x3), and branch that helps them
> understand what compilers are actually doing in there, it will doubtless
> help them with both why pointers are astoundingly useful and how/when to
> use them.
I preferred the "pragmatic" examples: those focused upon a particular
problem, and used that problem as the template to discuss how to access
particular things. Once you get them mentally breaking down the
problem, they naturally ask the "how do I" questions, which are a bit
easier to answer than the "why" questions.
>> Sum reductions look the same in all languages. And they can be done
>> incorrectly in all languages :(
>
> Which is the one reason that they DO need at least the first couple of
> chapters of real numerical methods somewhere in there. Fortran
> encourages you to think that there is a standard FORmula TRANslation for
> any equation based algorithm, and of course in once sense there is. If
> you fail to ever learn the risks of summing e.g. alternativing series
> with terms that mostly cancel, one day you are bound to e.g. sum up your
> own spherical bessel functions from the ascending recursion relation and
> wonder why all your answers end up wrong... especially when it WORKS for
> the first three or four values of \ell.
The example I showed in the MPI class was this:
program sum
real*4 sum_x,sum_y
integer i,N
N=100000000
sum_x=0.0
do i=1,N
sum_x = sum_x + 1.0/float(i)
enddo
print *,' sum = ',sum_x
sum_y=0.0
do i=N,1,-1
sum_y = sum_y + 1.0/float(i)
enddo
print *,' sum = ',sum_y
print *,' difference = ',sum_x-sum_y
end
Compiling and running this usually gets people's attention
landman at lightning:~$ gfortran sumfs.f
landman at lightning:~$ ./a.out
sum = 15.40368
sum = 18.80792
difference = -3.404236
Same sum, just done in different orders. Yes it is a divergent series
in general, but that isn't the reason why you get this difference. Its
all about the roundoff error accumulation. You see this in every
language.
The issue is that even good languages can "hide" bad algorithms. Its
the algorithms that matter. FWIW: the second sum is much closer to what
the double precision version will report.
>
> rgb
>
--
Joseph Landman, Ph.D
Founder and CEO
Scalable Informatics LLC,
email: landman at scalableinformatics.com
web : http://www.scalableinformatics.com
http://jackrabbit.scalableinformatics.com
phone: +1 734 786 8423
fax : +1 866 888 3112
cell : +1 734 612 4615
_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
!DSPAM:47436b2d228533022792082!
More information about the Beowulf
mailing list