Logs: liberachat/#haskell
| 2026-03-10 07:19:00 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 264 seconds) |
| 2026-03-10 07:29:37 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-10 07:31:30 | → | CiaoSen joins (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) |
| 2026-03-10 07:35:10 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 276 seconds) |
| 2026-03-10 07:45:24 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-10 07:46:15 | → | Axman6 joins (~Axman6@user/axman6) |
| 2026-03-10 07:50:09 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-10 07:59:53 | → | merijn joins (~merijn@host-cl.cgnat-g.v4.dfn.nl) |
| 2026-03-10 08:05:51 | → | srazkvt joins (~sarah@user/srazkvt) |
| 2026-03-10 08:07:04 | × | merijn quits (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
| 2026-03-10 08:09:21 | → | fp1 joins (~Thunderbi@2001:708:20:1406::10c5) |
| 2026-03-10 08:10:09 | → | sord937 joins (~sord937@gateway/tor-sasl/sord937) |
| 2026-03-10 08:31:04 | → | chele joins (~chele@user/chele) |
| 2026-03-10 08:38:21 | × | tzh quits (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
| 2026-03-10 08:43:51 | × | emmanuelux quits (~em@user/emmanuelux) (Quit: bye) |
| 2026-03-10 08:44:37 | → | danza joins (~danza@user/danza) |
| 2026-03-10 08:47:30 | → | oskarw joins (~user@user/oskarw) |
| 2026-03-10 08:50:30 | × | humasect quits (~humasect@dyn-192-249-132-90.nexicom.net) (Remote host closed the connection) |
| 2026-03-10 08:52:58 | → | ChaiTRex joins (~ChaiTRex@user/chaitrex) |
| 2026-03-10 08:56:26 | → | merijn joins (~merijn@77.242.116.146) |
| 2026-03-10 08:58:59 | → | acidjnk joins (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) |
| 2026-03-10 09:16:40 | × | olivial quits (~benjaminl@user/benjaminl) (Read error: Connection reset by peer) |
| 2026-03-10 09:16:56 | → | olivial joins (~benjaminl@user/benjaminl) |
| 2026-03-10 09:18:56 | × | chele quits (~chele@user/chele) (Remote host closed the connection) |
| 2026-03-10 09:21:30 | → | chele joins (~chele@user/chele) |
| 2026-03-10 09:29:53 | → | arandombit joins (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) |
| 2026-03-10 09:29:53 | × | arandombit quits (~arandombi@2a02:2455:8656:7100:2149:c35e:cd23:4e9a) (Changing host) |
| 2026-03-10 09:29:53 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-03-10 09:31:23 | → | Freakie joins (~Freakie@37.96.7.244) |
| 2026-03-10 09:35:27 | × | arandombit quits (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-10 09:39:33 | <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 09:41:31 | <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 09:41:59 | × | danza quits (~danza@user/danza) (Ping timeout: 245 seconds) |
| 2026-03-10 09:45:31 | → | danza joins (~danza@user/danza) |
| 2026-03-10 09:50:52 | <probie> | How is the priority queue implemented? |
| 2026-03-10 09:51:50 | <Freakie> | I've used a typeclass as an abstraction over different implementations |
| 2026-03-10 09:52:09 | <Freakie> | mostly I've just used Data.Set, but I've also played around with MultiSet and the MinQueue from pqueue |
| 2026-03-10 09:52:43 | <Freakie> | they both seem to have the same allocation rate from what I've been able to gather from experimentation |
| 2026-03-10 09:54:40 | <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 09:56:19 | <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 09:58:01 | <Freakie> | the space cost just seems absurdly high still |
| 2026-03-10 09:58:33 | <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 09:58:42 | <Freakie> | but i'm not sure if that's the right track |
| 2026-03-10 09:59:38 | <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:00:28 | <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:02:26 | → | tromp joins (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) |
| 2026-03-10 10:06:33 | × | fp1 quits (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 248 seconds) |
| 2026-03-10 10:08:01 | × | xff0x quits (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 272 seconds) |
| 2026-03-10 10:11:08 | → | dhil joins (~dhil@5.151.29.141) |
| 2026-03-10 10:16:16 | <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 10:16:53 | × | tromp quits (~textual@2001:1c00:3487:1b00:5cb9:87bb:7dcb:d170) (Ping timeout: 272 seconds) |
| 2026-03-10 10:19:43 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-03-10 10:21:58 | <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 10:22:00 | → | comerijn joins (~merijn@77.242.116.146) |
| 2026-03-10 10:24:30 | × | merijn quits (~merijn@77.242.116.146) (Ping timeout: 246 seconds) |
| 2026-03-10 10:27:11 | → | danz32096 joins (~danza@user/danza) |
| 2026-03-10 10:29:06 | × | danza quits (~danza@user/danza) (Ping timeout: 248 seconds) |
| 2026-03-10 10:33:24 | × | arandombit quits (~arandombi@user/arandombit) (Ping timeout: 264 seconds) |
| 2026-03-10 10:39:02 | × | marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 10:39:21 | <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 10:39:24 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 2026-03-10 10:39:41 | <jreicher> | Some things just have to be GCed; that's the nature of them. (Not the implementation, but the algorithm itself) |
| 2026-03-10 10:40:30 | <probie> | Freakie: does performance improve if you make the nursery bigger? (e.g. try something like `+RTS -A64m -RTS`) |
| 2026-03-10 10:48:46 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-03-10 10:52:22 | → | acidjnk_new joins (~acidjnk@p200300d6e700e547f0589d3e513577e0.dip0.t-ipconnect.de) |
| 2026-03-10 10:55:31 | × | acidjnk quits (~acidjnk@p200300d6e700e52576436b4620b4c2a8.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
| 2026-03-10 10:56:58 | <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 10:57:33 | <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 10:58:30 | <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:00:20 | <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:00:28 | <Freakie> | and I'm not sure how exactly to troubleshoot that |
| 2026-03-10 11:03:43 | → | xff0x joins (~xff0x@2405:6580:b080:900:cfba:7074:7dbc:e7e9) |
| 2026-03-10 11:10:43 | × | marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 11:11:08 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 2026-03-10 11:20:08 | × | Googulator quits (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 11:20:42 | → | Googulator joins (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 11:21:42 | × | CiaoSen quits (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Quit: CiaoSen) |
| 2026-03-10 11:23:44 | → | Pozyomka joins (~pyon@user/pyon) |
| 2026-03-10 11:26:40 | → | CiaoSen joins (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) |
| 2026-03-10 11:29:40 | → | tristanC joins (~tristanC@user/tristanc) |
| 2026-03-10 11:35:20 | × | Googulator quits (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) (Quit: Client closed) |
| 2026-03-10 11:35:34 | → | Googulator joins (~Googulato@2a01-036d-0106-0119-01e8-0aed-2fac-7c8a.pool6.digikabel.hu) |
| 2026-03-10 11:37:57 | × | pabs3 quits (~pabs3@user/pabs3) (Ping timeout: 272 seconds) |
| 2026-03-10 11:39:45 | × | marinelli quits (~weechat@gateway/tor-sasl/marinelli) (Remote host closed the connection) |
| 2026-03-10 11:40:09 | → | marinelli joins (~weechat@gateway/tor-sasl/marinelli) |
| 2026-03-10 11:42:32 | × | Freakie quits (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 11:45:19 | × | danz32096 quits (~danza@user/danza) (Remote host closed the connection) |
| 2026-03-10 11:51:04 | → | pabs3 joins (~pabs3@user/pabs3) |
| 2026-03-10 11:55:16 | <comerijn> | Freakie: How big is your queue? |
| 2026-03-10 11:56:44 | <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 11:56:56 | <comerijn> | And large live sets are a worst case for GHCs GC approach |
| 2026-03-10 11:57:09 | → | Freakie joins (~Freakie@37.96.7.244) |
| 2026-03-10 11:59:44 | × | arandombit quits (~arandombi@user/arandombit) (Remote host closed the connection) |
| 2026-03-10 12:01:04 | <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:02:47 | → | arandombit joins (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) |
| 2026-03-10 12:02:47 | × | arandombit quits (~arandombi@2a02:2455:8656:7100:4919:8888:312f:1c7c) (Changing host) |
| 2026-03-10 12:02:47 | → | arandombit joins (~arandombi@user/arandombit) |
| 2026-03-10 12:03:37 | <Freakie> | I've been considering doing that as well but it's a larger process |
| 2026-03-10 12:03:50 | <Freakie> | (assuming you're responding to my previous comments) |
| 2026-03-10 12:14:57 | → | __monty__ joins (~toonn@user/toonn) |
All times are in UTC.