Ben Chambers <ben### [at] pacificwebguycom> wrote:
> You ARE making approximations.  You're not approximating the underlying
> shape, however, but you are approximating the values of the cos() function.
Hi,
I really don't see where is the approximation you talking about...
Just to let you know that the original parser (and that's the case of all
mathematical parsers) are using an internal stack to save the intermediate
values. So, by saving the value of cosinus fct (as DOUBLE precision
variable), I'm not doing something that the original parser wasn't doing.
The actual parsers are doing the same thing by storing intermediate values
in the stack. What you're saying can be true if the CPU holds an internal
fct defined like the original isosurface formulas but that is not the case
because the CPU implement only basic fcts like "+", "-", cos,...
> Also, this kind of method can wreak havoc (and actually cause a speed
> penalty) in multicore architectures.  First, this data needs to be held
> in memory (and to be truly effective, it *MUST* fit within the L1 cache,
> otherwise it will be slower than the native function call).  Fine when
> you have a few hundred values, even a few thousand.  But how many values
> do you need for the accuracy to be acceptable?  100,000?  1,000,000,000?

You're right about the importance of the cache (I explained that in previous
messages) but for this too I have a solution : I'm using a 64 parallel
instructions inside the parser. I know that the CPU is never looking for a
single value to store in the L1 cache(when it needs a value, it's storing a
bunch of consecutives ones in L2 in case it needs another values near the
original one). The 64 values have then a big chance to be stored "in the
same time" in the cache L1 and then to be processed at the speed of light.
Tests shows that a 64 parallel operations inside the parser is almost as
fast as a 512 or even a 1000 operations and this is due to the amount of
memory cache inside the CPU. CPU have more and more L1 cache memory, so
this "technologie" is working good now, but will work even better tommorow:
It's somehow a "scalable" technic

> I'm saying that if you want anything even
> close to accurate enough for POV-Ray, your dataset would be too large to
> be usable, and you would be better off with the original functions.
Sorry to say it again, but I really don't see from where the loss of
precision for PovRay can came from in case it's using this technic: In the
deepest level, PovRay is using "only" the CPU "welded" fcts...
Cheers,
Taha

Post a reply to this message