github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 05:57
nwc10 had hoped someone else would try it (the branch) 08:06
good *, leont
leont Hi nwc10 :-) 08:52
nwc10 This is MoarVM version 2014.08-108-g93d47dd 10:00
that's a bit old.
nine I'd call it a pretty young MoarVM 10:05
nwc10 I built a new one
nwc10 * nom 10:14
Oh, that will be my problem...
dogbert17 checks out 'XXX-A-Better-Hash' ... 10:53
nwc10 it *is* safe for work. that's not what the XXX was about. It was more "FIXME-before-merging" 10:57
dogbert17 :-) 11:00
no errors found during a normal stresstest run 11:03
nwc10 OK, so it builds and works on big endian PPC64 and PPC32 13:54
dogbert17 nwc10: I have tried your branch on my RPi 4 and spectest was happy 13:55
nwc10 I tried it on mine, and it doesn't fail any new tests 13:56
but we seem to be making x86_64 assumptions about floating point
(thanks)
dogbert17 yes, one test always fails on my RPi, i.e. t/spec/S02-types/num.t
have tried to break the branch on my PC so far without success :) 13:57
nwc10 IIRC they break on an x86 built 13:58
build
I did that with -m32 a while back - real x86 VMs are too slow
dogbert17 I have a 32bit Linux VM
nwc10 my mail is on a friend's 32 bit linux VM 13:59
IIRC it's single core
dogbert17 it isn't what I have used while testing though
nwc10 "my" machine, with 24 x86_64 cores, building -m32, is 24 cores of x86
dogbert17 24 cores, impressive
nwc10 apparently it's going to be replaced. It's a former production server, and it's 10 years old. 14:00
so it must have been good when it was new
dogbert17 it was probably expensive as hell when it was bought
nwc10 this was my assumption too, but it predates me 14:01
dogbert17 asan is happy with your branch as well 14:03
nwc10 ooh, this one is a bit less old: This is MoarVM version 2015.12-31-ge2d6f75 14:12
brrt 2015? :-o 14:23
nwc10 yes, I figure that checkout dates from when I looked into the big endian stuff. As a bit of an encore from bending my brain into getting MoarVM working on ARM (32 bit, that is) without breaking x86_64 or x86 14:25
the fun being C compiler alignement rules
and how (nine reminds me) Mast was generated in a different way
nwc10 "bit less old" probably means that logged into the machine when it was new-ish, and just tried thing sout 14:26
oh, we don't built on sparc64 (no AO_fetch_compare_and_swap) 14:36
and not on sparc32 - this one is more wierd: 14:37
3rdparty/libtommath/tommath.h:80:1: error: unable to emulate 'TI'
80 | typedef unsigned long private_mp_word __attribute__((mode(TI)));
| ^~~~~~~
that's a bother. sparc is excellent for hating code with bad alignment assumptions. 14:38
dogbert17 XXX-A-Better-Hash does improve performance, at least during the parsing stage and spectest and probably elsewhere as well, very nice 20:33
nwc10 :-) 20:35
with dumbbench I measured a 2% speedup in 'say "Hello world"' but that's probably not a great claim to advertise 20:36
dogbert17 I got the rakudo parse stage down to under 39 seconds, that's a first for me 20:44
is is usually around 41+ seconds 20:45
s/is/it/ 20:46
MasterDuke nwc10: src/6model/reprs/MVMHash.c: In function ‘MVMHash_gc_mark’:src/gc/worklist.h:93:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] 93 | if (*item && !( (*(MVMCollectable**)item)->flags & MVM_CF_SECOND_GEN)) { \src/6model/reprs/MVMHash.c:66:13: note: in expansion of macro 22:09
‘MVM_gc_worklist_add_no_include_gen2_nocheck’ 66 | MVM_gc_worklist_add_no_include_gen2_nocheck(tc, worklist, &current->hash_handle.key);

Powered by Cro and the Raku® Programming Language.

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

Thank you!