|
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:02
reportable6 left
00:03
reportable6 joined
05:24
linkable6 left,
evalable6 left,
evalable6 joined
05:26
linkable6 joined
06:02
reportable6 left
06:05
reportable6 joined
|
|||
| 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 | |
|
08:08
LizBot left
08:09
LizBot joined,
LizBot left,
LizBot joined
08:24
LizBot left,
LizBot joined
08:25
LizBot left,
LizBot joined
|
|||
| 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 | |
|
09:14
linkable6 left
09:16
linkable6 joined
|
|||
| 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 | ||
|
11:16
Altai-man joined
11:19
sena_kun left
12:02
reportable6 left
12:03
reportable6 joined
15:42
bisectable6 left,
unicodable6 left,
benchable6 left,
tellable6 left,
quotable6 left,
bloatable6 left,
shareable6 left,
committable6 left,
reportable6 left,
releasable6 left,
greppable6 left,
notable6 left,
coverable6 left,
linkable6 left,
sourceable6 left,
squashable6 left,
statisfiable6 left,
nativecallable6 left,
evalable6 left
15:43
releasable6 joined,
greppable6 joined,
statisfiable6 joined,
benchable6 joined,
notable6 joined,
bloatable6 joined
15:44
tellable6 joined,
reportable6 joined,
shareable6 joined,
linkable6 joined,
squashable6 joined
15:45
coverable6 joined,
sourceable6 joined,
evalable6 joined,
bisectable6 joined,
committable6 joined,
quotable6 joined,
unicodable6 joined,
nativecallable6 joined
18:02
reportable6 left
18:03
reportable6 joined
19:00
linkable6 left
19:02
linkable6 joined
19:05
Kaiepi left
19:24
ilogger2 left,
ilogger2 joined
20:45
Kaiepi joined
20:49
squashable6 left
20:50
squashable6 joined
20:51
squashable6 left
20:53
squashable6 joined
21:39
linkable6 left
21:42
linkable6 joined
22:58
bisectable6 left
22:59
bisectable6 joined
23:00
linkable6 left
23:03
linkable6 joined
|
|||