Newest at the top
| 2026-03-10 13:24:13 +0100 | <Freakie> | I've done lots of small optimizations since |
| 2026-03-10 13:24:10 +0100 | <comerijn> | Freakie: GHC does a copy&collect (so all live data is copied into a new heap, then we just wipe the old heap) |
| 2026-03-10 13:24:09 +0100 | <Freakie> | I already had compactness in mind but the one time I tried doing it it, it seemed to have no effect |
| 2026-03-10 13:23:49 +0100 | <comerijn> | Freakie: What c_wraith mentioned might help (compact regions) those let you treat large chunks of life data as a single pointer, which will speed up GC considerably |
| 2026-03-10 13:23:18 +0100 | <comerijn> | I'll have to see if I can find it |
| 2026-03-10 13:23:09 +0100 | <Freakie> | can you link the post again? |
| 2026-03-10 13:22:59 +0100 | <Leary> | Freakie: In future, check the logs; they're linked in the topic. |
| 2026-03-10 13:22:40 +0100 | <comerijn> | Freakie: That and the fact that laziness does lots of short-lived allocations, so the GC is tuned for fast allocation and short-lived data |
| 2026-03-10 13:22:35 +0100 | <Freakie> | doublechecking residency |
| 2026-03-10 13:22:25 +0100 | <Freakie> | I don't have any metrics on the queue size but it's likely to be quite large in general because of the problem itself I'm benchmarking (encoding a boolean formula for n-queens) |
| 2026-03-10 13:21:43 +0100 | <comerijn> | And my other previous comment: there's a well known blogpost from ages ago of a company struggle with Haskell GC also for a queue and part of their problem (and, I suspect, yours) was that their inherent problem involved a large liveset |
| 2026-03-10 13:21:41 +0100 | <Freakie> | I assume that's linked to pointers being acylic |
| 2026-03-10 13:21:17 +0100 | <comerijn> | Freakie: Therefore big live sets will increase your GC times quite a bit |
| 2026-03-10 13:21:00 +0100 | <comerijn> | Freakie: Note that (unlike what you may be used to from most GC languages) GHC's GC scales in live data, not garbage |
| 2026-03-10 13:20:31 +0100 | <comerijn> | Freakie: And I asked how big your queue was |
| 2026-03-10 13:20:21 +0100 | <comerijn> | Freakie: Max residency |
| 2026-03-10 13:20:11 +0100 | <Freakie> | by live set do you mean maximum residency or total memory in use as per reported by +RTS -s or do you mean the number of objects that are live at a time? |
| 2026-03-10 13:19:28 +0100 | <Freakie> | comerijn: sorry no, I had to change locations so I haven't seen anything for the past hour |
| 2026-03-10 13:18:55 +0100 | <comerijn> | Freakie: Also you mentioned avoiding allocations, but those are incredibly cheap so that's almost never worth it |
| 2026-03-10 13:17:35 +0100 | <comerijn> | Freakie: Also, how big is your live set? |
| 2026-03-10 13:17:29 +0100 | <comerijn> | Freakie: Did you see my comments? |
| 2026-03-10 13:14:57 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2026-03-10 13:03:50 +0100 | <Freakie> | (assuming you're responding to my previous comments) |
| 2026-03-10 13:03:37 +0100 | <Freakie> | I've been considering doing that as well but it's a larger process |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 13:02:47 +0100 | arandombit | (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 13:01:04 +0100 | <c_wraith> | Huh. I never really thought about making each entry in a container its own compact region, but there are cases where that could really reduce GC pressure. (like if there aren't all that many entries, but they have a lot of internal pointers) |
| 2026-03-10 12:59:44 +0100 | arandombit | (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-10 12:57:09 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 12:56:56 +0100 | <comerijn> | And large live sets are a worst case for GHCs GC approach |
| 2026-03-10 12:56:44 +0100 | <comerijn> | because there's a well known blogpost from ages ago of a company struggle with Haskell GC also for a queue and part of their problem (and, I suspect, yours) was that their inherent problem involved a large liveset |
| 2026-03-10 12:55:16 +0100 | <comerijn> | Freakie: How big is your queue? |
| 2026-03-10 12:51:04 +0100 | pabs3 | (~pabs3@user/pabs3) pabs3 |
| 2026-03-10 12:45:19 +0100 | danz32096 | (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-10 12:42:32 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 12:40:09 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:39:45 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:37:57 +0100 | pabs3 | (~pabs3@user/pabs3) (Ping timeout: 272 seconds) |
| 2026-03-10 12:35:34 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:35:20 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:29:40 +0100 | tristanC | (~tristanC@user/tristanc) tristanC |
| 2026-03-10 12:26:40 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) CiaoSen |
| 2026-03-10 12:23:44 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2026-03-10 12:21:42 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Quit: CiaoSen) |
| 2026-03-10 12:20:42 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 12:20:08 +0100 | Googulator | (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 12:11:08 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) marinelli |
| 2026-03-10 12:10:43 +0100 | marinelli | (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 12:03:43 +0100 | xff0x | (~xff0x@2405:6580:b080:900:cfba:7074:7dbc:e7e9) |