Demos of the SWAR library

[thecppzoo]

Reviewers: please, in the case you're satisfied with the PR up to a certain commit, please state your satisfaction in a comment. If the other reviewer is also satisfied as of the same commit as you, then please merge up to that commit to the master branch. This is more "agile"

[jamierpond]

will run this on my M1 machine later on today, but i think you'll need another layer here of

if (${TARGET_PLATFORM} == X86_64) 
    // enable avx
endif()

will find the code i've used before which will do this only when AVX is actually detected on the machine, but i think this will need to be updated to work on ARM

[thecppzoo]

Wait, doesn't XCode in M1 allow you to cross compile transparently to x86-64?

[jamierpond]

Oh I see you're assuming it will make the dual ARM+Intel binary ?

[jamierpond]

I think it would be cool to try and keep the code (where possible) architecture independent, otherwise could become a pain to try and go back and wrangle it to work in the future.

[Scottbruceheart]

Keeping code as arch independent as possible seems critical if our objectives are to work everywhere. Which I think they are.

[thecppzoo]

Yes, friends, architecture independence is a primary objective. But we have the freedom to draft and experiment architecture specific.

[Scottbruceheart]

Did I overlook the tests for the added functions that act as evidence that the benchmarks are doing the right thing?

The GCC strlen is painfully hard to read. I much prefer our methods.

SWAR atoi comment doesn't read easily to me (I had to go reread Lemire's). Needs a rework.

If we're intending this as demo code, that directly means we want other SWE to read and understand and believe correctness and be impressed with as little cognitive effort on their part as possible.

[thecppzoo]

Did I overlook the tests for the added functions that act as evidence that the benchmarks are doing the right thing?

Yes, as of this commit, in catch2swar-demos.cpp:
https://github.com/thecppzoo/zoo/pull/69/files#diff-286f2a6168f774ab1f7b54d49d8549b8c721a01199a226197f6a752573790674

SWAR atoi comment doesn't read easily to me (I had to go reread Lemire's). Needs a rework.

If we're intending this as demo code, that directly means we want other SWE to read and understand and believe correctness and be impressed with as little cognitive effort on their part as possible.

This is not advertising nor marketing. These demos are the necessary complement to the code to avoid frustrations of not being able to see things being used and to provide us feedback to drive further development.

What is the comment that doesn't read easily?

[thecppzoo]

The GCC strlen is painfully hard to read. I much prefer our methods.

Thanks, but your comment is entirely subjective.

What is the lesson to be learned from GCC's code, or from "our methods"? GCC's code had a programming technique lurking in it that took me three attempts in three years to fully grok. It has several "low-hanging-fruit" performance mistakes, and our code implicitly showcases the superiority of little-endian encoding for this type of task.

I think that this deserves a whole essay to discuss in proper detail and context, it would be helpful to know your opinion with full articulation of its points.