Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!chem.ucsd.edu!tps
From: tps@chem.ucsd.edu (Tom Stockfisch)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran vs. C for numerical work
Message-ID: <929@chem.ucsd.EDU>
Date: 7 Dec 90 08:13:13 GMT
References: <9458:Nov2721:51:5590@kramden.acf.nyu.edu> <17680:Nov2806:04:1090@kramden.acf.nyu.edu> <7200@lanl.gov> <2392:Nov2902:59:0590@kramden.acf.nyu.edu> <72@tdatirv.UUCP>
Reply-To: tps@chem.ucsd.edu (Tom Stockfisch)
Organization: Chemistry Dept, UC San Diego
Lines: 33

In article <72@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes:
>In article <2392:Nov2902:59:0590@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>>In article <7200@lanl.gov> ttw@lanl.gov (Tony Warnock) writes:
>>> There is also no storage overhead
>>>     associated with keeping arrays of pointers. For multi-dimensional
>>>     problems, this overhead could be quite large.

>>... That's true, but it's really not a problem.
>>If you have a 5 by 5 by 2 by 3 by 15 array, can you begrudge space
>>for thirty pointers so that you save 5% of your pointers

>Except for one thing. In scientific computation typical dimensions would be
>more like 1000 by 1000 by 1000 by 1000 by 50, which requires a great deal more
>than a mere thirty pointers.

Lets see, assuming 4byte single precision elements,
one of your "typical" objects is... 200 trillion bytes!

Yow, you do some _serious_ computing!

Assuming a 4 byte pointer, the pointer overhead is still only 2%.

Oops, 32 bits can't access 200 trillion bytes.
Must be 64 bit pointers.

Ok, you have a 4% pointer overhead.



Disclaimer:    :-)
-- 

|| Tom Stockfisch, UCSD Chemistry	tps@chem.ucsd.edu