Newest at the top
| 2025-03-12 23:15:38 +0100 | michalz | (~michalz@185.246.207.205) (Remote host closed the connection) |
| 2025-03-12 23:14:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 23:12:32 +0100 | <Inst> | it's doing it simultaneously |
| 2025-03-12 23:11:07 +0100 | <EvanR> | one which lets you forget parts you don't need anymore, before the whole tree is created |
| 2025-03-12 23:10:52 +0100 | <EvanR> | lined up |
| 2025-03-12 23:10:48 +0100 | <EvanR> | because you get better laziness by having a plan lined for consuming the tree |
| 2025-03-12 23:10:18 +0100 | <EvanR> | is it populating an actual data structure before doing anything else |
| 2025-03-12 23:09:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 23:09:33 +0100 | Square2 | (~Square4@user/square) (Ping timeout: 245 seconds) |
| 2025-03-12 23:09:06 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
| 2025-03-12 23:08:20 +0100 | <Inst> | but honestly, tbh, the vision in my head of this tree lazily being populated outwards from the bottom left corner is beautiful |
| 2025-03-12 23:07:46 +0100 | <Inst> | i'm just doing exercises, i have a strong feeling and others have suggested what i'm trying to do is dumb |
| 2025-03-12 23:06:40 +0100 | Square | (~Square@user/square) Square |
| 2025-03-12 23:06:22 +0100 | <juri_> | (source: I write ~AVX512 assembly by hand, to make LLMs go faster) |
| 2025-03-12 23:05:45 +0100 | <juri_> | the real problem is: modern computers have an architecture that looks uniform from one angle, but if you get out a stopwatch... has layers of caches, dumb rules, and in order to get real performance, you need to almost hand compile, and back, just so you get your units-of-work in the right sizes for all of the different cache subsystems. |
| 2025-03-12 23:04:14 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 23:04:11 +0100 | <EvanR> | :( |
| 2025-03-12 23:03:39 +0100 | <juri_> | oh, it's much more complicated than that. :) |
| 2025-03-12 23:03:38 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
| 2025-03-12 23:03:02 +0100 | <EvanR> | I guess IRL you would also want to align your power of 2 size array/vector with the cache lines |
| 2025-03-12 23:02:39 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) |
| 2025-03-12 23:01:54 +0100 | <juri_> | they use Vector internally, but wrap that in an interesting interface. |
| 2025-03-12 23:01:14 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
| 2025-03-12 23:00:17 +0100 | <juri_> | FWIW, repa seems to be useful for these things. |
| 2025-03-12 22:59:06 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 22:59:03 +0100 | Sgeo | (~Sgeo@user/sgeo) Sgeo |
| 2025-03-12 22:58:16 +0100 | <EvanR> | there are a few conal videos where he wants to do parallel computation (eventually, in hardware) and he rejects linked list in favor of array (of size power of 2) |
| 2025-03-12 22:57:00 +0100 | <Inst> | c_wraith: thanks for the warning, I finally understand why lists are so hard to parallelize. They're effectively a one-channel stream, so i need a long computation to spark and parallelize the next computation before the first computation finishes, and even then, I'll have problems with blackholing / blocking, as you've said. |
| 2025-03-12 22:54:27 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:53:52 +0100 | Inst | (~Inst@user/Inst) Inst |
| 2025-03-12 22:51:56 +0100 | xkuru | (~xkuru@user/xkuru) xkuru |
| 2025-03-12 22:51:33 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-03-12 22:49:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
| 2025-03-12 22:48:23 +0100 | tusko | (uid478376@user/tusko) tusko |
| 2025-03-12 22:47:34 +0100 | fantom | (~fantom@2.219.56.221) |
| 2025-03-12 22:45:38 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
| 2025-03-12 22:43:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 22:39:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:37:42 +0100 | sdrfan123 | (~sdrfan123@2607:fb90:ad22:c6ba:1965:cecd:386e:8114) (Quit: Client closed) |
| 2025-03-12 22:30:16 +0100 | jespada | (~jespada@r190-135-78-231.dialup.adsl.anteldata.net.uy) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-03-12 22:28:29 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-03-12 22:27:31 +0100 | cheater_ | cheater |
| 2025-03-12 22:27:22 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 244 seconds) |
| 2025-03-12 22:26:55 +0100 | cheater_ | (~Username@user/cheater) cheater |
| 2025-03-12 22:23:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-03-12 22:22:25 +0100 | tusko | (uid478376@user/tusko) (Quit: Connection closed for inactivity) |
| 2025-03-12 22:17:39 +0100 | tabaqui | (~root@167.71.80.236) (Quit: WeeChat 4.5.1) |
| 2025-03-12 22:12:54 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
| 2025-03-12 22:09:39 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 265 seconds) |
| 2025-03-12 22:08:19 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |