Newest at the top
| 2025-03-09 20:22:05 +0100 | <Inst> | i mean, is this an actual problem? I was asking that, i.e, when I was trying parallelism for a brute force attempt at calculating blackjack's split EV, I was told, just benchmark and see what happens |
| 2025-03-09 20:21:10 +0100 | <int-e> | And keeping subtasks coarse enough, which makes it hard to do this generically. Oh well. |
| 2025-03-09 20:20:16 +0100 | <EvanR> | if it doesn't, or if it hurts performance, then it's not good |
| 2025-03-09 20:20:15 +0100 | <int-e> | (personally I'd worry about splitting tasks evenly enough) |
| 2025-03-09 20:20:09 +0100 | <EvanR> | one issue with parallel code is delivering on an increase in performance |
| 2025-03-09 20:19:39 +0100 | <EvanR> | which I seriously doubt |
| 2025-03-09 20:19:33 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-09 20:19:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-09 20:19:27 +0100 | <EvanR> | thinking it would be the fastest possible |
| 2025-03-09 20:19:25 +0100 | <int-e> | EvanR: 20; the lone 2^20 was correcting what 1048576 is |
| 2025-03-09 20:19:16 +0100 | <EvanR> | 19 would imply you're doing x*y in its own parallel computation |
| 2025-03-09 20:18:48 +0100 | <EvanR> | so how many levels of splitting |
| 2025-03-09 20:17:07 +0100 | <Inst> | i mean if there's a million element list, it's 2^20, would be less |
| 2025-03-09 20:16:25 +0100 | <EvanR> | 2^2^20 elements |
| 2025-03-09 20:16:17 +0100 | <EvanR> | 2^20 levels of splitting would be a very large list |
| 2025-03-09 20:15:37 +0100 | <EvanR> | it might not work if you try to mconcat over that many chunks at a time |
| 2025-03-09 20:15:22 +0100 | <[exa]> | that's probably gonna differ a lot from machine to machine no? |
| 2025-03-09 20:15:13 +0100 | <EvanR> | since you only have like double digit cores |
| 2025-03-09 20:14:46 +0100 | <Inst> | 2^20 |
| 2025-03-09 20:14:42 +0100 | <Inst> | ehhh, probably closer to 20 or so, if 1048576 is 2 |
| 2025-03-09 20:14:14 +0100 | <Inst> | right now, i'm thinking hundreds |
| 2025-03-09 20:13:29 +0100 | fmira | (~user@user/fmira) fmira |
| 2025-03-09 20:13:16 +0100 | <EvanR> | how many levels of splitting |
| 2025-03-09 20:13:02 +0100 | fmira | (~user@user/fmira) (Remote host closed the connection) |
| 2025-03-09 20:12:34 +0100 | <Inst> | at least for the list variant, subdivide into the list into smaller elements, toss rpar (iirc) on the smaller elements, get intermediate results, then use another split and merge until i end up with a list of 1 element then return that element via rseq |
| 2025-03-09 20:12:29 +0100 | raym | (~ray@user/raym) raym |
| 2025-03-09 20:12:09 +0100 | raym | (~ray@user/raym) (Ping timeout: 244 seconds) |
| 2025-03-09 20:10:35 +0100 | <EvanR> | exactly |
| 2025-03-09 20:10:20 +0100 | <EvanR> | how? |
| 2025-03-09 20:08:57 +0100 | <Inst> | just make a dumb foldPar and foldMapPar function |
| 2025-03-09 20:08:38 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f122c9d6c56f23204e7.dip0.t-ipconnect.de) |
| 2025-03-09 20:08:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-09 20:06:15 +0100 | <[exa]> | Inst: maybe check out https://hackage.haskell.org/package/parallel-3.2.2.0/docs/Control-Parallel-Strategies.html |
| 2025-03-09 20:05:22 +0100 | <EvanR> | what are you actually trying to do again |
| 2025-03-09 20:04:56 +0100 | <Inst> | but that implies it'll cache, and getNumCapabilities' bind value can change |
| 2025-03-09 20:04:32 +0100 | <Inst> | at the very least, i can see a problem, I want to unsafePerformIO getNumCapabilities |
| 2025-03-09 20:04:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-09 20:02:25 +0100 | <Inst> | is the reason no one's done this already because it relies too much on the specifics of the operation and is dangerous to generalize? |
| 2025-03-09 20:00:42 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2025-03-09 20:00:02 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2025-03-09 19:58:59 +0100 | <EvanR> | what's the biggest number n might be, realistically |
| 2025-03-09 19:58:23 +0100 | <Inst> | for length |
| 2025-03-09 19:58:20 +0100 | <Inst> | since lists are O(n) |
| 2025-03-09 19:58:09 +0100 | <Inst> | it's not, tbh |
| 2025-03-09 19:54:25 +0100 | <[exa]> | c_wraith: oh whew okay, cool |
| 2025-03-09 19:54:17 +0100 | <[exa]> | Inst: yeah depending on what you aim to do there I guess it might be super straightforward |
| 2025-03-09 19:53:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-09 19:52:40 +0100 | <c_wraith> | [exa]: if you're willing to maintain them, you can use environment files. https://ghc.gitlab.haskell.org/ghc/doc/users_guide/packages.html#package-environments |
| 2025-03-09 19:51:31 +0100 | down200 | (~down200@shell.lug.mtu.edu) down200 |
| 2025-03-09 19:49:14 +0100 | <Inst> | oh. lol |