5 ms·
Did you experiment with doing it JS-only prior to the C++ version? If so, what kind of performance increase did you see with WebAssembly?
by stupidcar 9y ago
Did you experiment with doing it JS-only prior to the C++ version? If so, what kind of performance increase did you see with WebAssembly?
- dman 9y agoNo, when I first prototyped it I had written a Python version initially. From memory the first C++ build was ~80x faster than the Python prototype.
- carapace 9y agoI'm curious if you did any profiling? If the intent was always to rewrite the whole prototype in C++ then it kinda wouldn't matter, eh?
- texodus 9y agoWe do some benchmarking just for catching performance regressions and validating assumptions against the non-WebAssembly version, but definitely need more in this regard. [benchmark for wasm build](https://jpmorganchase.github.io/perspective/examples/benchmark.html https://jpmorganchase.github.io/perspective/examples/benchma...)
- goatlover 9y ago80x faster than using Pandas? What if you just used the Numpy values array?
- dman 9y agoYou will get me into trouble! I said 80x faster than the Python prototype. I did benchmark this vs Pandas over the years and depending on the usecase the two codebases trade blows with each other for static data. However for streaming datasets Perspective has a large advantage over Pandas since pandas does a full group by on every update, while perspective does its work incrementally using deltas.
- spankalee 9y agoThis++ WebAssembly can be certainly faster than JS in certain situations, but well-structured, monomorphic JS with the kind of type-hints for numeric values that asm.js is based off of can be extremely fast as well. It'd be great to check the assumption that WASM is actually faster in this case, and by how much, especially given the friction of sending anything other than numbers across the JS/WASM boundary.
- kodablah 9y agoAnd to be fair, you'd have to build it with something like prepack to get some of the optimizations LLVM gives you.
- sciyoshi 9y agoI'd also be interested in some performance comparisons with a library like CrossFilter [1]. Does the improvement outweigh the penalties of crossing the JS/WebASM boundary? [1] http://square.github.io/crossfilter/ http://square.github.io/crossfilter/
- texodus 9y agoThe boundary-crossing is definitely the bottleneck right now. We are currently putting alot of work into the Apache Arrow support specifically to avoid this crossover, which will allow us to send data from the server in binary and avoid parsing in the browser.
- BenGosub 9y agobringing Apache Arrow in the browser alongside wasm is exciting to say the least! Amazing capabilities are coming to browsers...
- lmeyerov 9y agoWe (Graphistry) recently contributed a native JS reader/writer into the Apache Arrow project, so may help both teams! We did it as legwork for our beyond-native efforts (GPU cloud streaming) and taming our JS datatypes, so similar needs here I'm guessing! Funny enough: was in NYC today talking with banking teams about related tech. Too bad we didn't know about this effort, would have loved to meet!