|
01:07
pyrimidine joined
01:52
pyrimidine joined
|
|||
| MasterDuke | timotimo: i just rebuilt moar/nqp/rakudo with jnthn++ | 02:15 | |
| 's latest changes | |||
| timotimo | ah, good! | 02:16 | |
| will be interesting to see if things improve | |||
| MasterDuke | and now the rakudo version with natives is noticeably faster | ||
| timotimo | lovely! | 02:17 | |
| what code were we talking about again? | |||
| i was thinking of whateverable and memory leaks and such | |||
| MasterDuke | 'use nqp; sub a() { nqp::stmts((my $f := nqp::open("small_compile.sql", "r")), (my str $l), (my int $s = 0), nqp::while(($l = nqp::readlinefh($f)), ++$s), $s) }; say(a())' | ||
| where small_compile.sql is 1m lines | 02:18 | ||
| timotimo | can you give percentage improvements or something? | ||
| MasterDuke | the pure nqp version was the same, the rakudo version with native is now just slightly slower than the nqp version | 02:19 | |
| when before it was almost twice as slow | |||
| timotimo | how slight we talking? | ||
| MasterDuke | oh, maybe slightly faster | 02:20 | |
| MasterDuke double checks which commands were run | |||
| no, the nqp version is about 50ms faster on average | 02:21 | ||
| 1620 vs 1670 | |||
| timotimo | that sounds quite good | 02:22 | |
| so 1.6s to slurp up an 1m line file line-by-line | |||
| MasterDuke | yep. though perl5 does the same thing in 190 | 02:25 | |
| timotimo | oof | 02:26 | |
| with utf8, too? | |||
| or does perl5 read it as ascii? | |||
| MasterDuke | it reads as ascii, let me try again with utf8 | 02:27 | |
| utf8 is 1165 | 02:28 | ||
| timotimo | we're quite close, then | ||
| MasterDuke | so we're only 0.5s off? not terrible | ||
| timotimo | how is ascii with perl6? probably rather slow | ||
| MasterDuke | 1250 | 02:30 | |
| so ~ 0.4s faster than utf8 | 02:31 | ||
| though this is with essentially writing nqp in perl6 | 02:32 | ||
| oh, and actually all those non-perl5 times include profiling | |||
| uh, some of them do | 02:33 | ||
| timotimo | the difference through profiling is stronger when you invoke stuff and allocate stuff | ||
| unless you mean perf | 02:36 | ||
| in which case the overhead is almost negligible | |||
| MasterDuke | the naive perl6 version, 'my int $s = 0; ++$s for "small_compile.sql".IO.lines; say $s', takes 3875 in contrast to writing nqp in perl6 | ||
| no, i was doing --profile | |||
| timotimo | ok | 02:37 | |
| MasterDuke | ah, that's not exactly the same naive perl6 i tested yesterday, that was 'sub a() { my $s = 0; ++$s for "small_compile.sql".IO.lines; $s }; say(a())', but even it is 4200 instead of 4700, so ~0.5s faster | 02:41 | |
| jnthn++ | |||
| and making $s an int brings it down another 350ms | 02:46 | ||
| timotimo | nice | ||
|
02:48
ilbot3 joined
|
|||
| MasterDuke | and FWIW, this 'sub a() { my $f = open "small_compile.sql"; my $l; my int $s = 0; while $l = $f.get { ++$s }; return $s }; say(a())' was 2870 | 03:02 | |
| but this 'sub a() { my $f = open "small_compile.sql"; my int $s = 0; while $f.get -> $l { ++$s }; return $s }; say(a())' was 3340 | 03:03 | ||
|
03:12
agentzh joined
05:13
KDr2 joined
05:31
geekosaur joined
06:34
brrt joined
06:53
domidumont joined
06:59
domidumont joined
|
|||
| brrt | merging the data section support is going to be one hell of a job | 07:20 | |
|
07:46
brrt joined
|
|||
| brrt | blog.pyston.org/2017/01/31/pyston-...ure-plans/ | 07:48 | |
| (hard not to think 'another one bytes the dust') | |||
| nwc10 | I wonder if dropbox will now be looking at grumpy | 07:58 | |
| and also "Dropbox has increasingly been writing its performance-sensitive code in other languages, such as Go" | 07:59 | ||
| brrt | grumpy, that was the python-to-go-compiler | 08:00 | |
| wasn't it? | |||
| nwc10 | yes | ||
| there's sort of two parts to my two lines (in my head at least) hence the "also" | |||
| brrt | well, ehm, hmmm, i'm not sure how to interpret that | 08:01 | |
| nwc10 | 1) looks like their Python 2 EOL strategey is "not Python" | ||
| arnsholt | I strongly suspect that speed and CPython compatibility (in particular extensions) are almost diametrically opposed | ||
| brrt nods | |||
| brrt nods enthusiastically | |||
| counterpoint: SciPY | |||
| nwc10 | 2) I wonder if the arrival of Grumpy makes them more interested in that approach for the Python they do have | ||
| yes, roughly what I was thinking - does a sweet spot between "more speed" and "enough compatibilitly" even exit? | 08:02 | ||
| er, exist | |||
| arnsholt | Isn't SciPy mostly a wrapper over NumPy, which plugs into LAPACK/BLAS/whatever? | ||
| nwc10 | Hacker News is brutal: news.ycombinator.com/item?id=13534992 | 08:03 | |
| brrt | oh, i've mostly stopped reading it | ||
| nwc10 | read that. there are just two comments. Both polite. | ||
| brrt | ah, seen | ||
| :-) | |||
| reasonably polite, yes | |||
| nwc10 | yes, well | ||
| brrt | meanwhile, we're still sloughing on with MoarVM.... | 08:04 | |
| nwc10 | polite words. not polite concepts | ||
| brrt | to be fair | ||
| I'd move to go if I was them | |||
| it is an amazing tool, if not the most elegant language | |||
| to be also fair, I'm sometimes kind of amazed of how far our little community has come | 08:10 | ||
| samcv | nqp: say(nqp::unicmp_s('a', 'B', 7, 0, 0,0)) | 08:18 | |
| camelia | nqp-moarvm: OUTPUT«1» | ||
| samcv | m: use nqp; say(nqp::unicmp_s('a', 'B', 7, 0, 0,0)) | ||
| camelia | rakudo-moar 951a44: OUTPUT«This type cannot unbox to a native integer: P6opaque, Str in block <unit> at <tmp> line 1» | ||
| samcv | for some reason this tries to unbox into the incorrect type | ||
| it tries to unbox the strings into integers and the 7 into a string | |||
| and i'm not sure why the hell | 08:19 | ||
| it does this. anybody know more about this type of thing? | |||
| Geth | MoarVM/jit-data-section: 2c2374c01f | (Bart Wiegmans)++ | 2 files Add data section for JIT code This enables us to store (function) pointers and the like in a separate section rather than having to shuffle them in via constant expressions (ie. movabs). Expected to be a code-size saving, might eventually be used to canonicalize pointers and make JIT code serializable. |
08:28 | |
| MoarVM/jit-data-section: 2d81976c6c | (Bart Wiegmans)++ | 7 files Emit data node for extop 'fake' registers This should plug a minor memory leak from malloc()-ing 'fake' registers used for extop support. Introduces a MVM_JIT_DATA node type. |
|||
| brrt | PR coming up | ||
| Geth | MoarVM: bdw++ created pull request #516: Add data section for JIT compiled code |
08:32 | |
|
08:49
zakharyas joined
09:38
domidumont joined
|
|||
| jnthn | brrt++ | 10:03 | |
| Will look at that later when my @other-task are cut down a bit :) | |||
| brrt | sure :-) | 10:04 | |
| NB: i want to do more advanced stuff, like having a table of pointers and supporting serialization / linking | |||
| but, not really necessary for now | 10:05 | ||
| jnthn | *nod* | ||
| There's always opportunity to do more stuff... :) | |||
| brrt | infinite amounts of work, if you want it | 10:06 | |
| samcv | hi jnthn | 10:13 | |
| jnthn | hi, samcv | ||
| samcv | when you have the time can yo usee what i wrote above? | ||
| about 1 hour ago | |||
| jnthn | About the op oddity? I've no immediate idea :S | ||
| samcv | yeah | ||
| :\ | |||
| i *thought* it worked fine before | 10:14 | ||
| jnthn | I assume the oplist entry is correct? | ||
| 'cus that's what the NQP mapping uses for its types | |||
| samcv | this is in MVM or in nqp? | 10:17 | |
| ah looks like mvm | |||
| w(int64) r(str) r(str) r(int64) r(int64) r(int64) :pure | |||
| that looks right to me | |||
| jnthn | Then your call looks wrong, I think? 'cus you passed 4 ints at the end? | 10:19 | |
| nqp::unicmp_s('a', 'B', 7, 0, 0,0) | |||
| Is that final 0 meant to be there? | 10:20 | ||
| samcv | heh | ||
| m: use nqp; say(nqp::unicmp_s('a', 'B', 7, 0, 0) | 10:21 | ||
| camelia | rakudo-moar 951a44: OUTPUT«===SORRY!=== Error while compiling <tmp>Unable to parse expression in argument list; couldn't find final ')' at <tmp>:1------> qp; say(nqp::unicmp_s('a', 'B', 7, 0, 0)⏏<EOL>» | ||
| samcv | m: use nqp; say(nqp::unicmp_s('a', 'B', 7, 0, 0)) | ||
| camelia | rakudo-moar 951a44: OUTPUT«-1» | ||
| samcv | aha! | ||
| very good | |||
|
10:35
agentzh joined
12:28
domidumont joined
13:00
pyrimidi_ joined
13:01
dogbert17_ joined
13:02
geekosaur joined
13:26
pyrimidine joined
|
|||
| timotimo | IMO "make clean" should also clean 3rdparty folders | 13:41 | |
|
13:42
travis-ci joined
|
|||
| travis-ci | MoarVM build errored. Jonathan Worthington 'Refuse to form an NFA with a zeroed to-state. | 13:42 | |
| travis-ci.org/MoarVM/MoarVM/builds/197052674 github.com/MoarVM/MoarVM/compare/8...d4bd53e62a | |||
|
13:42
travis-ci left
13:46
KDr2 joined
|
|||
| brrt | make realclean does, i think | 13:48 | |
| timotimo | oh | 13:49 | |
| brrt | 'git submodule foreach git clean -xdf' is what i usually do | ||
| timotimo | hehe. | 13:50 | |
| so .. how did it happen that suddenly the code threw sigill? | |||
| oh! | |||
| i have a theory | |||
| brrt | hmmmm | 13:51 | |
| is it JIT related\ | |||
| timotimo | no | ||
| i think my exclusion patterns for syncthing aren't good enough | |||
| so perhaps it synchronised some .a files | 13:52 | ||
| i'm pretty sure i'm excluding .o files | |||
|
14:00
ggoebel joined
14:05
domidumont joined
14:37
agentzh joined
16:11
pyrimidine joined
16:14
brrt joined
16:41
pyrimidine joined
16:52
domidumont joined
16:53
agentzh joined
17:00
pyrimidine joined
17:22
zakharyas joined
17:29
geekosaur joined
17:32
pyrimidine joined
18:00
pyrimidine joined
18:16
pyrimidine joined
18:27
pyrimidine joined
18:42
Geth joined
18:52
pyrimidine joined
19:00
agentzh joined
19:07
FROGGS joined
19:20
pyrimidine joined
19:50
pyrimidine joined
19:54
agentzh joined
20:01
FROGGS joined
20:18
pyrimidine joined
20:51
pyrimidine joined
21:09
agentzh joined
21:36
agentzh joined
22:15
MasterDuke joined
22:51
pyrimidine joined
23:02
ggoebel joined
|
|||