|
🦋 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:08
reportable6 left
00:09
reportable6 joined
00:41
ggoebel left
00:51
ggoebel joined
|
|||
| Geth | rakudo/vrurg-unlimited-threads: 4e56f241d8 | (Elizabeth Mattijsen)++ (committed by Vadim Belman) | src/core.c/ThreadPoolScheduler.pm6 Add :max_threads(*|Inf) as option to ThreadPoolScheduler For those of us brave enough to not want to be stopped by a maximum number of OS threads. Specifying * or Inf will internally store the value 9223372036854775807 (aka the current maximum value for an uint attribute). The accessor will return Inf if this value is found. |
01:31 | |
| rakudo/vrurg-unlimited-threads: 49172cb140 | (Vadim Belman)++ | src/core.c/ThreadPoolScheduler.pm6 Support for setting unlimited max_threads from environment Extending PR #4941. Aside of just setting `$!max_threads` to a specific number via `RAKUDO_MAX_THREADS` environment variable the following special cases are now supported too: ... (23 more lines) |
|||
| rakudo: vrurg++ created pull request #4941: Allow setting ThreadPoolScheduler's max_threads to semi-infinite value |
01:35 | ||
| rakudo/vrurg-unlimited-threads: b0ebb5e610 | (Vadim Belman)++ | src/core.c/ThreadPoolScheduler.pm6 Support for setting unlimited max_threads from environment Extending PR #4931. Aside of just setting `$!max_threads` to a specific number via `RAKUDO_MAX_THREADS` environment variable the following special cases are now supported too: ... (23 more lines) |
|||
|
01:49
Kaiepi left
02:02
ggoebel left
03:08
Kaiepi joined
04:08
bisectable6 left,
reportable6 left,
bloatable6 left,
unicodable6 left,
sourceable6 left,
committable6 left,
notable6 left,
evalable6 left,
benchable6 left,
shareable6 left,
nativecallable6 left,
greppable6 left,
releasable6 left,
tellable6 left,
coverable6 left,
linkable6 left,
quotable6 left,
statisfiable6 left
04:09
sourceable6 joined,
coverable6 joined,
quotable6 joined,
unicodable6 joined,
benchable6 joined,
statisfiable6 joined,
greppable6 joined
04:10
releasable6 joined,
tellable6 joined,
shareable6 joined,
nativecallable6 joined
04:11
linkable6 joined,
evalable6 joined,
bloatable6 joined,
notable6 joined,
bisectable6 joined,
reportable6 joined
04:12
committable6 joined
05:12
unicodable6 left,
coverable6 left,
greppable6 left,
benchable6 left,
bisectable6 left,
committable6 left,
shareable6 left,
releasable6 left,
evalable6 left,
bloatable6 left,
tellable6 left,
quotable6 left,
linkable6 left,
reportable6 left,
sourceable6 left,
notable6 left,
nativecallable6 left,
statisfiable6 left,
nativecallable6 joined,
benchable6 joined,
committable6 joined,
bisectable6 joined,
bloatable6 joined,
quotable6 joined
05:13
linkable6 joined,
evalable6 joined,
shareable6 joined
05:14
tellable6 joined,
notable6 joined,
reportable6 joined,
coverable6 joined,
greppable6 joined,
releasable6 joined
05:15
unicodable6 joined,
statisfiable6 joined,
sourceable6 joined
06:04
Kaiepi left
06:07
reportable6 left
06:09
reportable6 joined
06:24
japhb joined
06:41
lizmat joined
|
|||
| releasable6 | Next release in ≈2 days and ≈11 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 07:00 | |
| dogbert17 | lizmat: are you still happy with your M1 Mac Mini or have any problems surfaced? | 10:37 | |
| I was a bit interested in the performance of test-t now that you have a faster CPU but no jit | 10:58 | ||
|
11:23
ggoebel joined
|
|||
| lizmat | dogbert17: old MBP / new MacMini: .867 / .837 | 11:25 | |
| the version with 200K lines: 11.476 / 12.791 | 11:28 | ||
| so I'd say for longer running processes, the JIT still makes a difference | |||
| with JIT disabled on the old MBP: 1.26 | 11:29 | ||
| m: say .867 / 1.26 | 11:30 | ||
| camelia | 0.688095 | ||
| lizmat | m: say 1.26 / .867 | ||
| camelia | 1.453287 | ||
| lizmat | so the JIT makes the 10K ine about 45% faster | ||
| for the 200K version: | 11:31 | ||
| m: say 19.92 / 11.476 | 11:32 | ||
| camelia | 1.735796 | ||
| lizmat | 70% faster or the 200K version | ||
|
12:03
Kaiepi joined
12:06
reportable6 left
12:07
reportable6 joined
|
|||
| dogbert17 | interesting stats | 12:36 | |
|
12:38
MasterDuke joined
13:16
ggoebel left,
ggoebel_ joined
|
|||
| vrurg | greppable6: initial_threads | 13:37 | |
| greppable6 | vrurg, 5 lines, 4 modules: gist.github.com/22d4da0d466bc021f7...9308f51883 | ||
|
14:03
ggoebel_ left
14:14
lizmat left
|
|||
| Geth | rakudo/vrurg-unlimited-threads: febff8fb7c | (Vadim Belman)++ | src/core.c/ThreadPoolScheduler.pm6 Fix JVM build This would be more correct approach for MoarVM backend too. - Removed `$.initial_threads` attribute because it is only used at the construction stage and is not needed otherwise. |
14:29 | |
|
15:30
ggoebel_ joined
15:41
ggoebel_ left
16:19
ggoebel_ joined
16:30
ggoebel_ left
17:25
lizmat joined,
ggoebel_ joined
18:07
reportable6 left
18:09
reportable6 joined
20:32
japhb left
|
|||
| Geth | rakudo/master: 4 commits pushed by (Elizabeth Mattijsen)++, (Vadim Belman)++ | 21:00 | |
|
21:48
lizmat left
22:48
unicodable6 left,
coverable6 left,
notable6 left,
nativecallable6 left,
sourceable6 left,
evalable6 left,
releasable6 left,
committable6 left,
tellable6 left,
bisectable6 left,
benchable6 left,
linkable6 left,
reportable6 left,
statisfiable6 left,
bloatable6 left,
quotable6 left,
shareable6 left,
greppable6 left
22:49
evalable6 joined,
unicodable6 joined,
linkable6 joined,
benchable6 joined
22:50
bloatable6 joined,
releasable6 joined,
quotable6 joined,
sourceable6 joined,
bisectable6 joined,
greppable6 joined
22:51
reportable6 joined,
notable6 joined,
committable6 joined,
tellable6 joined,
nativecallable6 joined,
coverable6 joined,
statisfiable6 joined,
shareable6 joined
|
|||