Newest at the top
| 2026-03-07 14:41:02 +0100 | <Guest89> | I mean the primary data structure is itself one big list, but I'm still not sure whether laziness or not is the way to go |
| 2026-03-07 14:40:04 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-07 14:39:48 +0100 | <[exa]> | (except the ones where you know that laziness is required) |
| 2026-03-07 14:39:25 +0100 | <[exa]> | also do add bangs to all your datatype definitions (Pair !Ptr !Ptr, etc) |
| 2026-03-07 14:38:53 +0100 | <Guest89> | inlining seemed to take the worst of the initial overhead (like 20% or something) but yeah, thunsk everywhere |
| 2026-03-07 14:38:52 +0100 | madresch | (~Thunderbi@user/madresch) (Ping timeout: 256 seconds) |
| 2026-03-07 14:38:30 +0100 | <Guest89> | I will look into it |
| 2026-03-07 14:38:23 +0100 | <[exa]> | anyway lots of the allocations in your profile actually seem to point to typeclass methods so I guess that a bit of specialization could help there |
| 2026-03-07 14:38:16 +0100 | <Guest89> | so compiler- or language-specific optimizations are kind of not the point there |
| 2026-03-07 14:37:45 +0100 | <Guest89> | well it's supposed to be an implementation that can be used as a jumping-off point if someone more nerdy about proofs would want to make a provably correct version |
| 2026-03-07 14:37:12 +0100 | CallipygousPepe | (~reuben@user/CallipygousPepe) CallipygousPepe |
| 2026-03-07 14:36:39 +0100 | <[exa]> | Guest89: by "semantically correct" you mean "readable" :D |
| 2026-03-07 14:35:53 +0100 | <Guest89> | my tl;dr is that the extra LOC should be whatever |
| 2026-03-07 14:35:36 +0100 | <Guest89> | I'm doing this for my master's thesis, but I'll probably end up presenting a "clean" version that's semantically correct in the thesis itself and then using an optimized version for the actual benchmarks |
| 2026-03-07 14:34:20 +0100 | <[exa]> | (tbh my binary changed from like 9M to 9.5M when I was trying it, so I decided I don't care) |
| 2026-03-07 14:33:54 +0100 | <[exa]> | yeah it may cost an extra copy of the code |
| 2026-03-07 14:33:38 +0100 | <[exa]> | like, the part with typeclass dictionaries getting passed around is not a huge deal, but in the end you may have 1 less allocation, and the possibility to specialize is open |
| 2026-03-07 14:33:06 +0100 | <Guest89> | you have to do twice the work though in terms of source code though, right? |
| 2026-03-07 14:33:00 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) chromoblob\0 |
| 2026-03-07 14:32:45 +0100 | <Guest89> | hmm |
| 2026-03-07 14:32:43 +0100 | chromoblob | (~chromoblo@user/chromob1ot1c) (Read error: Connection reset by peer) |
| 2026-03-07 14:32:43 +0100 | <[exa]> | yeah |
| 2026-03-07 14:32:38 +0100 | <Guest89> | from the specialization |
| 2026-03-07 14:32:34 +0100 | <Guest89> | because it has a separate definition already? |
| 2026-03-07 14:32:31 +0100 | <[exa]> | and the specialized code is much more likely to realize that it can do stuff strictly |
| 2026-03-07 14:32:17 +0100 | <[exa]> | if you specialize code you don't need to send the typeclass pointer around |
| 2026-03-07 14:31:57 +0100 | <[exa]> | in short ghc seemed quite lazy to inline stuff across modules unless I asked for it explicitly |
| 2026-03-07 14:31:53 +0100 | arandombit | (~arandombi@user/arandombit) (Ping timeout: 268 seconds) |
| 2026-03-07 14:31:45 +0100 | <Guest89> | what are the benefits of specializing, exactly? |
| 2026-03-07 14:31:19 +0100 | <Guest89> | mostly I've tried to use pragmas to force things like inlining, but I haven't done anything to specialize |
| 2026-03-07 14:31:03 +0100 | <Guest89> | I can try some of the other settings later though |
| 2026-03-07 14:30:57 +0100 | <Guest89> | I've got -O1 enabled atm but I didn't observe much when I tried -O2 |
| 2026-03-07 14:30:38 +0100 | <[exa]> | Guest89: ( ghc-options: -O2 -fspecialise-aggressively -fexpose-all-unfoldings ) |
| 2026-03-07 14:30:35 +0100 | <Guest89> | not anything that specializes |
| 2026-03-07 14:30:27 +0100 | <[exa]> | Guest89: do you have some compiler options that force it to specialize stuff? |
| 2026-03-07 14:29:34 +0100 | <Guest89> | yeah I'm working on it exa; I'm not seeing as big a reduction in memory as I expected. seems more thunks are being allocated now instead |
| 2026-03-07 14:28:55 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-07 14:28:19 +0100 | <[exa]> | ( "similar" based solely on fact I had complex IDs and a structure of them :D ) |
| 2026-03-07 14:27:17 +0100 | <haskellbridge> | <loonycyborg> > length [undefined, undefined, undefined] |
| 2026-03-07 14:26:55 +0100 | <[exa]> | Guest89: based on my experience on a similar project that allocated a lot, you really want to make the tuples strict. |
| 2026-03-07 14:26:50 +0100 | <haskellbridge> | <loonycyborg> hmm nice |
| 2026-03-07 14:26:31 +0100 | <lambdabot> | 3 |
| 2026-03-07 14:26:30 +0100 | <haskellbridge> | > length [undefined, undefined, undefined] |
| 2026-03-07 14:26:30 +0100 | <haskellbridge> | <loonycyborg> test |
| 2026-03-07 14:26:14 +0100 | <haskellbridge> | length [undefined, undefined, undefined] |
| 2026-03-07 14:26:14 +0100 | <haskellbridge> | <loonycyborg> test |
| 2026-03-07 14:26:11 +0100 | <int-e> | well, it had a leading space |
| 2026-03-07 14:25:26 +0100 | <__monty__> | Yep, the latter. |
| 2026-03-07 14:25:16 +0100 | <haskellbridge> | <loonycyborg> is one of those tests without prefix? |
| 2026-03-07 14:24:54 +0100 | <haskellbridge> | test |