| 6 Oct 2024 |
|  @sofo:matrix.org left the room. | 15:27:39 |
| 7 Oct 2024 |
 cdepillabout | In reply to @emilazy:matrix.org
many a time I have been on the inside saying "nope, you can't do better than that", only to be blindsided when some person I've never heard of before comes along and does better in ways I would have said would never work 😅 I totally get this. Just the other day I replied to someone on one of my repos saying it wouldn't be technically possible to fix one of the issues they had opened. Only to realize a few minutes later they had already sent a PR fixing the issue I thought couldn't be fixed 🤕 | 06:00:33 |
 emily | this PR clearly does not exist closes | 06:01:35 |
| 8 Oct 2024 |
 eldritchcookie | how do i unmark broken something https://github.com/typedbyte/apecs-effectful/issues/1 | 14:33:29 |
 MangoIV | 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? | 14:41:22 |
| eldritchcookie | 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 | 14:43:24 |
| 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 |
