[Beowulf] Teaching Scientific Computation (looking for the perfect text)

[Joe Landman]

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