3 ms·

I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon What specifically do you see as the fit

• frig 17y ago
  The fit imho is that at least if you stick to numerics you'd have to try pretty hard not to be writing code in a way that could be easily translated into something that'd be runnable on a gpu (or larrabee). This isn't really a new idea: http://portal.acm.org/citation.cfm?id=579.357248&coll=GUIDE&dl=ACM&idx=J783&part=periodical&WantType=periodical&title=ACM%20Transactions%20on%20Programming%20Languages%20and%20Systems%20(TOPLAS) http://portal.acm.org/citation.cfm?id=579.357248&coll=GU... ...(and gpus / larrabee etc. aren't solely vector processors, but the idea is apparent). Most of the bulk numeric actions in an array language map pretty nicely to the data-parallel approach you need to use to take advantage of a gpu or larrabee (if it ever shows up); in particular take a look through this: http://www.ncsa.illinois.edu/~gshi/LRBni_cheatsheet.pdf http://www.ncsa.illinois.edu/~gshi/LRBni_cheatsheet.pdf ...and see how much more straightforward it'd be to take advantage of (compared to SSE and so on). Your interpreter has to be a little more sophisticated (work has to be kept in units of 512 bytes) but seems much more tractable than previously. Since this isn't a new idea there's history to learn from; it was previously the case that you'd get a speedup from offloading work to the vector units but not really a cost-proportionate one. But now if you look at the performance differential between cpus and gpus and their relative costs it starts making sense again.