Newest at the top
| 2025-03-29 06:30:12 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-03-29 06:25:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-03-29 06:22:56 +0100 | xff0x | (~xff0x@2405:6580:b080:900:73c3:617e:93dd:971) (Ping timeout: 244 seconds) |
| 2025-03-29 06:20:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-29 06:11:34 +0100 | tabaqui | (~tabaqui@167.71.80.236) (Ping timeout: 244 seconds) |
| 2025-03-29 06:11:33 +0100 | Square | (~Square@user/square) Square |
| 2025-03-29 06:11:29 +0100 | Square2 | (~Square@user/square) Square |
| 2025-03-29 06:09:28 +0100 | son0p | (~ff@190.249.196.199) (Ping timeout: 268 seconds) |
| 2025-03-29 06:09:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
| 2025-03-29 06:04:20 +0100 | Flow | (~none@gentoo/developer/flow) flow |
| 2025-03-29 05:58:03 +0100 | Flow | (~none@gentoo/developer/flow) (Ping timeout: 252 seconds) |
| 2025-03-29 05:39:26 +0100 | bilegeek | (~bilegeek@2600:1008:b001:c41c:5fd7:83ed:e07c:8226) bilegeek |
| 2025-03-29 05:30:42 +0100 | aforemny | (~aforemny@i577B139C.versanet.de) (Ping timeout: 246 seconds) |
| 2025-03-29 05:29:50 +0100 | aforemny_ | (~aforemny@i577B132D.versanet.de) aforemny |
| 2025-03-29 05:17:28 +0100 | <haskellbridge> | <Liamzee> are there good reasons not to use Twain? Are there limitations of Twain I should know about? |
| 2025-03-29 05:13:08 +0100 | <haskellbridge> | <Bowuigi> Probably yes to the refcounting, not to the efficient GC |
| 2025-03-29 05:12:36 +0100 | <haskellbridge> | <Bowuigi> No clue but probably yes. Tho allocations are not inferred in Rust (that's why you have to deal with the borrow checker) |
| 2025-03-29 05:11:12 +0100 | <haskellbridge> | <Liamzee> Bowuigi: |
| 2025-03-29 05:11:09 +0100 | <haskellbridge> | <Liamzee> is that what rust's optimizer is actually doing? |
| 2025-03-29 04:51:55 +0100 | ChanServ | +v haskellbridge |
| 2025-03-29 04:51:55 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) hackager |
| 2025-03-29 04:51:21 +0100 | haskellbridge | (~hackager@syn-024-093-192-219.res.spectrum.com) (Remote host closed the connection) |
| 2025-03-29 04:49:10 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
| 2025-03-29 04:30:26 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 252 seconds) |
| 2025-03-29 04:29:49 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
| 2025-03-29 04:08:58 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) ZLima12 |
| 2025-03-29 04:07:49 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) (Remote host closed the connection) |
| 2025-03-29 04:07:23 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
| 2025-03-29 04:06:50 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
| 2025-03-29 04:02:26 +0100 | EvanR | (~EvanR@user/evanr) (Ping timeout: 272 seconds) |
| 2025-03-29 04:01:40 +0100 | EvanR_ | (~EvanR@user/evanr) EvanR |
| 2025-03-29 03:59:22 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-29 03:48:18 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2025-03-29 03:40:53 +0100 | talismanick | (~user@2601:644:937c:ed10::ae5) talismanick |
| 2025-03-29 03:40:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-29 03:39:10 +0100 | ensyde | (~ensyde@2601:5c6:c200:6dc0::6f7f) ensyde |
| 2025-03-29 03:37:54 +0100 | tomku | (~tomku@user/tomku) tomku |
| 2025-03-29 03:29:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-29 03:19:28 +0100 | nitrix | (~nitrix@user/meow/nitrix) nitrix |
| 2025-03-29 03:13:54 +0100 | <haskellbridge> | <Bowuigi> Modern GCs have a lot of thought put into them in order to make them really fast. Allocation for those is practically free and deallocation is deferred until it's at near-peak efficiency |
| 2025-03-29 03:13:37 +0100 | tomku | (~tomku@user/tomku) (Ping timeout: 244 seconds) |
| 2025-03-29 03:11:15 +0100 | <haskellbridge> | <Bowuigi> But you don't have to trust me here, the Perceus (basically inferring linear and inserting alloc/free) tests a lot of people have done show improvements only on very specific examples, but poorer performance otherwise |
| 2025-03-29 03:09:48 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-29 03:09:34 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-29 03:09:30 +0100 | malte | (~malte@mal.tc) malte |
| 2025-03-29 03:08:34 +0100 | <haskellbridge> | <Bowuigi> On many cases, an arena allocator is the fastest option because you can free many things at once (faster than one thing at a time). It's even recommended in C because of it's speed and simplicity |
| 2025-03-29 03:07:14 +0100 | <haskellbridge> | <Bowuigi> Liamzee freeing after use isn't the fastest option. In fact, switching to it on linear code would actually make it slower |
| 2025-03-29 03:04:31 +0100 | malte | (~malte@mal.tc) (Remote host closed the connection) |
| 2025-03-29 03:04:03 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
| 2025-03-29 03:00:51 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |