41–50 of 66 posts
CMT vs SMT (very simplified view): https://i.imgur.com/AcZnipK.png
As you can see, with CMT, you have the same amount of ALUs than with SMT but a single thread can only use its dedicated ALU leaving the other one useless meanwhile SMT allows a single thread to use all ALUs.
For our application (heavily numeric, very well behaved cache access), turning on hyperthreading only increased real performance by about 10% (measured as work completed per unit of time). However, we settled on a metric where we defined CPU use to be load average divided by number of cores. Doubling the number of cores the system showed in top allowed us to meet the required margin.
So from a bureaucratic point of view, hyperthreading was a 100% improvement.
Intel i5 desktop chips don’t have hyper-threading (SMT) and haven’t for the 10 years they’ve been available. Typically the i7 variant of the same CPU has been about £100 more (roughly 50%). The point about only 5% extra die space makes no difference to the consumer, as there is/was quite a high cost premium on desktops for that feature. Now Intel has removed hyper-threading from most of it’s i7 desktop chips, and you…
"Intel i5 desktop chips don’t have hyper-threading (SMT) and haven’t for the 10 years they’ve been available." That's mostly true, though there have been a few desktop i5 processors with hyperthreads. Like: https://ark.intel.com/content/www/us/en/ark/products/43546/i...
In the linked article about ghk's talk, you find this tidbit: "If you're not using a supported distro, or a stable long-term kernel, you have an insecure system. It's that simple. All those embedded devices out there, that are not updated, totally easy to break." Is he still talking about SMT, or just poor security of Linux in general? I'm wondering about this since "all those embedded devices out there" that I can t…
Tons of stuff like NUC's used as digital displays, kiosks, etc, everywhere. I'd be surprised if even half of that was on a proper update path. Embedded isn't just like, microcontrollers. Think about all the times you've seen a BSOD on a billboard.
Flagging this as it's an absurdly shallow article apparently combining about 10 minutes of "research" after hearing something on twitter with conflating typical end user use-cases and an entire technology. The "tuning" and "oh noes my VMs this is surely a new problem nobody doing virtualization has ever thought of" section is too absurd to even bother with. But for the security aspect it's worth pointing out that in…
I'd argue most large compute by total $ is actually shared at the host level i.e. public/private cloud or user devices. Basically the only things that aren't are dedicated clusters for specific applications and a few hundred supercomputers while AWS alone has over 100x as many cores as the largest supercomputer.
Also I don't think there is a high horse to be on about an article not targeting the audience of the largest exacompute scale clusters, not everyone/everything at HN need be at the forefront of the field to avoid being flagged.
Earlier quoted context omitted.
That's not true. NIC queues and CPUs are still very important to get good performance on servers by pinning different queues to different cores.
Only if your workload involves passing around a lot of network traffic (e.g. a load balancer) or is highly latency-sensitive. I've got backend servers that routinely max out 32c/64t CPUs but push so little traffic that replacing the NIC with a cell phone modem would make no discernible difference. There are many types of server workloads where the NIC is not the bottleneck at all, so the parent's argument that low NI…
You're debating an argument that was never made.
Earlier quoted context omitted.
Tons of stuff like NUC's used as digital displays, kiosks, etc, everywhere. I'd be surprised if even half of that was on a proper update path. Embedded isn't just like, microcontrollers. Think about all the times you've seen a BSOD on a billboard.
If it doesn't have a jtag connector it isn't embedded.
JTAG on the NUCs actually led to a CVE as well IIRC.
Earlier quoted context omitted.
If it doesn't have a jtag connector it isn't embedded.
This comment is extremely ironic considering it was an Intel processor that spurred the widespread use of JTAG and all the way up to Skylake Intel products had traditional JTAG connectors. These days they do JTAG over a physical USB port but I'm not sure how the shape of the port is supposed to matter. JTAG on the NUCs actually led to a CVE as well IIRC.
Of course SMT makes sense. Why would it not be? Article says that thats because ppl only count the threads in their "cpuinfo" output and get the wrong impression? Intel vulnerabilities are not SMT vulnerabilities per-se, they are side channel attacks on a specific SMT implementation.
Flagging this as it's an absurdly shallow article apparently combining about 10 minutes of "research" after hearing something on twitter with conflating typical end user use-cases and an entire technology. The "tuning" and "oh noes my VMs this is surely a new problem nobody doing virtualization has ever thought of" section is too absurd to even bother with. But for the security aspect it's worth pointing out that in…
There aren't really many "performance critical" multithreaded environments in the world. For the most part you either have something that doesn't scale and needs a really fast thread or you have a cost equation about how many servers you need to buy/maintain. The main exception that comes to mind are extremely large databases that heavily resist horizontal scaling due to poor design (of either software or database).…
