Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-07

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

All times shown according to UTC.

Time Nick Message
01:23 ugexe m: say ("a" eqv "a") === True; # cxreg | i think that's a regression, i have an old build that returns True
01:23 camelia rakudo-moar ac36d2: OUTPUT«False␤»
01:24 ugexe i saw a known regression for ===, but not sure its known for eqv
04:10 sortiz joined #p6dev
07:55 sortiz Seems that https://github.com/rakudo/rakudo/commit/463e7589a1c332e4135c265f624f8e99ae02c2b9#diff-b97adc1f620bac34861ecff3ba643717R6 should be "nqp::p6bool(nqp::eqaddr(a,b) || (nqp::eqaddr(a.WHAT,b.WHAT) && (a cmp b) == 0))"
07:59 lizmat m: say Int =:= Int
07:59 camelia rakudo-moar ac36d2: OUTPUT«True␤»
08:02 lizmat sortiz: it could be...  but what is wrong with what's there now ?
08:04 sortiz lizmat, see ugexe report a few hours before.
08:04 sortiz http://irclog.perlgeek.de/p6dev/2016-05-07#i_12446159
08:05 lizmat ah, it's missing a boolify
08:05 sortiz Yep
08:06 lizmat testing a fix
08:07 lizmat :q
08:07 lizmat oops
08:10 sortiz And I don't have yet your list that operators that now don't need the nqp variant ;-)
08:11 sortiz s/that/of/
08:17 lizmat I am still failing to understand why it returned 1 instead of True
08:17 lizmat m: say ("a" cmp "b") == 0
08:17 camelia rakudo-moar ac36d2: OUTPUT«False␤»
08:17 lizmat m: say "a" =:= "a"
08:17 camelia rakudo-moar ac36d2: OUTPUT«True␤»
08:19 lizmat m: sub a(\a,\b) { a =:= b || (a.WHAT =:= b.WHAT && (a cmp b) == 0) }; say a("a","a") === True
08:19 camelia rakudo-moar ac36d2: OUTPUT«True␤»
08:20 [Tux] This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04
08:20 [Tux] test            24.333
08:20 [Tux] test-t          14.947
08:20 [Tux] csv-parser      36.061
08:20 [Tux] :(
08:23 lizmat [Tux]: looking at that degradation
08:23 [Tux] lizmat++
08:24 lizmat since the only difference is really all of the optimizing commits I did, perhaps they're not optimizing when combined  :-(
08:29 lizmat m: my $a = "a"; say $a =:= $a   # yeah, True
08:29 camelia rakudo-moar ac36d2: OUTPUT«True␤»
08:29 lizmat m: my $a = "a"; say $a =:= $a || 0   # WAT?
08:29 camelia rakudo-moar ac36d2: OUTPUT«1␤»
08:31 sortiz Oops!
08:31 lizmat *that's* the underlying bug
08:32 RabidGravy joined #p6dev
08:32 lizmat m: say "a" =:= "a" || 0   # must be runtime
08:32 camelia rakudo-moar ac36d2: OUTPUT«True␤»
08:33 sortiz That seems of another level to me.
08:33 lizmat looks like an optimizer bug:
08:33 lizmat $ perl6 --optimize=0 -e 'my $a = "a"; say $a =:= $a || 0'
08:33 lizmat True
08:34 lizmat $ perl6 --optimize=2 -e 'my $a = "a"; say $a =:= $a || 0'
08:34 lizmat 1
08:34 lizmat level 2 and up
08:39 * lizmat submitted RT #128092
08:39 lizmat https://rt.perl.org/Ticket/Display.html?id=128092
08:44 dalek rakudo/nom: 411e76f | lizmat++ | src/core/Stringy.pm:
08:44 dalek rakudo/nom: Temporary fix for RT #128092
08:44 dalek rakudo/nom:
08:44 dalek rakudo/nom: ugexe++ for spotting, sortiz++ for following up
08:44 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/411e76fae2
08:44 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128092
08:45 psch hm, travis as-is isn't that useful for croaking about install-core-dist.pl :/
08:46 psch as in, since it runs "make test" last it doesn't show the build as failed when install-core-dist.pl failed
08:52 lizmat [Tux]: I cannot reproduce your findings:
08:52 lizmat I went back to 631a36cbe32c98fba0 (2 May)
08:52 lizmat on that version, test-t runs for me in 13.153 seconds
08:53 lizmat whereas at nom, it runs in 12.044 seconds
08:53 lizmat m: say 12.044 / 13.153
08:53 camelia rakudo-moar 411e76: OUTPUT«0.915685␤»
08:53 lizmat so almost 9% faster
08:55 lizmat maybe I should start posting my numbers everyday as well  :-)
08:55 masak yes :)
08:56 masak m: say ((1 - 12.044 / 13.153) * 100).fmt("%5.2f%% faster")
08:56 camelia rakudo-moar 411e76: OUTPUT« 8.43% faster␤»
08:57 sortiz psch, btw, as the provides are installed and precompiled in order, don't need "NativeCall" be after the others? That can be the explanation nadim++ reported problem.
08:58 psch sortiz: i have no idea.  what did nadim report?
08:58 masak in other news, on a nicks-that-weird-me-out scale, "hotel" wins some kind of prize. I don't know why :P
08:59 sortiz psch, see http://irclog.perlgeek.de/perl6/2016-05-07#i_12446630
09:00 lizmat .oO( you can never leave )
09:01 psch sortiz: i don't know if that could be related to provides order.  maybe if NativeCall was before NativeCall::Types, but since the former 'use'es the latter that should sort itself out, afaiu
09:01 sortiz I.e NativeCall uses NativeCall::Types, so if installed first can use an older NC::Types (preinstalled) version.
09:02 psch hm, yeah, maybe
09:02 sortiz The install can't know the dependency order.
09:02 psch i don't really understand this part of the code base particularly well :)
09:02 lizmat [Tux]: do you do a configure every morning as well?  or just a "make install" ?
09:03 * masak .oO( you can never `leave` )
09:03 sortiz psch Me neither, just guessing :-)
09:03 psch sortiz: yeah.  the overlap is that the issue on r-j i'm trying to understand dies when trying to load NativeCall::Types
09:04 psch but reordering the provides in install-core-dist.pl didn't help there... :)
09:09 psch ...is it just me or does "handle data passed into a sub via a hash in order" seem somewhat impossible?
09:14 sortiz Seems so, and I think that in this case order matters.
09:16 psch i don't know.  it didn't seem to matter before... :)
09:17 psch and as far as i know no one touched CUR stuff since the moveable-precomp merge
09:17 psch which means the question is, did nadim see that error due to the merge or is something else going on?
09:19 sortiz There are lots of reports in where nuking the install or .perl6 solved the problem.
09:21 sortiz And travis-ci, as is always clean, don't show.
09:41 lizmat jnthn: looking at Junction, what is the reason for making $!storage a high level list (other than being able to .map on it?)
09:41 cognominal joined #p6dev
09:42 lizmat jnthn: also, what is the function of the STATEMENT_LIST symbol ?
09:56 dalek rakudo/nom: cf199c9 | lizmat++ | src/core/Junction.pm:
09:56 dalek rakudo/nom: Eliminate some dead code
09:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/cf199c9046
10:24 [Tux] lizmat, rakudobrew build moar
10:25 [Tux] but I can force a rebuild of everything by nuking the source code
10:27 lizmat [Tux]: rm -rf install; rm -rf ~/.perl   # what I just did
10:29 RabidGravy anyone want to close https://rt.perl.org/Ticket/Display.html?id=128091 as spam?
10:30 * psch can't close
10:30 psch but i did report it
10:31 psch i like how "How are we different from others" is one of their suggested questions, along with "REMOVE"
10:39 * bartolin marked 128091 as SPAM
10:40 psch ...that button is actually confusing :/
10:40 psch well, RT now says the ticket is deleted
10:44 [Tux] This is Rakudo version 2016.04-120-gcf199c9 built on MoarVM version 2016.04-26-g1088538
10:44 [Tux] test            22.437
10:44 [Tux] test-t          14.258
10:44 [Tux] csv-parser      36.310
10:44 [Tux] that is starting from scratch
10:49 lizmat [Tux] hhmmm... is this with blead from all ?
10:52 lizmat afk&
11:08 sortiz psch, about the install-core-dist.pl problem, it occurs to me in the script first try to uninstall that "CORE" distro and then proceed.
11:09 psch sortiz: it does?  it looks to me like it just tries to force install over it
11:12 sortiz Yes, but the forced install can't be in parallel, so, if as I suspect the problem is the order, that can be solved.
11:14 psch well, i strongly hope that whatever exactly the issue is it can be solved... :)
11:15 psch anyway, i'm not looking at anything broken in moar with install-core-dist.pl right now, r-j dies in there for a bit longer already
11:16 sortiz Ah, ok.
11:16 psch sortiz: i don't think having to order provides in a specific way (which, as it's a hash anyway, is kinda hard) is the right solution
11:16 psch sortiz: we'd probably need some kind of dependency detection if that's really the problem
11:21 sortiz psch, a few days ago I was asking if the provides keys can include a ':ver<x.y.z>', part that can help to solve this kind of problems, but get warnocked :(
11:22 psch i don't see how that can solve the current "we can't reinstall the same rakudo version into the same prefix" problem
11:23 psch and for any solution i can imagine (without a lot of actual code knowledge here, though) doesn't really need to know if the version is the same or great or anything
11:23 psch s/for//
11:25 sortiz Well, part of the problem is that those libraries, part of rakudo, aren't in settings, so should be installed like any other module, and exposed to the same problems about versioning and dependencies.
11:26 psch i don't think that's part of the problem that we can't force-install a distribution if it already is installed
11:26 psch i mean, it's a general concern with supplying standard libraries, yes
11:27 psch but it's not directly related to "we erronously reuse an already installed dependency of an already installed module that we want to force-reinstall"
11:32 sortiz I need to understand that part of the code. Right now I'm just speculating.
11:33 psch well, i'm mostly arguing from how i understand you see the problem :)
11:34 psch consider (1) we have a distribution installed (2) this distribution has two modules of which one depends on the other (3) we want to reinstall the same distribution (4) we get an error because installation of the depending module tries to use the installed dependency instead of force-installing the dependency first
11:34 psch i don't see any way to solve that with version checking alone
11:35 psch but yeah, i'm all for more people understanding the rakudo source, ++sortiz :)
12:03 bartolin btw, here is a gist with the issues I've seen with rakudo-j after the merge of 'relocateable-precomp': https://gist.github.com/usev6/607c0f00e4e6341a2276b9592e29bcda
12:04 bartolin maybe I should rakudobug that. any thoughts?
12:05 psch bartolin: i'm poking at the prefix thingy, but in general i'd say yes to RT tickets
12:05 psch even for what i'm poking at right now, 'cause i might not figure it out ;)
12:07 bartolin psch++ # poking :-)
12:58 [Tux] lizmat, yes
12:59 [Tux] command is rakudobrew build  moar-blead
12:59 [Tux] (previous paste was wrong. sorry if that caused confusion)
13:09 bartolin psch: reported as #128094
13:09 synopsebot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=128094
13:14 stmuk whats the status of the jvm build? is it getting better?
13:15 psch ...not really.  well, at least not on my end
13:15 psch it was working, but then the relocatable-precomp branch was merged :S
13:55 psch $ ./perl6-j tools/build/install-core-dist.pl /home/psch/rakudo/rakudo/install/share/perl6
13:55 psch installed!
13:55 psch that looks pretty good from here... :)
13:55 bartolin \o/
13:59 psch gonna check if building r-m into the same prefix works, and then gonna build with both backends, again into the same prefix
14:11 psch hm, "Missing or wrong version of dependency 'src/Perl6/Pod.nqp'" still
14:13 psch why is the precomp'd version of that in $prefix/share/nqp/..?
14:13 psch well, $prefix/share/nqp/lib/Perl6 to be precise
14:15 psch i mean, i'd have thought that share/nqp/ contains nqp libs
14:16 psch well, it's the same across the backends... vOv
14:23 TimToady joined #p6dev
14:49 psch hrm
14:49 psch actually i think my solution there is bad
14:50 psch what i'm doing is skipping the target repo in the repo chain when precompiling
14:50 psch but that obviously breaks when we're precompiling something that correctly has its dependencies already precompiled
14:52 psch yeah, i guess that'd mean dependecy analysis...
15:21 ugexe it might be nice to have some basic precomp api stuff (or a blog post on how to use what exists now) for invalidating/deleting precomps
15:21 ugexe like, say, .invalidate-rev-deps($dep-spec)
15:22 ugexe that might give enough to work with for the time being to allow the fully engineered solution to manifest
15:23 ugexe s/allow/allow time for/
15:26 * psch doesn't really understand CUR stuffs well enough to say if that's a good idea
16:12 jnthn lizmat: (On Junction's $!storage) just implementation convenience (so you can map on it, for example :))
16:13 jnthn lizmat: STATEMENT_LIST looks to be just another way to write nqp::stmts or so
16:13 jnthn lizmat: Equivalent to do { ... } but without the lexical scope I guess
16:20 timotimo that's right; i've used STATEMENT_LIST in JSON::Fast to make a loop curly-free
16:20 timotimo .o( curly-fries? )
17:00 TimToady another way to look at STATEMENT_LIST is that its semantics are like a C comma operator
17:01 TimToady it used to be SEQ, but we decided to de-overload sequences a bit
17:01 timotimo oh, in C you can get much better performance by using the comma operator? i have to put that into all MoarVM's code !!
17:02 TimToady C doesn't turn {} into closures, so you shouldn't really need that...
17:03 timotimo :)
17:03 TimToady what's really hilarious in C is the do { ... } while 0 workaround so that macros interpolate as single expressions
17:04 timotimo yeah, that's funny
17:04 timotimo should be possible to make a macro for that
17:04 TimToady .oO("Why should we fix the language when there's an arduous workaround we can inflict on generations of users?")
18:48 lizmat jnthn: since the type of junction is basically set at Junction creation time, and .Bool and .ACCEPTS all check what type they are
18:48 lizmat jnthn: would it be an idea to create a subclass for each type of Junction with dedicated .Bool and .ACCEPTS in them ?
18:49 lizmat so Junction.new(@a,:type<any>) would create an JunctionAny is Junction { method Bool {}, method ACCEPTS {} } ?
18:50 psch i have an urge to suggest "shouldn't that be role?" right here
18:51 psch +a
18:53 psch i think that's mostly memetic though
18:53 psch 'cause there's a lot "i find OO works easier with roles" in our echochamber
18:54 psch i do like the idea of having specific kinds of Junctions instead of one kind that has to handle multiple... kinds
18:54 psch s:1st,:2nd/kind/type/
18:54 lizmat m: dd (Junction.new((1,2,3),:type<any>) but role JunctionAny { }).WHAT
18:54 camelia rakudo-moar cf199c: OUTPUT«Junction+{JunctionAny}␤»
18:55 lizmat dd class JunctionAny is Junction { }; (JunctionAny.new((1,2,3),:type<any>)).WHAT
18:55 lizmat m: dd class JunctionAny is Junction { }; (JunctionAny.new((1,2,3),:type<any>)).WHAT
18:55 camelia rakudo-moar cf199c: OUTPUT«JunctionAny␤»
18:55 lizmat the reason for this is optimization, so whatever is fastest  :-)
18:57 psch that probably has to be measured, yeah
18:58 psch lizmat: i was more thinking < class AnyJunction does Junction { ... } >, fwiw
18:59 lizmat ah, that would work too  :-)
18:59 psch well, or JunctionAny of course vOv
18:59 psch the point being that there's, afaict, 4 spots where it matters what kind of Junction we have inside Junction.pm,
18:59 psch -,
18:59 lizmat yeah, which would allow you to create your own JunctionTwo easily  :-)
18:59 psch exactly
19:00 lizmat there's more places: sub any/all/one/none and infix | & ^
19:00 lizmat and methods Any.any/all/one/none
19:01 psch well, those have to create the correct junctions, yeah
19:01 psch -s
19:01 lizmat fwiw, I'm streamlining Junction atm
19:09 timotimo having multiple classes would also make junctions extendable
19:10 timotimo you already said that, i nee
19:10 timotimo see
19:11 lizmat making Junction a role, yes...
19:11 lizmat however, knowing that Junction is already set up in the BOOTSTRAP, is not going to make that easy, no ?
19:12 timotimo oh, er, hmm
19:17 lizmat so I guess mixing in a role or subclassing is more easily feasible, by the looks of it
19:18 psch i'd try something like "my stub Junction metaclass Perl6::Metamodel::ConcreteRoleHOW" or so in BOOTSTRAP.nqp
19:19 psch although that might be the wrong metaclass
19:20 timotimo hmm
19:20 psch we don't do anything like that yet though, which means nothing around to cargo cult
19:20 psch otoh, that might also mean "good idea to try to spot bugs"... :)
19:29 hankache joined #p6dev
19:34 dalek rakudo/nom: f9db924 | lizmat++ | src/core/Junction.pm:
19:34 dalek rakudo/nom: Eliminate some more dead code
19:34 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/f9db924db8
20:09 lizmat m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); nqp::iterval(nqp::shift($iter)) := 666; dd $h   # too bad this doesn't work
20:09 camelia rakudo-moar f9db92: OUTPUT«===SORRY!=== Error while compiling /tmp/M4w3laWjz7␤Cannot use bind operator with this left-hand side␤at /tmp/M4w3laWjz7:1␤------> ; nqp::iterval(nqp::shift($iter)) := 666⏏; dd $h   # too bad this doesn't work␤»
20:16 psch m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); $h{nqp::iterkey_s(nqp::shift($iter))} := 666; dd $h
20:16 camelia rakudo-moar f9db92: OUTPUT«{:a(666)}␤»
20:16 psch i don't think we have any nqp op that returns an l-value, do we?
20:17 lizmat psch: not sure
20:19 lizmat m: use nqp; my $h := nqp::hash("a",42); my $iter := nqp::iterator($h); my $a := nqp::iterval(nqp::shift($iter)); $a := 666; dd $h  # no error, but not the right thing either
20:19 camelia rakudo-moar f9db92: OUTPUT«{:a(42)}␤»
20:25 timotimo we obviously need an "akteyerf" object :P
20:25 lizmat no, not obviously
20:26 lizmat it would just simplify one case in the autothreader
20:26 timotimo ah, when we autothread over a hash?
20:26 lizmat yup
20:26 lizmat no, when we autothread with named parameters
20:28 timotimo oh
20:28 timotimo oh!
20:29 timotimo yeah, now i get it :)
20:30 timotimo we could split the list of nameds into "part that get changed" and "part that stays the same" and "just" flatten them together in the invocation. i wonder if that's fast at all
20:31 lizmat well, it's already pretty naughty, :-)
20:40 timotimo oh, i remember that part! :D
20:44 jnthn lizmat: I think having a type explosion around Junction would be ugly. I the end we should be able to compile simple given/when over integers into jump tables, at which point it'll be pretty cheap as it is today with the flag.
20:44 lizmat what about the idea of a Junction Role ?
20:44 jnthn What would that win us?
20:45 lizmat the possibility to create things like two() that would be true if two in the junction were true ?
20:45 lizmat see earlier discussion
20:45 jnthn It's possible today, just subclass. :)
20:46 lizmat ok, fair enough  :-)
20:46 jnthn But since you have to check all the things anyway, you don't come out ahead of a .grep(...).elems, I'd guess?
20:47 lizmat yeah, in that case, yes
20:47 jnthn Well, you can short-circuit on the third I guess :)
20:47 timotimo oh, of course you can do it with a subclass
20:47 * timotimo facepalms
20:47 timotimo i should have seen that
20:47 lizmat timotimo: that was my original idea  :-)
20:47 jnthn But I can't say I've seen a lot of demand for such a feature :)
20:48 lizmat true, I was just looking at optimizing  :-)
20:49 lizmat fwiw, I'm trying to measure the changes I did to method AUTOTHREAD
20:49 lizmat but I can't seem to get it called  :-(
20:49 lizmat jnthn: do you have a simple example of autothreading I could use for benchmark ?
20:50 jnthn m: sub foo($a) { say Backtrace.new.full }; foo(1 | 2)
20:50 camelia rakudo-moar f9db92: OUTPUT«  in block  at gen/moar/m-CORE.setting line 20861␤  in method new at gen/moar/m-CORE.setting line 20862␤  in sub foo at /tmp/1s_QBz9DS7 line 1␤  in block  at gen/moar/m-CORE.setting line 7374␤  in method sink-all at gen/moar/m-CORE.setting line 419…»
20:50 jnthn m: sub foo($a) { say Backtrace.new.full ~~ /AUTOTHREAD/ }; foo(1 | 2)
20:50 camelia rakudo-moar f9db92: OUTPUT«「AUTOTHREAD」␤「AUTOTHREAD」␤»
20:50 jnthn Seems that hits it?
20:51 lizmat yup
20:57 lizmat I was also thinking of adding really async autothreading
20:57 lizmat jnthn: or do you have any specific ideas about that ?
21:00 lizmat was thinking of farming off if there are more than 100 states
21:00 jnthn lizmat: I think it's get .race and .hyper really solid first, and then just do it in terms of those :)
21:01 jnthn s/it's/I'd/
21:03 lizmat ok
21:17 dalek rakudo/nom: e093ccd | lizmat++ | src/core/Junction.pm:
21:17 dalek rakudo/nom: Make autothreader 2x to 3x faster
21:17 dalek rakudo/nom:
21:17 dalek rakudo/nom: - my @a = flat 0 xx 999, 1; sub a($a) {$a}; for ^100 {++$i if a(@a.any)}  # 2x
21:17 dalek rakudo/nom: - my @a = flat 1, 0 xx 999; sub a($a) {$a}; for ^100 {++$i if a(@a.any)}  # 3x
21:17 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e093ccd6d4
21:18 timotimo *nice*
21:20 jnthn lizmat++
21:20 lizmat that's only part 1  :-)
21:21 timotimo jnthn: calling .list on a Channel from multiple threads is no problem, correct? we might want to note that as an explicit "good pattern" in the docs, then
21:22 jnthn Well, so long as you know that they're racing :)
21:22 jnthn I'd be reluctant to call it a good pattern
21:22 timotimo yeah, in this case i'm spreading work out to multiple workers
21:22 timotimo that's the "good" kind of race, right?
21:22 jnthn Yeah
21:23 jnthn In that whether it's good is highly situational
21:23 jnthn I mean, it's fine if the work isn't very fine-grained.
21:23 jnthn And if you don't need it to scale
21:23 jnthn (As in, you don't expect to be doing it in tons of places)
21:23 jnthn 'cus it actually ties up the thread doing the iteration.
21:24 timotimo um, i'm not sure i understand
21:24 jnthn But those aside, yes, it's a good thing.
21:24 timotimo ties up the thread that does the iteration?
21:24 jnthn for $channel.list { } # between receiving items, the thread doing the looping is blocked and can't be used for anything else.
21:26 timotimo oh, right
21:27 timotimo well, that wasn't a notable thing for me, because i expected it to be like that
21:27 jnthn Right, as I said, it's situational, just something to be aware of :)
21:27 jnthn I'm always reluctant with things like "good patterns" and "best practices".
21:28 jnthn 'cus they get carried away without their context... :)
21:28 timotimo that's true
21:28 timotimo happens way too often in comp-sci, and probably everywhere else, too
21:49 dalek rakudo/nom: 626b5a9 | lizmat++ | src/core/ (2 files):
21:49 dalek rakudo/nom: Make Any.any|all|none|one 14x faster
21:49 dalek rakudo/nom:
21:49 dalek rakudo/nom: - create internal SET-SELF method which also tests for valid type
21:49 dalek rakudo/nom: - add another Junction.new candidate that only uses positionals
21:49 dalek rakudo/nom: - call new positional Junction.new from Any.any|all|none|one
21:49 dalek rakudo/nom: - no longer listify inside Any.any|all|none|one, as SET-SELF does that
21:49 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/626b5a9caf
21:51 timotimo damn. that's a fine improvement
21:58 lizmat good night, #p6dev
21:59 jnthn 'night, lizmat :)
22:00 lizmat oh, BTW
22:00 lizmat I'm not sure hyper/race would be a good fit for authothreading
22:00 lizmat as they would need to short-circuit
22:01 lizmat will sleep on that more&
22:07 timotimo i somehow b0rked the naive version :\
22:09 jnthn lizmat: last works in map/grep :)
22:10 timotimo i think it was about using when directly inside a while ($_ = ...) { } loop
22:10 timotimo but what do i know
22:18 timotimo Internal error: zeroed target thread ID in work pass
22:18 timotimo sorry, jnthn, i can't figure out how much faster it is :(
22:18 jnthn grmbl
22:19 jnthn Guess it ran into one of the outstanding things to fix in that branch
22:19 timotimo could be, yeah
22:19 jnthn I had it in single-threaded tests too :)
22:20 timotimo let's see if it can do the naive non-threaded version
22:22 timotimo hm, might be that it's a tiny bit faster
22:29 timotimo do we have something that makes reading ascii encoded files ridiculously fast by ignoring the whole NFG thing?
22:33 jnthn It can't totally ignore it since \r\n is a synthetic
22:33 timotimo oh
22:33 timotimo beh.
22:35 jnthn But it saves on the UTF-8 decoding of course :)
22:36 jnthn Last I checked though the most expensive part of reading lots of small lines was malloc/free of buffers :P
22:36 timotimo i'd expect i can get a nice factor improvement by using Buf instead of Str here
23:13 timotimo oh, btw
23:13 timotimo perf says 45% in fixed_size_alloc, 6% in fixed_size_free
23:16 jnthn timotimo: Yeah...that's part of what reframe already gets rid of, and will later rid us of more in there
23:16 timotimo yup
23:16 jnthn FSA also wants to get better :)

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