Newest at the top
| 2026-01-23 13:56:30 +0100 | <tomsmeding> | I recommended atomicModifyIORef' more because it does what it does well, and doesn't suggest it can do any more than it does :p |
| 2026-01-23 13:56:24 +0100 | <merijn> | once you're planning to update every N milliseconds, that's when I'd consider thinking about performance implications |
| 2026-01-23 13:55:43 +0100 | <merijn> | if it's sub-second then it *might* matter |
| 2026-01-23 13:55:31 +0100 | <tomsmeding> | ^ |
| 2026-01-23 13:55:25 +0100 | <merijn> | If your update frequencies is measures in "once every few seconds" (or less frequent) the performance difference between any of the solutions is essentially irrelevant |
| 2026-01-23 13:55:13 +0100 | <tomsmeding> | merijn: as I said: if you only ever need to read, yes, life is easy :p |
| 2026-01-23 13:54:20 +0100 | <merijn> | bwe: tbh, "not very fast" here still means "pretty goddamn fast" |
| 2026-01-23 13:53:51 +0100 | <merijn> | tomsmeding: readMVar is non blocking on full MVars |
| 2026-01-23 13:52:35 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 265 seconds) |
| 2026-01-23 13:47:25 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 264 seconds) |
| 2026-01-23 13:42:00 +0100 | fp | (~Thunderbi@2001:708:150:10::9d7e) fp |
| 2026-01-23 13:39:37 +0100 | danz20169 | (~danza@user/danza) (Quit: got to go) |
| 2026-01-23 13:39:25 +0100 | fp | (~Thunderbi@2001:708:150:10::9d7e) (Ping timeout: 244 seconds) |
| 2026-01-23 13:38:31 +0100 | DetourNe- | DetourNetworkUK |
| 2026-01-23 13:38:11 +0100 | <bwe> | tomsmeding: ok, thanks. |
| 2026-01-23 13:36:47 +0100 | DetourNetworkUK | (~DetourNet@user/DetourNetworkUK) (Read error: Connection reset by peer) |
| 2026-01-23 13:36:14 +0100 | DetourNe- | (~DetourNet@user/DetourNetworkUK) DetourNetworkUK |
| 2026-01-23 13:31:53 +0100 | <tomsmeding> | bwe: it kind of sounds like atomicModifyIORef' is good enough; if it isn't, come back |
| 2026-01-23 13:31:31 +0100 | <bwe> | tomsmeding: I simply need to update a state from db. Effectively swapping the old data for the new data. I am not sure how can I tell right now whether the type of atomicModifyIORef' fits my use case, though. |
| 2026-01-23 13:31:20 +0100 | <tomsmeding> | (you can get correct + fast + convenient if you never need to communicate between threads! Read-only shared data works very well ;p) |
| 2026-01-23 13:28:28 +0100 | <tomsmeding> | TVar is convenient and correct across the board (programming with STM is great!), but depending on your application's behaviour it may not be very fast |
| 2026-01-23 13:27:49 +0100 | <tomsmeding> | IORefs are plenty convenient if all you need is atomicModifyIORef', but they are rather limited otherwise |
| 2026-01-23 13:27:31 +0100 | <tomsmeding> | bwe: it's more how you use them, although neither MVar nor TVar are particularly fast (STM is just the framework around TVar so not a separate thing) |
| 2026-01-23 13:26:38 +0100 | <bwe> | tomsmeding: how would we categorize MVar, TVar, STM, IORef into two out of three of: correct, fast, convenient? |
| 2026-01-23 13:26:37 +0100 | <tomsmeding> | bwe: if the type of atomicModifyIORef' (mind the ') is good enough for you, it's almost guaranteed to be the fastest option |
| 2026-01-23 13:26:18 +0100 | xff0x | (~xff0x@2405:6580:b080:900:3b58:3b23:6c7:a174) |
| 2026-01-23 13:26:02 +0100 | <bwe> | Axman6, mauke: that's exactly what I want to do, I know when I've got new data and only then want to update the IORef / MVar. -- So if I only want to swap something out, I'd be fine with an IORef? |
| 2026-01-23 13:25:28 +0100 | hakutaku | (~textual@chen.yukari.eu.org) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2026-01-23 13:25:13 +0100 | <tomsmeding> | merijn: what do you mean? |
| 2026-01-23 13:20:35 +0100 | <merijn> | tomsmeding: MVar doesn't have to ever lock and queue if you don't want to, though |
| 2026-01-23 13:18:10 +0100 | <merijn> | int-e: Bad STM design can easily cause that |
| 2026-01-23 13:17:59 +0100 | <merijn> | int-e: Almost surely |
| 2026-01-23 13:10:54 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) (Quit: Client closed) |
| 2026-01-23 13:10:54 +0100 | Googulator25 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:05:33 +0100 | comonad | (~comonad@p200300d02722ae00dce4ce9451b59974.dip0.t-ipconnect.de) (Ping timeout: 260 seconds) |
| 2026-01-23 13:03:09 +0100 | <tomsmeding> | (you may be thinking of ForeignPtr, which does implement Ord) |
| 2026-01-23 13:01:37 +0100 | Googulator23 | (~Googulato@team.broadbit.hu) |
| 2026-01-23 13:00:51 +0100 | <tomsmeding> | Axman6: MVar doesn't implement Ord, only Eq |
| 2026-01-23 12:57:54 +0100 | <tomsmeding> | int-e: I'm not aware of any, I'm an academic |
| 2026-01-23 12:57:29 +0100 | fp1 | fp |
| 2026-01-23 12:57:29 +0100 | fp | (~Thunderbi@2001:708:20:1406::10c5) (Ping timeout: 265 seconds) |
| 2026-01-23 12:57:27 +0100 | <ncf> | Leary: i didn't mean to encapsulate general recursion tbh, only to point out that the clarity of expressing things in terms of (co)algebras needn't come at the price of general recursion |
| 2026-01-23 12:57:22 +0100 | <tomsmeding> | concurrent programming: correct, fast, convenient; pick 2 |
| 2026-01-23 12:57:16 +0100 | <int-e> | Do we have any canonical STM horror story (along the lines of "it worked great until we ran it in production with 50 simultaneous threads and then it spent 90% of its time retrying STM transactions"?) |
| 2026-01-23 12:56:51 +0100 | fp1 | (~Thunderbi@2001:708:150:10::9d7e) fp |
| 2026-01-23 12:56:28 +0100 | <tomsmeding> | *as it has similar |
| 2026-01-23 12:56:14 +0100 | <tomsmeding> | and if you are worried about performance implications of using an MVar over an IORef, you should also be worried about STM, as it similar (?) overhead, and also has starvation issues if you have very long and also very short transactions that update the same TVars |
| 2026-01-23 12:53:26 +0100 | <int-e> | You can perhaps criticize the IORef docs for not mentioning STM, but the reason for that is probably historical, and you'll find out about STM when you read the MVar docs. |
| 2026-01-23 12:53:23 +0100 | <tomsmeding> | (if you only ever lock such locks in a particular global order, this problem cannot arise) |
| 2026-01-23 12:53:20 +0100 | merijn | (~merijn@77.242.116.146) merijn |