Newest at the top
| 2024-10-11 18:20:27 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-11 18:17:37 +0200 | euleritian | (~euleritia@ip4d16fc38.dynamic.kabel-deutschland.de) |
| 2024-10-11 18:17:26 +0200 | euleritian | (~euleritia@176.2.132.103) (Read error: Connection reset by peer) |
| 2024-10-11 18:17:26 +0200 | <k`> | can't do anything with them, it leaves them alone. And of course the number of set branches is the log of the number of thunks it was creating before. |
| 2024-10-11 18:17:25 +0200 | <k`> | Anyway, I was automatically generating huge IntSets representing grapheme break properties, and GHC was compiling them into tens of thousands of thunks (and, in the case of O0, leaving the set definitions completely unevaluated). Using a splice has the desired effect of dumping each branch of the set literally into the simplifier, and since GHC |
| 2024-10-11 18:15:43 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-11 18:12:54 +0200 | <geekosaur> | kinda says soemthing that I've never seen that before, apparently nobody cares about compatibility at all |
| 2024-10-11 18:11:13 +0200 | <geekosaur> | "NOTINLINE is a synonym for NOINLINE (NOINLINE is specified by Haskell 98 as the standard way to disable inlining, so it should be used if you want your code to be portable)." |
| 2024-10-11 18:10:57 +0200 | <geekosaur> | interesting |
| 2024-10-11 18:10:55 +0200 | <geekosaur> | oh, huh, it does say once I follow the chains that NOTINLINE is accepted |
| 2024-10-11 18:10:50 +0200 | <k`> | Ah, guess I'm the fool. I'll try to rewrite that muscle memory. |
| 2024-10-11 18:09:56 +0200 | <geekosaur> | I say that with backing from the manual https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/pragmas.html#inline-and-noinline-pr… |
| 2024-10-11 18:09:29 +0200 | <k`> | 'NOTINLINE' is the original form from the Haskell spec. It still works. |
| 2024-10-11 18:09:11 +0200 | <geekosaur> | (well, if you had warnings enabled)] |
| 2024-10-11 18:09:08 +0200 | <k`> | You say that, but clearly you haven't tried it. |
| 2024-10-11 18:08:57 +0200 | <geekosaur> | it's "NOINLINE" |
| 2024-10-11 18:08:57 +0200 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2024-10-11 18:08:49 +0200 | <geekosaur> | "NOTINLINE" would get you an unrecognized pragma warning |
| 2024-10-11 18:08:39 +0200 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2024-10-11 18:08:21 +0200 | <k`> | NOTINLINE isn't a typo. Try it out. |
| 2024-10-11 18:08:01 +0200 | <c_wraith> | But seriously, inappropriate inlining is the only way I can explain the observed results of generating it with TH reducing code size and compilation time. |
| 2024-10-11 18:06:44 +0200 | cfricke | (~cfricke@user/cfricke) (Quit: WeeChat 4.2.2) |
| 2024-10-11 18:06:42 +0200 | <c_wraith> | Oh, I didn't scroll back quite that far. |
| 2024-10-11 18:06:08 +0200 | <geekosaur> | (well, called it NOTINLINE, hopefully that was only typoed on IRC) |
| 2024-10-11 18:05:51 +0200 | <geekosaur> | [11 13:54:48] <k`> Is there any way to force GHC to statically compile a data structure? I'm generating an IntSet in a source file from the union of a lot of ranges. The set itself is relatively small (thanks to the clever implementation of IntSet), but the resulting interface file and binary are huge. I have already marked the set NOTINLINE and tried O0, O1, and O2. |
| 2024-10-11 18:05:38 +0200 | <geekosaur> | didn't they say they already did that? |
| 2024-10-11 18:04:42 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2024-10-11 18:04:01 +0200 | <c_wraith> | I suppose you could test if a simple NOINLINE pragma also does anything useful |
| 2024-10-11 18:03:07 +0200 | <c_wraith> | I really don't understand what you were doing that made GHC do what it was before. The only thing I can think of is that it was attempting to inline the definition everywhere and run rules with a lot of simplifier steps on it |
| 2024-10-11 18:02:42 +0200 | <geekosaur> | first time I've ever heard of TH making compilation faster |
| 2024-10-11 18:00:17 +0200 | mceresa | (~mceresa@user/mceresa) mceresa |
| 2024-10-11 17:59:59 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-11 17:58:06 +0200 | araujo | (~araujo@45.146.54.21) (Ping timeout: 252 seconds) |
| 2024-10-11 17:56:38 +0200 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2024-10-11 17:56:21 +0200 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2024-10-11 17:56:15 +0200 | euleritian | (~euleritia@176.2.132.103) |
| 2024-10-11 17:55:53 +0200 | spew | (~spew@201.141.99.170) spew |
| 2024-10-11 17:55:29 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 255 seconds) |
| 2024-10-11 17:55:19 +0200 | acidjnk | (~acidjnk@p200300d6e72cfb8501454db6567a02c6.dip0.t-ipconnect.de) (Ping timeout: 264 seconds) |
| 2024-10-11 17:55:13 +0200 | <k`> | And compilation time from about 30 seconds to under a second. |
| 2024-10-11 17:54:32 +0200 | <k`> | Yeah, It's very nice. In this case it also dropped the cmm dump from about 200,000 loc to about 17,000 loc. |
| 2024-10-11 17:54:26 +0200 | euleritian | (~euleritia@dynamic-176-001-134-031.176.1.pool.telefonica.de) (Ping timeout: 252 seconds) |
| 2024-10-11 17:50:29 +0200 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2024-10-11 17:49:34 +0200 | k` | (~k`@152.7.255.192) |
| 2024-10-11 17:49:21 +0200 | k` | (~k`@152.7.255.192) (Quit: Client closed) |
| 2024-10-11 17:48:49 +0200 | synchromesh | (~john@2406:5a00:2497:300:b439:971c:5f64:53b2) synchromesh |
| 2024-10-11 17:47:27 +0200 | synchrom1 | (~john@2406:5a00:2497:300:b439:971c:5f64:53b2) (Read error: Connection reset by peer) |
| 2024-10-11 17:46:30 +0200 | <c_wraith> | But a very pleasant change |
| 2024-10-11 17:46:17 +0200 | <c_wraith> | huh. IntSet having a Lift instance is pretty recent. |
| 2024-10-11 17:44:24 +0200 | <k`> | I think having GHC running optimizing passes over all those little Int thunks was doing terrible things. |