Camelia, the Perl 6 bug

IRC log for #parrot, 2011-07-26

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:01 soh_cah_toa left #parrot
00:02 soh_cah_toa joined #parrot
00:10 theory left #parrot
00:19 bubaflub joined #parrot
00:19 bubaflub ~
00:19 whiteknight hello bubaflub
00:19 bubaflub hello whiteknight
00:20 dmalcolm left #parrot
00:23 dalek parrot/m0-prototype: 823bed4 | cotto++ | t/m0/integration/m0_hash.m0:
00:23 dalek parrot/m0-prototype: make debugging output for hashing test easier to enable
00:23 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/823bed4351
00:24 bubaflub jay: good work on getting that stuff compiled and running
00:25 kid51 is now known as kid51_at_dinner
00:26 daniel-s joined #parrot
00:31 dalek parrot/whiteknight/imcc_tag: 8229ddd | Whiteknight++ | / (3 files):
00:31 dalek parrot/whiteknight/imcc_tag: Add in some code to imcc.y (not used yet) to replace :load and :init with :tag. Fix Parrot_pf_subs_by_flag to treat :init and :load together with :tag seamlessly.
00:31 dalek parrot/whiteknight/imcc_tag: review: https://github.com/parrot/parrot/commit/8229ddd07d
00:49 jay ~~ hey bubaflub, thanks, whiteknight++ on that one.
00:50 soh_cah_toa left #parrot
01:02 soh_cah_toa joined #parrot
01:09 darbelo left #parrot
01:13 kid51_at_dinner is now known as kid51
01:14 kid51 bubaflub:  I quoted you in my FOSSCON talk in Philadelphia on Saturday:  http://thenceforward.net/parrot/fosscon201107/
01:17 bubaflub kid51: wow.  i'm reading it now.
01:20 dalek parrot/whiteknight/frontend_parrot2: 7c91174 | Whiteknight++ | frontend/parrot (3 files):
01:20 dalek parrot/whiteknight/frontend_parrot2: Prototype for a new alternate frontend. The new frontend intends to bootstrap into PIR as early as possible, using new packfile and compiler features.
01:20 dalek parrot/whiteknight/frontend_parrot2: review: https://github.com/parrot/parrot/commit/7c91174d3d
01:32 kid51 So, the command I was ignorant of was: git remote prune origin
01:33 Felipe I didn't knew it either
01:34 bubaflub left #parrot
01:35 kid51 Now, locally: 'git branch -r | wc -l' shows 67 ... which is the number of branches shows in the github drop-down
01:35 * kid51 happy
01:36 Felipe :D
01:42 kid51 left #parrot
01:45 woosley joined #parrot
01:45 cotto ~~
01:49 dalek parrot/whiteknight/frontend_parrot2: 8b85ecc | Whiteknight++ | frontend/parrot2/main.c:
01:49 dalek parrot/whiteknight/frontend_parrot2: A few small speculative changes and some TODO notes
01:49 dalek parrot/whiteknight/frontend_parrot2: review: https://github.com/parrot/parrot/commit/8b85ecc6e0
01:57 whiteknight left #parrot
02:06 soh_cah_toa left #parrot
02:34 cotto parrot 2: This time it's personal.
02:37 d4l3k_ joined #parrot
02:39 tempire_ joined #parrot
02:40 pmichaud_ joined #parrot
02:40 pjcj_ joined #parrot
02:40 sorear_ joined #parrot
02:40 ascent_ joined #parrot
02:40 PerlPilot joined #parrot
02:41 tewk__ joined #parrot
02:44 ascent left #parrot
02:44 tewk_ left #parrot
02:44 pjcj left #parrot
02:44 slavorg left #parrot
02:44 dalek left #parrot
02:44 sorear left #parrot
02:44 pmichaud left #parrot
02:44 PacoLinux left #parrot
02:44 tempire left #parrot
02:44 PerlJam left #parrot
02:44 knewt left #parrot
02:44 tempire_ is now known as tempire
02:45 d4l3k_ is now known as dalek
02:52 knewt joined #parrot
02:55 soh_cah_toa joined #parrot
02:56 PacoLinux joined #parrot
03:13 soh_cah_toa left #parrot
03:14 theory joined #parrot
03:24 soh_cah_toa joined #parrot
03:27 sorear_ is now known as sorear
03:37 dalek parrot/m0-prototype: 093802e | cotto++ | t/m0/integration/m0_hash.m0:
03:37 dalek parrot/m0-prototype: fix test so that it can pass
03:37 dalek parrot/m0-prototype: review: https://github.com/parrot/parrot/commit/093802ef1e
04:27 daniel-s left #parrot
04:33 bluescreen joined #parrot
04:41 theory left #parrot
04:43 dafrito left #parrot
04:52 dalek parrot: 97e3693 | soh_cah_toa++ | runtime/parrot/library/osutils.pir:
04:52 dalek parrot: Added perldoc to osutils.pir. Also cleaned up source code so I could figure what each function was doing more clearly.
04:52 dalek parrot: review: https://github.com/parrot/parrot/commit/97e3693f1d
04:52 dalek parrot: 9efc5f9 | soh_cah_toa++ | runtime/parrot/library/osutils.pir:
04:52 dalek parrot: Removed a few trailing whitespaces in osutils.pir that were causing t/codingstd/trailing_space.t to fail. Also added some perldoc corrections that were missing because of a delinquent vim swap file.
04:52 dalek parrot: review: https://github.com/parrot/parrot/commit/9efc5f99f5
05:16 soh_cah_toa left #parrot
06:02 dalek plumage: 0f7da31 | soh_cah_toa++ | / (2 files):
06:02 dalek plumage: Created a manpage and added steps after 'install' and 'uninstall' for installing/uninstalling it. Took it off the TODO list.
06:02 dalek plumage: review: https://github.com/parrot/​plumage/commit/0f7da31747
06:04 TiMBuS left #parrot
06:04 dalek plumage: 7576138 | soh_cah_toa++ | docs/man/plumage.1.gz:
06:04 dalek plumage: Forgot to actually track the new manpage from the previous commit.
06:04 dalek plumage: review: https://github.com/parrot/​plumage/commit/7576138029
06:06 bluescreen left #parrot
06:14 cotto ~~
06:51 dalek left #parrot
06:55 dalek joined #parrot
07:19 d4l3k_ joined #parrot
07:19 dalek left #parrot
07:20 d4l3k_ is now known as dalek
07:29 mj41 joined #parrot
07:39 preflex joined #parrot
07:43 preflex_ left #parrot
07:50 particle left #parrot
08:01 daniel-s joined #parrot
08:34 cotto msg dukeleto I'm running into surprising behavior with Perl's pack and unpack functions.   Does https://gist.github.com/1106278 look like a familiar issue?
08:34 aloha OK. I'll deliver the message.
08:38 moritz how do I extend parrot's library loading path (say, in PIR)?
08:39 moritz I want the same effect as I wrote parrot -L somePath
08:41 moritz and where would I find such things in the docs?
08:41 cotto moritz, look for IGLOBALS_LIB_PATHS
08:44 moritz nqp: say(pir::const::IGLOBALS_LIB_PATHS)
08:44 p6eval nqp: OUTPUT«9␤»
08:44 moritz nqp: say(pir::getinterp__P()[pir:​:const::IGLOBALS_LIB_PATHS])
08:44 p6eval nqp: OUTPUT«5␤»
08:45 moritz nqp: say(nqp::join(' ', pir::getinterp__P()[pir::co​nst::IGLOBALS_LIB_PATHS]))
08:45 p6eval nqp: OUTPUT«[ "./", "/home/p6eval/nqp/install/lib/​parrot/3.6.0-devel/include/", "/home/p6eval/nqp/install/lib​/parrot/3.6.0-devel/include/" ] [ "./", "/home/p6eval/nqp/install/lib/​parrot/3.6.0-devel/library/", "/home/p6eval/nqp/install/lib​/parrot/3.6.0-devel/library/" ] [ "dynext/", "/ho…
08:45 moritz nqp: say(nqp::join(' ', pir::getinterp__P()[pir::con​st::IGLOBALS_LIB_PATHS][1]))
08:45 p6eval nqp: OUTPUT«./ /home/p6eval/nqp/install/lib​/parrot/3.6.0-devel/library/ /home/p6eval/nqp/install/lib/​parrot/3.6.0-devel/library/␤»
08:45 moritz cotto++
09:04 woosley left #parrot
09:46 slavorg joined #parrot
09:57 pjcj_ is now known as pjcj
10:07 contingencyplan left #parrot
10:44 preflex_ joined #parrot
10:49 preflex left #parrot
11:15 dalek nqp: 1b06d16 | jonathan++ | / (24 files):
11:15 dalek nqp: Eliminate the REPR PMC, which wrapped around the REPR function pointer table; after a previous refactor that table is now always a singleton. Makes things simpler, and removes a level of indirection for every REPR operation.
11:15 dalek nqp: review: https://github.com/perl6/nqp/commit/1b06d16100
11:48 dalek rakudo/nom-install: 9da32b2 | moritz++ | / (2 files):
11:48 dalek rakudo/nom-install: compile a lot more things in blib/ instead of src/gen
11:48 dalek rakudo/nom-install:
11:48 dalek rakudo/nom-install: That way we have a more consistent layout between source tree and installation tree
11:48 dalek rakudo/nom-install: review: https://github.com/rakudo/rakudo/commit/9da32b2e0c
11:48 dalek rakudo/nom-install: f74a171 | moritz++ | / (3 files):
11:48 dalek rakudo/nom-install: be more consistent with build locations
11:48 dalek rakudo/nom-install: review: https://github.com/rakudo/rakudo/commit/f74a171e7f
11:48 dalek rakudo/nom-install: bcb8d70 | moritz++ | src/Perl6/ (2 files):
11:48 dalek rakudo/nom-install: simplify module loading
11:48 dalek rakudo/nom-install: review: https://github.com/rakudo/rakudo/commit/bcb8d70668
12:18 jsut joined #parrot
12:21 dalek nqp: e9244ec | jonathan++ | src/HLL/SerializationContextBuilder.pm:
12:21 dalek nqp: Get an SC to track those others it ends up referencing.
12:21 dalek nqp: review: https://github.com/perl6/nqp/commit/e9244ec4fd
12:21 dalek nqp: 3279ea7 | jonathan++ | src/ (2 files):
12:21 dalek nqp: Add a way to give an SC a friendly description.
12:21 dalek nqp: review: https://github.com/perl6/nqp/commit/3279ea7231
12:21 dalek nqp: 95fbb94 | jonathan++ | src/ (3 files):
12:21 dalek nqp: Improve detection of wrong version of pre-compiled code being used, and include the filename in the error rather than a weird SC identifier.
12:21 dalek nqp: review: https://github.com/perl6/nqp/commit/95fbb9402b
12:23 jsut_ left #parrot
12:41 dalek rakudo/nom: c19671d | jonathan++ | / (2 files):
12:41 dalek rakudo/nom: Bump NQP revision and chase 6model API updates.
12:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/c19671d825
12:41 dalek rakudo/nom: d0ce251 | jonathan++ | src/Perl6/Grammar.pm:
12:41 dalek rakudo/nom: Add description to SC if available, so we can get the better dependency out of date errors.
12:41 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d0ce251d27
12:45 bluescreen joined #parrot
12:50 dalek nqp: 4a314bf | moritz++ | t/nqp/58-attrs.t:
12:50 dalek nqp: fix 58-attrs.t
12:50 dalek nqp: review: https://github.com/perl6/nqp/commit/4a314bf301
12:51 whiteknight joined #parrot
12:52 whiteknight left #parrot
12:52 whiteknight joined #parrot
12:52 whiteknight good morning, #parrot
12:53 tadzik good morning whiteknight
12:53 whiteknight hello tadzik
12:54 whiteknight msg soh_cah_toa that "verbose" named parameter should cause the chmod function to output a record to stdout. Take a look at the cp() function for an example. I would rather the behavior be properly implemented instead of being removed
12:54 aloha OK. I'll deliver the message.
12:58 atrodo =~
13:04 whiteknight !!!
13:04 * whiteknight finally fixed a terrible bug at work
13:05 moritz as terrible as dropbox's "any password accepted" bug?
13:05 whiteknight not quite that bad
13:06 whiteknight inside a stored proc called from a stored proc called from a stored proc, called from extremely convoluted C# code, there was a field varchar(20) that should have been varchar(5)
13:06 whiteknight er, varchar(50)
13:06 whiteknight and the overflow warning was helpfully being converted to a fatal error, then rethrown with a less helpful error message
13:06 moritz ah, failing at failing
13:06 moritz the good old favorite
13:07 atrodo Ah, the rethrow but don't tell you original exception bug.  I hate that
13:07 whiteknight I love this construct: try { ... } catch(exception_with_helpful_details) { throw new Exception("Generic error message"); }
13:08 atrodo (generic excpetions)--
13:11 daniel-s left #parrot
13:11 bubaflub joined #parrot
13:11 whiteknight Actually, the SQL exception wasn't particularlyl helpful either. It told me that a field was overflowing, but wouldn't tell me which field, which table, or in which of the millions of nested stored procs
13:13 daniel-s joined #parrot
13:14 particle joined #parrot
13:14 atrodo whiteknight> I take it you work at a place that puts most of it's business logic in stored procedures?
13:15 whiteknight surprisingly, no.
13:15 bubaflub_ joined #parrot
13:15 whiteknight stored procs are mostly just for data access, but there is a lot of complicated "optimization" going on
13:15 bubaflub_ ~
13:15 bubaflub left #parrot
13:15 bubaflub_ is now known as bubaflub
13:16 dalek rakudo/nom: 10d4051 | (Solomon Foster)++ | src/core/ (2 files):
13:16 dalek rakudo/nom: Start to implement sign.
13:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/10d4051806
13:17 atrodo whiteknight> premature optimizations?
13:17 whiteknight in some places, maybe. They're very careful about trying not to load more data at any point than is strictly necessary
13:18 atrodo whiteknight> Doesn't sound too bad
13:18 whiteknight so the DB does a heck of a lot of filtering and limiting
13:18 whiteknight Selecting data sets into temporary tables, and then selecting subsets from temporary tables, etc
13:19 TiMBuS joined #parrot
13:36 bubaflub left #parrot
13:36 bubaflub joined #parrot
13:38 RobertLJ joined #parrot
13:51 bubaflub left #parrot
13:52 bubaflub joined #parrot
14:19 jay ~~
14:19 tadzik hey jay
14:19 jay morning tadzik, all
14:20 whiteknight good morning jay, tadzik
14:21 smash joined #parrot
14:21 smash hello everyone
14:21 whiteknight good morning smash. How are you doing today?
14:21 smash whiteknight: fine thank you, and you?
14:22 Felipe good morning all
14:22 whiteknight smash: I'm doing well, thanks. Packing up, moving to a new place at the end of the week. Staying very very busy
14:22 whiteknight hello Felipe
14:23 whiteknight Felipe: The weekly design meeting is today in #parrotsketch at 19:30 UTC. You should come
14:24 Felipe okay
14:30 smash whiteknight: good luck with movings :)
14:30 bubaflub left #parrot
14:30 bubaflub joined #parrot
14:44 fperrad joined #parrot
14:44 dalek rakudo/nom: 9c39731 | (Solomon Foster)++ | src/core/Real.pm:
14:44 dalek rakudo/nom: Add Real.sign(Real:U:).
14:44 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/9c39731fe9
14:50 dalek rakudo/nom: bbde437 | (Solomon Foster)++ | t/spectest.data:
14:50 dalek rakudo/nom: Turn on sign.t.
14:50 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/bbde4376db
14:54 jay whiteknight: followup on the compilation issue, simple pure PIR example where I'm not getting any gains to compiling to bytecode (and you can probably tell me why):  https://gist.github.com/1106928
14:56 whiteknight jay: The PIR compilation process is pretty speedy. I also suspect some inefficiencies in bytcode loading
14:56 whiteknight I would expect to see some kind of improvement. So it's weird that it isn't the case
14:57 jay Ok... I also found the following http://www.parrot.org/wiki/how-convert-pir-c
14:57 jay This seems to imply that we wouldn't expect to be able to do as well as compiled C code in an HLL like I'm building... and that ultimately performance would need to be obtained by moving certain things back to C?
14:57 whiteknight hmm I haven't seen that before
14:58 whiteknight we would never expect to do as well as compiled C code. There's no way
14:58 jay I plead ignorance... I just don't know what is "reasonable" to expect for performance in a Parrot HLL compared to R's interpreter (it doesn't yet have JIT or anything).
14:58 whiteknight moving certain operations to be written in C instead of PIR can bring speedups in certain cases, but not all. There is overhead in switching between the two contexts
14:59 whiteknight jay: Are you running an optimized Parrot?
14:59 jay Er... um....   I did the configure and build as recommended, running Ubuntu.  No special things, no.
15:00 tadzik you can also go full hardcore and try --debugging=0 :)
15:00 whiteknight jay: Okay, when you configure, use "perl Configure.pl --optimize"
15:00 whiteknight That will cut out all the debugging nonsense. Should be a significant speedup
15:00 tadzik it is
15:00 whiteknight well, not all the debugging stuff, just the various assertions, it inlines some code, etc
15:01 jay Ah -- so your defaults are "developer defaults" rather than some "stable end-user defaults".
15:01 whiteknight jay: It only sounds stupid if you say it like that
15:01 whiteknight :)
15:01 jay lol  Different worlds.  I tend to explain my work to end-users, not to developers.
15:02 whiteknight Eventually, we probably want to invert that. --optimize should be the default and would need to be turned off for internals development
15:02 jay Interesting philosophical issues here, to do with how you see Parrot now, and how you see it in 1 year, 5 years, etc... and outreach to the "real world".
15:02 whiteknight jay: Definitely try to rebuild Parrot with --optimize. You will see improvements, but still won't be as good as C
15:03 jay Doing it now, will report back on the differences.
15:03 whiteknight awesome
15:03 * whiteknight makes a mental note to document that somewhere, in big bold letters
15:03 * whiteknight loses a few other mental notes, trying to find space for that new one
15:06 jay My advisor used to say, 'if you don't write it down, it never happened.'
15:06 whiteknight yeah, I'm a walking example of that
15:09 atrodo I need a midget on my back to act as my stenographer.
15:12 jay Looks like about a 5x speedup.  Still no performance improvement by compiling to bytecode.  https://gist.github.com/1106928
15:12 moritz what about making --optimize the default, and requiring a --debug to disable it?
15:13 whiteknight moritz: that's what I'm thinking
15:13 tadzik jay: maybe pir compiler is fast enough
15:13 tadzik (to not make compilation visible)
15:13 tadzik jay: how about --optimize --debugging=0 ?
15:13 whiteknight jay: 5x? Not bad. I'm flummoxed by the lack of performance improvements with compiling to bytecode
15:14 whiteknight It may be that for such a small program, the overhead of compilation is as small as the overhead in packfile loading
15:14 whiteknight as program size increases, I would expect the differences between the two to manifest
15:14 dalek parrot: 66e6aee | moritz++ | README:
15:14 dalek parrot: recommend Configure.pl --optimize
15:14 dalek parrot: review: https://github.com/parrot/parrot/commit/66e6aee5d8
15:14 moritz not the best solution, but better than doing nothing for now, IMHO
15:14 jay Maybe.  I'll redo my NQR (HLL) benchmarks now, unless there is interest in tadzik's addition of --debugging=0?  Easy enough while I'm doing this I suppose, give me a few minutes.
15:15 moritz jay: that won't make much of a difference, IME
15:15 tadzik it was quite significant last time I was doing that
15:15 tadzik (which was a year ago)
15:15 jay I'll do it.  Give me a few more minutes and I'll report back.
15:15 tadzik but that was the whole Rakudo I think, not a short PIR file
15:21 daniel-s left #parrot
15:23 dmalcolm joined #parrot
15:24 jay No change adding --debugging=0.  I'll go redo by NQR benchmarks next.
15:24 tadzik I see
15:25 jay But like you say, that was pretty plain-vanilla PIR, nothing fancy at all.
15:25 tadzik how about the whole NQR in some case?
15:26 jay Yes, that is what I'll do next.  Though what do you mean by "the whole NQR" ?
15:26 tadzik oh, the pir is the pir generated from nqr code?
15:26 tadzik did the non-precompiled case sped up with --debugging=0?
15:27 jay No, this PIR was just my own simple PIR to get a handle on native Parrot speed.  --debugging=0 didn't make a difference either in the .pir or the .pbc.
15:27 jay My NQR version will have all the overhead of the full HLL.  Will take me a few minutes.
15:28 tadzik that's where --debugging=0 might make a difference
15:36 jay Ok, cool.  I'll work on a plot to summarize the results, but old NQR --> NQR after --optimize --debugging=0 gives a 2.5x increase, and compiling to bytecode gives about an addition 10% speed gain, for a total of roughly 3x speed increase over the old NQR interpreted benchmarks.
15:46 whiteknight http://www.unlimitednovelty.com/2011/07/tr​ouble-with-erlang-or-erlang-is-ghetto.html Interesting read about Erlang
15:49 whiteknight jay: 3x is certainly nothing to sneeze at
15:50 jay Nope.  I have a PDF... nice slope improvement as a result of the optimization, but still (as I think you would expect) not in the same ballpark as R.
15:51 jay www.stat.yale.edu/~jay/while.pdf
15:52 jay Thanks -- this was a big help whiteknight++ tadzik++ moritz++
15:56 jay I suppose I could add a line for the straight PIR loop... the intercept would be around 0.02, and the slope very shallow, like the green or even shallower.  R's green intercept is high because of the startup overhead of course.
15:56 whiteknight jay: It's good to see the improvement. I am going to suspect from the graph that R has a JIT
15:56 jay The problem is that nobody would actually think straight PIR is a fair comparison to an end-user package.  No, R has no JIT.  That is the interpreter working on a script.
15:57 whiteknight hmm... That's weird. I would have to see what they are doing
15:57 whiteknight I don't see what else would explain having so much startup overhead, and so shallow a curve
15:58 jay They load various packages on startup and handle a lot of accounting to support the user I'm sure.  As for shallow: it's only shallow compared to the alternatives... and maybe NQR is just really bad.
15:59 whiteknight NQR is going to generate unoptimized PIR code that is much more verbose than any PIR code you or I would write by hand
16:00 jay Fair enough... but there is no way around that, right?
16:00 whiteknight At the moment, no. We have an optimization framework, but I don't think anybody has written any optimizations for it yet
16:00 whiteknight so that's sort of a non-starter
16:01 jay I'll grab some lunch and then see how my other benchmarks change.  They are equally interesting, not quite as trivial.
16:02 whiteknight ok
16:02 whiteknight At the moment you are probably going to have to live with some bad performance. We're working on improving things
16:04 jay I'm not interested in performance per se, only in coming to terms with this as a possibly viable alternative to R for future development.  You have interoperability advantages that R can't touch, and scalable advantages that R can't touch.  Wins and losses, obviously.
16:04 jay back in a bit...
16:15 benabik joined #parrot
16:16 benabik ~~
16:32 whiteknight hello benabik
16:35 mj41 left #parrot
16:36 benabik o/ whiteknight
16:47 Kulag left #parrot
16:54 Kulag joined #parrot
16:55 jay If I do      parrot foo.pir     does that compile to bytecode and then run?  I.e. is it really equivalent to the two-step process of    parrot -o foo.pbc foo.pir ; parrot foo.pbc ?
16:56 whiteknight jay: basically, yes
16:57 whiteknight Parrot runs bytecode, so the PIR compiler generates a bytecode PackFile structure in memory from the input code
16:57 whiteknight when you do it with a .pbc, Parrot reads in the .pbc file and creates a PackFile structure in memory also
16:57 jay Ah.  That explains why my "compiled" runs are just faster by a fixed speed -- the fixed speed of compilation.  Not really interesting.
16:57 whiteknight right
16:58 whiteknight Like I said, I suspect there are some inefficiencies in the .pbc file loading sequence
16:58 whiteknight but that would only shave some time off the top, not fix overall complexity
16:59 jay www.stat.yale.edu/~jay/meanexp.pdf      similar gains to before.  Here, I'm using GSL for the mean of a vector of values: should be very fast.  NQR will be slower than R because the random number generation involves PIR looping, rather than C code generating a vector of random values simultaneously (as would happen in R).
16:59 whiteknight okay, that's a much better graph. I still can't imagine why the R performance curve is shaped like that
17:00 benabik jay: "optimized" NQR?
17:00 whiteknight how can it be almost flat across that entire range?
17:00 jay So this is very interesting: I hypothesize that the NQR performance could match the R performance if I created a vectorized random number generator in C... the difference for this benchmark would only be the intercept, not the slope.
17:00 jay "optimized" by building Parrot with --optimize as whiteknight++ recommended.
17:00 benabik Ah, yes, that helps a lot.
17:01 jay It only looks flat... it's very shallow... just much faster than NQR, nothing more.
17:01 whiteknight it's flat enough to be disconcerting
17:01 jay Yeah, sorry about that.  R is pretty good.
17:02 whiteknight Do you know much about the R interpreter internals?
17:02 jay In this benchmark, almost everything is compiled C code, though.
17:02 whiteknight ok
17:02 jay The interpreter is a nightmare of C code I think.
17:03 jay There are about 300,000 lines of C code in the src/ tree, plus another 70,000 lines in the header files.
17:04 jay So actually the slope difference is due entirely to the difference between looping in PIR for the random number generation vs looping in C with a vectorized random number generator.
17:07 Coke it's not surprising that R is faster than NQR. I think tcl8.5 was some several hundred times faster than partcl.
17:07 whiteknight I would need to look at the implementation again to see, but I think our random number generator is simplistic
17:07 whiteknight I think it falls back to system rand()
17:07 jay Off-topic: https://gist.github.com/1107238  This is from Dan Adler, who is in Germany I think, a very sharp guy who does lots of different things (not just R stuff).  This project of his might actually have some value to Parrot (but I don't know enough to guarantee it).  Worth a 3-minute glance for one of you.
17:08 jay whiteknight: I used the R random number generator, not yours.
17:08 jay So I'm really controlling for as many differences as possible.
17:08 whiteknight jay: Yes, that rdyncall does look interesting. Same thing as our NCI system. Maybe better
17:09 whiteknight jay: Oh, you were calling the R random number generator through NCI?
17:09 jay Dan Adler is *really* sharp.  Trust me on that one, I don't say it much.  One of the best I've met.
17:09 jay whiteknight: yes.
17:10 whiteknight Any time you call C code from PIR code, there's a context switch which is non-trivial. I've done benchmarks of programs where I've seen significant speedups by rewritting particular bits of C code into PIR
17:10 whiteknight there are no hard rules, but sometimes the overhead is prohibitive. I suspect calling it in a tight loop exacerbates the problems
17:10 jay whiteknight: so I would be looping in PIR making repeated calls to the random number generator via NCI... so as I said I could probably match R by writing a vectorized random number generator wrapper in C.
17:10 jay whiteknight: yes, we agree.
17:11 mj41 joined #parrot
17:11 jay Actually, if you guys got Dan Adler interested in some aspect of Parrot, it would be huge for you.  Maybe I could help there, I know Dan pretty well.
17:11 benabik whiteknight: PIR->C has a large cost?  I thought the cost hit when we went C->PIR...
17:11 atrodo Pretty sure it's either way
17:13 benabik Is PIR->C slow due to FFI problems?  Is it faster if you make a custom PMC?
17:14 whiteknight cost is either way. PIR -> C is expensive. C -> PIR is even worse
17:14 atrodo My understanding is that the transition in/out of the VM is expensive
17:15 benabik Hence the desire to get as much into the VM as possible in M0?  Also hopefully decrease that barrier.
17:15 whiteknight When you call an NCI function, you need to invoke the NCI wrapper PMC, pull the parameters out of the calling context with PCC, and then call the C function. Then, if there are return values, it's the reverse
17:15 whiteknight wrap the C returns in Parrot types, put them in the return continuation, continue
17:16 RobertLJ left #parrot
17:17 benabik Hm.  Most of that is difficult to avoid.  Pity.
17:19 whiteknight Well, that's exactly what M0 is designed to overcome
17:19 whiteknight I think there is a lot of room to optimize here as well
17:20 dalek NQR: 1a1d830 | (Jay Emerson)++ | STATUS:
17:20 dalek NQR: Benchmarks updated
17:20 dalek NQR: review: https://github.com/NQRCore/NQR/commit/1a1d8300c1
17:26 jay Would M0 eventually allow "compiling" C code into the VM directly, avoiding the overhead of the NCI?  I'm just trying to see the big picture.
17:34 whiteknight jay: M0 is going to allow easier JIT, which will compile bytecode down to C code, optimizing along the way
17:35 whiteknight M0 also will have integrated FFI, so much of the overhead of NCI could disappear if we were clever about it
17:36 jay ok, thanks.
17:41 cotto_work ~~
17:43 Felipe ~~
17:58 dalek TT #2164 created by Andy Dougherty <doughera@…>++: Error detecting attributes (g++-3.3)
17:58 dalek TT #2164: http://trac.parrot.org/parrot/ticket/2164
17:58 dalek TT #1047 closed by jkeenan++: pf_items assumes sizeof(INTVAL) == sizeof(opcode_t)
17:58 dalek TT #1047: http://trac.parrot.org/parrot/ticket/1047
17:59 dukeleto jay: M0 will be written in C, but it won't know anything about compiling C code, if that clarifies things
18:00 benabik dukeleto: But it will know very deeply about talking to C code, yes?
18:01 dukeleto benabik: FFI/NCI will be in M0, but libffi does most of the heavy lifting
18:01 jay Yes, I think I'm in the ballpark.  And it does seem to related to previous benchmark results this AM where the NCI may explain much of the differences.
18:02 cotto_work dukeleto: how familiar are you with pack/unpack in perl 5?
18:02 dukeleto jay: our NCI system most probably has some dog-slow codepaths that have not been optimized at all, or behavior you didn't ask for is assumed and unnecessary work is being done
18:02 dukeleto cotto_work: a few notches on my stick. why?
18:02 cotto_work dukeleto: I'm having platform-specific issues - https://gist.github.com/1106278
18:03 jay dukeleto: We may have covered that...  --optimize and rebuilding Parrot gave a pretty damn impressive speedup.
18:03 dukeleto jay: ah, yes. That will do it :)
18:03 dukeleto jay: optimized builds are much harder to debug, but they are much faster :)
18:04 dukeleto cotto_work: i means something different to each perl. I think you need to be more specific
18:04 dukeleto cotto_work: like specifying the "width" of the integer
18:06 cotto_work dukeleto: I was using "l", but that seemed to be at least 32 bits rather than exactly 32 bits.
18:07 lucian joined #parrot
18:07 dukeleto jay: dyncall looks very interesting
18:08 jay I don't know enough to know if it would be helpful, but I have the highest opinion of Dan Adler.  He's not a statistician, he's more of a computer science jock/hacker.  He only works on things that he finds cool.  I think you would like him!
18:09 dukeleto jay: dyncall looks very similar to libffi
18:10 jay Well, libffi saved my bacon playing around with GSL... though bubaflub seems to have a workaround with the thunks.
18:16 atrodo cotto_work> Did you try N?
18:16 dalek rakudo/nom: eb38b99 | jonathan++ | src/Perl6/Actions.pm:
18:16 dalek rakudo/nom: Fix thunk building, so BEGIN say 1 + 2 will work.
18:16 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/eb38b99402
18:17 rurban joined #parrot
18:18 rurban Will rakudo-star-2011.07 the next and when? Maybe someone knows
18:21 rurban Because it might be the last one with these packaging rules and I want to provide it for cygwin
18:28 cotto_work rurban: the #perl6 folks could probably answer that better than we can
18:29 rurban thanks. yes, it's today. pmichaud already working on it.
18:29 rurban left #parrot
18:52 jay left #parrot
19:00 NotFound left #parrot
19:01 NotFound joined #parrot
19:18 soh_cah_toa joined #parrot
19:19 PerlPilot is now known as PerlJam
19:22 dalek rakudo/nom: 08c2f9c | jonathan++ | src/Perl6/Metamodel/RoleToClassApplier.pm:
19:22 dalek rakudo/nom: Be more consistent on quoting in an error (TimToady++).
19:22 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/08c2f9cce6
19:25 bubaflub ping dukeleto
19:28 whiteknight aloha: time?
19:28 aloha whiteknight: time is a lion, where i am a lamb.
19:28 whiteknight aloha: clock?
19:28 aloha whiteknight: LAX: Tue, 12:28 PDT / CHI: Tue, 14:28 CDT / NYC: Tue, 15:28 EDT / UTC: Tue, 19:28 UTC / LON: Tue, 20:28 BST / BER: Tue, 21:28 CEST / TOK: Wed, 04:28 JST / SYD: Wed, 05:28 EST
19:28 whiteknight #ps in 2
19:28 whiteknight Let's see some last-minute reports!
19:31 cotto_work there you go
19:32 whiteknight #ps in now
19:34 benabik aloha: time is also you probably meant clock
19:34 aloha benabik: Okay.
19:34 benabik aloha: time?
19:34 aloha benabik: time is a lion, where i am a lamb. or you probably meant clock
19:36 contingencyplan joined #parrot
19:40 ingy hi benabik o/
19:40 benabik o/ ingy
19:40 ingy :)
19:47 dukeleto bubaflub: pong
19:47 tcurtis ~~
19:47 dalek parrot: 8cc26e4 | fperrad++ | runtime/parrot/library/Archive/ (2 files):
19:47 dalek parrot: [Archive] add some documentation
19:47 dalek parrot: review: https://github.com/parrot/parrot/commit/8cc26e4a56
19:47 dukeleto soh_cah_toa: pong
19:47 bubaflub dukeleto: i'm looking at jitterbug stuff - do you have an instance running by any chance?
19:48 dukeleto bubaflub: yep, a few
19:48 bubaflub dukeleto: great.  can i take a peek?  i may actually use this for work...
19:48 dukeleto bubaflub: here is the newest one, which i know is working currently: http://dev.cashmusic.org:3000/
19:49 dukeleto bubaflub: i had one at jitterbug.leto.net:3000, but i think something borked it
19:49 bubaflub dukeleto: ok
19:50 cotto_work dukeleto: #ps?
19:50 bubaflub dukeleto: what i'm looking for is a dashboard that could track number of test failures per test run.  also, our test suite takes ~24hrs to run, so i'm looking for something that can run via cron and not post commit-hook
19:51 dukeleto bubaflub: sure, doable
19:53 bubaflub dukeleto: great.
19:53 bubaflub dukeleto: saves me from having to do my own... i started doing it in Catalyst but started feeling real lazy real quick
19:54 dukeleto bubaflub: basically, you would run builder.pl in cron, and don't add a github hook
19:54 bubaflub dukeleto: great.  and what about charting / report type stuff.  already there / easily extensible so i could add something in?
19:57 dukeleto bubaflub: it is a dancer app, reasonably easy to start hacking on
19:57 bubaflub dukeleto: great.  i'm thinking for work i'd need a reports section (probably with jQuery charting) and user/login stuff.
19:58 dukeleto bubaflub: http://jitterbug.pl
19:58 dukeleto bubaflub: sounds like much of the stuff you want would be nice to have in jitterbug
19:59 bubaflub dukeleto: yep.  i'm angling to get paid to hack on open source :-)
19:59 dukeleto bubaflub: there ya go!
20:01 fperrad left #parrot
20:09 ambs joined #parrot
20:10 benabik whiteknight: If I use Packfile.view, I have to run some kinds of sub manually, yes?  I'm thinking of :load and :init here, but not sure if there are other kinds.
20:11 whiteknight benabik: at the moment, the ones you can get at manually are :main, :load, and :init
20:11 whiteknight I have a new branch in the works where you can create and fetch subs by any arbitrary tag name
20:12 benabik whiteknight: Right.  And nothing in the Packfile{,View} PMCs will run :load and :init for me, right?  So I need to run them manually?
20:12 whiteknight PackfileView certainly will not. I don't think Packfile and friends will either
20:15 benabik :immediate and :postcomp both seem like a bad idea.
20:16 NotFound_b joined #parrot
20:17 NotFound left #parrot
20:18 NotFound_b is now known as NotFound
20:18 whiteknight :immediate and :postcomp both run during compilation or immediately thereafter. Those are tags for teh compiler only, and it doesn't make sense to keep that data around after compilation
20:19 cotto_work aloha: PDS Q2 2011 is Saturday July 30 at 2100 UTC
20:19 aloha cotto_work: Okay.
20:20 benabik whiteknight: Those are specifically for IMCC, so I don't need to worry about them for PCT?
20:20 whiteknight Depends what you mean by "worry about them"
20:21 whiteknight current PCT generates :immediate subs. I don't know if it also generates :postcomp
20:21 bluescreen left #parrot
20:33 whiteknight Felipe++
20:37 Coke Felipe: welcome aboard.
20:37 Felipe thanks
20:40 tadzik . o O ( Felipe gets Felipe++ for joining. Send some to mom! )
20:41 perlite_ joined #parrot
20:44 Felipe whiteknight++
20:44 perlite left #parrot
20:44 perlite_ is now known as perlite
20:45 whiteknight Felipe: That pull request looks good to me. I haven't tested it yet, but you can merge it in if you want
20:45 jay joined #parrot
20:46 dalek NQR: 690825b | (Jay Emerson)++ | / (4 files):
20:46 dalek NQR: Revised bracket set operations [] for atomic set... not
20:46 dalek NQR: yet vectorized.  Will do [] get properly next.  whiteknight++
20:46 dalek NQR: for matrixy examples.
20:46 dalek NQR: review: https://github.com/NQRCore/NQR/commit/690825ba77
20:50 whiteknight I really do want to get back into matrixy at some point
20:50 whiteknight I would love to get that fixed up and working again, with all the cool new tools and libraries that we've been building
20:50 jay Or else join the dark side and team up with me...
20:50 whiteknight I would love to do that too
20:51 jay At this point, the advice is greatly appreciated.  Until I learn more, advice is more valuable than actually effort.
20:51 jay < actual effort >
20:52 jay where "actual effort" is not intended to belittle "advice"... "advice" is clearly effort... just not direct coding effort.  Ai carumba.
20:53 whiteknight :)
20:53 whiteknight My goal, if I can get matrixy running at least a reasonable subset of the M language, is to be able to use it as a nice high-level interface to PLA
20:54 jay I just got the basic bracket operator working, so v[5] <- 10000 works separately from a <- 10000.  Subtle, but not terribly difficult.
20:54 whiteknight that's a nice step forward
20:54 jay If I had GSL bindings, would that supplant the need for PLA?
20:54 Felipe whiteknight: okay
20:54 whiteknight jay: I really need to learn R, if I want to be playing with it convincingly. You know of any good tutorials?
20:54 bluescreen joined #parrot
20:54 whiteknight jay: PLA is just matrices and BLAS. It stores matrices in a format that should be usable by GSL
20:55 whiteknight jay: think of PLA like the data storage, GSL would be something to do with that data
20:55 * Coke wonders if R is the language he remembers hearing about on Flowing Data.
20:55 jay whiteknight: Yup: ask me.  I'm the best (ha).  I know some things about the language that matter if you are trying to learn something of use for Parrot or Parrot HLLs.
20:56 jay No, seriously, just a sec, I'll give you a link.
20:57 jay Check out the PDF in this directory.  Intended as an Intro for people with coding experience in other languages.  http://www.stat.yale.edu/~ja​y/Brazil/Campinas/IntroToR/
20:58 jay I need to get organized and keep better track of various talk material.  That one was from a trip to Brazil last summer.
20:58 whiteknight jay: For an idea about what PLA does, check out this link: https://github.com/Whiteknight/parrot-linear-​algebra/blob/master/examples/elimination.nqp
21:00 whiteknight basically, it makes working with 2D matrices dirt simple. They just work the way you would expect, without having to play around with arrays and other not-quite-right stuff
21:00 jay Ok, so I remember seeing the NumMatrix2D class.  Fundamentally, the underlying object should just be a Fixed*Array (or a Resizable*Array) -- R has classes vector, matrix, and array (and has no scalar... a "scalar" is a vector of length 1).  But a matrix is just a 2D array for user-friendliness.
21:01 whiteknight right. Internally, NumMatrix2D is just an allocated block of memory, like an array. An [X,1] matrix is identical to an array of length X
21:02 jay Adding a class to NQR is way up near the top of my "todo" list.  So far I just have vectors, and that was the right way to start.
21:03 whiteknight I'm heading home now. We can chat more later tonight
21:03 jay k... good luck packing!
21:03 whiteknight thanks! I need it!
21:03 jay not fun.
21:03 whiteknight left #parrot
21:09 jay Coke: Flowing Data?  Not sure.  I did some preliminary work on handling streaming data once...
21:11 Coke jay: http://flowingdata.com/
21:12 Felipe brb
21:12 Coke yes, that was it. e.g.:
21:12 Coke http://flowingdata.com/2011/05/11/how-​to-map-connections-with-great-circles/
21:14 jay Coke: actually pretty nice examples on that second page.  The best-known visualization guy (in terms of the subject matter, independently of the software) is Edward Tufte.  http://www.edwardtufte.com/tufte/  He has a few excellent books, and does the lecture circuit.
21:16 PerlJam Tufte++
21:17 jay An amazing speaker, too.  Worth doing one of his workshops just to observe him in action.
21:20 * PerlJam wonders if Ed Tufte and Hans Rosling ever crossed paths.
21:21 jay jay think that is an excellent question.  Ed is in the area, and I actually need to track him down... I'll try to ask.
21:23 bluescreen left #parrot
21:26 ambs left #parrot
21:31 mj41 left #parrot
21:32 lucian left #parrot
21:36 lucian joined #parrot
21:37 bluescreen joined #parrot
21:43 Psyche^ joined #parrot
21:43 theory joined #parrot
21:48 Patterner left #parrot
21:48 Psyche^ is now known as Patterner
22:01 bubaflub left #parrot
22:17 theory left #parrot
22:19 darbelo joined #parrot
22:30 theory joined #parrot
22:35 soh_cah_toa left #parrot
22:35 dalek lalrskate: b1edb40 | tcurtis++ | src/LALR/DPDA.winxed:
22:35 dalek lalrskate: Remove debugging lines.
22:35 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/b1edb40911
22:35 dalek lalrskate: f3c7281 | tcurtis++ | / (3 files):
22:35 dalek lalrskate: Implement interpretation of read transitions.
22:35 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/f3c7281104
22:35 dalek lalrskate: 1b3ef6a | tcurtis++ | / (2 files):
22:36 dalek lalrskate: Add test and support for Top transitions.
22:36 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/1b3ef6ad4f
22:36 dalek lalrskate: c62447f | tcurtis++ | t/dpda-interpreter.t:
22:36 dalek lalrskate: Add test that input is actually removed from the input string by ReadTransitions.
22:36 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/c62447f478
22:36 dalek lalrskate: 11cc92a | tcurtis++ | src/LALR/DPDA/Interpreter.winxed:
22:36 dalek lalrskate: Pop the read symbol when transitioning along a ReadTransition.
22:36 dalek lalrskate: review: https://github.com/ekiru/l​alrskate/commit/11cc92a58c
22:59 jay ./in
23:02 NotFound left #parrot
23:06 whiteknight joined #parrot
23:15 whiteknight good afternoon, #parrot
23:15 Coke gluten abend.
23:16 whiteknight sounds tasty
23:25 Felipe lol
23:26 Felipe whiteknight: weird, I tried the automerge, but it did nothing.
23:26 whiteknight hmm. weird
23:27 Felipe no notification either
23:27 Felipe I'll merge by hand
23:27 whiteknight ok
23:33 benabik left #parrot
23:35 benabik joined #parrot
23:39 benabik left #parrot
23:40 benabik joined #parrot
23:41 benabik left #parrot
23:42 kid51 joined #parrot
23:44 darbelo left #parrot
23:45 Coke THE AUTOMERGE, IT DOES NOTHING!
23:45 lucian left #parrot
23:45 Felipe I've used it in other project...
23:46 Felipe but It failed now :D
23:46 lucian joined #parrot
23:51 preflex joined #parrot
23:53 lucian left #parrot
23:54 preflex_ left #parrot
23:54 lucian joined #parrot

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

Parrot | source cross referenced