| dalek | arVM: 68a18b4 | timotimo++ | src/ (2 files): cannot * in a type object also outputs the debug_name. |
01:33 | |
|
01:40
mst joined,
BinGOs joined
01:44
mst joined
06:23
domidumont joined
06:28
domidumont joined
06:56
domidumont joined
07:05
sivoais joined
07:51
sivoais joined
08:23
brrt joined
|
|||
| brrt | good *, #moarvm | 08:26 | |
| nwc10 | good *, brrt | ||
| brrt: I finally got round to watching air.mozilla.org/language-composition/ | 08:28 | ||
| (it's from 2014) | |||
| brrt | then evidently you got further than me :-) | ||
| what is it about? | |||
| nwc10 | and apart from the content, a bit of me is wondering "what happened next?" because the concepts and projects described seem to have vanished | ||
| using 2 (or more) languages at the same time | 08:29 | ||
| brrt | oh, that seems... evil | ||
| nwc10 | specific examples were Prolog and Python (on the PyPy backend) | ||
| and PHP and Python (again with PyPy) | |||
| but the interesting part was that there was very little overhead in calling between them | 08:30 | ||
| brrt | hmmm | ||
| nwc10 | because it's all written in RPython | ||
| brrt | aha | ||
| nwc10 | *one* interesting part was that | ||
| there was also "Even with mixed source files, our performance is better than the stock PHP interpreter." from the abstract | |||
| brrt | well, that is .... | ||
| nwc10 | it's not clear why hippyvm.baroquesoftware.com/ stalled | ||
| brrt | not all that unexpected, given when comparing pypy with php | ||
| nwc10 | but I'm going to guess "because no-one wants it enough to pay for it" | 08:31 | |
| brrt resists snarking about facebooks' php engineers | |||
| I will remark only that writing your own interpreter is much more fun than using another ones | 08:32 | ||
| also, and that is I guess part of the problem/barrier that the PyPy folks are facing, it isn't exactly hard | 08:33 | ||
| unlike compilers | |||
| well, 'good' compilers | |||
| nwc10 | I admit that "I read it on the Internet" and not in a technical publication | 08:34 | |
| (IIRC it was reputable, and I think it was bloomberg) | |||
| how it took a *long* time to get HHVM to out-perform HipHop | |||
| but implied was that this wasn't done for "fun", but because it was thought to make (some) business sense | |||
| brrt | I'm very, very curious what that business sense could be | 08:35 | |
| nwc10 | hardware is expensive, at Facebook scale | ||
| brrt | note that those remarks also go, just as well, to the question 'why didn't we use LLVM for the JIT' | ||
| nwc10 | I thought that Pyston had demonstrated why LLVM isn't great for a dynamic language JIT :-) | 08:36 | |
| brrt | part of the answer is of course 'using LLVM is total pain for a dynamic language JIT' | ||
| nwc10 | well, more, at Facebook scale, engineering time may actually be cheaper than even more hardware | ||
| brrt | but that doesn't... hold *completely*, because Julia does get away with it | ||
| nwc10 | was Julia designed for it? | ||
| brrt | yes | ||
| nwc10 | my understanding is that Scala makes trade-offs to fit the JVM | ||
| brrt | on it, is maybe a better way to say it | ||
| nwc10 | Julia is like that? | 08:37 | |
| (for its target) | |||
|
08:37
zakharyas joined
|
|||
| brrt | actually, Julia was designed to be like R, but with the added luxury of writing your own for loops | 08:37 | |
| but yes, I got that impression that Julia was bound to LLVM tightly | |||
| I guess I'm saying that, given all the things the facebook folks could've chosen to do with HHVM, it doesn't seem like they chose the shortest / most efficient path | 08:38 | ||
| nwc10 | ah OK. I missed that that was what you were saying | 08:39 | |
| brrt | and I get that for facebook, none of that matters | ||
| because scale | |||
| nwc10 | and I assume "because x86_64" | ||
| and IIRC "because Ubuntu" | 08:40 | ||
| at least, they can assume that they don't need portability | |||
| brrt | and one of the things that they could've done was build on something like HippyVM or started their own PyPy based effort - PyPy ought to be considered proven by now | ||
| nwc10 | I think that they *did* pay for HippyVM for a while | ||
| I've not looked at the HHVM source. Maybe I should. How long does it take to build? | 08:41 | ||
| brrt | never looked at it, never built it, probably C++ | ||
| so 'longish' | |||
| nwc10 | IIRC MoarVM is seconds | ||
| brrt | yes :-D | ||
| nwc10 | Rubinius (which is C++)(when I could get it to build) was about 10 minutes | ||
| PyPy was 40 | |||
| and is a complete RAM hog | |||
| brrt | that is the other part of pypy's problem | 08:42 | |
| the problem that RPython is solving, strictly speaking, isn't a hard one and can be done in C/C++ by an experienced engineer easily | |||
| nwc10 | :-) | 08:43 | |
| brrt | the problem solved by their JIT compiler and meta-tracing backend, that *is hard*, but people forego it because using RPython is a pain | ||
| nwc10 | the :-) was because I was jumping to the conclusion "so they would be better of *not* self-hosting" | ||
| brrt | .. I think so, yes | 08:44 | |
| but I may be wrong about that | |||
| nwc10 | well, we need a parallel universe before we can prove it | 08:45 | |
| and probably several, so that we have enough experiments to avoid errors :-) | |||
| brrt | :-) | ||
|
10:44
JimmyZ joined
10:45
ilmari joined
12:19
zakharyas joined
13:42
JimmyZ joined
18:47
domidumont joined
19:12
masak joined
|
|||
| masak | jnthn: according to a git grep I just made of the moarvm source code, you're a three-star programmer ;) | 19:12 | |
| three asterisks occur in 15 places of the source code. four don't occur. | 19:13 | ||
| I'm not stating this as any kind of challenge or call for action, by the way :P | |||
|
19:41
sivoais joined
|
|||
| jnthn | I didn't make it to four stars anywhere? :) | 19:48 | |
| timotimo | hm, can i break upon entering a .c file from anywhere in gdb? | ||
| jnthn | masak: At a guess, those 15 places are largely under src/gc/? :) | 19:50 | |
| nine | timotimo: don't think so :/ | ||
| jnthn | Moving GCs talk a lot about the location of pointers, which gets you to two stars. And you're sometimes interested in lists of those locations, which gets you to three. | 19:51 | |
| So in that domain you kinda end up there without doing anything clever. | 19:52 | ||
| masak | jnthn: 10 are in src/gc | ||
| jnthn | To the extent that a moving GC isn't already sorta clever. :P | ||
| nine | .oO(lists of locations of string arrays) |
||
| masak | jnthn: 3 are in src/core, 1 is in src/strings/unicode_db.c, 1 is in tools/ucd2c.pl (but still C code) | 19:53 | |
| jnthn | Oh man, I wonder if that Unicode one is the primary composites table :P | ||
| masak | jnthn: comp_p? :) | ||
| jnthn | Yup :) | ||
| masak | it's actually `static const MVMint32 ***comp_p[]`, so I guess that one could be seen as four stars :P | 19:54 | |
| jnthn | And I'll get in sr/core one or more is in threadcontext.h and is GC related. | ||
| *src/core | |||
| timotimo | nine: here's my setup (it has nothing to do with perl6 or moarvm): i have a game that misbehaves when multiple monitors are connected. it still has DWARF symbols for the SDL2 that's compiled into it (i.e. statically linked and partially inlined). i'd like to see how exactly it uses the SDL api without manually typing every SDL function i could be interested in as breakpoints | ||
| jnthn | *guess also :) | ||
| timotimo: ltrace? | 19:56 | ||
| timotimo | "It intercepts and records the dynamic library calls which are called by the executed process" | 19:57 | |
| does it also handle non-dynamic library calls? | |||
| nine | (gdb) help rbreak | ||
| Set a breakpoint for all functions matching REGEXP. | |||
| jnthn | No idea, sorry | ||
| nine | Do SDL functions have a common prefix? | ||
| timotimo | oooh | ||
| yes, they do | |||
| jnthn | nine++ # I didn't know about that one either...nice! :) | ||
| timotimo | Breakpoint 1289 at 0x8404fb0 | 19:58 | |
| <function, no debug info> NInputHandler::InitInputDevices(SDL_Window*, void*, bool, bool); | |||
| nine | Apparently one can even do: rbreak file.c:. | ||
| timotimo | %) | ||
| neat. | 19:59 | ||
| another question: this file is full of references to /home/kyle/blahblah/blahblah/SDL2-2.0.1/src/... files | 20:02 | ||
| can i tell gdb "i have the same files, but at a different path"? | |||
| aha | 20:03 | ||
| set substitute-path | |||
| ohmygosh it works | 20:07 | ||
| this is pretty cool | |||
| jnthn: how come we don't have a serialization and deserialization function for MVMHash? | 21:04 | ||
| lizmat | jnthn: gist.github.com/lizmat/32ce2b17a5a...9a64ca9bef # concurrent fail on OS X | 21:07 | |
| { my $*PROMISE := $p; $vow.keep(code(|c)) }, | 21:08 | ||
| looks like it lost the code to be executed | |||
| jnthn | timotimo: It's handled specially (grep for MVMHash in serialization.c) | 21:11 | |
| timotimo | oh | ||
| well, that explains it. but why do we get errors for it missing? just a bug? | |||
| jnthn | lizmat: I suspect elsewhere. | ||
| timotimo: Yeah, sounds like | |||
| timotimo | OK, good to know | ||
| jnthn | timotimo: Something doing write_obj_ref instead of write_ref or something I guess | ||
| lizmat: As in, I suspect not just OSX :) | 21:12 | ||
| timotimo | interesting. that should be findable | ||
| jnthn | I've seen that one on Linux also | ||
| timotimo | ltrace gives me an incredible amount of output | ||
| lizmat | jnthn: ok | ||
| jnthn | Didn't get to the bottom of why yet | ||
| timotimo | because ltrace also gives operator new, operator new[], operator delete, operator delete[], but also memcmp, memcpy, str*cmp, ... | 21:18 | |
| jnthn | Hm, you can't tell it which libraries you do/don't care about? :) | 21:19 | |
| timotimo | -l, --library filename | 21:20 | |
| Display only the symbols included in the library filename. | |||
| this ought to be it, but i'm not sure it actually considers the statically linked SDL a "library" in that sense | |||
| jnthn | ah, ok | 21:21 | |
| timotimo | "Because it uses the dynamic library hooking mechanism, ltrace cannot trace calls to libraries which are statically linked directly to the target" | 21:26 | |