00:01 colomon joined 00:13 cognome joined 00:16 cognome joined 00:17 cognome_ joined 00:44 cognome joined 00:45 cognome_ joined 01:01 lizmat_ joined 01:18 camelia joined 01:46 cognome joined 02:01 colomon joined 02:13 colomon joined 02:17 JimmyZ joined
JimmyZ Hello, what is callsite intern? 02:19
02:33 colomon joined 02:46 cognome joined 02:50 mlilenium_ joined, mlilenium_ left 03:03 JimmyZ_ joined 03:46 cognome joined 03:54 cognome joined 04:45 ggoebel1111118 joined 04:46 cognome joined 05:46 cognome joined 06:28 JimmyZ_ joined
nine TimToady: sudo cpupower frequency-set -g performance # gives stabler benchmark numbers 06:34
JimmyZ cpupower doesn't exist on ubuntu ... 06:35
ok, installing it. 06:37
nine An alternative would be: sudo cpufreq-set -g performance 06:38
JimmyZ hmm , I didnt' see -g performance in the man page :( 06:44
06:46 cognome joined
timotimo JimmyZ: we only generate (or look for?) spesh candidates when we invoke something if the callsite has been interned 06:54
interning means we stash the callsite in our interning array and have made sure that the pointer points to the interned callsite rather than the one we may have just created
okay, so stuff for today: 06:57
- look more closely at how we spesh decont and maybe turn deconts on known container types into a direct pointer lookup 06:58
- look more closely at assign and maybe turn assign into assignunchecked and perhaps even into a direct pointer assignment
oh, also: a decont on a code-ish container type (the proxies) could become an invoke directly and then we could inline the little piece of code it has in BOOTSTRAP.nqp 06:59
07:01 Ven joined
JimmyZ other quesiont: I see calliste is intened after deserialization, can we intern the callsite before serialization? :0 07:02
that is, seriallize the interned calliste :P 07:03
timotimo - run some proper tests to see if (or why not) the invocations from all over our c code get treated by spesh at all 07:05
07:06 zakharyas joined 07:13 kjs_ joined 07:46 cognome joined 08:04 _sri joined 08:07 _sri joined 08:23 lizmat joined 08:36 woolfy joined 08:46 cognome joined 09:08 FROGGS joined 09:09 Ven joined 09:27 kjs_ joined 09:46 cognome joined 09:53 cognome joined 10:13 flaviusb joined
timotimo guess what was wrong with my trigonometry? 10:32
i was using the atan function to implement the atan2 op
jnthn It's broken 'cos you comitted a sin 10:33
tadzik *g*
dalek arVM: eb73c5e | (Timo Paulssen)++ | src/jit/graph.c:
atan is a very poor implementation for atan2.
tadzik even the argument list is different :D 10:34
gotta love gotos
timotimo wtf. 10:47
what, argument list?
OH FFS
thank you
tadzik :) 10:48
well, you already fixed it anyway, I think?
timotimo something else is wrong, too 10:49
why is this still wrong >:( 10:50
ah doh
no, damn, i ah'd too quickly
dalek arVM: a71fb99 | (Timo Paulssen)++ | src/jit/graph.c:
atan2 actually takes two arguments.
 10:53
timotimo this is still wrong :(
tadzik: tell me what i'm doing wrong :(
i'm staring at the code and can't see what is wrong 10:54
tadzik I woke up at 5 today, I can't help anyone with anything :)
timotimo :| 10:55
11:34 kjs_ joined
dalek arVM: ca1f3b2 | (Timo Paulssen)++ | src/jit/graph.c:
fix atan2 op; ven++ for tracking this down
 11:40
timotimo how the fucking fuck can this fix it? 11:41
Ven \o/ I fixed it. 11:42
dalek arVM: 641391a | (Timo Paulssen)++ | src/jit/graph.c:
Revert "fix atan2 op; ven++ for tracking this down"

This reverts commit ca1f3b26eaf465880a122d66a43efc5c921d000a.		 11:51
timotimo something must have been in a weird state before i committed ca1f3b2 12:04
because that commit was apparently not necessary
12:04 brrt joined 12:12 JimmyZ joined 12:23 jnthn joined 12:24 nine joined 12:37 brrt joined 12:43 daxim joined
dalek arVM: 256554b | (Timo Paulssen)++ | src/jit/graph.c:
fix atan2 and friends for real this time; jnthn++ and nwc10++
 12:55
jnthn tries building that 12:56
13:04 kjs_ joined
brrt yeah, that's a good idea timotimo :-) 13:17
that should work a bit better
dalek arVM: 03ac9a7 | (Tobias Leich)++ | src/io/syncfile.c:
implement set_separator for syncfiles
 13:21
nwc10 timotimo++ # fixed 13:30
timotimo "a bit"? %) 13:35
i think it only passed the spec tests on my machine because the right input arguments happened to have been put onto the "floating point stack"-like thing before by other ops (like unbox_n or something)
brrt that happens often 13:37
that can be a really annoying way to mask bugs
in fact
i have a blog post about just that
timotimo oh damn 13:38
i seem to recall reading that
brrt :-) 13:41
timotimo it's especially annoying because the day before i tried to build neg_n
and had to use the special movsd or whatever instruction
(also, it didn't work out)
brrt no, neg_n is hard
JimmyZ looks like some ops which calls MVMROOT is a bit hard to jit, except wrapping them to function? 13:42
JimmyZ hopes we can jit the MVMROOT too :P 13:43
brrt hmmm 13:44
let me think about that for a bit
JimmyZ i.e: add_I etc..
13:45 kjs_ joined
brrt but yeah... in the general case wrapping-to-function is not going to cost you /that/ much 13:45
JimmyZ these ops avoids a MVROOT, by using REGS, since gc updates REGS address.
brrt yeah, i don't think they need a MVMROOT 13:47
hmm 13:49
basically, this is for stack-variables mostly 13:50
i don't really do that often
14:05 kjs_ joined 14:10 lizmat joined 15:29 brrt joined 15:40 woolfy left 16:00 woolfy joined, woolfy left, lizmat joined 16:01 kjs_ joined 16:28 cognome joined 20:46 FROGGS joined 20:48 Ven joined
timotimo we could block sigterm with sigprocmask and check for sigterm in the "main thread" and get an actually useful stack trace like people who come from python are used to. 21:02
except signal(SIGTERM) doesn't wrok 21:03
work
21:28 brrt joined
brrt ok, numeric negation is just xor with the highest possible byte 21:44
22:06 camelia joined
dalek arVM: e75de84 | (Bart Wiegmans)++ | src/jit/ (2 files):
Add numeric negation
 23:13
23:13 brrt left 23:38 cognome joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!