Camelia, the Perl 6 bug

IRC log for #parrot, 2011-05-09

Parrot | source cross referenced

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

All times shown according to UTC.

Time Nick Message
00:00 bacek_at_work ~~
00:00 whiteknight msg pmichaud I suspect bacek's patch doesn't extend to x86_64. Can you try https://gist.github.com/961822 to see if it helps on your machine?
00:00 * bacek_at_work is really sad looking at benchmarks...
00:00 aloha OK. I'll deliver the message.
00:00 whiteknight bacek_at_work: don't worry, we'll fix them
00:02 bacek_at_work whiteknight, we do have PTR_SIZE defined. You can use it instead of sizeof().
00:02 whiteknight oh, I didn't know that. We can fix that patch before we commit it
00:03 bacek_at_work Something like #if PTR_SIZE == 4\n#define INVALID_PTR_MASK 3\n#else if PTR_SIZE == 8\n #define INVALID_SIZE_MASK = 7\n#else #define INVALID_PTR_MASK = 0\n #endif
00:04 whiteknight yeah, that would be better
00:04 whiteknight in either case, this should help pmichaud
00:04 bacek_at_work I hope so.
00:05 whiteknight I can't think of any other big reason for big performance regressions since 3.0
00:08 whiteknight bacek_at_work: how did you even figure out that function was the cause of the slowdowns?
00:08 plobsing whiteknight: why use preprocessor conditionals. why not (sizeof (void *) - 1)?
00:09 whiteknight plobsing: because shut-up. That's why.
00:09 whiteknight I don't know. I didn't think about it :)
00:09 benabik plobsing: Preprocessor conditionals are run once at compile time.  sizeof() is run every time the function is called.
00:09 plobsing benabik: not true. it is a compiler builtin
00:09 whiteknight benabik: the optimizer should deal with that no problem
00:10 whiteknight plobsing: yeah, there are definitely better ways to do it. I don't have my programming cap on right now
00:11 benabik Buh.  Head in other project...  Compiler _should_ collapse a constant expression, yes.
00:11 whiteknight benabik: just because *our* compilers don't usually do that doesn't mean most real compilers don't
00:12 whiteknight benabik: something something something your gsoc project something something something
00:12 benabik whiteknight: I had been following the backlog but not thinking about constant collapsing when I typed.
00:14 benabik whiteknight: And, IMHO, constant collapsing should be handled before you hit my GSoC work.
00:14 benabik whiteknight: Although a set of common passes for tree-optimization _would_ be nice.
00:15 whiteknight benabik: we do have a tree optimizations project that was done for GSoC last year. You might want to dust that off and see if it still works
00:15 whiteknight good practice for dealing with PAST/PST
00:15 whiteknight POST
00:15 benabik whiteknight: Hm, yes...  Making sure that works on nqp_pct might be nice.
00:16 benabik whiteknight: Am hampered by the fact that tree-optimization is just a framework for optimizers and not actually a library of optimizers.
00:16 * benabik adds another "would be nice" task to his pile.
00:16 whiteknight benabik: I think there were a few basic optimizations in there
00:17 whiteknight benabik: you should tree tree-optimizations as if it's just a standard step in the compilation process. that's how most compilers will probably do it
00:17 whiteknight even if the number of optimizations a compiler uses might be small by default
00:17 NotFound Constant collapsing is not rockey science, even winxed does it ;)
00:18 benabik whiteknight: Yes, the compiler object should get a PAST tree from the actions, pass it into tree-optimizer and then use to_pbc to it.  It's probably not appropriate to mangle the given PAST tree in PAST::Compiler though.
00:19 TimToady I tend to disapprove of constant collapsing done by an interpreter other than the one that would be used if the constants weren't collapsed, since it's easy to get out-of-sync type and language errors...
00:20 TimToady so I'd prefer a pass that merely told me that a bit of code was constant, and then run it like it's real code
00:20 whiteknight TimToady: Each compiler will pick which optimizations to use, if any
00:21 whiteknight the functionality to run any optimizations should be built-in, whether the compiler uses any or not
00:21 whiteknight I just want to make sure that during the GSoC work, the capability doesn't get neglected
00:22 NotFound Winxed evaluates at compile time some builtins when used with constant arguments. That may be hard at any level lower than the interpreter.
00:23 NotFound I mean, the compiler.
00:23 whiteknight integer and float constants are no-brainers to optimize. Strings too, since they're immutable
00:23 whiteknight pmcs are harder. You really can't constant-fold them in any portable, meaningful way
00:23 TimToady the more polymorphic your dispatch is, the less you can rely on anyone else to figure out which operator they should really be folded via
00:23 whiteknight especially if HLLs can arbitrarily map in new types for the built-ins
00:24 TimToady or however you say that in English...
00:24 whiteknight TimToady: true. Compiler authors are going to have to do a lot of work to determine which optimizations they want to use, and even to write their own custom passes
00:25 TimToady mostly they need the capability of migrating atributes up and down the tree, like "is pure enough to constant fold"
00:25 benabik left #parrot
00:25 NotFound whiteknight: so it may be easier to do it in the compiler.
00:25 whiteknight NotFound: right. Parrot doesn't do the optimizations. Parrot only provides the tools for other people to do them
00:28 whiteknight TimToady: being able to determine attribute purity is well outside the scope of Parrot
00:28 whiteknight but, PAST having a flag that says "this is pure", and letting the compiler set and read that flag is something we could do
00:35 NotFound What is "pure"?
00:37 bacek_at_work whiteknight, (how I found) it was only possible place which can explain such a big difference between runs.
00:47 lucian left #parrot
00:55 jrtayloriv left #parrot
01:04 whiteknight left #parrot
01:22 pmichaud 00:00 <whiteknight> msg pmichaud I suspect bacek's patch doesn't extend to x86_64.
01:23 pmichaud well.... since it improves things on x86_64, it must "extend to it", yes?  Or am I misunderstanding the statement?
01:23 pmichaud I mean, compare the rakudo-2011.04 and rakudo-2011.04-p1 times
01:25 bacek_at_work pmichaud, can you try whiteknight++ patch on github?
01:25 bacek_at_work It should improve amd64 performance
01:25 pmichaud instead of or in addition to the patch received via email?
01:25 bacek_at_work addition
01:26 pmichaud okay
01:26 pmichaud should I just compare the two versions, or should I also include 2011.04 and 2011.01 ?
01:26 pmichaud (the two patched versions)
01:26 cotto left #parrot
01:28 bacek_at_work just compare with -p1
01:28 bacek_at_work it will give good indication of performance
01:29 pmichaud will have results in about 60 mins
01:29 pmichaud (have a few other errands to do here)
01:29 pmichaud my new desktop is nice and fast :)
01:30 bacek_at_work :)
01:30 pmichaud pmichaud@kiwi:/zip/perl/rakudo-2011.04-p2/parrot$ patch -p1 <is_ptr_2.patch
01:30 pmichaud patching file src/gc/gc_gms.c
01:30 pmichaud Hunk #1 FAILED at 1520.
01:30 pmichaud 1 out of 1 hunk FAILED -- saving rejects to file src/gc/gc_gms.c.rej
01:30 pmichaud pmichaud@kiwi:/zip/perl/rakudo-2011.04-p2/parrot$
01:30 pmichaud ;(
01:32 pmichaud patch wants
01:32 pmichaud +    const size_t invalid_ptr_mask = sizeof(void*) == 8 ? 7 : 3;
01:32 pmichaud gc_gms.c has
01:32 pmichaud size_t            i;
01:33 pmichaud I'd prefer not to guess at this point, so I'll wait for an updated patch.
01:34 bacek_at_work Are you applying it to 3.0+patch or master?
01:34 pmichaud 3.3+patch
01:35 pmichaud 3.3+is_ptr.patch
01:35 bacek_at_work oops. 3.3
01:35 pmichaud definitely not master
01:35 bacek_at_work ok. I'll try to create new patch.
01:35 pmichaud I'm only working from releases at this point.
01:35 pmichaud I can benchmark master, too, if need be.
01:36 pmichaud this new benchmark harness+suite is making it much easier to run tests like this :)
01:37 pmichaud (I can patch either 3.3+first patch or an unpatched 3.3.... whichever is easiest for you :)
01:37 pmichaud afk, errands
01:46 woosley joined #parrot
01:50 rurban_ joined #parrot
01:52 rurban left #parrot
01:52 rurban_ is now known as rurban
02:02 bacek_at_work msg pmichaud https://gist.github.com/961919 on top of is_ptr.patch
02:02 aloha OK. I'll deliver the message.
02:03 luben pmichaud, in master I have tweeked gc default params, so you could benchmark it, the tweeks give some 5-10% speedup on core.pm on my systems
02:15 benabik joined #parrot
02:24 woosley left #parrot
02:41 pmichaud running benchmarks for -p1 and -p2 now
02:48 pmichaud while waiting for that... here's the same set of benchmark runs as earlier but run from my notebook:  https://gist.github.com/961962
02:49 woosley joined #parrot
02:53 pmichaud I'm also running the benchmarks on my old desktop... but it probably won't be finished with them until tomorrow morning (another 12 hours from now)
02:56 pmichaud oh, should only be about eight hours :)
03:15 pmichaud http://gist.github.com/961995  # no significant difference between -p1 and -p2 for core.pm
03:15 pmichaud (still waiting for other tests to complete)
03:29 pmichaud n@cpe-74-65-60-43.rochester.res.rr.com] has joined #parrot
03:29 pmichaud oops
03:30 pmichaud http://gist.github.com/962008  # results of -p1 versus -p2 for first sets of tests
03:30 pmichaud the system is still running the .p6 and spectests.... but so far there's no significant difference between -p1 and -p2
03:31 pmichaud afk for a while
03:42 bacek_at_work msg pmichaud can you also test 2011.01 on kiwi?  Or 2011.04-p2 on plum?
03:42 aloha OK. I'll deliver the message.
03:45 hudnix left #parrot
03:51 bubaflub left #parrot
04:29 pmichaud bacek_at_work: 2011.01 on kiwi should be the same numbers I posted earlier
04:29 pmichaud I can re-test if you like
04:30 pmichaud ore.pm: rakudo-2011.01 (ms2)        64.2    65.9    65.9    64.3       64.2   100.0%
04:44 soh_cah_toa left #parrot
04:44 pmichaud here's what I have so far:
04:45 pmichaud https://gist.github.com/961736  # kiwi, releases 2011.01 through 2011.04-p1-ms2
04:45 pmichaud https://gist.github.com/962060  # kiwi, 2011.04-p1 vs 2011.04-p2
04:45 pmichaud https://gist.github.com/961962  # plum, releases 2011.01 through 2011.04-p1-ms2
04:45 pmichaud I'm currently running 2011.01, 2011.04-p1 and 2011.04-p2 on plum
04:45 pmichaud I'll also re-run those builds on kiwi
04:48 bluescreen_ left #parrot
04:48 bluescreen left #parrot
04:48 bluescreen__ left #parrot
04:51 bacek_at_work pmichaud++ # benchmarking!
05:00 ShaneC joined #parrot
05:13 pmichaud core.pm results for 2011.01, 2011.04-p1, and 2011.04-p2, on kiwi:
05:13 pmichaud core.pm: rakudo-2011.01 (ms2)        66.6    67.0    65.5    65.6       65.5   100.0% rakudo-2011.04-p1 (gms)     68.3    68.4    68.3    68.6       68.3   104.3% rakudo-2011.04-p2 (gms)     68.3    68.5    68.5    68.1       68.1   104.0%
05:13 pmichaud oops
05:14 pmichaud that didn't format well
05:14 ShaneC left #parrot
05:14 pmichaud anyway, I'll let the rest of the bench marks run and post when I wake up from sleep
05:14 pmichaud afk, sleep
05:38 theory left #parrot
05:57 jsut joined #parrot
06:02 jsut_ left #parrot
06:17 birdwindupbird joined #parrot
06:51 fperrad joined #parrot
06:53 cotto joined #parrot
06:54 cotto ~~
06:54 tadzik o/
07:02 mj41 joined #parrot
07:06 moritz \o
07:11 bacek_at_work /o
07:15 baest_ is now known as baest
07:24 dalek parrot: b788633 | dukeleto++ | NEWS:
07:24 dalek parrot: Add a NEWS item
07:24 dalek parrot: review: https://github.com/parrot/parrot/commit/b788633950
07:29 dukeleto why do Capture PMC's exist?
07:30 moritz because Match objects are captures
07:30 moritz and that makes nqp-rx much faster than doing it in PIR
07:30 moritz (and historic reasons, I think they used to be used for argument passing, or something)
07:47 dalek parrot/leto/embed_grant: 3d00eba | dukeleto++ | t/src/extend_vtable.t:
07:47 dalek parrot/leto/embed_grant: Properly destroy more PMCs at the end of tests
07:47 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/3d00ebab06
07:47 dukeleto moritz: yes, they seem to be a historical accretion
07:48 dukeleto moritz++ for the explanation
07:49 moritz dukeleto: I think it might work out to move captures to nqp-rx/nqp
07:50 particle joined #parrot
07:51 dod joined #parrot
07:56 dukeleto moritz: not a bad idea
07:57 moritz ... under the assumption that the Capture dynpmc from nqp and nqp-rx don't conflict
07:57 moritz migth be a matter of a small rename
07:58 moritz or maybe nqp wants to go without Capture in the long run, and use a 6model capture (any opinions jnthn__?)
07:59 dalek parrot/leto/embed_grant: 621bb56 | dukeleto++ | t/src/extend_vtable.t:
07:59 dalek parrot/leto/embed_grant: [t] Parrot_PMC_getprop
07:59 dalek parrot/leto/embed_grant: review: https://github.com/parrot/parrot/commit/621bb56873
08:11 jnthn__ moritz: nqp nor nqp-rx has never had a Capture PMC of its own - it uses teh Parrot one in nqp-rx.
08:12 jnthn__ And in nqp we don't use it because it's (memory-wise) cheaper not to do so with 6model.
08:12 jnthn__ Capture is used by PAST also
08:13 moritz jnthn__: the idea was to move it to nqp-rx, but if PAST uses it, that might not be an option
08:13 jnthn__ yeah, I think PAST using it will kill that plan.
08:13 jnthn__ Also nqp-rx has never had dynpmcs
08:14 moritz right, the idea was "zero runtime"
08:15 jnthn__ exactly
08:16 moritz or "parrot is my runtime" ( /me wants PIMR t-shirts :-)
08:24 Tene aloha: tell whiteknight that I've started drafting my second attempt at ruby object model on 6model
08:25 Tene aloha is our msg bot, right?
08:25 aloha Tene: Dunno.
08:25 sorear aloha: msg Tene test
08:25 aloha sorear: OK. I'll deliver the message.
08:25 moritz Tene: yes, s/tell/msg/
08:25 Tene aloha: msg whiteknight that I've started drafting my second attempt at ruby object model on 6model
08:25 aloha Tene: OK. I'll deliver the message.
08:45 jnthn__ Tene: yay :)
08:51 contingencyplan left #parrot
08:55 dafrito left #parrot
09:05 SHODAN joined #parrot
09:06 dduncan joined #parrot
09:06 dduncan left #parrot
09:13 woosley left #parrot
09:27 bacek ~
09:27 bacek ~~
09:27 bacek ~~~
09:28 bacek aloha, help
09:28 aloha bacek: Ask me for help about: msg, convert, status, vars, karma, insult, auth, seen, maths, infobot, clock, translate, loader (say 'help <modulename>').
09:28 bacek aloha, help msg
09:28 aloha bacek: msg <nick> [that] <message>
09:28 bacek Tene, ^^^^
09:44 ShaneC joined #parrot
09:50 rurban_ joined #parrot
09:51 woosley joined #parrot
09:52 rurban left #parrot
09:52 rurban_ is now known as rurban
10:09 ambs joined #parrot
10:11 ShaneC1 joined #parrot
10:13 ShaneC left #parrot
10:25 dalek parrot: ef5ece1 | bacek++ | src/gc/gc_gms.c:
10:25 dalek parrot: Fix very-very subtile bug with handling of GMS "dirty_list".
10:25 dalek parrot:
10:25 dalek parrot: It should fix tickets #2105 and other GC related bugs.
10:26 dalek parrot: review: https://github.com/parrot/parrot/commit/ef5ece1765
10:27 preflex left #parrot
10:30 preflex joined #parrot
10:53 dod left #parrot
11:06 dod joined #parrot
11:09 Psyche^ joined #parrot
11:09 Psyche^ is now known as Patterner
11:24 dalek parrot: 8e129a0 | bacek++ | include/parrot/pobj.h:
11:24 dalek parrot: [cage] Remove unused PObj flag
11:24 dalek parrot: review: https://github.com/parrot/parrot/commit/8e129a09b5
11:37 lucian joined #parrot
11:38 SHODAN left #parrot
11:52 pmichaud good morning, #parrot
11:53 moritz \o pmichaud
11:53 lucian left #parrot
11:54 pmichaud http://gist.github.com/962397 # kiwi, 2011.01, 2011.04-p1 and 2011.04.p2
11:55 pmichaud http://gist.github.com/962400 # plum, 2011.01, 2011.04-p1 and 2011.04.p2
11:56 pmichaud http://gist.github.com/962403 # orange, 2011.01 through 2011.04-p1-ms2
11:59 bluescreen joined #parrot
11:59 jnthn__ o/ pmichaud
12:00 bacek aloha, pmichaud
12:01 pmichaud bacek: benchmark results ^^^
12:01 bacek pmichaud, looking right now
12:03 bacek pmichaud, erm... Looks like ms2 wins only on 8G of memory. Interesting.
12:04 pmichaud ...?
12:04 pmichaud to me, ms2 never "wins"
12:05 lucian joined #parrot
12:05 bacek pmichaud, check kiwi stats. It's considerably faster on ms2 vs gms
12:06 pmichaud slower
12:06 bacek mmm....
12:06 bacek erm...
12:06 bacek gms is slower. Or I misunderstand almost everything
12:06 pmichaud you're misunderstanding, yes.
12:07 pmichaud 2011.01 with ms2 is faster than 2011.04 with gms, yes.
12:07 pmichaud but 2011.04 with ms2 is very much slower than 2011.04 with gms
12:07 bacek It is what I'm talking about :)
12:08 pmichaud the difference isn't between ms2 and gms, but between 2011.01 and 2011.04
12:08 bacek ms2 in 04 is different to ms2 in 01.
12:08 bacek so
12:08 bacek let's only compare ms2(01) vs gms(04+) :)
12:09 moritz it would be useful to find out which non-GC part have made parrot slower
12:10 bacek moritz, it will. One step at the time
12:11 moritz sure
12:11 plobsing moritz: that would require profiling. we either need a suitably fast testcase or a very powerful machine.
12:11 bacek pmichaud, "rx" test.
12:11 moritz or bisecting (assuming it can be attributed to one or just a hand ful of commits)
12:12 bacek Do I understand correctly that it's actually "GC heavy" test?
12:12 moritz is there any test that's not GC heavy?
12:12 pmichaud bacek: yes... it's heavy gc similar to how core.pm is a gc heavy test
12:13 moritz I mean if invocations allocate objects...
12:13 pmichaud the rx test is a bunch of pattern matches...   also, it's the test that has the most regular expressions to parse
12:14 bacek pmichaud, yes. But "rx" is always faster than "core.pm". Which can indicate that we are actually loosing a lot of time somewhere else.
12:14 pmichaud right
12:14 pmichaud I've been saying that I don't think gc is the primary slowdown culprit here
12:15 pmichaud I think that gc improvements have just been masking other slowdowns
12:15 bacek Agreed. But I think we can make GC faster anyway.
12:15 jnthn__ bacek: If you have ms2, do the write barriers have any overhead/do anything?
12:16 moritz they are #define'd out at preprocessor time
12:16 jnthn__ OK.
12:16 pmichaud jnthn__: I'm wondering if the write barriers are the prime reason for the slowdown at 2011.02
12:16 jnthn__ pmichaud: Right, thus my question. :)
12:16 bacek jnthn__, one comparison in most cases.
12:16 moritz at least that's what the original plan was
12:16 bacek #define PARROT_GC_WRITE_BARRIER(i, p) do { if (PObj_GC_need_write_barrier_TEST((p))) Parrot_gc_write_barrier((i), (p)); } while(0)
12:17 pmichaud it would be good to know at which point "ms2" changed from 2011.01 to 2011.04
12:17 bacek single flag test. Shouldn't be too heavy.
12:20 pmichaud slightly off-topic:  would it be better to put the log files in the rakbench repo as compressed or uncomressed files?
12:20 bacek let me quick check 02 with WB defined out
12:20 pmichaud uncompress: 2.6MB, compressed: 100K
12:21 moritz uncompressed
12:21 moritz ie "don't bother, it's not too large"
12:24 bacek msg luben Can you make CLI "nursery collection percentage" float, not int? It will help with benchmarking (or fine tuning)
12:24 aloha OK. I'll deliver the message.
12:25 hudnix joined #parrot
12:25 bacek pmichaud, ms2-02 is considerably slower on my box even without WBs.
12:26 bacek 111s vs 212s
12:26 lucian left #parrot
12:26 pmichaud bacek: so, sounds like something else hit Parrot between 2011.01 and 2011.02
12:26 bacek 111s for current master
12:27 bacek pmichaud, I think so, but would like to have "independent validation".
12:28 bacek It's in include/parrot/gc_api.h. If you can replace #define PARROT_GC_WRITE_BARRIER with empty definition and rerun "core.pm" test on kiwi it will be helpful.
12:30 pmichaud you want me to do the change on 2011.02 ?
12:31 bacek yes
12:31 moritz is 2011.01 parrot 3.0.0 ?
12:31 pmichaud moritz: yes
12:32 pmichaud (that's the   /3.0  in 2011.01/3.0 :-)
12:32 moritz I'll do some nqp-rx benchmarking on 3.0.0 vs. 3.1.0
12:33 pmichaud moritz: good idea.  I was thinking of adding some nqp-rx benchmarks to the suite also
12:33 moritz nqp-rx didn't bump PARROT_REVISION for ages, for which I'm rather grateful right now :-)
12:34 moritz it still has 2.9.1 or something as dependency
12:35 pmichaud bacek: what builds would you like me to compare against 2011.02-nwb   (no write barrier)
12:35 pmichaud ?
12:35 pmichaud 2011.01, yes.
12:35 bacek indeed
12:35 pmichaud any others?
12:35 bacek 2011.02
12:35 bacek (original one)
12:35 pmichaud just the core.pm and rx tests, or all tests?
12:36 bacek I think core.pm and rx will be enough for now.
12:36 pmichaud okay
12:36 bacek I just need indication that WBs aren't responsible for such slowdown.
12:41 whiteknight joined #parrot
12:48 moritz timings for running the 01-regex.t tests in nqp-rx on parrot 3.0.0: 11.789 +- 0.208  on parrot 3.1.0:  12.938 +- 0.041
12:49 bacek moritz, amd64?
12:49 pmichaud http://gist.github.com/962458  # trial 1, 2011.01 vs 2011.02 vs 2011.02-nwb
12:49 moritz bacek: tes
12:50 moritz bacek: erm, yes
12:50 bacek pmichaud, so yes. WBs aren't responsible by it self.
12:51 whiteknight pmichaud: did you try the quick patch I made last night?
12:51 pmichaud moritz: maybe try timing p6regex-test, if you can?
12:51 pmichaud p6regex-test is closer to rx
12:51 bacek whiteknight, didn't help much...
12:52 moritz pmichaud: p6regex-test = 01-regex.t + harness
12:52 whiteknight bacek: did it help at all?
12:52 moritz pmichaud: so that's essentially what I did
12:52 pmichaud moritz: okay
12:52 pmichaud moritz: thanks
12:52 moritz pmichaud: you're welcome
12:52 bacek whiteknight, not really.
12:52 moritz I'll run it a few more times, to get some statistical significance
12:52 whiteknight okay, it was just a shot in the dark
12:52 pmichaud 11:54 <pmichaud> http://gist.github.com/962397 # kiwi, 2011.01, 2011.04-p1 and 2011.04.p2
12:52 pmichaud 11:55 <pmichaud> http://gist.github.com/962400 # plum, 2011.01, 2011.04-p1 and 2011.04.p2
12:53 pmichaud whiteknight: ^^^
12:53 pmichaud 2011.04-p2 is with the additional patch
12:53 whiteknight okay, yeah. No improvement
12:53 whiteknight at least it's no worse :)
12:54 atrodo (low standards)++
12:54 whiteknight msg Tene I'm glad to hear that. Let me know if you have anything online I can see, or any notes you can send. I'm very interested to see anything
12:54 aloha OK. I'll deliver the message.
12:58 whiteknight bacek++ # the subtle GMS fix for darwin
12:59 bacek whiteknight, it wasn't darwin specific. But it was really hard to catch.
12:59 pmichaud http://gist.github.com/962472 # trials 1+2, 2011.01 vs 2011.02 vs 2011.02-nwb
13:00 pmichaud http://gist.github.com/962476 # patch used to empty-define PARROT_GC_WRITE_BARRIER
13:01 pmichaud I'm afk for a bit
13:01 coke_ rohit?
13:02 coke_ seen rohit.nsit08?
13:02 aloha Sorry, I haven't seen rohit.nsit08.
13:02 coke_ seen rohit_nsit08?
13:02 aloha rohit_nsit08 was last seen in #parrot 3 days 20 hours ago joining the channel.
13:02 coke_ rohit is rohit_nsit08
13:05 moritz nqp-rx on parrot 3.0.0: (11.730 +- 0.323)s
13:05 moritz nqp-rx on parrot 3.0.0: (12.929 +- 0.047)s
13:05 moritz now with 15 runs each
13:06 moritz sorry, second line is 3.1.0
13:07 moritz that's a difference of 3.2 standard deviations
13:07 moritz so the chance that this is all stasticial flucations is < 0.1%
13:09 jnthn__ Statistical methods. You knows them.
13:09 moritz at least I pretend to :-)
13:12 dalek parrot: 19962bf | bacek++ | / (2 files):
13:12 dalek parrot: [gc] Avoid second scan of C stack for soling fresh root objects. It should improve GC performance a bit.
13:12 dalek parrot: review: https://github.com/parrot/parrot/commit/19962bf49d
13:13 bacek s/solin/soiling/
13:17 coke_ whiteknight: hasty last minute meeting with rohit scheduled for 9am eastern. APparently too last minute. his exams are... "preponed" and will be hitting earlier than originally scheduled. Sooner to start coding, but this week is now very hectic for him.
13:20 whiteknight it's good to get exams over earlier, and start coding sooner
13:23 coke_ I look forward to having a scheduled time to meet on the calendar. ;)
13:23 bacek ok, guys.
13:23 coke_ second time I've picked a time after he's already gone to sleep.
13:24 bacek It's getting dark and cold here. I'll try to hide under the blanket for a while.
13:24 * moritz just drags tadzik into #phasers
13:24 moritz 'night bacek
13:24 tadzik now?
13:24 moritz tadzik: no, generally for gsoc meetings
13:24 tadzik oh, I see
13:25 bacek msg pmichaud if you can retest 01 vs 04-bleeding-edge on kiwi it will be really helpful.
13:25 aloha OK. I'll deliver the message.
13:25 moritz tadzik: sorry, wasn't very clear :-)
13:25 tadzik no, I just wasn't paying attention :) Your sentence was the first one on the stack :)
13:31 birdwindupbird left #parrot
13:38 whiteknight seen cgaertner
13:38 aloha cgaertner was last seen in #parrot 36 days 23 hours ago saying "btw, who would be willing to mentor the project? the proposal template ask for that information, I I don't remeber anyone actually mentioning that...".
13:40 bubaflub joined #parrot
13:57 rohit_nsit08 joined #parrot
13:57 rohit_nsit08 hello #parrot
13:57 rohit_nsit08 coke_: ping
13:57 whiteknight good morning rohit_nsit08
13:57 whiteknight rohit_nsit08: I'm going to be your backup mentor this summer
13:57 whiteknight I don't know if Coke told you
13:58 rohit_nsit08 whiteknight: hello, good morning, yah read the mail, I'm happy :-) .
13:58 rohit_nsit08 whiteknight: my university exams have now preponed and the new dates are from 12 to 26 of may instead of 16 to 31st so i
13:59 rohit_nsit08 I'll be able to start work earlier but now I'll have to study for exams
13:59 whiteknight that's good. Less time to study, but more time to write code!
13:59 rohit_nsit08 I informed coke_ about this change
13:59 whiteknight yes, we talked this morning
14:00 bacek_at_work left #parrot
14:01 rohit_nsit08 whiteknight: okay, I'll see if i get some time in between the exams, and mail you and coke_ about the doubts if any.
14:04 aloha left #parrot
14:06 birdwindupbird joined #parrot
14:06 aloha joined #parrot
14:10 bacek_at_work joined #parrot
14:13 ambs_ joined #parrot
14:14 ambs left #parrot
14:14 ambs_ is now known as ambs
14:22 darbelo joined #parrot
14:36 contingencyplan joined #parrot
14:37 dalek parrot: 6832e5f | luben++ | / (4 files):
14:37 dalek parrot: use float for --gc-nursery-size
14:37 dalek parrot: review: https://github.com/parrot/parrot/commit/6832e5fa2c
14:46 ttbot Parrot 6832e5fa MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/1188
14:57 atrodo_ joined #parrot
14:58 atrodo left #parrot
14:58 atrodo_ is now known as atrodo
14:58 atrodo is now known as atrodo_
14:58 atrodo_ is now known as atrodo
15:14 dalek parrot: 75fe3b2 | mikehh++ | frontend/parrot/main.c:
15:14 dalek parrot: fix incorrect ASSERT_ARGS
15:14 dalek parrot: review: https://github.com/parrot/parrot/commit/75fe3b2fca
15:21 hercynium joined #parrot
15:22 ttbot Parrot 75fe3b2f MSWin32-x86-multi-thread make error http://tt.taptinder.org/cmdinfo/1208
15:26 mikehh strtof does not seem to be in the includes for windows build
15:26 whiteknight windows fail
15:26 whiteknight I'll fire up the build on my win64 box soon to see what happens
15:27 mikehh line #679 of frontend/parrot/main.c
15:29 whiteknight oh, luben would have just changed that in his recent commit
15:29 whiteknight okay
15:29 mikehh builds fine for me on Ubuntu 11.04 amd64
15:30 whiteknight mikehh: Can you change "strtof" to "(float)strtod"? I think that should fix the windows build
15:30 NotFound strtof is not ansi C, use strtod
15:30 whiteknight I can't test it here for a while
15:30 mikehh whiteknight: can do
15:30 whiteknight mikehh++
15:31 whiteknight at the very least it shouldn't break anything on linux, and might just make the bot shut up about windows
15:31 woosley left #parrot
15:33 plobsing (float)strtod defeats the purpose. the intent was to expose fractional values for GC tuning parameters (a feature requested by bacek). we were previously using strtod
15:34 NotFound ?
15:34 NotFound What's the problem with fractional values and strtod?
15:34 whiteknight strtod would still be giving us doubles
15:34 plobsing oops. wow, disregard. need to focus on one thing at a time
15:34 whiteknight :)
15:34 plobsing back to $work
15:35 NotFound ETOOMUCHSTRTOx
15:35 whiteknight ETOOMUCHLIBC
15:36 atrodo libc--
15:36 atrodo c--
15:36 whiteknight if this were 1970, libc would be the undisputed king of libraries. Now, it isn't allowed to be nominated
15:36 dalek parrot: 5881c3c | mikehh++ | frontend/parrot/main.c:
15:36 dalek parrot: attempt to fix windows build
15:36 dalek parrot: review: https://github.com/parrot/parrot/commit/5881c3c851
15:36 woosley joined #parrot
15:36 whiteknight actually, that's a lie. In 1970 there were probably better libraries out there
15:37 atrodo I'm waiting for someone to chime in and say lisp
15:38 NotFound Probably, but C ran in machines where compilers with better libraries didn't fit.
15:39 whiteknight (nobody-should (mention (lisp)))
15:39 whiteknight I hates me some S-expressions
15:40 whiteknight Apparently Super Mario 64 was written in Lisp
15:40 atrodo Link?
15:41 NotFound atrodo: no, Link is in other game.
15:41 atrodo NotFound++
15:43 whiteknight http://www.franz.com/success/customer_​apps/animation_graphics/nichimen.lhtml
15:43 whiteknight maybe it wasn't written in lisp itself. either way, something something lisp
15:43 atrodo whiteknight> That's what i found
15:43 atrodo I normally find marketing materials suspect
15:48 whiteknight yeah
15:49 benabik ~~
15:49 davidfetter joined #parrot
15:50 atrodo Especially since that's the only real reference i can find and the company that was supposedly at the core of the whole thing, Nichimen Graphics, has very little info about them
15:50 theory joined #parrot
15:51 whiteknight okay, so the only cool thing I can point to that I think involved lisp might be an exaggeration or an outright lie
15:51 whiteknight awesomeness
15:54 whiteknight I read a blog a few days back where the guy suggested lisp's poor showing was because it was too flexible, and everybody wrote their own extensions and stuff, and nobody built good reusable libraries
15:54 whiteknight I don't know enough about the language community, but it sounded plausible
15:54 moritz some people like emacs
15:55 moritz a language really needs a killer app
15:55 atrodo whiteknight> http://coding.derkeiler.com/Archive/Lis​p/comp.lang.lisp/2005-11/msg01698.html # Thread on comp.lang.lisp.  An exaggeration at worse
15:55 moritz without rails, ruby would be largely unknown today
15:55 moritz or at least largly unused :-)
15:55 atrodo Without perl, Perl would be largely unknown today as well :)
16:05 woosley left #parrot
16:05 dalek winxed: r990 | NotFound++ | trunk/winxedst1.winxed:
16:05 dalek winxed: minimal refactor of MemberExpr emiters
16:05 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=990
16:23 mj41 left #parrot
16:37 coke_ msg rohit_nsit08 looks like you showed up an hour later than I expected. Just to confirm, NY/Eastern time is currently 4 off UTC by my clock.
16:37 aloha OK. I'll deliver the message.
16:38 whiteknight timezones are the worst
16:39 * coke_ blames DST more.
16:39 * coke_ would be happy if the whole world just used UTC with no DST.
16:39 whiteknight I would far prefer that in a number of ways
16:40 benabik coke_: US/Eastern is currently EDT/UTC-4.
16:40 whiteknight the only time I've ever seen a use for timezones is on new years eve, so people don't start kissing before midnight
16:40 coke_ benabik: ... "that's what I said"
16:40 coke_ (but thanks for confirming it's not just me.)
16:41 benabik coke_: You were looking for confirmation...  Although not from me, I guess.  :-)
16:41 whiteknight no other day of the year does it matter that 8 AM for me "looks" like 8 AM in singapore
16:42 Tene whiteknight: my problems with ruby 6model stuff earlier was that I didn't have a coherent model for what I was trying to do, what was handled by which parts, etc.
16:43 Tene I was trying to use get_how for two different things in different places, but not consistently.
16:45 Tene whiteknight: so, approximately, I need to implement http://ruby-doc.org/core/classes/Module.html with 6model, along with the smaller Class and Object, glue them together like http://www.hokstad.com/static/rom/rom.png
16:45 Tene https://github.com/ruby/ruby/raw/tr​unk/doc/images/boottime-classes.png is the version in the ruby source tree
16:45 Tene that's the core metacircular loop in the ruby class hierarchy
16:46 Tene So, that should be fairly simple and straightforward.
16:47 Tene My other problem last time was that I was mixing levels and trying to have a separate implementation of things living outside the ruby class hierarchy, but I wasn't doing that explicitly, so I was kind of halfway between
16:48 Tene when I really needed to just buy in completely.
16:54 mj41 joined #parrot
17:00 whiteknight Tene: okay, that makes sense
17:01 whiteknight I need to start reading all those links!
17:03 ShaneC1 left #parrot
17:04 Tene Which links?
17:08 darbelo left #parrot
17:09 benabik left #parrot
17:11 whiteknight Tene: those links you just posted
17:12 whiteknight well, only one of them isn't a picture
17:12 whiteknight so that's the one I will read
17:13 rohit_nsit08 left #parrot
17:22 darbelo joined #parrot
17:22 Tene Eh, it's just the API docs for the Module class.  The summary is "Implement Ruby's object model directly, using Ruby's normal API"
17:23 Tene If you want to learn about Ruby's object model, my recommendation is http://www.slideshare.net/burkelibbey/rubys-​object-model-metaprogramming-and-other-magic
17:23 ShaneC joined #parrot
17:24 whiteknight okay, then I will read that too
17:24 whiteknight I read a lot
17:25 Tene I don't know where your interests fall between 6model and ruby's object model
17:26 jnthn__ "Implement Ruby's object model directly, using Ruby's normal API" - sounds like the Right Thing. :)
17:26 whiteknight Tene: I need to learn everything about everything
17:27 whiteknight Tene: and I have to start somewhere. so I am starting here
17:27 Tene :)
17:30 whiteknight I really need to learn ruby eventually
17:30 whiteknight I've put it off for long enough
17:30 pmichaud preliminary results of 2011.01 versus rakudo-bleed: http://gist.github.com/962932
17:32 pmichaud aloha msg bacek_at_work preliminary results of 2011.01 versus rakudo-bleed: http://gist.github.com/962932
17:32 aloha pmichaud: OK. I'll deliver the message.
17:32 pmichaud afk, lunch
17:33 ShaneC left #parrot
17:41 whiteknight FFFFFUUUUUUU
17:42 whiteknight There's really no excuse for our performance still being in that same ballpark. We should be much better than 3.0
17:42 whiteknight not just a hair better on some benchmarks
17:43 cotto_work ~~
17:44 whiteknight good morning, cotto_work
17:46 cotto_work hi whiteknight
17:49 dalek winxed: r991 | NotFound++ | trunk/winxedst (2 files):
17:49 dalek winxed: improve prefix ++ and -- operators in stage 0
17:49 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=991
17:50 rurban_ joined #parrot
17:52 rurban left #parrot
17:52 rurban_ is now known as rurban
17:58 benabik joined #parrot
18:00 dalek winxed: r992 | NotFound++ | trunk/winxedst0.cpp:
18:00 dalek winxed: fix generated indentation
18:00 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=992
18:10 ambs left #parrot
18:10 dalek winxed: r993 | NotFound++ | trunk/winxedst1.winxed:
18:10 dalek winxed: profit from ++ improvements
18:10 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=993
18:13 birdwindupbird left #parrot
18:14 whiteknight left #parrot
18:15 _dolmen_ joined #parrot
18:18 coke_ (benchmark) is it possible that the benchmark is dominated by rakudo, not parrot?
18:21 plobsing coke_: git log --after 2011.01 shows 7 commits.
18:21 coke_ plobsing: so?
18:21 plobsing none of them look particularly suspect
18:22 coke_ I think you misunderstand my point. I'm suggesting that perhaps even if parrot is improving slightly, if rakudo is doing a lot of work, it doesn't matter.
18:23 coke_ (not that I think this is necessarily the case, but that's what I'm floating here.)
18:23 sorear time = rakudo * parrot
18:23 sorear everything rakudo does relies on slow parrot ops
18:23 plobsing I'd also point out that Ωη exhibits a similar regression
18:24 plobsing likely due to similar means of operation
18:24 plobsing so it isn't just rakudo
18:24 whiteknight joined #parrot
18:27 pmichaud coke_: what we can say pretty definitively is that parrot performance with ms2 has gotten substantially worse
18:28 pmichaud so, *something* has been changing to cause the significant slowdown
18:28 pmichaud (I'm currently doing some bisects to see if I can narrow it down a bit)
18:31 pmichaud ("git log --after=2011.01" doesn't show all of the commits since the 2011.01 release for me.)
18:32 plobsing hmmm... not sure what's up with that
18:32 pmichaud maybe git is treating it like some sort of weird date
18:32 pmichaud git log --after=2011.01.01  shows me all of the commits since jan 1
18:33 _dolmen_ left #parrot
18:33 _dolmen_ joined #parrot
18:34 dolmen__ joined #parrot
18:34 plobsing pmichaud: would it be possible to run some identical version of parrot accross 3.0 and 3.1 to show the regression is parrot-side?
18:34 pmichaud you mean "identical version of rakudo"?
18:35 plobsing s/identical... yeah that
18:35 pmichaud not really.  3.0 didn't have the write barrier code, 3.1 required it
18:35 pmichaud so rakudo *had* to change to cope with that change in parrot.
18:35 plobsing didn't some intermediary versions of parrot have a nop wb macro?
18:36 benabik I think you want "git log 2011.01.01.."
18:36 pmichaud not until after 3.0 was released
18:36 plobsing benabik: no, I was trying to refer to the release tag
18:36 pmichaud notably, using the ..'s works for me
18:36 pmichaud git log 2011.01..2011.02  shows me the commits between the two releases
18:37 benabik plobsing: --after is for dates, not tags
18:37 dolmen__ left #parrot
18:37 benabik plobsing: A..B is a revision range from committish A to committish B.  Omitting one means HEAD.
18:38 plobsing I'm used to git tools dwimming without me even thinking about it anymore. I didn't even bother looking up the --after flag, I just assumed it was there.
18:40 plobsing pmichaud: we could provide a small patch to 3.0 that added a nop-wb macro. would that allow a direct head-to-head?
18:40 pmichaud plobsing: I think I've already isolated it to before the write barrier code
18:40 pmichaud just need about 30 more seconds to confirm :)
18:41 pmichaud okay
18:42 plobsing benabik: so why does "--after 2011.01" mean after May 1st then? 2011.01 is clearly year.month. year.day makes no sense.
18:42 pmichaud rakudo 2011.01-25-g03380cd  running on parrot RELEASE_3_0_0-457-gfe658a7   takes 141 seconds for core.pm
18:42 benabik plobsing: The approxidate code is... wierd.
18:43 pmichaud this is the version of rakudo *before* the write barrier patches were applied
18:43 plobsing humans and time are a recipe for fail, true. but this one is one of the more straightforward cases.
18:43 pmichaud I may be able to run this version of rakudo on stock 3.0.0
18:45 benabik plobsing: It will parse num.num.num as Y-M-D unless M > 12.  It appears to give preference to day over month in the two digit range.  Given reason is so that "01 Apr 05" is "April 1, 2005"  (git.git:date.c:523)
18:47 plobsing benabik: but if you only have 2 pieces of information, and one is a year, logically, the other is a month. otherwise the date is nonsensical and parsing should throw an error.
18:47 benabik plobsing: Git's date parsing generally prefers "good enough" to "actually correct".  It looks like the code that handles yyyy.mm.dd only triggers if given three numbers.
18:48 pmichaud okay, confirmed that the issue is likely a Parrot one
18:49 benabik plobsing: It only parses forwards, so it uses the first two digit number as a day so it can get a month later.  I think the best idea would be to extend the yyyy.mm.dd function to use "no day" to mean 1.
18:49 pmichaud rakudo 2011.01-25-g03380cd running on parrot RELEASE_3_0_0 takes 70 seconds for core.pm
18:50 * benabik writes a note to git list.
18:50 pmichaud so somewhere between RELEASE_3_0_0 and RELEASE_3_0_0-457-gfe658a7 we experienced a 200% slowdown in compilation of core.pm
18:50 benabik plobsing: I'm only looking at what it does do, not what it should do.  :-D
18:50 pmichaud I guess now it's just a matter of bisecting a bit :-)
18:51 * pmichaud starts a bisect
18:52 benabik git-bisect++
18:53 lucian joined #parrot
18:53 plobsing benabik: I get that. I'm just saying what it does makes no sense. I expect my heuristics to be smarter than that in this day and age.
18:54 plobsing <insert obligatory mjd heuristic quote>
18:54 benabik plobsing: Fair enough.  I'm going to point this out on git@ and hope someone gets the tuits to fix it before I'm done with finals.  :-D
18:55 tadzik you're lucky to have your finals soon :)
18:55 benabik tadzik: When's yours?
18:55 tadzik benabik: end on 30th of June
18:56 benabik tadzik: Ew.  I thought the 20th was a bit obnoxious.
18:56 tadzik that quite sucks when you see the gsoc timeline
18:58 [hercynium] joined #parrot
18:59 dalek parrot: a5aa340 | cotto++ | src/gc/gc_gms.c:
18:59 dalek parrot: typo fix
18:59 dalek parrot: review: https://github.com/parrot/parrot/commit/a5aa34070f
19:00 benabik tadzik: Agreed.
19:01 plobsing benabik: if git is going to take year, day as a valid date combo, the day had better be interpreted as julian date. I'm sure someone will find that useful ;)
19:01 pmichaud RELEASE_3_0_0-228-g2f0daea  good
19:02 benabik plobsing: I suspect it's more something they never thought about in the YYYY.MM.DD parsing instead of a deliberate choice.
19:03 hercynium left #parrot
19:03 [hercynium] is now known as hercynium
19:05 hercynium left #parrot
19:06 hercynium joined #parrot
19:06 pmichaud RELEASE_3_0_0-342-gc2ffe55 good
19:10 pmichaud RELEASE_3_0_0-399-g1429108 good
19:14 pmichaud RELEASE_3_0_0-428-gbc265ee good
19:17 plobsing with each narrowing, it is looking more and more like gc_dynamic_threshold
19:20 pmichaud RELEASE_3_0_0-443-gbe26ad5 bad
19:23 pmichaud RELEASE_3_0_0-369-gfe73887 good
19:26 jevin left #parrot
19:29 whiteknight parrot-dev has been getting a hell of a lot of chinese-language spam lately
19:29 pmichaud RELEASE_3_0_0-373-g0d519eb bad
19:29 whiteknight plobsing: I keep looking at that merge
19:30 whiteknight I can't put my finger on it
19:30 pmichaud the merge commit is the first one that reported bad, yes.
19:30 pmichaud two steps to go
19:30 whiteknight ok, that's kind of a relief. I was hoping it wouldn't be the exception refactors
19:30 whiteknight it would be a shame to rip those out
19:31 plobsing whiteknight: that last two bisects point to c0ddc7563fb7ed78f7235fec72f8e635894018ae as something more reasonable
19:31 plobsing we could quite easily change that
19:33 whiteknight maybe a command-line flag, since it is a legitimate trade-off between memory consumption and performance
19:33 dafrito joined #parrot
19:33 whiteknight of course, I think we still have --gc=inf, so if you really want to skew one for the other we can already do it
19:33 whiteknight you'll scream along until you hit swap
19:34 plobsing we have a command line flag to control it IIUC. but that kind of insight requires a lot of attention. the defaults should be decently fast to start with.
19:35 plobsing I think the 4M low threshold is mostly for lowmem systems. perhaps configure should detect low memory systems and/or have a --lowmem flag.
19:35 pmichaud RELEASE_3_0_0-371-g00d27fb bad
19:35 whiteknight plobsing: yeah, that's fine too. How do we detect low mem? Or, more specifically, what is "low"?
19:36 whiteknight 4M really is too low, unless your screenname is kid51
19:36 whiteknight of course, if we revert that commit outright, I'm sure he'll see build failures
19:36 whiteknight so we need something configurable
19:37 plobsing We have routines to detect system memory, on which we used to base our GC thresholds.
19:37 plobsing We could go back to that, but with sanity checks.
19:37 whiteknight right, my question is about what heuristic is used to determine "low"ness or not
19:38 whiteknight if sysmem is below a certain threshold we use a fixed 4M threshold, and above that we use a percentage?
19:38 plobsing if (`whoami` == "jimk") { lowmem() }
19:38 plobsing whiteknight: that's the jist of it
19:39 whiteknight I actually like that heuristic. Compute the sysmem and the precentage. If it's below 4m, set it to 4m
19:39 plobsing because 4M is likely the lowest sane value, or at the low end of the scale for sane values
19:39 benabik The question becomes "what should we consider low", and set the percentage so 4M = low * percent
19:39 whiteknight right, that's the minimum that would allow it to even function
19:40 pmichaud RELEASE_3_0_0-370-gc0ddc75 bad
19:40 whiteknight the old system was to use one eighth of system memory. I like that
19:40 plobsing that is kinda big for a lower bound, but is more dynamic
19:41 pmichaud one eighth obviously worked reasonably well for 2011.01 :-)
19:41 benabik That means the minimum is only likely to trigger for systems with 32MB of detected memory.
19:41 benabik s/likely/going/
19:41 plobsing pmichaud: sure, on an otherwise unloaded system.
19:42 pmichaud in my case, there's a huge difference between 1GB and 4MB :-)
19:42 AzureStone left #parrot
19:42 pmichaud (assuming Parrot_sysmem_amount is returning on my sys)
19:42 plobsing once you get other processes on there introducing cache pressure, 1/8 * ($x Gb) memory is huge
19:42 pmichaud note that for rakudo spectests, I'm running seven copies of rakudo at once
19:44 pmichaud if we assume a "lowmem" machine to be 256M, then 32M was obviously still too big
19:45 pmichaud (since it had to later to be reduced to 4MB)
19:45 pmichaud I'm also wondering if the number isn't strictly linear
19:45 jnthn__ Logarithm? :)
19:45 plobsing alternatively, it might just be that 4M is a common size for L2 cache
19:45 whiteknight Maybe Parrot needs to set some lower limits for expected amount of RAM
19:45 plobsing which would make it a reasonable-ish guess
19:45 whiteknight I mean, there is a lower limit where things stop working, we should get out in front and codify that
19:46 whiteknight below 128M, maybe we throw up our hands and decide it's not worthwhile
19:46 cotto_work ulimit would be nice for that.
19:46 whiteknight at least not for the "desktop edition" of Parrot
19:46 pmichaud I'm going to patch rakudo bleed with the /8 threshold and see what I get
19:46 whiteknight I would rather our policy be that 128M was our lowest supported level, then to randomly fail below that and be expected to debug every instance
19:47 whiteknight or 64M, or whatever we want it to be
19:47 AzureStone joined #parrot
19:47 pmichaud note that kid51 was having trouble on a 256MB machine (which iirc led to this patch)
19:47 whiteknight not stating a lower limit means every failure is a problem for us. At some threshold we need to say we don't expect success
19:47 pmichaud so 128MB seems unachievable, at least for now
19:47 benabik pmichaud: By my math that means we should set the threshold to 1/64 of sysmem.
19:48 plobsing the sysmem code at that time was inconsistent across OSes
19:48 plobsing perhaps the darwin did not show the full 256M
19:49 pmichaud oh, wait
19:49 pmichaud min_threshold only applies to ms2?
19:49 plobsing gms may have something similar
19:50 pmichaud because fixing this for ms2 won't improve gms :-(
19:50 plobsing I must admit I am a little surprised that this wound up being a GC-based regression. My money was riding on something else (eg: exceptions).
19:51 benabik left #parrot
19:51 cotto_work I'd have lost that bet too.
19:51 pmichaud sadly, it means that gms still isn't providing a significant performance improvement for rakudo
19:52 pmichaud and that we can't really look at the 2011.01->2011.02 regression as the reason why
19:52 plobsing pmichaud: you could try uping GC_DEFAULT_NURSERY_SIZE
19:53 plobsing that's the gms equiv
19:53 plobsing and the threshold is currently 2% sysmem
19:53 whiteknight that seems low
19:54 plobsing whiteknight: that would be the size of the gen0 nursery. it's a moderately aggressive bet that performs well when the generational heuristic holds.
20:04 bluescreen left #parrot
20:04 plobsing pmichaud: is the 3.1 performance with c0ddc75 reverted equivalent or better than 3.0?
20:04 plobsing or is that large regression hiding other regressions?
20:04 pmichaud plobsing: I'm currently trying 3.3 with a revert of c0ddc75
20:04 pmichaud that way we can compare it with gms also
20:05 pmichaud I can try a 3.1 with c0ddc75 a bit later
20:05 pmichaud (c0ddc75 revert)
20:10 pmichaud http://gist.github.com/963276   # the first set of numbers with c0ddc75 revert
20:10 whiteknight okay, so that brings ms2 back into the ballpark
20:11 pmichaud the -p3 build is the one that has switched min_threshold back to sysmem()/8
20:11 whiteknight I'm still frustrated that gms is underperforming. We think it should be doing much better
20:11 plobsing I'd call that no significant difference except c0ddc75.
20:11 pmichaud sadly, it means ms2 still outperforms gms on my system
20:11 whiteknight pmichaud: it may just be your machine, since you have so much mem
20:11 pmichaud I can try it on my lower-memory notebook
20:12 pmichaud it only has 3GB mem
20:12 pmichaud (fsvo "only"  :)
20:12 plobsing that means the ms2 regression was purely a function of GC tuning and suggests similar improvements can be had on gms
20:12 whiteknight I'm just trying to piece the data together. When GMS landed several people saw significant improvements in several benchmarks, including rakudo build and spectest
20:12 plobsing pmichaud: don't hate on the 3Gb lappy. that's my main machine.
20:12 pmichaud I love my laptop :)
20:13 pmichaud it's still my favorite machine
20:13 whiteknight I was seeing at least 15% across the board, much better on certain bits
20:13 pmichaud whiteknight: yes, but was that relative to ms2 with the c0ddc75 commit?
20:13 whiteknight so the fact that ms2 is outperforming gms on your machine is striking to me
20:13 whiteknight I really don't know the relative timing
20:13 pmichaud right
20:13 plobsing it is all in the tuning
20:13 pmichaud I *do* see performance improvement from gms versus 2011.01 on my notebook, yes.
20:14 pmichaud but I don't think that's entirely a function of memory.  There's something else going on there, because I didn't see a similar improvement on my old desktop when running it with only 3GB
20:14 pmichaud there's something else about my laptop that causes gms to perform especially well
20:14 pmichaud (I don't know what it is)
20:14 plobsing cache?
20:15 pmichaud L2 cache:              6144K
20:15 pmichaud maybe
20:15 whiteknight my laptop has 4GB, I think, and it saw good improvements
20:16 pmichaud my old desktop's cache is 1024K
20:17 pmichaud (most of the numbers are available in https://github.com/pmichaud/ra​kbench/tree/master/results/log if anyone wants to look
20:18 ambs joined #parrot
20:24 ambs left #parrot
20:24 ambs joined #parrot
20:31 fperrad left #parrot
20:39 soh_cah_toa joined #parrot
20:41 whiteknight left #parrot
20:47 ambs_ joined #parrot
20:47 ambs left #parrot
20:47 ambs_ is now known as ambs
20:48 cotto_work dukeleto: ping
21:02 perlite_ joined #parrot
21:05 benabik joined #parrot
21:05 perlite left #parrot
21:05 perlite_ is now known as perlite
21:06 benabik left #parrot
21:24 bubaflub left #parrot
21:27 dalek winxed: r994 | NotFound++ | trunk/winxedst1.winxed:
21:27 dalek winxed: allow null in conditional operator and a few codingstd fixes
21:27 dalek winxed: review: http://code.google.com/p/w​inxed/source/detail?r=994
21:33 ambs left #parrot
21:36 bubaflub joined #parrot
21:39 theory left #parrot
21:41 mj41 left #parrot
21:53 jevin joined #parrot
22:02 benabik joined #parrot
22:02 benabik left #parrot
22:11 bubaflub left #parrot
22:29 lucian left #parrot
22:33 _dolmen_ left #parrot
22:40 perlite left #parrot
22:40 preflex left #parrot
22:40 spinclad left #parrot
22:40 dukeleto left #parrot
22:40 mikehh left #parrot
22:40 simcop2387 left #parrot
22:40 tcurtis left #parrot
22:40 cotto_work left #parrot
22:40 PerlJam left #parrot
22:40 kthakore left #parrot
22:40 marc left #parrot
22:40 jnthn__ left #parrot
22:40 TimToady left #parrot
22:40 pmichaud left #parrot
22:40 tadzik left #parrot
22:43 perlite joined #parrot
22:43 preflex joined #parrot
22:43 spinclad joined #parrot
22:43 dukeleto joined #parrot
22:43 mikehh joined #parrot
22:43 simcop2387 joined #parrot
22:43 tcurtis joined #parrot
22:43 cotto_work joined #parrot
22:43 PerlJam joined #parrot
22:43 kthakore joined #parrot
22:43 marc joined #parrot
22:43 jnthn__ joined #parrot
22:43 TimToady joined #parrot
22:43 pmichaud joined #parrot
22:43 tadzik joined #parrot
22:51 bacek ~~
22:55 cotto_work ~~
22:55 bacek msg pmichaud "sin.t". gms is actually faster than ms2. Parrot_pmc_new is 9.9G vs 10.4G instructions on 04-master vs 01. BUT! 04 allocates 1M more GCable. 15.1M vs 14.2M. And do more calls: pcc_invoke 744K vs 684K.
22:55 aloha OK. I'll deliver the message.
22:56 * bacek run to $dayjob
22:56 cotto_work aloha: clock?
22:56 aloha cotto_work: LAX: Mon, 15:56 PDT / CHI: Mon, 17:56 CDT / NYC: Mon, 18:56 EDT / UTC: Mon, 22:56 UTC / LON: Mon, 23:56 BST / BER: Tue, 00:56 CEST / TOK: Tue, 07:56 JST / SYD: Tue, 08:56 EST
22:56 plobsing bacek: can you confirm the /topic entry about the breakage you added has been fixed?
22:58 bacek plobsing, ah. Yes. It's fixed. Not in very optimal way but fixed
22:59 plobsing yeah, I was thinking iterating the hash twice sucked, but it did the job
22:59 cotto_work bacek: do you have a test case that tickles the bug?
22:59 plobsing just confirming there wasn't some deeper issue
23:00 bacek cotto_work, I'm not sure it's "a bug". Just observation of change in behavior.
23:00 cotto_work double free sounds like a bug
23:00 bacek cotto_work, or are you asking about /topic?
23:01 cotto_work yes
23:01 bacek it's kind of hard to write testcase for it. I'll try to implement it tonight.
23:01 cotto_work ok
23:01 Topic for #parrot is now Parrot 3.3.0 released | http://parrot.org | Log: http://irclog.perlgeek.de/parrot/today
23:04 hercynium left #parrot
23:04 cotto_work I see why that'd be a tricky test case.  You can always initialize and clone it directly.
23:10 whiteknight joined #parrot
23:10 bubaflub joined #parrot
23:21 bacek_at_work ~~
23:22 whiteknight hello bacek_at_work
23:23 bacek_at_work aloha, whiteknight
23:23 whiteknight bacek_at_work: no more late debugging sessions! you need rest
23:23 bacek_at_work :)
23:25 theory joined #parrot
23:28 whiteknight I need to start valgrinding master
23:34 plobsing it would be nice if there were a benchmark framework that could be run in the background in spare cycles a la $x@home.
23:34 whiteknight yes, that would be quite nice
23:36 cotto_work ipfy@home
23:37 cotto_work though benchmarking shouldn't really run in the background unless we're relying on something like valgrind
23:37 cotto_work which has its own issues
23:39 whiteknight benchmarkin is nice, but we already know there is a performance problem. What we need is targetted searching to figure out when things went bad, then we need to figure out how to un-bad it
23:39 whiteknight and unbad it on all our target platforms, not fixing one to regress another
23:41 plobsing whiteknight: if you maintained a database of performance benchmarks you cared about, you wouldn't have to bisect (or you could bisect from drastically reduced bounds)
23:41 whiteknight true
23:41 cotto_work actually, benchmarking in the background wouldn't be too bad on platforms that tell you how much time was spent per-process.
23:41 plobsing you could trigger alerts about degrading performance AS THEY HAPPEN, in stead of 4 months later when someone notices
23:42 cotto_work that'd be amazing
23:42 cotto_work volunteers?
23:42 plobsing I guess I've talked this up too much not to
23:43 plobsing I'll look into it
23:43 plobsing along with the myriad of other things I've committed to doing in my copious spare time
23:46 cotto_work All we need is a barely-working prototype client and server.
23:46 cotto_work fsvo "all"
23:46 plobsing don't we already have enough barely-working floating around here already?
23:47 cotto_work you'd think so
23:51 plobsing are there any virtualization solutions that emulate a real computers timings
23:52 cotto_work That's not a bad idea.
23:52 plobsing basically the system clock slows down and accelerates to hide the host

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

Parrot | source cross referenced