Thread 106495377

And some retards still believe the compiler will optimize everything for you.

Show godbolt output

>>106495382
No, do it yourself

>>106495388
I don't care enough

>>106495501
>polish programmers

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

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

>>106495377 (OP)
Not idiomatic.
int s = std::reduce(arr, arr + cnt);

>>106495606
Not fastomatic.

>>106495377 (OP)
::qsort is slower than std::ranges::sort

>>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 (OP)
Experts don't even understand why structured bindings work the way they do or were designed that way

>>106495971
another noob retard

>>106495377 (OP)
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 (OP)
>#include
>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 (OP)
nigger it's 2k25 and you're still arguing on c/c++? christ

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

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(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 (OP)
>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 (OP)
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 (OP)
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 (OP)
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.

>>106497094
anyone who says that can't be trusted to do it correct.

>>106496960
>the first function may invoke undefined behavior if 'arr' has more than 32767 elements
Why?

>>106495377 (OP)
Not OP, but I benchmarked it.
I made sure to randomize cache between runs.
I also added another option which is using spans, but accumulating by using std::reduce, and guess what on fast optimization, std::reduce caused spans to be just as fast as the C method, but it was a close race.
==> result_o0 <==
Slow Elapsed (s) 6.7619e-05s
Fast Elapsed (s) 2.033e-05s
Slow with std::reduce Elapsed (s) 7.1959e-05s

==> result_o1 <==
Slow Elapsed (s) 2e-07s
Fast Elapsed (s) 9e-08s
Slow with std::reduce Elapsed (s) 3.18e-06s

==> result_o2 <==
Slow Elapsed (s) 2.1e-07s
Fast Elapsed (s) 5e-08s
Slow with std::reduce Elapsed (s) 1e-07s

==> result_o3 <==
Slow Elapsed (s) 1.9e-07s
Fast Elapsed (s) 1e-07s
Slow with std::reduce Elapsed (s) 8e-08s

==> result_ofast <==
Slow Elapsed (s) 2e-07s
Fast Elapsed (s) 8e-08s
Slow with std::reduce Elapsed (s) 5e-08s

==> result_os <==
Slow Elapsed (s) 2.1e-07s
Fast Elapsed (s) 8e-08s
Slow with std::reduce Elapsed (s) 1.1e-07s

>>106497562
This is the code I used with g++ as -std=c++20
#include
#include
#include
#include
#include

int fast(int *arr, int cnt)
{
int s { 0 };
for (int i = 0; i < cnt; ++i)
{
s += arr[i];
}
return s;
}

int slow(int *arr, int cnt)
{
int s { 0 };
for (int x : std::span(arr, cnt))
{
s += x;
}
return s;
}

int slow_with_std_reduce(int *arr, int cnt)
{
auto span_of_arr { std::span(arr, cnt) };
return std::reduce(span_of_arr.begin(), span_of_arr.end(), 0);
}

void __attribute__((optimize("O0"))) randomize_cache()
{
const size_t bigger_than_cachesize { 10 * 1024 * 1024 };
static long *p { new long[bigger_than_cachesize] };

for (int i = 0; i < bigger_than_cachesize; ++i)
{
p[i] = rand();
}
}

to be continued

>>106497588
int main()
{
using namespace std::chrono;

const size_t test_arr_size { 5000 };

int test_arr[50000];

for (size_t i = 0; i < test_arr_size; ++i)
{
test_arr[i] = rand();
}

randomize_cache();

const auto test_arr_ptr { reinterpret_cast(test_arr) };

const auto slow_start { steady_clock::now() };

const auto slow_result { slow(test_arr_ptr, test_arr_size) };

const auto slow_stop { steady_clock::now() };

randomize_cache();

const auto fast_start { steady_clock::now() };

const auto fast_result { fast(test_arr_ptr, test_arr_size) };

const auto fast_stop { steady_clock::now() };

randomize_cache();

const auto slow_with_std_reduce_start { steady_clock::now() };

const auto slow_with_std_reduce_result { slow_with_std_reduce(test_arr_ptr, test_arr_size) };

const auto slow_with_std_reduce_stop { steady_clock::now() };

const duration elapsed_slow { slow_stop - slow_start };

std::cout << "Slow Elapsed (s) " << elapsed_slow << '\n';

const duration elapsed_fast { fast_stop - fast_start };

std::cout << "Fast Elapsed (s) " << elapsed_fast << '\n';

const duration elapsed_slow_with_std_reduce { slow_with_std_reduce_stop - slow_with_std_reduce_start };

std::cout << "Slow with std::reduce Elapsed (s) " << elapsed_slow_with_std_reduce << '\n';
}

>>106497595
I just realized I used the wrong array size, let me fix it.
==> result_o0 <==
Slow Elapsed (s) 0.000667988s
Fast Elapsed (s) 0.000200509s
Slow with std::reduce Elapsed (s) 0.000713617s

==> result_o1 <==
Slow Elapsed (s) 2e-07s
Fast Elapsed (s) 1e-07s
Slow with std::reduce Elapsed (s) 2.245e-05s

==> result_o2 <==
Slow Elapsed (s) 2.5e-07s
Fast Elapsed (s) 1e-07s
Slow with std::reduce Elapsed (s) 1e-07s

==> result_o3 <==
Slow Elapsed (s) 2e-07s
Fast Elapsed (s) 7e-08s
Slow with std::reduce Elapsed (s) 6e-08s

==> result_ofast <==
Slow Elapsed (s) 2e-07s
Fast Elapsed (s) 1e-07s
Slow with std::reduce Elapsed (s) 7e-08s

==> result_os <==
Slow Elapsed (s) 2.2e-07s
Fast Elapsed (s) 7e-08s
Slow with std::reduce Elapsed (s) 8e-08s

>>106497615
Used this as fix to main
const size_t test_arr_size { 50000 };

int test_arr[test_arr_size];

for (size_t i = 0; i < test_arr_size; ++i)
{
test_arr[i] = rand();
}

>>106497615
One last fix I swear, so I checked my assembly output because those numbers seemed too low, and the compiler had reordered my now statements. So I fixed that, here are the new results:
==> result_o0 <==
Slow Elapsed (s) 0.000699038s
Fast Elapsed (s) 0.000200809s
Slow with std::reduce Elapsed (s) 0.000640428s

==> result_o1 <==
Slow Elapsed (s) 4.263e-05s
Fast Elapsed (s) 5.702e-05s
Slow with std::reduce Elapsed (s) 2.302e-05s

==> result_o2 <==
Slow Elapsed (s) 1.836e-05s
Fast Elapsed (s) 1.716e-05s
Slow with std::reduce Elapsed (s) 2.441e-05s

==> result_o3 <==
Slow Elapsed (s) 1.87e-05s
Fast Elapsed (s) 2.2059e-05s
Slow with std::reduce Elapsed (s) 2.381e-05s

==> result_ofast <==
Slow Elapsed (s) 1.5909e-05s
Fast Elapsed (s) 1.99e-05s
Slow with std::reduce Elapsed (s) 2.233e-05s

==> result_os <==
Slow Elapsed (s) 4.642e-05s
Fast Elapsed (s) 4.172e-05s
Slow with std::reduce Elapsed (s) 2.358e-05s

>>106497588
Why do you niggers use #include? Is it still 1800?

>>106497988
and the corrections to main is this
template
__attribute__((always_inline)) inline void do_not_optimize(const T &value) {
asm volatile("" : "+m"(const_cast(value)));
}

int main()
{
using namespace std::chrono;

const size_t test_arr_size { 50000 };

int test_arr[test_arr_size];

for (size_t i = 0; i < test_arr_size; ++i)
{
test_arr[i] = rand();
}

randomize_cache();

const auto test_arr_ptr { reinterpret_cast(test_arr) };

const auto slow_start { high_resolution_clock::now() };

do_not_optimize(test_arr_ptr);
const auto slow_result { slow(test_arr_ptr, test_arr_size) };
do_not_optimize(slow_result);

const auto slow_stop { high_resolution_clock::now() };

randomize_cache();

const auto fast_start { high_resolution_clock::now() };

do_not_optimize(test_arr_ptr);
const auto fast_result { fast(test_arr_ptr, test_arr_size) };
do_not_optimize(fast_result);

const auto fast_stop { high_resolution_clock::now() };

randomize_cache();

const auto slow_with_std_reduce_start { high_resolution_clock::now() };

do_not_optimize(test_arr_ptr);
const auto slow_with_std_reduce_result { slow_with_std_reduce(test_arr_ptr, test_arr_size) };
do_not_optimize(slow_with_std_reduce_result);

const auto slow_with_std_reduce_stop { high_resolution_clock::now() };

Micro-benchmarking at this level isn't very useful.

>>106498064
I know, I just wanted to show that C++ even when abstract is still good at doing stuff.

assuming this isn't bait. even without compiler optimizations the code will be almost identical in performance. a span is a lightweight objects, and range based for loops are also pretty light weight. you have using two abstractions in the second example, iterators and spans, but some could argue it is easier to read. i guess if it matters that much don't use them?

>>106496681
>Beef,
is this an anti-jeet language?

>>106497988
don't c++ fags know how to print nanoseconds?

>>106498306
It's anti-vegan.

>>106498317
I was being lazy and I wasn't sure if the thread would unalive before I could put my autism on display okay.

>>106495501
>>106495526
What book is this from?

>>106495501
muh zero-cost abstraction

>>106496627
put the length first

OP is gay

>>106498533
mfw the compiler isn't smart enough to just emit
mov edi,std::cout
mov esi,10
call std::ostream::operator<<(int)

shit lang

>>106498560
>i dont know what constness is
>proceeds to language in pointless language flamewars
hang yourself you worthless nigger faggot

>>106498696
>language in pointless
engage in*

>>106498696
your mythical smart compiler should be able to look at the whole program and see nothing writes to your array bro just pretend its const bro

>>106498705
>bro just pretend its const bro
thats what youre doing
>should be able to look at the whole program
yea, its called lto
>your mythical smart compiler
there are only a handful of actually good compilers, and this is one of them.

kys nigger faggot. go back to jeetscript

>>106498533
>>106498560
Should have eliminated one mov but.

>>106498874
Wait, I'm retarded.
ecx gets overwritten.

>>106495377 (OP)
C++ is faster than any other language if you never use stl headers.

I never felt the need to make simple for loops like that more readable.

>Build succeeded with 123 warning(s) in 10.4s
Not my problem

>>106496659
>sepplesniggers are incapable of reading
makes sense, your IDE automates half your workflow these days and you just plug other people's nightmare template libraries into eachother for a living.

>>106499307
I don't use an IDE.

>>106498874
what disassembler?

>>106495377 (OP)
https://www.youtube.com/watch?v=B2BFbs0DJzw

>>106495971
IS THAT A RAW POINTER I"M GONNNANANANANANANANNANANANANANSFJDNSAOFCHNJIOSVFHJNPO(WJNCVIENVIKNVONILCNEIOVFJEPOIRVHP(HFJ O(HJDPINFVILENKILVBNDJ(ERFHOFVHINRFIRBN(PIEHV

>>106495377 (OP)
Why don't you pass the fucking array cnt.

>>106501029
you forget the Segmentation fault (core dumped)

>>106501486
Using that meme outs you as a bad programmer. What is your mind apple score?

>>106496700
kill yourself

>>106501505
5

>>106495377 (OP)
>In C++, a span is a lightweight, non-owning view over a contiguous sequence of objects.
holy mental retardation
now the committee wants iterators for arrays

this stopped being funny a while ago

>>106501568
it's just a pointer and a length. stop being a dumb retard.

>>106501585
then why is it slower you demented faggot?

>>106500956
>>106498874
Yeah, I'm also curious

>>106501636
it isn't, dumb retard

>>106501636
Because you're an incompetent nigger who doesn't know how to tell compiler to optimize it.
Anything benchmarked without
>-flto=1
>-march=native
>-DNDEBUG
>-O3
is worthless and not even worth analyzing or considering, kill yourself

>>106501649
>youre using it wrong
no, its shit
>>106501645
yes it is you retarded autismo trash >>106501649

>>106501656
dumb retard

>>106501661
>t. rustranny monkeyposter
youre supposed to be b&

>>106501656
Yes, you are in fact using it wrong, you stupid nigger. Compiler does what you tell it to, and by default you aren't trying to build a fully optimized release for specific hardware ignoring all possible costs like potential cache thrashing due to code bloat or platform incompatibility.

>>106501665
obsessed

>>106501670
>t. sub 80 iq brown

>>106501668
no
its a shit implementation made by mental retards that has no point in the first place

of course a handicapped nigger like yourself is gonna defend that

>>106501690
>no arguments
dumb obsessed retard

>>106501690
Of course a handicapped nigger will ship -O0 build to production because it's "fast enough" and he didn't have to learn anything.
Oh wait, you aren't gonna ship anything ever, unemployable retard.

>>106501698
>digression
nothing is gonna save you from the fact that this shit has no right NOT to dissolve like syntactic sugar

sepples is a flaming pile of garbage

>>106501668
You are 100% wrong and you are 200% braindead.

>>106501649
OP here, you are another braindead noob retard, get the fuck out of here.

>>106501707
>>106501729
>>106501741
all me

>>106501743
*vaguely self erotical nuUHHH*

>>106501707
It does when you tell it to, now explain why it should when you didn't tell it to.

>>106501992
because it receives the same parameters as a for loop.
theres zero fucking excuse to offset that effort to the end user
in fact
theres zero excuse for an alternate interface to begin with
instead of forcing upon the user to use fukken span for lifetime negritude reasons, this should be inferred by the compiler

its bad craftsmanship
and its indefensible even from the safety negritude perspective

why would you leave the possibility to the s er to make an oopsie if your overaching goal is safety?
the result is that theres another interface to learn, which adds complexity to an already bloated framework
and THAT does FUCK ALL for safety, in fact, its counter productive, negating the benefits of the whole idea and the work thats been invested in it with the same stroke

this is motherfucking retarded
and i see autistm' signature retardation in the complete inability to comprehend ergonomics

>>106502353
>the possibility to the s er
*the possibility to the user

>>106502353
>Compiler doesn't optimize with no optimizations
Which part of this is unclear to you, nigger?

>>106502405
nono
this is perfectly clear

where you cant comprehend shit
as a broken fucken detritus of a mind aka autistic
is that this construct should have zero runtime costs because its internals are operating beyond the scope of the language

but you cant fucking understand basic abstraction for shit
because youre autistic
and thus
mentally retarded

>>106498560
the array is extern, so it cannot assume that the data is the same that it was initialized with. make it static and it can.

>>106502426
It has 0 runtime cost when you enable optimizations, which part of this isn't clear to you, dumb nigger?
Also consider formatting your posts better so there's no cost to parsing them.

>>106502405
ill make it extra clear bc youre a retard with zero (0) visualization abilities and even less mental flexibility
so i have to painstakingly explain everything to you step by fucking step:

>because its internals are operating beyond the scope of the language
and
>it gets the same parameters as a for loop
it can be substituted with a for loop and the magic can happen behind the scenes
because for the lifetime niggerdom bullshit the compiler can identify types with associated lifetimes syntactically

and just do the fucking switch bw a for loop and a fucking span
no new interface needed
but im sure autistic mental retardation played a role
and the associated immature ego shit
and sepples ended up with another interface FOR FUCKING LOOPS
AND WHICH IS SHITTER THAN THE ORIGINAL, WITH A RUNTIME COST BC WHY NOT

this is a complete quality assesment failure

>>106502462
Your shitty formatting and inability to spell out whole words is tiresome and I didn't read your post. Learn English first before you tell me about C++, nigger.

>>106502438
>It has 0 runtime cost when you enable optimizations
>digression

BECAUSE THE COMPILER REWRITES YOUR FUCKING CODE YOU DUMB NIGGERFUCK
>WRITE INTERNALS FOR SEPPLES
>AAHH FUCK IT THE COMPILER WILL TAKE CARE OF THAT

HOW ISNT THIS NIGGER TIER?

>>106502467
span isn't internal, it's implemented in C++ you dumb nigger, anybody can write their own.

ZERO FUCKING QUALITY ASSESMENT
>AH FUCK IT LETS PUSH IT TO PROD ANYWAYS

>>106502474
then its a user lib
and then why the fuck did you post it on /g/ then?

> silence
yeah shut the fuck up retardo autistic trash
especially after this
>Learn English first before you tell me about C++,
nigger
this isnt /lit/, this is /g/
you fucking retarded piece of shit (aka autist)

Calm down, Ranjeet.

>>106502556
im whiter than you
and your genes are fucked, non human

>>106502561
You're so brown that having to add one commandline option to solve your non-issue makes you seethe in pure rage.

>>106502581
>n-no, u
peak 80 iq
everyone clap now

>>106500956
>>106501640
Beef IDE's built-in debugger.

Amazing difference in execution speed depending on if a variable is named A or named Z.

>>106502467
The "fast" code is "faster" literally only when compiler rewrites the code

>>106503020
no.
the compiler is a copilot
it can fix some of your fuckups.
but it wont make you anywheere near as good as an actual pro.

QA failure
fukken sepples is a NIGGER joke

>>106503020
>compiler rewrites the code
yes. that's the purpose of a compiler.

and not a joke which punchline is "yeah but he was bwaawn, hahah"
no
its a joke as told by a fucking NIGGER
and a fucking braindamaged one
a NIGGER who takes grack
takes massive amounts of it
and wwho has smoken all the va rioust types of bread AND of salt there is comercially available

>no challenge
autismo rabble shute the fuck up
AS THEY SHOULD

>>106502629
Thanks

>>106497160
what the fuck does this image refer to

>>106507076
thank you