4 ms·

Perhaps, but C and C++ assume flat address spaces and modern hardware includes many programmable devices with their own device memory, e.g. GPUs. Naturally this

Perhaps, but C and C++ assume flat address spaces and modern hardware includes many programmable devices with their own device memory, e.g. GPUs. Naturally this discontinuity causes a great deal of pain and many schemes have been developed to bridge this gap such as USM (Unified Shared Memory). Personally I would like to see a native language which attempts to acknowledge and work with disjoint and/or "far away" address spaces. However the daunting complexity of such a feature would likely exclude it from any portable programming language.

vvanders 3y ago
Those disjoint memory addresses can be an absolute pain to deal with, ask anyone who had to spend time dragging performance out of the PS3 despite it being faster on paper. UMA/USM can also bring it's own set of issues when you have pathological access patterns that collide with normal system memory utilization. For what its worth UMA/USM wasn't build to bridge a gap but rather to offer greater flexibility in resource utilization for embedded platforms, that's been moving upstream(along with tiling GPUs) over the years. With UMA you can page in other data on a use-case basis which is why they were relatively popular in phones, if you don't have a bunch of textures loaded on the GPU you can give that space back to other programs. Although come to think of it we used to stream audio data from GPU memory on certain consoles that didn't have large discrete system memory(the bus connecting System <-> GPU memory had some pretty harsh restrictions so you had to limit it to non-bursty, low throughput data which audio/music fit well into).
memefrog 3y ago
There is a technical report for C (from the C standards committee) called 'Embedded C' which extends C with 'named address space' storage qualifiers. So you can do 'float _Gpu myarray[1<<14];' As far as I know, nobody uses it.

vvanders 3y ago

Those disjoint memory addresses can be an absolute pain to deal with, ask anyone who had to spend time dragging performance out of the PS3 despite it being faster on paper. UMA/USM can also bring it's own set of issues when you have pathological access patterns that collide with normal system memory utilization. For what its worth UMA/USM wasn't build to bridge a gap but rather to offer greater flexibility in resource utilization for embedded platforms, that's been moving upstream(along with tiling GPUs) over the years. With UMA you can page in other data on a use-case basis which is why they were relatively popular in phones, if you don't have a bunch of textures loaded on the GPU you can give that space back to other programs. Although come to think of it we used to stream audio data from GPU memory on certain consoles that didn't have large discrete system memory(the bus connecting System <-> GPU memory had some pretty harsh restrictions so you had to limit it to non-bursty, low throughput data which audio/music fit well into).

memefrog 3y ago

There is a technical report for C (from the C standards committee) called 'Embedded C' which extends C with 'named address space' storage qualifiers. So you can do 'float _Gpu myarray[1<<14];' As far as I know, nobody uses it.