Newest at the top
| 2026-04-20 13:23:13 +0000 | Ikosit8 | (~Ikosit@user/ikosit) Ikosit |
| 2026-04-20 13:23:08 +0000 | Ikosit | (~Ikosit@user/ikosit) (Ping timeout: 256 seconds) |
| 2026-04-20 13:19:41 +0000 | tromp | (~textual@2001:1c00:340e:2700:c9bc:b29c:36e3:d32a) |
| 2026-04-20 13:18:05 +0000 | <Freakie> | or other good suggestions for keeping productivity high I guess |
| 2026-04-20 13:08:24 +0000 | tromp | (~textual@2001:1c00:340e:2700:c9bc:b29c:36e3:d32a) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-04-20 13:08:21 +0000 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-04-20 13:07:37 +0000 | pabs3 | (~pabs3@user/pabs3) (Remote host closed the connection) |
| 2026-04-20 13:06:52 +0000 | CiaoSen | (~Jura@p549cbfb1.dip0.t-ipconnect.de) (Ping timeout: 265 seconds) |
| 2026-04-20 13:04:24 +0000 | Square3 | (~Square4@user/square) (Ping timeout: 244 seconds) |
| 2026-04-20 13:01:12 +0000 | rekahsoft | (~rekahsoft@bras-base-orllon1103w-grc-20-76-67-111-168.dsl.bell.ca) rekahsoft |
| 2026-04-20 12:53:11 +0000 | <Freakie> | do you have a reference on best practices with regions? |
| 2026-04-20 12:47:46 +0000 | tromp | (~textual@2001:1c00:340e:2700:c9bc:b29c:36e3:d32a) |
| 2026-04-20 12:45:39 +0000 | <merijn> | I mean, I would expect/want productivity of >80% ideally >90% |
| 2026-04-20 12:21:25 +0000 | gawen | (~gawen@user/gawen) (Ping timeout: 245 seconds) |
| 2026-04-20 12:20:59 +0000 | gawen_ | (~gawen@user/gawen) gawen |
| 2026-04-20 12:17:08 +0000 | <Freakie> | the input arguments can be quite large so maybe they are just a consequence of garbage collection or something, idk |
| 2026-04-20 12:15:48 +0000 | totbwf | (sid402332@user/totbwf) totbwf |
| 2026-04-20 12:15:48 +0000 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) (Changing host) |
| 2026-04-20 12:13:59 +0000 | edm | (sid147314@id-147314.hampstead.irccloud.com) |
| 2026-04-20 12:09:38 +0000 | <Freakie> | sometimes it would be something along the lines of 5% MUT-to-GC reported but productivity was reported to be something like 20-30% |
| 2026-04-20 12:09:16 +0000 | totbwf | (sid402332@id-402332.uxbridge.irccloud.com) |
| 2026-04-20 12:09:09 +0000 | <Freakie> | but also I think the productivity reporting has seemed off sometimes |
| 2026-04-20 12:08:39 +0000 | Eoco | (~ian@128.101.131.218) Eoco |
| 2026-04-20 12:08:15 +0000 | <Freakie> | I have a smaller input where both compact and non-compact runs use about 20 seconds of mut time but the pure version uses about 4-5x as much GC time than the one compacted |
| 2026-04-20 12:07:22 +0000 | puke | (~puke@user/puke) puke |
| 2026-04-20 12:06:57 +0000 | puke | (~puke@user/puke) (Remote host closed the connection) |
| 2026-04-20 12:06:28 +0000 | <Freakie> | I assume consing to compact regions is more expensive than a pure cons operation, all else equal |
| 2026-04-20 12:05:41 +0000 | <Freakie> | I mean GC would continually traverse append-only data during the algorithms |
| 2026-04-20 12:05:16 +0000 | <merijn> | So even lower productivity? |
| 2026-04-20 12:05:05 +0000 | <merijn> | Even less? o.O |
| 2026-04-20 12:04:46 +0000 | <Freakie> | total time was about 30 minutes, MUT I believe was a little less |
| 2026-04-20 12:04:34 +0000 | <Freakie> | my peeve is that the profiler only reports all the compacted data as having been allocated by the system instead of the modules |
| 2026-04-20 12:04:29 +0000 | <merijn> | And what was it without the compact regions? |
| 2026-04-20 12:04:05 +0000 | <merijn> | oof, productivity 12% is kinda abysmal xD |
| 2026-04-20 12:03:47 +0000 | <merijn> | That one was what I meant :p |
| 2026-04-20 12:03:22 +0000 | <Freakie> | or sorry what do you mean by report? |
| 2026-04-20 12:03:11 +0000 | <Freakie> | https://pastebin.com/CN8itK6R |
| 2026-04-20 12:02:35 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) Lord_of_Life |
| 2026-04-20 12:02:04 +0000 | <merijn> | Freakie: can you pastebin the GC report? |
| 2026-04-20 12:01:56 +0000 | <Freakie> | I would assume the profiler would report it differently since it's a using a public API though? |
| 2026-04-20 12:01:41 +0000 | <merijn> | So it might report that as GC time, I don't know :) |
| 2026-04-20 12:01:18 +0000 | mustafa | (sid502723@rockylinux/releng/mustafa) mustafa |
| 2026-04-20 12:01:16 +0000 | dy | (sid3438@user/dy) \\\\\ |
| 2026-04-20 12:01:10 +0000 | sclv | (sid39734@haskell/developer/sclv) sclv |
| 2026-04-20 12:01:09 +0000 | <merijn> | Freakie: Yeah, I just mean that the way GHC implements compacting is the exact same code as GC. i.e. starting from a root, traverse the memory and copy to new heap (except the heap is now a compact region instead of the normal heap) |
| 2026-04-20 12:00:23 +0000 | <Freakie> | all I know is that appending uses CompactAdd# which is a GHC primitive |
| 2026-04-20 12:00:09 +0000 | hook54321 | (sid149355@user/hook54321) hook54321 |
| 2026-04-20 11:59:35 +0000 | <Freakie> | I will admit that I just used an implementation of a package I found that I couldn't install through cabal because it was too old, so I haven't looked too much into how it works |
| 2026-04-20 11:59:14 +0000 | Adeon | (sid418992@id-418992.lymington.irccloud.com) Adeon |
| 2026-04-20 11:59:12 +0000 | Lord_of_Life | (~Lord@user/lord-of-life/x-2819915) (Excess Flood) |