Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today | Please fix master branch after github.com/parrot/parrot/commit/2953196d6c
Set by moderator on 7 May 2011.
bacek_at_work ~~ 00:00
whiteknight msg pmichaud I suspect bacek's patch doesn't extend to x86_64. Can you try gist.github.com/961822 to see if it helps on your machine?
bacek_at_work is really sad looking at benchmarks...
aloha OK. I'll deliver the message.
whiteknight bacek_at_work: don't worry, we'll fix them
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
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:03
whiteknight yeah, that would be better 00:04
in either case, this should help pmichaud
bacek_at_work I hope so.
whiteknight I can't think of any other big reason for big performance regressions since 3.0 00:05
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)?
whiteknight plobsing: because shut-up. That's why. 00:09
I don't know. I didn't think about it :)
benabik plobsing: Preprocessor conditionals are run once at compile time. sizeof() is run every time the function is called.
plobsing benabik: not true. it is a compiler builtin
whiteknight benabik: the optimizer should deal with that no problem
plobsing: yeah, there are definitely better ways to do it. I don't have my programming cap on right now 00:10
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
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.
whiteknight: And, IMHO, constant collapsing should be handled before you hit my GSoC work. 00:14
whiteknight: Although a set of common passes for tree-optimization _would_ be nice.
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
good practice for dealing with PAST/PST
POST
benabik whiteknight: Hm, yes... Making sure that works on nqp_pct might be nice.
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.
whiteknight benabik: I think there were a few basic optimizations in there
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
even if the number of optimizations a compiler uses might be small by default
NotFound Constant collapsing is not rockey science, even winxed does it ;)
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:18
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:19
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
the functionality to run any optimizations should be built-in, whether the compiler uses any or not 00:21
I just want to make sure that during the GSoC work, the capability doesn't get neglected
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:22
I mean, the compiler. 00:23
whiteknight integer and float constants are no-brainers to optimize. Strings too, since they're immutable
pmcs are harder. You really can't constant-fold them in any portable, meaningful way
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
whiteknight especially if HLLs can arbitrarily map in new types for the built-ins
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
TimToady mostly they need the capability of migrating atributes up and down the tree, like "is pure enough to constant fold" 00:25
00:25 benabik left
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
TimToady: being able to determine attribute purity is well outside the scope of Parrot 00:28
but, PAST having a flag that says "this is pure", and letting the compiler set and read that flag is something we could do
NotFound What is "pure"? 00:35
bacek_at_work whiteknight, (how I found) it was only possible place which can explain such a big difference between runs. 00:37
00:47 lucian left 00:55 jrtayloriv left 01:04 whiteknight left
pmichaud 00:00 <whiteknight> msg pmichaud I suspect bacek's patch doesn't extend to x86_64. 01:22
well.... since it improves things on x86_64, it must "extend to it", yes? Or am I misunderstanding the statement? 01:23
I mean, compare the rakudo-2011.04 and rakudo-2011.04-p1 times
bacek_at_work pmichaud, can you try whiteknight++ patch on github? 01:25
It should improve amd64 performance
pmichaud instead of or in addition to the patch received via email?
bacek_at_work addition
pmichaud okay 01:26
should I just compare the two versions, or should I also include 2011.04 and 2011.01 ?
(the two patched versions)
01:26 cotto left
bacek_at_work just compare with -p1 01:28
it will give good indication of performance
pmichaud will have results in about 60 mins 01:29
(have a few other errands to do here)
my new desktop is nice and fast :)
bacek_at_work :) 01:30
pmichaud pmichaud@kiwi:/zip/perl/rakudo-2011.04-p2/parrot$ patch -p1 <is_ptr_2.patch
patching file src/gc/gc_gms.c
Hunk #1 FAILED at 1520.
1 out of 1 hunk FAILED -- saving rejects to file src/gc/gc_gms.c.rej
pmichaud@kiwi:/zip/perl/rakudo-2011.04-p2/parrot$
;(
patch wants 01:32
+ const size_t invalid_ptr_mask = sizeof(void*) == 8 ? 7 : 3;
gc_gms.c has
size_t i;
I'd prefer not to guess at this point, so I'll wait for an updated patch. 01:33
bacek_at_work Are you applying it to 3.0+patch or master? 01:34
pmichaud 3.3+patch
3.3+is_ptr.patch 01:35
bacek_at_work oops. 3.3
pmichaud definitely not master
bacek_at_work ok. I'll try to create new patch.
pmichaud I'm only working from releases at this point.
I can benchmark master, too, if need be.
this new benchmark harness+suite is making it much easier to run tests like this :) 01:36
(I can patch either 3.3+first patch or an unpatched 3.3.... whichever is easiest for you :) 01:37
afk, errands
01:46 woosley joined 01:50 rurban_ joined 01:52 rurban left, rurban_ is now known as rurban
bacek_at_work msg pmichaud gist.github.com/961919 on top of is_ptr.patch 02:02
aloha OK. I'll deliver the message.
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:03
02:15 benabik joined 02:24 woosley left
pmichaud running benchmarks for -p1 and -p2 now 02:41
while waiting for that... here's the same set of benchmark runs as earlier but run from my notebook: gist.github.com/961962 02:48
02:49 woosley joined
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:53
oh, should only be about eight hours :) 02:56
gist.github.com/961995 # no significant difference between -p1 and -p2 for core.pm 03:15
(still waiting for other tests to complete)
n@cpe-74-65-60-43.rochester.res.rr.com] has joined #parrot 03:29
oops
gist.github.com/962008 # results of -p1 versus -p2 for first sets of tests 03:30
the system is still running the .p6 and spectests.... but so far there's no significant difference between -p1 and -p2
afk for a while 03:31
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 03:51 bubaflub left
pmichaud bacek_at_work: 2011.01 on kiwi should be the same numbers I posted earlier 04:29
I can re-test if you like
ore.pm: rakudo-2011.01 (ms2) 64.2 65.9 65.9 64.3 64.2 100.0% 04:30
04:44 soh_cah_toa left
pmichaud here's what I have so far: 04:44
gist.github.com/961736 # kiwi, releases 2011.01 through 2011.04-p1-ms2 04:45
gist.github.com/962060 # kiwi, 2011.04-p1 vs 2011.04-p2
gist.github.com/961962 # plum, releases 2011.01 through 2011.04-p1-ms2
I'm currently running 2011.01, 2011.04-p1 and 2011.04-p2 on plum
I'll also re-run those builds on kiwi
04:48 bluescreen_ left, bluescreen left, bluescreen__ left
bacek_at_work pmichaud++ # benchmarking! 04:51
05:00 ShaneC joined
pmichaud core.pm results for 2011.01, 2011.04-p1, and 2011.04-p2, on kiwi: 05:13
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%
oops
that didn't format well 05:14
05:14 ShaneC left
pmichaud anyway, I'll let the rest of the bench marks run and post when I wake up from sleep 05:14
afk, sleep
05:38 theory left 05:57 jsut joined 06:02 jsut_ left 06:17 birdwindupbird joined 06:51 fperrad joined 06:53 cotto joined
cotto ~~ 06:54
tadzik o/
07:02 mj41 joined
moritz \\o 07:06
bacek_at_work /o 07:11
07:15 baest_ is now known as baest
dalek rrot: b788633 | dukeleto++ | NEWS:
Add a NEWS item
 07:24
dukeleto why do Capture PMC's exist? 07:29
moritz because Match objects are captures 07:30
and that makes nqp-rx much faster than doing it in PIR
(and historic reasons, I think they used to be used for argument passing, or something)
dalek rrot/leto/embed_grant: 3d00eba | dukeleto++ | t/src/extend_vtable.t:
Properly destroy more PMCs at the end of tests
 07:47
dukeleto moritz: yes, they seem to be a historical accretion
moritz++ for the explanation 07:48
moritz dukeleto: I think it might work out to move captures to nqp-rx/nqp 07:49
07:50 particle joined 07:51 dod joined
dukeleto moritz: not a bad idea 07:56
moritz ... under the assumption that the Capture dynpmc from nqp and nqp-rx don't conflict 07:57
migth be a matter of a small rename
or maybe nqp wants to go without Capture in the long run, and use a 6model capture (any opinions jnthn__?) 07:58
dalek rrot/leto/embed_grant: 621bb56 | dukeleto++ | t/src/extend_vtable.t:
[t] Parrot_PMC_getprop
 07:59
jnthn__ moritz: nqp nor nqp-rx has never had a Capture PMC of its own - it uses teh Parrot one in nqp-rx. 08:11
And in nqp we don't use it because it's (memory-wise) cheaper not to do so with 6model. 08:12
Capture is used by PAST also
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.
Also nqp-rx has never had dynpmcs
moritz right, the idea was "zero runtime" 08:14
jnthn__ exactly 08:15
moritz or "parrot is my runtime" ( /me wants PIMR t-shirts :-) 08:16
Tene aloha: tell whiteknight that I've started drafting my second attempt at ruby object model on 6model 08:24
aloha is our msg bot, right? 08:25
aloha Tene: Dunno.
sorear aloha: msg Tene test
aloha sorear: OK. I'll deliver the message.
moritz Tene: yes, s/tell/msg/
Tene aloha: msg whiteknight that I've started drafting my second attempt at ruby object model on 6model
aloha Tene: OK. I'll deliver the message.
jnthn__ Tene: yay :) 08:45
08:51 contingencyplan left 08:55 dafrito left 09:05 SHODAN joined 09:06 dduncan joined, dduncan left 09:13 woosley left
bacek ~ 09:27
~~
~~~
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>').
bacek aloha, help msg
aloha bacek: msg <nick> [that] <message>
bacek Tene, ^^^^
09:44 ShaneC joined 09:50 rurban_ joined 09:51 woosley joined 09:52 rurban left, rurban_ is now known as rurban 10:09 ambs joined 10:11 ShaneC1 joined 10:13 ShaneC left
dalek rrot: ef5ece1 | bacek++ | src/gc/gc_gms.c:
Fix very-very subtile bug with handling of GMS "dirty_list".

It should fix tickets #2105 and other GC related bugs.		 10:25
10:27 preflex left 10:30 preflex joined 10:53 dod left 11:06 dod joined 11:09 Psyche^ joined, Psyche^ is now known as Patterner
dalek rrot: 8e129a0 | bacek++ | include/parrot/pobj.h:
[cage] Remove unused PObj flag
 11:24
11:37 lucian joined 11:38 SHODAN left
pmichaud good morning, #parrot 11:52
moritz \\o pmichaud 11:53
11:53 lucian left
pmichaud gist.github.com/962397 # kiwi, 2011.01, 2011.04-p1 and 2011.04.p2 11:54
gist.github.com/962400 # plum, 2011.01, 2011.04-p1 and 2011.04.p2 11:55
gist.github.com/962403 # orange, 2011.01 through 2011.04-p1-ms2 11:56
11:59 bluescreen joined
jnthn__ o/ pmichaud 11:59
bacek aloha, pmichaud 12:00
pmichaud bacek: benchmark results ^^^ 12:01
bacek pmichaud, looking right now
pmichaud, erm... Looks like ms2 wins only on 8G of memory. Interesting. 12:03
pmichaud ...? 12:04
to me, ms2 never "wins"
12:05 lucian joined
bacek pmichaud, check kiwi stats. It's considerably faster on ms2 vs gms 12:05
pmichaud slower 12:06
bacek mmm....
erm...
gms is slower. Or I misunderstand almost everything
pmichaud you're misunderstanding, yes.
2011.01 with ms2 is faster than 2011.04 with gms, yes. 12:07
but 2011.04 with ms2 is very much slower than 2011.04 with gms
bacek It is what I'm talking about :)
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.
so
let's only compare ms2(01) vs gms(04+) :)
moritz it would be useful to find out which non-GC part have made parrot slower 12:09
bacek moritz, it will. One step at the time 12:10
moritz sure 12:11
plobsing moritz: that would require profiling. we either need a suitably fast testcase or a very powerful machine.
bacek pmichaud, "rx" test.
moritz or bisecting (assuming it can be attributed to one or just a hand ful of commits)
bacek Do I understand correctly that it's actually "GC heavy" test? 12:12
moritz is there any test that's not GC heavy?
pmichaud bacek: yes... it's heavy gc similar to how core.pm is a gc heavy test
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
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
I've been saying that I don't think gc is the primary slowdown culprit here
I think that gc improvements have just been masking other slowdowns 12:15
bacek Agreed. But I think we can make GC faster anyway.
jnthn__ bacek: If you have ms2, do the write barriers have any overhead/do anything?
moritz they are #define'd out at preprocessor time 12:16
jnthn__ OK.
pmichaud jnthn__: I'm wondering if the write barriers are the prime reason for the slowdown at 2011.02
jnthn__ pmichaud: Right, thus my question. :)
bacek jnthn__, one comparison in most cases.
moritz at least that's what the original plan was
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)
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.
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
pmichaud uncompress: 2.6MB, compressed: 100K
moritz uncompressed 12:21
ie "don't bother, it's not too large"
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
bacek pmichaud, ms2-02 is considerably slower on my box even without WBs. 12:25
111s vs 212s 12:26
12:26 lucian left
pmichaud bacek: so, sounds like something else hit Parrot between 2011.01 and 2011.02 12:26
bacek 111s for current master
pmichaud, I think so, but would like to have "independent validation". 12:27
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:28
pmichaud you want me to do the change on 2011.02 ? 12:30
bacek yes 12:31
moritz is 2011.01 parrot 3.0.0 ?
pmichaud moritz: yes
(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
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 :-)
it still has 2.9.1 or something as dependency 12:34
pmichaud bacek: what builds would you like me to compare against 2011.02-nwb (no write barrier) 12:35
?
2011.01, yes.
bacek indeed
pmichaud any others?
bacek 2011.02
(original one)
pmichaud just the core.pm and rx tests, or all tests?
bacek I think core.pm and rx will be enough for now. 12:36
pmichaud okay
bacek I just need indication that WBs aren't responsible for such slowdown.
12:41 whiteknight joined
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:48
bacek moritz, amd64? 12:49
pmichaud gist.github.com/962458 # trial 1, 2011.01 vs 2011.02 vs 2011.02-nwb
moritz bacek: tes
bacek: erm, yes 12:50
bacek pmichaud, so yes. WBs aren't responsible by it self.
whiteknight pmichaud: did you try the quick patch I made last night? 12:51
pmichaud moritz: maybe try timing p6regex-test, if you can?
p6regex-test is closer to rx
bacek whiteknight, didn't help much...
moritz pmichaud: p6regex-test = 01-regex.t + harness 12:52
whiteknight bacek: did it help at all?
moritz pmichaud: so that's essentially what I did
pmichaud moritz: okay
moritz: thanks
moritz pmichaud: you're welcome
bacek whiteknight, not really.
moritz I'll run it a few more times, to get some statistical significance
whiteknight okay, it was just a shot in the dark
pmichaud 11:54 <pmichaud> gist.github.com/962397 # kiwi, 2011.01, 2011.04-p1 and 2011.04.p2
11:55 <pmichaud> gist.github.com/962400 # plum, 2011.01, 2011.04-p1 and 2011.04.p2
whiteknight: ^^^ 12:53
2011.04-p2 is with the additional patch
whiteknight okay, yeah. No improvement
at least it's no worse :)
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
aloha OK. I'll deliver the message.
whiteknight bacek++ # the subtle GMS fix for darwin 12:58
bacek whiteknight, it wasn't darwin specific. But it was really hard to catch. 12:59
pmichaud gist.github.com/962472 # trials 1+2, 2011.01 vs 2011.02 vs 2011.02-nwb
gist.github.com/962476 # patch used to empty-define PARROT_GC_WRITE_BARRIER 13:00
I'm afk for a bit 13:01
coke_ rohit?
seen rohit.nsit08? 13:02
aloha Sorry, I haven't seen rohit.nsit08.
coke_ seen rohit_nsit08?
aloha rohit_nsit08 was last seen in #parrot 3 days 20 hours ago joining the channel.
coke_ rohit is rohit_nsit08
moritz nqp-rx on parrot 3.0.0: (11.730 +- 0.323)s 13:05
nqp-rx on parrot 3.0.0: (12.929 +- 0.047)s
now with 15 runs each
sorry, second line is 3.1.0 13:06
that's a difference of 3.2 standard deviations 13:07
so the chance that this is all stasticial flucations is < 0.1%
jnthn__ Statistical methods. You knows them. 13:09
moritz at least I pretend to :-)
dalek rrot: 19962bf | bacek++ | / (2 files):
[gc] Avoid second scan of C stack for soling fresh root objects. It should improve GC performance a bit.
 13:12
bacek s/solin/soiling/ 13:13
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:17
whiteknight it's good to get exams over earlier, and start coding sooner 13:20
coke_ I look forward to having a scheduled time to meet on the calendar. ;) 13:23
bacek ok, guys.
coke_ second time I've picked a time after he's already gone to sleep.
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
'night bacek
tadzik now?
moritz tadzik: no, generally for gsoc meetings
tadzik oh, I see
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.
moritz tadzik: sorry, wasn't very clear :-)
tadzik no, I just wasn't paying attention :) Your sentence was the first one on the stack :)
13:31 birdwindupbird left
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 13:57 rohit_nsit08 joined
rohit_nsit08 hello #parrot 13:57
coke_: ping
whiteknight good morning rohit_nsit08
rohit_nsit08: I'm going to be your backup mentor this summer
I don't know if Coke told you
rohit_nsit08 whiteknight: hello, good morning, yah read the mail, I'm happy :-) . 13:58
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
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!
rohit_nsit08 I informed coke_ about this change
whiteknight yes, we talked this morning
14:00 bacek_at_work left
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:01
14:04 aloha left 14:06 birdwindupbird joined, aloha joined 14:10 bacek_at_work joined 14:13 ambs_ joined 14:14 ambs left, ambs_ is now known as ambs 14:22 darbelo joined 14:36 contingencyplan joined
dalek rrot: 6832e5f | luben++ | / (4 files):
use float for --gc-nursery-size
 14:37
ttbot Parrot 6832e5fa MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/1188 14:46
14:57 atrodo_ joined 14:58 atrodo left, atrodo_ is now known as atrodo, atrodo is now known as atrodo_, atrodo_ is now known as atrodo
dalek rrot: 75fe3b2 | mikehh++ | frontend/parrot/main.c:
fix incorrect ASSERT_ARGS
 15:14
15:21 hercynium joined
ttbot Parrot 75fe3b2f MSWin32-x86-multi-thread make error tt.taptinder.org/cmdinfo/1208 15:22
mikehh strtof does not seem to be in the includes for windows build 15:26
whiteknight windows fail
I'll fire up the build on my win64 box soon to see what happens
mikehh line #679 of frontend/parrot/main.c 15:27
whiteknight oh, luben would have just changed that in his recent commit 15:29
okay
mikehh builds fine for me on Ubuntu 11.04 amd64
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
whiteknight I can't test it here for a while
mikehh whiteknight: can do
whiteknight mikehh++
at the very least it shouldn't break anything on linux, and might just make the bot shut up about windows 15:31
15:31 woosley left
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:33
NotFound ? 15:34
What's the problem with fractional values and strtod?
whiteknight strtod would still be giving us doubles
plobsing oops. wow, disregard. need to focus on one thing at a time
whiteknight :)
plobsing back to $work
NotFound ETOOMUCHSTRTOx 15:35
whiteknight ETOOMUCHLIBC
atrodo libc-- 15:36
c--
whiteknight if this were 1970, libc would be the undisputed king of libraries. Now, it isn't allowed to be nominated
dalek rrot: 5881c3c | mikehh++ | frontend/parrot/main.c:
attempt to fix windows build
15:36 woosley joined
whiteknight actually, that's a lie. In 1970 there were probably better libraries out there 15:36
atrodo I'm waiting for someone to chime in and say lisp 15:37
NotFound Probably, but C ran in machines where compilers with better libraries didn't fit. 15:38
whiteknight (nobody-should (mention (lisp))) 15:39
I hates me some S-expressions
Apparently Super Mario 64 was written in Lisp 15:40
atrodo Link?
NotFound atrodo: no, Link is in other game. 15:41
atrodo NotFound++
whiteknight www.franz.com/success/customer_apps...imen.lhtml 15:43
maybe it wasn't written in lisp itself. either way, something something lisp
atrodo whiteknight> That's what i found
I normally find marketing materials suspect
whiteknight yeah 15:48
benabik ~~ 15:49
15:49 davidfetter joined
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
15:50 theory joined
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
awesomeness
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
I don't know enough about the language community, but it sounded plausible
moritz some people like emacs
a language really needs a killer app 15:55
atrodo whiteknight> coding.derkeiler.com/Archive/Lisp/c...01698.html # Thread on comp.lang.lisp. An exaggeration at worse
moritz without rails, ruby would be largely unknown today
or at least largly unused :-)
atrodo Without perl, Perl would be largely unknown today as well :)
16:05 woosley left
dalek nxed: r990 | NotFound++ | trunk/winxedst1.winxed:
minimal refactor of MemberExpr emiters
 16:05
16:23 mj41 left
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.
whiteknight timezones are the worst 16:38
coke_ blames DST more. 16:39
coke_ would be happy if the whole world just used UTC with no DST.
whiteknight I would far prefer that in a number of ways
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
coke_ benabik: ... "that's what I said"
(but thanks for confirming it's not just me.)
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
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:42
I was trying to use get_how for two different things in different places, but not consistently. 16:43
whiteknight: so, approximately, I need to implement ruby-doc.org/core/classes/Module.html with 6model, along with the smaller Class and Object, glue them together like www.hokstad.com/static/rom/rom.png 16:45
github.com/ruby/ruby/raw/trunk/doc...lasses.png is the version in the ruby source tree
that's the core metacircular loop in the ruby class hierarchy
So, that should be fairly simple and straightforward. 16:46
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:47
when I really needed to just buy in completely. 16:48
16:54 mj41 joined
whiteknight Tene: okay, that makes sense 17:00
I need to start reading all those links! 17:01
17:03 ShaneC1 left
Tene Which links? 17:04
17:08 darbelo left 17:09 benabik left
whiteknight Tene: those links you just posted 17:11
well, only one of them isn't a picture 17:12
so that's the one I will read
17:13 rohit_nsit08 left 17:22 darbelo joined
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:22
If you want to learn about Ruby's object model, my recommendation is www.slideshare.net/burkelibbey/ruby...ther-magic 17:23
17:23 ShaneC joined
whiteknight okay, then I will read that too 17:24
I read a lot
Tene I don't know where your interests fall between 6model and ruby's object model 17:25
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
Tene: and I have to start somewhere. so I am starting here 17:27
Tene :)
whiteknight I really need to learn ruby eventually 17:30
I've put it off for long enough
pmichaud preliminary results of 2011.01 versus rakudo-bleed: gist.github.com/962932
aloha msg bacek_at_work preliminary results of 2011.01 versus rakudo-bleed: gist.github.com/962932 17:32
aloha pmichaud: OK. I'll deliver the message.
pmichaud afk, lunch
17:33 ShaneC left
whiteknight FFFFFUUUUUUU 17:41
There's really no excuse for our performance still being in that same ballpark. We should be much better than 3.0 17:42
not just a hair better on some benchmarks
cotto_work ~~ 17:43
whiteknight good morning, cotto_work 17:44
cotto_work hi whiteknight 17:46
dalek nxed: r991 | NotFound++ | trunk/winxedst (2 files):
improve prefix ++ and -- operators in stage 0
 17:49
17:50 rurban_ joined 17:52 rurban left, rurban_ is now known as rurban 17:58 benabik joined
dalek nxed: r992 | NotFound++ | trunk/winxedst0.cpp:
fix generated indentation
 18:00
18:10 ambs left
dalek nxed: r993 | NotFound++ | trunk/winxedst1.winxed:
profit from ++ improvements
 18:10
18:13 birdwindupbird left 18:14 whiteknight left 18:15 _dolmen_ joined
coke_ (benchmark) is it possible that the benchmark is dominated by rakudo, not parrot? 18:18
plobsing coke_: git log --after 2011.01 shows 7 commits. 18:21
coke_ plobsing: so?
plobsing none of them look particularly suspect
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:22
(not that I think this is necessarily the case, but that's what I'm floating here.) 18:23
sorear time = rakudo * parrot
everything rakudo does relies on slow parrot ops
plobsing I'd also point out that Ī©Ī· exhibits a similar regression
likely due to similar means of operation 18:24
so it isn't just rakudo
18:24 whiteknight joined
pmichaud coke_: what we can say pretty definitively is that parrot performance with ms2 has gotten substantially worse 18:27
so, *something* has been changing to cause the significant slowdown 18:28
(I'm currently doing some bisects to see if I can narrow it down a bit)
("git log --after=2011.01" doesn't show all of the commits since the 2011.01 release for me.) 18:31
plobsing hmmm... not sure what's up with that 18:32
pmichaud maybe git is treating it like some sort of weird date
git log --after=2011.01.01 shows me all of the commits since jan 1
18:33 _dolmen_ left, _dolmen_ joined 18:34 dolmen__ joined
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"?
plobsing s/identical... yeah that 18:35
pmichaud not really. 3.0 didn't have the write barrier code, 3.1 required it
so rakudo *had* to change to cope with that change in parrot.
plobsing didn't some intermediary versions of parrot have a nop wb macro?
benabik I think you want "git log 2011.01.01.." 18:36
pmichaud not until after 3.0 was released
plobsing benabik: no, I was trying to refer to the release tag
pmichaud notably, using the ..'s works for me
git log 2011.01..2011.02 shows me the commits between the two releases
benabik plobsing: --after is for dates, not tags 18:37
18:37 dolmen__ left
benabik plobsing: A..B is a revision range from committish A to committish B. Omitting one means HEAD. 18:37
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:38
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
just need about 30 more seconds to confirm :)
okay 18:41
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
benabik plobsing: The approxidate code is... wierd.
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.
pmichaud I may be able to run this version of rakudo on stock 3.0.0
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:45
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.
pmichaud okay, confirmed that the issue is likely a Parrot one 18:48
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
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
benabik plobsing: I'm only looking at what it does do, not what it should do. :-D
pmichaud I guess now it's just a matter of bisecting a bit :-)
pmichaud starts a bisect 18:51
benabik git-bisect++ 18:52
18:53 lucian joined
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:53
<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
tadzik you're lucky to have your finals soon :) 18:55
benabik tadzik: When's yours?
tadzik benabik: end on 30th of June
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
dalek rrot: a5aa340 | cotto++ | src/gc/gc_gms.c:
typo fix
 18:59
benabik tadzik: Agreed. 19:00
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
benabik plobsing: I suspect it's more something they never thought about in the YYYY.MM.DD parsing instead of a deliberate choice. 19:02
19:03 hercynium left, [hercynium] is now known as hercynium 19:05 hercynium left 19:06 hercynium joined
pmichaud RELEASE_3_0_0-342-gc2ffe55 good 19:06
RELEASE_3_0_0-399-g1429108 good 19:10
RELEASE_3_0_0-428-gbc265ee good 19:14
plobsing with each narrowing, it is looking more and more like gc_dynamic_threshold 19:17
pmichaud RELEASE_3_0_0-443-gbe26ad5 bad 19:20
RELEASE_3_0_0-369-gfe73887 good 19:23
19:26 jevin left
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
whiteknight plobsing: I keep looking at that merge
I can't put my finger on it 19:30
pmichaud the merge commit is the first one that reported bad, yes.
two steps to go
whiteknight ok, that's kind of a relief. I was hoping it wouldn't be the exception refactors
it would be a shame to rip those out
plobsing whiteknight: that last two bisects point to c0ddc7563fb7ed78f7235fec72f8e635894018ae as something more reasonable 19:31
we could quite easily change that
whiteknight maybe a command-line flag, since it is a legitimate trade-off between memory consumption and performance 19:33
19:33 dafrito joined
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
you'll scream along until you hit swap
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:34
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
whiteknight plobsing: yeah, that's fine too. How do we detect low mem? Or, more specifically, what is "low"?
4M really is too low, unless your screenname is kid51 19:36
of course, if we revert that commit outright, I'm sure he'll see build failures
so we need something configurable
plobsing We have routines to detect system memory, on which we used to base our GC thresholds. 19:37
We could go back to that, but with sanity checks.
whiteknight right, my question is about what heuristic is used to determine "low"ness or not
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() }
whiteknight: that's the jist of it
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
benabik The question becomes "what should we consider low", and set the percentage so 4M = low * percent
whiteknight right, that's the minimum that would allow it to even function
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
plobsing that is kinda big for a lower bound, but is more dynamic
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.
s/likely/going/
plobsing pmichaud: sure, on an otherwise unloaded system.
pmichaud in my case, there's a huge difference between 1GB and 4MB :-) 19:42
19:42 AzureStone left
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
pmichaud note that for rakudo spectests, I'm running seven copies of rakudo at once
if we assume a "lowmem" machine to be 256M, then 32M was obviously still too big 19:44
(since it had to later to be reduced to 4MB) 19:45
I'm also wondering if the number isn't strictly linear
jnthn__ Logarithm? :)
plobsing alternatively, it might just be that 4M is a common size for L2 cache
whiteknight Maybe Parrot needs to set some lower limits for expected amount of RAM
plobsing which would make it a reasonable-ish guess
whiteknight I mean, there is a lower limit where things stop working, we should get out in front and codify that
below 128M, maybe we throw up our hands and decide it's not worthwhile 19:46
cotto_work ulimit would be nice for that.
whiteknight at least not for the "desktop edition" of Parrot
pmichaud I'm going to patch rakudo bleed with the /8 threshold and see what I get
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
or 64M, or whatever we want it to be 19:47
19:47 AzureStone joined
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
pmichaud so 128MB seems unachievable, at least for now
benabik pmichaud: By my math that means we should set the threshold to 1/64 of sysmem.
plobsing the sysmem code at that time was inconsistent across OSes 19:48
perhaps the darwin did not show the full 256M
pmichaud oh, wait 19:49
min_threshold only applies to ms2?
plobsing gms may have something similar
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
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
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
that's the gms equiv 19:53
and the threshold is currently 2% sysmem
whiteknight that seems low
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. 19:54
20:04 bluescreen left
plobsing pmichaud: is the 3.1 performance with c0ddc75 reverted equivalent or better than 3.0? 20:04
or is that large regression hiding other regressions?
pmichaud plobsing: I'm currently trying 3.3 with a revert of c0ddc75
that way we can compare it with gms also
I can try a 3.1 with c0ddc75 a bit later 20:05
(c0ddc75 revert)
gist.github.com/963276 # the first set of numbers with c0ddc75 revert 20:10
whiteknight okay, so that brings ms2 back into the ballpark
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
plobsing I'd call that no significant difference except c0ddc75.
pmichaud sadly, it means ms2 still outperforms gms on my system
whiteknight pmichaud: it may just be your machine, since you have so much mem
pmichaud I can try it on my lower-memory notebook
it only has 3GB mem 20:12
(fsvo "only" :)
plobsing that means the ms2 regression was purely a function of GC tuning and suggests similar improvements can be had on gms
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
plobsing pmichaud: don't hate on the 3Gb lappy. that's my main machine.
pmichaud I love my laptop :)
it's still my favorite machine 20:13
whiteknight I was seeing at least 15% across the board, much better on certain bits
pmichaud whiteknight: yes, but was that relative to ms2 with the c0ddc75 commit?
whiteknight so the fact that ms2 is outperforming gms on your machine is striking to me
I really don't know the relative timing
pmichaud right
plobsing it is all in the tuning
pmichaud I *do* see performance improvement from gms versus 2011.01 on my notebook, yes.
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
there's something else about my laptop that causes gms to perform especially well
(I don't know what it is)
plobsing cache?
pmichaud L2 cache: 6144K 20:15
maybe
whiteknight my laptop has 4GB, I think, and it saw good improvements
pmichaud my old desktop's cache is 1024K 20:16
(most of the numbers are available in github.com/pmichaud/rakbench/tree/...esults/log if anyone wants to look 20:17
20:18 ambs joined 20:24 ambs left, ambs joined 20:31 fperrad left 20:39 soh_cah_toa joined 20:41 whiteknight left 20:47 ambs_ joined, ambs left, ambs_ is now known as ambs
cotto_work dukeleto: ping 20:48
21:02 perlite_ joined 21:05 benabik joined, perlite left, perlite_ is now known as perlite 21:06 benabik left 21:24 bubaflub left
dalek nxed: r994 | NotFound++ | trunk/winxedst1.winxed:
allow null in conditional operator and a few codingstd fixes
 21:27
21:33 ambs left 21:36 bubaflub joined 21:39 theory left 21:41 mj41 left 21:53 jevin joined 22:02 benabik joined, benabik left 22:11 bubaflub left 22:29 lucian left 22:33 _dolmen_ left 22:40 perlite left, preflex left, spinclad left, dukeleto left, mikehh left, simcop2387 left, tcurtis left, cotto_work left, PerlJam left, kthakore left, marc left, jnthn__ left, TimToady left, pmichaud left, tadzik left 22:43 perlite joined, preflex joined, spinclad joined, dukeleto joined, mikehh joined, simcop2387 joined, tcurtis joined, cotto_work joined, PerlJam joined, kthakore joined, marc joined, jnthn__ joined, TimToady joined, pmichaud joined, tadzik joined
bacek ~~ 22:51
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.
aloha OK. I'll deliver the message.
bacek run to $dayjob 22:56
cotto_work aloha: clock?
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
plobsing bacek: can you confirm the /topic entry about the breakage you added has been fixed?
bacek plobsing, ah. Yes. It's fixed. Not in very optimal way but fixed 22:58
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?
plobsing just confirming there wasn't some deeper issue
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
bacek cotto_work, or are you asking about /topic?
cotto_work yes 23:01
bacek it's kind of hard to write testcase for it. I'll try to implement it tonight.
cotto_work ok
moderator Parrot 3.3.0 released | parrot.org | Log: irclog.perlgeek.de/parrot/today 23:01
23:04 hercynium left
cotto_work I see why that'd be a tricky test case. You can always initialize and clone it directly. 23:04
23:10 whiteknight joined, bubaflub joined
bacek_at_work ~~ 23:21
whiteknight hello bacek_at_work 23:22
bacek_at_work aloha, whiteknight 23:23
whiteknight bacek_at_work: no more late debugging sessions! you need rest
bacek_at_work :)
23:25 theory joined
whiteknight I need to start valgrinding master 23:28
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
cotto_work ipfy@home 23:36
though benchmarking shouldn't really run in the background unless we're relying on something like valgrind 23:37
which has its own issues
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
and unbad it on all our target platforms, not fixing one to regress another
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
cotto_work actually, benchmarking in the background wouldn't be too bad on platforms that tell you how much time was spent per-process.
plobsing you could trigger alerts about degrading performance AS THEY HAPPEN, in stead of 4 months later when someone notices
cotto_work that'd be amazing 23:42
volunteers?
plobsing I guess I've talked this up too much not to
I'll look into it 23:43
along with the myriad of other things I've committed to doing in my copious spare time
cotto_work All we need is a barely-working prototype client and server. 23:46
fsvo "all"
plobsing don't we already have enough barely-working floating around here already?
cotto_work you'd think so 23:47
plobsing are there any virtualization solutions that emulate a real computers timings 23:51
cotto_work That's not a bad idea. 23:52
plobsing basically the system clock slows down and accelerates to hide the host

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!