Why is söyoverflow like this

Attached: 1635692111917.png (1528x1628, 254.51K)

>gives very detailed answer
>BTFOs performance ricers
Yep, I'm thinking based.

zoomers are like 10 iq points lower on average than previous generations so you have to spoonfeed them everything and change the question they asked to make it relevant

>very detailed non-answer
Look at those updoots. Immeasurably based.

It seems like 90% of the questions on stackoverflow are a result of the XY problem

It seems like a very reasonable answer, what's your fucking problem?

it doesn't answer the question that was asked

>XY problem
Autism? Because I think autism. I mean it's pretty obvious.

The question was malformed, he's lucky it didn't get locked.
Faster how?

no, m3n are the probl3m

What's wrong? I can only see an average Any Forumsentooman in the pic.

Never have I read "Just try it out lol" written in such a faggy way

It clearly implies there is a performance difference, but it doesn't get into the details (memory density/cache utilization).
For someone dumb enough to ask this question this is probably the right level of depth to go into.

Also memory bandwidth, maybe a few others to.

It answers it well enough.
The OP is trying to prematurely optimize a c program, unless this program has been profiled, and a single hot loop is wasting all your cycles on the target plaform, there is no purpose in scrimping to save a few bytes or cycles.

No wait, what the fuck?
This is actually asking if *more* bits is *faster*?

>doesn't realize there's a hidden shift operation from 32 to 64
fucking midwit

well, yeah. it's hidden.

Wouldn't it be enough to mask the most significant 32 bits in the alu output? That way you get 32 bit math w/ a 64 bit alu.

Depends on the architecture dumbass. In some cases operations on 32 bit values will be compiles to sign extend to the native word length (64 bits or whatever), do the operation, then get truncated back. This most commonly comes up for DSPs. The intX_fast types are made specifically for this, they let the compiler pick the fastest size that can fit the number of bits you care about.

What hidden shift? 64bit archs can load/store 32bit integers and can operate on them directly using 32bit instructions.
Which archs? On amd64 and I'm sure arm64/mips64 at least you can work on 32bit integers directly.
>dsp
Yeah, because that's clearly what that faggot on so was asking.