Re: The myth of fingerprints, er, no, garbage collectors
"Yuri Davidovsky (as work at disclosure dot ie)" <[email protected]> Mon, 29 Jun 2026 14:30:44 +0200
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_922ED4B5-F825-43DF-BF20-F469F3665F7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Jun 2026, at 13:19, Tim Bradshaw <[email protected]> wrote: >=20 > So if I'm right, things are not too bad if my objects are laid out as = o1_1,o1_2,...,o1_n,o2_1,... where o1_1 means 1st field of 1st object &c = (1-based, sorry) and all the fields are the same type.=20 You mean, you put all single floats belonging to you structs in one = array, then all the doubles go into a different array, etc? This layout = is technically SIMD friendly, but in practice it will work only for a = specific set of circumstances. The issue here is that you typically want to apply the same operation to = fields that have the same purpose. So in a particle struct of two fields = (x, y) you have two properties that are of the same type (meaning, they = will fit into SIMD registers just fine) but they both have different = purposes =E2=80=94=20 X is responsible for the particle position on the X-axis, Y is responsible for the particle position on the Y-axis. If we go back to the example of determining the origin vector magnitude = by=20 sqrt(x=C2=B2 + y=C2=B2) it turns out that you won=E2=80=99t be able to calculate that using SIMD = because your X and Y values are adjacent and SIMD lanes do not cross = communicate. But it will still work for things like counting the sum, or = max, or average: x1 y1 z1 w1 +=20 x2 y2 z2 w2 =3D x=E2=80=99 y=E2=80=99 z=E2=80=99 w' If you need the fields to be SIMD operated on in all situations, the = simplest approach with your design would be to assign each field to a = separate vector, so if you have a struct that has four fields, like (x, = y, z, w), you could have four typed float point arrays like so: v1: x1, x2, x3 =E2=80=A6 xn v2: y1, y2, y3 =E2=80=A6 yn v3: z1, z2, z3 =E2=80=A6 zn v4: w1, w2, w3 =E2=80=A6 wn This way you can stream your structs through the SIMD registers with = minimal changes to your code. --Apple-Mail=_922ED4B5-F825-43DF-BF20-F469F3665F7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;"><br><blockquote type=3D"cite">On 29 Jun = 2026, at 13:19, Tim Bradshaw <[email protected]> wrote:<br><br = class=3D"Apple-interchange-newline">So if I'm right, things are not too = bad if my objects are laid out as o1_1,o1_2,...,o1_n,o2_1,... where o1_1 = means 1st field of 1st object &c (1-based, sorry) and all the fields = are the same type. </blockquote><br><div>You mean, you put all = single floats belonging to you structs in one array, then all the = doubles go into a different array, etc? This layout is technically SIMD = friendly, but in practice it will work only for a specific set of = circumstances.</div><div><br></div><div>The issue here is that you = typically want to apply the same operation to fields that have the same = purpose. So in a particle struct of two fields <i>(x, y)</i> you have = two properties that are of the same type (meaning, they will fit into = SIMD registers just fine) but they both have different purposes = =E2=80=94 </div><div><br></div><div>X is responsible for the = particle position on the X-axis,</div><div>Y is responsible for the = particle position on the Y-axis.</div><div><br></div><div>If we go back = to the example of determining the origin vector magnitude = by </div><div><br></div><div><b><font face=3D"Courier New">sqrt(x=C2=B2= + y=C2=B2)</font></b></div><div><br></div><div>it turns out that you = won=E2=80=99t be able to calculate that using SIMD because your X and Y = values are adjacent and SIMD lanes do not cross communicate. But it will = still work for things like counting the sum, or max, or = average:</div><div><br></div><div><b><font face=3D"Courier New"> = x1 y1 z1 w1</font></b></div><div><b><font face=3D"Courier = New">+ </font></b></div><div><b><font face=3D"Courier New"> = x2 y2 z2 w2</font></b></div><div><b><font face=3D"Courier New">=3D = x=E2=80=99 y=E2=80=99 z=E2=80=99 = w'</font></b></div><div><br></div><div>If you need the fields to be SIMD = operated on in all situations, the simplest approach with your design = would be to assign each field to a separate vector, so if you have a = struct that has four fields, like <i>(x, y, z, w)</i>, you could have = four typed float point arrays like so:</div><div><br></div><div><b><font = face=3D"Courier New">v1: x1, x2, x3 =E2=80=A6 = xn</font></b></div><div><b><font face=3D"Courier New">v2: y1, y2, y3 =E2=80= =A6 yn</font></b></div><div><b><font face=3D"Courier New">v3: z1, z2, z3 = =E2=80=A6 zn</font></b></div><div><b><font face=3D"Courier New">v4: w1, = w2, w3 =E2=80=A6 wn</font></b></div><div><br></div><div>This way you can = stream your structs through the SIMD registers with minimal changes to = your = code.</div><div><br></div><div><br></div><div><br></div></body></html>= --Apple-Mail=_922ED4B5-F825-43DF-BF20-F469F3665F7B-- _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html