4 ms·

Is the world ready for lower-level languages? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cac

Is the world ready for lower-level languages? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cache-aware). Maybe... limited loop code-length to fit in cache; No pointer chasing (though you can workaround anything in a TM). Some java subsets for very limited hardware might be instances.

notduncansmith 7y ago
You may want to read about Java Card: https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card
Impossible 7y ago
GPU languages have some cache aware constraints, especially if you're working with the graphics pipeline vs compute where you have more constrained inputs and outputs. Shared memory is also often used as a user managed cache. Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.
- gpderetta 7y ago
  > Cell SPUs had explicit user managed cache and host DMA just a nitpick, but explicitly user managed caches aren't. They are really better known as scratchpads. A cache is supposed to be mostly transparent except for the performance implications.
derefr 7y ago
> Assembly isn’t What you mean is that the popular Instruction Set Architectures (x86, ARM) don’t expose these pragmatics. (Though the microcode architectures of the processors executing these ISAs probably do.) There are other ISAs (e.g. Itanium, most Very Long Instruction Word ISAs) that do expose these pragmatics, constraining what instructions can appear when in an instruction stream. Which in turn means that assembly code for these ISAs needs to be written with awareness of these pragmatics.

4 ms·

Is the world ready for lower-level languages? e.g. cache-aware. (assembly isn't) In a way, GPU shader languages "fit" parallel GPU architecture (though not cac

by hyperpallium 7y ago

notduncansmith 7y ago
You may want to read about Java Card: https://en.wikipedia.org/wiki/Java_Card https://en.wikipedia.org/wiki/Java_Card
Impossible 7y ago
GPU languages have some cache aware constraints, especially if you're working with the graphics pipeline vs compute where you have more constrained inputs and outputs. Shared memory is also often used as a user managed cache. Cell SPUs had explicit user managed cache and host DMA, and Intel ISPC and Unity Burst compiler/ECS (variants of C and C#) are good examples of programming environments that try to more explicitly encourage parallelism and/or optimal cache utilization.
- gpderetta 7y ago
  > Cell SPUs had explicit user managed cache and host DMA just a nitpick, but explicitly user managed caches aren't. They are really better known as scratchpads. A cache is supposed to be mostly transparent except for the performance implications.
derefr 7y ago
> Assembly isn’t What you mean is that the popular Instruction Set Architectures (x86, ARM) don’t expose these pragmatics. (Though the microcode architectures of the processors executing these ISAs probably do.) There are other ISAs (e.g. Itanium, most Very Long Instruction Word ISAs) that do expose these pragmatics, constraining what instructions can appear when in an instruction stream. Which in turn means that assembly code for these ISAs needs to be written with awareness of these pragmatics.