Newest at the top
| 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 |
| 2026-07-02 16:38:11 +0000 | <tomsmeding> | " |
| 2026-07-02 16:38:09 +0000 | <tomsmeding> | otherwise I'm not sure how it can "return an empty list millions of times |
| 2026-07-02 16:38:02 +0000 | <absentia> | i wait until the TQueue changes |
| 2026-07-02 16:37:56 +0000 | <absentia> | and if it's empty, i don't do anything |
| 2026-07-02 16:37:52 +0000 | <tomsmeding> | but anyway, flushTQueue runs in STM; what are you doing with its result afterwards? |
| 2026-07-02 16:37:50 +0000 | <EvanR> | that's normally what STM retry does, block until something changes |
| 2026-07-02 16:37:46 +0000 | <absentia> | right |
| 2026-07-02 16:37:41 +0000 | <tomsmeding> | if I want the contents of the queue as a list, and the queue is empty, I want an empty list |
| 2026-07-02 16:37:25 +0000 | <tomsmeding> | but why on earth would you do that |