Cfags and premature pessimizers BTFO

Attached: Screenshot.png (554x1078, 208K)

Other urls found in this thread:

travisdowns.github.io/blog/2019/08/26/vector-inc.html
twitter.com/SFWRedditGifs

Of course. Mature programmers care more about type-safety.

Its funny because of glibc's ass retarded strlen() with the long words and out of bounds access.

DEALLOCATE THIS

Attached: 1537096871542.jpg (1679x586, 164K)

>Cfags
>std::vector
Fucking retard.
But it's always been well known that the native size of the computer (usually represented by int) is faster. That's literally why integer promotion is in the language.
char/short is only used for storage reasons.

If anyone wants to read.

travisdowns.github.io/blog/2019/08/26/vector-inc.html

>unironically replying on autovectorization in 2019
either use intrinsics or ispc

>CFags
>Picture is talking about C++

People use variables that are less than a native word to conserve on space, not for speed. Your compiler may even optimize it away if you allow it.

>>Picture is talking about C++
With the naive C approach that the programmer knows everything and muh micro ops dude CACHE lmao

>everyone who has replied so far has failed to notice the reason it is slower is because C is retarded about char*, not because of muh native integer sizes.

Please don't spew imagined up bullshit on public forums thank you.

char* aliasing has many genuine uses, don't blame the language for what the programmer or retarded compiler did.

If char * aliasing didn't exist, it would be impossible to write any memcpy-like function in standards conforming C.

How is this news to anyone? Yes 32bit is faster on 64bit and guess what. 64bit is even faster than 32. With 8bit you have to split your memory in many small segments and all of that takes time.

It has many genuine uses but the way it is implemented makes 8-bit integer types and even strings slow as shit because of a design issue that could have easily been avoided with mild psychic powers.

Wrong, retard.

Google keywords recommended for your learning: SIMD, SWAR, vectorization

Also the real bottleneck for most programs is memory bandwidth and overflowing cache as problem sizes increase.

You can deal with 8x as much data before hitting the slow-down point with 8-bit integers.

8x bigger problem sizes 8x faster. God bless 8-bit integers and fuck C++ for making them impossible to use.

Looks like it's in stable bootloop.

>values the size of processor registers are faster than data with less/more bits

woooooooow broken computing mechanics

>not using SIMD

Attached: 1565974148111.jpg (125x111, 2K)

Then don't use C. How come c++ has generic memcpy that just works?

C++ is not a language for cache optimisations and other garbage. There is no cache or register keyword in C++, so stop writing unreadable code. Go write assembly if you want a locked-down autistic program.

There is no x86-64 SIMD on arduino and raspberry pie so you couldnt compile, making std::vector not.very std.

yeah but arm has it's own simd too. just write a few optimized implementations for the platforms you want and a generic one for the rest.

Even if we ignore everything others have said so far, isn't data in C word aligned? So uint_8 is still the word size even though most of it is just padded 0s.

No, each variable is aligned to sizeof() itself. Thats why we place variables largest to smallest in structs to reduce padding

Of course it is lmfao, might even be faster with 64 bit integers. The computer works with 32b or 64b go any lower and the loop will slow down because extra ops need to be performed

As for the retards shouting but muh SIMD! and blablabla. It makes no fucking difference, the computer is designed to work with 32 bit or 64 bit so that is going to be faster, end of story.

People who are shouting smid wish that there would be no compatibility aka retards