02:13
vendethiel joined
04:10
tokuhiro_ joined
07:38
FROGGS joined
|
|||
nwc10 | good *, #moarvm | 07:55 | |
09:11
zakharyas joined
10:48
brrt joined
|
|||
brrt | good * | 10:49 | |
i've a question | 10:50 | ||
for symmetry reasons it would be.. reasonable to add a 'zero label' at the beginning of the jit code | |||
well, let me first explain the challenge | |||
lizmat | brrt nwc10 o/ | ||
brrt | \o lizmat | 10:51 | |
i've decided on the following labeling strategy; all basic blocks receive a label that is equal to their basic block index; the graph end recieves a label equal to the number-of-basic-blocks (hence 1+ largest basic block); | 10:52 | ||
only before-instruction labels exists, and they are managed in an associative array, whereby the index + the instruction label offset equals the label number | 10:54 | ||
internal expression labels are calculated after that still | |||
anyway, because the first basic block is always a NOP, it is simply skipped during JIT graph building | 11:01 | ||
(first bb of a spesh graph, that is) | |||
but this bb has index 0; hence no basic block has index 0; hence this label is not initialized, hence a crash | 11:02 | ||
(label 0 is used as the initial entry label for a newly created frame) | |||
timotimo | brrt: you could just put nops in the code? | 11:03 | |
brrt | i though it would be a sensible idea to have label 0 as the 'start of graph' label, except that it is of course completely redundant | ||
anyway, lecture & | |||
timotimo | good lecture, brrt | ||
lizmat | .tell jnthn I think we have a problem with nqp::readlinechompfh : if the last line in a file is empty, nqp::eoffh is 1 and nqp::chars=0 | 11:10 | |
hmmm...no yoleaux here ? | |||
.tell I wouldn't expect eoffh to be true until the next read | 11:11 | ||
timotimo | yeah, no yoleaux in here | ||
11:23
camelia joined
|
|||
lizmat | $ 6 'spurt("one","\n"); say open("one").get' | 11:27 | |
(Str) | |||
11:27
camelia joined
|
|||
nwc10 | brrt: yes, wingolog.org/archives/2015/11/03/tw...mentations is interesting. And seems to have created a sideline in (C)Python speed optimisation snark. For reasons I don't know why | 11:39 | |
FAT Python looks interesting enough - as in, I'm curious to see how the experiment pans out: article.gmane.org/gmane.comp.python.devel/155300 | |||
given that "no plan survives contact with the enemy" | |||
eg blog.kevmod.com/2014/04/pyston-faq/ -- PyPy uses a tracing loop JIT, and Pyston uses a method-at-a-time JIT. A tracing JIT like PyPy can be impossible to beat when they hit their fast path, but my hope is that a method-JIT like Pyston could hit its fast path more often and more reliably, especially for larger codebases, which will end up being a win even if the fast path is not quite as fast. | 11:41 | ||
jnthn | timotimo: We actually compute the NFC/NFG "together" rather than producing all the codepoints as an intermediate step, and encodings are free to not send stuff through the normalizer; that's what the utf8-c8 decoder will do. | 11:52 | |
timotimo | oh! | 11:53 | |
that's good! | |||
... AFK for a bit | 11:54 | ||
oh, also: github.com/MoarVM/MoarVM/issues/149 this issue is about a "die" in a signal handler not causing the program to exit. i think it shouldn't, but i wanted input from someone else before i reject the addendum to this ticket. | |||
jnthn | timotimo: That's not a MoarVM issue any more | 11:57 | |
And there's already an RT about die in a tap getting swallowed | 11:58 | ||
dalek | arVM/utf8-c8: 8c0623f | jnthn++ | src/strings/utf8_c8.c: Factor out repetitive resizing code. |
12:20 | |
arVM/utf8-c8: e97782b | jnthn++ | src/strings/utf8_c8.c: Flush normalizer upon an undecodable. |
12:28 | ||
brrt | nwc10, oh, backloggings | 12:41 | |
dalek | arVM/utf8-c8: 065cd60 | jnthn++ | src/strings/utf8_c8.c: Fix reject loop to not lose bytes. |
||
brrt | nwc10: i can kind of explain the wingolog snark, i think | 12:42 | |
nwc10 | oh? The comment snark seemed to be from people other than the blog owner | 12:43 | |
brrt | the cpython core development team has decided not to add features that improve performance by x% if they increase complexity by >x% | ||
oh, really? | |||
i didn't read the comments | |||
nwc10 | there was somewhat snark in the blog | ||
and then similarly toned comments from at least one person | 12:44 | ||
brrt | well, it is a reasonable question; it's almost as if the cpython team doesn't care (gasp) | ||
and the cpython team *doesn't* care, and this is within their rights to do so | |||
nwc10 | and *yes*, it did all seem to agree - that the CPython folks aren't fretting about performance | ||
brrt | i liked the expression 'c extension furnace' | 12:45 | |
nwc10 | me too | 12:46 | |
loved that one | |||
arnsholt | Yeah, that was a brilliant turn of phrase | ||
jnthn | Choosing to compete by being the solid/stable/reliable choice is reasonable. | 12:47 | |
Many people *will* value that over performance | |||
Part of the challenge of MoarVM development is that we need to both provide reliability and push the Perl 6 performance boundary too. | 12:48 | ||
nwc10 | Choosing to avoid painting yourself into a maintenance corner in the middle future also makes sense | ||
in the same vein, it's important to have "rigidly defined areas of doubt and uncertainty" otherwise you have no wiggle room to fix any bugs ever | 12:49 | ||
"but the existing implementation did that, and I relied on it" | |||
arnsholt | Yeah, Python suffers a bit from that, I think | 12:50 | |
jnthn | We've yet to see how well "if it's not covered by the test suite it's our wiggle room" works out for Perl 6. :) | 12:52 | |
arnsholt | Yeah, obviously =) | 12:53 | |
But at least there's some consideration given to the potential existence of several implementations | |||
We've got that going for us, which is nice =) | |||
nwc10 | brrt: it's really hard to assess 'increase complexity by >x%' | 12:56 | |
brrt | yes | ||
nwc10 | I agree that it's a legitimate choice. It's just that it's very hard to try to be objective about it | ||
brrt | well, it is a costly choice, too | 12:57 | |
on the other hand.... | |||
the other side of it, is that the JIT has seen a somewhat oscillatory process of complexity | 12:58 | ||
i.e. I add something to make something work, then I change it to be more understandable, then I add new features, then I rework them | |||
that is basically the only way I can keep going | |||
if you insert a barrier at >x% complexity, then you may never cross it | 12:59 | ||
because it tells people 'don't bother doing that, it is too complex' | |||
so, there is an important signal value in not wanting complexity, aside from the effect of reducing complexity | 13:00 | ||
and as an aside, the guile vm looks actually increasingly promising, i think | 13:01 | ||
timotimo: do you recall who it was that asked for illumos? | 13:04 | ||
timotimo | it was konobi | 13:07 | |
brrt | hmmm... doesn't seem to be online now | 13:10 | |
i would kind of need a good testcase for this | 13:11 | ||
it'd be really stupid if illumos support would fail because of this minor issue in minilua | 13:12 | ||
on the other hand | |||
we can configure to disable the JIT for illumos | |||
timotimo | why is konobi not online? at least in the nicklist | 13:13 | |
brrt | oh, he is | 13:14 | |
i was looking wrong | |||
timotimo | that's why i relied on my tab key | ||
brrt is using webchat because of the great it department of my $study-office | 13:19 | ||
timotimo | %) | 13:20 | |
brrt | i can't listen to internet radio, either :-( | 13:22 | |
(first world problems much... :-P) | |||
13:23
stmuk_ joined
|
|||
timotimo | that's a productivity reducing problem, IMO | 13:25 | |
well, it can be. depending on the person in question | |||
13:26
kjs_ joined
|
|||
brrt | happiness reducing problem, i think | 13:29 | |
also, reducing stimuli problem in a shared office | 13:30 | ||
dalek | arVM/utf8-c8: 1650c8b | jnthn++ | src/strings/utf8_c8.c: Fix off-by-one on the undecodable. |
13:40 | |
arVM/utf8-c8: 58f2bbb | jnthn++ | src/strings/utf8_c8.c: Implement UTF-8 C-8 encoding. |
|||
brrt | (also the phrase 'powerful, bitter C++ wizard' - rather strong image) | 13:58 | |
14:35
brrt joined
15:08
colomon_ joined
|
|||
dalek | arVM/utf8-c8: 96fafa0 | jnthn++ | src/strings/utf8_c8.c: Implement UTF-8 C-8 streaming decode. |
15:14 | |
jnthn | Phew | ||
nwc10 | in that, you think that it's done? | ||
jnthn | The encoding, yes | 15:15 | |
Now I "just" need to update various places to use it | |||
timotimo | much triage | ||
jnthn | I also can't really write tests for its effectiveness on Windows | ||
Because Windows was sensible enough specify the encoding for file system entries | 15:16 | ||
brrt | wait, what | ||
jnthn | I mean, the encoding I can test | ||
brrt | filesystem entries (file- and directorynames) are encoded in windows? :-o | ||
hmmm | |||
brrt wonders.. and wonders | |||
and sees potential for abuse | 15:17 | ||
jnthn | Well, hmm | 15:19 | |
"Use any character in the current code page for a name, including Unicode characters and characters in the extended character set" | |||
timotimo | so ... i wonder why loop { start { say "hello" } } hangs. should i spend time investigating that? | 15:20 | |
jnthn | timotimo: I've no idea why it would | ||
timotimo | (that's issue 140 on github) | ||
lizmat | perhaps it doesn't get a lock to actually cue ? | ||
I mean, start doesn't actually cue, does it ? | 15:21 | ||
jnthn | It cues | ||
Well, it calls Promise.start({...}), which does | |||
brrt | cue? | 15:22 | |
lizmat | so it pushes it to $!ququq | ||
$!queue | |||
timotimo | it takes its sweet time to actually hang ... | 15:23 | |
lizmat | does anything reading from the queue get a chance in that loop { start {} } setup ? | ||
timotimo | or perhaps i'm failing to reproduce that right now | ||
sure, the code blocks get run all the time | |||
now it hangs! | |||
jnthn | lizmat: Well, it's another thread that's reading | ||
timotimo: Neat. Now get backtraces of the threads (C level should do) under the debugger :) | 15:24 | ||
timotimo | oh. why did i ctrl-c? :| | 15:25 | |
(because another snippet in that issue uses sleep 0.01 instead of say and is said to segfault) | |||
it doesn't segfault here, but surprisingly its memory usage grows | |||
nwc10 | jnthn: it seems to break | 15:26 | |
timotimo | stopped it just above a gig | ||
nwc10 | not ok 96 - nqp::escape | ||
dalek | arVM/utf8-c8: 3f77ddc | jnthn++ | src/strings/utf8_c8. (2 files): Add "encode to C string" function for UTF-8 C-8. |
||
jnthn | nwc10: "it"? | ||
nwc10 | origin/utf8-c8 | ||
yes, sorry, return key faster than me | |||
jnthn | nwc10: Suspect missing patches from master | 15:27 | |
nwc10 | is that one of those "excuses" like: | 15:28 | |
15:28 <dipsy> Your excuse is: clock speed | |||
:-) | |||
lizmat | so if I understand C-8 correctly, it creates 256 synthetics for each possible byte value ? | ||
nwc10 | well, 128, if I understand it, because it's only the octets 128-255 | 15:29 | |
timotimo | gist.github.com/timo/e718153e22177958174b - fun! | 15:30 | |
lizmat | wouldn't that be usable for allowing regexen on binaries, given the right syntactic sugar ? | ||
brrt | timotimo: you might want to run that with MVM_JIT_DISABLE=1 | 15:31 | |
and see if that changes anything, anyway | |||
timotimo | one thing about regexes on binaries is that we'd like to switch interpretations between 8 and 16 and 32 bits and such | ||
brrt: can do! | |||
brrt | :-) | ||
timotimo | i forgot about the backtrace screwyness we get ... | 15:32 | |
lizmat | I think a lot of people would already be very happy with 8 bit :-) | ||
timotimo | it looks a lot like a case we didn't yet cover in the GC orchestration code | ||
brrt: any reason to go "bt full" on this? | 15:33 | ||
brrt | other than why not, i'm not sure | ||
timotimo | there's a second file in there now | ||
brrt | i'm surprised by how many threads there are | ||
oh, it's a loop, duh | 15:34 | ||
timotimo | brrt: because of LABELS = {0x7ffff7afd0fe <MVM_interp_run+142>, 0x7ffff7b0dd31 <MVM_interp_run+68801>, | ||
brrt | oh, well, then not | ||
anyway, my spider sense is thinking OSR | |||
probably wrong, but worth a shot | |||
timotimo | now there's a third file in there | 15:37 | |
helpfully that file is right on top | |||
jnthn | nwc10: No, there actually is a patch in master about escape that landed after I started the branch :) | 15:38 | |
timotimo | could just be that shift of ConcBlockingQueue has to mark the thread as "blocked" | ||
jnthn | timotimo: Ah, it doesn't? | 15:39 | |
It should | |||
nwc10 | people other than you commit stuff‽ | ||
jnthn | I know, shocking! | ||
timotimo | hm, actually | ||
it seems like it does | |||
jnthn | The project's at risk of having a community or something :P | ||
timotimo | because inside the thread that shows that particular variable, num_threads is 2 | ||
thread 15 is doing some atomic integer faffing about inside orchestrate.c | 15:40 | ||
thread 1 is in gc_enter_from_allocator and has num_threads = 2 | |||
brrt | we shouldn't let the bus factor get too high :-o | 15:41 | |
timotimo | brrt: makes it more expensive for the government to shut our project down | ||
thread 1 spins on if (threads && threads != last_starter) ... while (MVM_load(&tc->instance->gc_start) > 1); | 15:42 | ||
thread 15 is inside the while (MVM_load(&tc->instance->gc_start)) | 15:43 | ||
oh, would you look at that | 15:45 | ||
print tc->instance->threads | |||
0x0 | |||
who does that? | |||
jnthn | o.O | 15:46 | |
timotimo | for some reason there's an if(threads && ...) in there | 15:47 | |
so ... do we expect tthat to be null in some cases? | |||
dalek | arVM/utf8-c8: 3f40008 | jnthn++ | src/ (11 files): Use UTF-8 C-8 encoding in OS/IO interactions. |
||
timotimo | like, if there's only the one main thread? | ||
timotimo is definitely not on the GC orchestration bus | 15:48 | ||
jnthn | $ env - ACME=$'L\xe9on' ./perl6-m -e 'say "hi"' | 15:49 | |
hi | |||
\o/ | |||
timotimo | neato! | 15:50 | |
m: say chr(\xe9) | |||
camelia | rakudo-moar ea87a8: OUTPUT«===SORRY!=== Error while compiling /tmp/2b1CTawTcgUndeclared routine: xe9 used at line 1» | ||
timotimo | m: say chr(0xe9) | ||
camelia | rakudo-moar ea87a8: OUTPUT«é» | ||
timotimo | m: say uniname(0xe9) | 15:51 | |
camelia | rakudo-moar ea87a8: OUTPUT«LATIN SMALL LETTER E WITH ACUTE» | ||
timotimo | ah. damn this font. | ||
brrt | timotimo: we're distributed over multiple government areas already, so that makes it pretty hard for one government to shut moarvm down | 15:54 | |
except ofcourse by the TPP agreement | |||
16:02
kjs_ joined
|
|||
dalek | arVM/utf8-c8: 43377bb | jnthn++ | src/strings/utf8_c8.c: Be a little smarter about undecodables. |
16:03 | |
timotimo | there is already a single world government. it's the one run by the lizard people | 16:10 | |
brrt | lousy government at that, with so many civil wars, then | 16:12 | |
timotimo | yeah | 16:13 | |
well ... | |||
really depends on what metric you apply | |||
they clearly have something different in mind than "world peace and the continuation of the human race" | |||
that's not "typical lizard people stuff" | 16:14 | ||
bbiab | |||
jnthn | Darn, that was a silly bug | 16:18 | |
dalek | arVM/utf8-c8: e5a39f6 | jnthn++ | src/strings/utf8_c8.c: Fix forgotten function call rename. |
16:19 | |
jnthn | $ echo 'say(42)' > $'L\xe9on' && ./perl6-m $'L\xe9on' 42 | 16:20 | |
fail paste, that 42 at the end shoulda been on another line | |||
But anyways, it works. | |||
brrt | \o/ | 16:21 | |
dalek | arVM: 1beea0b | jnthn++ | / (9 files): Work in progress UTF-8 Clean-8bit encoding. For allowing us to round-trip filenames and so forth. Only partially implemented so far. ee75b65 | jnthn++ | src/strings/utf8_c8.c: Tweak comment to be lik-er. |
16:39 | |
jnthn | Dear dalek, that was a merge :P | ||
16:40
dalek joined
|
|||
17:29
kjs_ joined
|
|||
dalek | arVM/even-moar-jit: 7d88c3e | brrt++ | / (10 files): Refactor labelling Now all basic blocks receive a label equal to their basic block index. Because we skip the first basic block, the 'zeroth' label is available for the graph start, and the end-of-graph label is simply equal to the number of basic blocks (hence 1 greater than the latest basic block). Individual instructions are labeled, if necessary, using an associative array as before. Internal expression labels are computed during compilation based on the offset. |
17:35 | |
17:36
brrt joined
|
|||
brrt | of course, the real work is now porting the labeling stuff to the epxression jit | 17:38 | |
i'm wondering if i can try to make the interface between these things shared | 17:39 | ||
jnthn | brrt++ # the scheme sounds sane | 17:41 | |
jnthn bbl | |||
brrt | :-) | 17:42 | |
17:44
brrt joined
|
|||
JimmyZ | jnthn: I saw there was a gist about type coercion, I lost the url ... | 17:45 | |
17:47
kjs_ joined
|
|||
TimToady | a datapoint on the non-complexifiying of Python; at Hackers Guido was showing off $9 Python board that they're gonna distribute a million of to British schoolchildren | 18:01 | |
I've always emphasized community, but Guido has usually aimed more for institutionalizing, which I figured out when he went to work for NIST :) | 18:03 | ||
nwc10 | what's "Hackers" in this context? I have a suspicion that it's pretty hard to Google | ||
japhb has to mentally recite "If you don't have anything nice to say, don't say anything at all" WRT institutionalized Python | 18:04 | ||
nwc10 | the board will be this, unless I'm confused: en.wikipedia.org/wiki/Micro_Bit | ||
18:04
colomon joined
|
|||
nwc10 | my employer had been at risk of becoming an institution. And those that could survive the environment, institutionalised. | 18:05 | |
Fortunately, regime change happened. | |||
japhb | My wife once had a contracting job that was so stressful that people literally left the team via heart attack. | 18:07 | |
(She was sufficiently mobile to leave of her own volition first, but sheesh.) | 18:08 | ||
nwc10: If the specs on the wikipedia page are correct, the I/O controller on that board is significantly more powerful than the CPU. | 18:09 | ||
TimToady | nwc10: the 31st Hackers Conference, which was this weekend | 18:11 | |
18:11
kjs_ joined
|
|||
[Coke] still can't find a url even with that. (one major hit, but it's from 2014) | 18:12 | ||
nwc10 | me neither. :-) | ||
that probably shows how cool it is | 18:13 | ||
TimToady | it's invite only | ||
and very off-the-record | 18:14 | ||
no photos or recordings, by policy | 18:15 | ||
[Coke] | You're probably violating the first rule of hackers conference right now. | 18:20 | |
arnsholt | Sounds vaguely like Chatham House rules (or whatever the name for it was) | 18:21 | |
TimToady | [Coke]: undoubtedly :) | 18:25 | |
I don't think the project itself is secret, but perhaps the fact that Guido mentioned it at Hackers is :) | 18:26 | ||
18:27
FROGGS joined
|
|||
nwc10 | no, not secret now. eg pyfound.blogspot.co.at/2015/07/bbc-...nched.html | 18:28 | |
www.bbc.co.uk/mediacentre/mediapacks/microbit | |||
and most intestingly ntoll.org/article/story-micropython-on-microbit | 18:29 | ||
TimToady | "batteries not included" :) | ||
timotimo | moarvm has no chance to run on a slim device :| | 18:30 | |
well, moarvm itself does | |||
rakudo ... not so much | 18:31 | ||
japhb wonders about nqp | 18:52 | ||
18:52
Peter_R joined
|
|||
japhb | Because for the embedded case, that would feel about right. | 18:53 | |
18:54
vendethiel joined
|
|||
TimToady | JimmyZ: you were looking for gist.github.com/anonymous/8efdab238ead35b1d4fa maybe? | 19:02 | |
19:13
sivoais joined
19:25
sivoais joined
19:38
TimToady joined
|
|||
jnthn | TimToady: I don't recall you ruling if you agreed with that gist or not ;) | 20:00 | |
timotimo | jnthn: i was thinking about frames that may have multiple osrpoints and such; wouldn't it make sense to only kick out the osrpoint(s) that actually get hit? because of our logging and stuff? | 20:07 | |
and ... would that work at all? causing an already spesh'd frame to be spesh'd again? | 20:08 | ||
and if it's not worthwhile to keep osrpoints around, perhaps we want to put in something that'd re-spesh after 10x as many rounds, so that we catch many more spesh'd callees on the second try | 20:09 | ||
jnthn | How common is having multiple osrpoints? | 20:11 | |
timotimo | good Q. i was hoping to hear your intuition on it, but i could actually measure it | 20:12 | |
jnthn | My suspicions is "not highly common" | ||
timotimo | i was thinking something like a little loop to prepare data, then a big loop to do stuff | ||
and then the first loop would "steal" the logging phase | 20:13 | ||
timotimo does too much thinking with too little measuring | |||
it's just that i have no answer for the "we spesh outers before our callees get speshed" situation and it bugs me | |||
20:32
kjs_ joined
21:07
Ven_ joined
21:08
Ven__ joined
21:12
kjs_ joined
21:15
synbot6 joined
21:21
Ven_ joined
|
|||
hoelzro | jcdav.is/2015/11/09/More-JVM-Signal-Tricks/ | 21:35 | |
neat trick! | |||
lizmat | m: "\r\n".ords.say | 21:43 | |
camelia | rakudo-moar aaf9fc: OUTPUT«(13 10)» | ||
21:51
Ven_ joined
|
|||
konobi | okay... i checked with the libuv folks... it seems that the compile error is specific to this build | 21:57 | |
ugh... looks like an illumos glitch | 22:05 |