91–100 of 159 posts
Earlier quoted context omitted.
You mean it's random then, right? I mean let's talk about what a hyperthread really is: It's the left over functional units (or execution units). Say you have 100 adders, the processor tries to schedule as many instructions as it can on those 100 adders, but eventually it will run into data dependencies. The left over units can go to a hyperthread. My understanding (let me know if I'm wrong) is that Hyperthread aware…
My understanding (let me know if I'm wrong) is that Hyperthread aware OSes (which is like what, everything since WinXP/Linux kernel 2.4?) will schedule lower priority tasks to the logical cores and higher priority tasks to the real cores That is not how I understand it. The OS sees two identical logical cores per physical core and the CPU manages which is which internally. Also it's not really high and low priority -…
I benchmarked this myself using POV-Ray (which is extremely heavy on floating point) when I first got my i7-3770k (4 cores, 8 threads).
Using two rendering threads was double the speed of one, four was double the speed of two, but eight was only about 15% faster than four.
I don't think I've ever actually seen an example of real-world tasks that get slowed down by HT. Every example I've seen was contrived, built specifically to be slower with HT.
Earlier quoted context omitted.
Question: If I rent 4 core AWS instance, does it mean 4 physical cores or 4 hyper threaded cores? Is there a standard to this definition of “cores” across GCP, DO, Linode, etc. I don’t have the experience or knowledge about cloud computing but just have a DO instance running a web server. I’m curious.
A cloud "vCPU" is a hyperthread and in good providers (EC2/GCE) they are properly pinned to the hardware such that, for example, a 4-vCPU VM would be placed on two dedicated physical cores. This was probably done for performance originally but now it also has security benefits. You can get hints of this by running lstopo on VMs and similar bare metal servers. On second and third tier cloud providers, the vCPUs tend t…
Does that mean hyperthreading is effectively unpatchably insecure? Cloud Providers are gonna have a bad time if this is true.
You can give both hyperthreads in a physical core to the same tenant, no? Scheduling different VMs to run on the same hyperthreaded core at once seems like it can't be good for either VM's performance, even if there were no security concerns. Hyperthreading is much more useful for running multiple threads of the same app, accessing similar instruction caches etc. (There's also a question of safety within the VM, but…
Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…
With the newer AMD processors having as many real cores as they do, does the cost-benefit analysis of HT/SMT change? I read in a comment here a few weeks ago that turning it off on the newer AMD CPUs can yield better performance because of improved cache-coherency on some workloads (My memory of what I read might be totally wrong).
So, realistically, how much performance did your average OpenBSD server just lose from following this mitigation?
Performance is not a top priority for OpenBSD. If you read https://www.openbsd.org/goals.html , the word "performance" does not appear.
Does this mean AMD hyperthreading has a performance + security advantage over currently shipping Intel processors? Edit: https://www.amd.com/en/corporate/security-updates > 8/14/18 – Updated: As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also k…
Earlier quoted context omitted.
You mean it's random then, right? I mean let's talk about what a hyperthread really is: It's the left over functional units (or execution units). Say you have 100 adders, the processor tries to schedule as many instructions as it can on those 100 adders, but eventually it will run into data dependencies. The left over units can go to a hyperthread. My understanding (let me know if I'm wrong) is that Hyperthread aware…
My understanding (let me know if I'm wrong) is that Hyperthread aware OSes (which is like what, everything since WinXP/Linux kernel 2.4?) will schedule lower priority tasks to the logical cores and higher priority tasks to the real cores That is not how I understand it. The OS sees two identical logical cores per physical core and the CPU manages which is which internally. Also it's not really high and low priority -…
In this case, reconstruction 2 MP images on a quadcore E3 Skylake, the performance without HT was better, and even better after replacing some of the pathological uses with B-tree and similar structures under iirc MIT/BSD using the same interface (it was just a typedef away). Also they used size_t for thenumber of an image in your dataset, yet their software is far from scaling that far without a major performance fix due to the cost//benefit of optimization leaning towards a good couple sessions with a profiler, before spending the money on the compute (unless the deadline precludes it).
The dataset still doesn't fit into L3, and even then there are ways to block the image similar to matrix multiplication.
perf stat -dd works wonders. The ubuntu package is perf-tools-unstable, iirc, and setting lbr for the callgraoh of perf top if you run on Haswell or newer gives you stack traces for code compiled with -fomit-frame-pointer.
I would love to but how in the world do I do this when I'm using Windows and Lenovo doesn't give me an option in the BIOS?
Earlier quoted context omitted.
Yes!
Where did you get that impression?
¹ For example in SPECvirt_sc2013 the patch reduces performance by 31% (https://www.servethehome.com/wp-content/uploads/2018/08/Inte...) 31% is unheard of for a security patch! It's a difficult security-speed tradeoff that businesses must carefully consider.
