Perl 6 - the future is here, just unevenly distributed

IRC log for #pdl, 2013-11-27

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 sivoais joined #pdl
00:07 preaction_ joined #pdl
00:07 Mithaldu joined #pdl
00:07 jberger joined #pdl
00:07 drrho joined #pdl
00:07 jberger_ joined #pdl
00:07 gtodd1 joined #pdl
00:07 ribasushi joined #pdl
00:07 lungching joined #pdl
00:07 Bender2 joined #pdl
00:07 Bender1 joined #pdl
00:07 perigrin joined #pdl
00:07 osfameron joined #pdl
00:07 pdurbin joined #pdl
01:06 jberger__ joined #pdl
12:45 sivoais joined #pdl
12:57 vicash joined #pdl
13:44 jberger__ joined #pdl
14:20 webart ... some mathematically sophisticated stats and graphing/plotting regarding turkey consumption would be nice ;-)
14:22 webart joined #pdl
14:38 vicash webart: access to that data first would be necessary
14:38 Mithaldu just draw a curve that looks like a turkey
14:40 vicash which came first the bird or the country Turkey
14:40 Mithaldu the country is older than the english language i'm sure
14:41 Mithaldu http://www.wolframalpha.com/input/?i=turkey+curve&dataset=
14:41 vicash but it was known as Asia Minor or something  like that earlier  i think.. not verified
14:41 Mithaldu hm, ok, you're right
14:42 Mithaldu republic of turkey was only established in about 1920
14:45 vicash Mithaldu: what is RPerl ?
14:46 Mithaldu an inline compiler that compiles a restricted set of perl 5 to C for performance gains
14:46 Mithaldu like inline::c
14:46 Mithaldu only you can write perl instead of c
14:47 vicash sounds nice. is this basically going to be some sort of a JIT for Perl or does it have to be added as a package requirement to use it
14:47 Mithaldu i think you should go look at inline::c
14:47 vicash i have used Inline::C
14:47 vicash and Inline::Java
14:48 Mithaldu then i'm unclear how you go to JIT from that :P
14:48 vicash let me rephrase my question.
14:48 vicash will the standard perl executable incorporate the work done by RPerl or will I have to do something like "use RPerl" in my script to use it
14:49 Mithaldu as far as i understand it the api will be identical to Inline::C
14:49 vicash ok. that answers my question.
14:49 Mithaldu so the answer to your question would be no and no :P
14:49 vicash still sounds good for those folks who dont want to write C
14:50 Mithaldu yes, totally
16:40 chm joined #pdl
16:42 chm The idea of RPerl sounds nice but the license is non-free except for non-commercial use.
16:44 chm Mithaldu vicash : The FPerl motivation and strategy was interestingly similar to the direction PDL is working towards....
16:45 chm Although it looks like the RPerl folks have some perl heavyweight developers on their team...
16:49 Mithaldu chm: where are you seeing the license bit?
16:49 Mithaldu all i see is "same terms as perl 5.18.0
16:54 chm the RPerl FAQ: Q: How much does RPerl cost? A: RPerl is 100% free-of-charge for all non-commercial use as licensed under the same terms as Perl 5.18.0. This means you can use RPerl at home or at work, but you can't re-sell RPerl without the source code and you can't change the copyright terms.
16:55 chm It's not what they said, its what they left out....
16:56 Mithaldu hm, that seems weird
16:56 Mithaldu i'm gonna have to poke at that
16:56 Mithaldu thanks for pointing it out!
16:56 Mithaldu also, home time
16:57 chm Regarding the PDL for GPU discussion yesterday, that is another of the goals for PDL3
16:58 chm The 2 parts of the problem are handling data motion CPU<->GPU
16:58 vicash chm: i would like to help when that work begins
16:58 chm and then the computation which would involve different kernels.
16:59 vicash yes custom kernels will need to be written or auto-generated based on templates
16:59 chm I didn't understand run4flat with the comment that PDL::PP doesn't have a thread index
16:59 chm A thread index could easily be provided---in essence that is what PDL threading is about already
16:59 vicash even then there will be specific kernels based on GPU capabilities. each GPU might have very high global memory but very low local memory which may be needed to aggregate values or for temporary variables
17:00 vicash yes i agree with your thread index comment as i looked up PDL::ParallelCPU to see how it was doing it
17:00 chm Interestingly enough, CUDA has announced an SDK to drive their GPU compiler via LLVM
17:00 chm and OpenCL has already headed down that route.
17:01 chm It should be possible to start with CUDA accelleration first and then add more
17:01 chm seamless support
17:01 vicash but starting with OpenCL would allow one to debug the code on Intel CPUs and AMD CPUs using their OpenCL CPU libraries
17:02 vicash direct debugging on the GPU is not well implemented or not implemented depending on whether you plan to purchase NVIDIA's NSight debugger
17:02 chm Right.  My familiarity with OpenCL is that you can write CUDA/OpenCL with pretty much the same code
17:03 chm The basics of the APIs seem to match up very closely.  We could stick to the common subset for basic implementations
17:03 vicash yes and no, CUDA primitives are different . One can write code that looks similar but the way they work is different. CUDA does give more GPU memory allocation capabilities that are slightly closer to the metal but OpenCL will work on various GPUs.. so it is a trade off
17:05 chm Right.  I'm planning to get into GPU programming again with an aim at PDL accelleration once we have working 64bit indexing.
17:05 vicash but if you want to go with CUDA first, that is your decision as you're the maintainer
17:05 chm Not good to work with multi-GB data and GPU memories if you cannot address it...
17:06 chm I'm not restricting things at all.  I'm more interested in the shortest time to market.
17:06 vicash sure, makes sense
17:06 chm The last time I looked at CUDA + OpenCL was a couple of years ago.
17:06 chm Things have gotten *much* better on all fronts---I'll need to come up to speed again.
17:07 vicash yes. that is true. and things keep improving
17:07 chm If we just had the ability for GPU acceleration for underlying functionality via cuda or opencl kernels, that would be a win.
17:07 vicash the good thing about both CUDA and OpenCL is one can determine the capabilities of the GPU and adjust the kernel parameters or even the kernel code to comply with the GPUs
17:08 chm I have a number of algorithms that if I could use the GPU, I wouldn't really care that I
17:08 chm don't use direct PDL threading ops.  Take FFTs for example.
17:09 chm One nice thing about CUDA (possibly OpenCL) is they have the ability to target PTX in a hardware independent way.
17:09 chm Then the video driver just JITs things for the hardware.
17:09 chm I think that is what Apple was doing for OpenCL and their ipad graphics support.
17:10 vicash actually if you run OpenCL kernels, they get compiled into PTX first and then executed
17:10 vicash that is NVIDIA's method
17:10 chm Interesting.
17:10 vicash you can see the code in Linux under the ~/.nv/ComputeCache directory
17:11 chm Lunch time here, got to go for a bit o/
18:07 chm ...
18:08 vicash i wanted to mention that although OpenCL and CUDA are reasonably well designed DSLs one could target GPUs using the native PTX as well...
18:08 vicash although that is an arduous task per se but not impossible
18:10 vicash however, i would really be interested in using OpenCL since Altera says they support it on FPGAs and having something like PDL support FPGA devices makes it a viable futuristic alternative
19:05 chm I took a look at OpenCL at it appears to be pretty much the CUDA using the driver model
19:06 chm and not the runtime.  It should be possible to support both/either.
19:06 chm See PyCUDA and PyOpenCL implementations for a start.
19:07 chm Maybe we could kickstart our own implementations by reviewing those code bases.
19:07 chm Might help avoid some dead ends, allow for compatibility, and make a way for the higher level implementation.
19:14 vicash sounds like a plan
19:31 chm It might be an opportunity for a pdl code sprint...
19:31 chm Once we decide what to do, a lot of the work is grinding out the details/boilerplate
20:38 chm ...
21:17 vicash \quit
22:37 jberger_ joined #pdl
23:08 jberger__ joined #pdl
23:25 jberger_ joined #pdl
23:52 jberger__ joined #pdl

| Channels | #pdl index | Today | | Search | Google Search | Plain-Text | summary