Newest at the top
| 2025-03-09 20:30:15 +0100 | hattckory | (~hattckory@bras-base-toroon4524w-grc-48-184-145-138-167.dsl.bell.ca) |
| 2025-03-09 20:27:43 +0100 | Smiles | (uid551636@id-551636.lymington.irccloud.com) (Quit: Connection closed for inactivity) |
| 2025-03-09 20:24:11 +0100 | <int-e> | real-time profiling data and just in time compilation make this more realistic |
| 2025-03-09 20:23:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-09 20:23:49 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
| 2025-03-09 20:23:24 +0100 | <EvanR> | sun with java claimed to have done it |
| 2025-03-09 20:23:13 +0100 | int-e | shrugs |
| 2025-03-09 20:23:11 +0100 | <EvanR> | "just parallel my code" has been a promise for 30 years now |
| 2025-03-09 20:23:06 +0100 | <int-e> | that's not generic |
| 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 |