>>>>> David Mertens <[email protected]> writes: >>>>> On Wed, Jun 29, 2011 at 2:49 PM, Ivan Shmakov wrote:
[…] > Getting back to your original question, my understanding of > Christian's threading work (which John's patch exposed in a more > automatic way) is that, rather than looping over additional ranks, > PDL's automatic multithreading will split up those tasks into > separate threads. >> Formerly, it was suggested [1] that a kind of FORALL construct is to >> be implemented. >> [1] nntp://news.gmane.org/[email protected] > I was unable to follow the link to your first reference. Can you > double-check it? It works in Lynx, but I guess that it's one of the very few browsers to have a newsreader built-in. The same post is also available via the following http: URI: [1] http://permalink.gmane.org/gmane.comp.lang.perl.pdl.general/4378 >> I wonder, wouldn't it be better to have something like the ‘with’ >> (e. g., [2]) SAC [3] operator implemented instead? > That's pretty much what the PDL threading engine does already. It's > not quite as easy to use as SaC's with-loop, but it's pretty much as > powerful, unless I missed something about SaC. My understanding is that while SaC will compile a single ‘with’ statement into a single machine code loop, while a single PDL expression may get implemented as a series of. AIUI, the following will result in two loops (to be executed in sequence), even though only one is actually necessary: my $b = 2 * $a + 1; I've already posted some notes on the issue earlier [4]. Now, I think that I've got the idea, yet my approach is based on (low level, as in “C”) code generation and I'm not sure it thus will fit PDL nicely. (But I hope that it will allow for solutions for a wider range of tasks, and possibly at lower cost.) [4] http://permalink.gmane.org/gmane.comp.lang.perl.pdl.general/4292 >> Also, my understanding is that the transparent utilization of GPU's >> will require dynamic GPU code generation. > That depends on what you mean by 'transparent.' Have you programmed > with CUDA or OpenCL? Not yet. > When people who have not programmed on GPUs talk about 'transparent' > utilization, I find that they usually mean 'opaque', i. e. they want > it to work without understanding how it works at the lower levels. It somehow reminds me the X window (client, server) terminology issue. But yes, I do mean that the underlying hardware will not be visible to the programmer (unless the latter opts to use a lower-level abstraction.) >> I wonder, may dynamic /CPU/ code generation be considered for PDL >> just as well? > Maybe? Probably? It also seems to me that naive implementations could > end up costing more than the current pre-compiled methods that PDL > uses. To some extent it is already possible to create PDL methods on > the fly with Inline::Pdlpp, but it's not JIT in the real sense of the > term (lots of harddrive writes and reads, to be specific). So, sure, > that would be nice if it was done well. Unfortunately, the only > programmers with the chops to implement such an idea with PDL either > (a) don't have the time or (b) are no longer part of the PDL > community. ACK. >> (I have some ideas that will demand such a facility.) > If you really want to dynamically generate PDL::PP code, I highly > recommend looking into Inline::Pdlpp. Be warned: it's not the best > documented system and it has a steep learning curve. (It needs to be > rewritten, or at least improved.) Feel free to post your questions > here. ACK. Thanks! -- FSF associate member #7257 _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
