mainly because AMD doesn't even have it so you have to be compiling for intel in the first place

yeah so any larger server systems who actualy need all juice they can get

what actualy do computing and heavy lifting :D

but indeed for normal users the HLE hit aint __that__ bad expect on probly some rare cases

@Goz3rr and aint HLE anyway C/C++ only thing or ?

HLE is about machine code

it's an instruction

yeah but all thing i know have had problems/used it have had something to do with C so i was just quessing

HLE adds two instruction prefixes

which through some black magic fuckery are backwards compatible

so they can remove HLE without breaking anything

since it'll just fall back

the performance loss that tweet is talking about is unrelated to HLE instructions itself

the microcode update changed something relating to how jump instructions are decoded

the problem this tweet is talking about

compilers can know about this issue and generate different code

to avoid crossing 32 byte boundaries or ending up on a 32 byte boundary

for negligible side effects (basically just add a nop or reorder code)

but the problem is

everything has to be recompiled for that to happen

hence things compiled before now might try to do that and see reduced performance

and the way almost all modern software works

no one actually compiles for different cpus

unless you're some arch turboautist

gentoo*

Same difference

it's not, you don't build from source on arch unless outside package manageer

Performance in games seems to be in line with the 0-4% decrease Intel states

Mainly because games are GPU limited anyways

INTEL NO 1

>when desktop CPUs are more powerful than your 10 times more expensive server CPUs

LOL!

>actually taking passmark as a representative benchmark

LOL!

LOL!

you're laughing now until you realize that with the current going AMD users will get the same performance impact

yeah when that happens

it's already happening

intel submitted the patches to GCC today