glathoud / flatorize Goto Github PK

See if we can derive D code generation without too much pain, most likely by cloning flatorize_c.

background: we already have support for basic types in the C plugin. We could reuse this to generate asm.js code, and compare the performance:

• with the original JS code.
• with the corresponding C code.

So that we can integrate flatorize's generated code directly in transfun: glathoud/transfun#7

...with the recent asm.js plugin code, and since code generation now runs fast, make a single python script to run it all.

2014-12-01 note about GCC:

• one or two years ago I could compile the stuff under explore/C with -O3 without any problem.
• in an old VM with an old GCC I had a strange pointer "unwanted decrement bug" when returning the struct from the malloc helper. Workaround: write the struct with the array float io_array[] first, then declare the convenience pointers float *. The bug disappeared.
• on my Ubuntu laptop with GCC 4.8.2, the newly generated DFT1024 "big code" cannot compile anymore with any of -O1, -O2 or -O3. Neither compile the above-mentioned old stuff under explore/C with -O1, -O2 or -O3 - code that hasn't changed!
• without those options the C code is running 2x slower than Chrome 39.
• slowly getting fed up with GCC.
• since the general spirit of flatorize is to get a "fast enough" performance in a generic and portable manner, i.e. reliably, i.e. also a "fast enough" software development experience, and not to get the absolute fastest performance at all costs, I am considering alternatives like clang.

Now with clang: Speed comparison JavaScript vs. C:

On an Ubuntu laptop for the (heavy) DFT1024 case I measured a speed of about 47800 iterations per seconds for Chrome 39 and about 60000 iterations per seconds for clang.

This is fast enough for me to do scientific computation in the browser with a much much faster and simpler developement process (JavaScript) than in C.

Just for fun compare on the DFT1024 test case:

• the generic flatorize_c code generation + clang compilation, as well as with GCC (see issue #2 with GCC, but does not always happen)
• the specific FFTW + gcc compilation

misc:

• split dftrealfloat and dftrealdouble for a fairer comparison with FFTW
• in the dftrealdouble case this excludes naive_v8 and flatorize_v8 since they only use 32-bit floats.
  http://www.fftw.org/doc/Precision.html#Precision

for all JS files written until now: flatorize, flatorize_asmjs, flatorize_c, flatorize_type_util ...

See if we can derive OCaml code generation without too much pain, most likely by cloning flatorize_c.

(see ./lib/flatmat)

background: when matrix/vector dimensions are unknown at compile time, but one would like to benefit from the high speed code generated for known dimensions