Show godbolt output

>>106495382
No, do it yourself

>>106495388
I don't care enough

File: 0_billy-butcher-in-the-boys.jpg (39 KB, 810x539)

39 KB JPG

>cnt

File: Screenshot_2025-09-05_23-13-14.png (49 KB, 627x363)

49 KB PNG

>>106495377

File: Screenshot_2025-09-05_23-15-36.png (89 KB, 628x386)

89 KB PNG

>>106495501

File: aa.png (31 KB, 533x393)

31 KB PNG

>>106495501
>polish programmers

>>106495377
> STL makes slow loops
It has always been thus.
Loop is too big to fit into a cache-line.

>>106495377
everything C++ does to get away from its "legacy" "deprecated" C core just makes it worse and worse

>>106495377
Not idiomatic.

int s = std::reduce(arr, arr + cnt);

File: s.png (8 KB, 492x51)

8 KB PNG

>>106495606
Not fastomatic.

>>106495377
::qsort is slower than std::ranges::sort

File: 1757109617.png (47 KB, 607x475)

47 KB PNG

>>106495382
even at -O1 it optimizes to similar assembly. the only difference being the loop counter,
you can get identical assembly by changing it to

for (int* a = arr; a != arr + cnt; ++a)
       s += *a;

op using -O0 and then complaining about unoptimized code

>>106495377
Experts don't even understand why structured bindings work the way they do or were designed that way

>>106495971
another noob retard

>>106495377
What compiler, optimisation level and list did you use to run the benchmark? Using clang++ 19.1.7 with -O2 on a list of random numbers, "slow" is much faster than "fast" for short lists and they become roughly equivalent as the list grows.

>>106496356
>is much faster
Sorry, I read my table incorrectly. They're roughly equivalent regardless of list length.

>>106495377
>#include <span>
>uses a C++ bloated template class just for the ability to do fancy for loops
>complains that its slow
Modern C++ and Rust are all about type masturbation.
If everyone thinks that doing

struct MyType {
    void* data;
    size_t length;
};

is bad, buggy and makes the code unreadable then performance is the least of the concerns here.
Disgusting.

>>106495377
nigger it's 2k25 and you're still arguing on c/c++? christ

>>106495377
>>106496627
>using #includes instead of imports
kys
>using void* instead of templates
kys

File: fastslow.png (58 KB, 1454x691)

58 KB PNG

In Beef, they both generate the same assembly when you force inline the span.

[Export, LinkName("Fast")]
static int Fast(int* arr, int count)
{
    int s = 0;
    for (int i = 0; i < count; ++i)
    {
        s += arr[i];
    }
    return s;
}

[Export, LinkName("Slow")]
static int Slow(int* arr, int count)
{
    int s = 0;
    for (int x in Span<int>(arr, count))
    {
        s += x;
    }
    return s;
}

>>106496681
>>106495526
>>106495501
delete this post right now, you're completely ruining my fucking thread you fucking anti-fun faggot

>>106495377
>slow c++ function is 60% slower than fast c++ function (trust me bro)
absolute retard

>>106496647
It's 2025 and the noob retards still haven't fixed their compilers.

>>106496700
You don't even understand the posts you quoted, +1 noob retard.
>>106496703
Noob retard.

the first function may invoke undefined behavior if 'arr' has more than 32767 elements, the second will never invoke ub.
good luck looping over the bytes of an image in a portable manner.
ps both compile to the same assembly with the right compiler flags; if you don't know what you're doing, C and C++ are not for you.

>>106495377
the point of stl is for the garuntees, not for the speeds. The truth is that whichever one either encourages cache filling or whichever one engages simd instructions is going to be more performant. But I'd like to see whether it really is faster or not when speed optimization is turned on.

>>106495377
C++ compilers have never compiled index based loops and pointer based loops into identical code. They are different.

>>106496960
You are the most stupid of all noob retards in this thread. Congratulations.

>>106497026
Why do you keep saying noob retard?

>>106497039
because he has autism. ignore his thread starting now.

>>106496700
Beef is a better OOP lang than C++ every wish it could be.

>>106495377
Micro benchmarking can be very difficult to do correctly and even experts fuck it up sometimes. Judging by what you're benchmarking and your attitude, I can safely say I don't trust you to have the competence to have done it correctly.

>>106497080
If you can't benchmark that you're a noob retard.