Newest at the top
| 2024-11-12 20:29:32 +0100 | <int-e> | avoid success at all cost? |
| 2024-11-12 20:29:13 +0100 | <EvanR> | it's just not that kind of language |
| 2024-11-12 20:29:04 +0100 | <EvanR> | I've never really had any success violating haskell's semantics |
| 2024-11-12 20:28:42 +0100 | <EvanR> | exactly |
| 2024-11-12 20:28:27 +0100 | <bailsman> | I don't though. |
| 2024-11-12 20:28:04 +0100 | <EvanR> | but someone noted the existence of unsafeThaw which is your trap door into "I know what I'm doing" |
| 2024-11-12 20:27:09 +0100 | <EvanR> | since it is |
| 2024-11-12 20:27:06 +0100 | <EvanR> | it certainly would still be treated like a mutable array |
| 2024-11-12 20:26:17 +0100 | <bailsman> | I would like most of the code to be regular normal pure code |
| 2024-11-12 20:25:57 +0100 | <bailsman> | I wonder if that still causes the compiler to think the data is "actually mutable" and disables a ton of optimizations |
| 2024-11-12 20:25:54 +0100 | <EvanR> | which is a different subject from increasing the performance of working with an array |
| 2024-11-12 20:25:33 +0100 | <EvanR> | what I just suggested as in response to "compiler stops me from writing to it when I don't want to, because... I might accidentally write code to write to it for some reason" |
| 2024-11-12 20:24:48 +0100 | <bailsman> | If that's easy to do, why isn't it how freeze/thaw already works? |
| 2024-11-12 20:24:37 +0100 | sawilagar | (~sawilagar@user/sawilagar) (Quit: Leaving) |
| 2024-11-12 20:24:08 +0100 | <bailsman> | Interesting. Can you make an example? |
| 2024-11-12 20:23:38 +0100 | <EvanR> | you can wrap your ST array in a newtype which won't allow you to write through it |
| 2024-11-12 20:23:07 +0100 | <bailsman> | but I would like the compiler to ensure that I'm not writing to the data where I don't want to be writing to it. |
| 2024-11-12 20:22:48 +0100 | <bailsman> | I'm totally happy to annotate all the rest of the code however the type system needs me |
| 2024-11-12 20:22:28 +0100 | <EvanR> | you can access the array however you want, and the whole operation will be considered pure in the end |
| 2024-11-12 20:22:16 +0100 | <EvanR> | the whole thing being an ST action sounds like what ST is meant for |
| 2024-11-12 20:21:50 +0100 | <bailsman> | So what I should do instead is design it to pass mutable references around and just not write to them where I'm not supposed to? |
| 2024-11-12 20:21:20 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
| 2024-11-12 20:21:14 +0100 | <EvanR> | but I expect the total cost to defeat the purpose of all this optimization talk |
| 2024-11-12 20:20:52 +0100 | <EvanR> | since it's temporary maybe it won't be so bad |
| 2024-11-12 20:20:29 +0100 | <EvanR> | see if it fits into the gc first generation |
| 2024-11-12 20:20:20 +0100 | <bailsman> | I mean that was pretty much my worry, and why I was looking for whether "immutable references to mutable data" are a thing |
| 2024-11-12 20:19:58 +0100 | <EvanR> | fine then |
| 2024-11-12 20:19:47 +0100 | <bailsman> | it's just memcopy can't you do that at terrabytes per second or something |
| 2024-11-12 20:19:45 +0100 | <EvanR> | especially if you do it once per loop and discard it all |
| 2024-11-12 20:19:28 +0100 | <EvanR> | not cheap |
| 2024-11-12 20:19:21 +0100 | <EvanR> | copying 100k elements? |
| 2024-11-12 20:19:18 +0100 | <bailsman> | geekosaur: yes |
| 2024-11-12 20:19:07 +0100 | <bailsman> | Is it? I wonder if it's going to be the fastest part, so fast that I'll be embarrased to have enough wondered about the issue. |
| 2024-11-12 20:19:06 +0100 | <EvanR> | gc |
| 2024-11-12 20:19:05 +0100 | <EvanR> | accessing a mutable array involves more book keeping than an immutable array, in the gd |
| 2024-11-12 20:18:59 +0100 | <geekosaur> | am I understanding correctly that updateSingleElement only reads, and ultimately produces a value that the impure code will actually use to mutate? |
| 2024-11-12 20:18:20 +0100 | <EvanR> | well, the frozenCopy is going to be expensive, and there's no real way around it |
| 2024-11-12 20:17:41 +0100 | <bailsman> | updateSingleElement and everything it calls |
| 2024-11-12 20:17:33 +0100 | <EvanR> | what pure part |
| 2024-11-12 20:17:28 +0100 | <bailsman> | No, because the "pure part" of the code should not write anywhere |
| 2024-11-12 20:17:18 +0100 | <EvanR> | mutable array it is |
| 2024-11-12 20:17:08 +0100 | <bailsman> | Every iteration of the loop, every element is going to get updated again. I want to keep modifying them over and over (in place) |
| 2024-11-12 20:16:50 +0100 | <EvanR> | but not the other way around |
| 2024-11-12 20:16:47 +0100 | <EvanR> | "for free" |
| 2024-11-12 20:16:39 +0100 | <EvanR> | the normal intuitive way sounds like you just want a mutable array. There is a thing where you can export a mutable array that you made as a "pure" immutable array from an ST action |
| 2024-11-12 20:15:28 +0100 | <bailsman> | I think what I might want to do is just do an O(n) copy of the entire mutable vector using regular freeze (not unsafeFreeze) and then do something like modify (updateSingleElement frozenCopy) index? That's one allocation, but it's kind of outside the core loop, and the whole thing is already O(n) anyway and copying some memory over is fast. |
| 2024-11-12 20:15:10 +0100 | <bailsman> | I want to write most of the logic in "normal intuitive code" but then also have the optimizer notice that it's being updated in place and not do any allocations (because I've read somewhere allocations are bad - I've not actually done any profiling) |
| 2024-11-12 20:14:47 +0100 | <EvanR> | so when you thaw something it makes a copy unless there was a rewrite rule to avoid it because of reasons |
| 2024-11-12 20:13:53 +0100 | <EvanR> | this is the purely theoretical part. The practical difficulty is that mutable and immutable objects are treated totally different in the runtime system |
| 2024-11-12 20:13:09 +0100 | <EvanR> | I assume you think that's not happening, because you carefully cleared that part of the code |