The feasibility of GPU acceleration in ASP.Net Core MVC

Throughout the past few weeks, in my spare time, I have been researching and planning an attempt at improving efficiency and load potential of ASP.Net sites via the use of GPU acceleration. This task has been quite a challenge, although there are a number of powerful NuGet packages that utilise the NVidea CUDA SDK, they aren’t strictly designed for ASP.Net so getting them to be correctly referenced was not easily possible.

After a large range of attempts, it has proven not to possible at the current time using pre-existing packages, although still possible to an extent, but one which doesn’t bring as many benefits as what was hoped.

The theory of GPU accelerating ASP.Net MVC would be to change how an Asynchronous controller function would handle resourcing; rather than splitting up a CPU’s thread-count to the number of users accessing an application, it would be ideal to split up a GPU’s (in this case CUDA) core count to allow for a much larger quantity of users accessing a site, although only a theoretical result.

To put this into theoretical perspective, we can take a high end Intel Xeon Processor with 24 cores and 48 threads and compare this to a high end Nvidea Card which in contract has 3584 Parallel-Processing cores. It is, from face value, easy to see the potential advantage, more available cores means that we can have more functions running in an Asynchronous fashion, potentially allowing more users onto a site at once and hopefully decreasing latency of page response times.

Obviously, there are a huge range of arguments that have been going on regarding this topic and I don’t intend on joining these heated debates but the curiosity and rise in deep-learning via GPU Parallel-Computing shows that GPU’s are paving the way for a more efficient approach to Computing.

The difficulty I encountered with trying to get ASP.Net to work with GPU’s is mainly that there is no real support for Parallelising ASP in that manor, all existing Asynchronous computation is done via the CPU and the reason for this is that a huge range of servers do not have dedicated GPU’s present inside them, meaning the idea of Microsoft or Open-Source Developers for .NET Core providing support for GPU Parallelism is somewhat unnecessary at this time. There are some packages available, notably Hybridizer by Altimesh, and AleaGPU. Both these packages allow development using C# rather than having to move to C++, providing an easier transition to GPU utilisation. However, these packages are only really designed around Desktop and Console Applications and not for Server-Side Applications, providing issues when it comes to implementation.

The only way I could work around this, is creating Class Libraries which use these packages and allow for GPU usage but this brings with it an annoying issue which is maintainability. Class Libraries need to be converted to .dll files at runtime which means debugging code in the .dll when something goes wrong is a pain in itself.

When taking all of this into consideration, I will continue to, on an enterprise and business level, to view the GPU acceleration capability of ASP.Net asynchronous functions, as an infeasible method of development. On a personal level, I plan to see what the possibility of rewriting/modifying the existing .NET Core packages which provide asynchronous functionality to try and achieve the goal I have in mind. From here, it may be possible to determine the overall feasibility of GPU acceleration.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s