»ö« Welcome to Perl 6! | perl6.org/ | evalbot usage: 'perl6: say 3;' or rakudo:, niecza:, std:, or /msg p6eval perl6: ... | irclog: irc.perl6.org/ | UTF-8 is our friend! Set by sorear on 4 February 2011. |
|||
00:00
Alias left
00:03
Alias joined
|
|||
felher | Whats the preffered idiom to do something x times? 'for ^x { do_something() }'? | 00:03 | |
donri | 5.times do something end # nowait | 00:05 | |
00:10
molaf joined
|
|||
[Coke] | nom: for ^5 { say 1} | 00:13 | |
TimToady | you mean rakudo: now | ||
donri | that sucker be merged eh | ||
TimToady | not a merge, a replacement | 00:14 | |
rakudo: say 1 for ^5 | |||
p6eval | rakudo 2bac6a: OUTPUT«11111» | ||
TimToady | rakudo: ^5 ==> map: say 1 | 00:15 | |
p6eval | rakudo 2bac6a: OUTPUT«===SORRY!===Confused at line 1, near "^5 ==> map"» | ||
[Coke] missed the party, being all $DAYJOBby with cold fusion and sql and jquery, oh my. | |||
donri | rakudo: class it{}; say it is so True | 00:16 | |
p6eval | rakudo 2bac6a: OUTPUT«===SORRY!===Confused at line 1, near "say it is "» | ||
felher | k, so i'll stick with for ^x. :) | 00:19 | |
[Coke] | whoops. I've been testnig nom branch last few days. | ||
Can we send an email to the dev list or get a blog post or something? | 00:20 | ||
should we able to just checkout master in an existing clone, or do we need to reclone? | 00:23 | ||
benabik | You should be able to check it out in an existing clone. | 00:29 | |
[Coke] sees lots of updates to t/spectest.data that don't actually show the error message. do we not want those anymore? | 00:34 | ||
(rant: no updates to master's RSS feed in google reader) | 00:40 | ||
... so, I'm confused. | 00:41 | ||
github.com/rakudo/rakudo/commits/master does not look like nom. | |||
is it just the eval robot that was updated? | |||
PerlJam | [Coke]: must be | 00:46 | |
master may actually go away. | |||
I don't know what pm decided. | |||
00:48
uasi joined
00:52
uasi left
01:02
donri left
01:10
drbean joined
01:12
uasi joined
01:13
uasi left
01:15
uasi joined
01:33
wolfman2000 joined
01:55
Sarten-X joined
02:00
tokuhirom left
02:01
woosley joined
|
|||
pmichaud | I've still been waiting to hear from jnthn++. But I may simply make a decision for him. | 02:01 | |
s/for/without/ | |||
02:14
jevin left
02:15
jevin joined
02:26
cexsum left
03:00
Tedd1 left
|
|||
lue | Hm. "master" suggests to me "mainstream --- use this if you're not a hardcore rakudo dev", but I wouldn't mind too much if it disappeared (no more "hey, it's not nom anymore, it's master!!") | 03:07 | |
03:26
DarthGandalf joined
|
|||
pmichaud | yeah, I'm inclined to not have a master, at least for a while. | 03:26 | |
03:27
Su-Shee left
|
|||
lue | "There's no such thing as 'mainstream' right now, at least not until we're Perl 6" | 03:28 | |
03:28
Su-Shee joined
03:32
zappepcs_ joined
03:33
odoacre joined
|
|||
lue | .oO(would current master become "beta" or "ng" (or some other -Ofun name?)) |
03:34 | |
benabik | b: say 'hello' | 03:35 | |
p6eval | b a55346: OUTPUT«hello» | ||
sorear | good * #perl6 | ||
lue: no "beta". | |||
lue: beta is -Ono-fun | |||
lue: because people are conditioned to think beta = leading-edge | |||
lue | ah, yes, forgot about that. | 03:37 | |
sorear | phenny: tell mberends Separate solutions for separate problems. | 03:39 | |
phenny | sorear: I'll pass that on when mberends is around. | ||
sorear | phenny: tell masak Str per se is immutable but there's... something... between Str and Cursor that is mutable. See also <cut>. | 03:43 | |
phenny | sorear: I'll pass that on when masak is around. | ||
03:44
zappepcs_ left,
zappepcs_ joined
|
|||
sorear | seen colomon | 03:45 | |
aloha | colomon was last seen in #perl6 8 hours 23 mins ago saying "\o". | ||
sorear | o/ colomon | 03:46 | |
03:46
zappepcs_ left
03:47
zappepcs_ joined
03:55
kfo_ left
03:56
ZaphrodZenovka left,
kfo joined
04:00
abercrombie left
04:01
ZapZ joined
04:03
ZapZ left
04:15
wolfman2000 left
04:16
satyavvd joined
04:20
Trashlord left
04:22
Trashlord joined
04:53
am0c left
05:04
sftp_ left
05:06
am0c joined
05:09
dhaivat joined
|
|||
dhaivat | When's Perl6 gonna be done? I'm sick of using PHP for work. | 05:10 | |
05:10
molaf left
|
|||
moritz | good morning | 05:24 | |
dhaivat: when is Perl 5 gonna be done? or C++? or Java? | 05:25 | ||
05:25
mberends joined
|
|||
sorear | morning moritz | 05:25 | |
mberends | morning moritz and hi, pre-thanks sorear | 05:26 | |
phenny | mberends: 03:39Z <sorear> tell mberends Separate solutions for separate problems. | ||
mberends | sorear: did yesterday's discussion leave you with something to work with, or a bikeshed color scheme? | 05:27 | |
sorear | yes | 05:32 | |
mberends | :) | 05:33 | |
plobsing | moritz: they just formally approved a new version of the fortran standard last year. apparently it can take over 50 years for a language to be "done". | 05:34 | |
moritz | .oO( lisp ) |
05:35 | |
TimToady | we're not really interested in "done", so much as "competitive" | 05:36 | |
plobsing | lisp is not a language. it is a philosophy. | ||
lue | "done" implies there's a fixed, concrete end-goal. From where I stand, there isn't one. | 05:38 | |
mberends | "practical" is what I want | 05:39 | |
in my view we will have succeeded when Ubuntu includes some Perl 6 based GUI apps in the place of the current Python based ones. | 05:53 | ||
05:54
araujo left
|
|||
lue | in my view we'll have succeeded when emerge uses P6 instead of python+bash :) | 05:56 | |
benabik | We'll have succeeded when people spent time talking about how they use P6 instead of talking about when we'll have succeeded. | 06:08 | |
dhaivat | lue: what's emerge? | 06:09 | |
sorear | lue: Ada is done. | ||
lue | it's the package manager for gentoo, a linux distro. | ||
sorear | although they might be designing a successor, I dunno | ||
06:16
koban` joined
06:17
koban` left
|
|||
sorear | dhaivat: The point is that your question is ill-defined because "done" is ill-defined. | 06:17 | |
dhaivat: If you ask a well-defined question about a definable concept like speed, memory usage, library support, etc, we can try to make forecasts. | 06:18 | ||
of course this is a volunteer project. we don't have HR or employment contracts, and the amount of work being done on Perl 6 fluctuates wildly from month to month, which means any forecasts will be of only approximate utility | 06:19 | ||
06:21
mberends left
06:22
ralfradio left
06:24
mberends joined
06:25
wayland76 joined
06:27
Tedd1 joined
06:35
ralfradio joined
06:36
wayland joined,
wayland76 left
07:02
cognominal___ left,
cognominal___ joined
07:05
jevin left
07:07
birdwindupbird joined
07:08
jevin joined
07:09
dark_x joined
07:11
araujo joined,
agentzh joined
07:18
ralfradio left
07:27
mj41 joined
07:29
rhr left
07:38
wamba joined
07:42
saaki joined
07:46
wamba left
|
|||
bbkr | mberends: FYI Lion 10.7.1 upgrade installed. No detailed changelog from Apple is available except "we fixed many, many things, worship us now". | 07:49 | |
07:55
daxim joined
07:56
rhr joined
|
|||
moritz | rakudo: augment class IO::Socket::INET { method foo() { } } | 08:00 | |
p6eval | rakudo 2bac6a: OUTPUT«===SORRY!===augment not allowed without 'use MONKEY_TYPING' at line 1, near "{ method f"» | ||
moritz | rakudo: use MONKEY_TYPING; augment class IO::Socket::INET { method foo() { } } | ||
p6eval | rakudo 2bac6a: ( no output ) | ||
mberends | bbkr: thanks! Some installation suggestions - mono (for Niecza), valgrind, JSON.pm. Also you may like some mberends/.profile bits stolen from Debian :) | 08:04 | |
bbkr | mberends: which JSON.pm - from P5? | 08:10 | |
mberends | yes, so it varies per installed p5 version I suppose | ||
bbkr | installation started: p5-json p5-json-xs mono mono-basic valgrind. JSON is common for all P5 versions. I'm not sure if you need also valgrind-devel | 08:14 | |
mberends | 'git pull' has also slowed down again from bbrk.org - is this another ssh problem? It works, but the delay is about 35 seconds. | 08:15 | |
valgrind-devel is probably only for devs who are changing valgrind. I think valgrind does use libc-devel on Debian. | 08:17 | ||
Debian valgrind depends on libc6-dbg | 08:20 | ||
bbkr | Yes, I know about git slowdowns. I'll try to figure out what is causing it. | 08:21 | |
mberends | it's only a minor matter | 08:22 | |
08:27
bbkr left
|
|||
mls | morning perl6! | 08:27 | |
phenny | mls: 01 Sep 16:52Z <pmichaud> tell mls would you be able to do the same sort of callgraph analysis for compilation of Rakudo ng's setting? | ||
mls: 01 Sep 16:53Z <pmichaud> tell mls it would be really useful to be able to compare the differences between ng and master | |||
mls | ok, generating... | 08:28 | |
08:49
ab5tract joined
08:50
wayland left
|
|||
flussence | lue: it's funny you should mention portage... one of their GSoC projects was a libbash to make it easier to write a package manager in other languages. turns out it's also a million times faster than calling the shell too. | 08:50 | |
08:51
wayland_ joined
|
|||
tadzik | hello #perl6 | 08:52 | |
moritz | o/ | 08:53 | |
09:10
woosley left,
orafu left,
orafu joined
|
|||
mls | phenny, tell pmichaud www4.informatik.uni-erlangen.de/~ml..._ng.out.gz | 09:17 | |
phenny | mls: I'll pass that on when pmichaud is around. | ||
09:28
pernatiy left
09:31
fhelmberger left
09:35
Mowah_ joined
09:37
fhelmberger joined
|
|||
mls | wow, the number of calls to as_post has grown quite a bit | 09:43 | |
tadzik | flussence: ping | ||
moritz | I wonder if that's related to how we store literals | 09:45 | |
tadzik | flussence: I guess we've come to the conclusion that Pod AST is not neceserilly HTML-friendly (see Lists in Pod). I thought about Markdown parsing today, and wondered if we want some sort of unified AST for Documents generally. Then we can write a Pod -> DocAST compiler and generate HTML easily from whatever we can compile to DocAST. So that'd work for Markdown as well, and whatever we want | 09:48 | |
mberends | tadzik: +1 good thinking | 09:52 | |
daxim | compare with the parsing work done by rjbs on pod and autarch on markdown resulting in events | 09:56 | |
sometimes, an ast is inconvenient | |||
tadzik | I think having a HTML emmiter for every possible format on earth is inconvenient | 09:57 | |
mls | moritz: could be the PAST::Want nodes | ||
unfortunately the pir seems to have no annotations, so kcachegrind doesn't show the file/line | 09:58 | ||
(the compiler should auto-generate annotations for subs that don't have any...) | 10:00 | ||
moritz | speaking of annotations... somehow in nom all reported files seem to be the current script, never modules | ||
tadzik | oh, speaking of which. We're not really into installing .pirs anymore, are we? | 10:01 | |
10:02
nebuchadnezzar left
|
|||
mls | (manually intserting .annotate statements...) | 10:02 | |
moritz | tadzik: you mean we should be installing .pbcs instead? | 10:03 | |
tadzik | moritz: I don't know, but we don't install e.g. Test.pir, do we? | ||
I think there's a reason for that | 10:05 | ||
also, IoC doesn't work when installed with pirs | |||
gist.github.com/1188309 | 10:06 | ||
10:08
espadrine joined,
uasi left
10:10
am0c left
10:11
wamba joined,
nebuchadnezzar joined
|
|||
flussence | tadzik: maybe we should just have a docbookxml emitter, and let that figure out how to convert to other formats :) | 10:15 | |
10:16
MayDaniel joined
10:29
Trashlord left
|
|||
bbkr_ | mberends: do you want mono LTS 2.6.7 or latest stable 2.10.5? | 10:37 | |
10:38
daxim left
10:39
daxim joined
|
|||
tadzik | flussence: if it's good enough? I mean, I don't know, never used it. And I'm much more towards the AST than a stringy format | 10:40 | |
10:40
MayDaniel left
|
|||
tadzik | maybe a sensemaking docbookxml emmiter is the first step | 10:40 | |
10:43
uasi joined
|
|||
bbkr_ | mberends: and bad news - valgrind is not yet released for Lion | 10:44 | |
10:45
uasi left,
uasi joined
10:49
uasi left
|
|||
mberends | bbkr_: mono latest stable please :) 2.6.7 has the old Boehm GC whilst 2.10.x has generational. sorear++ mostly uses latest mono | 10:50 | |
bbkr_ | mberends: no problem. i see 2 packages - MRE and MDK. do you need both? | 10:52 | |
mberends | bbkr_: I think MDK is to develop mono itself, if so then not required | 10:53 | |
bbkr_: the Mono C# compiler might be in a separate 'mcs' package | 10:54 | ||
espadrine | mberends: Do you know whether Boehm is still actively developed btw? | 10:56 | |
/me wonders if they think about implementing more advanced features in it. | |||
10:57
lateau_ joined
|
|||
mberends | espadrine: I think the Boehm main code is very mature and stable, but other people are producing experimental derivatives from it for SMP, NUMA etc. | 10:58 | |
10:59
flussence_ joined
11:01
flussence left
|
|||
mberends | espadrine: Hans Boehm is quite active with other memory management projects nowadays. www.hpl.hp.com/personal/Hans_Boehm/gc/ | 11:03 | |
mls | does pbc_merge really strip the annotations? | ||
11:04
thelazydeveloper joined
11:05
Trashlord joined
11:08
aduitsis joined
|
|||
bbkr_ | mberends: please check if mono MRE is installed correctly. 2.10.5 version, mcs is present, i'm not sure if anything else is required | 11:11 | |
mberends | bbkr_: starting Niezca build... | 11:13 | |
11:13
thelazydeveloper left
11:17
woosley joined
|
|||
mberends | bbkr_: Niecza built ok and passed all tests :) | 11:18 | |
bbkr_ | \o/ | ||
11:21
agentzh left
11:31
fhelmberger left
11:32
fhelmberger joined,
flussence_ is now known as flussence
11:34
daniel-s left
11:35
mtk left
|
|||
pmichaud | good morning, #perl6 | 11:48 | |
phenny | pmichaud: 09:17Z <mls> tell pmichaud www4.informatik.uni-erlangen.de/~ml..._ng.out.gz | ||
mberends | \o pmichaud | 11:49 | |
11:49
cognominal joined
11:51
cognominal___ left
|
|||
flussence | uh oh, my graph data contains negative values... | 11:52 | |
11:53
JimmyZ joined,
satyavvd left
|
|||
mberends | pmichaud: moving pir::time__N calls around in lib/Test.pm works, and produces timings between 5% and 95% lower than the currently committed version, but clutters Test.pm with timing code. Some may find this undesirable, justifying it depends on how much we want the feature. | 11:54 | |
some tests execute in 16 microseconds on the OS X server :) | 11:55 | ||
tadzik | wow, Rakudo is fast! :P | ||
flussence | I've been computing fails from ($plan - $pass - $skip - $todo)... looks like that's wrong. github.com/flussence/specgraphs/co...a16#diff-0 | ||
(maybe I should just omit them altogether and consider any test not accounted for a fail) | 11:56 | ||
pmichaud | seems to me that fails should be counted directly | 11:57 | |
not computed | |||
11:58
ab5tract left
|
|||
flussence | I'm doing it using TAP::Parser::Aggregator - didn't see an option to account for fails in the .pod, maybe I just missed it... | 11:59 | |
pmichaud | mls: ping | ||
12:10
mtk joined
12:30
MayDaniel joined
12:40
wamba left
12:41
daniel-s joined
12:48
donri joined
12:52
wamba joined
12:53
mtk left
12:57
bluescreen10 joined
13:06
mtk joined
|
|||
pmichaud | mberends: could I get a diff of your Test.pm with the additional pir::time__N calls, so I can see how cluttered it is? | 13:07 | |
mberends | ok | ||
pmichaud | gotta run a few errands -- bbiaw | 13:10 | |
(mberends: I don't need the diff immediately -- just whenever you get a chance) | 13:11 | ||
mberends | about to paste it anyway, but no hurry here | ||
pastebin.com/tDqSx0gZ | 13:12 | ||
13:19
daxim left
13:29
apejens left
13:30
wayland_ left
13:31
apejens joined
13:32
im2ee joined
|
|||
im2ee | Hello perl's world! :) | 13:34 | |
mls | pmichaud: hi! | ||
mberends | pmichaud: if the pir::time__N clutter is unwelcome I can work around it by making tools/test_summary.pl switch in its own Test.pm instead of the standard one in lib/, perhaps even by simply tweaking PERL6_LIB. There would be a bit of maintenance skew, but nothing serious. | 13:37 | |
13:46
woosley left
13:47
Mowah_ left
|
|||
tadzik | hello im2ee | 13:47 | |
[Coke] learns how to say "I don't know" in chinese. | 13:48 | ||
JimmyZ | [Coke]: ;) | 13:49 | |
tadzik | now as you long as you act as a very dumb person, you can perfectly resemble a native chinese speaker :) | 13:50 | |
13:50
aduitsis left
13:51
Holy_Cow joined,
Holy_Cow left
13:52
aduitsis joined
|
|||
JimmyZ | there are hundreds of dialects in china, but I can only say two of them | 13:55 | |
13:55
aduitsis left
|
|||
JimmyZ | s/say/say && understand/ | 13:55 | |
mberends | pmichaud: either way I plan to add some reporting to tools/test_summary.pl in a --view option. Current thoughts are a menu, sort by test time, speedup/slowdown since earlier test or % change, view in 'less'. | 13:57 | |
13:58
Alias left
13:59
odoacre left
14:02
risou_awy is now known as risou
14:05
jaldhar left
14:15
molaf joined
14:16
mkramer left
14:35
woosley joined
14:37
sftp joined
14:49
ggoebel joined
14:53
DerHartmut joined
|
|||
DerHartmut | Hi together | 14:53 | |
moritz | hello | ||
14:55
birdwindupbird left
15:11
scorpil joined
15:17
woosley left
15:35
scorpil left
15:36
im2ee left
15:37
im2ee joined
16:04
Aridai joined,
scorpil joined
16:10
Aridai left
16:13
dark_x left
16:24
dhaivat left
16:25
mj41 left
16:28
im2ee left
16:29
im2ee joined,
dark_x joined
16:32
colomon left,
JimmyZ left
16:55
envi left
|
|||
mls | pmichaud: the as_post calls showing up highest in the profile are just PAST::Block, PAST::Stmts, PAST::Stmt. Nothing suspicious. | 16:56 | |
16:57
DerHartmut left,
scorpil left
|
|||
im2ee | <.space> in tokens is the same what \s in p5? :) | 17:02 | |
PerlJam | im2ee: yes | 17:04 | |
im2ee | PerlJam, thanks :) | ||
PerlJam | well, <.space> is the same as \s in Perl 6. Perl 6's \s differes slightly from Perl 5's \s | 17:05 | |
17:05
uasi joined
|
|||
im2ee | Ok. :) | 17:05 | |
17:18
uasi left
17:22
lucs joined
17:26
mj41 joined
|
|||
pmichaud | back again | 17:33 | |
It's not the as_post calls that concern me so much (although if we have a lot more as_post for PAST::Block|Stmts|Stmt than for the others, *that* would be odd) | 17:36 | ||
apparently we create 3x as many PCT::Node objects in nom as we do in ng | |||
and that's probably why the past->post stage of compilation is taking so much longer | |||
in ng, we end up creating 465,609 PCT::Node objects (calls to 'new'). in nom, that number is 1,198,256 | 17:37 | ||
mls | Yes, that's also what the profiles say. There are twice as many objects created for nom, thus it takes twice as long. | 17:39 | |
(probably not twice, but 3x many object. It takes twice as long because the parsing time stays constant) | 17:40 | ||
pmichaud | I'd like to be able to get profiles for ng and nom where we compile the setting using --target=past instead of --target=pir | 17:41 | |
that would remove the creation of POST nodes out of the profile | |||
but _really_ I'd like to be able to generate these profiles myself :) | 17:42 | ||
moritz | mls: could you share your parrot patches? | ||
mls | Sure, I'll upload the (ugly) patch... | ||
17:42
buubot_backup left
|
|||
pmichaud | mls: how does your way of creating the profiles differ from Parrot's profiling runcore option, other than it seems to work in places where the profiling runcore doesn't and is apparently a ton faster? | 17:43 | |
mls | It's not that different. I looked at the parrot profile code, but it seems to print a line for every op instead of incrementing counters. | ||
(And I also use the TSC instead of doing a syscall. Highly unportable, but fast) | 17:44 | ||
(That's for counting cycles, op counting is portable, of course) | 17:45 | ||
pmichaud | I think it would be very valuable to get your code in as a runcore option | ||
even if it's only available for certain platforms to begin with | 17:46 | ||
mls | Yes, it shouldn't be that hard to integrate. It'll only report ops for platforms with no TSC. | ||
pmichaud | what do the numbers under "Incl." and "Self" represent? | ||
tadzik | TSC? | ||
pmichaud | oh, it's "ops" and "cycles" | 17:47 | |
cooool | |||
what are "cycles"? | |||
mls | en.wikipedia.org/wiki/Time_Stamp_Counter | ||
pmichaud | hmmmmm | 17:48 | |
moritz | what you get from (mutual) recursion, I thikn | ||
pmichaud | I think there must be something wrong, then. | ||
mls | what's wrong? | ||
pmichaud | should that be "ops" and "ticks" instead of "ops" and "cycles"? | ||
(to avoid the pun with "cycles" as used in callgraph cycle detection?) | 17:49 | ||
mls | Yes, ticks is probably the better name. | ||
pmichaud | okay, I'll use "ticks" here. | ||
The profile seems to indicate that the lineof function is responsible for the greatest number of ticks | |||
mls | ops | ||
sorear | good * #perl6 | 17:50 | |
mls | Hi sorear! | ||
pmichaud | when I switch to displaying ticks instead of ops, lineof jumps way to the top | 17:51 | |
(in the ng profile) | |||
mls | In my kcachegrind it's the other way round. | ||
Oh, ng. | |||
looking... | |||
Yes, it's number one both for ops and ticks | 17:52 | ||
cotto_work | mls: where's your patch? | ||
pmichaud | currently lineof is implemented using a linear search, which is O(n**2). I switched it to be a binary search so that it's O(n*log(n)) but saw hardly _any_ impact on overall performance. | ||
mls | working on it... | ||
Yes, that's to be expected | |||
pmichaud | and I put in some other tracing code into lineof to find out why it's taking a long time there.... and it still didn't seem to be a source of slowdown | 17:53 | |
so I'm curious why it appears so high in the profile | |||
mls | lineof isn't slow | ||
You should look at 'Incl.' | |||
(Speaking of lineof, I've also optimized it a bit. I store the position of the last match, because the lineof queries seem to be done in ascending order most of the time | 17:54 | ||
PerlJam | Are you guys still looking at the same kcachegrind file that mls posted yesterday? | ||
pmichaud | yeah, I thought about doing that approach also. | ||
PerlJam: yes, and a new one posted this morning for ng that I'm using as comparison. | 17:55 | ||
17:55
mberends left
|
|||
mls | you can do that on top of the binary search | 17:55 | |
pmichaud | I'll apply my binary search patch so we can get that artificial slowdown out of the profiles. | ||
mls | But lineof is not the responsible for the slowness. I once patched it to just return 0, and the compilation was just a couple of seconds faster | 17:56 | |
(back to patch creation...) | |||
pmichaud | right, so I'm wondering why it shows up high on the ticks count | 17:57 | |
according to the profile, it's 25% of the ticks | |||
mls | Just for "Self" | ||
pmichaud | no, in Incl | ||
(looking at ng here) | |||
mls | Checking... | ||
pmichaud | main has 296,492,734,685 Incl. ticks. lineof has 55,251,168,511 Incl. ticks | 17:58 | |
oh, sorry, 16% of the ticks. Still. | |||
(mental calculation error) | |||
mls | ticks have to be taken with a grain of salt | 17:59 | |
(not the animal ;) ) | |||
cause other processes interfere with the measurement | |||
pmichaud | like gc? | ||
mls | it's like gettimeofday() etc. | ||
Yes, gc as well. | 18:00 | ||
18:00
donri left
|
|||
pmichaud | yeah, so it looks like we can't really use ticks as a good measure of where things are slow. | 18:00 | |
mls | Well, it's better than nothing | ||
pmichaud | sure, but it also means it can lead us down false optimization paths | 18:01 | |
PerlJam | It's too bad you can't get actual timings. | ||
(except on a gross scale) | |||
pmichaud | PerlJam: yeah, this is one of those areas where I've been disappointed with parrot profiling. figuring out where things are slow is really hard. | 18:02 | |
18:02
frettled left
|
|||
pmichaud | not that profiling is easy, mind you :) | 18:02 | |
18:02
frettled joined
|
|||
TimToady | let's add threading and make it even harder! :) | 18:02 | |
pmichaud makes a little noose out of threads for TimToady++ | 18:03 | ||
mls | If the parrot run takes a long time, chances are that influences like gc will not matter much | ||
PerlJam | TimToady: it gets easier if you first project into 10 dimensions and then back out again. | ||
pmichaud | but I wonder why lineof gets such a disproportionate amount of the cost | 18:04 | |
mls | if gc always hits the same function, it's probably the function's fault | ||
PerlJam | mls: you have some statistical evidence to back up that claim? :) | ||
mls | ;) | ||
Did you do your lineof optimization in ng? | |||
pmichaud | actually, if gc is a function of number of ops executed, then lineof gets hit more often simply because it's executing so many ops (even though those ops are fast) | ||
the lineof optimization goes in Parrot | 18:05 | ||
mls | gc gets triggered by PMC allocation | ||
tadzik | pardon me, what's lineof()? | ||
pmichaud | well, that can't be it then. when lineof is called, it's not allocating PMCs | ||
mls | (gc = parrot's garbage collection, right?) | ||
tadzik | mls: right | ||
pmichaud | yes, gc == parrot's garbage collection | ||
mls | yes, so it's not a gc issue. | ||
18:06
mkramer joined
|
|||
pmichaud | lineof() is the function in HLLCompiler that calculates line numbers for source | 18:06 | |
18:06
buubot_backup joined
|
|||
pmichaud | i.e., given a string of source code and a position offset, determine the line number of the offset | 18:06 | |
tadzik | whoa | ||
mls | I can re-run the ng profiling to see if anything changes | ||
but first, i'll upload the patch... | |||
tadzik | do we need that for anything besides annotations? | 18:07 | |
pmichaud | tadzik: error messages, but those are rare | ||
at least, they're rare when compiling the setting | |||
tadzik | aye | ||
TimToady | tadzik: the main reason for lineof() is actually reliability | ||
pmichaud | and I'm fairly certain that lineof itself isn't eating up 16% of compilation time | ||
TimToady | it's very, very difficult to enforce line number counting in a parser | ||
tadzik | I thought that's it, but I didn't think that'd be so expensive in action | ||
pmichaud | tadzik: right, which is why I think it's a profiler artifact and not reality | 18:08 | |
tadzik | may be | ||
TimToady | but we can always be pretty sure of the current parser position | ||
pmichaud | and I'm trying to figure out the source of the artifact | ||
TimToady | I don't suppose there's anything in the profiling code that calls lineof() surreptitiously? | ||
pmichaud | doesn't seem likely. | 18:09 | |
the profiler is in C, while lineof() is PIR. | |||
and lineof() is strictly compile-time. | |||
that's a good thought, though, so I'll explore it a bit. | 18:10 | ||
PerlJam | I bet someone could build a chart of the necessary timing information for each parrot op and then marry that with mls' data to figure out where the real slow-down is. | ||
It would take a bit of work to do it by hand though | |||
pmichaud | PerlJam: I think it's not so simple. | 18:11 | |
PerlJam: remember that parrot ops sometimes call into PIR. | |||
so "timing information for each parrot op" gets convoluted really quick. | |||
PerlJam | well, how about "timing for each parrot-level sub" instead? | 18:12 | |
cotto_work | Yeah. Dealing with nested runloops took a lot of thought. | ||
pmichaud | "timing for each parrot-level sub" is also somewhat convoluted. See gc. | ||
If GC occurs in the middle of a sub, do we charge the sub with the cost of GC? | |||
PerlJam | pmichaud: it would have to be stastical | ||
with large error bars I guess | |||
pmichaud | what might be really helpful is if the profiler could treat GC as a separate subcall | 18:13 | |
so then if, for example, GC is occurring within lineof, it shows lineof as a caller and charges the expense of the GC to the phantom GC sub instead of lineof itself | |||
(the Incl. total would still include the cost of the GC, but we'd be able to separate the GC cost from the "actual work" cost) | 18:14 | ||
PerlJam | I haven't seen mls' patch, but it sounds like he could intercept GC calls and do something special. | 18:15 | |
pmichaud | maybe. I suspect the profiling patch works at the level of intercepting things at the level of op dispatch. GC takes place in another area, iiuc. | 18:16 | |
mls | yes | 18:17 | |
18:17
plobsing left
18:18
mberends joined
18:19
plobsing joined,
kaare_ joined
|
|||
PerlJam | isn't there an op to force a GC run? | 18:19 | |
Couldn't you call it periodically so that GC runs are more predictable? | |||
cotto_work | collect iirc | ||
mls | diff: www4.informatik.uni-erlangen.de/~ml...ofile.diff | 18:21 | |
pmichaud | we probably could, yes. but based on what mls++ said above, I doubt that gc is occurring during lineof | ||
mls | Use: parrot -R slow will dump the valgrind data to stderr | ||
not very confty, but it works for now | 18:22 | ||
PerlJam | I wonder how much the GC system knows about the state of parrot when it's called? Maybe the GC system itself could be instrumented for profiling such that the results could be subtracted from the cachegrind stuff | ||
cotto_work | mls: do you mind if I start a branch on parrot.git with that? | ||
mls | no, go ahead | ||
the patch is now in public domain ;) | 18:23 | ||
pmichaud | cotto_work++ cotto_work++ a branch with that is exactly what we need | ||
plobsing | mls: why do you manually handle the annotations and then call PackFile_Annotations_lookup? | 18:24 | |
pmichaud | just a sec, I'm about to commit my binary search patch | ||
mls | see the discussion on #parrot | ||
plobsing | mls when? | ||
cotto_work | mls: what's the difference between this profiler and the one in parrot now? | 18:25 | |
plobsing | oic, it handles the sub lines. sorry | ||
18:25
rlb3 joined
|
|||
mls | Didn't you suggest the null annotations? | 18:25 | |
cotto_work | is it just sub-level? | ||
plobsing | yes. I didn't put 2 and 2 together | 18:26 | |
pmichaud | binary search patch pushed. | 18:27 | |
mls | (for reference: that was my lineof patch: gist.github.com/1189409) | 18:30 | |
pmichaud | I think we can get a bit better if we simply cache lastline and not lastpos | 18:32 | |
and compare linepos[lastline] against pos | |||
18:33
rlb3 left
|
|||
pmichaud | if linepos[lastline] < pos, then we start from lastline. | 18:33 | |
mls | You need to check that lastline is in bounds first | ||
pmichaud | in bounds? | ||
mls | lastline < elems(linepos) | 18:34 | |
pmichaud | it has to be, if we're caching | ||
well, I suppose it could be elems(linepos) exactly | |||
mls | yes | 18:35 | |
pmichaud | which would be "out of bounds". but that's still a pretty easy check. | ||
it gives us a better start position for 'line' (or 'lo' in the binary search) | |||
cotto_work | mls: I'll push as soon as I've verified a clean(ish) build. Thanks! | ||
mls | I hope it works also on 64bit builds, I've just tested 32bits | 18:36 | |
cotto_work | mls: I'd appreciate it if you'd send a quick note to parrot-dev about what it does. | ||
I believe pmichaud can answer that question. ;) | |||
and pushed | 18:37 | ||
pmichaud | well, I'm waiting for the branch to arrive :) | ||
because then it's easy to do in nom | |||
just --gen-parrot=branchname | |||
18:38
ab5tract joined
|
|||
mls | I think I stored lastpos so that lookups between lastpos and linepos[lastline] also are fast | 18:38 | |
i.e. if you lookup the same value twice, the second lookup is fast | 18:39 | ||
pmichaud | I suspect "look up the same value twice" almost never happens, though. | ||
18:39
lateau_ left
|
|||
pmichaud | well, it might happen, now that I think about it. | 18:39 | |
mls | well, you can just subtrace one from lastline | 18:40 | |
then you also don't run into problems with elems(linepos) | |||
pmichaud | might run into problems on line 0, though. | ||
so still need the check. | |||
mls | ;) yes, but that's a simple == 0 check | ||
pmichaud | well, checking against elems() isn't hard either, since we have to get that value anyway | 18:41 | |
18:41
donri joined
|
|||
pmichaud | I'll add a 'lastline' patch here shortly | 18:41 | |
mls | subtracting one will help the "lookup same value" case | 18:42 | |
but implement it any way you like ;) | |||
18:43
MayDaniel left
19:05
mkramer left
19:06
mkramer joined
19:12
jevin left
19:13
jevin joined
|
|||
mls | cotto_work: mail sent. | 19:18 | |
ok, weekend ;) | 19:21 | ||
lue | hello Camelialand o/ | 19:28 | |
tadzik | o/ | 19:32 | |
sorear | hello | ||
19:33
mj41 left
|
|||
TimToady | nom: my @x; @x[0][0] = 42; | 19:33 | |
rakudo: my @x; @x[0][0] = 42; | |||
p6eval | rakudo 2bac6a: OUTPUT«Cannot assign to a non-container in <anon> at /tmp/Dcv4MRlqCV:1 in <anon> at /tmp/Dcv4MRlqCV:1» | ||
TimToady | is there an eta on autoviv in nom? | ||
PerlJam | TimToady: when it's ready. ;) | 19:34 | |