Newest at the top
| 2024-11-14 18:53:20 +0100 | <tomsmeding> | then change the unsafeThaw to thaw, because with the unsafeThaw + unsafeFreeze you're still in unsafe world |
| 2024-11-14 18:53:01 +0100 | <tomsmeding> | bailsman: try putting the whole mutable part in ST, so that you only have one unsafeThaw and one unsafeFreeze; presumably that should still be fast |
| 2024-11-14 18:52:12 +0100 | <tomsmeding> | I would still not do this |
| 2024-11-14 18:51:51 +0100 | <tomsmeding> | yes IO sequences, so that's fine |
| 2024-11-14 18:51:50 +0100 | <geekosaur> | evaluate has to be in IO |
| 2024-11-14 18:51:47 +0100 | <tomsmeding> | (evaluate runs in IO) |
| 2024-11-14 18:51:42 +0100 | <bailsman> | sure |
| 2024-11-14 18:51:35 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 255 seconds) |
| 2024-11-14 18:51:32 +0100 | <tomsmeding> | in IO? |
| 2024-11-14 18:51:29 +0100 | <bailsman> | evaluate $ force |
| 2024-11-14 18:51:26 +0100 | <tomsmeding> | (again depending on the precise code) |
| 2024-11-14 18:51:15 +0100 | <tomsmeding> | GHC may just decide that "fully evaluating" the values can also happen a bit later |
| 2024-11-14 18:50:58 +0100 | <tomsmeding> | bailsman: yes, depending on how you ensure that it is fully evaluated |
| 2024-11-14 18:47:10 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-14 18:46:27 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-11-14 18:44:03 +0100 | ft | (~ft@p4fc2a216.dip0.t-ipconnect.de) ft |
| 2024-11-14 18:39:30 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2024-11-14 18:38:56 +0100 | housemate | (~housemate@146.70.66.228) (Quit: "I saw it in a tiktok video and thought that it was the most smartest answer ever." ~ AnonOps Radio [some time some place] | I AM THE DERIVATIVE I AM GOING TANGENT TO THE CURVE!) |
| 2024-11-14 18:37:43 +0100 | <bailsman> | Replacing the code with the safe versions of freeze and thaw makes it 3x slower |
| 2024-11-14 18:37:26 +0100 | <geekosaur> | ST will ensure that for you |
| 2024-11-14 18:36:47 +0100 | <bailsman> | I actually really like the performance now - I'd like to fully understand the dragons on my path. |
| 2024-11-14 18:35:42 +0100 | <bailsman> | Even if I make sure that the code with mutable reference has fully evaluated before any code with immutable references tries to read? |
| 2024-11-14 18:34:51 +0100 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2024-11-14 18:34:19 +0100 | <tomsmeding> | work in ST and keep the thing mutable while you're mutating it |
| 2024-11-14 18:33:54 +0100 | <tomsmeding> | please don't do this :p |
| 2024-11-14 18:33:35 +0100 | <tomsmeding> | GHC assumes that immutable values don't change and sometimes optimises quite aggressively based on that assumption |
| 2024-11-14 18:33:32 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-14 18:33:13 +0100 | <tomsmeding> | bailsman: yes, mutating an immutable vector is sure to produce very strange issues |
| 2024-11-14 18:32:55 +0100 | <bailsman> | I should probably find a way to keep it mutable permanently rather than thawing and freezing |
| 2024-11-14 18:31:59 +0100 | <bailsman> | more readable on multiple lines |
| 2024-11-14 18:31:34 +0100 | <bailsman> | https://paste.tomsmeding.com/yaTzqQA3 |
| 2024-11-14 18:27:04 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) alexherbo2 |
| 2024-11-14 18:26:43 +0100 | alexherbo2 | (~alexherbo@2a02-8440-3313-668b-a9ec-921f-0511-ee3f.rev.sfr.net) (Remote host closed the connection) |
| 2024-11-14 18:26:10 +0100 | <bailsman> | updateValue is pure. This is the 'inplace map': `runST $ do; mv <- VU.unsafeThaw v; VUM.iforM_ mv $ \i s -> VUM.write mv i $! updateValue s; VU.unsafeFreeze mv` |
| 2024-11-14 18:25:10 +0100 | <tomsmeding> | bailsman: "please tell me" if you show the code, perhaps we can :) |
| 2024-11-14 18:23:30 +0100 | <bailsman> | Please tell me it's not going to segfault on me if I move forward with this in more complex examples |
| 2024-11-14 18:22:15 +0100 | <bailsman> | why did nobody tell me :P |
| 2024-11-14 18:22:11 +0100 | <bailsman> | Wait, so apparently I can derive the unboxed instances with minimal boilerplate (as tuples), and the pure world doesn't even need to know or care that I did that all. I can write it idiomatically. And it's now as fast as C |
| 2024-11-14 18:21:58 +0100 | emfrom | (~emfrom@37.168.28.138) (Remote host closed the connection) |
| 2024-11-14 18:13:09 +0100 | Inst | (~Inst@user/Inst) (Ping timeout: 276 seconds) |
| 2024-11-14 18:12:03 +0100 | emfrom | (~emfrom@37.168.28.138) |
| 2024-11-14 18:11:25 +0100 | Inst_ | (~Inst@user/Inst) Inst |
| 2024-11-14 18:10:57 +0100 | mantraofpie | (~mantraofp@user/mantraofpie) mantraofpie |
| 2024-11-14 18:10:17 +0100 | mantraofpie | (~mantraofp@user/mantraofpie) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2024-11-14 18:05:45 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 252 seconds) |
| 2024-11-14 18:03:50 +0100 | mantraofpie_ | mantraofpie |
| 2024-11-14 17:58:53 +0100 | housemate | (~housemate@146.70.66.228) housemate |
| 2024-11-14 17:58:27 +0100 | aljazmc | (~aljazmc@user/aljazmc) aljazmc |
| 2024-11-14 17:58:01 +0100 | aljazmc | (~aljazmc@user/aljazmc) (Remote host closed the connection) |
| 2024-11-14 17:46:08 +0100 | Digit | (~user@user/digit) Digit |