Thanks, the source of digest seems especially helpful. Ironically, I actually used only 10 or so lines with simd code in the package in a single function that is a bottleneck. It gives a very noticable performance boost, even with unaligned vectors, and something about directly using processor registers seems elegant to me. The article by Langdale and Lemire that you pointed to on your blog was also inspirational.
Unfortunately getting those 10 lines to reliably work on other machines looks like a long term project and the advice from Thomas that GCC on windows might decide to faultily optimize other code is a bit scary. I'll take the advice to heart and will not try to include simd code in any of my cran packages in the near future. I learned C and Cpp via R, like many people probably, and makefiles and portability have never come up until now so there's quite some learning ahead. At least I now have some good places to start. Thank you all for the help! Op wo 27 mrt 2024 om 12:27 schreef Dirk Eddelbuettel <e...@debian.org>: > > > On 27 March 2024 at 08:48, jesse koops wrote: > | Thank you, I was not aware of the easy way to search CRAN. I looked at > | rcppsimdjson of course, but couldn't figure it out since it is done in > | the simdjson library if interpret it correclty, not within the R > | ecosystem and I didn't know how that would change things. Writing R > | extensions assumes a lot of prior knowledge so I will have to work my > | way up to there first. > > I think I have (at least) one other package doing something like this _in the > library layer too_ as suggested by Tomas, namely crc32c as used by digest. > You could study how crc32c [0] does this for x86_64 and arm64 to get hardware > optimization. (This may be more specific cpu hardware optimization but at > least the library and cmake files are small.) > > I decided as a teenager that assembler wasn't for me and haven't looked back, > but I happily take advantage of it when bundled well. So strong second for > the recommendation by Tomas to rely on this being done in an external and > tested library. > > (Another interesting one there is highway [1]. Just packaging that would > likely be an excellent contribution.) > > Dirk > > [0] repo: https://github.com/google/crc32c > [1] repo: https://github.com/google/highway > docs: https://google.github.io/highway/en/master/ > > > | > | Op di 26 mrt 2024 om 15:41 schreef Dirk Eddelbuettel <e...@debian.org>: > | > > | > > | > On 26 March 2024 at 10:53, jesse koops wrote: > | > | How can I make this portable and CRAN-acceptable? > | > > | > But writing (or borrowing ?) some hardware detection via either configure > / > | > autoconf or cmake. This is no different than other tasks decided at > install-time. > | > > | > Start with 'Writing R Extensions', as always, and work your way up from > | > there. And if memory serves there are already a few other packages with > SIMD > | > at CRAN so you can also try to take advantage of the search for a 'token' > | > (here: 'SIMD') at the (unofficial) CRAN mirror at GitHub: > | > > | > https://github.com/search?q=org%3Acran%20SIMD&type=code > | > > | > Hth, Dirk > | > > | > -- > | > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
