Attached: 1635692111917.png (1528x1628, 254.51K)
Why is söyoverflow like this
Camden Williams
Kayden Scott
>gives very detailed answer
>BTFOs performance ricers
Yep, I'm thinking based.
Christopher White
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
Noah Hill
>very detailed non-answer
Look at those updoots. Immeasurably based.
Oliver Anderson
It seems like 90% of the questions on stackoverflow are a result of the XY problem
Grayson Phillips
It seems like a very reasonable answer, what's your fucking problem?
Josiah Wood
it doesn't answer the question that was asked
John Jackson
>XY problem
Autism? Because I think autism. I mean it's pretty obvious.
Parker Brown
The question was malformed, he's lucky it didn't get locked.
Faster how?
Nolan Murphy
no, m3n are the probl3m
Nicholas Parker
What's wrong? I can only see an average Any Forumsentooman in the pic.
Austin Martinez
Never have I read "Just try it out lol" written in such a faggy way
Samuel Evans
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.
Alexander Myers
Also memory bandwidth, maybe a few others to.
Jordan Roberts
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.
Austin Wright
No wait, what the fuck?
This is actually asking if *more* bits is *faster*?
Julian Adams
>doesn't realize there's a hidden shift operation from 32 to 64
fucking midwit
Ayden Cox
well, yeah. it's hidden.
Eli White
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.
Daniel Young
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.
Brody Morgan
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.