Newest at the top
| 2025-01-08 21:11:05 +0100 | <c_wraith> | And while it can do that in a single module with -O2, it does not appear to do it cross-module with -O2 |
| 2025-01-08 21:10:38 +0100 | <c_wraith> | It needs a worker/wrapper transform for GHC to inline it at all |
| 2025-01-08 21:10:21 +0100 | <c_wraith> | I think the INLINE pragma is being ignored because the definition it would need to apply to is directly recursive |
| 2025-01-08 21:09:51 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
| 2025-01-08 21:09:51 +0100 | <c_wraith> | Oh. No, I think this idea just doesn't work. |
| 2025-01-08 21:07:00 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
| 2025-01-08 21:04:40 +0100 | visilii | (~visilii@213.24.125.237) (Ping timeout: 265 seconds) |
| 2025-01-08 21:03:50 +0100 | hseg | (~gesh@46.120.21.249) (Ping timeout: 272 seconds) |
| 2025-01-08 21:00:44 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-01-08 21:00:35 +0100 | visilii_ | (~visilii@188.254.110.9) |
| 2025-01-08 21:00:04 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-01-08 20:55:56 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-01-08 20:55:26 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-01-08 20:53:50 +0100 | <c_wraith> | I might need to compile it as a sublibrary |
| 2025-01-08 20:53:26 +0100 | <c_wraith> | Huh. Looks like cabal might override the -O2 in an OPTIONS_GHC pragma |
| 2025-01-08 20:52:07 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2025-01-08 20:41:28 +0100 | raym | (~ray@user/raym) raym |
| 2025-01-08 20:35:57 +0100 | <tomsmeding> | which sounds like what you want here |
| 2025-01-08 20:35:51 +0100 | <tomsmeding> | > So GHC guarantees to inline precisely the code that you wrote, no more and no less. |
| 2025-01-08 20:35:44 +0100 | <tomsmeding> | but the GHC user's guide says: ( https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#inline-and-noinline-pr… ) |
| 2025-01-08 20:35:15 +0100 | <tomsmeding> | yeah this may be too much trickery |
| 2025-01-08 20:33:15 +0100 | <c_wraith> | Huh. Not sure how INLINE interacts with this. |
| 2025-01-08 20:30:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-01-08 20:28:16 +0100 | <tomsmeding> | ctrl-D is often faster than typing "exit" ... oh too late |
| 2025-01-08 20:28:10 +0100 | mari41300 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-08 20:28:06 +0100 | <mari41300> | sorry i'm tired. See you all o/ |
| 2025-01-08 20:27:55 +0100 | <mari41300> | :P |
| 2025-01-08 20:27:51 +0100 | <mari41300> | exit |
| 2025-01-08 20:27:37 +0100 | <tomsmeding> | c_wraith: is it just one function? mark them as INLINE, use them (trivially, in a wrapper function) in two separate modules, compile those two modules with different options? |
| 2025-01-08 20:27:21 +0100 | <smiesner> | thanks all :) |
| 2025-01-08 20:27:08 +0100 | <smiesner> | tomsmeding: will try that for sure! |
| 2025-01-08 20:24:02 +0100 | <tomsmeding> | if that works, then you can `:def R \_ -> Prelude.return ":!cabal build\n:r"` to define a ghci command :R that first builds and then reloads ;) |
| 2025-01-08 20:23:37 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) (Quit: sord937) |
| 2025-01-08 20:23:13 +0100 | <tomsmeding> | smiesner: also try running 'cabal build' in another terminal, and then :r |
| 2025-01-08 20:21:37 +0100 | l__k | (~student@188.254.126.139) (Ping timeout: 252 seconds) |
| 2025-01-08 20:18:53 +0100 | l_k | (~student@213.24.133.217) |
| 2025-01-08 20:18:23 +0100 | plitter | (~plitter@user/plitter) plitter |
| 2025-01-08 20:17:20 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) () |
| 2025-01-08 20:17:11 +0100 | <c_wraith> | (my point is to demonstrate how much easier a time GHC has when you write code that's easily amenable to optimization, instead of making it apply the slow -O2 stuff to find places to optimize) |
| 2025-01-08 20:15:49 +0100 | <c_wraith> | usually you'd only run benchmarks with the options you're actually using. My case is uncommon in that what I really want to demonstrate is the difference between them. (One benchmark is unaffected, a different one improves immensely) |
| 2025-01-08 20:14:55 +0100 | <mari41300> | well i guess it would be common for benchs to be run multiple times with different opts |
| 2025-01-08 20:14:10 +0100 | l_k | (~student@81.177.126.233) (Ping timeout: 252 seconds) |
| 2025-01-08 20:14:02 +0100 | <c_wraith> | err, benchmark suite |
| 2025-01-08 20:13:55 +0100 | <c_wraith> | mari41300: I can't compile my test suite with -O1 and -O2 simultaneously. The best I could manage is moving it into multiple modules with different ghc options per module and duplicating the definition between multiple modules. That's not great for maintainability |
| 2025-01-08 20:13:34 +0100 | OftenFaded53 | (~OftenFade@user/tisktisk) OftenFaded |
| 2025-01-08 20:11:26 +0100 | <mari41300> | i did not get what you meant c_wraith |
| 2025-01-08 20:11:24 +0100 | l__k | (~student@188.254.126.139) |
| 2025-01-08 20:10:14 +0100 | saulosilva | (~saulosilv@181.216.220.21) (Quit: Client closed) |
| 2025-01-08 20:10:04 +0100 | <mari41300> | hm but odd that the cabal repl does not detect changes cabal build would |
| 2025-01-08 20:08:57 +0100 | <haskellbridge> | <sm> also, if you are reloading a lot, I find this really useful in .ghci: :def rmain \args -> return $ ":reload\n:main "<>args |