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.
00:00 reportable6 left 00:03 reportable6 joined 02:06 releasable6 left, bloatable6 left, shareable6 left, evalable6 left, linkable6 left, tellable6 left, greppable6 left, squashable6 left, quotable6 left, unicodable6 left, nativecallable6 left, statisfiable6 left, benchable6 left, bisectable6 left, reportable6 left, committable6 left, coverable6 left, quotable6 joined, benchable6 joined, evalable6 joined, squashable6 joined, statisfiable6 joined 02:07 shareable6 joined, greppable6 joined, releasable6 joined, bloatable6 joined, coverable6 joined, committable6 joined 02:08 nativecallable6 joined, unicodable6 joined, reportable6 joined, bisectable6 joined 02:09 linkable6 joined, tellable6 joined 03:08 frost joined 03:10 frost left 05:00 frost joined 05:04 frost left 06:00 reportable6 left 06:02 reportable6 joined 06:32 squashable6 left 06:34 squashable6 joined 08:07 [Coke] left
Woodi I think compiler can un-switch 'if' or two or few more from loops but switch-case is bigger animal... I gues that Perl 5 do not had switch initially becouse in 90's they didn't know how to do fast switch and this construct probably is still considered big thing 08:20
08:42 [Coke] joined 09:02 sena_kun joined
Nemokosch I was curious if the simdjson challenge was mentioned. I can't estimate rf's judgement there but the sentiment was that really really a lot of time is wasted by constructing Raku objects the high-level way; the end result is not necessarily better than just using NQP all the way. 09:14
What if you genuinely don't care about supporting multiple backends, only about getting your objects natively and then only do the exposing in Raku? How can one generate the MoarVM representation of certain Raku objects straight from C? 09:16
lizmat I guess you could reverse-engineer the bytecode (MAST) logic and build bytecode from C 09:17
but that feels *very* fragile 09:18
Nemokosch Anyway, why does it involve any bytecode to get a data structure representation used by a C-based runtime, in C? 09:19
lizmat cause the bytecode knows how to create Raku objects 09:20
Nemokosch one would think that there is, like, BootHash and then it's a C struct in MoarVM or something like that
lizmat and give them the correct references
I think it'd be simpler to create the bytecode to create a hash, and let the bytecode do the work 09:21
that'd be *(ess* fragile than creating a BootHash from scratch
Nemokosch but that's quite reasonably the place where the performance is lost
lizmat ah, it's about performance... 09:22
yes, I guess the reason why JSON::Fast is so relatively fast, is that it does most of the things in NQP 09:23
Nemokosch I was just reading back on the Reddit thread
www.reddit.com/r/rakulang/comments...with_raku/ this one, that is
it sounds logical to think that you aren't getting the real performance bump with loads of data because you still have to construct loads of Raku objects the usual way 09:25
and it really nags one that you can just get C headers to Ruby and skip this step
lizmat well, yes...
now, having spent several weeks of my life tuning JSON::Fast I'm actually not looking forward to go into that again :-) 09:26
If I'd be looking for a project, I'd say being able to create standalone executables from a Raku program, would be higher on the list :-) 09:27
Nemokosch the competition is big haha 09:29
imagine targeting LLVM
lizmat many people have suggested targeting LLVM, none have actually take on that project 09:33
irclogs.raku.org/search.html?query...2023-02-21 09:34
shorter URL: irclogs.raku.org/search.html?query...nel=moarvm 09:35
09:42 gighu joined 09:43 gighu left
Nemokosch You make it sound as if it was only a matter of decision, a "do or do not" thing 10:01
in fact, being able to use MoarVM data structures from C is a much more tangible idea
lizmat this is exactly why Perl is stuck with XS 10:03
I really think that's a bad way to go
Nemokosch 1. it's better than nothing at all 10:04
lizmat I disagree
Nemokosch 2. it seems that we lie to ourselves quite often about the options we have
lizmat oh, it's definitely an option 10:05
Nemokosch well, it's sad that you disagree. Do you also disagree that being instantly 80x slower than C++ while using C++ is the rightful destiny?
okay, I tripped myself up in that sentence
lizmat if you think C++ is the way, use C++ ? 10:06
Nemokosch do you also disagree that the 80x time penalty is a show stopper?
rf used C++ and STILL received that time penalty
simply for binding it to Raku
lizmat well, I can't say if it's in the binding, or in something else, as I haven't looked at the actual code 10:07
Nemokosch same but to say there is nothing to be earned here wouldn't be right
and if something seems relatively low investment at least, it's to expose the indeed C data structures used by MoarVM, in C 10:08
timo1 if you're fine with not being supported, you can grab the ThreadContext off of the stack when your C or C++ function is called into
Woodi Nemokosh: or just patch few functions into Moar branch and use it :) 10:09
timo1 CPython extensions are also Not Great for them in the long term, i believe 10:10
Woodi but then what timo1 and lizmat says - unsupported and just C
timo1 pypy had to do a lot of work to make cpy extensions usable
Nemokosch I'm not quite there. It's just I thought the demand didn't appear in the right context. The context was basically "I'll do whatever it takes to be fast, I'm writing C++ anyway" 10:11
lizmat and I think it's still the same trap that Perl fell into with XS
timo1 ideally a raku user would pay no performance for the flexibility that raku offers
can we get a good benchmark of exactly what we are spending our time on after the simdjson parser has done its work already? 10:12
Woodi possibly XS'es complicate things. straight C addition is saner 10:13
but "private"
Nemokosch fwiw I think under some circumstances it's better to be 10x faster and "not be supported", and this "json simd" definitely seems like that sort of thing
Woodi and simdjson blogpost ends with question: why ppls use so much json ?? :) 10:14
Nemokosch also I don't know if this supposed solution (i.e generating the data structure in a C-compatible way and - some version of - MoarVM will be able to consume it) actually works 10:15
however it seems relatively easy to at least figure out if it does
by "works" I mean "it actually gets significantly faster" 10:16
Woodi Nemokosh: it is Raku feature it is so easy :) 10:18
lizmat glancing at the simd code, I see several things that would significantly improve performance on the Raku side 10:19
Woodi no problems with threads ? 10:20
Nemokosch inb4 rewrite the whole thing in NQP 10:22
ah no, I checked it now 10:24
it's already unreadable tbh so that cannot be the thing...
Woodi btw. libtommath is realy nice :)
Nemokosch anyway, feel invited to ponder upon this for a bit - what if your strategy is "I don't mind the performance, I will just write it in C or C++"? What are the costs of bridging data? When can you safely get to the Raku side? 10:29
Yes, in theory, you wouldn't really have to do that - but in practice you do and it's not obvious what would suddenly change the whole situation 10:30
lizmat Nemokosch I think it would be wiser to *first* look at *why* simd has the speed it has 10:31
I'm pretty sure there's at least a factor 2 to be gained by not using expensive constructs in hot places
Nemokosch of course, I can't vouch for the particular code 10:37
frankly, I can barely read it
timo1 i haven't looked at it a 10:38
at all :P
Nemokosch Anyway, I think it can also help a lot if somebody has improvement ideas for the code. I for one don't; I would basically have to first learn the performance implications to be of any use with that 10:45
12:00 reportable6 left 12:01 reportable6 joined 12:33 frost joined
nine Nemokosch: yes, in Ruby you can skip the check and just create a hash from C code. And you pay for that by having Ruby still be dog slow and unable to make use of more than a CPU core and their core developers being unable to fix that. 17:42
tellable6 nine, I'll pass your message to Nemokosch
nine Same is true for Python and Perl.
There is a cost to exposing your internals and that cost is being stuck in time or abandoning all your users. That's not a choice we want to make. 17:43
Nemokosch That's a bit too much statement at once, it would be good to put them into context. Since 1. I'm not using Ruby 2. I don't want to make guesses for Python which has several implementations these days, let's just "play safe" 17:46
jnthn Further, the JIT will probably turn the various hash ops like atkey and bindkey directly into the C function calls that one would make for hash construction anyway. 17:48
Nemokosch Raku is not fast enough, to this very day, to just turn a blind eye on any sort of "plan b" to gain some performance when a task just genuinely needs to be done faster
There's no denial that you can easily gain some performance by simply draining the CPU, much easier than in the aforementioned languages 17:49
but that performance gain is seriously limited, by the nature of things, unless you have a NASA mainframe and some ultra-parallelizable code in addition... 17:51
so to neglect any sort of tool that can make the language useful under somewhat "hot" conditions, seems arrogant for nothing 17:52
"beggars can't be choosers", as they say 17:53
jnthn Nemokosch: Please see jnthn.net/papers/2021-vmil-moarvm-...tions.pdf, especially around slide 80 (although it may not make sense without reading an amount of what comes before it) 17:58
tellable6 jnthn, I'll pass your message to Nemokosch
18:00 reportable6 left, reportable6 joined
nine Nemokosch: Perl, Python and Ruby (talking about their default implementations which are the ones in use everywhere) to this day can't do multi threading because their initial implementations could not. Since they all exposed their internals, they just cannot change this fact without losing backwards compatibility. 18:07
tellable6 nine, I'll pass your message to Nemokosch
nine If you wonder how important that compatibility is, see that whole Python 2 -> 3 fiasco and also the first part of my message: other implementations exist that don't have this problem but they are used less by at least an order of magnitude.
Nemokosch I would rather not talk about any fiasco involving versions... 18:08
nine The result is that yes, one can speed up programs written in those languages by just replacing hot parts with C code, but the downside is that this is actually the only way.
If we want to make pure Raku code any faster we have to be able to make sweeping changes through the whole stack and indeed we have done that a lot already. Incidentally, completely replacing our hash implementation was one of these changes. And that wouldn't have been possible if the hash's memory layout was exposed to user code. 18:13
Nemokosch Well this is my fault for not being clear; I didn't mean to suggest there should be some stable API to working with Raku internals in C 18:23
timo1 as long as we haven't tossed out extops yet, you may just be vaguely in luck 18:24
can we register more than one extops thingie in one moar?
[Coke] removing them is on the roadmap, though, I thought.
timo1 indeed
you'll be completely out of luck in terms of compatibility with more than one exact version of moarvm!
no guarantees for ABI backwards or forwards compatibility
probably only incidentally and not guaranteed to have back & forwards compatibility with APIs 18:25
but your functions get MVMObjects and MVMThreadContext and all that
nine Luckily for the "no stable API or any guarantees at all really" case, there's no need for us to do anything. If someone wants to go that route they can do whatever they want. As timo suggested, grabbing a tc pointer off the stack or just modifying MoarVM directly. It is open source after all. 18:26
Nemokosch perhaps it would be better to not modify MoarVM, if you ever mean to distribute the end result, even with some declared version guards 18:27
or distribute the module with a custom-baked MoarVM? šŸ˜„
nine Distributing results is off the table anyway if you're dabbling in internals
Yep, that might be a way 18:28
timo1 hey hey hey now
"all is fair, as long as you predeclare"!
hm, does the artistic license 2 require you to come up with a different name for this product? :D 18:29
Nemokosch there is a difference between saying "this is essentially just a hack that is never guaranteed to work" and "this will only work under MoarVM version XYZ and whatever the author of the module can guarantee"
the latter is very much just an exaggerated form of many actual existing modules that silently depend on NQP, which I suppose has it's own version, and isn't an official part of the Raku language 18:31
timo1 these don't exactly depend on nqp if all they do is refer to nqp:: ops in raku code 18:32
Nemokosch it's just NQP has a stable-ish Raku API
lizmat Nemokosch ping!
timo1 and of course you have to "use MONKEY-GUTS" or what's it so you can even have them in your code
Nemokosch ping indeed - didn't see the mail, sorry 18:33
timo1 i may give a little look to whatever code we're actually talking about tonight. is there a link? 18:34
19:19 linkable6 left 19:20 linkable6 joined
Nemokosch one sec 19:59
github.com/rawleyfowler/JSON-Simd/...md.rakumod 20:00
by the way, back to Jonathan's presentation - it rings a bell, I think I've seen that on video 20:01
timo1 holy crap, in the single header file version, the header alone is 32k lines, and the cpp file is another 16k 20:18
i think i would start with handling the "location" thing very differently 20:19
have a pop callback and a push callback or so to create a new array or object, and some way to pass a key if you are in an object right then 20:21
i wonder if there's an easier way to get at $*JSON than to look on the stack for a dynamic variable 20:22
doing a full string split on every add-value has got to be costly, and the marshalling of so many Str objects as well 20:24
and also, going from $*JSON to whatever the "active" object is is surely very expensive 20:25
imagine you have { a: { a: { a: { a: { a: { a: { a: { a: [1,2,3,4,5,6,7,8,9] }}}}}}}}
for each of these integers you have to split "a.a.a.a.a.a.a.a.0" into bits, go through the $*JSON to reach that array, and then you can finally push one integer, and you go right back to the start 20:26
i'd say making this mechanism simpler ought to give at least a 10x improvement in run time 20:31
but really it'd be an algorithmic improvement, i.e. better O(whatever)
now who wants to implement that? :) 20:33
btw do we have a comparison between JSON::Fast and this version of JSON::Simd? 20:34
Nemokosch from what I know, it barely beats JSON::Fast, if at all 20:58
jdv note that there is "prior art" in ctilmes's JSON::simd - which just by scanning - seems a bit more mature 21:12
21:30 codesections joined, codesections left 21:31 sena_kun left
jdv if we could refrain from changing master because release that would be nice 21:54
22:00 frost left 22:03 gighu joined 23:25 gighu 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!