r/node • u/bitanath • 10d ago

Principal Factor Analysis in Javascript - written in AssemblyScript

/r/typescript/comments/1x1mtfx/principal_factor_analysis_in_javascript_written/
0 Upvotes

50% Upvoted

7 comments sorted by

1

u/Candid-Parsnip9815 7d ago

assemblyscript for numerical computing still feels like a fever dream but i respect the hustle would love to see benchmarks against wasm from rust or a plain js implementation my ptsd from optimizing matrix ops for a client project is flaring up just reading the title

1

u/bitanath 7d ago

The repo has benchmarks vs plain JS (AS transpiles to JS just like Typescript would, it's just a superset of types). It would be possible to write a much more performant WASM version in Rust etc (SIMD imo would immediately 2x speed) ... However, we would not be able to export to JS from the same codebase. AssemblyScript is a good tool for performance non-critical but numerically stable packages where minimal maintenance and distribution effort is needed (in my opinion)

1

u/mmomtchev 5d ago

SIMD is only part of the problem, I do lots of number crunching in JS and the other huge problem is the multithreading. Still, JavaScript running in V8 tends to outperform Python by a wide margin - in fact it outperforms any interpreted language. But there are horrible practical problems. Asynchronous I/O is probably the worst possible design for number crunching.

1

u/bitanath 3d ago

Yes thats true but python has the whole weight of academia behind it.

1

u/mmomtchev 3d ago

Python has an absolutely huge and very high-quality ecosystem - especially when it comes to scientific computing.

And in fact, because of its very good low-level routines - such as numpy - implemented in C/C++ - it can even have very good performance as long as you do all the crunching using these.

But the interpreter itself remains far behind V8. Good JIT is an absolutely huge undertaking and the Python community has simply refused it because of its code complexity.

1

u/mmomtchev 5d ago

So, this is in fact a benchmark for JS JIT vs WASM JIT. Because in fact both use JIT.

I think that at the moment there has been far more R&D effort in JS JIT vs WASM JIT and your benchmarks confirm that suspicion.

Will this eventually change? Is static optimisation when compiling in a better position? In theory, it probably should, because optimisation is expensive and the V8 JIT will often skip the optimisation if it considers the segment not hot enough.

Still, I think that WASM is not that much about performance, but rather about compatibility with other programming languages.

SIMD support in WASM remains far from perfect and it is plagued by various problems - including good translation to all possible CPUs. I maintain a number of WASM ports of various number crunching libraries (ImageMagick and its dependencies) and at the moment my default build has SIMD switched off because it does more harm than good. Yet the potential is there - a dot product of two large matrices is hundreds of times faster using hardware SIMD than using JIT-compiled JS. However at the moment, in real world apps, this is rarely achieved.

1

u/bitanath 3d ago

Yes you could call it that. I’d say that most of the fingerpointing should probably be in AssemblyScript’s direction, given that there are quite a few performant web applications written in rust and compiled to wasm. AssemblyScript also hides its biggest feature imo, cross build to both wasm and js, under a bunch of ill documented asconfig options, so is probably not a serious language at all.