Newest at the top
| 2026-07-02 17:48:01 +0000 | target_i | (~target_i@user/target-i/x-6023099) target_i |
| 2026-07-02 17:47:48 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-07-02 17:45:34 +0000 | takuan | (~takuan@d8D86B996.access.telenet.be) (Ping timeout: 256 seconds) |
| 2026-07-02 17:41:00 +0000 | emilym | (~Thunderbi@user/emilym) (Ping timeout: 245 seconds) |
| 2026-07-02 17:30:26 +0000 | chymera | (~chymera@ns1000526.ip-51-81-46.us) chymera |
| 2026-07-02 17:14:33 +0000 | dolio | (~dolio@130.44.140.168) dolio |
| 2026-07-02 17:12:51 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) |
| 2026-07-02 17:11:32 +0000 | dolio | (~dolio@130.44.140.168) (Ping timeout: 268 seconds) |
| 2026-07-02 17:10:14 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-07-02 16:59:09 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) |
| 2026-07-02 16:56:02 +0000 | <tomsmeding> | so I get your frustration :p |
| 2026-07-02 16:55:45 +0000 | <tomsmeding> | and profiling is sometimes more difficult than in other languages for laziness and cost attribution reasons |
| 2026-07-02 16:55:15 +0000 | <tomsmeding> | absentia: I fully admit that even though performance can be untransparent in all languages, it's especially likely to be so in haskell |
| 2026-07-02 16:53:26 +0000 | <absentia> | if i had profiled first, as i knew i should have, i wouldn't have gone on some wild goose chases.. |
| 2026-07-02 16:53:02 +0000 | <absentia> | this was quite the journey |
| 2026-07-02 16:52:59 +0000 | <absentia> | yes well thank you for humoring my inane rants |
| 2026-07-02 16:52:47 +0000 | emilym | (~Thunderbi@user/emilym) emilym |
| 2026-07-02 16:52:32 +0000 | emilym | (~Thunderbi@user/emilym) (Remote host closed the connection) |
| 2026-07-02 16:51:23 +0000 | <int-e> | Hmm, maybe just having a tight allocating loop that adds heap pressure is enough? Or maybe handling empty lists still comes with a cost. |
| 2026-07-02 16:46:41 +0000 | tromp | (~textual@2001:1c00:340e:2700:39b7:4dd7:ef94:da89) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2026-07-02 16:46:18 +0000 | danza | (~danza@user/danza) (Remote host closed the connection) |
| 2026-07-02 16:44:27 +0000 | <tomsmeding> | (a mutex guarantees forward progress if the thread holding the mutex is not descheduled from the processor; STM may get arbitrary levels of contention in the worst case, where there is no forward progress even if all relevant threads are scheduled) |
| 2026-07-02 16:43:33 +0000 | <tomsmeding> | it's _the_ primary failure more of STM as a concurrency synchronisation/communication system |
| 2026-07-02 16:43:03 +0000 | <tomsmeding> | still, the only thing I can imagine here is STM contention, so that's a very interesting bug you found :) |
| 2026-07-02 16:42:31 +0000 | <tomsmeding> | succeeding on the second attempt is not too bad |
| 2026-07-02 16:42:13 +0000 | <tomsmeding> | so I guess this busy loop can make every _second_ write fail with high probability, but then when that second write restarts, it should likely succeed |
| 2026-07-02 16:41:33 +0000 | <tomsmeding> | s/contest with anything/contest anything/ |
| 2026-07-02 16:41:26 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Read error: Connection reset by peer) |
| 2026-07-02 16:41:24 +0000 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-07-02 16:41:20 +0000 | <tomsmeding> | but it will only contest anything if it read something non-empty, because otherwise it'll only readTVar, and readTVar doesn't contest with anything |
| 2026-07-02 16:40:46 +0000 | <tomsmeding> | running an STM transaction in a busy loop can tank performance if it contests other transactions and thus results in many more failures across the application than there would otherwise be |
| 2026-07-02 16:39:56 +0000 | <tomsmeding> | int-e++ |
| 2026-07-02 16:39:48 +0000 | <int-e> | absentia: congrats on finding that, thanks for sharing |
| 2026-07-02 16:39:47 +0000 | <tomsmeding> | well yes that busy-loops, but I'm not sure how that would tank performance |
| 2026-07-02 16:39:30 +0000 | <absentia> | basically |
| 2026-07-02 16:39:28 +0000 | <absentia> | yeah |
| 2026-07-02 16:39:24 +0000 | <tomsmeding> | forever $ do l <- atomically (flushTQueue q); handle l |
| 2026-07-02 16:39:01 +0000 | <tomsmeding> | _ah_ |
| 2026-07-02 16:38:59 +0000 | <absentia> | then again |
| 2026-07-02 16:38:57 +0000 | <absentia> | then check again |
| 2026-07-02 16:38:54 +0000 | <absentia> | previously it would just flush the queue and iterate over a possibly empty collection |
| 2026-07-02 16:38:50 +0000 | <tomsmeding> | what were you doing before |
| 2026-07-02 16:38:46 +0000 | <absentia> | exactly |
| 2026-07-02 16:38:43 +0000 | <tomsmeding> | `do l <- flushTQueue q; when (null l) retry; return l` |
| 2026-07-02 16:38:37 +0000 | <absentia> | that's what i'm doing now |
| 2026-07-02 16:38:31 +0000 | <tomsmeding> | but shouldn't that just work fine |
| 2026-07-02 16:38:24 +0000 | <tomsmeding> | right |
| 2026-07-02 16:38:22 +0000 | <absentia> | tomsmeding: with `retry` |
| 2026-07-02 16:38:14 +0000 | <tomsmeding> | how do you wait? |
| 2026-07-02 16:38:14 +0000 | <absentia> | instead of checking again immediately, irrespective of whether or not something has changed |