timotimo | i did nothing at all for moarvm today :( | 00:37 | |
00:54
rblackwe joined
00:59
cognominal joined
01:27
jnap joined
02:47
ilbot3 joined
03:37
sorear joined
04:23
jnthn joined
07:26
FROGGS joined
|
|||
FROGGS | o/ | 07:31 | |
diakopter | €£¥₩ | 07:59 | |
FROGGS | yeah, scratch that | 08:20 | |
diakopter | ? | ||
FROGGS | your signs have scratches | 08:21 | |
chars | |||
w/e | |||
diakopter | ah, so they do | ||
masak | twitter.com/FakeUnicode/status/430...6087447552 | 08:26 | |
08:41
odc joined
|
|||
FROGGS | haha! | 09:52 | |
that is something for a nice t-shirt | 09:55 | ||
masak: do you know the sad thing? nobody at work does understand that joke -.- | 12:57 | ||
masak | clearly they need to learn more about Unicode. | 13:04 | |
FROGGS | yeah :/ | 13:08 | |
13:33
jnthn joined
|
|||
nwc10 | OK, I think that the reason that I am getting into such a mess with the submodules is that | 13:43 | |
git checkout $commit # does not update the position of submodules | |||
but | |||
git add -u # does stage submodules | |||
with the result that you can inadvertently commit changes to the submodule state without actually touching them | 13:44 | ||
this inconsistency is hateful | |||
masak | nwc10: I was *just* reading about this. | ||
timotimo | isn't that just the same as the regular behavior of the staging area? | ||
if you don't git add a change, you won't get it | |||
nwc10 | no, my issue is that git checkout $commit | 13:45 | |
doesn't cleanly move you to the state of history at that commit | |||
timotimo | and you have to git add submodule changes (commits) as if they were changes to a single file | ||
masak | nwc10: see stackoverflow.com/questions/1992018...-initially and stackoverflow.com/questions/1260748...-submodule | ||
nwc10 | it *ought* to also update the sumodules | ||
timotimo | oh, you mean checkout on the *outer* part | ||
nwc10 | yes. at the top level | ||
masak | nwc10: there's one entry in the tree object in the object database, and one entry in .gitmodules | ||
nwc10 | and a reference in .git/config too | 13:46 | |
a "mention" to be clear | |||
not an SHA-1 | |||
masak | 对对 | 13:48 | |
nwc10 | oh, and you can't @tirade_of_expletives git stash a submodule chance | 13:56 | |
change | |||
so that doesn't work *either*, if you're used to the idea of `git stash` takes me to a clean state | |||
it is fucked up. | |||
it takes all the nice linear (ish) concepts of plain git and makes it as fun as subversion | |||
OK, I am now torturing NQP master. Let's see how long before that hits a bug I'm not yet aware of | 13:59 | ||
timotimo | oh ... yeah :| | 14:00 | |
14:01
jnap joined
|
|||
nwc10 | more usefully, I'm torturing with this bug fixed: paste.scsys.co.uk/299937 | 14:04 | |
torture "fail" will be any time within about 24 hours | 14:05 | ||
pass takes at least 24 hours | |||
timotimo | wow | 14:21 | |
nwc10 | slow, but worth it for the insight | 14:22 | |
timotimo | aye | 14:23 | |
nwc10 | had something like "on the 81500th nursery allocation something is allocated. 128 allocations later something stored a pointer to it. 14 allocations later it used that pointer" | ||
ie missing write barrier | |||
timotimo | that's amazing | 14:24 | |
i wish it weren't that slow :( | |||
at some point we really should look into getting moarvm up to -O3 | 14:25 | ||
nwc10 | anyone could do this. I'll guess that it needs -fno-strict-aliasing | 14:26 | |
which means that the C code isn't really C | |||
timotimo | mhm :\ | ||
can you tell how to fix that? | |||
nwc10 | aliasing violations - no, not trivially | 14:27 | |
it's something I don't understand well | |||
timotimo | okay :\ | ||
nwc10 | but any cast that isn't to/from char * is a problem | ||
and we should be using unions rather than ever more casts | |||
timotimo | aye. | ||
nwc10 | but for now, see if it will build with `-O3 -fno-strict-aliasing` | ||
timotimo | i will | ||
nwc10 | or even -O2 -fno-strict-aliasing | ||
timotimo | can we put unions "in there" just to tell gcc to not change the structs around? | ||
nwc10 | I can't answer that easily, and certainly not while trying to be at work | 14:29 | |
diakopter | nwc10: what's the "previous commit" mentioned in the commit message of the url you just pasted | ||
nwc10 | diakopter: yes. | ||
diakopter | er, I mean, which/where is it? :) | ||
timotimo is getting into the rakudo compilation stage with -O3 -fno-strict-aliasing | |||
nwc10 | paste.scsys.co.uk/299952 | 14:30 | |
I told jnthn about it privately, but I wasn't yet sure that it was | |||
a) correct | |||
b) the only one | |||
timotimo | Stage parse : 43.553 | 14:31 | |
14:32
colomon joined
|
|||
timotimo | Stage parse : 45.637 | 14:33 | |
the first one was with -O3, the second one with -O1, both with -g3 | |||
nwc10 | -O2 and -Os would both also be interesting. It may be that -O3 and -O2 are pretty close | 14:34 | |
actually IIRC -O3 is documented as "might turn out to be slower" | |||
diakopter | nwc10: I'm also not 100% sure that's correct. did jnthn think it was? | 14:35 | |
timotimo | oh? | ||
diakopter | "that" = the whole repossession write barrier thing | ||
(I'm just looking at that code now for the first time) | 14:36 | ||
nwc10 | diakopter: jnthn had just the + and - lines pasted to him on IRC | 14:37 | |
and thought (from that) that it looked sane | |||
certainly, the problem is that the LHS of that assignment ends up with cache item [4] being in the nursery, but the object on the LHS of the assignment isn't flagged as being a nursery root | 14:38 | ||
timotimo | with -O2 i get Stage parse : 45.744 | 14:40 | |
nwc10 | oh, interesting, thanks | ||
diakopter | nwc10: I agree it looks sane assuming the rest of the code I haven't reviewed is correct. :) | 14:44 | |
14:47
benabik joined
|
|||
diakopter | there's a very ethereal stack of assumptions the code is making I haven't confirmed yet [not that it's a bad thing; just the normal uncertainties when only partially reviewing new code] | 14:47 | |
timotimo | diakopter: are you going to be implementing the moarvm-perl5-interop in secret? if so, have you already started doing anything code-like? | 14:48 | |
14:49
ggoebel1113 joined
|
|||
diakopter | 1. no 2. it's a secret | 14:50 | |
seriously though.. yes I have a handful of starts in that direction | 14:51 | ||
timotimo | you got me a handful excited :) | 14:53 | |
diakopter | well franky I think the high-level profiler will be far more use to everyone for quite a while | 14:54 | |
er. | 14:55 | ||
*frankly | |||
timotimo: especially you :) | 14:59 | ||
I suspect there are many hundreds of valuable optimization opportunities in 1. the nqp source of the compiler 2. the qast emitted by both nqp's and rakudo's compilers and 3. rakudo's setting | 15:02 | ||
.. which will almost certainly improve performance on all 3 backends for the foreseeable future... | 15:05 | ||
not to mention 4. the C/Java source of the runtime in all 3 backends, which will also be revealed indirectly (or directly, if the per-mast/jast/pirt bytecode profiler works without unbearable space/time requirements) | 15:08 | ||
[if someone makes the profiler work on the jvm and parrot backends too, which wouldn't be too onerous] | 15:10 | ||
benabik | I still want to create a data-flow framework. Never ended up doing it for PAST, but maybe I could do so for QAST. | 15:16 | |
timotimo | ooooh | 15:19 | |
that would allow for great optimizations | |||
benabik | That was the general idea, yes. | ||
Of course, I don't really have the spare time. Maybe if my advisor can't hire me over the summer... Is Perl6 going to be in GSoC this summer? | 15:20 | ||
FROGGS | benabik: we hope so | 15:21 | |
benabik: and we're doing our best so this can happen | |||
benabik | I'd offer to help mentor, but I might need to apply for the moneys instead. :-) | ||
nwc10 | benabik: you are a student, at least in Google's eyes? | 15:27 | |
benabik | nwc10: I'm enrolled in a university. :-) Grad studies take a nice long time, so I'll be eligible for GSoC for a while yet. | 15:28 | |
nwc10 | If participating in GSoC as a student buys you time to work on @stuff, then I feel that you could contribute more as a student than a mentor | 15:29 | |
the bigger shortage is usually competant students who can deliver cool stuff without needing massive mentoring | |||
eg, compare what pmurias did with the other 2 last year | |||
benabik | Yes, but my grad assistantship pays better. So if I get that, I'd rather do research and help by mentoring. | 15:30 | |
timotimo doesn't know what the other 2 students did | |||
nwc10 | "parrot stuff" | ||
the final reports should say. | |||
timotimo | mhm | 15:31 | |
i'm still very much looking forward to pmurias++ being able to resume his work | |||
nwc10 | to be scrupulously fair, pmurias's stuff isn't merged in yet | ||
and I'd love to see that happen. and get to (at least) a merged working NQP | |||
benabik: what you say, by my reasoning, implies that GSoC doesn't buy you time. | 15:34 | ||
benabik | nwc10: Need to pay attention to the bottom line, sadly. Already working hard to stay afloat, can't take the pay cut to work on GSoC if I can avoid it. :-( | 15:37 | |
nwc10 | yes, prioritise food, rent and sanity | 15:41 | |
rurban__ | I volunteered as MoarVM JIT mentor for gsoc. Is this okay? | 16:24 | |
But the luajit framework seems to be the best, and I have no experience with that. Yichun Zhang would be the best for this | 16:26 | ||
timotimo | isn't it very early to be thinking about jit? (not complaining, though) | 16:27 | |
rurban__ | JIT influences the VM design overall | 16:29 | |
timotimo | ah, that sounds very legit | ||
diakopter | a lot of thinking has already gone into MoarVM's jit | 16:31 | |
timotimo | and i don't know anything about these thinkings :( | ||
diakopter | and it has already influenced the VM design overall a lot | ||
timotimo: right, again, one of those things that would take a lot longer to communicate all the rationale and methodology and requirements and VM interaction constraints than feasible for jnthn to do heretofore. | 16:34 | ||
timotimo | ah, yes | ||
diakopter | rurban__: I think gsoc 2014 is too soon for jnthn to be able to mentor that project appropriately, but maybe he'll change his assessment and weigh in differently than he has in the past on this topic | 16:38 | |
rurban__ | I see. Well someone addded this task to the gsoc ideas list. It wasn't me :) | 16:40 | |
diakopter | hm | 16:41 | |
rurban__ | leto maybe | ||
Oh, it was froggs | 16:42 | ||
diakopter | the fact that no one has removed the rperl listing from the gsoc ideas list is... breathtakingly demoralizing | 16:48 | |
timotimo | what is rperl? | 16:49 | |
diakopter | you don't want to know | ||
timotimo | but now i don't understand! | ||
diakopter | this should inform your understanding: www.faqs.org/patents/app/20080216064 | 16:51 | |
timotimo | it's a challenging read | 16:57 | |
diakopter | that's what the examiner said, but much more bitterly and at length | 17:14 | |
timotimo | sorry, i have no clue what you would like me to understand about all this | 17:18 | |
benabik | rperl.org ? | 17:20 | |
diakopter | you weren't meant to read the whole patent application; I expected you to immediately recognize the utter insanity of every aspect of that application, and scoff bitingly at the world we live in where a patent lawyer would take the money of a madman to submit a incoherent flight of fancy that is clearly the ravings of a lunatic | 17:22 | |
the rperl proposal is not quite as grandiose or indicative of hypergraphia, but it's just as impractical and absurd | 17:26 | ||
jnthn | *sigh* backlog... | 17:28 | |
nwc10: On submodules, at one $client we added a git checkout hook that forced sync of the submodules on each checkout. It may help for you. | 17:32 | ||
diakopter | to equivocate a tad, in that patent app, there are a few kernels of good, novel ideas... but you have to be very "flexible" in your thinking to imagine them. | 17:41 | |
jnthn | rurban__: I'm really not at all comfortable with you mentoring a MoarVM JIT project; for one, you've not been working on MoarVM so far, and for another I know we make design calls rather differnetly, and in MoarVM they need making my way if we're going to get a consistent design. | 17:42 | |
17:43
FROGGS joined
|
|||
jnthn | As for timing, the specialization stuff should come before the JIT. It *may* be there in time. I hope it will be. It's harder to be certain. | 17:44 | |
diakopter | given that the gsoc projects nail down their requirements in april.. | ||
jnthn | Yeah. I'd *like* to be some way along with the specializer by then. | ||
I suspect I'll start impleenting aspects of it in Feb. | 17:45 | ||
Though not sure how far I'll get besides the dominance/SSA stuff. | |||
timotimo | diakopter: ah! i was trying very hard to make the connection between virtualisation and meta-operating-systems to rperl | 17:55 | |
FROGGS | so, what exactly did I do wrong? :o) | 18:25 | |
diakopter | who what where? :) | ||
jnthn | FROGGS: EVERYTHING!!! | 18:26 | |
:P | |||
FROGGS | :P | ||
jnthn isn't aware of anything in particular :) | |||
Guess that means I need to git pull? :P | |||
FROGGS | jnthn: no, I was talking about GSoC ideas page atm I think | 18:27 | |
jnthn: but I'd love to talk to you about openpipe | |||
the op | |||
jnthn: do you have a second? | |||
jnthn | yeah, though this train is not the smoothest and looking at the laptop is making me a little ill... | 18:28 | |
Go ahead, anyway. | |||
FROGGS | its signature is like: openpipe(MVMThreadContext *tc, MVMString *cmd, MVMString *cwd, MVMObject *env, MVMString *err_path) | ||
I am missing the directions and redirections there... | 18:29 | ||
like for open("wc", :r, :w, :p) | |||
jnthn | Is that supported on any backend? | ||
FROGGS | or: run("wc", :in, :out, :err(:out)) | 18:30 | |
jnthn: no | |||
but it is something that is specced and does not break existing code | |||
I just think that the err_path param is weird, and needs to be replaced by others | 18:31 | ||
jnthn | Are :r and :w pipes actually separate? | ||
What is err_path for? | |||
That is, if you :p :r :w then you get a read pipe and a write pipe? | |||
FROGGS | that is about stderr redirection of the child process I think | ||
jnthn: yes, you get an IO::Pipe which you can print to and read from | 18:32 | ||
I'd respec it to have .in, .out and .err filehandly things | |||
jnthn | :r and :w would be :in and :out? | 18:33 | |
jnthn wonders if we should really be doing this with open... | |||
FROGGS | if you'd checkout wip-openpipe in MoarVM and rakudo then you'd already have a working qx btw | ||
jnthn: no | |||
I propose that you can do: open(Str, :w, :r, :p) and run(Str, :in, :out, :err) | |||
jnthn | Why keep the :P in open and not just say "use run"? | 18:34 | |
uh, :p | |||
FROGGS | I think we should keep open(:p) because it might be used somewhere | ||
jnthn | What do :w and :r mean on open? | 18:36 | |
What do you get back? | |||
FROGGS | and open() is not that bad because you have to .close it for example | ||
an IO::Pipe | 18:37 | ||
and if you do: $fh = open("wc", :w, :p); $fh.say("hello"); $fh.close | |||
jnthn | r: my $h = 'README'.IO; $h.open(:r); say $h.get | ||
camelia | rakudo-parrot 44ab3c: OUTPUT«Unable to open filehandle from path '/home/p6eval/README': No such file or directory(2) in method open at gen/parrot/CORE.setting:13219 in method open at gen/parrot/CORE.setting:13208 in block at /tmp/tmpfile:1» | ||
..rakudo-jvm 44ab3c: OUTPUT«java.nio.file.NoSuchFileException: /home/p6eval_eval/README in method open at gen/jvm/CORE.setting:13179 in method open at gen/jvm/CORE.setting:13169 in block at /tmp/tmpfile:1» | |||
..rakudo-moar 44ab3c: OUTPUT«Failed to open file: no such file or directory in method open at src/gen/m-CORE.setting:13177 in method open at src/gen/m-CORE.setting:13167 in block at /tmp/tmpfile:1» | |||
FROGGS | you are actually operating on $fh.in | ||
jnthn | r: my $h = 'perl6'.IO; $h.open(:r); say $h.get | 18:38 | |
camelia | rakudo-parrot 44ab3c: OUTPUT«Unable to open filehandle from path '/home/p6eval/perl6': No such file or directory(2) in method open at gen/parrot/CORE.setting:13219 in method open at gen/parrot/CORE.setting:13208 in block at /tmp/tmpfile:1» | ||
..rakudo-jvm 44ab3c: OUTPUT«java.nio.file.NoSuchFileException: /home/p6eval_eval/perl6 in method open at gen/jvm/CORE.setting:13179 in method open at gen/jvm/CORE.setting:13169 in block at /tmp/tmpfile:1» | |||
..rakudo-moar 44ab3c: OUTPUT«Failed to open file: no such file or directory in method open at src/gen/m-CORE.setting:13177 in method open at src/gen/m-CORE.setting:13167 in block at /tmp/tmpfile:1» | |||
jnthn | > my $h = 'README'.IO; $h.open(:r); say $h.get; | 18:39 | |
Rakudo Perl 6 | |||
I'm worried design wise here 'cus if you pass :p there...the IO::Handle cannot suddenly become an IO::Pipe... | |||
FROGGS | why not? | ||
jnthn | Note that I never use a return value from open... | 18:40 | |
FROGGS | :bin will give you a buf instead of a Str, that is the same thing | ||
jnthn | > my $h = 'README'.IO; say $h.WHAT; $h.open(:r); say $h.get; | ||
(IO::Handle) | |||
Rakudo Perl 6 | |||
FROGGS | hmmm | ||
jnthn | What you be able to .get on something you open('...@', :p)'d one? | 18:41 | |
FROGGS | I can't parse the question | ||
jnthn | my $h = open('something_that_pipes_output', :r, :p); say $h.get; # does it work, I do I have to $h.in.get ? | 18:42 | |
FROGGS | I think it should work | 18:43 | |
(and should be the same as $h.out.get) | |||
jnthn | uh, yeah, I meant out | ||
But it's out, not err, yes? | |||
With open you can't get at the err pipe or request something with it? | 18:44 | ||
FROGGS | .get would default to .out | ||
there is currently no way to tell open something about err | 18:45 | ||
this perlcabal.org/syn/S32/IO.html#IO::Pipe tells something about: ($r, $w) = IO::Pipe.pair; | 18:46 | ||
but that is pretty weird imo | |||
jnthn | I guess then that we could kinda make it so open with :p gives back something with the same kinda API as without... | ||
I can kinda buy the "something already uses it" argument... | |||
...but we tend to lean away from designs where a named arg causes a different return type. | 18:47 | ||
FROGGS | I agree | ||
jnthn | Put another way, I'm wondering if :p on open is partly a "Perl 5 had it that way so we copied it" thing rathre than a "this is the design we want" thing... | ||
FROGGS | I can't tell :o) | 18:48 | |
TimToady++ did not comment on that so far | |||
jnthn: do you know about a windows command line tool that I can pipe to? | 18:51 | ||
timotimo | hah, that could be read as TimToady++ # did not comment on that so far | ||
:P | |||
jnthn | FROGGS: more? :) | ||
FROGGS | something that reads from stdin and blocks? | ||
hehe | |||
clearly a win! | |||
hmmm, lets see | 18:52 | ||
timotimo | pass some variable that will get the pipe assigned to it as the named parameter :P | 18:53 | |
FROGGS | wut? | ||
nah | |||
jnthn | FROGGS: Maybe "sort"? | 18:55 | |
FROGGS | jnthn++ | 18:56 | |
both will do | |||
jnthn | C:\consulting\rakudo-moar>type README | sort /reverse | ||
Rakudo Perl 6 | |||
AUTHOR Where to get help or answers to questions Submitting patches | |||
:) | |||
bah, om nom line breaks | |||
18:57
tgt joined
18:59
benabik joined
19:23
FROGGS joined
19:39
tgt joined
|
|||
FROGGS | ahh | 19:50 | |
jnthn: "more".IO.pipe would give you an IO::Pipe of course | |||
like we handle IO::Path today | |||
I will come up with a proper solution within the next days | 19:51 | ||
though, $dayjob time now :o( | |||
jnthn | timotimo: What's current status of little big int work? Or small big int? Which branch is the active one? | 20:10 | |
timotimo: I am interested to give some tuits to help it along at some point in the next few days. | |||
timotimo | little_big_int is the branch i'm working on, i have some WIP things locally | 20:11 | |
also, there's stuff in the frying pan right now | |||
i don't think i've got a sufficiently sane design to go ahead with | 20:12 | ||
jnthn | Would it help if I sketched out the overall idea of what I was aiming for data structure wise, and then do a couple of ops as examples, and pass it back? | ||
timotimo | that would be good, yes | ||
jnthn | ok | 20:13 | |
I'll see how I feel when I get off this train and back home | |||
Otherwise it'll be tomorrow. | |||
timotimo | i've got as far as making a proper union for the lbi vs mp_int * | ||
when would the former be? | |||
one thing i noticed very late into the development process is that libtommath also has alternatives for bigint + a "digit" (where a digit refers to an unsigned long, i think) | 20:14 | ||
so we can harness the power of that rather than upgrading to two full big ints sometimes | |||
jnthn | Depends how late it's running... :P | 20:15 | |
Gosh, it's on time.... | |||
timotimo | wow! | ||
jnthn | So 10:45pm or so | ||
timotimo | what'? your right-now? | ||
er | |||
what's your time right now? | |||
nwc10 believes jnthn is at 21:16 | 20:16 | ||
timotimo | ah, so that's the same local time as mine | ||
good. | |||
maybe i'll push my shitty WIP code until then | |||
but first i'll handle the nom in my pan | |||
jnthn | timotimo: In Sweden; same as yours... | 20:18 | |
timotimo | in sweden, time zone is the same as *you*! | 20:19 | |
FROGGS | "parrot threads have a radical performance advantage over MoarVM threads" - do we already have threads? | 20:23 | |
or should I read it as "non existing threads are slower than existing ones" ? | 20:24 | ||
jnthn | uh, lol? :) | ||
timotimo | in what context was that said? | ||
jnthn | In the context of utter cluelessness :P | ||
FROGGS | here wiki.enlightenedperl.org/gsoc2014/ideas | ||
I guess rurban wrote it | 20:25 | ||
timotimo | what could he have meant? | 20:26 | |
FROGGS | I dunno | ||
I am thinking about that for half an hour now | |||
is there a whitepaper about MoarVM thread design? | 20:27 | ||
jnthn | No, 'cus I barely have time to make stuff work, let alone write whitepapers :P | 20:28 | |
FROGGS | or maybe he has heard about its design in a talk and that is his conclusion of the design or so | ||
jnthn | The goal for MoarVM in this area is "provide what Rakudo's concurrency needs" | ||
Note that in my recent talk, building on top of JVM threads we got a factor of > 3 speedup with a not exactly stellar concurrent factoring on a quad-core box. | 20:29 | ||
timotimo | that's an advantage to parrot threads, but not necessarily a performance advantage/disadvantage | ||
jnthn | In that particular example. | ||
timotimo | only imagine what speedups parrot threads could offer! | 20:30 | |
maybe as far up as 9001x! | |||
FROGGS | yeah, I tried to use parrot's threads | ||
jnthn | Well, given that a factor of 4 is essentially "perfect" here... | ||
FROGGS | it is okay unless you want to access lexicals | ||
true | |||
timotimo | well, that's exactly what rurban proposes to fix, isn't it? | 20:31 | |
FROGGS | I think so | ||
and maybe the bug I have heard about that something in NQPLexpad makes it crash when you are not super careful | |||
I think he said once that the NQPLexpad is not thread safe | 20:32 | ||
timotimo | oh | ||
FROGGS | dunno if parrot's threads can effectively utilize more than one cpu if you access lexicals in the worker thread | 20:33 | |
(or if any other threading model can do that, I am a n00b here) | |||
jnthn | NQPLexpad is safe enough in the traditional meaning of thread safe in so far as you do hash lookups and write the result into a register. | 20:34 | |
nwc10 | bother. There is something unrooted that torture can't (yet) spot because it gets shoved into gen2 at just the wrong time | ||
jnthn | And the hash lookups are reads. | ||
And register stores that matter for VM safety are atomic. | 20:35 | ||
The problem is that Parrot wants more than that. | |||
afaict, it wants you to do every piece of inter-thread communication by scheduling a task. | 20:36 | ||
FROGGS | correct, by spawning a green thread | ||
I did that when playing with hyper ops | |||
jnthn | The benefit is that threads can then run completely independently and GC when they like. | ||
timotimo | that doesn't immediately strike me as superior in terms of performance, except for the GC thing jnthn just mentioned | 20:37 | |
jnthn | The downside is that even reading a lexical needs that overhead. | ||
FROGGS | you actually can't read in a lexical within that green thread, this one would explode | 20:38 | |
you have to create an os thread within that green thread that does the work | |||
at least that is what I learned last autumn | |||
20:44
jnap joined
20:46
diakopter left
21:26
crab2313 joined
22:03
ssutch joined
22:42
lue joined
|
|||
nwc10 | jnthn: are all STables the same size? | 22:56 | |
jnthn | nwc10: Yes | 22:57 | |
nwc10 | good. :-) | ||
that means that all gen2 STables will be in the same place | |||
bother. 30G is not enough to torture the other bug out | |||
jnthn | Ugh | 22:58 | |
nwc10 | there's not much more RAM left | ||
so I have a plan B | |||
but that's for tomorrow | |||
jnthn | Did the patch for the cache thing make it somewhere? | ||
nwc10 | to a paste :-) | ||
so, no, not really | |||
would you like it right now? | 22:59 | ||
jnthn | Don't suppose you've the paste handy? | ||
nwc10 | I am trying (and failing) to get to sleep | ||
jnthn | Well, it's the kinda easy-ish thing I can do now, while tired but not tired enough to sleep :) | ||
nwc10 | jnthn: paste.scsys.co.uk/299952 | 23:00 | |
I believe that there is a second missing write barrier somewhere for assignment to an STable | 23:01 | ||
this is the one that I am having trouble finding | |||
obviously, there might be 3 or more. :-( | 23:02 | ||
but I'm suspicious/hopeful/overconfident? that that's unlikely | |||
in that, if I drop the nursery size, my SEGV goes away. Which I think is because something has managed to be promoted to gen2 before it got used in an assignment | 23:03 | ||
timotimo | jnthn: a friend suggested to me to have "get_bigint" always allocate an mp_int as first approximation and at the end of the calculations always free it again | ||
and to have a "set_bigint" function that can create an LBI or keep the existing big integer | |||
i thought that sounded like a sane idea, but i didn't get much further than that | 23:04 | ||
dalek | arVM: bbf922e | nicholas++ | src/core/interp.c: Add a missing write barrier in OS settypecache. If the result of MVM_repr_at_pos_o() is in the nursery, then a write barrier is needed to ensure that the STable whose cache is being set becomes correctly marked as a nursery root, and hence Object addresses in the cache get updated. |
23:08 | |
arVM: af99e23 | jnthn++ | src/core/interp.c: Missing write barrier in setwho. |
23:18 | ||
arVM: c369985 | jnthn++ | src/core/interp.c: Missing write barrier in setboolspec. |
23:21 | ||
arVM: 78459b3 | jnthn++ | src/6model/serialization.c: Missing write barriers in invo-spec deserialize. |
23:25 | ||
timotimo | seems like jnthn is a bit quicker at finding missing write barriers %) | 23:26 | |
dalek | arVM: 684be81 | jnthn++ | src/6model/reprs/P6opaque.c: A few missing P6opaque REPR data write barriers. |
23:44 | |
timotimo | jnthn: another thing i noticed is that when creating a big integer, libtommath has a default alloc size of 32 | 23:45 | |
there is a -DMP_LOW_MEM flag that changes that to 8 | |||
i could not observe a memory usage improvement, which may be because we have mp_shrink in all the right places or something | 23:46 | ||
jnthn | nwc10: I did an audit of all the places (afaict) that assign into an STable, and found various missing write barriers. All on rare codepaths, but no more rare than the settypecache one. | ||
nwc10: Patched all I could find. Hope it might help. | |||
timotimo | 32 x sizeof mp_digit | 23:47 | |
jnthn | What is sizeof mp_dicit? | 23:48 | |
I don't know it'll make a difference in a big way to starting memory size | |||
BUT if you make an array of 100,000 Ints I get you spot it. | |||
timotimo | possibly 64 bits | ||
depends heavily on the defines | |||
jnthn | eek, that's big | 23:49 | |
m: say 32 * 8 | |||
camelia | rakudo-moar 90b3d6: OUTPUT«256» | ||
timotimo | MP_8BIT makes it an unsigned char, MP_16BIT makes it an unsigned short | ||
jnthn | I suspect making the digits smaller isn't a win overall | 23:50 | |
timotimo | apparently they use 28 of 32 bits or something? | ||
jnthn | Yeah | ||
But making the number of them we default to could help a lot | |||
*to smaller | |||
timotimo | yeah, -DMP_LOW_MEM | 23:51 | |
jnthn | Yeah | ||
What did you try to compare memory use? | 23:52 | ||
timotimo | ... i didn't put any thought into it :D | 23:53 | |
so i used 'say 1', which i shortly thereafter realized was not sensible | 23:54 | ||
jnthn | uh, no :P | 23:56 | |
Try my @a = ^100000; or so :) | |||
timotimo | that'd be much more helpful, aye | ||
but i imagine that well-placed mp_shrinks will reduce the actual memory usage | 23:57 | ||
jnthn | Allocating only to shrink again is just wasteful though. | 23:59 |