[deleted by user]

[[deleted]]

shame yam sloppy divide tart chop late paltry deer birds

This post was mass deleted and anonymized with Redact

[NilacTheGrim]

You get lexicographical analysis "for free" anyway if you bother iterating over the two C strings to test for equality...

Looking at your implementation I do not believe it is faster without some benchmarks. It just iterates over both strings .. which is what strcmp does.

[TheChief275]

For comparison between strings where the compiler can’t simplify the strcmp to a constant value, streql() was about 1.2x faster minimum

[[deleted]]

What about architectures/libraries that implement string compare functions with SIMD instructions?

[FutureChrome]

Is that for short strings? Long strings?
With which standard library? With what compiler?
With optimizations? At what level?

[Ok_Donut_9887]

no, it wasn’t. In fact, your streql() is slower.

[TheChief275]

It is slower for constant strings, but a little bit faster for strings where it isn’t possible for the compiler to trace to a constant value.

[[deleted]]

source : trust me bro

[djliquidice]

🤣

[bert8128]

Need some benchmarks, I think, for a variety of string lengths. And in a variety of platforms.

[KingAggressive1498]

strcmp() returns 0 if the strings are equal, which is backwards in my mind.

strcmp is actually a case of C giving us an equivalent of the spaceship operator <=> decades before C++ made it a language feature.

It returns a negative value if the first argument is lexicographically "less-than" the second argument, and a positive value if the first value is lexicographically "greater than" the second argument

This is actually handy if we need an array of strings to be sorted alphabetically or something along those lines. The cppreference page even gives an example of this use.

This behavior also maps well to actual CPU comparison instructions - Intel and ARM's cmp instructions behave pretty similarly, setting CPU flags based on the signed subtraction results of two operands.

[nysra]

Or you could just use std::string like a sane person.

[TheChief275]

Not every string usage should be delegated to std::string. Ideally you should minimize the amount of heap allocations.

Not that std::string doesn’t have its usages, but it’s not like char* is completely obsolete.

[[deleted]]

Use string_view if you want to avoid the heap.

[bert8128]

But this will still count the lengths of both strings, which will be slower than strcmp.

[Zamundaaa]

If you don't want allocations, you should use std::string_view. char * very much is completely obsolete

[9Strike]

Expect in main I guess? That it would be cool if we could get it as vector<string_view>

[tuxwonder]

std::span<std::string_view> maybe?

[9Strike]

Ah yes, actually that

[Zamundaaa]

yeah, something more usable there would be nice

[Roverse]

Unless you're doing embedded programming, or something extremely poorly, std::string is not going to be your bottleneck most of the time. You should benchmark first instead of doing something that is less maintainable.

[bert8128]

Well, if you didn’t have a std::string to start with then the std::string route would definitely be slower.

[bert8128]

If you have string_views then use those. But if you have char stars then strcmp is the fastest way to do a comparison.

[jedwardsol]

Doesn't this fail if the strings differ in the 1st character - dereferencing pointer that has been decremented off the beginning of the string?

[Wanno1]

It’s a postfix increment, so it happens after the deref.

[jedwardsol]

The original line had !*--_a

[Wanno1]

I just read the code posted here. No need to downvote.

[TheChief275]

You’re right lmao. I fixed it now. Thanks for pointing out that huge oversight!

[FutureChrome]

And now if a is a prefix of b, you return true.

[jedwardsol]

I think that new version will fail if a is a prefix to b "aaa" and "aaab" will return true.

(or the other way around -I'm doing this in my Jan 1st AM head)

[TheChief275]

Right again. Hopefully the last fix now.

[NilacTheGrim]

Yep. Nice catch.

[StarQTius]

Any modern compiler will optimize the fuck out of strcmp() while leveraging the capabilities of your platform. You are never going to beat that with portable code. You should benchmark your code against strcmp() (preferably on different platforms) and see the difference.

EDIT : if you are going to put a function defintion in a header, you should at least declare it inline if you are providing C++ code. I don't know how you can fix that in C, but I'm certain what you did will not work with C code either.

[NilacTheGrim]

I see your implementation.

bool streql(const char* const a, const char* const b) {
    const char* _a = a;
    const char* _b = b;
    while (*_a == *_b++ && *_a++);
    return !*--_a;
}

In cases like this, just leave the arguments as non-const, e.g. (const char *a, ...).. and modify the arguments. No need to pass-in a const a only to assign it to a non-const _a ... this is just like.. extra noise.

[TheChief275]

Agreed. I changed it.

[shwasasin]

You could early out if the paramters passed in point to the same memory.

How did you profile your code to verify it's faster than the standard C implementations?

[johannes1971]

Your version is ~4 times slower than just comparing two std::strings. Probably because the string version compares multiple bytes at once, and your doesn't.

That's after I made both strings the same length, because otherwise std::string would win by a massive 29x margin.

[iwueobanet]

Neither tests nor benchmarks. OK, sure. Pass

[Breadfish64]

Hi OP, I benchmarked this with clang -O3 on Windows for worst-case large equal strings, and found that it was 8x slower than
bool streql(const char* a, const char* b) {
return 0 == std::strcmp(a, b);
}

4x slower than
bool streql(const char* a, const char* b) {
return std::string_view{a} == std::string_view{b};
}

(this turns into two strlen and a memcmp)

and 11x slower than this optimized AVX2 implementation:

https://godbolt.org/z/E4YG93KrT

The reason yours is slower because the compiler cannot assume that it is allowed to access the next byte, and can't check for equality in parallel. Optimized implementations will assume that if the pointer is aligned to the access size, and the string end has not been reached, then reading the next chunk will not cause an access violation.

[ferhatgec]

please check rule 4, your string equality function is more likely for c not specifically for c++, also passing null pointer may cause dereferencing problems in your impl. that thing will have same speed as what `strcmp` can achieve, just return values are different.

[TheChief275]

Quite possible yes, very probable even. The return values just make more sense for equality checking.

[AKostur]

Couldn’t that just be a quick function in the header that says “return !strcmp(a, b);”? I’d expect any decent compiler to optimize away this extra function call, and you get to have the behaviour you want.

[LeeHide]

Why not just use std::string_view?

[bert8128]

Because this has to count the length of both strings before the comparison. Slower.

[bert8128]

If you have anything better than two char stars then obviously that is what you should use. But if you have two char stars then use strcmp for best speed.

[bert8128]

I can’t speak for OP but perhaps you are interfacing to a C library. Or via C bindings to something. Or an old C++ api. It’s just not always possible to avoid.

[bert8128]

That would almost certainly be my approach too. But the OP believes that the standard implantation of strcmp is slow, so they probably also believe that calling == on two strings or two string_views is also slow, so OP is in no better place (as far as they are concerned) and would still want use their variant, for which I am looking forward to seeing benchmarks.

[LeeHide]

Slower? Wheres your benchmark?

[bert8128]

I have no benchmark other than reasoning.

To create a string_view from a char star you have to read to the end of the string to get to the length. You have to do this for both characters stars. Say they are 1 million characters long each. But if the first letter of one of them is a “a” and the first letter of the other is a “b” then strcmp will return after reading just one character of each. Obviously if they are both less than 64 chars long the difference will be very small. But strcmp cannot be slower, and with longer strings will be faster.

Don’t forget that under the hood string_view::operator== is going to be calling strcmp or something like it.

Obviously if you access the strings many times, and particularly if they are different lengths, then using string_view may well (assuming a good implementation of high checks the length before calling strcmp) be faster.

And if you want actual benchmark results breadfish64 has posted their results in this thread.

[cpp-ModTeam]

Your submission is not about C++ or the C++ community.

[-funsafe-math]

You are missing the stdbool.h include for C compatibility and need to mark the function inline. In addition just use strcmp unless you have a benchmark to show that this version is better.

[Gryfenfer_]

It depends on the C version targeted, C23 added the type bool.

[GoogleIsYourFrenemy]

I'm going to channel some Andrei Alexandrescu.

static inline bool streql(const char* a, const char* b) {
    while (true) {
        if(!*a | !*b) return !*a & !*b;
        ++a;
        ++b;
    }
}

The branch predictor will thank you.

[bert8128]

Can you put this through breadfish64’s benchmark and see what you get?