2025/01/11

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 +0100sprotte24(~sprotte24@p200300d16f109200d837c3a3f02cbb16.dip0.t-ipconnect.de)
2025-01-11 20:10:56 +0100merijn(~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 +0100tromp(~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl)
2025-01-11 20:06:10 +0100acidjnk(~acidjnk@p200300d6e7283f90c8dc7c78c19bd00e.dip0.t-ipconnect.de) (Ping timeout: 272 seconds)
2025-01-11 20:05:33 +0100ljdarj(~Thunderbi@user/ljdarj) ljdarj
2025-01-11 20:05:22 +0100merijn(~merijn@128-137-045-062.dynamic.caiway.nl) merijn
2025-01-11 19:59:28 +0100pavonia(~user@user/siracusa) siracusa
2025-01-11 19:59:03 +0100ljdarj(~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 +0100merijn(~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 +0100merijn(~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