Newest at the top
| 2025-01-11 19:56:46 +0100 | <bailsman> | but that still requires generics |
| 2025-01-11 19:56:44 +0100 | <EvanR> | python script to write all your lenses for you xD |
| 2025-01-11 19:56:40 +0100 | <bailsman> | I'm not using lenses anymore either. I like overloadedrecordupdate better |
| 2025-01-11 19:56:37 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-11 19:56:08 +0100 | <c_wraith> | Oh, I'd never derive lenses. Just write them by hand. They're like 2 lines each. |
| 2025-01-11 19:55:53 +0100 | <c_wraith> | I mean they fixed the "starting an interpreter takes 10 seconds of flat overhead" thing. |
| 2025-01-11 19:55:49 +0100 | <bailsman> | Just deriving lenses |
| 2025-01-11 19:55:40 +0100 | <geekosaur> | I'm afraid to ask what you're doing that takes 20 seconds |
| 2025-01-11 19:55:35 +0100 | <bailsman> | that's with GHC 9.13 |
| 2025-01-11 19:55:31 +0100 | <bailsman> | What do you mean anymore? |
| 2025-01-11 19:55:25 +0100 | <c_wraith> | it definitely used to be |
| 2025-01-11 19:55:19 +0100 | <c_wraith> | ... yeah, TH isn't that slow anymore |
| 2025-01-11 19:55:08 +0100 | <bailsman> | It literally goes from compiling instantly to taking 20+ seconds every time. |
| 2025-01-11 19:55:06 +0100 | <geekosaur> | I know the why, I just don't need them. I looked into how they work only because someone at one point tossed out the thing about GHC generics being a lousy implementation of sums-of-products |
| 2025-01-11 19:54:57 +0100 | <c_wraith> | template haskell is a lot faster than it used to be in the 8.x and earlier days |
| 2025-01-11 19:54:42 +0100 | <bailsman> | And the best part is it still compiles instantly, unlike template haskell, which is an abomination that should be scoured from the earth. |
| 2025-01-11 19:54:02 +0100 | <c_wraith> | It turns out you can just ignore generics for nearly everything you do! |
| 2025-01-11 19:54:00 +0100 | <bailsman> | Anyway my experience with generics has been very positive. generic-lens, derive-storable etc, its one line and it just works TM. That's why I figured maybe I can make my data types serializable in one line too |
| 2025-01-11 19:53:35 +0100 | <geekosaur> | `deriving stock` that is |
| 2025-01-11 19:53:28 +0100 | <c_wraith> | ghc generics are something I've still never learned the how or why of. |
| 2025-01-11 19:53:22 +0100 | <geekosaur> | maybe if it really mattered I'd consider writing a compiler plugin to replace the TH, I think you can add new "default deriving" mechanisms that way |
| 2025-01-11 19:52:44 +0100 | <geekosaur> | but from what I know of ghc generics I think if I needed them I'd eat the cost of TH and use generics-sop instead |
| 2025-01-11 19:52:18 +0100 | <geekosaur> | ) |
| 2025-01-11 19:52:14 +0100 | <geekosaur> | (most of my programming doesn't benefot from generics_ |
| 2025-01-11 19:52:08 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-11 19:51:59 +0100 | <geekosaur> | if it has to "re-derive" the setField at runtime for every use, you could be very unhappy. I haven't delved into generics deeply enough to know how smart that part is |
| 2025-01-11 19:51:21 +0100 | <geekosaur> | (creation cost is amortized over the uses) |
| 2025-01-11 19:51:12 +0100 | <geekosaur> | setField I'm not sure of. if it's only done once instead of once per use it probably ends up being a win depending on how often it's used |
| 2025-01-11 19:50:38 +0100 | <bailsman> | but if I use a generically derived "setField" it would go indirect? (let me try to figure out how to dump the core output for such a field access) |
| 2025-01-11 19:49:54 +0100 | <geekosaur> | right |
| 2025-01-11 19:49:41 +0100 | <bailsman> | OK I think I get it. What is going through the generic layer is "how do I lay this out in memory?" but the data access does not go through that layer in this case. |
| 2025-01-11 19:49:33 +0100 | <geekosaur> | this may end up being equal cost, if there's a single iteration, because making the `Storable` does the same list traversal unless you were starting from a vector to begin with (in which case there is no point in comparing these because vectors will always beat lists) |
| 2025-01-11 19:48:30 +0100 | <geekosaur> | but the result of GStorable is everything next to each other. |
| 2025-01-11 19:48:05 +0100 | <geekosaur> | in the case of lists vs. GStorable: you convert once, you do possibly many accesses afterward. if you go directly via pure lists you're dereferencing pointers to values, then pointers to the next list cell, then pointer to its value, etc. |
| 2025-01-11 19:47:53 +0100 | cheater_ | cheater |
| 2025-01-11 19:47:46 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 252 seconds) |
| 2025-01-11 19:46:58 +0100 | <bailsman> | no you're communicating, I'm just missing a lot of stuff because I'm new |
| 2025-01-11 19:46:49 +0100 | stef204 | (~stef204@user/stef204) stef204 |
| 2025-01-11 19:46:46 +0100 | <geekosaur> | I thought I explained that already |
| 2025-01-11 19:46:38 +0100 | <geekosaur> | I, uh, think we're not communicating |
| 2025-01-11 19:46:36 +0100 | swistak | (~swistak@185.21.216.141) |
| 2025-01-11 19:46:07 +0100 | <bailsman> | in one line |
| 2025-01-11 19:45:59 +0100 | <bailsman> | made storable with "instance GStorable myrecord" |
| 2025-01-11 19:45:56 +0100 | <geekosaur> | there's no reason to chase pointers in that case, all elements are laid out next to each other |
| 2025-01-11 19:45:41 +0100 | <geekosaur> | you said storable vectors |
| 2025-01-11 19:45:29 +0100 | <bailsman> | If it's runtime as you say |
| 2025-01-11 19:45:28 +0100 | cheater_ | (~Username@user/cheater) cheater |
| 2025-01-11 19:45:19 +0100 | <bailsman> | But why doesn't the generic layer cause pointer chasing? |
| 2025-01-11 19:45:09 +0100 | <geekosaur> | consecutive memory locations are always going to be faster than lots of pointer chasing |
| 2025-01-11 19:45:06 +0100 | <bailsman> | I don't understand, if it's going through some generic indirection, I'd expect that to be about as slow as boxed vectors. I thought what made those slow was the indirection |