[Beowulf] computational cost (was TeX/LaTex for Ubuntu)

[Lux, Jim (337C)]

On 6/24/13 5:53 PM, "Joe Landman" <landman at scalableinformatics.com> wrote:

>[not trying to hijack the thread, just thinking about an interesting
>
>
>
>Why this is interesting, and the entre into this from the LaTeX bit, is
>that when I was starting out on my thesis research topic, the cost of
>precomputing, storing, and later retrieving specific data (integrals)
>was low compared to the computational cost of generating that data when
>needed, even though the code fundamentally favored "in-situ" generation
>(made for a cleaner design).


Same thing for FFT algorithms. If you have to compute sin and cos by
series expansion (e.g. In a library subroutine) then storing a table of
the multiplicands needed in the butterflies is useful. But if you have
hardware trig functions (e.g. As in the 80287 and later FPUs), it's
potentially faster to calculate the trig function than to do the table
lookup, if main memory is slow.  I'm sure there are other examples of this
kind of thing.  Coding the kernel of something like an FFT so that it fits
entirely in level 1 cache.


>
>Previously, in undergrad, I was working on a research project for a
>professor, and the cost of storage was gigantic as compared to the cost
>of computing (in-situ again), even though the latter took somewhat more
>time.

I once sold a very successful software system that did a brute force
sequential search (multiple keys in each record) of about 1000-2000
records, because it was a LOT faster than doing all the log(N) lookups of
record numbers in a ordered index (which would take many disk reads to
bring in the index blocks and traverse down the tree) and then merging the
results.

Instead, you could just STORE the entire search key space (about 100
bytes/record) in memory, and search the 100kbytes of RAM in BASIC using
string compares.  (this was back in the day when a 10 Mbyte hard drive on
a PC was an exotic piece of gear).  Whipped the rear of all the popular
database engines of the time (dBase, Paradox, FoxPro, etc.)  Memory is a
heck of a lot faster than disk reads..


>
>What I find interesting is how, throughout my career on the non-vendor
>side of the fence, costs of one aspect or another significantly
>influenced code and code implementation.
>
>Just some random thoughts on a warm Monday night in NY.

>From a miserably hot and humid afternoon in Virginia Beach, VA  (I *am* a
California boy, and the 35C isn't so bad, but with a RH>60% it's miserable)

Jim