Make the benchmark compile successfully by GCC

[PragmaTwice]

The benchmark CANNOT be compiled successfully by either GCC (12.2) or Clang (14.0).

This PR makes the benchmark pass gcc and run successfully.

BTW, the SSO inline size of std::string in libstdc++ is 15 now (22 in libc++, maybe),
so the default SSO size of SIMDString in the benchmark is not fair to be compared with std::string.

Also, the only use of SIMD in the whole project is a handwritten memcpy: this is strange,
because memcpy in glibc, for example, is highly optimized (handwritten assembly with SSE2/AVX2 instructions),
so I find it hard to believe that such a very trivial toy memcpy could be more efficient.

IMHO this project is more like an assignment from a random college student than a proven product in a company.

[PragmaTwice]

pos here is an iterator (aka const char*), so it cannot be added to another const char* (m_data).

IMHO it is a logical error (and also a compile error).

[linwansong]

This has been fixed as of 8495257

[vxw77]

They also have a bug in the implementation #3

[MBkkt]

If we talk about memcpy I think their main target is windows libc.
And on windows is common to replace it.
microsoft/mimalloc#201
But yes not sse :)

Also if we talk about glibc It can be worse for very short memcpy because of it's optimized for big sizes
https://research.google/pubs/pub50338/
Here some interesting and relatively new research about it

[linwansong]

BTW, the SSO inline size of std::string in libstdc++ is 15 now (22 in libc++, maybe), so the default SSO size of SIMDString in the benchmark is not fair to be compared with std::string.

The whole point is that we allow for a larger buffer size than std::string. Different string libraries are good for different use cases. As it says in the README.md

SIMDString is designed and benchmarked for the usage patterns found in games and other real-time 3D applications. It may perform less well and even underperform std::string for applications with different usage patterns.

If you want an exact apples to apples comparison, use SIMDString<16>.

Also, the only use of SIMD in the whole project is a handwritten memcpy: this is strange,

Since SSE instructions can only be performed on 16-byte aligned memory, we can only perform SSE memcpy on memory that we can guarantee is 16-byte aligned. SSE memcpy on heap storage is possible, but it requires that heap memory also be 16-byte aligned, which we're not requiring.

because memcpy in glibc, for example, is highly optimized (handwritten assembly with SSE2/AVX2 instructions),
so I find it hard to believe that such a very trivial toy memcpy could be more efficient.

To repeat what @MBkkt said, this isn't true for all versions of libc. memcpy would also run faster in this case because the buffer is 16-byte aligned.

[luizpara]

Also, the only use of SIMD in the whole project is a handwritten memcpy: this is strange

@PragmaTwice you are absolutely right. And worse - that handwritten memcpy:

(1) is used only for short strings stored in the stack (not for the actually problematic ones, the ones allocated to the heap);
(2) it boils down to loading 2 char arrays within 2 __m128i (the copied array and the destination array), assigning elements of one array to the other and then assuming the compiler will vectorize.

IMHO this project is more like an assignment from a random college student than a proven product in a company.

This is indeed a very strange repository, full of bugs and based on a naive and trivial usage of SIMD.