Date: Fri, 13 Sep 2024 09:53:43 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Joe Schaefer <joesuf4@gmail.com> Cc: Pat Maddox <pat@patmaddox.com>, Alan Somers <asomers@freebsd.org>, Chris <bsd-lists@bsdforge.com>, Warner Losh <imp@bsdimp.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: The Case for Rust (in any system) Message-ID: <2D0F93DC-36DA-4FB9-BFD2-D7678EC03CD7@FreeBSD.org> In-Reply-To: <CAOzHqcJs2Ls9rG-X9%2Bjsc=Z2XHvh_eo=5jyFSaTDc6kUMK8vPg@mail.gmail.com> References: <CAOzHqcJ0rOR4CoL84WgZQNcgY2G9vuiHccE4XT_otJ2R51KJ3Q@mail.gmail.com> <2EE309BF-CE1D-48AD-9C53-D4C87998B4A0@freebsd.org> <CAOzHqcJs2Ls9rG-X9%2Bjsc=Z2XHvh_eo=5jyFSaTDc6kUMK8vPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_AB27066B-36F6-47DB-93E4-77C69043DC8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 13 Sep 2024, at 08:59, Joe Schaefer <joesuf4@gmail.com> wrote: >=20 > That=E2=80=98s because you are a dork.=20 In case you were wondering, that was the point when you lost all = credibility in this thread. > The point isn=E2=80=99t that calloc calls are faster than vector = allocations. The point is that by changing the way you deal with = arrays (as objects that manage their own size, versus managing the sizes = using up front preallocations and dealing with their growth yourself), = we can exchange function calls for pointer dereferences. And that=E2=80=99s precisely the change you get by calling .reserve with = the expected size. And the speedup tends to be exactly what you claimed = you got. David --Apple-Mail=_AB27066B-36F6-47DB-93E4-77C69043DC8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><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;">On 13 Sep = 2024, at 08:59, Joe Schaefer <joesuf4@gmail.com> = wrote:<br><div><blockquote type=3D"cite"><br = class=3D"Apple-interchange-newline"><div><meta charset=3D"UTF-8"><div = dir=3D"auto" style=3D"font-size: 1rem; font-style: normal; = font-variant-caps: normal; font-weight: 400; letter-spacing: normal; = orphans: auto; text-align: start; text-indent: 0px; text-transform: = none; white-space: normal; widows: auto; -webkit-text-stroke-width: 0px; = text-decoration: none; font-family: -apple-system, "helvetica = neue"; word-spacing: 1px; background-color: rgba(0, 0, 0, 0); = border-color: rgb(49, 49, 49); color: rgb(49, 49, 49);">That=E2=80=98s = because you are a dork. = </div></div></blockquote><div><br></div><div>In case you were wondering, = that was the point when you lost all credibility in this = thread.</div><br><blockquote type=3D"cite"><div><div dir=3D"auto" = style=3D"font-size: 1rem; font-style: normal; font-variant-caps: normal; = font-weight: 400; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; -webkit-text-stroke-width: 0px; text-decoration: none; = font-family: -apple-system, "helvetica neue"; word-spacing: = 1px; background-color: rgba(0, 0, 0, 0); border-color: rgb(49, 49, 49); = color: rgb(49, 49, 49);">The point isn=E2=80=99t that calloc calls are = faster than vector allocations. The point is that by changing the = way you deal with arrays (as objects that manage their own size, versus = managing the sizes using up front preallocations and dealing with their = growth yourself), we can exchange function calls for pointer = dereferences.</div></div></blockquote><div><br = class=3D"Apple-interchange-newline"></div><div>And that=E2=80=99s = precisely the change you get by calling .reserve with the expected size. = And the speedup tends to be exactly what you claimed you = got.</div><div><br></div><div>David</div><div><br></div></div><br></body><= /html>= --Apple-Mail=_AB27066B-36F6-47DB-93E4-77C69043DC8C--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2D0F93DC-36DA-4FB9-BFD2-D7678EC03CD7>