Logs: liberachat/#haskell
| 2021-07-01 23:40:11 | → | stefan-_ joins (~cri@42dots.de) |
| 2021-07-01 23:40:58 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-07-01 23:44:06 | × | cuz quits (~user@2601:182:cc02:8b0:480:5e00:5c91:f4b2) (Ping timeout: 256 seconds) |
| 2021-07-01 23:44:42 | × | shapr quits (~user@pool-108-28-144-11.washdc.fios.verizon.net) (Ping timeout: 240 seconds) |
| 2021-07-01 23:47:12 | → | bitdex joins (~bitdex@gateway/tor-sasl/bitdex) |
| 2021-07-01 23:57:48 | × | machinedgod quits (~machinedg@24.105.81.50) (Ping timeout: 252 seconds) |
| 2021-07-02 00:02:04 | → | mud joins (~mud@user/kadoban) |
| 2021-07-02 00:03:56 | <c_wraith> | that sounds like a strictness issue |
| 2021-07-02 00:04:18 | → | Feuermagier joins (~Feuermagi@user/feuermagier) |
| 2021-07-02 00:05:45 | <dsal> | Yeah, MT in Haskell does mean you need to actually force computation in the threads you spawn if you want them to be useful. :) |
| 2021-07-02 00:05:56 | <ephemient> | rdrand would be pretty fast but it is broken on a number of configurations |
| 2021-07-02 00:11:53 | <ephemient> | ... or not, looking at intel docs it only provides random values at 100Hz and is shared between cores |
| 2021-07-02 00:12:50 | × | Morrow quits (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) (Ping timeout: 252 seconds) |
| 2021-07-02 00:17:37 | <c_wraith> | rdrand is intended to feed entropy pools like should be behind /dev/urandom |
| 2021-07-02 00:18:11 | <c_wraith> | for which 100Hz is actually pretty good, if there's any entropy in the output of rdrand at all |
| 2021-07-02 00:30:21 | → | takuan joins (~takuan@178-116-218-225.access.telenet.be) |
| 2021-07-02 00:31:46 | × | falafel quits (~falafel@pool-96-255-70-50.washdc.fios.verizon.net) (Ping timeout: 258 seconds) |
| 2021-07-02 00:33:54 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-02 00:34:38 | × | hegstal quits (~hegstal@2a02:c7f:7604:8a00:8d05:aaa6:8a87:6441) (Remote host closed the connection) |
| 2021-07-02 00:37:02 | × | zaquest quits (~notzaques@5.128.210.178) (Remote host closed the connection) |
| 2021-07-02 00:37:33 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Quit: WeeChat 3.2) |
| 2021-07-02 00:38:00 | → | zaquest joins (~notzaques@5.128.210.178) |
| 2021-07-02 00:39:24 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-07-02 00:40:18 | × | shutdown_-h_now quits (~arjan@82-75-187-100.cable.dynamic.v4.ziggo.nl) (Ping timeout: 268 seconds) |
| 2021-07-02 00:43:16 | → | fizbin joins (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) |
| 2021-07-02 00:46:24 | mnrmnaugh | is now known as hflotmnaugh |
| 2021-07-02 00:47:40 | × | fizbin quits (~fizbin@c-73-33-197-160.hsd1.nj.comcast.net) (Ping timeout: 252 seconds) |
| 2021-07-02 00:51:46 | <jackdk> | Hum. I am currently generating my generators before forking (`gens <- replicateM n $ newStdGen >>= newIORef`) and then the main part of the job should be `forConcurrently jobs $ force $ ...`, where `jobs :: [(OtherStuff, IORef StdGen)]` |
| 2021-07-02 00:52:42 | × | takuan quits (~takuan@178-116-218-225.access.telenet.be) (Ping timeout: 240 seconds) |
| 2021-07-02 00:55:36 | → | anandprabhu joins (~anandprab@94.202.243.198) |
| 2021-07-02 00:57:05 | → | shutdown_-h_now joins (~arjan@82-75-187-100.cable.dynamic.v4.ziggo.nl) |
| 2021-07-02 00:58:15 | <jackdk> | (`forConcurrently` is from `unliftio`, but it is still pegging 1/16 cores |
| 2021-07-02 00:58:44 | → | nate1 joins (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) |
| 2021-07-02 01:01:32 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Remote host closed the connection) |
| 2021-07-02 01:04:28 | × | nate1 quits (~nate@108-233-125-227.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 265 seconds) |
| 2021-07-02 01:04:44 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2021-07-02 01:04:58 | × | Erutuon quits (~Erutuon@user/erutuon) (Ping timeout: 268 seconds) |
| 2021-07-02 01:06:29 | → | gaze__ joins (sid387101@id-387101.brockwell.irccloud.com) |
| 2021-07-02 01:06:36 | <davean> | jackdk: dumb question, but you compiled with threading, right? |
| 2021-07-02 01:06:45 | → | Erutuon joins (~Erutuon@user/erutuon) |
| 2021-07-02 01:06:46 | <c_wraith> | jackdk: yes, that's a typical example of getting laziness wrong |
| 2021-07-02 01:06:55 | × | safinaskar quits (~safinaska@109.252.90.89) (Ping timeout: 246 seconds) |
| 2021-07-02 01:07:03 | <c_wraith> | jackdk: force doesn't do what you think it does |
| 2021-07-02 01:07:38 | <jackdk> | davean: `ghc-options: -threaded -rtsopts -with-rtsopts=-N`; c_wraith: I see the same behaviour with/without `force` - what does it actually do? |
| 2021-07-02 01:07:56 | <davean> | jackdk: force makes it so you can't look past force without everything inside being computed (sorta) |
| 2021-07-02 01:08:05 | <davean> | you probably want sometihng like seq more |
| 2021-07-02 01:08:09 | <davean> | or deepseq |
| 2021-07-02 01:08:12 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-02 01:08:12 | <gaze__> | Where does jaspervdj usually hang out/what’s his handle? I’m curious if there’s any way to use his web sockets library over SSL/TLS |
| 2021-07-02 01:08:17 | <c_wraith> | nah, you want evaluate |
| 2021-07-02 01:08:17 | → | cuz joins (~user@2601:182:cc02:8b0:bcb0:835d:1ce3:e86e) |
| 2021-07-02 01:08:21 | <c_wraith> | maybe with or without force |
| 2021-07-02 01:08:44 | <c_wraith> | But they key is that you want something that causes a pure computation to run when an IO action is executed |
| 2021-07-02 01:08:47 | × | learner-monad quits (~ehanneken@user/learner-monad) (Quit: WeeChat 3.2) |
| 2021-07-02 01:08:49 | <c_wraith> | and that's what evaluate does |
| 2021-07-02 01:08:57 | <davean> | evaluate is limited to IO |
| 2021-07-02 01:09:09 | <davean> | unlike seq for example |
| 2021-07-02 01:09:40 | <c_wraith> | So when calling forConcurrently, evaluate is the right choice |
| 2021-07-02 01:10:15 | <c_wraith> | It's not polymorphic in that parameter. It's always IO |
| 2021-07-02 01:10:16 | × | cheater quits (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-02 01:10:33 | → | cheater joins (~Username@user/cheater) |
| 2021-07-02 01:10:38 | × | eggplantade quits (~Eggplanta@2600:1700:bef1:5e10:dc49:b28b:5485:3e7e) (Remote host closed the connection) |
| 2021-07-02 01:11:13 | × | albet70 quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2021-07-02 01:11:46 | <davean> | c_wraith: why would you chose evaluate over seq here? |
| 2021-07-02 01:12:21 | → | albet70 joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2021-07-02 01:12:28 | <c_wraith> | because its semantics are an exact match for what's desired: when the IO computation is executed, evaluate the value |
| 2021-07-02 01:13:31 | <c_wraith> | could you use seq? sure, the docs for evaluate say how to implement it in terms of seq. But why not use the function that already exists and does exactly what you want, instead of reimplementing it? |
| 2021-07-02 01:13:38 | × | waleee quits (~waleee@2001:9b0:216:8200:d457:9189:7843:1dbd) (Ping timeout: 256 seconds) |
| 2021-07-02 01:14:27 | <jackdk> | force x = deepseq x x; force's haddock specifically calls out `evaluate $ force $ ...` as a way to force deep evaluation relative to other IO |
| 2021-07-02 01:14:36 | → | Cajun joins (~Cajun@ip98-163-211-112.no.no.cox.net) |
| 2021-07-02 01:15:47 | <jackdk> | so I have `jobs :: [(RVar x, IORef StdGen)]` and I try `forConcurrently jobs $ evaluate . force <=< uncurry runRVar`, but I still seem to only peg one core. Is there something else obvious that I'm likely missing? |
| 2021-07-02 01:16:17 | <c_wraith> | well, running with +RTS -N |
| 2021-07-02 01:16:50 | <jackdk> | Doesn't `-with-rtsopts=-N` give that? |
| 2021-07-02 01:17:02 | × | xff0x quits (~xff0x@2001:1a81:5237:1000:bd6:e736:a4f:c278) (Ping timeout: 256 seconds) |
| 2021-07-02 01:17:19 | <jackdk> | Currently running with `+RTS -H10G -N -p`, anyway |
| 2021-07-02 01:18:11 | <c_wraith> | the other potential way for it to all end up on one core is if there's a data dependency on the inputs that makes evaluating them linear |
| 2021-07-02 01:18:33 | <Cajun> | does running with `+RTS -s` mention using -N[your number of cores]? |
| 2021-07-02 01:18:41 | → | xff0x joins (~xff0x@2001:1a81:5272:cb00:9b5b:dd13:e926:61a1) |
| 2021-07-02 01:19:03 | <Cajun> | it should, cant see any reason why it wouldnt |
| 2021-07-02 01:19:21 | × | anandprabhu quits (~anandprab@94.202.243.198) (Quit: Leaving) |
| 2021-07-02 01:20:33 | <c_wraith> | like... if runRVar is fast but generating each RVar depends on the previous one, you can end up in a situation where waiting for the input to become available blocks all the threads |
| 2021-07-02 01:21:22 | → | eggplantade joins (~Eggplanta@2600:1700:bef1:5e10:5bf:4bd7:7b8b:fdcf) |
| 2021-07-02 01:21:49 | <c_wraith> | Or heck. If runRVar is fast and there's no data dependency, you might just be blocking in the repeated calls to newStdGen |
| 2021-07-02 01:21:55 | <c_wraith> | I don't know if it's actually fast |
| 2021-07-02 01:22:29 | <c_wraith> | (ie, make sure you're actually measuring the concurrent portion of the program) |
| 2021-07-02 01:22:44 | <jackdk> | c_wraith: I see what you're saying. I've flinched away from that hypothesis because `let jobs = zip (repeat (calculateFoo :: RVar x)) gens` and because it requires more thinking |
| 2021-07-02 01:23:38 | <c_wraith> | huh. you're repeating the same RVar? |
| 2021-07-02 01:23:49 | <c_wraith> | well that's *definitely* a data dependency between them :) |
| 2021-07-02 01:24:10 | <jackdk> | yes, I suppose it is >_< |
| 2021-07-02 01:24:36 | <c_wraith> | If evaluating calculateFoo takes a significant chunk of time, every thread but one will be blocked waiting for the lazy evaluation to finish |
| 2021-07-02 01:25:04 | <jackdk> | yeah, I see what you're saying. |
| 2021-07-02 01:25:32 | <jackdk> | and then when that's finally done, going through and rolling the dice on the actual random samples is reasonably quick but I've been hammering the wrong thing |
| 2021-07-02 01:26:02 | <c_wraith> | that's very easy to have happen with complex conditional probability expressions |
| 2021-07-02 01:26:40 | × | notzmv quits (~zmv@user/notzmv) (Ping timeout: 256 seconds) |
| 2021-07-02 01:28:40 | → | Morrow joins (~MorrowM_@bzq-110-168-31-106.red.bezeqint.net) |
| 2021-07-02 01:34:41 | <koz> | What's the standard way of generating a fresh name in the Q monad? |
| 2021-07-02 01:35:16 | → | norias joins (~jaredm@c-98-219-195-163.hsd1.pa.comcast.net) |
| 2021-07-02 01:36:13 | <geekosaur> | https://downloads.haskell.org/ghc/latest/docs/html/libraries/template-haskell-2.17.0.0/Language-Haskell-TH.html#v:newName ? |
| 2021-07-02 01:36:33 | <koz> | geekosaur: Thanks! |
| 2021-07-02 01:36:44 | <koz> | Why does it take a String then? |
All times are in UTC.