Hacker News Reader

Comment by faeyanpiraat | Hacker News Reader

Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)?

If not then what is the limiting factor?

View on HN

Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel.

WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but even so it's still totally possible and worthwhile because you can easily get 20 times the performance in many cases and handily beat native CPU code even on the web.

Hmm the UI is super unresponsive for me. As in, I try to move a slider, I can't tell where it's moving to... then I let go and it's somewhere I didn't expect.

Latest Firefox, Windows 10, Radeon RX 6700XT 16GB.

Do other WebGL 2 demos work well for you? Does it work in Chromium?

I haven't tested the code extensively so I'm sure it's broken in some configurations. It's just a proof of concept demo for now.

Ah sorry - disregard. I had a background process gobbling up GPU, and now I can use it in Firefox or Edge.

I do find it confusing, as I can put in numbers that get me well below a 3% withdrawal rate, but still have only 40% success rate. But I'm probably misunderstanding some of the mortgage sliders.

Yeah, it's confusing for sure. One day hopefully I'll have time to put a real UI on it. Right now it's assuming you buy a house with a mortgage (and property tax and yearly maintenance costs) at the same time as you retire. Put the house price to zero to eliminate all that. Also the expenses slider is before tax, so the tax rate slider influences how large your withdrawals actually are. The total withdrawal per year is displayed near the bottom.

I'm on Windows 11 with a Radeon RX570 8gb and it runs fine under Edge.

On Firefox it's way laggier but still usable.

This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well.

WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.

Isn't there something like SciPy which you can run on WebGPU?

At this point, there are very few tools actually running on WebGPU, as it's too new. One to watch for sure is IREE, which has a WebGPU backend planned and in the works.

There is wonnx a rust based webgpu enabled onnx runtime for ml stuff.

https://wgpu-py.readthedocs.io/en/stable/guide.html :

> As WebGPU spec is being developed, a reference implementation is also being build. It’s written in Rust, and is likely going to power the WebGPU implementation in Firefox. This reference implementation, called wgpu-native, also exposes a C-api, which means that it can be wrapped in Python. And this is what wgpu-py does.

> So in short, wgpu-py is a Python wrapper of wgpu-native, which is a wrapper for Vulkan, Metal and DX12, which are low-level API’s to talk to the GPU hardware.

So, it should be possible to WebGPU-accelerate SciPy; for example where NumPy is natively or third-partily CUDA-accelerated

edit: Intel MKL, https://Rapids.ai,

> Seamlessly scale from GPU workstations to multi-GPU servers and multi-node clusters with Dask.

Where can WebGPU + IDK WebRTC/WebSockets + Workers provide value for multi-GPU applications that already have efficient distributed messaging protocols?

"Considerable slowdown in Firefox once notebook gets a bit larger" https://github.com/jupyterlab/jupyterlab/issues/1639#issueco... Re: the differences between the W3C Service Workers API, Web Locks API, and the W3C Web Workers API and "4 Ways to Communicate Across Browser Tabs in Realtime" may be helpful.

Pyodide compiles CPython and the SciPy stack to WASM. The WASM build would probably benefit from WebGPU acceleration?

Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch processing.

Yes. Probably the single most effective use of the GPU for audio is convolutional reverb, for which a number of plugins exist. However, the problem is that GPUs are optimized for throughput rather than latency, and it gets worse when multiple applications (including the display compositor) are contending for the same GPU resource - it's not uncommon for dispatches to have to wait multiple milliseconds just to be scheduled.

I think there's potential for interesting things in the future. There's nothing inherently preventing a more latency-optimized GPU implementation, and I personally would love to see that for a number of reasons. That would unlock vastly more computational power for audio applications.

There's also machine learning, of course. You'll definitely be seeing (and hearing) more of that in the future.

Already on it! https://github.com/webonnx/wonnx - runs ONNX neural networks on top of WebGPU (in the browser, or using wgpu on top of Vulkan/DX12/..)

Probably possible, but you would really need some more concrete information.

For some easy experimentation with GPUs I would advise looking at Futhark. It's super easy to setup and get started.

https://futhark-lang.org/

GPUs are largely best suited for providing high throughput for doing similar computations across wide datasets. So if you can break down your algorithm into a series of steps which are largely independent and have limited flow-of-control it might be well suited to the task. If you need to have a lot of random access, or branching logic, it may not work so well. But often times it's possible to re-structure an algorithm designed for CPU to perform better on GPU.

But how many stocks even are there? You might not even have enough parallel operations to saturate a modern GPU.

Out of curiosity, why use WebGPU for this? If you're really trying to do something high performance, why not reach for something like CUDA?

We have a few examples of time series data processing in Hal9 with WebGL (no support for WebGPU just yet):

- Simple regression with TensorFlow.js: https://hal9.com/hal9/historic-temperature-analysis - LSTM with TensorFlow.js: https://hal9.com/hal9/bitcoin-prediction - ARIMA with Pyodide.js: https://hal9.com/hal9/ai-fundamentals-arima

If you have question or would be open to considering using Hal9 to do time series analysis in JavaScript, let me know! You can find me in Twitter at https://twitter.com/javierluraschi

Depends what you do the analysis with. The state of the art is a neural network, and the best there are transformers which do parallelize (as opposed to the previous generation, LSTMs which don't parallelize as well)

The limiting factor is usually parallelism, to utilize a GPU well you need to be running something on the order of 10000 threads in parallel.

Reply on news.ycombinator.com