Newest at the top
2024-04-29 23:28:28 +0200 | <shapr> | tomsmeding: sent! |
2024-04-29 23:27:32 +0200 | <shapr> | right on |
2024-04-29 23:27:29 +0200 | <tomsmeding> | (the '@' is syntax, put the filename after it) |
2024-04-29 23:27:22 +0200 | <tomsmeding> | curl --data-binary @thefile.mix https://tomsmeding.com/gooi/file.mix |
2024-04-29 23:27:07 +0200 | <tomsmeding> | what's in the file |
2024-04-29 23:26:53 +0200 | <shapr> | yes, I wonder why the regions explode like that? |
2024-04-29 23:25:48 +0200 | <tomsmeding> | but surely those regions are still about the source, not about the core? |
2024-04-29 23:25:21 +0200 | cashew | (~cashewsta@65.17.175.150) (Ping timeout: 252 seconds) |
2024-04-29 23:24:55 +0200 | <shapr> | Well, you get more regions with more depth, but I wouldn't expect this sort of size explosion |
2024-04-29 23:24:28 +0200 | <tomsmeding> | so you'd expect that to scale about linearly with program text size divided by the average variable name length? |
2024-04-29 23:23:52 +0200 | <tomsmeding> | I see |
2024-04-29 23:23:40 +0200 | <shapr> | tomsmeding: the mix file holds the list of regions that can be annotated, it's later turned into the pretty html output: https://wiki.haskell.org/Haskell_program_coverage |
2024-04-29 23:23:39 +0200 | <tomsmeding> | those are long arrays |
2024-04-29 23:23:11 +0200 | <shapr> | https://github.com/AccelerateHS/accelerate/blob/master/src/Data/Array/Accelerate/Test/NoFib/Issues… |
2024-04-29 23:23:07 +0200 | tomsmeding | has no reference here |
2024-04-29 23:22:59 +0200 | <shapr> | 82kb source file turned into a 440kb mix file |
2024-04-29 23:21:50 +0200 | <shapr> | wow, hpc produced a 440k mix file |
2024-04-29 23:20:59 +0200 | <tomsmeding> | surely it's the former, you don't want core coverage, you want haskell coverage |
2024-04-29 23:20:42 +0200 | <tomsmeding> | if the former, then core size is irrelevant |
2024-04-29 23:20:34 +0200 | <tomsmeding> | does it do that at the source level or in core after optimisation |
2024-04-29 23:20:26 +0200 | <shapr> | now that you mention it, lemme check the size of the mix files |
2024-04-29 23:20:14 +0200 | <shapr> | iirc, hpc puts a counter on every little definition |
2024-04-29 23:20:07 +0200 | <tomsmeding> | because compilation is definitely slow, but that's not the issue at hand here |
2024-04-29 23:20:04 +0200 | <shapr> | that's my guess |
2024-04-29 23:19:53 +0200 | <tomsmeding> | that there's just a huge amount of core, you mean? |
2024-04-29 23:19:19 +0200 | <shapr> | but that's just a guess |
2024-04-29 23:19:16 +0200 | <shapr> | I would guess it's related to the specialize things in that bug report |
2024-04-29 23:18:58 +0200 | <tomsmeding> | I wonder why HPC is tripping on it |
2024-04-29 23:18:53 +0200 | <tomsmeding> | the `accelerate` package itself is actually not anything special, it's just haskell |
2024-04-29 23:18:25 +0200 | <tomsmeding> | the latter just has an interpreter in normal haskell |
2024-04-29 23:18:15 +0200 | <shapr> | ah, not a problem then |
2024-04-29 23:18:15 +0200 | <tomsmeding> | not in `accelerate` |
2024-04-29 23:18:09 +0200 | <tomsmeding> | the LLVM stuff is in accelerate-llvm{,-native,-ptx} |
2024-04-29 23:17:26 +0200 | <shapr> | I'd see an error, right? |
2024-04-29 23:17:20 +0200 | <shapr> | I'm using nixos, and LLVM is not in scope, could that be it? |
2024-04-29 23:16:46 +0200 | <tomsmeding> | (which HPC might actually be fine with considering that's just FFI calls in the end) |
2024-04-29 23:16:17 +0200 | <tomsmeding> | this is not even the backend, which does runtime code generation using LLVM |
2024-04-29 23:16:16 +0200 | <shapr> | but again, doesn't help me poke at kudzu |
2024-04-29 23:15:53 +0200 | <shapr> | I'd believe that |
2024-04-29 23:15:47 +0200 | <tomsmeding> | surely this is a bug somewhere |
2024-04-29 23:14:44 +0200 | <shapr> | looks like it sticks on "sort:" |
2024-04-29 23:14:03 +0200 | cashew | (~cashewsta@65.17.175.150) |
2024-04-29 23:12:45 +0200 | <tomsmeding> | does it spin infinitely on one case or does it progress super slowly |
2024-04-29 23:12:15 +0200 | <shapr> | heh, ok |
2024-04-29 23:12:12 +0200 | <tomsmeding> | at least then you know what you're getting :p |
2024-04-29 23:12:07 +0200 | <tomsmeding> | try `cabal run nofib-accelerate -f nofib --enable-coverage` |
2024-04-29 23:11:47 +0200 | <tomsmeding> | can `cabal test` die |
2024-04-29 23:11:45 +0200 | <tomsmeding> | it doesn't even write the file until it's done? |
2024-04-29 23:11:44 +0200 | <shapr> | I can re-run with --test-show-details=direct if you want |
2024-04-29 23:11:33 +0200 | <shapr> | so either it's not writing to the file, or it writes at the end |