🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
00:02 reportable6 left 02:15 [Coke] left 02:34 [Coke] joined 02:44 frost joined 02:47 releasable6 left, nativecallable6 left, nativecallable6 joined, releasable6 joined, statisfiable6 left 02:48 statisfiable6 joined 03:04 reportable6 joined 03:49 andinus joined
andinus release manager, do they have to use their own hardware for running tests? 03:49
Xliff Oh. On the testing note. I have a 5950x AMD system that I can see about opening up for testing. 16 core, 32 thread 3.3Ghz 03:57
I have the hardware for a second. 03:58
And possibly before the 1st of the year, I would like to obtain a Xeon 8362 based system, so if someone has recommendations on a place that can build something like that, please drop me a PM, 04:01
andinus i can make time for it but don't have required hardware (Blin ~32GB memory)
Xliff And yes, I would be amendable to opening that system up for testing, as well.
I think current Rakudo has a 32 thread max limit on parallelization. I do remember trying something with VMs and a stoopidly large amount of cores a while back and it fell flat on its face. 04:03
japhb Xliff: I don't think it's _limited_ so much as not tuned enough to scale all the way up linearly. There is a *default* limit on general threads in the default scheduler, but that can be easily changed with e.g. the RAKUDO_MAX_THREADS environment variable. 04:20
Xliff japhb: Ah. I didn't know about that .What's the default value on that? 04:42
04:49 evalable6 left, linkable6 left
japhb 64, last I checked. It should be in docs/running.pod 04:51
04:52 evalable6 joined
japhb But there are (or were) some known scaling issues, only some of which have been addressed. For example, for a while certain usage patterns would cause the thread spawning heuristic think it didn't need any more threads and waste some cores. I think that one was addressed. 04:55
Similarly, lizmat found a pattern this week that slowly drops in CPU utilization over time, and I don't think that one's been nailed down yet. 04:56
Then of course there's the effect of Amdahl's law anywhere real serialization still occurs. 04:59
(thread serialization, not data serialization, I mean)
Xliff japhb: OK. Another data point for that. I tried running my parallel precompilation with some of my projects (had 96 core VM) and compilation hung unless I limited the number of parallel threads to 32. 05:01
japhb Xliff: That's interesting. What version of Rakudo was that? 05:05
05:52 evalable6 left 05:53 evalable6 joined 06:02 reportable6 left 06:03 reportable6 joined
Geth nqp: usev6++ created pull request #748:
[JVM] Fix conversion to unsigned int		 06:43
08:04 Xliff_ joined 08:06 MasterDuke left, Xliff left
Xliff_ japhb: I generally keep my Raku compilers current, so Definitely around 2021.09 08:26
08:55 patrickb joined
patrickb andinus: WRT Release manager requirements: Hardware for running tests will not be a limiting factor. There are multiple systems provided by others available for running tests / blin. 09:04
Geth nqp: 81fe4113a4 | (Christian Bartolomäus)++ | 2 files
[JVM] Fix conversion to unsigned int

  ... in VMArray with 32 bit. The old code handled the 1 as a signed
integer, so that (1 << 32) just evaluated to 1.
An alternative would have been to use Integer.toUnsignedLong(i), which is available since Java 8. We could change to those methods in the future -- but for consistency the should be used for the other types of VMArrays as well.		 09:18
lizmat japhb: I haven't been able to golf it yet, and it may still be an artefact of my own algorithm 09:27
Xliff_ lizmat: See my messages, above. 09:44
lizmat noted. I just realized that the default for maximum number of threads should probably be dependent on the number of cores available 09:49
09:49 linkable6 joined
Geth rakudo/max-threads-default: 04cd0754f8 | (Elizabeth Mattijsen)++ | src/core.c/ThreadPoolScheduler.pm6
Make the max number of threads depend on number of cores

Previously, this was set to 64. Clearly, should be dependent on actual number of cores available. For now, the maximum is set to 8 times the number of cores, based on the previous value an the more common 4-8 core hardware that was available when that maximum was originally set.		 10:01
rakudo: lizmat++ created pull request #4652:
Make the max number of threads depend on number of cores
rakudo: 259d29b36d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/core.c/IterationBuffer.pm6
Add IterationBuffer.unshift/prepend methods (#4641)

Seems like a logical addition without interfering with the performance of the other IterationBuffer logic. And I have a use-case for it :-)		 10:16
10:16 linkable6 left 10:19 linkable6 joined 10:34 janhen joined 11:34 evalable6 left, linkable6 left 11:35 linkable6 joined 12:02 reportable6 left 12:03 reportable6 joined 12:06 kjp left 13:06 statisfiable6 left, quotable6 left, linkable6 left, benchable6 left, reportable6 left, bloatable6 left, bisectable6 left, greppable6 left, tellable6 left, squashable6 left, notable6 left, shareable6 left, unicodable6 left, committable6 left, releasable6 left, nativecallable6 left, coverable6 left, sourceable6 left, committable6 joined, coverable6 joined, bloatable6 joined 13:07 bisectable6 joined 13:08 releasable6 joined, quotable6 joined, tellable6 joined 13:09 shareable6 joined 13:37 evalable6 joined 14:07 notable6 joined, benchable6 joined, reportable6 joined 14:08 squashable6 joined 14:09 statisfiable6 joined 14:18 vrurg joined 14:20 vrurg_ left 14:30 vrurg_ joined 14:33 vrurg_ left, vrurg_ joined, vrurg left 14:43 frost left 14:53 janhen left 15:07 greppable6 joined 15:08 linkable6 joined 15:09 sourceable6 joined
japhb Xliff_: It might be worth checking that parallel precomp threading case with HEAD rakudo, because new-disp and a ton of reliability bugfixes have landed since 2021.09. 15:40
Xliff_ japhb: Heh. Next time I have access to something with more than 32 cores, I will. ;) 15:47
16:08 nativecallable6 joined 16:20 Xliff_ left, patrickb left 17:07 unicodable6 joined, [Coke]_ joined, lizmat_ joined 17:09 leont_ joined 17:10 gfldex_ joined 17:16 [Coke] left, lizmat left, zostay left, gfldex left, leont left, camelia left, leont_ is now known as leont 17:22 zostay joined, camelia joined 17:32 lizmat_ left 17:33 lizmat joined 18:02 reportable6 left 18:06 [Coke]_ left 18:13 Colt joined 18:25 TempIRCLogger left, TempIRCLogger joined 18:26 [Coke] joined 18:56 Colt left 18:57 Colt joined 18:58 Xliff joined 19:01 Colt left 19:02 Colt joined, gfldex_ is now known as gfldex
gfldex m: my @a = 1,2 … Inf; say @a.first(* > 1, :end); @a.tail; 19:03
camelia Nil
Cannot tail a lazy list
in block <unit> at <tmp> line 1
19:03 Colt left, Colt1 joined, Colt1 left
gfldex is there a reason why first(:end) silently fails but tails refuses to work with lazy lists? 19:03
19:05 reportable6 joined 19:06 Colt joined 20:00 dogbert17 left 20:03 dogbert17 joined 20:09 dogbert11 joined, dogbert17 left 20:22 vrurg_ is now known as vrurg 20:25 dogbert11 left 20:43 dogbert11 joined 21:22 dogbert11 left 21:24 dogbert11 joined 22:15 dogbert11 left, dogbert11 joined 22:22 dogbert17 joined, dogbert11 left 23:16 dogbert11 joined 23:18 dogbert17 left
lizmat gfldex: can't think of a particular reason for this inconsistency 23:27
gfldex There is actually a test for Inf in line github.com/rakudo/rakudo/blob/mast....pm6#L1406 . 23:49
lizmat: tail is using iterators that in turn throw X::Cannot::Lazy, while first is using nqp::while . 23:54

Powered by Cro and the Raku® Programming Language.

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

Thank you!