Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
02:11 MasterDuke joined
Geth MoarVM/main: 6d8a4c7521 | (Daniel Green)++ | 3rdparty/mimalloc
Bump mimalloc to 2.1.7
 02:38
MoarVM/main: ed50e2c73d | MasterDuke17++ (committed using GitHub Web editor) | 3rdparty/mimalloc
Merge pull request #1819 from MasterDuke17/bump_mimalloc_to_2.1.7
07:49 sena_kun joined 08:30 sena_kun left
timo1 lizmat: is it possible to give HTML::Entity::Fast a list/hash of entities I don't want translated without a big loss in performance? 12:33
lizmat so you'd basically want to remove N entries from the lookup hash? 12:34
timo1 quite a few of the translations i kind-of don't really need i think? i mostly want to make sure nothing in the text i'm outputting is accidentally parsed as HTML, so the most important by far is &lt;, but i'm not sure if a whitelist of just < is good enough? 12:35
yeah, and if you add something to remove individual items, maybe a whitelist would also be interesting
in particular, using a real \n instead of &NewLine; makes the HTML source a lot easier to look at, and the resulting code is also full of &cup; or something like that? 12:36
anyway, not a big priority or anything 12:37
lizmat to be clear: you want to omit some conversions from "decode-html-entities" right?
timo1 that's right 12:41
currently i do decode-html-entities($bla).replace("&newline;", "\n") which is obviously silly :)
lizmat could you provide be with a before / after example I could use for testing? 12:42
*me :-) 12:43
timo1 i'll be calling it multiple thousand times, so if i could somehow do the setup once and re-use it a bunch of times (whether it be with a class or something else) so as to avoid a performance penalty ...
lizmat ack 12:45
ok, working on it :-) 12:50
timo1 ok, as i said, low priority, but if you have a tuit in the right shape anyway ... :) 13:01
13:07 brrt joined
timo1 o/ brrt 13:07
brrt ohai timo1
I hear talk of deprecating the expression JIT 13:08
timo1 right, nine is very unhappy about being unable to enforce order of operations in the generated assembly
and the fact that nobody has learned to work on it 13:09
brrt yeah, that is a bug indeed
I had a design to fix it, I lost the design, and forgot what made it work
nine is, in other words, very right
lizmat timo1: need to go afk for an hour or so, will work on entities afterwards 13:10
timo1 i'm not sure about the mentioned lack of dramatic performance improvement from the jit, though i'm not sure if that was referencing lego jit or exprjit
though of course the point that a big amount of improvement comes from spesh is true
spesh can, after all, consider not only multiple operations in a row, but also stuff across BB boundaries
brrt indeed
timo1 which neither of the two JITs can do
brrt well, the theory was, if spesh can do this, it makes little sense for the JIT to do it as well 13:11
that theory doesn't work as well as I would have hoped
see you back lizmat
timo1 the exprjit can harness information that crosses nqp "opcode boundaries" kind of like how spesh can harness information that crosses BB boundaries 13:12
and of course some nqp opcodes compile to something that has BBs in it as well
i'm not sure if i have a point i'm trying to make
brrt well, part of the theory was that the expr JIT would be able to avoid a lot of the memory traffic that was forced by the architecture of the lego JIT 13:15
that theory is only a bit true
in practice, the expression JIT per-opcode fragments may have multiple basic blocks, so the register allocator forces a lot of that memory traffic right back 13:16
timo1 i once asked a friend, how bad is a jit that puts load in front of everything and store after everything, and he was like "failing grade"
brrt LOL
well, send your friend my regards :D
timo1 not those exact words tbh, i don't remember the details, it was very long ago
well, i mean, it's still fine to have a jit that "only" gets around Interpreter Overhead with a load-do-store design 13:17
BBIAB
brrt yeah, but a lot of the interpreter overhead *is* the load/store cycle
timo1 you mean a branch inside the lego brick for an op causes register renaming to "fail"? 13:19
brrt a branch or a call to a function 13:20
especially function calls, it means we have to spill all the 'live' values
timo1 right, they do have to go on the stack, unless we just so happen to know the function we're calling won't, for example, write over the xmm* registers, which the compiler actually might do a bunch 13:23
but also, getting more stuff that we'd usually call functions for onto the exprjit level could be beneficial. inlining, essentially. 13:24
how hard would it be to implement devirtualization for things like reprop calls in the exprjit btw? i'm not sure we ever talked through that but i did mention it at least ... all that was long ago of course 13:26
oh but that's just details that may not matter at all for the discussion at hand
brrt It's actually not all that hard, you'd register a JIT callback on the repr struct, and it would be given a handle to an expr JIT tree 13:38
combine that with a bit of build magic to be able to generate a map from opcode -> tree, with bindings, this is actually a fairly small project
but indeed, it doesn't really matter :-) 13:39
timo1 you did so much work describing the design of the exprjit with its tiler and everything and somehow i still don't get it 13:40
brrt doing the same for the lego JIT is actually a bit more tricky since the dynasm handle tends to be fairly tightly bound to the (single) source file that generated it, so we'd have to do more build magic to make that convenient 13:41
well.... I blame myself for that more than anyone else, really
timo1 i don't think the blog posts were bad? 13:42
brrt I'm the last person to fairly judge that
but
truth be told, I don't know?
timo1 ah, you say the implementation of, say, VMArray_push_int32 would also have to go into emit.dasc or it might not work right? 13:43
brrt I've worked in rather different environments over the past 10 years
I think so yes.
I think that's actually also what we did for the expression JIT as well
timo1 right, all the tiles are in one file, but of course with the exprjit these tiles aren't specific to, for example, one single repr 13:44
brrt correct
yes, we did include the tiles source in the emit.dasc
timo1 in theory, we already have the right position in legojit to not just double-devirt to a function call for reprops; we just have to put a "emit this lego block" instead of a "emit a C function call" in the emit_reprop function (or more likely a function called by it) 13:45
i wonder why i never bothered to do that honestly 13:46
brrt yes, but if you have to make that single function dispatch for every possible repr / op combination, that will be a dragon.
timo1 *shrug* it could actually be split into per-REPR files/functions, even registered as a function in the reprop just like the spesh function is 13:47
brrt that's why I said you'd want to have the JIT handler a pointer in the repr struct
right :-)
and then you could, or rather would, still have to either place it in the emit.dasc, or a file included by emit.dasc
timo1 it wouldn't be so bad to have the file included by emit.dasc right? 13:48
brrt I think that would be pretty acceptable yes 13:49
timo1 one thing bad about exprjit not having devirt is that a BB gets a chance at exprjit first, and will output the worse, more general reprop implementation, when the lego jit could have devirted 13:53
brrt true 13:54
timo1 what were you going to say with "I've worked in rather different environments over the past 10 years"? 13:59
brrt I forgot :D 14:02
anyway, I have more +pre/s
si+/
pressing, toddler issues to deal with at the moment
speak you later :-)
14:03 brrt left
timo1 looking forward to it :) 14:10
16:46 brrt joined
brrt \o 16:47
timo1 o/
brrt toddler wants to keep touching the keys 16:48
timo1 they're like cats in this regard 16:49
16:50 brrt left
timo1 i assume the toddler found the power off button? 16:55
lizmat hehe 18:12
Nicholas www.youtube.com/watch?v=B0oFpOJaIYc -- La retransmission du vol inaugural d'Ariane 6 débutera à 18H30 TU -- I thought that the point of calling it "UTC" was that it was a language neutral not-a-TLA, and yet, here we are. 18:24
anyway, not your usual rocket launch
lizmat Nicholas o/ 18:34
pride of Europe... about half the power of Falcon 9 in non-recoverable mode 18:35
[Coke] \o/ 19:01
lizmat anyways... looks like it was a successful launch 19:04
[Coke] "nominal" 19:06
lizmat timo1: updated version of HTML-Entity-Fast on its way to the ecosystem 19:07
nine Well dubious product strategy but the engineering quality is certainly still there :) 19:37
lizmat yeah, there's that: and they've improved their PR with a camera on the rocket sending live images, like SpaceX 19:38
only a 20 second lag or so
19:50 MasterDuke left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!