Perl 6 - the future is here, just unevenly distributed

IRC log for #native, 2015-08-04

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

All times shown according to UTC.

Time Nick Message
14:10 jberger people on this channel might be interested to see run4flat's new module: https://metacpan.org/pod/C::Blocks
14:10 jberger I know he's been working on it for a long time
15:07 plicease i was just looking at that looks interesting.
17:36 run4flat joined #native
17:37 run4flat In case you missed it, C::Blocks is out: https://metacpan.org/pod/C::Blocks
17:38 run4flat I am currently working on new benchmarks to compare C::Blocks to other mechanisms
17:38 run4flat the development repo is here: https://github.com/run4flat/C-Blocks
17:39 run4flat jberger, thanks for the heads-up about this channel. :-)
17:45 plicease run4flat++
17:49 run4flat plicease, I see you have already forked the project. I am particularly keen on any benchmarks we can put together comparing C::Blocks and your various FFI modules
17:50 plicease Yeah.  I was actually going to see if I could figure out why t/80-StretchyBuffer.t was failing
17:51 plicease but realized that it was going to take me longer to figure out than I had to devote today.
17:52 run4flat what OS are you on?
17:52 plicease linux.
17:52 run4flat what version of Perl?
17:53 plicease 5.23.1
17:53 run4flat Retrieving lexically scoped variables only works on v5.18 and higher, and t/80 uses lexically scoped variables
17:53 run4flat hmmmm
17:53 plicease though I saw similar failures in cpan testers matrix.
17:54 plicease https://gist.github.com/plicease/cca716d67fd79f692bd9
17:55 run4flat thanks
17:55 run4flat heh, prove always refrains from displaying segfaults, which is probably what is happening here
17:56 plicease yeah.  sorry I verified that by running it with perl -Mblib
17:56 run4flat if you run it as "perl -Mblib t/80-StretchyBuffer.t", you'll probably be told it segfaults
17:56 run4flat yep
17:56 plicease i can try and get you the stack trace if you aren't able to reproduce it yourself.
17:57 run4flat I can reproduce a similar problem on other OSes, such as Windows
17:57 run4flat the problem witth Windows is that I don't have a debugger
17:57 plicease doh.
17:59 run4flat I should probably figure out how to install gdb on my Windows machine, though I'm not sure how well it would play with Strawberry's mingw subsystem
18:00 run4flat hmm, strawberry v5.16 has a debugger option
18:12 sivoais run4flat++ # excited to see the progress on C::Blocks
18:25 jberger run4flat: o/
18:51 run4flat sweet, with the help of alh on #xs, I just figured out how to support lexical variable "interpolation" for Perls before 5.18
18:51 run4flat :-)
19:09 jberger there are some smart people on this here internet
19:10 jberger what was missing before 5.18?
20:34 run4flat pad_findmy_pv and variants, which have been around probably since v5.0, was not part of the official API until 5.18
20:35 run4flat and before it was officially part of the API, it was called pad_findmy
20:37 sivoais run4flat: since you're not in #pdl, I'll ask here
20:38 sivoais re: your post to pdl-porters with the benchmark
20:38 run4flat yeah what's up
20:39 sivoais Do you think that the extra speed that PDL has *despite* the method calls all has to do with the GCC optimiser?
20:39 sivoais and the ability to use SSE extensions?
20:39 run4flat I am sure it has everything to do with the GCC optimizer
20:40 run4flat as to whether it has anything to do with SSE extensions, I actually know nothing about those, other than their name
20:41 run4flat I seem to remember reading that tcc is pretty dumb when it comes to register management
20:41 sivoais so maybe if TinyCC could be used to keep PDL calls in C code entirely, it would benefit from both
20:41 run4flat I'm not quite sure what you mean there
20:41 run4flat I can say this
20:42 run4flat if you compile your code with an optimizing compiler, you can call it with TCC no problem
20:42 run4flat that is really the best win, I think
20:42 sivoais A GCC/Clang compiled PDL library called by TinyCC code
20:42 run4flat yes
20:42 run4flat write a C api for PDL compiled by GCC/Clang
20:42 run4flat interface with C::Blocks
20:42 * sivoais nods
20:43 sivoais sounds good
20:43 sivoais :-)
20:43 run4flat I've been bandying about the idea of writing some sort of N-dimensional array library with C::Blocks
20:43 run4flat that would give most of the PDL functionality including autolooping
20:43 run4flat but not arbitrary slices
20:44 sivoais libdynd does this, but it is in C++
20:44 run4flat hey, good to know
20:44 sivoais <https://github.com/ContinuumIO/libdynd>
20:44 sivoais better link <https://github.com/libdynd/libdynd>
20:45 sivoais it's part of that whole Blaze and DARPA XDATA thing you mentioned in a blog post a *long* time ago
20:45 run4flat right
20:45 run4flat part of the reason I worked on C::Blocks is the belief that we won't beat Python at the ND-array game
20:45 run4flat so let's try a different appraoch
20:46 sivoais though I'm still miffed that neither Numpy or Julia take the best bits from APL
20:46 run4flat that said, it may be possible to create extern-C binding for this
20:46 run4flat and make those bindings accessible via C::Blocks
20:46 sivoais *nor
20:46 run4flat yeah, I find that shocking.
20:46 * sivoais nods
20:46 sivoais that's what I was thinking
20:47 sivoais for the start of PDL3 dev, I'd like to start benchmarking different approaches that already exist so that I can get a feel for what is out there
20:47 run4flat yeah
20:48 run4flat in my limited experience, I believe that support for ragged array types, which seems to be one of the big pushes for the Blaze work, is not the real problem
20:48 run4flat I expect that the real problem for true high performance has to do with random access latency
20:49 run4flat I'd have to look at DyND closely to see if it really addresses that
20:50 run4flat but this is really speculation on my part
20:54 run4flat benchmarks for all of this would be very, very helpful
20:56 sivoais I'll try to gather some in a few weeks. I don't have the tuits right now. :-P
20:56 run4flat no rush
20:56 run4flat My wife is due at the end of this week, so I will have zero time very, very soon
20:57 jberger luckily that unborn child has a Pooh Bear waiting for it when it arrives!
20:58 run4flat yes, with krinkly ears
20:58 sivoais :-D
21:08 jberger I was a little sorry about the ears
21:09 jberger I don't know where to find the usual Pooh Bear anymore
21:09 jberger you wouldn't think it hard to find
21:10 run4flat no, they're supposed to be krinkly
21:10 run4flat it's a form of stimulation for the child
21:11 run4flat though I'll admit I was thrown off a bit at first
21:15 jberger ah, perhaps that is why
21:15 jberger and I found it at babies r us, so that makes sense
21:34 run4flat I am off for the night
21:34 run4flat o/
21:54 jberger \o

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