Linux 4.20 is 25% slower than 4.19

Linux 4.20 is 25% slower than 4.19.
phoronix.com/scan.php?page=article&item=linux-420-bisect

Attached: Download (47).jpg (600x352, 33K)

Other urls found in this thread:

phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1061646-bisected-the-unfortunate-reason-linux-4-20-is-running-slower?p=1061693#post1061693
phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1
twitter.com/SFWRedditImages

Hahahaha

Debian stable master race at 4.9 wins again

Attached: BEC04165-3079-4AB6-B308-069848285E46.jpg (1366x768, 255K)

AMD master race, buy Intel, get ~70% of the performance you paid for, what a fucking joke.

Hoping it was just a simple performance regression in Linux 4.20 that could be quickly resolved, that was not the finding when bisecting these performance shortcomings... An intentional kernel change for better mitigating against Spectre is the latest reason why the Intel Linux performance is much slower. That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

Basically, the STIBP addition in Linux 4.20 will affect systems that have up-to-date/available microcode with this support and where your CPU has Hyper Threading enabled/present.

You mean
>Linux 4.20 is 25% slower than 4.19 on Intel

>Linux 4.20 is 25% slower than 4.19
Not with AMD hardware, lul.
Stop being an Inturd retard.
Join the #BETTERED.

AHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAHAHAHAHAHAHHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA

Attached: 1537012159186.png (1200x800, 164K)

doesn't matter which OS you run right? it happens to everything?

Why is Intel refusing to fully patch Spectre/ Meltdown at the hardware level once and for all?

DELETE THIS

Attached: 1540220717862.png (1384x725, 138K)

but it's 100% more progressive

>4.9
fag

Attached: shot.jpg (1366x768, 408K)

>price- 166%
It's 250% now, $800 for 9900k and $310 for 2700x

> patch spectre/meltdown ... at the hardware level
What do you mean... Like, I'm giving you the benefit of the doubt and hoping you mean microcode, but if you don't, and are talking about patching existing processors: you can't. It's hardware. You can't just re-etch the processor. What we have is pretty much as close to a patch as we can get. You can't really "patch" around the foundation of the system, the hardware behavior, and trying to do so in software severely effects performance. Not to mention that the feature here which is being patched around is one which offered significant speed boosts in the first place.

severely affects*

I meant the new ones that have come out since the exploits.
They've released numerous chips with the exploits instead of reworking the design to avoid it.
A microcode fix is just a bandaid.

Attached: 1521636672590.jpg (716x724, 15K)

>Java-based DaCapo tests taking up to ~50% more time to complete to code compilation tests taking measurably longer to lower PostgreSQL database server performance to longer Blender3D rendering times.

Have Linux kernel developers went nuts? This is stupid.

>AMD unaffected
That's funny, I hope there's a way to disable this spectre crap on my thinkpad though.

NOOOO AAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH

Attached: 1534595224911.png (807x867, 343K)

>not using backports
...

Yeah, the exploits should be running at twice the clock speed!

>Debian stable master race at 4.9
>not grsec patched kernel
wtf

this post is funded by Russia gang

>paying for bloat and slower kernel

Whew, for a moment there I was worried.

Attached: 2deructkk2jz.jpg (596x1197, 137K)

So... basically, it's spectre again?

AMD master race reporting in. Feels good not having my CPU slowed down with every kernel release.

It is HT Spectre variant. Very expensive to mitigate at software level only. You have to disable HT in BIOS to avoid penalties for other cores.

based

>patching the hardware
You mean patching the microcode rights?

It probably not enough to patch the microcode so they have to add extra protections in the upper layers.The only ways they can fix the hardware is by releasing new ones.

Because not all workloads need the patches. If you have an airgapped workstation, for instance

he means that newly released hardware is still vulnerable

No worries, your Linux just chillin senpai

Attached: before-after-420.jpg (468x423, 30K)

>420
>Thinking slowly.
That's on purpose.

>4.20
>slower
Ayylmao

Attached: images(7).jpg (270x187, 8K)

COCked

They'll have to scrap Core entirely, dummy, and they have no engineers capable of something other than monkey patching left.

Delete this antisemitic thread, goyim

It's not fair!

What are we gonna do intel bros?

Attached: 1497880928990.png (653x726, 84K)

How do I compile one without any security patches? Because the chances of encountering something using those vulnerabilities in the wild are lower than of me getting laid.

>That change is "STIBP" for cross-hyperthread Spectre mitigation on Intel processors. STIBP is the Single Thread Indirect Branch Predictors (STIBP) allows for preventing cross-hyperthread control of decisions that are made by indirect branch predictors.

Attached: 1512175979risitasriretosad.gif (250x188, 1.63M)

Just delid + delap + apply chiller

Attached: 1514937277489.jpg (626x657, 81K)

the bugs are intrinsic to how Intel's processors work. "fixing" the bugs requires extensive redesigns. That takes years. Building ZEN from the ground up costed 5.

4.20 has not even been released

Performance regressions are quite normal, the change that causes the problem is reverted and life goes on.

5.....competent white engineers?

kek good to know. I was going for an APU laptop next year, but now even more so. Hopefully Zen2 will be out on laptops by then.

SHUT IT DOWN

>With all security mitigations enabled Skylake has lower IPC than Bulldozer

AHHAHAHHAHAHHAHHAHAHHA

lol

Is there even a way to disable this kind of patching on Windows anyways? I mean, doesn't Windows already patch whatever shit is needed and reduce performance by quite a bit?

>dude just revert the security fix lmao

So , how long till the OS is fully cucked ?

I mean that's what you get for using intel
>inb4 intel shill squad arrives
No, AMD is not GENERALLY better, but it dodged a bullet here. It's definite to have security holes too, and as long as speed is a higher priority than security is, this will keep happening
That being said, at least fully disclose your fucking security holes you jew FUCKS
openBSD did nothing wrong and everyone shat on it for "muh tinfoil disabling HT" only to do so a few months later

1 engineer, 5 years.

Holyshit
Intel is gonna sink in the server market

linux doesn't matter

For servers? Is this shitposting?
Who do you even think is the primary customer of intel (or any company's) products, 1337 gaymers?

They are not refusing, they're probably doing it right now, but it will take literal years.
We're talking about redoing the way the shit works internally.

>openBSD did nothing wrong and everyone shat on it for "muh tinfoil disabling HT" only to do so a few months later
Came to post this. Truly the god-tier OS

t. paid microshill

Kill yourself redditurd.

Based google AI response

>the entirety of top500 supercomputers doesn't matter
>billions of phones don't matter
>web doesn't matter

>not knowing that 4.9 received free grsecurity patches
I want newfags to leave.

Attached: wc9wv4m0edk01.png (801x1022, 479K)

Thanks Based Jim Keller

i fell for the limux meme what's a good video player for debian?

Attached: 1520704978946.jpg (538x491, 22K)

Attached: 1515840841704.jpg (691x771, 64K)

Same as everywhere else, mpv.

> FAT BIRD BAD

Attached: 2k48t0.jpg (500x607, 19K)

Can often find the 2700X for cheaper, I picked up one for 290. I swapped out my 1800X for one and resold the 1800X with the 2700X's cooler for 280.

So I was able to jump from the 1800X to a 2700X for 10 bucks, lol.

Thanks Based Jim Keller

>relies on aftermarket "security" patches kept updated by literally who
or
>still hasn't updated from 4.9.(23 or w/e)
either way you're retarded

some greek bonobo keep saying hyperthreading is irrelevant if you have more than 4 cores
is there truth to this or is it just one of those "I only use a single core so whatever"-gamers?

Attached: 1519776753486.gif (303x307, 1.24M)

Depends on the workload

4.9 receives official security patches until 2023.

Thanks Based Jim Keller

compiling with gcc and encoding x264 with ffmpeg I guess are the big ones for me

Both of those scale well across threads, you'll definitely benefit from SMT even on a 4+ core CPU

thank the coc.
it's going to get worse before it gets better.
welcome to the post-meritocracy linux kernel.

>hyperthreading is irrelevant if you have more than 4 cores
nonsense
I don't know if HT help ffmpeg much, but it benefits compilation speeds for sure

HT is not just about "Moar virtual cores".
It is a way to squeeze more performance out of the CPUs.
The trick is that in many, many, many cases, a CPU will "stall" for several reasons, such as missing the cache data, wrong branch prediction, instructions that take a while.., so with HT you run two threads on the same CPU, normally splitting half of the clock cycles for each, but when one of your threads gets into a stall, the other one is allowed to run twice as fast, giving you an end result of 1+1=2.3

Iseee
the comment on the phoronix article seemed like a pretty opinionated post
>

Attached: phoronix.png (1187x314, 57K)

That's complete bullshit. With all cores loaded, hyperthreading is about 30% performance boost.

I guess he must be stoned.

Attached: wassup.jpg (500x500, 41K)

Speed is ableist and against the CoC
>how one textfile reduces performance by 25%

pics or link to whitepaper?

kek

dude weed lmao

Looks like the CoC is kicking in.

Thanks Based Jim Keller

I mean what he writes is mostly correct but for some reason he believes that just because HT *may* be slower in some cases it's suddenly not worth to have it enabled, when in practice you'd just be disabling a 15-30% performance boost like a retard

This guy is an idiot. The point of SMT is to make use of idle pipeline cycles when a core is stalled on memory accesses (which is already 12-15 cycles for an L2 hit, 50-100 for L3, and even worse for DRAM). Clearly not every workload is not going to be entirely pointer chasing, but enough parts of enough of them do have memory stall that SMT usually yields aggregate throughput improvements.

>With all cores loaded, hyperthreading is about 30% performance boost.
Again, this is workload and platform dependent. Zen can get numbers around this in more than a trivial amount of cases largely since its baseline DRAM latency is lackluster.

> phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1061646-bisected-the-unfortunate-reason-linux-4-20-is-running-slower?p=1061693#post1061693

sometimes I do not really know

Attached: bepo.png (1194x314, 32K)

Intel is done for in the server market.

Attached: 1515517767970.jpg (474x473, 12K)

Thanks Based Jim Keller

checked

Thanks Based Jim Keller!

>Intel
>big iron anything
>>>>>>>>done
Their chips may be shit right now, but their support has always been top tier. AMD never got their act together in that regard even since the Opteron days.

Attached: 1429385613191.jpg (640x852, 58K)

phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1

THE HORROR, THE HORROR