Re: Precomputing time for Table Lookup method
- From: "robertwessel2@xxxxxxxxx" <robertwessel2@xxxxxxxxx>
- Date: 25 Feb 2006 01:53:55 -0800
vladimir@xxxxxxxxx wrote:
First, you're posting on Usenet, so please quote properly. In many
cases posts are received/viewed without the context of the thread
they're in.
OK! You have a good sense of humor, but the restriction of the ROM
capacity is more evident, than the precomputing time restriction.
In 1985 the capacity of floppy disk was 1,44 Mb, today the DVD capacity
may be 14 Gb,
that is, it increased in 10**4 times. BUT the time required for one
function evaluation decreased in not so much time.
So technoligical progress rans more quickly, than time evaluation
progress.
I'm not sure I like the counting the capacity of those two rather
disparate media types, since both evolved under a variety of
constraints that are totally unrelated to capacity. OTOH, four orders
of magnitude is not too far off, if a little low. A better comparison
is hard disks, which went from ~40MB full height 5.25" inch units in
1985, to 500GB 1" / 3.35" now, for something like a 90,000 times
density increase (and an even bigger cost per bit reduction). So I'd
call the increase in storage density over that timer interval closer to
five orders of magnitude.
On the computational side, I agree, progress has been a little slower,
but In 1985 the very first 16MHz 386s became available (at least as
demos, they didn't really ship in volume until '86). The fastest
dual-core P4s or Athlons are on the order of four magnitudes faster.
Again, if we take price into account, the improvement is an extra 5x,
or thereabouts.
Many people are absolutely sure that the restriction of the direct
Table Lookup method
is in only technology ROM possibilities. BUT the precomputing time
plays may be more important role.
In my time, when I researched the CORDIC (Volder algorithm) method
http://en.wikipedia.org/wiki/CORDIC
for function evaluation many people said, that in the nearest future
Table Lookup method would be the best and universal method for any
functions.
But I proved, that is not true.
Table lookup may be (or may soon be) plausible for singles, but
certainly not for doubles. But I still think storage capacity is the
bigger issue. As the developer you only have to buy the storage to
hold the precomputed table (approximately) once, plus the computing
power to do the, *ahem*, precomputation. Each user has to buy the
storage. As a quick calculation, the 300 million disk drives needed to
hold 2**64 doubles would cost on the order of $50 billion (I'm assuming
you're going to get a quantity discount). Using your 500,000 year
example, you could buy five million PCs to do the precompuation in a
month or so, and it would only cost you $5 billion. Clearly computing
cost is not the current limiting factor. If we look ahead another
couple of decades, and assume disk capacity and CPU performance are
going to again increase 5 and 4 orders of magnitude (neither is likely,
but...), then the cost of the required storage goes to $500,000 and the
computational cost to $500,000. That's still highly dominated by
storage, not computation costs, since people will need to buy many
instances of the storage while you still need only one computational
instance.
Of course if we're talking about memory, that's a couple or orders of
magnitude further behind.
.
- Follow-Ups:
- Re: Precomputing time for Table Lookup method
- From: vladimir
- Re: Precomputing time for Table Lookup method
- References:
- Precomputing time for Table Lookup method
- From: vladimir
- Re: Precomputing time for Table Lookup method
- From: robertwessel2@xxxxxxxxx
- Re: Precomputing time for Table Lookup method
- From: vladimir
- Precomputing time for Table Lookup method
- Prev by Date: Re: Precomputing time for Table Lookup method
- Next by Date: Latency
- Previous by thread: Re: Precomputing time for Table Lookup method
- Next by thread: Re: Precomputing time for Table Lookup method
- Index(es):
Relevant Pages
|
|