Newest at the top
| 2026-02-14 22:48:14 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-14 22:43:27 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 22:42:43 +0100 | <tomsmeding> | 99% certain they don't built on top of vector and allocate their own primitive arrays |
| 2026-02-14 22:40:56 +0100 | <[exa]> | probie: btw really try if repa manages to SIMD, deconstructing a working instance is a MUCH easier way to debug compilers than trying to hit a subtle trick that does it |
| 2026-02-14 22:40:50 +0100 | <int-e> | *led |
| 2026-02-14 22:40:44 +0100 | caubert | (~caubert@user/caubert) (Ping timeout: 245 seconds) |
| 2026-02-14 22:40:41 +0100 | <int-e> | It lead to `inlinePerformIO` being renamed :-) |
| 2026-02-14 22:40:12 +0100 | <int-e> | probie: Well, you have mutable data there; even lazy evaluation shouldn't accidentally alias those. (Though for people who remember the early days of bytestring... yes, these things have happened.) |
| 2026-02-14 22:39:05 +0100 | <tomsmeding> | it might be possible to devise something in combination with linear types |
| 2026-02-14 22:38:36 +0100 | <probie> | We need a new GHC extension that introduces the `restrict` keyword (although I can't imagine that being a sane thing to have in the context of non-strict evaluation) |
| 2026-02-14 22:38:03 +0100 | <int-e> | and it'll get awkward regardless if the relative alignment of the two pointers isn't 0. |
| 2026-02-14 22:37:24 +0100 | <[exa]> | oh yes true |
| 2026-02-14 22:37:11 +0100 | <tomsmeding> | [exa]: remember this is a loop with dependencies so llvm can't unroll |
| 2026-02-14 22:37:01 +0100 | <int-e> | And I don't think you can express the promise that these two pointers never alias at the Haskell level. |
| 2026-02-14 22:36:54 +0100 | <[exa]> | is it? (does the vector start on aligned addr?) |
| 2026-02-14 22:36:17 +0100 | <tomsmeding> | ah yes, in this case it is |
| 2026-02-14 22:36:01 +0100 | <int-e> | tomsmeding: well, the alignment is already fixed by how you unrolled the loop |
| 2026-02-14 22:36:00 +0100 | <[exa]> | like, ofc llvm is going to brainify that to The Way Better Aligned Load |
| 2026-02-14 22:35:40 +0100 | <tomsmeding> | I'm... not sure what I was thinking |
| 2026-02-14 22:35:33 +0100 | <tomsmeding> | [exa]: good point, my bad, yes loadu is a thing |
| 2026-02-14 22:35:07 +0100 | <tomsmeding> | so it should just generate a prologue |
| 2026-02-14 22:34:58 +0100 | <tomsmeding> | but yes, I guess that llvm will have to deal with unaligned arrays anyway because it cannot assume any arbitrary pointer is aligned |
| 2026-02-14 22:34:47 +0100 | <[exa]> | loadu doesn't exist for epi8? |
| 2026-02-14 22:34:23 +0100 | <tomsmeding> | [exa]: simd instructions do have alignment constraints where normal x86 memory ops don't |
| 2026-02-14 22:33:48 +0100 | <[exa]> | probie: the alignment isn't a totally huge deal (just adds a bit of a weight on whether llvm later chooses the unaligned load or doesn't even trigger) |
| 2026-02-14 22:31:59 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-02-14 22:31:44 +0100 | machinedgod | (~machinedg@d75-159-126-101.abhsia.telus.net) machinedgod |
| 2026-02-14 22:31:32 +0100 | <probie> | Vector still has alignment issues though, so I'm not inclined to bend over backwards to get it to work |
| 2026-02-14 22:26:51 +0100 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-02-14 22:26:29 +0100 | <tomsmeding> | storable vectors are just C-style arrays as you expect |
| 2026-02-14 22:26:10 +0100 | <tomsmeding> | so there is indirection between the vector you have in hand and the underlying storage |
| 2026-02-14 22:25:59 +0100 | <[exa]> | probie: also highly suggest having a look at if repa/massiv can do this and if it can, copy what they did. IIRC these would still count these as "pure" haskell. |
| 2026-02-14 22:25:55 +0100 | <tomsmeding> | the idea of unboxed vectors is that they are struct-of-arrays transformed, i.e. a vector of (Int, Int) is actually two vectors under the hood |
| 2026-02-14 22:25:32 +0100 | <tomsmeding> | recommend storable vectors for that though, as they have a sensible withForeignPtr function |
| 2026-02-14 22:25:04 +0100 | <[exa]> | probie: there should be some (ugly but working) way to get a pointer to the vector which can be used as the required target type for the primitive op |
| 2026-02-14 22:24:30 +0100 | infinity0 | (~infinity0@pwned.gg) infinity0 |
| 2026-02-14 22:23:55 +0100 | <probie> | I think if I want to do this in "pure" Haskell, I'm better off ditching vector, and using `MutableByteArray#`s with the explicit SIMD operations from ghc-prim |
| 2026-02-14 22:21:54 +0100 | <[exa]> | :( |
| 2026-02-14 22:21:42 +0100 | <probie> | [exa]: It did fail, and the reads are absolutely not aligned |
| 2026-02-14 22:21:18 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Quit: Leaving) |
| 2026-02-14 22:20:25 +0100 | <[exa]> | probie: btw if this fails, try making sure the reads are aligned (no real clue how to help there tho.) |
| 2026-02-14 22:19:44 +0100 | <tomsmeding> | <3 |
| 2026-02-14 22:19:33 +0100 | <[exa]> | tomsmeding: cool I'm going to simd my stupid database string-indexing code :D |
| 2026-02-14 22:19:28 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
| 2026-02-14 22:17:27 +0100 | <geekosaur> | (I typo each of those into the other constantly…) |
| 2026-02-14 22:16:34 +0100 | <tomsmeding> | I can't type any more |
| 2026-02-14 22:16:32 +0100 | <tomsmeding> | s/ghc/gcc/ |
| 2026-02-14 22:16:00 +0100 | <tomsmeding> | -ffast-math dances circles around IEEE semantics, but memory semantics aren't broken down as far as I know |
| 2026-02-14 22:15:42 +0100 | <tomsmeding> | I would be surprised if ghc does this at any optimisation level |
| 2026-02-14 22:15:23 +0100 | <tomsmeding> | ignoring this is a blatant violation of the semantics |