|
|
|
|
|
|
by alcidesfonseca
2294 days ago
|
|
|
Back in 2010 I worked on a user-library and preprocessor that did the same thing [1]. Had exactly the same restrictions. Classes are supported if they act as dumb structs. Recursion is now supported in CUDA via dynamic parallelism (or faking the stack) but it is not performant at all. The ideal language for GPU programming is closer to Julia or a MATLAB-like language where arrays and matrices are first-class. [1] https://github.com/AEminium/AeminiumGPU |
|
|
That pulled up "Chapel" in my head and a couple of clicks later the net pulled this up:
"PGAS (Partitioned Global Address Space) programming models were originally designed to facilitate productive parallel programming at both the intra-node and inter-node levels in homogeneous parallel machines. However, there is a growing need to support accelerators, especially GPU accelerators, in heterogeneous nodes in a cluster. Among high-level PGAS programming languages, Chapel is well suited for this task due to its use of locales and domains to help abstract away low-level details of data and compute mappings for different compute nodes, as well as for different processing units (CPU vs. GPU) within a node. In this paper, we address some of the key limitations of past approaches on mapping Chapel on to GPUs ..."
https://pldi19.sigplan.org/details/CHIUW-2019-papers/4/GPUIt...