ArcSin timings

[jj2007]

Was missing MbProHeap initialization:

Code: [Select]

  ifdef MbBufferInit
call MbBufferInit
  endif


Did you call ArcSinInit before ShowCpu? Normally the Init macro takes care of all that, but my timings template keeps the option open to run it without MasmBasic, so I chose the ifdef MbBufferInit instead.

[HSE]

Did you call ArcSinInit before ShowCpu? Normally the Init macro takes care of all that, but my timings template keeps the option open to run it without MasmBasic, so I chose the ifdef MbBufferInit instead.

Essentially is the code you posted. The MasmBasic book is not so clear 

BTW FastMath name sound nice, but is a little misleading. Perhaps MathLUT or something like that, because is a look up table creation macro, not fast calculation. 

[jj2007]

BTW FastMath name sound nice, but is a little misleading. Perhaps MathLUT or something like that, because is a look up table creation macro, not fast calculation. 

If it gives you a factor 8-12 faster math, then the name is not that important ;-)

[daydreamer]

originally made for Guga's color conversions
SIMD taylor version

Code: [Select]

I love SIMD
0.234714
0.61685
0.380504
0.234714
0.144784
2!,4!,6!,8!
0.5
0.0416667
0.00138889
2.48016e-05
cosine result :0.707426
sine result :0.707107
arcsine result:0.900242
times x:1000000
clock cycles :55624547
cycles/loop :55


[HSE]

If it gives you a factor 8-12 faster math

Not relly.

I'm thinking the equations (without presition acount) :
 

•   Time_of_building_per_access = Time_to_build_table/Number_of_accesses_per_program
•   FactorJJ = Time_of_calculation/(Time_of_access  + Time_of_building_per_access)

 

Indiference point is replacing around 25250 calculations. In this point factor is 1.

[jj2007]

It takes one millisecond to build the table, Héctor. The more complex the mathematical function is, the more you can gain with FastMath

[HSE]

The more complex the mathematical function is, the more you can gain with FastMath

Only if you are calling the table beyond indiference point 

[daydreamer]

It takes one millisecond to build the table, Héctor. The more complex the mathematical function is, the more you can gain with FastMath

But if you make tables in Workerthread, while windows main thread creates and loads lot of things when it starts,you wouldn't notice the milliseconds it takes for make one or several tables

[HSE]

But if you make tables in Workerthread, while windows main thread creates and loads lot of things when it starts,you wouldn't notice the milliseconds it takes for make one or several tables

Yes, you need even more time to prepare for the game

Tables like this are very usefull in games because you don't need presition.

Only if you are calling the table beyond indiference point 

Indeed you have some profit after 50504 table access (almost double of indiference point)

[jj2007]

Indeed you have some profit after 50504 table access (almost double of indiference point)

Ok, put Step 0.5 in ArcSinInit and do your optimisation again

[HSE]

Ok, put Step 0.02 in ArcSinInit and do your optimisation again

I you don't need any precition you just could put any number as a solution, that could be even faster 

[jj2007]

If you don't need precision, check if it's still good enough with Step 0.5:

Code: [Select]

ArcSinInit:
  NanoTimer()
  FastMath ArcSin ; define a math function
For_ fct=0.0 To 1.0 Step 0.1
fld fct
fstp REAL10 ptr [edi]
void Arcsinus(fct)
fstp REAL10 ptr [edi+REAL10]
add edi, 2*REAL10
Next
  FastMath
  PrintLine NanoTimer$(), " for initialising the FastMath macro"
  For_ fct=0.05 To 1.0 Step 0.1 ; compare the exact value with the estimate
PrintLine Str$("%3f\t", fct), Str$("%9f\t", Arcsinus(fct)v), Str$("%9f", ArcSin(fct)v)
  Next
  retn
Internally, FastMath uses SetPoly3. It's a fairly sophisticated LUT

[HSE]

Hi JJ!

With step= 0.1 you can have an absolute error= 5.6 x 10⁰ (relative error is 9.6% in that point). That is very big, especially  compared with usual default: absolute error = 1.0 x 10^-6. 

Then first you have to find step size for presicion you need, and second you have to choose between direct calculation or table depending on number of access to solution.

Regards. HSE

[jj2007]

Right, 9.6% is quite big. Use 0.01 instead, the table gets created in less than 100 microseconds, and the error is 1% max.

If that is not precise enough, go for 0.001:

Code: [Select]

Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz (SSE4)
202 µs for initialising the FastMath macro
0.0500  2.86598398      2.86598398
0.150   8.62692656      8.62692656
0.250   14.4775122      14.4775122
0.350   20.4873151      20.4873151
0.450   26.7436840      26.7436840
0.550   33.3670130      33.3670130
0.650   40.5416019      40.5416019
0.750   48.5903779      48.5903789
0.850   58.2116694      58.2116729
0.950   71.8051277      71.8051861
202 microseconds, or 0.2 milliseconds. Given that some of my "professional" software needs minutes to start, I start wondering what is the motivation behind your critical comments, Héctor

[HSE]

I start wondering what is the motivation behind your critical comments, Héctor

Just beating what I can. It's the laboratory:

Algorithm and code design research laboratory. This is the place to post assembler algorithms and code design for discussion, optimisation and any other improvements that can be made on it. Post code here to be beaten to death to make it better, smaller, faster or more powerful. Feel free to explain the optimisation methods used so that everyone can get a feel for the code design.

Tables are interesting tools, especially if you macro make so easy to create, but how to build it and when to use it deserve some considerations.