|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:00
reportable6 left
00:02
reportable6 joined
|
|||
| Geth | MoarVM: 7e190207bf | (Timo Paulssen)++ | src/gc/orchestrate.c log gc start a little later to fix profiling |
00:49 | |
| MoarVM: 5b174f5286 | (Timo Paulssen)++ | src/spesh/args.c allow param_*_ins ops to spesh when Int/Num/Str present also puts comments in the spesh log when argument-based specialization bailed out due to one of those. |
|||
|
02:07
anatofuz joined
02:09
anatofuz left
02:10
anatofuz joined
02:16
anatofuz left
02:45
anatofuz joined
03:14
anatofuz left,
anatofuz joined
03:41
anatofuz left
04:07
squashable6 left
04:09
squashable6 joined
05:07
lizmat left
06:00
reportable6 left
06:03
reportable6 joined
07:45
zakharyas joined
07:55
discord6 left,
discord6 joined,
discord6 left,
discord6 joined
08:43
tbrowder left,
mtj_ left
08:45
kawaii left
08:46
kawaii joined
08:47
tbrowder joined,
mtj_ joined
09:22
brrt joined
09:46
squashable6 left
|
|||
| Guest37021 wonders if jnthn is back from Latvia | 09:47 | ||
| jnthn | Yes, got back home yesterday evening, and now having first day at the office in 2 weeks and trying to take care of all the things that need taking care of after that. :-) | 09:48 | |
| While simultaneously wishing I was still asleep... :) | |||
| nwc10 | coffee machine is operational? | ||
| Guest37021 | coffee might help a bit :) | ||
|
09:49
squashable6 joined
|
|||
| nwc10 | beer fridge is not having a "dry day"? | 09:49 | |
| jnthn | It seems I foolishly drank most of the beer fridge's content before my trip, which might make for an enforced "dry day" :P | 09:53 | |
| Depends if I can be bothered to go to a shop or something | |||
| The coffee machine is very much operational, and worked perfectly. Perhaps because I carefully cleaned it before my two weeks away :) | 09:54 | ||
| nwc10 | jnthn in "not stupid" shocker | ||
| Guest37021 | sounds like jnthn has things under control | 10:07 | |
| brrt | ohai nwc10, jnthn, Guest37021 | 10:45 | |
| Guest37021 | hello brrt | 10:47 | |
|
11:29
brrt left
11:31
pamplemousse joined
|
|||
| timotimo | hoping my latest commit will get a little bit of real-world testing :P | 11:31 | |
| Guest37021 | timotimo: shouldn't you have moved the heap profiler calls while you were making changes to orchestrate.c :) | 11:56 | |
| timotimo | oh, i should have? | 11:58 | |
| that wasn't committed yet, then? %) | |||
| Guest37021 | nope, that dogbert guy can't be trusted :) | ||
|
11:59
brrt joined
|
|||
| Guest37021 | or do we need to ask jnthn which piece of code in finish_gc wakes the spesh thread? | 11:59 | |
|
12:00
reportable6 left,
reportable6 joined
|
|||
| brrt | why ask when you can read code? | 12:01 | |
| Guest37021 | but it's c code :) | 12:03 | |
| could it be around this line perhaps: github.com/MoarVM/MoarVM/blob/mast...ate.c#L193 | |||
| timotimo | we don't have to ask, it's the same piece of code that wakes all threads | ||
| brrt | C is a fairly simple programming language :-) | ||
| timotimo | there's nothing special about the spesh's thread's handling of GC | 12:04 | |
| it used to be that it's just always blocked, because we just tried to never ever gc while in spesh | |||
| but now it's a regular thread that just hits the GC_SYNC_POINT every now and then | 12:05 | ||
| Guest37021 | ok, so we move it to before line 187 then | ||
| AlexDaniel | brrt: reminds me of that one time I was listening to someone's thesis defence. Basically, the guy created some sort of tooling for teaching/learning C, mostly for those who didn't have previous programming experience. One of the questions was someone wondering if it's a good idea to teach C as the first language, to which he replied “if it turns out that C is not simple enough for that purpose we can do the same for assembly” | 12:16 | |
| brrt | AlexDaniel: assembly is, in fact, substantially simpler :-D | ||
| C just has a few more affordances | 12:17 | ||
| create comforts like structs | |||
| pamplemousse | The class I TA-ed in college actually did that-ish. It was the second class you would take as a CompSci major. We started with logic gates, moved to a toy assembly language, and then to C. It worked pretty well, I think | 12:19 | |
| timotimo | going via the logic gates probably puts people in the right headspace to grasp why assembly works the way it does | 12:23 | |
| pamplemousse | Mmhm. And teaching assembly before C really helped people understand pointers better | 12:36 | |
| timotimo | i can totally see that | 12:40 | |
|
12:46
lucasb joined
|
|||
| timotimo | hm. band_Ii could totally be a thing; if you know one of the operands is a small number, you can do the arithmetic by only looking at the smallest few "digit"s of the big number | 12:52 | |
| i'm saying this because i'm seeing a piece of code that does bignum arithmetic without needing to ... | 12:54 | ||
| jnthn | timotimo: Probably soemthing to let the EA handle | 12:57 | |
| timotimo | aaw, no! not a double-free or corruption error :< | ||
| i'm giving the loop block a native int parameter now, that should make things much better | 12:58 | ||
| ah, i wasn't using the latest version of Compress::Zstd (because i didn't install it system-wid) | |||
| nice. using a uint64 $_ parameter got it to become a band_i, it didn't even have to go and inline a sub for this purpose; possibly the static optimizer inlining the simple operator for me | 13:05 | ||
| even the pushes into the native arrays have beautifully turned into push_i instructions without much stuff around them | 13:08 | ||
| there is also a block marked "Inlined" without instructions, i think that belongs to a "sink" call :D | 13:11 | ||
| now if instead of iterating over that native array i just loop while the array isn't empty and shift off it, that could make it a bunch faster again, since no invocations are needed any more | 13:16 | ||
| # inline-preventing instruction: getlexstatic_o | 13:25 | ||
| # could not inline 'shift' (5860) candidate 0: target has a :noinline instruction | |||
| interesting | |||
| that is the getlexstatic to get &die for the "cannot shift from empty array" exception | 13:26 | ||
| i assume that if i had used .shift on an empty uint64 array a bunch of times before, it'd have been turned into a wval instead and the inline could have succeeded | 13:27 | ||
|
13:37
brrt left
|
|||
| timotimo | could move that piece of code off into a private method that doesn't take any parameters | 13:47 | |
|
14:01
zakharyas left
14:15
brrt joined
14:42
squashable6 left
14:44
squashable6 joined
14:57
brrt left
15:18
pamplemousse left
15:44
zakharyas joined
15:50
pamplemousse joined
15:51
brrt joined
15:55
pamplemousse left,
pamplemousse joined
16:20
brrt left
16:23
zakharyas left
16:42
squashable6 left,
squashable6 joined
16:53
japhb joined
16:56
chloekek joined
17:52
squashable6 left
17:56
squashable6 joined
18:00
reportable6 left
18:02
reportable6 joined
18:03
sena_kun joined
18:46
brrt joined
19:03
lizmat joined
|
|||
| brrt | \o | 19:08 | |
| timotimo | o/ | 19:13 | |
| MasterDuke | timotimo: did your optimization end up being noticeable? | 19:18 | |
| timotimo | my computer is too busy with other random crap to give me good measurement results :( | 19:19 | |
| MasterDuke | oh well. i have to wait until the 5.3 kernel for perf to work again | 19:21 | |
| timotimo | ouchies | 19:55 | |
| "my uint64 $i = $native-array.shift" now turns into a sequence of shift, sp_fastbox_bi_ic, decont_i, hllboxtype_i + box_i, hllize, decont_u | 19:57 | ||
| though the decont_u could actually be from the usage of $i rather than the assignment | |||
| pamplemousse | o/ | 19:58 | |
| timotimo | but still, ouch. | ||
| oh, no, after the decont_u, there's actually the sp_bindlex_in that puts the value in the lexical | 19:59 | ||
| oh yeah, and what happens next? it grabs the lexical and coerces it from signed to unsigned | 20:00 | ||
| japhb | >.< | ||
|
20:01
sena_kun left
|
|||
| timotimo | more improvements to PEA would make this better | 20:01 | |
| i think so, at least | |||
| japhb | There's still a bunch unmerged, isn't there? | ||
| timotimo | i think there is something | 20:02 | |
|
20:02
chloekek left
|
|||
| MasterDuke | is it any better if you use int64 instead of uint64? aren't uints in general pretty much completely broken? | 20:04 | |
| timotimo | not really better, no | 20:08 | |
| i haven't a clue why the decont_i isn't optimized here, either. shouldn't the resulting type of hllize be known there | 20:10 | ||
| oh, because it doesn't realize the exception throw in shift won't return a value back | 20:11 | ||
| so it can't rely on the return value being an int | 20:12 | ||
| d'oh | |||
| MasterDuke | is that a systemic problem? is it causing lost optimizations all over? | 20:13 | |
| timotimo | in one or two places maybe | 20:15 | |
| or maybe much more | 20:16 | ||
| hard to tell, really | |||
| MasterDuke | one or two in your code specifically? or would this be a problem for lots of random code (e.g., anything that uses any function with a return value and a possibly thrown exception)? | 20:20 | |
| timotimo | really mostly just those that use a blah ?? exception !! real-result shape | 20:21 | |
| i think the function i've been trying to optimize didn't take a lot of time in the first place | 20:34 | ||
| but it was an interesting place to look moar/rakudo performance wise | |||
| nah, it still took many seconds | 20:36 | ||
|
20:42
brrt left
|
|||
| timotimo | i think i mostly got aware of it because it had lots of allocations? | 20:42 | |
| MasterDuke | but it still had a bunch after your fix this morning? | 20:43 | |
| timotimo | i'm not sure actually | ||
|
20:47
brrt joined
20:51
brrt left
21:24
pamplemousse left
22:42
pamplemousse joined
22:55
pamplemousse left
23:13
pamplemousse joined
|
|||