Newest at the top
| 2025-03-12 17:01:14 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 17:01:04 +0100 | <ski> | mm |
| 2025-03-12 16:59:44 +0100 | <c_wraith> | Depending on what f does, it might make sense to do any number of different things in parallel. Or none. |
| 2025-03-12 16:58:38 +0100 | <c_wraith> | all it does is hand control back to f immediately, with all other behavior up to f. |
| 2025-03-12 16:56:56 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 16:56:50 +0100 | <c_wraith> | foldr is too low-level to really parallelize in any meaningful way. |
| 2025-03-12 16:55:59 +0100 | <ski> | s/odd/off/ |
| 2025-03-12 16:55:45 +0100 | <ski> | so, with `par cont a', you're sparking odd the recursive calls in `foldr'. each one performed would force its `a'. with `par a cont', you'd instead be sparking off the `a's all directly |
| 2025-03-12 16:55:30 +0100 | <c_wraith> | It's all *very* dependent on context. the whole way par works only is effective because of laziness. |
| 2025-03-12 16:54:37 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-12 16:53:43 +0100 | <Inst> | it's weird, because the par cont a, #1, generates more sparks, #2, fizzles more sparts, and #3, is faster |
| 2025-03-12 16:53:40 +0100 | <ski> | (well, i suppose it will be forced to WHNF. but not sparked) |
| 2025-03-12 16:53:01 +0100 | <ski> | `pseq (par cont a) (..)' seems a bit useless, the `a' will get ignored by the `pseq' ? |
| 2025-03-12 16:51:56 +0100 | <Inst> | i have two dummy cases under Data.Time benchmarking, the first is par a b, the second is par b a |
| 2025-03-12 16:50:42 +0100 | <c_wraith> | `par a b' creates a spark to evaluate a and returns b. |
| 2025-03-12 16:49:54 +0100 | <Inst> | par a cont should be generating a ton of sparks, but the cont can't return until all the sparks are generated, right? |
| 2025-03-12 16:49:40 +0100 | <Inst> | what is the difference, though? |
| 2025-03-12 16:47:50 +0100 | notdabs | (~Owner@2600:1700:69cf:9000:91e8:307c:455b:5f65) |
| 2025-03-12 16:46:46 +0100 | <Inst> | thanks |
| 2025-03-12 16:46:29 +0100 | <c_wraith> | that's going to be highly workload-dependent. There's no generally correct answer. |
| 2025-03-12 16:43:46 +0100 | <Inst> | \a cont -> par cont a `pseq` ...; is it more correct to have par a cont or par cont a? |
| 2025-03-12 16:42:46 +0100 | <Inst> | a foldr |
| 2025-03-12 16:42:31 +0100 | <Inst> | when you're parallelizing a fold |
| 2025-03-12 16:42:01 +0100 | Guest99 | (~Guest47@2600:387:f:7e18::6) (Quit: Client closed) |
| 2025-03-12 16:40:04 +0100 | gmg | (~user@user/gehmehgeh) (Quit: Leaving) |
| 2025-03-12 16:37:39 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-03-12 16:37:24 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 246 seconds) |
| 2025-03-12 16:37:04 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 244 seconds) |
| 2025-03-12 16:33:35 +0100 | T0NN | (~T0NN@193.42.62.209) (Quit: Client closed) |
| 2025-03-12 16:33:05 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 16:32:06 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-03-12 16:24:41 +0100 | Guest99 | (~Guest47@2600:387:f:7e18::6) |
| 2025-03-12 16:22:47 +0100 | pavonia | (~user@user/siracusa) (Quit: Bye!) |
| 2025-03-12 16:14:08 +0100 | infinity0 | (~infinity0@pwned.gg) (Ping timeout: 245 seconds) |
| 2025-03-12 16:07:05 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2025-03-12 16:00:39 +0100 | <[exa]> | tomsmeding: iiiiiiiinteresting thanks! |
| 2025-03-12 15:54:03 +0100 | T0NN | (~T0NN@193.42.62.209) |
| 2025-03-12 15:50:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
| 2025-03-12 15:47:40 +0100 | lottaquestions | (~nick@2607:fa49:5040:b100:5b52:ac7b:b1b7:f59f) lottaquestions |
| 2025-03-12 15:45:39 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 15:34:53 +0100 | TheCoffeMaker | (~TheCoffeM@user/thecoffemaker) TheCoffeMaker |
| 2025-03-12 15:31:11 +0100 | <carbolymer> | but in my quick test `sortBy (\_ _ -> GT)` results in just reversed list |
| 2025-03-12 15:30:39 +0100 | <carbolymer> | I guess it's not true for all comparison functions in sortBy |
| 2025-03-12 15:30:39 +0100 | <carbolymer> | >otherwise, e. g., for _ _ -> GT, the ordered list simply does not exist |
| 2025-03-12 15:29:21 +0100 | <tomsmeding> | it would be nice if this was also mentioned in 'sortBy', but I think we can extrapolate |
| 2025-03-12 15:28:59 +0100 | <tomsmeding> | carbolymer: from the haddocks of 'sort': The sort function implements a stable sorting algorithm. |
| 2025-03-12 15:28:57 +0100 | <carbolymer> | that was my intuition, thanks tomsmeding for confirming ;] |
| 2025-03-12 15:28:10 +0100 | T0NN | (~T0NN@104.28.196.52) (Client Quit) |
| 2025-03-12 15:27:39 +0100 | <tomsmeding> | for longer lists, it splits the list into runs of alternatingly ascending/descending elements; in your case there's just one run, so the algorithm terminates there |
| 2025-03-12 15:27:14 +0100 | <tomsmeding> | looking at the implementation, for lists of length <=4 it has a manually written decision tree that, if I am to believe the comments, should only reorder if a preceding element is strictly greater than a following element |