Messages in this thread | | | From | Sedat Dilek <> | Date | Fri, 12 Mar 2021 15:29:48 +0100 | Subject | Re: [PATCH 0/2] x86: Remove ideal_nops[] |
| |
On Fri, Mar 12, 2021 at 1:00 PM Peter Zijlstra <peterz@infradead.org> wrote: > > Hi! > > A while ago Steve complained about x86 being weird for having different NOPs [1] > > Having cursed the same thing before, I figured it was time to look at the NOP > situation. > > 32bit simply isn't a performance target anymore, so all we need is a set of > NOPs that works on all. > > x86_64 has two main NOP variants, NOPL and prefix NOP. NOPL was introduced by > P6 and is architecturally mandated for x86_64. However, some uarchs made the > choice to limit NOPL decoding to a single port, which obviously limits NOPL > throughput. Other uarchs have (severe) decoding penalties for excessive (>~3) > prefixes, hobbling prefix NOP throughput. > > But the thing is, all the modern uarchs can handle both without issue; that is > AMD K10 (2007) and later and Intel Ivy Bridge (2012) and later. The only > exception is Atom, which has the prefix penalty. > > Since ultimate performance of a 10 year old chip (Intel Sandy Bridge, 2011) is > simply irrelevant today, remove variable NOPs and use NOPL. >
Hi Peter,
I am an Intel SandyBridge power user and want the ultimate performance on my hardware.
What does this change exactly mean to/for me?
I got this laptop as the last gift for my birthday in 2012 from my mother. She died the same year. So, this is a bit sentimental hardware for me.
It's amazing what this laptop all was involved in. 10+ years of LLVM/Clang for Linux-kernel and Linux graphics stack. Worked in a Ubuntu/precise 12.04 LTS WUBI (installation) environment - 5 years (full LTS period) long! How many Linux-kernel bugs got reported and/or fixed... Debian/stretch...Debian/bullseye with no fresh installation. Rolling release.
I remember my decision in March 2012 not to choose that Asus notebook with the first hardware-revision of IvyBridge and bought conservatively a SandyBridge Gen. 2 Samsung notebook.
It's a pity to see no or restricted/limited Vulkan support.
If you are not concerned - life goes on for you.
It's like being white colored not understanding what "Black Lives Matter" really means. If people use or talk about white/black listings then allow/deny lists. Or being a female software developer having a 10-15% less salary because you are not male - in the same department! This week we had our 100th anniversary of International Women's Day. I am not black - I am male - I am not concerned - Live goes on?
Again, this machine is able to do fast Linux-kernel builds with an adapted Debian Linux v5.10 kernel-config. If you do NOT use Debian's LLVM/Clang - means build a selfmade stage1-only LLVM toolchain (saves ~1 hour of build-time) - or a ThinLTO+PGO optimized LLVM toolchain (saves again ~1 hour of build-time). Latest Linus Git plus With Clang-CFI took me today approx. 04:20 [hh:mm] with a selfmade stage1-only LLVM toolchain version 12.0.0-rc3. Again, this is amazing.
What I wanna try to say is: This is old hardware but you can - if you are a smart enough - optimize your builds.
On the other hand I can understand dropping support for XXX whatever hardware... Where is the limit(ation): Support 10 years or 7 years old hardware?
Sorry, I am a bit concerned that this is the beginning - or a backdoor ? - to drop (optimized) Intel SandyBridge support.
So, what do I need to do - to have "ultimate performance" back for SandyBridge with your patchset :-)?
Yes, you are right: Life goes on.
Regards, - Sedat -
> This gives us deterministic NOPs and restores sanity. > > > > [1] https://lkml.kernel.org/r/20210302105827.3403656c@gandalf.local.home >
| |