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.
Nicholas nine: did I read that right - a pure Raku re-implementation is within 50% of the speed of Perl with Inline::C ? 07:39
nine indeed 07:42
Nicholas That seems newsworthy
japhb That is *awesome*
moon-child nine++++ 07:43
Nicholas so, how many programmers competant at C do you have at work? And how many competant to maintain that code now? :-)
japhb Not just C, XS
Nicholas (this might actually be the same number. I phrased it slightly carefully)
nine To be fair, I probably could have gotten at least a factor of 10 (maybe 100?) more out of the Perl solution - by turning it into a C thing with Perl essentially just being the program loader. But essentially I pushed the hybrid code as far as I could without re-doing the whole architecture. 07:44
Nicholas japhb: if it's "only" Inline::C it might be possible to make it work without knowing XS. If all you're doing are "leaf" functions. *BUT* as soon as you get to arrays, it's going to need XS
nine: and your factor of 10 would save you how much hardware?
(I'm guessing this isn't like my ex $ork, where not-in-C is going to get *expensive*) 07:45
(like maybe a 6 figure sum)
japhb Nicholas: He quoted lines like "double const geo_distance = SvNV(*(hv_fetch(distances_hv, name_pv, name_len, 0)));" so I figured he was well into XS land.
nine The problem in this case is not really hardware cost, but development time. The simulation requires tuning every so often (due to changes in usage patterns). And this requires running it a lot, wasting hours and hours.
Nicholas oh, I missed that. Yes, that's well into XS 07:46
aha.
but, now you can parallelise it? :-)
nine The point where I figured that Raku may have a shot is actually that hash access. Because we have proper objects and attribute access is lightning speed compared to hash access.
Yes, and just adding ".hyper" in a single place already got me to 3.5s Raku vs. 5s Perl in my 200 iteration test case 07:47
japhb I still have to remind myself of that (the switch from Perl on attribute v. hash element access)
nine Unfortunately this revealed the issue I mentioned in #raku-dev yesterday, but we'll fix that at some point
Being only twice as slow is already a victory and makes it possible to use this in production. The point of the exercise is that someone else but me can take over maintenance and tuning, and having to grok that XS stuff in addition to the math is asking just a bit too much 07:49
And maybe we can fix the .hyper issue in time, then it's a done deal for sure 07:50
I also think that it took me less time to speed up the Raku version than the original Perl code. 07:54
lizmat maybe that leaves time for a blog post :-) 08:05
MasterDuke nine: where was it you said the precomp renaming should be patched for windows? 08:54
nine MasterDuke: CompUnit::PrecompilationStore::File 08:59
MasterDuke thanks 09:01
jnthnwrthngtn nine: I'm looking for an issue for the hyper thing you mentioned; is it still to be created or did you plan to look at it yourself? 09:21
nine jnthnwrthngtn: ah, sorry, will create an issue right away. Since I investigate most issues I find myself, I'm lazy about feeding Github. But help would be greatly appreciated! 09:31
jnthnwrthngtn: github.com/rakudo/rakudo/issues/4410 10:04
jnthnwrthngtn Hm, that error implicates a supply or react block somewhere 10:50
The Supplier patch is thus very unlikely to be guilty 10:51
Hm, though with the stacktrace Liz just posted it looks a bit like some object is undefined and we end up calling .emit in Mu where we shouldn't be 11:00
nine Yes, that's about how far I got. Which made me suspect spesh, but that turned out to be wrong
jnthnwrthngtn I suspect it's a race 11:05
.oO( The clue's in the name of the construct! )
More likely at the raku level than deeper 11:06
MasterDuke is it just .hyper or .race also? 11:07
nine race also