Newest at the top
| 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) |
| 2026-03-10 12:00:28 +0100 | <Freakie> | and I'm not sure how exactly to troubleshoot that |
| 2026-03-10 12:00:20 +0100 | <Freakie> | what confuses me a little is that the algorithm has two parts that are supposed to be roughly equal in work intensity but according to my profiles (at least the eventlog2html renders of them), only one of the algorithms are truly "busy" in terms of allocations |
| 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`) |