>>15
It doesn't exist, because the people who put together toy Lisp languages don't seem to understand how to write software that makes the most efficient use of common CPU hardware. OpenMP isn't really suited for GPUs, FPGAs or auxiliary CPU cores. OpenCL is. Many types of problems are better executed on in-order compute cores and GPUS/FPGAs with more FLOPs/watt, so there is a use case.
>>16
A Lisp-like could be perfect for it, but Common Lisp out of the box is horrible. You can't use linked-lists or other linked structures. It would need to be less imperative, at least on the GPU/FPGA side of things, and focus more on functional/flow-oriented/data-oriented programming where transforms on immutable data are executed in parallel and synchronization is performed via barriers on task dependencies. Any object orientation is out of the question.
Furthermore, the runtime for the language and how "objects" in the language are laid out in memory needs to be in Structure of Array order. Homogenous bounded arrays, not all grouped together in traditional structured or OOP fashion of Arrays of Structures. No pointers and cyclic references to other objects, but rather memory offsets into the homogenous arrays or hash-codes for open-addressed hash-table lookups.
Garbage collection is also out, upper bounds for all memory usage need to be known ahead of time (either compile time or as a function of the size of loaded assets/data at runtime), allocations are performed using fast linear allocators, and memory is released implicitly when tasks are finished executing and data goes out of scope.
It would need to be something like this, but with a Lisp-like syntax:
http://www.flowlang.net/p/flow-manifesto.html