3 ms·
That's graphistry's last 7+ years, where we do frontend CPU/GPU visual analytics experiences <> GPU server processes. 100% endorse this design, opens a lot :)
by lmeyerov 5y ago
That's graphistry's last 7+ years, where we do frontend CPU/GPU visual analytics experiences <> GPU server processes. 100% endorse this design, opens a lot :)
Main tweak is our model grew to "small client browser GPU/CPU session <> serverside multi-node multi-GPU time sharing." Current cloud services (lambda etc) fail here: cold-start, mostly CPU, etc, vs bursty sticky GPU sessions. A lot more power when you can scale resource use... so 1 server process is kind of dinky. Good backend abstractions are tricky here though, so starting with 1 process makes sense as they figure out a sustainable revenue model, e.g., powering demanding visual intelligence apps is vastly different from powering commodity netlify CRUD apps.
- paulgb 5y agoThanks, that means a lot coming from one of the pioneers of the approach! The fraud analysis use-case is actually semi-based on a real world experience I had building tools for fraud detection in adtech in 2013, where I often found myself taking a time-slice of a graph and loading it up in Gephi to compute a layout. I'd written other browser-based tools to make my work easier, but because I was shoehorning everything into a stateless backend, computing a large graph layout as part of it was tough. So when I saw what you were up to with Graphistry, it immediately resonated with me (though I was no longer working on fraud at the time).
- lmeyerov 5y agoSuper cool! Funny enough... We've stacked up ~4 incarnations of how we back our different kinds of sticky live GPU session workloads, and ironically, a big one we aren't doing but I keep wanting to see solved is user-defined GPU containers (vs our own). So, good luck!