Newest at the top
| 2025-01-08 12:02:19 +0100 | kuribas | (~user@ptr-17d51eo5v3yo1z5ic8l.18120a2.ip6.access.telenet.be) kuribas |
| 2025-01-08 11:57:49 +0100 | dsrt^ | (dsrt@c-98-242-74-66.hsd1.ga.comcast.net) (Ping timeout: 252 seconds) |
| 2025-01-08 11:56:49 +0100 | xff0x | (~xff0x@2405:6580:b080:900:6a01:c501:bf5a:df58) |
| 2025-01-08 11:54:04 +0100 | siborg | (sid630849@user/rawles) () |
| 2025-01-08 11:54:02 +0100 | notzmv | (~umar@user/notzmv) notzmv |
| 2025-01-08 11:45:10 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-08 11:45:06 +0100 | <haskellbridge> | <magic_rb> For certain systems it might be beneficial to do the bulk of the logic in C. Currently the way the renderer works is it every frame copies all my entities that need to be rendered into a storable array of structs and then passes that to C which loops over it. Its surprisingly fast lol |
| 2025-01-08 11:44:08 +0100 | <haskellbridge> | <magic_rb> Benefit of doing it in C is that there is only one implementation that i can call into from C for free |
| 2025-01-08 11:43:42 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:bcbc:bf70:1416:c809) ubert |
| 2025-01-08 11:43:36 +0100 | <merijn> | magic_rb: Right, but that's basically the same as writing it directly using ghc-prim, except then the portability problem is outsourced to GHC ;) |
| 2025-01-08 11:42:28 +0100 | <haskellbridge> | <magic_rb> But that would then mean id have to write different preambles per architecture which i dont really feel like doing :) |
| 2025-01-08 11:42:06 +0100 | <haskellbridge> | <magic_rb> Im kind of tempted to implement the sparse sets as foreign primops in C |
| 2025-01-08 11:39:47 +0100 | <merijn> | it's a slightly higher wrapper around stuff like ghc-prim |
| 2025-01-08 11:39:34 +0100 | <merijn> | primitive is fine too |
| 2025-01-08 11:39:26 +0100 | <merijn> | Just not very portable, but that only matters in a universe where we still pretend anything but GHC matters :P |
| 2025-01-08 11:39:24 +0100 | <haskellbridge> | <magic_rb> should i not be using primitive? |
| 2025-01-08 11:39:03 +0100 | <merijn> | That said, (most of) ghc-prim is perfectly safe and really not that complicated |
| 2025-01-08 11:39:00 +0100 | <haskellbridge> | <magic_rb> yeah fair, loking at the primitive package and PrimArray, i think thats what i need |
| 2025-01-08 11:38:36 +0100 | <merijn> | magic_rb: Once you start wondering "how do I avoid boxing/reboxing" you can't really avoid looking at that kinda stuff ;) |
| 2025-01-08 11:37:54 +0100 | <tomsmeding> | I see |
| 2025-01-08 11:37:37 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-08 11:37:32 +0100 | <haskellbridge> | <magic_rb> yeah i didnt want to go that deep, was hoping i could avoid it :) |
| 2025-01-08 11:37:03 +0100 | <merijn> | magic_rb: You should probably take some time browsing ghc-prim if you haven't yet :) |
| 2025-01-08 11:35:45 +0100 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 260 seconds) |
| 2025-01-08 11:34:42 +0100 | <haskellbridge> | <magic_rb> Which is a lot if exists is called hundreds of times per frame |
| 2025-01-08 11:34:30 +0100 | <haskellbridge> | <magic_rb> tomsmeding i looked at the core and its doing boxing unboxing in a single call to exists, i counted 3 or 4 boxes unboxes |
| 2025-01-08 11:33:38 +0100 | mari50420 | (~mari-este@user/mari-estel) mari-estel |
| 2025-01-08 11:33:27 +0100 | __monty__ | (~toonn@user/toonn) toonn |
| 2025-01-08 11:29:55 +0100 | jespada | (~jespada@2800:a4:f9:a300:c8c1:20a5:1a94:f1) (Quit: My Mac has gone to sleep. ZZZzzz…) |
| 2025-01-08 11:28:58 +0100 | Guest17 | (~Guest17@91.243.81.204) (Quit: Client closed) |
| 2025-01-08 11:26:03 +0100 | <tomsmeding> | https://hackage.haskell.org/package/vector-0.13.2.0/src/internal/unbox-tuple-instances |
| 2025-01-08 11:23:14 +0100 | <tomsmeding> | if you want to read manually from a MutableByteArray, https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-Exts.html#v:readInt64Array-35- |
| 2025-01-08 11:22:38 +0100 | <tomsmeding> | are you sure you're not looking for Data.Vector.Storable.Mutable? |
| 2025-01-08 11:21:43 +0100 | <tomsmeding> | one containing the fst components, the other containing the snd components |
| 2025-01-08 11:21:28 +0100 | <tomsmeding> | an `MVector s (Int, Int)` in the end consists of _two_ `MutableByteArray s`es |
| 2025-01-08 11:20:29 +0100 | <tomsmeding> | and also, the 'a' here is a boxed type |
| 2025-01-08 11:20:10 +0100 | <tomsmeding> | but unboxed types in an unboxed vector (as opposed to a _storable_ vector) are stored in struct-of-arrays format |
| 2025-01-08 11:19:31 +0100 | <tomsmeding> | recall my earlier comments on the ghc unboxer |
| 2025-01-08 11:19:20 +0100 | <tomsmeding> | are you sure you need that for performance? |
| 2025-01-08 11:17:34 +0100 | Guest17 | (~Guest17@91.243.81.204) |
| 2025-01-08 11:17:22 +0100 | Guest17 | (~Guest17@91.243.81.204) (Quit: Client closed) |
| 2025-01-08 11:15:55 +0100 | tnt2 | tnt1 |
| 2025-01-08 11:13:37 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
| 2025-01-08 11:13:34 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
| 2025-01-08 11:07:16 +0100 | <haskellbridge> | <magic_rb> is there no way to directly read from a Unboxed Mutable Vector using Int# as the index and read the undoxed type directly? https://hackage.haskell.org/package/vector-0.13.2.0/docs/Data-Vector-Unboxed-Mutable.html i dont see anything in the module |
| 2025-01-08 11:06:06 +0100 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) tomsmeding |
| 2025-01-08 11:04:23 +0100 | tomsmeding | (~tomsmedin@2a01:4f8:c0c:5e5e::2) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-01-08 11:01:01 +0100 | merijn | (~merijn@77.242.116.146) merijn |
| 2025-01-08 10:58:36 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 246 seconds) |
| 2025-01-08 10:57:56 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |