Newest at the top
| 2026-03-10 14:55:36 +0100 | CiaoSen | (~Jura@2a02:8071:64e1:da0:5a47:caff:fe78:33db) (Ping timeout: 264 seconds) |
| 2026-03-10 14:44:10 +0100 | Square2 | (~Square4@user/square) Square |
| 2026-03-10 14:36:22 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2026-03-10 14:30:10 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) (Ping timeout: 245 seconds) |
| 2026-03-10 14:27:44 +0100 | Fijxu_ | (~Fijxu@user/fijxu) fijxu |
| 2026-03-10 14:26:29 +0100 | Freakie | (~Freakie@37.96.7.244) |
| 2026-03-10 14:26:23 +0100 | adamCS | (~adamCS@70.19.85.77) adamCS |
| 2026-03-10 14:26:17 +0100 | Fijxu | (~Fijxu@user/fijxu) (Read error: Connection reset by peer) |
| 2026-03-10 14:25:49 +0100 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2026-03-10 14:20:54 +0100 | gabiruh | (~gabiruh@vps19177.publiccloud.com.br) gabiruh |
| 2026-03-10 14:18:33 +0100 | gabiruh | (~gabiruh@191.252.222.55) (Quit: ZNC 1.7.5 - https://znc.in) |
| 2026-03-10 14:17:19 +0100 | adamCS | (~adamCS@70.19.85.77) (Remote host closed the connection) |
| 2026-03-10 14:07:55 +0100 | nschoe | (~nschoe@82-65-202-30.subs.proxad.net) nschoe |
| 2026-03-10 14:07:38 +0100 | nschoe- | (~nschoe@2a01:e0a:8e:a190:bcc4:c62f:8a83:eae8) (Quit: ZNC 1.8.2 - https://znc.in) |
| 2026-03-10 14:07:24 +0100 | jreicher | (~joelr@user/jreicher) (Ping timeout: 256 seconds) |
| 2026-03-10 14:02:37 +0100 | Freakie | (~Freakie@37.96.7.244) (Quit: Client closed) |
| 2026-03-10 13:50:08 +0100 | <Freakie> | I hope it doesn't sound like I'm being difficult, I'm just working with a lot of constraints (albeit intentioanlly) |
| 2026-03-10 13:49:17 +0100 | <Freakie> | at which point in-memory sharing is also problematic |
| 2026-03-10 13:48:56 +0100 | <Freakie> | the same problem can be moved to cache level |
| 2026-03-10 13:48:36 +0100 | <Freakie> | the point is more that the whole model of computation i'm working with only counts I/O operations as costful, hence *in theory* pointer sharing is problematic |
| 2026-03-10 13:47:54 +0100 | <Freakie> | it would problem be something like that if I get that far |
| 2026-03-10 13:46:55 +0100 | <comerijn> | Why not give your data a Storable instance and just allocate blocks of memory explicitly |
| 2026-03-10 13:46:39 +0100 | <Freakie> | well technically it would only matter once data needs to be pushed to the disk |
| 2026-03-10 13:46:30 +0100 | <comerijn> | *that |
| 2026-03-10 13:46:27 +0100 | <comerijn> | At the point why not take an entirely different approach |
| 2026-03-10 13:46:12 +0100 | m1dnight_ | (~m1dnight@141.134.26.23) (Ping timeout: 244 seconds) |
| 2026-03-10 13:46:05 +0100 | <Freakie> | it's nothing to do with referential transparency and everything to do with data locality |
| 2026-03-10 13:45:53 +0100 | <Freakie> | I'm trying to work with I/O efficient algorithms and sharing can imply page faults |
| 2026-03-10 13:45:48 +0100 | <comerijn> | Freakie: In an immutable setting, how do you think you could possibly observe whether something is shared? |
| 2026-03-10 13:45:16 +0100 | <comerijn> | sharing or not sharing is not obsevable |
| 2026-03-10 13:45:12 +0100 | <Freakie> | it seems counterintuitive but it's a pretty essential part (at least if the algorithms actually manage to scale to the problem sizes they want toa ddress) |
| 2026-03-10 13:44:45 +0100 | <Freakie> | yes but sharing is a problem in theory for what the algorithms need to do |
| 2026-03-10 13:44:31 +0100 | <comerijn> | A compact region is not mutable |
| 2026-03-10 13:44:13 +0100 | <comerijn> | Data is immutable |
| 2026-03-10 13:44:09 +0100 | <comerijn> | Freakie: deep copying question makes no sense |
| 2026-03-10 13:43:25 +0100 | <Freakie> | (it's desired in what I'm trying to do) |
| 2026-03-10 13:43:16 +0100 | <Freakie> | do you know if the compact regions are deep copied? |
| 2026-03-10 13:42:51 +0100 | <Freakie> | and then sorting them lazily (i.e. when you actually need to traverse said level) |
| 2026-03-10 13:42:24 +0100 | <Freakie> | otherwise I was planning on using the levelwise layout of the BDD to separate the closest data (for example what needs to be processed on the current and next level) from the priority queue itself |
| 2026-03-10 13:41:02 +0100 | <Freakie> | maybe a compact PQ could help but then I suppose the region will just keep growing till the algorithm is done? |
| 2026-03-10 13:40:33 +0100 | <Freakie> | I know, I'm just not working with many other data structures than the BDDs themselves (which are represented by lists, and only traversed during algorithms) and the priroity queue |
| 2026-03-10 13:40:31 +0100 | <comerijn> | Including (parts) of your priority queue |
| 2026-03-10 13:40:06 +0100 | <comerijn> | Freakie: I mean, you don't have to limit yourself to compact individual BDD. You can compact essentially any arbitrary tree of data |
| 2026-03-10 13:39:31 +0100 | <comerijn> | Depends how often you trigger GC ;) |
| 2026-03-10 13:39:26 +0100 | <Freakie> | I can utilize the levelwise layout of the lists though |
| 2026-03-10 13:39:12 +0100 | <Freakie> | yeah I jjust mean to say that the extra cost of traversing the input lists shouldn't be the deciding factor |
| 2026-03-10 13:38:51 +0100 | <comerijn> | Freakie: The same applies for any of the data during the algorithms :) |
| 2026-03-10 13:38:46 +0100 | <Freakie> | for n = 8 the largest BDD generated only has like 10k nodes while the number of insertions to the PQ can hit double digits |
| 2026-03-10 13:38:36 +0100 | <comerijn> | ok, so that's probably not where your cost is |
| 2026-03-10 13:38:09 +0100 | <Freakie> | the thing is just that the BDDs themselves are not that large relative to the data allocated during the algorithms |