5 ms·

Please take this not as an insult but as invitation to offer help. Rank shouldn't be something to get confused about; if it is you're probably overthinking it.

by frig 17y ago

Please take this not as an insult but as invitation to offer help. Rank shouldn't be something to get confused about; if it is you're probably overthinking it. What did you find confusing about it?

silentbicycle 17y ago
I found the way that the linked interpreter above implements dimensions rather confusing, mostly. Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up than untangling a semi-obfuscated interpreter.
- frig 17y ago
  Yeah I've not studied that interpreter so if that's your specific interest no luck sadly; rank is an easy idea but wouldn't surprise me if there's some trick to it in an implementation that short. I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut. The interactive J labs are very good. You might also find the J for C programmers discussion of rank particularly helpful if you are looking at learning by understanding an implementation. I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon and what with more-versatile input devices showing up (making it easier to go back to funky symbols instead of line noise).
  - gruseom 17y ago
    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 between GPUs and array languages?
    - 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.

by frig 17y ago

Please take this not as an insult but as invitation to offer help. Rank shouldn't be something to get confused about; if it is you're probably overthinking it. What did you find confusing about it?

silentbicycle 17y ago

I found the way that the linked interpreter above implements dimensions rather confusing, mostly. Thanks for the offer, but I didn't get that far because I decided I was better off focusing on Erlang for the time being. I'm very curious about that language family, I'm just trying to not spread myself too thin. When I get back to it, I'll try working through the J labs - it's probably a much better way to pick it up than untangling a semi-obfuscated interpreter.

frig 17y ago
Yeah I've not studied that interpreter so if that's your specific interest no luck sadly; rank is an easy idea but wouldn't surprise me if there's some trick to it in an implementation that short. I think it'd be easier to untangle if you already had a working knowledge of the language but given the line-noisy look of J I can't blame you for trying the shortcut. The interactive J labs are very good. You might also find the J for C programmers discussion of rank particularly helpful if you are looking at learning by understanding an implementation. I figure the array languages will make a minor comeback soon what with gpus / larrabee / etc showing up on the horizon and what with more-versatile input devices showing up (making it easier to go back to funky symbols instead of line noise).
- gruseom 17y ago
  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 between GPUs and array languages?
  - 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.