01:28
JimmyZ_ joined
|
|||
JimmyZ_ | FROGGS: I would suggest you using MVM_platform_unlink in MVM_file_delete on Win32, which is more CJK-friendly | 01:30 | |
01:47
ilbot3 joined
02:25
donaldh joined
02:32
jnap joined
03:33
jnap joined
04:34
jnap joined
|
|||
nwc10 | Stage mast : 23867.263 | 04:35 | |
vs | |||
Stage mast : 18504.768 | |||
seems that unaligned MVMint64 matters a little bit | |||
(this is ARMv6) | |||
so, anyway, found a way to save a couple of hours | 04:36 | ||
04:50
hoelzro joined
05:31
FROGGS joined
|
|||
FROGGS | JimmyZ: I'll do that today (in case I don't forget) | 05:34 | |
05:34
jnap joined
06:34
benabik joined
06:35
jnap joined
06:50
FROGGS joined
06:53
zakharyas joined
06:55
domidumont joined
07:36
jnap joined
08:37
jnap joined
09:16
brrt joined
09:37
jnap joined
09:42
zakharyas1 joined
|
|||
nwc10 | but looks like gcc's codegen for ARM is not as good as clang's | 10:11 | |
not totally surprised | |||
a) Apple care about ARM | 10:12 | ||
b) someone said (forget whom, but was competant to say this) that gcc can't really cope with exploiting ARM's condition codes | |||
(hence the Norcroft compiler could generate much better code) | |||
maybe clang was written, aware of what was needed for ARM | |||
10:38
jnap joined
|
|||
brrt | (intel is making me want to buy one of their shiny new processors) | 10:41 | |
tadzik | heh. I rarely buy new CPUs, but when I do, the performance boost is stunning. I don't want to ruin it by buying them too often :D | 10:42 | |
FROGGS | true :o) | ||
brrt | i used to think that the cpu basically never mattered | ||
FROGGS | O.o | ||
tadzik | huh what :) | 10:43 | |
FROGGS | depends on what you are doing | ||
tadzik | I recently bought an SSD for an old computer with P4 in it | ||
it turned out that HDD was not the only cause of the slowness | |||
FROGGS | if you are a gamer, not only the cpu matters... if you a hacker, cpu+ssd matters I think | ||
brrt | tadzik, thats precisely what i found with a netbook i'm using | 10:44 | |
i was reviewing to buy a SSD | |||
tadzik | brrt: that should tell you something about the importance of CPU too :) | ||
brrt | but actually looking at load made clear that it was the CPU that was maxed out much more than actual disk access | ||
actually it is quite passable now that i've switched it over to x64 | |||
that is - for some workloads | 10:45 | ||
tadzik | what's in that netbook, atom? | ||
FROGGS | several atoms perhaps | ||
brrt | yes, single atom | ||
with hyperthreading (which does work to my amazement) | |||
tadzik | so, hydrogen? | ||
tadzik hides | 10:46 | ||
brrt | lol | ||
FROGGS | two netbooks would be hydrogen then | ||
brrt | a proton :-p | ||
tadzik | that'd be H2 | ||
FROGGS | still hydrogen, no? | ||
tadzik | yep | 10:47 | |
FROGGS | if it is H1 then you usually say it is a hydrogen molecule, no? | ||
(at least I do) | |||
brrt | hydrogen atom :-) | ||
tadzik | I guess | ||
FROGGS | or an ion? | ||
gah, I dunno :o) | |||
brrt | an ion is a charged molecule or atom :-) | 10:48 | |
a single H with a single electron would be a hydrogen radical | |||
FROGGS | ahh, of course | ||
tadzik | so I'm using helium which pretends to be berylium... | ||
FROGGS | so now we know: brrt's netbook is a radical when it is plugged in | 10:49 | |
brrt | :-) | 10:50 | |
11:09
avar joined
11:26
domidumont joined
11:39
jnap joined
11:41
domidumont joined
12:13
brrt left
12:40
jnap joined
13:05
LLamaRider joined
13:29
jnap joined
13:45
btyler joined
13:53
benabik joined
|
|||
JimmyZ | FROGGS++ | 13:53 | |
nwc10++, fixed the longstanding x86 building bug | 13:59 | ||
nwc10 | JimmyZ: I wasn't actually *trying* to do that. It was just a happy accident | 14:01 | |
but it seems to have been a very timely happy accident, given Moar Star | 14:03 | ||
JimmyZ | anyway, it's not a easy bug :P | ||
nwc10 | oh no it was not. | 14:04 | |
moritz | well, two weeks ago would've been even moar awesome :-) | ||
JimmyZ | :-) | ||
14:24
donaldh joined
14:41
FROGGS joined
14:50
zakharyas joined
16:05
btyler_ joined
|
|||
TimToady | um, just to set the record straight for posterity, H is a radical only if its electron is missing (or if you could give it an extra electron somehow, which is really hard) | 16:47 | |
one H and one electron is simply a hydrogen atom | |||
well, one proton and one electron, to be more precise | 16:49 | ||
I guess you could say that an H plus an electron is a radical, if you mean H as the atom first, but H+ is the normal radical for H | 16:50 | ||
I suppose the other way to make H- would be to make an antiproton :) | 16:51 | ||
TimToady wanders off to decrease the SNR over on #perl6 instead | 16:53 | ||
19:12
cognominal__ joined
|
|||
dalek | MoarVM/loop_labels: 3eea1e7 | nicholas++ | src/strings/utf8.c: | 19:12 | |
MoarVM/loop_labels: Remove BOM-discarding code from MVM_string_utf8_decode() | |||
MoarVM/loop_labels: | |||
MoarVM/loop_labels: This code is unreachable on a platform where char is signed, because there | |||
MoarVM/loop_labels: utf8[0] will be between -128 and and 127 inclusive, and hence never equal to | |||
19:13
dalek joined
|
|||
timotimo | jnthn: should i think a bit about making "set" operations not show up in the resulting bytecode after spesh if we can re-name the registers instead? | 19:13 | |
i'm thinking a set instead of a decont is pretty cheap, but even cheaper should be no set at all? | 19:19 | ||
jnthn | Right | ||
We probably want to do it in the backwards analysis as we're killing dead instructions. | |||
timotimo | my thoughts exactly | 19:22 | |
especially since i can figure out if the second argument to "set" has only a single use which is the set instruction itself | |||
i'll probably have to handle the facts database properly, otherwise i could upset the backwards analysis somewhat? | 19:23 | ||
jnthn | Well, usages is the main thing we care for at that point | 19:24 | |
If hou're in the backwards analysis you know we alrady optimized all the dominated children. | |||
(We're on our way back up the dom tree) | |||
timotimo | OK | 19:27 | |
19:36
brrt joined
|
|||
timotimo | well. if i'm going to procrastinate away interesting bugs in perl6, i could do worse than to be hunting performance in moarv. | 19:37 | |
moarvm. | |||
so, if we've tossed everything about the dominated children, does that mean i can safely ignore PHI? | 20:11 | ||
jnthn | Well... | 20:13 | |
not really | |||
I mean | |||
The backwards analysis of unused cares about PHIs. | |||
timotimo | then i'll have to actually figure out what phi exactly does ... | 20:14 | |
jnthn | But...wait | ||
You only really need to do your set cleanup within a basic block no? | |||
timotimo | phi is just ... the first argument is the result of merging all following registers, aye? | ||
jnthn | Yeah | 20:15 | |
You can view it as any other sintruction that writes | |||
For the sake of what you're doing here. | |||
brrt | how many registers can be merged in a phi? | ||
or is that nonsense | |||
jnthn | 8.rotate(90) | ||
brrt | :-) | ||
i get it | |||
timotimo | well, the trouble is: if i rename a variable by removing a set, i'll have to make sure it ends up with the proper name in the coming BBs | ||
jnthn | But actually really limited to the number of preds the BB has | ||
timotimo | are the usage counts for registers BB-internal? | 20:16 | |
brrt | i see | ||
how large can a BB grow? and how large are they in practice? | |||
timotimo | you can construct a BB with a million instructions | ||
just don't do anything that branches | |||
i think the maximum size is somewhere lower than a completely unrolled infinite loop. | 20:17 | ||
jnthn | Yeah, it's just a span of instructions with no branches | ||
So in theory, can be rather long. In reality...in most code, > 20 instructions is unusual. | 20:18 | ||
Since you typically end up with a conditional somewhere. | |||
brrt | right | 20:19 | |
timotimo | jnthn: it would seem like all i have to do is go through all code, find all variables that have just been set to something else where the usage of the source is exactly one and then go through the entire code again, replacing every register that has a re-naming done to it to the target (maybe through even more than one re-name) | 20:23 | |
brrt | hmm | 20:25 | |
jnthn | timotimo: oh..hmm | ||
brrt | how do you know when to stop | ||
jnthn | No, I was gonna do it different. | ||
brrt | or - don't you get a rename-DAG | ||
jnthn | I was going to make it so we record in facts the declaring instruction. | ||
And then you can just see usages is 1, than the declaring instruction is a set, and then it's relatively easy. | 20:26 | ||
In fact you can traverse and kill entire set-chains like that. | |||
timotimo | oh, i don't even have to go backwards | 20:35 | |
right, and i shouldn't - otherwise i may have to go multiple times, right? | |||
jnthn | I think you can just do it as part of the existing usage back-propagation pass, no? | 20:38 | |
timotimo | hm, i may be able to do that | 20:40 | |
wait, going in reverse? | 20:41 | ||
ah, that can work if i always fold it to the "later" of the names | |||
hmm. would i have a slot in the facts database for "renamed target" that i can follow until i find a null entry perhaps? | 20:44 | ||
hm. at that point i probably need both the register and its version. i wonder if i get into any time-travel trouble :) | |||
jnthn | No | 20:45 | |
You're making it too ocmplicated | |||
You just need to update facts so it stores the declaring instruction. | |||
Then you can see, for any read, if the thing being read has a usage of 1 (so you're looking at the only read) and if the thing that writes it is a set instruction. | 20:46 | ||
Then you can see if the thing that writes that set instruction is in the same situation. | |||
Just like traversing a linked list until the pattern doens't hold. | |||
Just need to make sure you don't cross BB boundaries | 20:47 | ||
And that the register in question doesn't get re-used in the meantime. | |||
dalek | arVM/spesh_trace: 32074aa | jonathan++ | src/spesh/facts.c: First pass at turning some logs into fact+guard. |
20:52 | |
jnthn | and that patch reveals our deopt ain't up to snuff yet :) | 20:55 | |
wow, my train might actually be about to get me home | |||
And home has beer, and a comfortabler coding environment :) | |||
brrt | wow, swedish trains travel so late? | 20:56 | |
jnthn | brrt: I shoulda been home by now if it wsa on time... | ||
printf("guard missed\n"); | 20:57 | ||
oops :) | |||
detrain...home in 10 or so... & | |||
brrt | fair enough | 20:58 | |
FROGGS | ha! jnthn++ dies alos printf-based debugging! \o/ | 20:59 | |
does* | |||
dang >.< | |||
also* | 21:00 | ||
brrt | is there another way? :-p | 21:01 | |
FROGGS | not for me... but jnthn seems always to smile when I let some debugging code slip :o) | 21:02 | |
brrt | i'm kidding though, i'm a big fan of gdb | 21:03 | |
knowing not yet 5% of all its features | |||
FROGGS | yes, gdb is awesome | 21:04 | |
but currently I hack on nqp-j | 21:05 | ||
brrt | i've used jdb, too, and couldn't figure it out | 21:06 | |
timotimo | hum. | ||
brrt | jdb is ok, but i feel like it hasn't had much attention in favor of graphical / IDE-based debuggers | ||
timotimo | i think i'm brainfarting a bit right now | 21:22 | |
so after the BBs have been removed if they are unreachable | 21:23 | ||
hmm, i'm supposed to save the creating operation in the facts | |||
hmm. if i turn a creating instruction into a different instruction, it'll stay "at the same place", so i can store a pointer | 21:24 | ||
but if it's removed ... hum ... | |||
i may have to take care of that then. though if it's removed the usages should be 0 and i shouldn't have to care about the register any more anyway | 21:25 | ||
jnthn | FROGGS: I do it when the most useful thing is a bunch of data to look over, yeah. | 21:29 | |
FROGGS: Which for me is fairly often. | |||
FROGGS: If it's a SEGV then it's straight over to another tool for the initial analysis. | 21:30 | ||
timotimo | gist.github.com/timo/a8cc59072de640a643c5 ā jnthn, does this look like what you had in mind at all? | 21:34 | |
dalek | arVM: d6a554f | (Timo Paulssen)++ | src/spesh/facts.h: remove duplicate words from from comments |
21:38 | |
jnthn | timotimo: yes, though I'm not sure about the name origin... | 21:41 | |
assigner could work (goes well with ss*a*) | |||
21:42
brrt left
|
|||
timotimo | ah, sure. | 21:44 | |
so, since all we do to "change" all the operations is to assign a different -> info on the instruction, the pointer should be "stable" right? | |||
jnthn | Right | 21:46 | |
timotimo | that's a good start. | ||
i think you said i'm thinking too complicated about this; with the right algorithm, will i have to go through every instruction and rename their operands if they are "out of date"? | 21:47 | ||
jnthn | Hmm | 21:49 | |
22:23
jnap joined
22:26
xiaomiao joined
|
|||
timotimo | i don't like the last word being "hmm" :) | 22:29 | |
nwc10 | timotimo: he said something (innocent, unrelated) to me privately about 20 minute later | 22:30 | |
jnthn | timotimo: soryr, bot distracted :) | 22:31 | |
timotimo | :) | ||
jnthn | uh, got :) | 22:32 | |
hah | |||
Oh...we may be able to get some even simpler way out of this | 22:33 | ||
If we just want to do this in the case we turn a decont into a set, for example | |||
If the decont is the only user of the written thing | |||
e.g. it's | |||
someinstr r1, r0 | 22:34 | ||
decont r2, r1 | |||
And it's that decont we want to eliminate, and r1 has a single usage | |||
Then we can simply delete the decont and then change | |||
someinstr r2, r0 | |||
Which I think will actually handle the majority of cases. | |||
timotimo | i think my thinking and planning capabilities are being hampered by the distance between me and my whiteboard | 22:35 | |
jnthn | Could draw it on your hand? | ||
timotimo | :D | ||
my handwriting is terrible even on paper | |||
i'd expect the effect to be squared if i handwrite on my hand | |||
jnthn | .oO( why'd you think it's called *hand*writing? :P ) |
22:36 | |
timotimo | clearly, there's some language in which "hand" means "bad" | 22:37 | |
22:41
cognominal__ joined
|
|||
timotimo | well, that does sound like something i'd want to be doing in a backwards-running process | 22:42 | |
i'll sleep on it | 22:50 | ||
(and then have a somewhat long drive) | |||
jnthn | sleep well, drive safely | 22:52 | |
jnthn should have a decent tuit supply over the next days | |||
Decided to hack more on things tomorrow when I've more energy, rather than screw stuff up tonight. :) |