Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-11-18

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:44 tokuhiro_ joined #moarvm
02:16 tokuhiro_ joined #moarvm
02:23 FROGGS_ joined #moarvm
02:51 Util joined #moarvm
03:31 dalek MoarVM: b3d0345 | hoelzro++ | src/ (4 files):
03:31 dalek MoarVM: Restore "Track whether or not a capture owns its callsite"
03:31 dalek MoarVM:
03:31 dalek MoarVM: This reverts commit 9befd69353643bff3a529aa5bea8101cd574fa29.
03:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b3d034541b
03:31 dalek MoarVM: 132f390 | hoelzro++ | src/core/args.c:
03:31 dalek MoarVM: Just check arg_flags to know whether or not to get rid of them
03:31 dalek MoarVM:
03:31 dalek MoarVM: One, arg_flags should know best.  Two, checking the callsite
03:31 dalek MoarVM: object is checking an object we don't own, and may be invalid by
03:31 dalek MoarVM: this point in the program.
03:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/132f390392
03:46 vendethiel joined #moarvm
06:23 TimToady joined #moarvm
06:56 domidumont joined #moarvm
07:01 domidumont joined #moarvm
07:08 FROGGS_ joined #moarvm
07:34 TimToady joined #moarvm
07:50 nwc10 hoelzro++ # ASAN approves
07:51 nwc10 (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 :-)
08:49 zakharyas joined #moarvm
09:01 kjs_ joined #moarvm
09:37 kjs_ joined #moarvm
11:31 brrt joined #moarvm
11:45 nwc10 hi brrt
11:45 nwc10 I found some things. http://hhvm.com/blog/10205/llvm-code-generation-in-hhvm
11:45 nwc10 ... 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.
11:46 nwc10 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 nwc10 meanwhile, I noticed that on http://www.zend.com/en/resources/php7_infographic they are happyly showing (er, choosing) graphs that show PHP7 to be faster than HHVM
11:46 nwc10 HHVM 3.7.0
11:47 nwc10 current HHVM is 3.10.10 and between the two we had http://hhvm.com/blog/9293/lockdown-results-and-hhvm-performance
11:47 nwc10 -- 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.
11:47 nwc10 so I wonder how fast PHP7 is compared with "this week"'s HHVM
11:47 nwc10 and if Zend are stuffed
11:48 nwc10 (well, unless you want to run PHP on non x86_64, because, for example, ARM is interesting)
11:48 ziggypup joined #moarvm
11:49 ziggypup left #moarvm
12:13 brrt hi nwc10
12:13 brrt (i was off for lunch)
12:14 nwc10 ilmari: ^^ :-)
12:14 nwc10 hi brrt
12:15 * brrt is reading about  that page
12:15 brrt i recall rurban saying good things about php7
12:15 brrt at least with regards to speed
12:22 * brrt is thinking of switching blogging platforms, but then recalls that he doesn't care about managing websites
12:25 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:31 brrt nwc10: very interesting. they're doing pretty much everything like how we're doing the moar-jit
12:31 brrt i do have to ask
12:31 brrt do my blog post come of as boasting in the same way this one does?
12:32 brrt i mean, they almost *want* to make it sound difficult and complex and Serious Engineering
12:33 timotimo i don't think your blog posts sound overly boasting
12:34 brrt oh, right, this is facebook, that .. explains? :-P
12:35 timotimo huh? what is facebook?
12:35 timotimo oh, the hhvm people
12:35 nwc10 brrt: I believe that a team of them have been workign on HHVM for several years
12:36 nwc10 and I got the impression that facebook tries really hard to only hire smart folks
12:36 nwc10 so they probably think that it's hard because they are finding it hard
12:36 nwc10 but also, they do need to make legacy code go fast
12:37 nwc10 rather than (re)designing the language if something turns out to be hard/impossible to make fast
12:38 brrt hmmm....
12:39 brrt yeah, i think that the whole problem of making (legacy) dynamic language code go fast is slowly proving more difficult than anybody imagined
12:40 brrt 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 brrt i'm stuck with python because $people
12:40 nwc10 presumably $people are on 2.7 - do they have a plan to migrate?
12:40 brrt my personal plan is to write everything py3 compatible
12:40 timotimo pypy is fantastic. i'm willing to say that over and over again :)
12:41 brrt python is a pretty good language at any rate :-)
12:42 brrt 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
12:42 timotimo oh, huh
12:43 timotimo 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?
12:44 timotimo nqp-m: say(nqp::ordfirst("à"))
12:44 camelia nqp-moarvm: OUTPUT«224␤»
12:44 timotimo nqp-m: say(nqp::ordfirst("ǎ"))
12:44 camelia nqp-moarvm: OUTPUT«462␤»
12:44 timotimo can has synthetic ...
12:44 timotimo nqp-m: say(nqp::ordfirst("\r\n"))
12:44 camelia nqp-moarvm: OUTPUT«13␤»
12:44 timotimo nqp-m: say(nqp::ordat("\r\n", 0))
12:44 camelia nqp-moarvm: OUTPUT«13␤»
12:44 timotimo nqp-m: say(nqp::ordat("\r\n", 1))
12:44 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…»
12:44 timotimo hum.
12:50 timotimo i still can't quite grasp why azawawi got trouble with JSON::Fast :(
12:52 brrt did.. he try turning the JIT off?
12:56 timotimo oh, you think the jit doesn't handle that?
12:57 timotimo it does, though
12:57 timotimo well, perhaps it doesn't handle it correctly?
12:57 timotimo signedness and such?
12:58 brrt handle what exactly :-)
12:58 timotimo if the number is negative, it calls nfg_get_grapheme_info
12:58 timotimo and noms the ->base
12:58 timotimo it just cmp and jge
12:59 brrt i dunno.. there may have been things i've been missing
12:59 brrt in recent moar news
13:05 timotimo yeah, brrt, getting the jit involved breaks it
13:06 timotimo now you fix it! :P
13:07 brrt ok, so what is the issue exactly :-)
13:07 brrt gimme a testcase
13:07 brrt and i will move the world
13:07 timotimo perl6 -e 'use nqp; for ^200 { say nqp::ordfirst("\r\n") }'
13:07 timotimo starts out outputting 13, then outputs 4294967309
13:08 timotimo lines 1518 and following in our .dasc file are what does that
13:08 timotimo so the comparison against 0 must be wrong-ish
13:12 jnthn Ah, so the JIT is where that synthetic bug comes from
13:12 timotimo thank brrt for pointing it out
13:14 brrt aha....
13:18 domidumont joined #moarvm
13:18 timotimo i don't know much about signedness and unsignedness at the ASM level
13:33 tokuhiro_ joined #moarvm
14:17 brrt timotimo; that isn't enough to replicate it for me?
14:17 timotimo it isn't?
14:18 timotimo it's 100% reliable on my end
14:18 timotimo with a higher number perhaps?
14:22 timotimo 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:23 brrt wow....
14:23 brrt no, it's apparantly related to output
14:23 brrt i had no idea we had regressed so far.. :-(
14:23 timotimo hm?
14:23 timotimo oh, i mean the code that builds NFAs
14:24 timotimo and the NFA optimizer
14:24 timotimo what do you mean is related to output?
14:26 timotimo anyway, i'm going to implement the bitwise ops that arnsholt's sum module uses
14:26 timotimo i have a bail log for his stuff
14:26 timotimo 3 BAIL: op <bor_I>
14:26 timotimo 3 BAIL: op <blshift_I>
14:26 timotimo 2 BAIL: op <bxor_I>
14:26 timotimo 2 BAIL: op <brshift_I>
14:26 timotimo 2 BAIL: op <band_I>
14:26 timotimo 1 BAIL: op <isprime_I>
14:26 timotimo 1 BAIL: op <bnot_I>
14:27 timotimo (pasted here for my convenience :P)
14:32 kjs_ joined #moarvm
14:35 timotimo brrt: you really can't reproduce it? there isn't an architecture difference, right?
14:35 brrt yeah, i can reproduce it
14:35 brrt these are all bigint thingies, aren't they?
14:36 timotimo that's right
14:37 timotimo 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:44 brrt seems like a plan, if that is safe
14:45 jnthn Should be; generally I like to keep op bodies in interp.c slim
14:46 timotimo getstd* all have a check for interp's handles to be null or not
14:46 timotimo i'm not sure if there's a good reason to duplicate that in the jit
14:46 brrt near as i can tell, the actual code fragment for MVM_nfg_get_synthetic in the jit is quite safe...
14:46 brrt maybe i should follow it a little further
14:46 timotimo on the other hand, you can compile a frame that only actually runs these ops after a bunch of runs
14:47 timotimo and then it can segv :\
14:47 timotimo oh well. it's not that hard to do an exception in the ji
14:47 timotimo jit*
14:50 brrt what do you mean timotimo? get a segv?
14:51 timotimo if tc->instance->std*_handle is null, then things go bad
14:52 jnthn Those are set up at startup, and I don't think they ever go away.
14:55 brrt i may be misunderstanding, but it seems that the issue *may* lie in p6box_i
14:55 brrt but that would be.. weird
14:56 timotimo brrt: could it be we have to set the upper 32bit of teh number to zeroes?
14:56 timotimo brrt: because MVMGrapheme32?
14:58 brrt whatddayamean
14:58 brrt yes, that could be
14:59 brrt you are quite correct
14:59 timotimo i can hardly believe i caught that...
15:05 dalek MoarVM: 59be148 | brrt++ | src/jit/emit_x64.dasc:
15:05 dalek MoarVM: Fix ordfist/ordat by correct size of synthetic
15:05 dalek MoarVM:
15:05 dalek MoarVM: timotimo++ for spotting and suggesting
15:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/59be148d82
15:05 timotimo neato.
15:05 brrt you don't really have to explicitly zero the upper bits, x86 does that by itself
15:06 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
15:06 brrt aye
15:06 timotimo right :)
15:14 kjs_ joined #moarvm
15:14 nwc10 brrt: I guess I'm repeating myself, but that's also what a "conclusion" is :-)
15:15 nwc10 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 nwc10 thought
15:15 nwc10 I think, sufficient to demonstrate (twice) that it's not cost effective.
15:15 brrt ... yes, that is very true
15:16 brrt on the other hand, http://julialang.org/
15:16 brrt although i haven't looked at that in anything resembling detail
15:17 brrt 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
15:17 brrt (for another data point, unladen swallow)
15:17 nwc10 oh, right, Julia was targetting LLVM from the start?
15:17 brrt yes
15:17 nwc10 Unladen Swallow didn't *seem* to get far enough that I'm confident that I'd trust it massively.
15:17 nwc10 Also, that was some years ago now, and LLVM got better
15:17 nwc10 so 2.5 :-)
15:18 nwc10 mmm, as I understand it Scala makes compramises in language design to fit with what the JVM can do. Maybe Julia is similar
15:52 domidumont1 joined #moarvm
15:54 kjs_ joined #moarvm
15:55 brrt julia is a bit more primitive i think than some other languages
15:55 brrt but the main competition for julia is, i think, not python or perl, but R
15:55 nwc10 ah :-)
15:55 nwc10 and that all makes sense
15:56 brrt another awesome language by the way, which interestingly enough doesn't have the identity crisis of any of the P languages
15:57 domidumont joined #moarvm
16:02 dalek MoarVM: 45d5efc | timotimo++ | src/ (4 files):
16:02 dalek MoarVM: jit bigint ops or, and, xor, brshift, blshift and bnot.
16:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/45d5efc12b
16:03 jnthn m: my @a of int; say @a;
16:03 camelia rakudo-moar cca5f2: OUTPUT«[]␤»
16:03 jnthn m: my @a of int; say @a.WHAT;
16:03 camelia rakudo-moar cca5f2: OUTPUT«(Array[int])␤»
16:03 jnthn yay, another thing fixed (locally)
16:19 domidumont joined #moarvm
16:26 dalek MoarVM: 308bfa4 | timotimo++ | src/ (3 files):
16:26 dalek MoarVM: jitting hintfor allows rakudo's "compile_var" to be jitted to completion.
16:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/308bfa4759
16:34 domidumont joined #moarvm
16:37 japhb test
16:37 japhb Huh
16:37 japhb It's like my previous message just went *poof*
16:37 timotimo success
16:37 timotimo i didn't see any messages from you :(
16:37 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.)
16:38 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.
16:38 * 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 ...
16:40 nwc10 timotimo: your most recent change breaks the NQP build :-(
16:40 timotimo oh? damn!
16:40 timotimo hintfor you mean?
16:40 timotimo damn, it does!
16:40 nwc10 This representation (P6int) does not support associative access at gen/moar/stage1/nqpmo.nqp:744  (gen/moar/stage1/nqpmo.moarvm:add_method:11)
16:40 nwc10 ...
16:41 timotimo ah
16:41 timotimo return type: void
16:41 timotimo that's wrong :)
16:42 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)
16:42 jnthn Yeah, builds are long-running and stress spesh/JIT more, though :)
16:42 dalek MoarVM: e4e412f | timotimo++ | src/jit/graph.c:
16:42 dalek MoarVM: fix return type of hintfor
16:42 dalek MoarVM:
16:42 dalek MoarVM: and with it, the nqp build
16:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e4e412fb17
16:42 timotimo there we go
16:42 nwc10 run all the things?
16:43 nwc10 they're quite fast if you're not using ASAN
16:44 travis-ci joined #moarvm
16:44 travis-ci MoarVM build failed. Timo Paulssen 'jitting hintfor allows rakudo's "compile_var" to be jitted to completion.'
16:44 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/91852366 https://github.com/MoarVM/MoarVM/compare/45d5efc12bfa...308bfa47590f
16:44 travis-ci left #moarvm
16:51 nwc10 the Rakudo setting build also stresses stuff a lot
16:51 nwc10 but yes, the spectests find other things
17:08 hoelzro o/ #moarvm
17:10 nwc10 \o hoelzro
17:10 nwc10 dear travis-ci, it's fixed.
17:11 hoelzro o/ nwc10
17:20 timotimo o/
17:27 domidumont joined #moarvm
17:30 hoelzro o/ timotimo
17:36 domidumont joined #moarvm
17:37 timotimo uh oh
17:38 timotimo 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?
17:42 timotimo i shall try.
17:42 timotimo i would have tried asan
17:43 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 nwc10 (and finds generally more stuff)
17:51 timotimo the rate of reproduction for this crash is about 50%
17:53 timotimo it doesn't help that the whole compilation of the digest lib goes through valgrind now, too ...
17:56 timotimo ah, excellent! problem caught on tape
17:57 timotimo the thing was free'd inside jitted code somehow, probably inside the big integer ops i built?
17:57 timotimo huh, gc_free of MVMString.c of all places
17:57 timotimo tries to re-free it
18:00 timotimo er
18:00 timotimo it does an invalid free
18:01 timotimo if it tried to do a double-free, the message would surely have looked different
18:06 FROGGS joined #moarvm
18:10 FROGGS o/
18:10 timotimo ohai FROGGS
18:25 timotimo hooray! the problem exists before my patches were applied!
18:34 timotimo that makes it a bit harder to find the culprit, though :\
19:31 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␤»
19:31 FROGGS I've got a patch for that
19:32 jnthn 9?! :)
19:32 jnthn FROGGS++ :)
19:43 dalek MoarVM: 7b382ac | FROGGS++ | src/6model/reprs/C (3 files):
19:43 dalek MoarVM: start with align=0 as it will grow with attrs
19:43 dalek MoarVM:
19:43 dalek MoarVM: When we compute the memory a CStruct, CPPStruct or CUnion will take, we will pick
19:43 dalek MoarVM: the biggest alignment of the struct members. Therefor it makes sense to not start
19:43 dalek MoarVM: with a value we might not reach. The previous code made a struct align to not less
19:43 dalek MoarVM: than 8 bytes which is problematic for inlined structs. This fixes RT #126675.
19:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7b382acd61
19:43 FROGGS ahh, feels good to have anything to commit after that long time
19:43 vendethiel joined #moarvm
19:47 hoelzro FROGGS++
19:49 FROGGS :o)
19:51 jnthn \o/
19:53 timotimo oh!
19:54 timotimo good work, FROGGS
19:54 timotimo i really don't feel like golfing libdigest into something that's somewhat minimal and still triggers The Bug
20:07 vendethiel- joined #moarvm
20:24 * jnthn finally has something to push that is along the lines of the thing he wanted to get working today :)
20:25 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.
20:25 jnthn hoelzro: What compiler, bitness, etc?
20:25 hoelzro jnthn: 64-bit Mingw on Windows 8.1
20:26 hoelzro I tried VS 2013 and 2015, same results
20:26 jnthn OK, 64-bit MSVC on Windows 7 here :)
20:26 jnthn o.O
20:26 hoelzro I'm wondering what I must be doing wrong!
20:26 jnthn Me too...
20:26 jnthn What Perl?
20:26 hoelzro strawberry
20:26 jnthn Though I don't think we steal too much out of its config...
20:28 FROGGS hoelzro: I'd suggest a 32bit strawberry toolchain
20:28 FROGGS a 5.20 or older
20:28 hoelzro 32-bit all the way? compielr and all?
20:28 FROGGS hoelzro: strawberry ships a gcc and gmake you can use
20:28 FROGGS just use that
20:28 hoelzro oh, really?
20:29 hoelzro that's handy
20:29 * retupmoca builds using strawberry perl and vs2015 without issue
20:29 hoelzro I'll try that, thanks FROGGS
20:29 FROGGS yes, install strawberry, and start configuring moar
20:29 hoelzro retupmoca: it seems like I'm the only one who has problems with this =/
20:29 hoelzro that makes me wonder if mingw's compiler interferes with strawberry's
20:29 FROGGS quite possible
20:30 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:31 FROGGS jnthn: you can choose AFAICT
20:31 FROGGS activestate's perl lies about how it is made...
20:32 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
20:32 hoelzro I think I may have just borked it
20:32 FROGGS :S
20:33 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
20:33 jnthn I dunno what you're running into
20:34 FROGGS problem is that is easy to do too much there, and have something that conflicts
20:34 jnthn It's odd.
20:34 FROGGS jnthn: install mingw *and* strawberry, and you are likely screwed
20:35 FROGGS 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 =(
20:36 hoelzro all this for testing Linenoise on Windows!
20:37 FROGGS hoelzro: if you wanna go the activeperl+msvc route, do steps 0,3,4 and 5 of https://github.com/rakudo/star/blob/master/tools/star/windows-msi.pod
20:38 hoelzro oh, that looks handy! thanks, FROGGS!
20:38 hoelzro I think MSVC would be ideal, because it's about as different as possible as my Linux dev env
20:38 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
20:38 FROGGS aye
20:47 Peter_R joined #moarvm
20:50 [Coke] hub.docker.com - rakudo-star has 48.8K pulls.
20:50 [Coke] ww
20:50 hoelzro \o/
20:53 cygx joined #moarvm
20:59 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 cygx you need a unix-like build environment on windows? oh, it's just this file over here...
21:13 konobi there's free (as in beer) versions of visual studio these days
21:16 cygx that's not particularly unix-like, though ;)
21:35 colomon joined #moarvm
22:35 colomon joined #moarvm
23:33 tokuhiro_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary