Newest at the top
2025-01-11 20:17:11 +0100 | <haskellbridge> | <Bowuigi> Interesting, GHC is actually very smart |
2025-01-11 20:16:33 +0100 | <bailsman> | so far as I can understand - I'm not an expert in reading the simpl output - it has entirely optimized out my setfield calls to just creating a new record passing in values from the original values by direct field access and/or the values that I passed in, which seems optimal. No mention of generic anything. |
2025-01-11 20:16:11 +0100 | <monochrom> | I haven't seen an example, but it is said that O2 can be slower than O1 for some code, hence I analogize it to gcc's O3. |
2025-01-11 20:14:37 +0100 | <monochrom> | OK vector is one of the few exceptions where O2 is necessary. |
2025-01-11 20:13:48 +0100 | <bailsman> | I don't actually really know what the difference is. |
2025-01-11 20:13:35 +0100 | <bailsman> | BEcause when I did my microbenchmarks with the storable vectors -O2 was much much faster, I believe because it was specializing better |
2025-01-11 20:12:53 +0100 | <monochrom> | And yeah, actually ghc : 1 : 2 :: gcc : 2 : 3 |
2025-01-11 20:12:46 +0100 | <c_wraith> | (most code is compiled at -O1, as it's the default and hackage even warns you about uploading -O2) |
2025-01-11 20:12:08 +0100 | <monochrom> | Yeah the -O0 code is also suspiciously much shorter. >:) |
2025-01-11 20:12:07 +0100 | <c_wraith> | why not -O1? that's the most relevant level |
2025-01-11 20:12:02 +0100 | <haskellbridge> | <Bowuigi> Check for calls to the generic methods instead |
2025-01-11 20:11:32 +0100 | <haskellbridge> | <Bowuigi> They might be inlined but still there |
2025-01-11 20:11:02 +0100 | sprotte24 | (~sprotte24@p200300d16f109200d837c3a3f02cbb16.dip0.t-ipconnect.de) |
2025-01-11 20:10:56 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
2025-01-11 20:10:43 +0100 | <bailsman> | OK I checked -ddump-simpl output, comparing -O0 and -O2. In -O0, there is "setField" all over the place. In -O2, there's no setField calls anywhere. Can I conclude these are actually getting optimized out, despite being generic? |
2025-01-11 20:10:35 +0100 | <EvanR> | haskell script to generate haskell |
2025-01-11 20:08:10 +0100 | <monochrom> | If someone else has already written the TH version, of course you can just use it and do nothing. But if no one has written either version and you have to write one yourself, the generics route is easier to write. |
2025-01-11 20:06:51 +0100 | <monochrom> | The GHC.Generics route has a linear-time runtime cost (to and from clones your input), whereas the TH route generates direct code that skips that. To be sure, I am lazy so I just use the generics route and not care about performance. :) |
2025-01-11 20:06:27 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
2025-01-11 20:06:10 +0100 | acidjnk | (~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 272 seconds) |
2025-01-11 20:05:33 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-01-11 20:05:22 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
2025-01-11 19:59:28 +0100 | pavonia | (~user@user/siracusa) siracusa |
2025-01-11 19:59:03 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 246 seconds) |
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 |