Re: DSP API proposal/draft

Hello again Jens,

I have made some updates to the DSP API specification (as usual:  
http://people.opera.com/mage/dspapi/ ), and I have included some of  
your proposals.

One of the most important changes is the addition of a "Numerical  
accuracy" section. I fear that it is not 100% complete, but I tried to  
formalize my intentions there (i.e. performance is more important than  
consistent accuracy).

Here are a few comments...

Citerar Jens Nockert <jens@nockert.se>:

> The main issues with the specification is that it rigidly specifies   
> certain things, while leaves other things floating. It also rigidly   
> specifies things in ways that seem to remove any chances of   
> optimization on systems that need it the most.

I hope the latest draft should be clearer on this point (there are  
probably still a few things to fix, though).

> It doesn't seem to allow for FMA (fused multiply-add, a * b + c with  
>  a single rounding) and hardware without support for subnormals for   
> example, both of which could improve performance.

Should be fixed, but please let me know if I've missed something.

>> o There are three interfaces: DSP, FFT, Filter
>
> Wouldn't it make sense to split DSP up into DSP and Vector or  something,

Could be, but I wanted to reduce global name space pollution.

> You could also pick the more generic DFT name, and not define
> which method the DFT is calculated with.

Makes sense. Haven't done that change yet though, since FFT has such a  
strong identity (it's e.g. used by all the DFT C/C++ libraries that I  
know of, in Matlab, etc).

Does anyone else have an opinion here?

> The current API is minimal and simple to implement, except for FFT   
> (and to some extent the Filters.) Adding support for   
> double-precision would make it _slightly_ larger, but I doubt it   
> would make much difference.

I think it would essentially make the implementation twice as complex  
(in terms of code size, testing effort, etc), since you'd likely want  
two different code paths for single and double precision (e.g. SSE and  
SSE2).

> At some point later, there could be an interface to save execution   
> plans. If any browser implements it in a way so that saving   
> execution plans make sense (linking to FFTW etc?)

The current specification should allow execution plans to be saved in  
an FFT object, or were you thinking of something else (or did I miss  
something).

[Comments on https://gist.github.com/3199146 ... ]

Generally, the spec is now much more permissive on things like FMA and  
other optimizations. Is it too permissive? (my only fear right now is  
that testability might be a bit more difficult)

> Trigonometry and Other Elementary Functions
>
> These are not actually specified in ES, only their names, so we may
> need to define them here; since everything else seems to aim for quite
> rigid specification.

I kind of liked the specification in ES, usually stating  
"implementation-dependent approximation", plus special case handling  
(NaNs etc).

> Since we're using single-precision, while Math uses double-precision,
> you would otherwise need to use double intermediates and therefore
> round twice if you follow the current wording of the spec.

Added note on use of single precision in latest draft.


> random
>
> What are the requirements, is it required to return the same result as
> ES Math.random() ran in a scalar loop? Is it allowed to use another
> parallel algorithm for generation? Is it allowed to use a different
> seed?

The specification only requires that random() must use the same  
DEFINITION as the one given in the ES specification. It does not have  
to use the same IMPLEMENTATION as the ES engine from which the API is  
accessed. This is an important feature, IMO.

> sum
>
> The implementation is not trivial, you should specify a method that
> sets the minimum precision at least.

Added a recommendation. Thoughts?


Regards,

   Marcus

Received on Sunday, 12 August 2012 08:43:16 UTC