01:44
tokuhiro_ joined
02:16
tokuhiro_ joined
02:23
FROGGS_ joined
02:51
Util joined
|
|||
dalek | arVM: b3d0345 | hoelzro++ | src/ (4 files): Restore "Track whether or not a capture owns its callsite" This reverts commit 9befd69353643bff3a529aa5bea8101cd574fa29. |
03:31 | |
arVM: 132f390 | hoelzro++ | src/core/args.c: Just check arg_flags to know whether or not to get rid of them One, arg_flags should know best. Two, checking the callsite object is checking an object we don't own, and may be invalid by this point in the program. |
|||
03:46
vendethiel joined
06:23
TimToady joined
06:56
domidumont joined
07:01
domidumont joined
07:08
FROGGS_ joined
07:34
TimToady joined
|
|||
nwc10 | hoelzro++ # ASAN approves | 07:50 | |
(UTF-16)-- # with the best "features" of UTF-8, the best "features" of UCS-32, some special features of its own - no wonder ASAN hates it :-) | 07:51 | ||
08:49
zakharyas joined
09:01
kjs_ joined
09:37
kjs_ joined
11:31
brrt joined
|
|||
nwc10 | hi brrt | 11:45 | |
I found some things. hhvm.com/blog/10205/llvm-code-generation-in-hhvm | |||
... Ultimately, we decided to not deploy the LLVM backend to production for now. Making such a large change across the whole web fleet always comes with risk, and without a performance improvement to justify the risk it’s not worth it. | |||
but also, this one made me wonder "oh geez, is this crazy or inspired?" -- Modifying code that may be running in another thread is a core part of HHVM’s design. | 11:46 | ||
meanwhile, I noticed that on www.zend.com/en/resources/php7_infographic they are happyly showing (er, choosing) graphs that show PHP7 to be faster than HHVM | |||
HHVM 3.7.0 | |||
current HHVM is 3.10.10 and between the two we had hhvm.com/blog/9293/lockdown-results...erformance | 11:47 | ||
-- During lockdown we achieved a 19.4% RPS improvement for MediaWiki workloads, and a 1.8% RPS improvement for WordPress. We demonstrated that HHVM is 55.5% faster than PHP 7 on a MediaWiki workload, 18.7% faster on a WordPress workload, and 10.2% faster on a Drupal 7 workload. | |||
so I wonder how fast PHP7 is compared with "this week"'s HHVM | |||
and if Zend are stuffed | |||
(well, unless you want to run PHP on non x86_64, because, for example, ARM is interesting) | 11:48 | ||
11:48
ziggypup joined
11:49
ziggypup left
|
|||
brrt | hi nwc10 | 12:13 | |
(i was off for lunch) | |||
nwc10 | ilmari: ^^ :-) | 12:14 | |
hi brrt | |||
brrt is reading about that page | 12:15 | ||
i recall rurban saying good things about php7 | |||
at least with regards to speed | |||
brrt is thinking of switching blogging platforms, but then recalls that he doesn't care about managing websites | 12:22 | ||
timotimo | jnthn: i think the only thing i'd need to change to make ordat not leak synthetics is use MVM_string_ord_basechar_at instead of MVM_string_get_grapheme_at - nqp::ordfirst also uses get_grapheme_at and thus probably wants to be changed as well. | 12:25 | |
brrt | nwc10: very interesting. they're doing pretty much everything like how we're doing the moar-jit | 12:31 | |
i do have to ask | |||
do my blog post come of as boasting in the same way this one does? | |||
i mean, they almost *want* to make it sound difficult and complex and Serious Engineering | 12:32 | ||
timotimo | i don't think your blog posts sound overly boasting | 12:33 | |
brrt | oh, right, this is facebook, that .. explains? :-P | 12:34 | |
timotimo | huh? what is facebook? | 12:35 | |
oh, the hhvm people | |||
nwc10 | brrt: I believe that a team of them have been workign on HHVM for several years | ||
and I got the impression that facebook tries really hard to only hire smart folks | 12:36 | ||
so they probably think that it's hard because they are finding it hard | |||
but also, they do need to make legacy code go fast | |||
rather than (re)designing the language if something turns out to be hard/impossible to make fast | 12:37 | ||
brrt | hmmm.... | 12:38 | |
yeah, i think that the whole problem of making (legacy) dynamic language code go fast is slowly proving more difficult than anybody imagined | 12:39 | ||
fwiw, i'm currently using pypy for Real Work, and it is a good 5 times faster on my (evil O(n^2)) algorithm | 12:40 | ||
i'm stuck with python because $people | |||
nwc10 | presumably $people are on 2.7 - do they have a plan to migrate? | ||
brrt | my personal plan is to write everything py3 compatible | ||
timotimo | pypy is fantastic. i'm willing to say that over and over again :) | ||
brrt | python is a pretty good language at any rate :-) | 12:41 | |
not to say i don't miss perl, but the meanest thing i can think of is that python is slow; that must be pretty high praise | 12:42 | ||
nwc10 | I continue to assume that a big problem that Python 3 has with getting adopted is that Python 2.7 was already too damn awesome | ||
timotimo | oh, huh | ||
i totally overlooked the "get basechar info" part to ordfirst and ordat | 12:43 | ||
brrt | anybody happens to be familiar with geometric algorithms and knows a less-than-O(n^2) to find all line intersections between two polygons? | ||
timotimo | nqp-m: say(nqp::ordfirst("à")) | 12:44 | |
camelia | nqp-moarvm: OUTPUT«224» | ||
timotimo | nqp-m: say(nqp::ordfirst("ǎ")) | ||
camelia | nqp-moarvm: OUTPUT«462» | ||
timotimo | can has synthetic ... | ||
nqp-m: say(nqp::ordfirst("\r\n")) | |||
camelia | nqp-moarvm: OUTPUT«13» | ||
timotimo | nqp-m: say(nqp::ordat("\r\n", 0)) | ||
camelia | nqp-moarvm: OUTPUT«13» | ||
timotimo | nqp-m: say(nqp::ordat("\r\n", 1)) | ||
camelia | nqp-moarvm: OUTPUT«Invalid string index: max 0, got 1 at /tmp/SxL62KDI03:1 (<ephemeral file>:<mainline>:22) from gen/moar/stage2/NQPHLL.nqp:1303 (/home/camelia/rakudo-m-inst-2/share/nqp/lib/NQPHLL.moarvm:eval:190) from gen/moar/stage2/NQPHLL.nqp:1506 (/home/camelia/rak…» | ||
timotimo | hum. | ||
i still can't quite grasp why azawawi got trouble with JSON::Fast :( | 12:50 | ||
brrt | did.. he try turning the JIT off? | 12:52 | |
timotimo | oh, you think the jit doesn't handle that? | 12:56 | |
it does, though | 12:57 | ||
well, perhaps it doesn't handle it correctly? | |||
signedness and such? | |||
brrt | handle what exactly :-) | 12:58 | |
timotimo | if the number is negative, it calls nfg_get_grapheme_info | ||
and noms the ->base | |||
it just cmp and jge | |||
brrt | i dunno.. there may have been things i've been missing | 12:59 | |
in recent moar news | |||
timotimo | yeah, brrt, getting the jit involved breaks it | 13:05 | |
now you fix it! :P | 13:06 | ||
brrt | ok, so what is the issue exactly :-) | 13:07 | |
gimme a testcase | |||
and i will move the world | |||
timotimo | perl6 -e 'use nqp; for ^200 { say nqp::ordfirst("\r\n") }' | ||
starts out outputting 13, then outputs 4294967309 | |||
lines 1518 and following in our .dasc file are what does that | 13:08 | ||
so the comparison against 0 must be wrong-ish | |||
jnthn | Ah, so the JIT is where that synthetic bug comes from | 13:12 | |
timotimo | thank brrt for pointing it out | ||
brrt | aha.... | 13:14 | |
13:18
domidumont joined
|
|||
timotimo | i don't know much about signedness and unsignedness at the ASM level | 13:18 | |
13:33
tokuhiro_ joined
|
|||
brrt | timotimo; that isn't enough to replicate it for me? | 14:17 | |
timotimo | it isn't? | ||
it's 100% reliable on my end | 14:18 | ||
with a higher number perhaps? | |||
a funny thing: we don't jit the NFA stuff because nqp::getstderr - which it uses for debugging - isn't implemented in the jit | 14:22 | ||
brrt | wow.... | 14:23 | |
no, it's apparantly related to output | |||
i had no idea we had regressed so far.. :-( | |||
timotimo | hm? | ||
oh, i mean the code that builds NFAs | |||
and the NFA optimizer | 14:24 | ||
what do you mean is related to output? | |||
anyway, i'm going to implement the bitwise ops that arnsholt's sum module uses | 14:26 | ||
i have a bail log for his stuff | |||
3 BAIL: op <bor_I> | |||
3 BAIL: op <blshift_I> | |||
2 BAIL: op <bxor_I> | |||
2 BAIL: op <brshift_I> | |||
2 BAIL: op <band_I> | |||
1 BAIL: op <isprime_I> | |||
1 BAIL: op <bnot_I> | |||
(pasted here for my convenience :P) | 14:27 | ||
14:32
kjs_ joined
|
|||
timotimo | brrt: you really can't reproduce it? there isn't an architecture difference, right? | 14:35 | |
brrt | yeah, i can reproduce it | ||
these are all bigint thingies, aren't they? | |||
timotimo | that's right | 14:36 | |
the only reason those aren't done yet is that there's an allocation that happens in interp.c that needs to be moved into bigintops.c | 14:37 | ||
brrt | seems like a plan, if that is safe | 14:44 | |
jnthn | Should be; generally I like to keep op bodies in interp.c slim | 14:45 | |
timotimo | getstd* all have a check for interp's handles to be null or not | 14:46 | |
i'm not sure if there's a good reason to duplicate that in the jit | |||
brrt | near as i can tell, the actual code fragment for MVM_nfg_get_synthetic in the jit is quite safe... | ||
maybe i should follow it a little further | |||
timotimo | on the other hand, you can compile a frame that only actually runs these ops after a bunch of runs | ||
and then it can segv :\ | 14:47 | ||
oh well. it's not that hard to do an exception in the ji | |||
jit* | |||
brrt | what do you mean timotimo? get a segv? | 14:50 | |
timotimo | if tc->instance->std*_handle is null, then things go bad | 14:51 | |
jnthn | Those are set up at startup, and I don't think they ever go away. | 14:52 | |
brrt | i may be misunderstanding, but it seems that the issue *may* lie in p6box_i | 14:55 | |
but that would be.. weird | |||
timotimo | brrt: could it be we have to set the upper 32bit of teh number to zeroes? | 14:56 | |
brrt: because MVMGrapheme32? | |||
brrt | whatddayamean | 14:58 | |
yes, that could be | |||
you are quite correct | 14:59 | ||
timotimo | i can hardly believe i caught that... | ||
dalek | arVM: 59be148 | brrt++ | src/jit/emit_x64.dasc: Fix ordfist/ordat by correct size of synthetic timotimo++ for spotting and suggesting |
15:05 | |
timotimo | neato. | ||
brrt | you don't really have to explicitly zero the upper bits, x86 does that by itself | ||
timotimo | just have to use the right register size | 15:06 | |
brrt | but it's stil very important not to load a bigger field than you have | ||
aye | |||
timotimo | right :) | ||
15:14
kjs_ joined
|
|||
nwc10 | brrt: I guess I'm repeating myself, but that's also what a "conclusion" is :-) | 15:14 | |
it's nice (for us) that two different competant teams, in two different languages, have investigaged using LLVM as a JIT (to the point of working code) and both found that it's LTA compared with what initial benchmarks would have though | 15:15 | ||
thought | |||
I think, sufficient to demonstrate (twice) that it's not cost effective. | |||
brrt | ... yes, that is very true | ||
on the other hand, julialang.org/ | 15:16 | ||
although i haven't looked at that in anything resembling detail | |||
but, retrofitting a dynamic language to run on llvm, that isn't a good way forward, and i can imagine why | 15:17 | ||
nwc10 | I really don't know enough about Julia to know if it fits LLVM's worldview better than the "P" lnguages | ||
brrt | (for another data point, unladen swallow) | ||
nwc10 | oh, right, Julia was targetting LLVM from the start? | ||
brrt | yes | ||
nwc10 | Unladen Swallow didn't *seem* to get far enough that I'm confident that I'd trust it massively. | ||
Also, that was some years ago now, and LLVM got better | |||
so 2.5 :-) | |||
mmm, as I understand it Scala makes compramises in language design to fit with what the JVM can do. Maybe Julia is similar | 15:18 | ||
15:52
domidumont1 joined
15:54
kjs_ joined
|
|||
brrt | julia is a bit more primitive i think than some other languages | 15:55 | |
but the main competition for julia is, i think, not python or perl, but R | |||
nwc10 | ah :-) | ||
and that all makes sense | |||
brrt | another awesome language by the way, which interestingly enough doesn't have the identity crisis of any of the P languages | 15:56 | |
15:57
domidumont joined
|
|||
dalek | arVM: 45d5efc | timotimo++ | src/ (4 files): jit bigint ops or, and, xor, brshift, blshift and bnot. |
16:02 | |
jnthn | m: my @a of int; say @a; | 16:03 | |
camelia | rakudo-moar cca5f2: OUTPUT«[]» | ||
jnthn | m: my @a of int; say @a.WHAT; | ||
camelia | rakudo-moar cca5f2: OUTPUT«(Array[int])» | ||
jnthn | yay, another thing fixed (locally) | ||
16:19
domidumont joined
|
|||
dalek | arVM: 308bfa4 | timotimo++ | src/ (3 files): jitting hintfor allows rakudo's "compile_var" to be jitted to completion. |
16:26 | |
16:34
domidumont joined
|
|||
japhb | test | 16:37 | |
Huh | |||
It's like my previous message just went *poof* | |||
timotimo | success | ||
i didn't see any messages from you :( | |||
japhb | jnthn: Did you decide whether you would be in Stockholm first weekend in December and up for a meetup? (I definitely will; I'm flying in Friday evening.) | ||
TimToady | japhb: did it start with a slash? | 16:38 | |
japhb | Nope; to resend I just up-arrowed and hit enter. It was just ... gone. | ||
japhb wonders if it was software, or the scroll wheel on the mouse just happening to glitch at the same moment I tried to send ... | |||
nwc10 | timotimo: your most recent change breaks the NQP build :-( | 16:40 | |
timotimo | oh? damn! | ||
hintfor you mean? | |||
damn, it does! | |||
nwc10 | This representation (P6int) does not support associative access at gen/moar/stage1/nqpmo.nqp:744 (gen/moar/stage1/nqpmo.moarvm:add_method:11) | ||
... | |||
timotimo | ah | 16:41 | |
return type: void | |||
that's wrong :) | |||
jnthn | timotimo: Please do always at least "make clean; make test" in NQP on Moar changes | 16:42 | |
timotimo | right. i ran spec tests instead m) | ||
jnthn | Yeah, builds are long-running and stress spesh/JIT more, though :) | ||
dalek | arVM: e4e412f | timotimo++ | src/jit/graph.c: fix return type of hintfor and with it, the nqp build |
||
timotimo | there we go | ||
nwc10 | run all the things? | ||
they're quite fast if you're not using ASAN | 16:43 | ||
16:44
travis-ci joined
|
|||
travis-ci | MoarVM build failed. Timo Paulssen 'jitting hintfor allows rakudo's "compile_var" to be jitted to completion.' | 16:44 | |
travis-ci.org/MoarVM/MoarVM/builds/91852366 github.com/MoarVM/MoarVM/compare/4...8bfa47590f | |||
16:44
travis-ci left
|
|||
nwc10 | the Rakudo setting build also stresses stuff a lot | 16:51 | |
but yes, the spectests find other things | |||
hoelzro | o/ #moarvm | 17:08 | |
nwc10 | \o hoelzro | 17:10 | |
dear travis-ci, it's fixed. | |||
hoelzro | o/ nwc10 | 17:11 | |
timotimo | o/ | 17:20 | |
17:27
domidumont joined
|
|||
hoelzro | o/ timotimo | 17:30 | |
17:36
domidumont joined
|
|||
timotimo | uh oh | 17:37 | |
my latest patches seem to cause a "double free or corruption" in the original un-optimized sha256 code | 17:38 | ||
nwc10 | that's glibc malloc? If so, if you run it with valgrind, do you get more useful info? | ||
timotimo | i shall try. | 17:42 | |
i would have tried asan | |||
nwc10 | both are useful, but if you've already got a build and one testcase to run, valgrind gets you answers more quickly | 17:43 | |
(and finds generally more stuff) | |||
timotimo | the rate of reproduction for this crash is about 50% | 17:51 | |
it doesn't help that the whole compilation of the digest lib goes through valgrind now, too ... | 17:53 | ||
ah, excellent! problem caught on tape | 17:56 | ||
the thing was free'd inside jitted code somehow, probably inside the big integer ops i built? | 17:57 | ||
huh, gc_free of MVMString.c of all places | |||
tries to re-free it | |||
er | 18:00 | ||
it does an invalid free | |||
if it tried to do a double-free, the message would surely have looked different | 18:01 | ||
18:06
FROGGS joined
|
|||
FROGGS | o/ | 18:10 | |
timotimo | ohai FROGGS | ||
hooray! the problem exists before my patches were applied! | 18:25 | ||
that makes it a bit harder to find the culprit, though :\ | 18:34 | ||
FROGGS | m: use NativeCall; class A is repr<CStruct> { has int8 $.a }; class B is repr<CStruct> { has int8 $.b }; class AB is repr<CStruct> { HAS A $.a; HAS B $.b }; say nativesizeof(AB) | 19:31 | |
camelia | rakudo-moar 73485c: OUTPUT«9» | ||
FROGGS | I've got a patch for that | ||
jnthn | 9?! :) | 19:32 | |
FROGGS++ :) | |||
dalek | arVM: 7b382ac | FROGGS++ | src/6model/reprs/C (3 files): start with align=0 as it will grow with attrs When we compute the memory a CStruct, CPPStruct or CUnion will take, we will pick the biggest alignment of the struct members. Therefor it makes sense to not start with a value we might not reach. The previous code made a struct align to not less than 8 bytes which is problematic for inlined structs. This fixes RT #126675. |
19:43 | |
FROGGS | ahh, feels good to have anything to commit after that long time | ||
19:43
vendethiel joined
|
|||
hoelzro | FROGGS++ | 19:47 | |
FROGGS | :o) | 19:49 | |
jnthn | \o/ | 19:51 | |
timotimo | oh! | 19:53 | |
good work, FROGGS | 19:54 | ||
i really don't feel like golfing libdigest into something that's somewhat minimal and still triggers The Bug | |||
20:07
vendethiel- joined
|
|||
jnthn finally has something to push that is along the lines of the thing he wanted to get working today :) | 20:24 | ||
hoelzro | I'm still unable to get a working MoarVM on Windows; it throws an access violation when trying to run the stage0 nqp.moarvm. Does that ring a bell for anyone? something with UTF-16 vs UTF-8 encodings, maybe? | 20:25 | |
jnthn | hoelzro: Odd, I build/run Moar on Windows every day without trouble. | ||
hoelzro: What compiler, bitness, etc? | |||
hoelzro | jnthn: 64-bit Mingw on Windows 8.1 | ||
I tried VS 2013 and 2015, same results | 20:26 | ||
jnthn | OK, 64-bit MSVC on Windows 7 here :) | ||
o.O | |||
hoelzro | I'm wondering what I must be doing wrong! | ||
jnthn | Me too... | ||
What Perl? | |||
hoelzro | strawberry | ||
jnthn | Though I don't think we steal too much out of its config... | ||
FROGGS | hoelzro: I'd suggest a 32bit strawberry toolchain | 20:28 | |
a 5.20 or older | |||
hoelzro | 32-bit all the way? compielr and all? | ||
FROGGS | hoelzro: strawberry ships a gcc and gmake you can use | ||
just use that | |||
hoelzro | oh, really? | ||
that's handy | 20:29 | ||
retupmoca builds using strawberry perl and vs2015 without issue | |||
hoelzro | I'll try that, thanks FROGGS | ||
FROGGS | yes, install strawberry, and start configuring moar | ||
hoelzro | retupmoca: it seems like I'm the only one who has problems with this =/ | ||
that makes me wonder if mingw's compiler interferes with strawberry's | |||
FROGGS | quite possible | ||
jnthn | If you're going to use MSVC, then ActiveState's Perl builds are likely a better way to go, since afaik they too use MSVC too | 20:30 | |
FROGGS | jnthn: you can choose AFAICT | 20:31 | |
activestate's perl lies about how it is made... | |||
hoelzro | if I could find my product key, I would just reinstall windows at this point | 20:32 | |
FROGGS | it will tell it was built using MSVC, and if you install the mingw toolchain, it will decide to tell it was build using this one | ||
hoelzro | I think I may have just borked it | ||
FROGGS | :S | ||
hoelzro | I could complain about how hard it is to get a working toolchain, but I'm sure I would be saying the same about Linux if I never used it =/ | 20:33 | |
FROGGS | true | ||
jnthn | I dunno what you're running into | ||
FROGGS | problem is that is easy to do too much there, and have something that conflicts | 20:34 | |
jnthn | It's odd. | ||
FROGGS | jnthn: install mingw *and* strawberry, and you are likely screwed | ||
so either use strawberry+gcc XOR strawberry+MSVC XOR activeperl+MSVC | 20:35 | ||
hoelzro | thanks for weighing in everyone; I feel like I do this every month =( | ||
all this for testing Linenoise on Windows! | 20:36 | ||
FROGGS | hoelzro: if you wanna go the activeperl+msvc route, do steps 0,3,4 and 5 of github.com/rakudo/star/blob/master...ws-msi.pod | 20:37 | |
hoelzro | oh, that looks handy! thanks, FROGGS! | 20:38 | |
I think MSVC would be ideal, because it's about as different as possible as my Linux dev env | |||
FROGGS | activeperl+msvc will probably also not interfere with mingw, just make sure the strawberry folder is renamed to something else, so perl.exe is from activeperl | ||
aye | |||
20:47
Peter_R joined
|
|||
[Coke] | hub.docker.com - rakudo-star has 48.8K pulls. | 20:50 | |
ww | |||
hoelzro | \o/ | ||
20:53
cygx joined
|
|||
cygx | in my more silly moments, I've been musing about creating a single-file windows build environment that budles busybox, tinycc, gnu make and a git clone based on libgit2 | 20:59 | |
you need a unix-like build environment on windows? oh, it's just this file over here... | |||
konobi | there's free (as in beer) versions of visual studio these days | 21:13 | |
cygx | that's not particularly unix-like, though ;) | 21:16 | |
21:35
colomon joined
22:35
colomon joined
23:33
tokuhiro_ joined
|