Newest at the top
| 2026-03-10 11:58:30 +0100 | <Freakie> | obviously garbage collection is unavoidable but if the runtime explodes for reasons not directly related to the work itself (i.e., not following the asymptotics) then it should be fixed |
| 2026-03-10 11:57:33 +0100 | <Freakie> | jreicher it's "undesirable" in the sense that up to 3/4 of the actual runtime is spent not doing work but just garbage collection |
| 2026-03-10 11:56:58 +0100 | <Freakie> | I've thought about nursery size before but never got around to it, I guess I'll give it a try in not too long |
| 2026-03-10 11:55:31 +0100 | acidjnk | (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-03-10 11:52:22 +0100 | acidjnk_new | (~acidjnk@p200300d6e700e547f0589d3e513577e0.dip0.t-ipconnect.de) acidjnk |
| 2026-03-10 11:48:46 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 11:40:30 +0100 | <probie> | Freakie: does performance improve if you make the nursery bigger? (e.g. try something like `+RTS -A64m -RTS`) |
| 2026-03-10 11:39:41 +0100 | <jreicher> | Some things just have to be GCed; that's the nature of them. (Not the implementation, but the algorithm itself) |
| 2026-03-10 11:39:24 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 11:39:21 +0100 | <jreicher> | Freakie: Just in case it helps, may I question why the garbage collection is "undesirable"? That might sound stupid, but what reason do you have to think it's not needed for your use case? |
| 2026-03-10 11:39:02 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 11:33:24 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-10 11:29:06 +0100 | danza | (~danza@user/danza) (Ping timeout: 248 seconds) |
| 2026-03-10 11:27:11 +0100 | danz32096 | (~danza@user/danza) danza |
| 2026-03-10 11:24:30 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2026-03-10 11:22:00 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
| 2026-03-10 11:21:58 +0100 | <Freakie> | unfortunately purity is pretty essential to what i'm trying to do, which is also why I'm having a difficult time brainstorming alternatives |
| 2026-03-10 11:19:43 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 11:16:53 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) (Ping timeout: 272 seconds) |
| 2026-03-10 11:16:16 +0100 | <probie> | Without actually seeing the code, all anyone here can do is guess. If the situation allows it, try a priority queue backed by some kind of mutable STVector, since you'll be able to enqueue/dequeue without allocations (beyond the occasional allocation to resize the backing vector) |
| 2026-03-10 11:11:08 +0100 | dhil | (~dhil@5.151.29.141) dhil |
| 2026-03-10 11:08:01 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 272 seconds) |
| 2026-03-10 11:06:33 +0100 | fp1 | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 248 seconds) |
| 2026-03-10 11:02:26 +0100 | tromp | (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) |
| 2026-03-10 11:00:28 +0100 | <Freakie> | for me the issue is just having been told multiple times that spending >50% of the runtime on GC suggests that something is wrong with the program ,so I was hoping to have some better way of evaluating that statement |
| 2026-03-10 10:59:38 +0100 | <Freakie> | otherwise I should be able to take advantage of my data structure to offload a lot of the work to using lists which should prevent a lot of rebalancing (and therefore allocations) |
| 2026-03-10 10:58:42 +0100 | <Freakie> | but i'm not sure if that's the right track |
| 2026-03-10 10:58:33 +0100 | <Freakie> | I was considering maybe restructuring my program to reuse the priority queue between different stages of the application so the pointer is kept alive throghout |
| 2026-03-10 10:58:01 +0100 | <Freakie> | the space cost just seems absurdly high still |
| 2026-03-10 10:56:19 +0100 | <probie> | Inserting an element is always going to cause an allocation (or more). You can't really avoid that without mutation (or linearity) |
| 2026-03-10 10:54:40 +0100 | <Freakie> | my fear is that the priority queues just have to handle too much data but on the input sizes I need to handle to the point that rebalancing is infeasible |
| 2026-03-10 10:52:43 +0100 | <Freakie> | they both seem to have the same allocation rate from what I've been able to gather from experimentation |
| 2026-03-10 10:52:09 +0100 | <Freakie> | mostly I've just used Data.Set, but I've also played around with MultiSet and the MinQueue from pqueue |
| 2026-03-10 10:51:50 +0100 | <Freakie> | I've used a typeclass as an abstraction over different implementations |
| 2026-03-10 10:50:52 +0100 | <probie> | How is the priority queue implemented? |
| 2026-03-10 10:45:31 +0100 | danza | (~danza@user/danza) danza |
| 2026-03-10 10:41:59 +0100 | danza | (~danza@user/danza) (Ping timeout: 245 seconds) |
| 2026-03-10 10:41:31 +0100 | <Freakie> | over half my runtime is still spent on garbage collecting and further profiling suggests that something like 90% of all of my allocations are spent on updating a priority queue (a lot of elements are inserted). I'm not sure I can do much to help my situation but if anyone could lend some insight again I'd be grateful |
| 2026-03-10 10:39:33 +0100 | <Freakie> | hi, I was here a few days ago with questions about profiling my program involving BDD algorithms (in case anyone was there and remember) |
| 2026-03-10 10:35:27 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 10:31:23 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) (Changing host) |
| 2026-03-10 10:29:53 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) |
| 2026-03-10 10:21:30 +0100 | chele | (~chele@user/chele) chele |
| 2026-03-10 10:18:56 +0100 | chele | (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-10 10:16:56 +0100 | olivial | (~benjaminl@user/benjaminl) benjaminl |
| 2026-03-10 10:16:40 +0100 | olivial | (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2026-03-10 09:58:59 +0100 | acidjnk | (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) acidjnk |
| 2026-03-10 09:56:26 +0100 | merijn | (~merijn@77.242.116.146) merijn |