Hacker News Reader

Comment by dman | Hacker News Reader

I wrote the C++ part of this codebase, would be happy to answer any questions about it here.

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?

No, 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.

I'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?

We 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/benchma...)

80x faster than using Pandas? What if you just used the Numpy values array?

You 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.

This++

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.

And to be fair, you'd have to build it with something like prepack to get some of the optimizations LLVM gives you.

I'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/

The 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.

bringing Apache Arrow in the browser alongside wasm is exciting to say the least! Amazing capabilities are coming to browsers...

We (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!

Drop me a note the next time you are in NY, would love to meet up.

Yes, this is the library we use.

We have met before actually, you did a demo at JPM in midtown several years back. Graphistry has come a very long way since then - impressive work!

Ah, small world. That was probably when we first started on client<>server GPU streaming. Looking forward to digging into the Perspective source!

Can you elaborate on how that could work? Does arrow really allow for abstracting away the need for serialization even in JS - server scenarios? I though it was more of a shared memory data frame utility ?

There is an early arrow example in the examples package - superstore-arrow.html. The idea is that, instead of converting your data to internet->text->JSON->ArrayBuffer, you just keep the data in binary and write it directly into the C++ heap ArrayBuffer as-is. We currently do not read this in C++ directly for various reasons related to how emscripten allocates memory, but the general idea is the same.

In addition to what texodus has said below, Crossfilter only implements a small subset of what perspective provides. For example, no streaming (although there is a related project from the Heer lab that supports incremental updates - https://github.com/jheer/datavore), only a single level of grouping, only in 1 dimension, and you can only support 16 dimension fields at once (without increasing a constant in the codebase).

I see it's possible to embed it in jupyterlab, it seems to do a lot:

* grid format * graph format * actual pivoting of data

Is that right?

It's using webassembly so in effect to do the pivot you must have created functions that exist in pandas?

Has anyone ported pandas to webassembly?

Is the grid editable? What are you using to create your output, html or canvas or something?

I realise I could look this stuff up but since you asked..

I believe you'd need to port Python to WebAssembly to make much use of pandas - unaware of any projects attempting the former.

The grid is just a plugin for the excellent [Hypergrid](https://github.com/openfin/fin-hypergrid), which is editable, but you'd need to manually push those edits back to the engine for now.

which answers my other question, so it's canvas?

The frontend is actually pure JS/HTML - the WebAssembly part is just the data engine, and runs in a WebWorker for CPU isolation.

Hypergrid is a canvas-based renderer, yes.

Nuitka can compile Python to LLVM IR, which can be compiled into WASM, I think.

As historical background: Python was one of the early emscripten asm.js experiments: https://github.com/kripken/emscripten/tree/master/tests/pyth...

WebAssembly code can talk to the rest of your JS (and therefore asm.js) code, right?

So PyPy.js runs Python in the browser via asm.js:

http://pypyjs.org/

https://github.com/pypyjs/pypyjs

Livebook uses PyPy.js to make a Jupyter-like notebook that runs entirely in the browser, and includes pandas:

https://livebook.inkandswitch.com

https://github.com/inkandswitch/livebook

And random plug for Observable in case you haven't seen it, a Jupyter-like Javascript environment, completely in the browser:

https://observablehq.com

Briefly in the animation I see there's hierachical (or multi-dimensional) data used. Could you tell me about what sort of data (statistics, monitoring) this supports?

Also, what methods are available for getting data streamed [into Perspective]? I'm skimming through the docs, but am not quite getting it...

[edited for clarity]

Right now, you can call a load() or update() method on an engine or widget to pass JSON, CSV or Apache Arrow data (as an ArrayBuffer) to the engine.

Apologize for the documentation clarity - this is our first release and very much under active construction!

Ok, thank you for this. I'll have to see some time about that Arrow support. JSON and CSV is already plenty enough.

I didn't have time for a proper look yet, so no worries. If at all possible post the code and data (or something like it) that is in those animations you have. That would perhaps allow users to dive in by tinkering here and there.

Just stalked you on linkedin with a similar question, but I was wondering if you were involved with the actual process of getting the library open sourced, and how that works at a large security focused company like JPMorgan Chase. (former Chase employee)

Thanks for taking questions. For a back end developer that's watching the front end landscape change from afar..

Do you feel like web assembly could potentially replace JS in the future with, say, my favorite back end language of choice?

Not the op, but there's more to frontend development than JS. You need to account for the API of browsers, the DOM, CSS and the myraid of frameworks and libraries built for the specific UI requirements of frontend development (e.g. React). So even if your favorite language of choice becomes compilable to WebAssembly, you'll still be learning an entirely different way of development that will be completely unfamiliar regardless.

The only thing I see languages compiled to WebAssembly taking over is development of highly resource intensive applications, algorithms or libraries. Or if there's a quantum leap with some specific language + framework that eliminates a lot of work with current frontend development. Otherwise, there will be too much fragmentation and you'll see the regression to the mean effect as has been the case with predecessors such as CoffeeScript, Elm, PureScript, ReasonML, and every other compile-to-JS language du jour.

A paradigm shift could happen and what's cool is that it could be entirely something new. This reminds me of the early days of the WWW when the first programming paradigm was Perl/CGI, then Cold Fusion, then Legacy ASP, and then ActiveX, and so on.

The possibility of some company creating, from scratch, a new web development paradigm, given everything we know today, is exciting.

Sure, and based on historical precedent, that's almost guaranteed to happen. But I doubt it will be whatever-my-favorite-backend-language-of-choice-is and more likely some-domain-specific-language-and-new-framework. In other words, we'll all be relearning everything again 5 years from now.

Java applets were supposed to provide that in the 90s. Netscape was going to actually embed Java in the browser as an alternative to JavaScript, but there wasn't enough time, so they just shipped with JS, and Java was provided via a plugin.

As a fellow backend developer I certainly hope so. I think web assembly gets us very close. Only two things I missed were direct canvas access from C++ without going through a JS shim and access to some kind of blob storage api in the browser.

Does it support:

virtualization (showing only a view of full dataset that is updated from server on scroll)

Pivoting (multiple levels/hierarchies on rows and on columns)

Apart from features what part did you consider was the biggest hurdle? What browsers did you target?

It supports virtualization, and it is utilized by both plugins (Hypergrid and Highcharts).

N levels of pivoting on both axes.

Should work on all browsers - if not, please open an issue!

Is there a way to drill down a node dynamically, by clicking on row header during pivoting, and then see its children?

Not through the UI yet, only in the engine API - but the pivoting itself is quite fast, so should still be suitable for drilling down "on the fly" so to stpeak

By virtualization I meant also not loading entire dataset to memory, but being able to work only on a constrained view of the data. For example, database has 1TB dataset, I only view 100 MB, further columns/sections are loaded when I scroll.

It is virtual in the sense that it does not realize the entire dataset in the JS side of the WebAssembly bridge - this is a performance optimization but entirely in-memory. While you can run the engine in node.js and use it to efficiently stream updates to a symmetric engine in the browser, we do not currently implement server-virtualized views.

Though, we have quite alot of experience doing this in the past - and the design of Perspective is very much a reaction to what we learned, at lesat in regards to the typical financial dataset which is much smaller than 1TB.

What was the best/worst part about getting it to work in WebAssembly?

Best part was the validation of a design decision of having minimal dependencies. It made the web assembly port almost trivial.

Worst part (which has improved dramatically) was the rough edges in the web assembly toolchains early on.

Is Emscripten the only game in town for WebAssembly C/C++ toolchains, or are there other contenders?

As far as I know yes for C/C++ this was the only viable toolchain that is publicly available.

Even outside of C/C++, Emscripten seems to be required in some fashion for just about every "compile X to webasm". Which i'm not that happy about as it's quite heavy and takes a long time to compile, which makes it harder for newcomers to try it out because it requires a fairly large time investment to even compile hello world.

Rust’s wasm32-unknown-unknown target does not use emscripten at all. The tool cargo-web will handle the js module shims for you.

cargo-web uses emscripten under the hood.

No, he is right. cargo-web supports three backends, of which only two include emscripten and the third using a native rust backend. https://github.com/koute/cargo-web#features

Rust can be compiled to wasm without emscripten using wasm32-unknown-unknown.

Does that mean I can install cargo-web without emscripten or do I still need it even though I am not going to use it just because the two other targets use it? In other words, is emscripten an optional or a hard dependency?

Its an optional dependency. You can build without it by just using a nightly version of rust with the wasm32-unknown-unknown backend.

An example of using cargo-web with the stdweb rust project: https://github.com/koute/stdweb#running-the-examples

> Even outside of C/C++, Emscripten seems to be required in some fashion for just about every "compile X to webasm".

One exception to this is Rust's new "wasm32-unknown-unknown" target, which uses LLVM to directly generate wasm files without going through emscripten: https://www.hellorust.com/news/native-wasm-target.html

The easiest way to use it for larger projects is probably via https://github.com/koute/cargo-web, which handles a lot of packaging very nicely.

It's really nice to use, assuming you already know Rust.

Yeah I'm super excited about Rust's new webasm compiler, as well as some new-ish stuff with .Net that works without Emscripten.

I get the ecosystem is super young, but it was honestly what kept me from playing with Webasm for a while, because each time I'd sit down to play with it I'd be in for a 3 hour compile after spending an hour getting my windows machine to have the right compilers and not stomping over other things I have setup on here.

Sounds like you were seeing an old emscripten SDK bug, where it compiled LLVM+clang unnecessarily and with debug info (which is very slow).

Currently there shouldn't be anything like that, it will download a binary build of LLVM+clang for your system. It should be ready to use immediately after that download.

There is Cheerp. https://www.leaningtech.com/cheerp/

I see it's possible to convert to Numpy arrays. Is `perspective` also a Python library?

Yes for much of its life perspective has been a python library. It offers a streaming dataframe abstraction in Python. I believe the Python bindings have not been open sourced yet.

That sounds super useful. Does it create its own window as a Python library or am I missing something?

The Python bits are unreleased and the python usage is restricted to desktop visualizations, so no you are not missing anything.

Can you say how old is this codebase and what was its original business case?

Codebase started in 2013. Original business case was to allow business users to create filtered/aggregated views on top of streaming data.

What's on the roadmap?

[]

Offtopic :)

Reply on news.ycombinator.com