Symbolic pkg vpa trig speed

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Symbolic pkg vpa trig speed

Colin Macdonald-2
In a bug report Dan asked:
> Just curious, from what you know about the arbitrary precision
> library, is it slow to compute trig functions out to sixteen digits
> compared to the floating point library?

Its currently a bit hard to tell, especially as Symbolic's handling of
large arrays of doubles is non-optimal (pending pytave GSoC work!) but
probably hundreds of times slower.

x = rand(10, 10);

% make vpa objects from x in 16, 32, 48 (of course these will not
magically have extra precision, its just for timing)
xv16 = vpa(x, 16);
xv32 = vpa(x, 32);
xv48 = vpa(x, 48);

tic; sin(x); toc
Elapsed time is 0.000461817 seconds.
tic; sin(xv16); toc
Elapsed time is 0.156639 seconds.
tic; sin(xv32); toc
Elapsed time is 0.118703 seconds.
tic; sin(xv48); toc
Elapsed time is 0.175145 seconds.

The xv16 = bit seems take longer than I expect..., I filed
https://github.com/cbm755/octsympy/issues/499)

best,
Colin

Reply | Threaded
Open this post in threaded view
|

Re: Symbolic pkg vpa trig speed

LachlanA
Colin Macdonald-2 wrote
x = rand(10, 10);

% make vpa objects from x in 16, 32, 48 (of course these will not
magically have extra precision, its just for timing)
xv16 = vpa(x, 16);
xv32 = vpa(x, 32);
xv48 = vpa(x, 48);

tic; sin(x); toc
Elapsed time is 0.000461817 seconds.
tic; sin(xv16); toc
Elapsed time is 0.156639 seconds.
tic; sin(xv32); toc
Elapsed time is 0.118703 seconds.
tic; sin(xv48); toc
Elapsed time is 0.175145 seconds.

The xv16 = bit seems take longer than I expect...
If the xv16 case was the first time sin was called for a symbolic variable, the time may include loading some code into memory, or other initialization.  What happens if you do them in the reverse order?

Cheers,
Lachlan
Reply | Threaded
Open this post in threaded view
|

Re: Symbolic pkg vpa trig speed

Daniel Sebald
On 07/06/2016 09:02 PM, LachlanA wrote:

> Colin Macdonald-2 wrote
>> x = rand(10, 10);
>>
>> % make vpa objects from x in 16, 32, 48 (of course these will not
>> magically have extra precision, its just for timing)
>> xv16 = vpa(x, 16);
>> xv32 = vpa(x, 32);
>> xv48 = vpa(x, 48);
>>
>> tic; sin(x); toc
>> Elapsed time is 0.000461817 seconds.
>> tic; sin(xv16); toc
>> Elapsed time is 0.156639 seconds.
>> tic; sin(xv32); toc
>> Elapsed time is 0.118703 seconds.
>> tic; sin(xv48); toc
>> Elapsed time is 0.175145 seconds.
>>
>> The xv16 = bit seems take longer than I expect...
>
> If the xv16 case was the first time sin was called for a symbolic variable,
> the time may include loading some code into memory, or other initialization.
> What happens if you do them in the reverse order?

Also, that native width of the CPU variables is likely 32 so there may
be less machine cycles needed for 32 if 16-bit require rounding or
something.  Try cputime() rather than clock time too:

stime = cputime();
<test code>
cputime() - stime

Dan

Reply | Threaded
Open this post in threaded view
|

Re: Symbolic pkg vpa trig speed

Colin Macdonald-2
On 06/07/16 20:23, Daniel J Sebald wrote:
>>> The xv16 = bit seems take longer than I expect...
>>
>> If the xv16 case was the first time sin was called for a symbolic
>> variable,
>> the time may include loading some code into memory, or other
>> initialization.
>> What happens if you do them in the reverse order?

Thanks, but I meant the conversion from double to vpa takes too long: an
order of magnitude longer than computing sin.

I think its just overhead because of a rather horrid loop over all
elements done in vpa.m: easily fixable, but I may want to do it with pytave.

Colin