github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
05:14 sena_kun joined 05:22 Kaiepi left 05:29 Kaiepi joined 05:30 Kaiepi left 05:31 Kaiepi joined 05:42 Altai-man joined 05:44 sena_kun left 06:13 squashable6 left 06:15 squashable6 joined
nwc10 good *, #moarvm 06:24
06:48 patrickb joined 07:02 leont joined 07:03 domidumont joined 07:38 MasterDuke joined 07:52 zakharyas joined
MasterDuke update on signal handling+setjmp/longjmp. i forgot that i had put `__thread` on the jmp_buf. when i remove it, i don't see any fails in random tests like i did before 08:06
so while this might not be the 100% optimal solution compared to gmp letting us pass in a callback, i think it's a candidate for merging as is (once the building+linking issue is solved) 08:08
08:14 brrt joined
brrt \o 08:16
nwc10 o/ 08:22
MasterDuke tobs: ping 08:31
brrt seems like it's going to be a loooong autumn and winter this year... 08:35
MasterDuke "I'm going to give you a prediction about this winter: It's going to be cold, it's going to be dark, and it's going to last you for the rest of your lives!" 08:37
brrt i'll google that... 08:39
oh, heh :-)
08:46 MasterDuke left 08:49 zakharyas left 08:50 zakharyas joined 09:08 zakharyas left, MasterDuke joined
tobs MasterDuke: pong. 09:12
I was following the gmp error handling talk with one eye here. It doesn't sound very pleasant. 09:14
MasterDuke tobs: i think it's ok. not great, but does seem to work well enough
tobs and the speed gains are worth it, I suppose?
MasterDuke oh yeah
tobs Sorry, I already forgot what tasks my branch are left with. Do you still need it? 09:15
MasterDuke i mentioned yesterday over in #raku-dev that `my ($a; $b; $c; $s); for 66..2_000 -> $e { $a = 23**$e; $b = 7**$e; $c = $a % $b; $c *= $c; $c += $a; $c -= $b; $s = $c.is-prime }; say $s; say now - INIT now` takes ~10s on the gmp branch, ~30s on master 09:16
well, we need to figure out how to actually link against the gmp built by what your branch does 09:17
tobs ah right. The gmp build should be changed to .so, that should be installed in a non-conflicting location, and then linking against it would be no problem (is my hope). 09:18
MasterDuke without having to link against the system one when building moarvm (which is what i think is happening). i can use the one we build via LD_PRELOAD when running raku after moarvm is built, but that's obviously not how it should happen
well, none of our other 3rdparty libraries use a .so. that may have been a red herring, making that change may have meant it picked up my system gmp, not actually using the .so we built anyway 09:19
tobs oh, could be... 09:20
so, this is my first free weekend since the branch got started. I'll put this on top of my list. 09:23
MasterDuke awesome, thanks
github.com/MasterDuke17/MoarVM/tre...figure-gmp is my work on top of your branch. it should pass all but one spectest (the one that unexpectedly lives because gmp can handle a bigger number than tommath) 09:25
09:26 zakharyas joined
tobs (I took on some extra paid teaching duties at the university. Normally that wouldn't have been a big deal, but boy is digital teaching something else. It took an unexpected amount of time.) 09:26
oh cool 09:27
MasterDuke github.com/MasterDuke17/MoarVM/com...6a7cae320f is the only commit that touches the build stuff you did, but i think the .so changes in it shouldn't be done/needed 09:28
MasterDuke has never been a professional teacher and doesn't think online-only would work well with my (definitely unpolished) teaching style 09:29
brrt: does this change look ok? github.com/MasterDuke17/MoarVM/com...2610-R2613 the C version is changing `foo->used > 0` to `mpz_size(foo) > 0` 09:31
brrt MasterDuke: I'll try to have a look for you 09:33
MasterDuke thanks
brrt oh, no, that's not okay
you do a `mov TMP4, [TMP1+offset]` and while I've forgotten exactly what TMP4 and TMP1 are - they are both volatile / caller-save registers 09:34
MasterDuke hm. i didn't change that line though...
09:35 zakharyas1 joined, zakharyas left
brrt actually... 09:35
actually it's okay.
because you *do* clobber the registers but you don't use any afterwards 09:36
MasterDuke i just noticed it could be simplified though, couldn't those first two lines now be `mov ARG1, MPINT:[TMP1 + offset];`? 09:37
brrt I'm not 100% sure why we use the MPINT
MasterDuke instead of `mov TMP4, [TMP1 + offset]; mov ARG1, MPINT:TMP4;`
brrt yeah, that's fine 09:38
though I should note
ARG1 is rcx on windows, TMP1 is also rcx on windows *and* posix
(giving names to registers was not one of my best moves in hindsight)
09:39 zakharyas1 left
MasterDuke so should be using a different TMP in the whole thing? 09:39
brrt nah, it doesn't matter, you can overwrite rcx with rcx just fine 09:40
MasterDuke k 09:41
brrt a minor comment of the type 'this clobbers registers but they are not read afterwards' would also be good
09:41 zakharyas joined
MasterDuke should also fix the comment a line or two above that mentions `a->used`. will do, thanks for looking 09:42
09:43 sena_kun joined 09:45 Altai-man left
brrt :-) 09:45
09:47 lizmat_ joined 09:48 lizmat left, lizmat_ is now known as lizmat
MasterDuke huh. i just changed 'MPINT' to 'MPZ' everywhere (including in the list of type declarations), but now it's complaining `error: ‘MPZ’ undeclared (first use in this function)` 09:50
lizmat perhaps the first MPINT was declared via a command-line option? 09:51
MasterDuke don't think so, grep says that was the only place the string 'MPINT' existed 09:53
oh, its just the `LABEL:[TMP1 + offset]` syntax it doesn't like 10:01
10:18 domidumont left 10:28 scovit joined
scovit Hi MasterDuke, I was curious and I checked you gmp patch. I wonder why you decided to pass all mpz_t using pointers, since as far as I remember, that is a reference type 10:31
a one element array 10:33
MasterDuke i don't remember. maybe just so i could s/mp_int/mpz_t/g and convert all the declarations? 10:36
but thanks for the reminder, i was going to see if there was a difference changing them to not be pointers 10:37
scovit probably most of the time the compiler optimizes those details out 10:38
the win would be if you can save some mallocs 10:39
like in struct MVMP6bigintBody, do you know what is sizeof(mpz_t)?
if it fits in 64 bits, that is clearly a win
you are welcome :) 10:40
MasterDuke sizeof(mpz_t) == 16 10:44
scovit oh, then it might be a win or not 10:45
also the flag trick would need to be reworked 10:48
maybe one could just get rid of it and simplify the code since gmp might already have good optimizations for small numbers 10:49
MasterDuke i tried that in one or two places, and our smallint code was still faster. but i didn't simplify the structure or anything 10:54
scovit I'm checking gmp.h , the smallint code will be faster because they don't do such an optimization. Theretically one could bump the smallint to 64 bit and use the same trick on the `mp_limb_t *_mp_d;` pointer field as flag. 10:55
but that means that moarvm becomes aware of gmp internals. And I am not sure that is a totally portable idea. 10:56
you also end up paying 64bit for each extra small int 10:57
but you save a malloc for each big int 10:58
if most smallints fit in 32 bit, you win with the current code. If they fit in 64 bit you would win with the new one 10:59
lizmat since ints are being used for indexing, I'd say that most smallints fit indeed in 32 bit generally 11:03
also: the regex engine is full of tiny ints :-) 11:08
MasterDuke some quick and dirty stats when compiling CORE.c.setting: all 1762 times store_int64_result() was called it fit in 32bits. when store_bigint_result() was called, 54 times it was big, 2243 times it was small 11:09
obviously those numbers would be different if doing some large math instead of compiling 11:10
lizmat so I gather this excludes native ints then :-)
MasterDuke right, i assume *_i ops generally wouldn't hit this code 11:11
lizmat ok, then disregard my mention of the regex engine :-) 11:12
11:24 brrt left 11:27 zakharyas left 11:37 scovit left 11:49 Kaiepi left, Kaiepi joined 12:17 zakharyas joined 12:49 domidumont joined 13:03 zakharyas1 joined 13:04 zakharyas left 13:33 brrt joined 13:42 Altai-man joined 13:44 sena_kun left 14:01 zakharyas1 left 14:27 lucasb joined 14:55 patrickb left 14:57 Kaiepi left 14:58 Kaiepi joined, zakharyas joined 15:11 zakharyas1 joined 15:15 zakharyas left 15:30 Kaeipi joined 15:31 Kaiepi left, domidumont left 16:47 Kaeipi left, Kaiepi joined 16:50 Kaiepi left, Kaiepi joined 16:58 brrt left 17:04 zakharyas1 left 17:22 Altai-man left, sena_kun joined 18:13 Ven`` joined 19:00 patrickb joined 19:05 Ven`` left 19:06 Ven`` joined 19:08 Ven`` left 19:15 Ven`` joined, vrurg joined 19:17 vrurg_ left 19:18 vrurg left 19:20 vrurg joined 19:23 patrickb left 19:30 patrickb joined 20:19 zakharyas joined 20:29 Ven`` left 20:30 sena_kun left 20:38 zakharyas left 21:11 Kaeipi joined 21:12 Kaiepi left 21:43 Merfont joined, Kaeipi left 21:49 patrickb left 21:59 patrickb joined 22:35 Merfont left 22:36 Merfont joined 22:54 patrickb left 22:59 ggoebel joined 23:32 Merfont left 23:33 Kaiepi 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!