|
03:09
vendethiel joined
|
|||
| dalek | MoarVM: db1f759 | hoelzro++ | src/core/callsite.h: | 06:38 | |
| MoarVM: Change MVM_callsite_num_nameds to take a const MVMCallsite | |||
| MoarVM: | |||
| MoarVM: MVM_callsite_num_nameds doesn't need to change the given callsite, | |||
| MoarVM: so we can have the compiler guarantee that so no mistakes are made | |||
|
06:38
dalek joined
06:56
domidumont joined
07:01
domidumont joined
08:12
FROGGS joined
08:38
Ven joined
08:46
zakharyas joined
09:07
kjs_ joined
09:50
brrt joined
|
|||
| brrt | good * #moarvm | 09:50 | |
| nwc10 | good *, brrt | 09:51 | |
| brrt | good * nwc10 | ||
| in the region of the topic of jits, and especially pypy... | 09:52 | ||
| i recently claimed that i got a 5x speedup on a pypy program compared to a python program | |||
| well, i implemented an improved algorithm that runs in O(n log n), rather than O(n^2) | |||
| nwc10 | and now your office is much colder? | 09:53 | |
| brrt | not only is cpython now faster than pypy original; cpython is faster than pypy, period | ||
| nwc10 | and quieter | ||
| brrt | yes.... | ||
| algorithms always win from runtime speed, it seems | |||
| nwc10 | OK, odd. If pypy can win on the inefficient algorithm, why can't it also win on the efficient algorithm? Does it now never hit a JIT path? | 09:54 | |
| brrt | it just runs too fast | ||
| the original algorithm did a million comparisons, this one just a few thousands | 09:55 | ||
| btw, wrt to the illumos build failure, i have a simple and stupid suspicion | 09:59 | ||
| my suspision is that a): lua and minilua use scanf and friends for parsing formats; | 10:00 | ||
| b): illumos / solaris scanf doesn't understand negative hexadecimals | |||
|
10:09
dalek joined
|
|||
| arnsholt | I got a 10x (or more, I suspect, for larger problems) using PyPy. But that problem is inherently O(n^2) or thereabouts, so no algorithm win to be had =) | 10:19 | |
|
10:51
brrt joined
11:39
Ven joined
13:22
kjs_ joined
13:35
dalek joined
14:29
Ven joined
14:56
Hotkeys joined
16:51
domidumont joined
16:57
domidumont joined
16:58
domidumont joined
17:12
FROGGS joined
|
|||
| diakopter | omg | 17:55 | |
|
17:58
vendethiel joined
|
|||
| timotimo | OYG? | 17:58 | |
|
18:11
psch joined
18:30
Hotkeys left
18:35
dalek joined
18:39
kjs_ joined
|
|||
| diakopter | timotimo: it's just, core setting compilation spends 6.6% of time in the MVMHash repr ops | 18:49 | |
| timotimo | yeah, we use hashes in a big portion of things | 18:50 | |
| diakopter | -_- # lolz | ||
| timotimo | have you tried using --target=<different values> to find out what parts add what amount of stuff where? | ||
| that may be interesting to know | |||
| diakopter | no, that's a stellar idea; I'll try it | 18:51 | |
| timotimo | also, does leaving out the optimizer with --optimize=off remove a big chunk of hashes or is it the same overall? | ||
| diakopter | timotimo: what's your theory there | 18:53 | |
| timotimo | the optimizer digs around a whole bunch in symbol tables and it also uses some hashes to store information about what things have what properties | 18:54 | |
| diakopter | actually most of the hash usage seems to occur during parsing | ||
| do we dedupe strings on compunit compilation | 18:56 | ||
| (I don't remember!) | |||
| timotimo | yes, we have a string heap that is backed by a hash to do just that | ||
| diakopter | oh yeah. | 18:57 | |
| and now I remember [re-?]implementing it. O_O | |||
| yeesh, seems uthash has fallen behind in the latest benchmark comparisons | 19:04 | ||
| timotimo | oh? | 19:05 | |
| i don't know how exactly we do our hashing with the new grapheme stuff, tbh | |||
|
19:25
leont joined
|
|||
| japhb | diakopter: Link to said benchmarks? | 19:26 | |
| diakopter | www.tommyds.it/doc/benchmark is the one I looked at most recently | 19:27 | |
| I guess it's not that recent | 19:28 | ||
|
19:32
kjs_ joined
21:08
kjs_ joined
21:15
diakopter___ joined
22:58
FROGGS joined
23:12
FROGGS joined
23:32
FROGGS joined
|
|||