| 8 Oct 2024 |
 MangoIV | In reply to @eldritchcookie:matrix.org
what would be the benefits? i guess if performance is critical you could use SIMD via LLVM but unless you have a custom modification to GHC itself that seems like too much effort I mean if you have a service that does a lot of arithmetic and the LLVM backend actually gives you considerable speed up then it might be very well worth a consideration. | 14:45:10 |
| MangoIV | Also mind that all the c libraries you’re binding are compiled without vector instructions. | 14:46:08 |
| MangoIV | That can sometimes give you a nx speed up | 14:46:50 |
| MangoIV | I just realised since I’m using a dep that implements an embarassingly parallelizable algorithm and the library actually wants to compile to AVX2 instructions but of course it doesn’t | 14:50:41 |
 alexfmpe | In reply to @mangoiv.:matrix.org
Something that just came to mind due to other things: Does anybody who use Nixpkgs + Haskell at work do something crazy like compile the entire dependency tree with certain modifications like specific platform specific instructions or the LLVM backend? Sort of? Using reflex-platform's package set means you get -fexpose-all-unfoldings everywhere plus a custom Text on JS plus a (not yet upstreamed) patch for GHC's garbage collection | 14:54:11 |
| alexfmpe | I think miso also has a fancy String but not sure whether they replace Text with it | 14:54:35 |
| alexfmpe | * I think miso also has a fancy string on JS but not sure whether they replace Text with it | 14:54:46 |
| MangoIV | Interesting. Though probably not as far reaching as I’d imagine. Also instane wrt exposing all unfoldings, what kinda machine are these package sets built on?! 😂 | 14:55:42 |
| MangoIV | \infty Gb of ram | 14:56:02 |
| alexfmpe | Hmm yeah you kinda want reflex-frp's binary cache to avoid recompiling the world | 14:56:44 |
| alexfmpe | At least until more stuff gets upstreamed | 14:57:00 |
| MangoIV | I mean you probably never want to upstream the fexpose all unfoldings stuff | 14:57:40 |
| alexfmpe | I'm not sure how much RAM requirement there is, but ghcjs linking tends to already require 16GB | 14:57:55 |
| MangoIV | I use it myself on some deps and it really makes things go much slower. | 14:58:03 |
| alexfmpe | In reply to @mangoiv.:matrix.org
I mean you probably never want to upstream the fexpose all unfoldings stuff Correct, but shouldn't need to recompile ghc for that | 14:58:22 |
| MangoIV | I mean recompiling GHC once or twice, who cares 🙃😅 | 14:58:53 |
| MangoIV | Although 16 GB of ram for linking GHCJS is absolutely nutz | 14:59:10 |
| alexfmpe | Recompiling per bump of nixpkgs-obtained-ghc | 14:59:36 |
| alexfmpe | If you bump nixpkgs and there's a minor version update or some flag changed here we go again | 15:00:00 |
| alexfmpe | In practice everyone just gets this stuff from reflex binary cache anyway | 15:00:20 |
| MangoIV | Have you tried if ca changes speed? | 15:00:34 |
| alexfmpe | ca? | 15:00:51 |
| MangoIV | ca-derivations | 15:00:58 |
| alexfmpe | Ah CA derivs | 15:00:59 |
| alexfmpe | Probably does | 15:01:14 |
| alexfmpe | I dunno if it's been tried | 15:01:32 |
| MangoIV | Inb4 it’s slower:O | 15:01:34 |
| MangoIV | * | 15:01:39 |
| alexfmpe | Current priority is getting on new js backend | 15:01:44 |
| MangoIV | In reply to @alexfmpe:matrix.org
I dunno if it's been tried Would be interested | 15:01:48 |
