3 ms·

I don't think this is meant to replace the x86 ISA, but rather SIMD units like MMX/SSE and traditional GPU shaders. The article was a bit muddled -- I'm waiting

I don't think this is meant to replace the x86 ISA, but rather SIMD units like MMX/SSE and traditional GPU shaders. The article was a bit muddled -- I'm waiting for the Anandtech version. Successful adoption will be dependent on good tooling. Auto-vectorizing is really hard in compilers, mostly because current languages aren't really built for it. But if AMD were to introduce something purpose-built (eg, with a Matlab-like syntax), then that might compel devs who aren't assembly or GPU gurus to develop against this.

cageface 15y ago
Maybe something like Google's new Renderscript API could be used to expose this in a friendly way?
sigil 15y ago
> But if AMD were to introduce something purpose-built (eg, with a Matlab-like syntax), then that might compel devs who aren't assembly or GPU gurus to develop against this. Does anyone know if it's possible to program GPUs today without using a new, special purpose programming language? That would be the killer app for GPUs. I see your point about most languages not admitting auto-vectorization. But couldn't you take a compilable functional language like Gambit Scheme, Clojure, or Haskell and emit GPU code for constructs like map and fold on numeric vector types?
- eru 15y ago
  > Does anyone know if it's possible to program GPUs today without using a new, special purpose programming language? That would be the killer app for GPUs. Haskell has an embedded domain specific language for it. (It's probably a monad.)
  - sigil 15y ago
    Hmm. Are you referring to this? http://www.cse.unsw.edu.au/~chak/papers/acc-cuda.pdf http://www.cse.unsw.edu.au/~chak/papers/acc-cuda.pdf
jcheng 15y ago
The R language (http://www.r-project.org http://www.r-project.org) is inherently well suited for auto-vectorizing. There are a couple of packages for GPU-accelerated processing already--currently heavily skewed towards CUDA though. http://cran.r-project.org/web/views/HighPerformanceComputing.html http://cran.r-project.org/web/views/HighPerformanceComputing... (scroll down to "Parallel Computing: GPUs")
jcheng 15y ago
Here's the AnandTech writeup (and as you expected, it's way better than the Register one): http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute http://www.anandtech.com/show/4455/amds-graphics-core-next-p...
buzzzlight 15y ago
Fellow programmers make fun of me for liking Matlab. I've tried to explain it to them many times (how it doesn't need iterators, how most things are one-liners, how it's 10-100 times less code all the way down), but I've come to the conclusion that they just feel threatened because it goes around most of the problems they've learned to solve with c. It's like how some auto mechanics don't think much of electric cars. I know that hundreds of cores is the future, but nobody knows how to use inherently parallel languages like Matlab, so all I can do right now is wait for the future to arrive.

cageface 15y ago

Maybe something like Google's new Renderscript API could be used to expose this in a friendly way?

sigil 15y ago

> But if AMD were to introduce something purpose-built (eg, with a Matlab-like syntax), then that might compel devs who aren't assembly or GPU gurus to develop against this. Does anyone know if it's possible to program GPUs today without using a new, special purpose programming language? That would be the killer app for GPUs. I see your point about most languages not admitting auto-vectorization. But couldn't you take a compilable functional language like Gambit Scheme, Clojure, or Haskell and emit GPU code for constructs like map and fold on numeric vector types?

eru 15y ago
> Does anyone know if it's possible to program GPUs today without using a new, special purpose programming language? That would be the killer app for GPUs. Haskell has an embedded domain specific language for it. (It's probably a monad.)
- sigil 15y ago
  Hmm. Are you referring to this? http://www.cse.unsw.edu.au/~chak/papers/acc-cuda.pdf http://www.cse.unsw.edu.au/~chak/papers/acc-cuda.pdf

jcheng 15y ago

The R language (http://www.r-project.org http://www.r-project.org) is inherently well suited for auto-vectorizing. There are a couple of packages for GPU-accelerated processing already--currently heavily skewed towards CUDA though. http://cran.r-project.org/web/views/HighPerformanceComputing.html http://cran.r-project.org/web/views/HighPerformanceComputing... (scroll down to "Parallel Computing: GPUs")

jcheng 15y ago

Here's the AnandTech writeup (and as you expected, it's way better than the Register one): http://www.anandtech.com/show/4455/amds-graphics-core-next-preview-amd-architects-for-compute http://www.anandtech.com/show/4455/amds-graphics-core-next-p...

buzzzlight 15y ago

Fellow programmers make fun of me for liking Matlab. I've tried to explain it to them many times (how it doesn't need iterators, how most things are one-liners, how it's 10-100 times less code all the way down), but I've come to the conclusion that they just feel threatened because it goes around most of the problems they've learned to solve with c. It's like how some auto mechanics don't think much of electric cars. I know that hundreds of cores is the future, but nobody knows how to use inherently parallel languages like Matlab, so all I can do right now is wait for the future to arrive.