Newest at the top
| 2025-03-28 22:03:34 +0100 | <haskellbridge> | <Liamzee> going full embedded with LH, at this time, is probably not a good idea, but developing wrapped linear Haskell libraries is probably a good transition to build up skills within the community and build up support for the LinearTypes extension |
| 2025-03-28 22:03:28 +0100 | AlexZenon | (~alzenon@178.34.150.194) |
| 2025-03-28 22:02:53 +0100 | <haskellbridge> | <Liamzee> yeah, i saw, I recently did a purview of the LH ecosystem :) |
| 2025-03-28 22:02:29 +0100 | AlexZenon | (~alzenon@178.34.150.194) (Ping timeout: 252 seconds) |
| 2025-03-28 22:02:24 +0100 | kimiamania | (~65804703@user/kimiamania) kimiamania |
| 2025-03-28 22:02:04 +0100 | <tomsmeding> | Liamzee: https://hackage.haskell.org/package/text-builder-linear for example |
| 2025-03-28 22:02:01 +0100 | kimiamania | (~65804703@user/kimiamania) (Quit: PegeLinux) |
| 2025-03-28 22:01:48 +0100 | <merijn> | EvanR: It was a program streaming a few GB worth of data from SQLite via conduit, it actually worked remarkably well in keeping low RES memory for the data size |
| 2025-03-28 22:01:42 +0100 | <haskellbridge> | <Liamzee> I guess, I'll ask directly, is there something wrong with using LinearTypes as something wrapped over by non-linear Haskell to provide a low-cost performance gain without needing FFI? |
| 2025-03-28 22:00:15 +0100 | <tomsmeding> | so if you're using a State monad that you would like to do mutable updates with, it's actually very easy to achieve that now |
| 2025-03-28 22:00:14 +0100 | <EvanR> | napkin math says that implies you "run out of resident memory" 400 times a second |
| 2025-03-28 21:59:42 +0100 | <haskellbridge> | <Liamzee> one cute trick you can do with LinearTypes that I haven't seen much is using LinearTypes ;) |
| 2025-03-28 21:59:38 +0100 | <tomsmeding> | you get `modify :: (s %1-> s) -> State s a -> State s a`, and it otherwise works essentially exactly like the normal state monad |
| 2025-03-28 21:59:14 +0100 | <tomsmeding> | one cute trick you can do with LinearTypes that I haven't seen much is `newtype State s a = Staet (s %1-> (Ur a, s))` |
| 2025-03-28 21:58:42 +0100 | <merijn> | Liamzee: FWIW, I've had Haskell programs with allocation rates of over 4 Gb/s (and this is the average over a duration of 2-3 minutes) that never exceeded more than a few 10s of MB of resident memory |
| 2025-03-28 21:57:45 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) (Client Quit) |
| 2025-03-28 21:57:45 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) jespada |
| 2025-03-28 21:57:31 +0100 | <EvanR> | allocation is fast and easy |
| 2025-03-28 21:57:29 +0100 | <merijn> | Maybe 1 or 2 instructions for an atomic CAS? |
| 2025-03-28 21:57:18 +0100 | <merijn> | It's basically "increment a number" and a comparison to check if you exceeded the heap |
| 2025-03-28 21:56:07 +0100 | <merijn> | Like, I'd be surprised if allocating memory took more than 5 instructions in GHC |
| 2025-03-28 21:55:32 +0100 | jespada | (~jespada@2800:a4:231e:8900:903f:fbe:20bf:5608) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-28 21:55:24 +0100 | <merijn> | EvanR: In place updates when reference count == 1 |
| 2025-03-28 21:55:15 +0100 | <merijn> | Liamzee: FYI, GHC's allocator is *stupidly* fast, though |
| 2025-03-28 21:55:10 +0100 | <EvanR> | "automatic mutation" ? |
| 2025-03-28 21:51:48 +0100 | <haskellbridge> | <Liamzee> which is a feature that some people want |
| 2025-03-28 21:51:42 +0100 | <haskellbridge> | <Liamzee> i'm just being conservative because i was told that there's no automatic mutation implied by linear haskell |
| 2025-03-28 21:50:15 +0100 | <haskellbridge> | <Liamzee> Web type? |
| 2025-03-28 21:49:57 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 248 seconds) |
| 2025-03-28 21:45:34 +0100 | <EvanR> | it just sounds like you're conflating "no GC memory management" with linear types |
| 2025-03-28 21:44:43 +0100 | <EvanR> | that's why Ur/Web waits until the end of the processing program to discard the entire block of memory |
| 2025-03-28 21:44:09 +0100 | <EvanR> | calling into a memory management system to "free" stuff constantly sounds like overhead of its own |
| 2025-03-28 21:43:56 +0100 | <haskellbridge> | <Liamzee> and not needing the GC to be on to cover the data |
| 2025-03-28 21:43:47 +0100 | <haskellbridge> | <Liamzee> at least in theory, though, it should have better performance due to not needing to do as many allocations |
| 2025-03-28 21:43:10 +0100 | <EvanR> | linear anything is often much more general in scope |
| 2025-03-28 21:41:59 +0100 | <EvanR> | e.g. it could have been evidence of some sort that's now invalid |
| 2025-03-28 21:41:38 +0100 | <EvanR> | in another case, it wasn't a real object the begin with |
| 2025-03-28 21:41:29 +0100 | <EvanR> | in another case, the object's ownership transferred elsewhere |
| 2025-03-28 21:41:13 +0100 | <EvanR> | freeing it would break things in that case |
| 2025-03-28 21:41:08 +0100 | <EvanR> | in one example, that space was immediately reused by the operation you just did |
| 2025-03-28 21:41:02 +0100 | <haskellbridge> | <Liamzee> "not sure if the allocator works that way" |
| 2025-03-28 21:40:39 +0100 | <EvanR> | it just means you can't use it again |
| 2025-03-28 21:40:27 +0100 | <EvanR> | the meaning of "consumed" doesn't necessarily mean "deleted from existence" |
| 2025-03-28 21:39:53 +0100 | <haskellbridge> | <Liamzee> you might have a GC for the nonlinear haskell wrapping the computation, but the linear computation doesn't need a GC |
| 2025-03-28 21:39:21 +0100 | <haskellbridge> | <Liamzee> i mean linear types imply that a value is consumed, meaning that its allocation can be cleared |
| 2025-03-28 21:37:30 +0100 | <EvanR> | free what |
| 2025-03-28 21:36:31 +0100 | <EvanR> | what do you mean |
| 2025-03-28 21:35:58 +0100 | <haskellbridge> | <Liamzee> EvanR: but while doing the computation, you could potentially do free after use, but i'm not sure if the allocator works that way |
| 2025-03-28 21:32:56 +0100 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/linear-base-0.4.0/docs/src/Data.Unrestricted.Linear.Internal.U… |
| 2025-03-28 21:32:13 +0100 | weary-traveler | (~user@user/user363627) user363627 |