GPU accelerated stock indicators

[seanpmac]

I would like to see the Stock Indicators GPU accelerated for faster signal processing.
The open source library https://www.ilgpu.net is well suited for this.
It would be great to see this library integrated with the Stock.Indicators library for optimal performance.

[DaveSkender]

I’ll take a look. Is this something that essentially requires a total rewrite of our library in ILGPU syntax?

[DaveSkender]

I was just taking a look at the samples and can’t make any sense of it. They look like machine operations to hack the GPU.

This would have to be more user friendly before I can even think about trying to implement this library. The API probably needs to be more abstracted so we don’t need to spend so much effort on the plumbing for memory management.

To start, a simpler example for those of us who are not infrastructure developers or GPU engineers would be helpful; like a simple C# method to calculate 2+2 that returns 4.

[DaveSkender]

So far, this is an very low return on effort ask. Our library is already quite fast, this looks like a huge effort to implement in its current state, and very few of our users really need it.

[DaveSkender]

Reading list:

• NVIDIA Hybridizer
• GPU programming in C#

[DaveSkender]

In doing some reading, GPU compatibility for indicators will need to be an entirely new library because it requires unique programming concepts that may not work well for people who can’t or don’t want to use a GPU.

I’ll keep this in mind for a new project, but will keep this discussion going here for research and implementation discovery.

[JGronholz]

Dave, this caught my eye, because I have experience with C#/Unity/DirectX. I'll follow your lead on the wontfix-ness of this, but have to say that I'm intrigued, and honestly surprised that I hadn't thought of it, myself...

Windows won't even install on a computer without a halfway decent GPU anymore, and OpenGL has ports for every other major OS. ComputeShaders are actually relatively easy to create, can be written in C#, and can return all of the typical .NET enumerable types used in this package. I'm willing to bet that most of your {maths} code will run on a GPU, unmodified. Pre-processor directives should be able to automate the GPU initialization, and handle directing the CalcXxx functions to the CPU/GPU, as appropriate.

Conceptually:

1. Upload the shaders to the video card. That's done only once.
2. On the CPU:

    Loop
    {
        if (symbolOrIntervalChanged) 
           upload full list of quotes to GPU;
        else if (quotesUpdated)
           upload only the new/updated candle(s) to GPU;

        foreach indicator
        {
            shader(indicator);
            return results;
        }
    }

The caveat:

• GPU's are designed to apply the same formula to an entire array of pixels/quotes/things, simultaneously. Unfortunately, many indicator results rely on the previous result. We want to start at a specific "pixel," and iterate the rest, one, by one, which is the exact opposite of what the GPU is best at. If you load 1000 quotes into the GPU, and hit go, only one thread can actually start working. Each of the other 999 threads will have to wait for the one before it to finish. Regardless of how many thousands of CUDA cores you throw at it, the operation remains synchronous. 😒

That said:

• Running synchronously on a GPU core is still better than competing with the UI thread.

• The input>output stages of pipeline shaders are extremely configurable, chaining is implied, and indicator results are unlikely to fill a GPU's memory, so you could cache, literally, every calculation performed.

• Along those same lines, each GPU core could work (synchronously) on a different symbol/indicator/interval combination. We try to do as little as possible, when we're CPU-bound, but it's a different animal, using the GPU. Recalculate everything, as often as possible, to maximum precision... Because, why not? 😁 Rather than spend CPU time determining whether some results need to be updated, you tell the GPU to start updating and don't stop. Nine out of ten results are duplicate, but so what? The more work you give it to do, the less time it has to make duplicate results.

• Brand new GPU's have faster memory than brand new motherboards, and uploads to the GPU use DMA, bypassing the CPU. Once initialized, the CPU would have little else to do besides service the UI, and occasionally call GPU.DoIt().

[DaveSkender]

Conceptually I really like the idea of using federated processing, so I generally like it. I'm mostly just not yet convinced that it's a good use of time to implement now vs later.

Given my very limited knowledge of how to do this, it looks like a very low return on effort. I'm making a lot of assumptions, but here's how I see it:

Costs

• 10x longer to implement
• unknown user hardware compatibility (reduced usability)
• fewer people could contribute to the project
• fragile and complex code that's difficult to debug
• time away from working on more useful features

Benefits

• maybe 10-20% faster processing speed

[DaveSkender]

With that said, if someone wants to do a proof of concept experiment by creating a complete Pull Request for one indicator, like SMA or EMA, to demonstrate effort vs performance vs code code complexity, I'd love to see it.

I suspect this could be a new .csproj project in this repo that builds a separate library, but utilizes shared aspects, from the existing one.

[seanpmac]

Here is one example of creating a sum of an array using ilgpu https://github.com/m4rs-mt/ILGPU/blob/master/Samples/SharedMemory/Program.cs this example synchronizes memory between CPU and GPU. Is your library using Parallel.Foreach to maximize use of CPU cores? https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/

…

On May 14, 2022 at 12:48:46 AM, Dave Skender ***@***.******@***.***)) wrote: In doing some reading, GPU compatibility for indicators will need to be an entirely new library because it requires unique programming concepts that may not work well for people who can’t or don’t want to use a GPU. I’ll keep this in mind for a new project, but will keep this discussion going here for research and implementation discovery. — Reply to this email directly, view it on GitHub(#765 (comment)), or unsubscribe(https://github.com/notifications/unsubscribe-auth/ADHPINX4ZYDGJJNW6HE77DDVJ5EE5ANCNFSM5UED7XZA). You are receiving this because you authored the thread.Message ID: ***@***.***>

[DaveSkender]

Thanks for the example. Helpful.

I have some experience with Parallel.Foreach. I have a reminder in the backlog to explore it again. If I recall, parallelism works best in async situations? I'd tried adding this in some cases, but found that it wasn't a great fit with static classes or didn't improve performance (can't remember exactly).