You must not be using an enterprise version then. RedHat charges $299 per workstation license, per year.
Somebody uses Redhat for workstations? Who? The vast majority of Redhat installs are servers. Stupidly expensive maintenance subscriptions imho, but it makes sense to somebody. I suppose, the cost is nothing compared to managing more machines with fewer admins.
In healthcare, for example, patient care is all that matters, and whether that happens in Linux or Windows is typically a very minor concern.
Today, Windows computers are routinely exploited to gain access to such critical infrastructure as the power grid. Why would you want to put your life at risk by helping the bad guys get into your medical devices too?
Who benefits by replacing inherently secure Linux with malware magnet Windows? Russia does most certainly. And just need to coopt as few as one official, a few weeks of over-the-paunch sex should do it, easier than winning at Russian roulette.
OK, this pdf sheds some light on the Power 8 question: it has 2 instruction fetch units per core, therefore does only 2 way SMT like the others, with 8 threads per core. So now I think, nobody actually does more than 2 way SMT. I will guess that dividing the superscalar resources 3 ways is just too much of a hit to justify adding more instruction fetch units. But up to 8 threads per core via TMT looks like a somewhat popular idea, we might see it show up on day in mainstream processors.
POWER9 processors for those HPC jobs use up to 4-way SMT as well, although they go to 8 for normal server loads in the "scale up" versions. SUN/Oracle used 8-way SMT as well for some of their processors. Each of the implementations are different, of course, and often configurable to a particular load or even dynamic like in some Oracle cores.
Right, it says so in the Wikipedia article I linked, except it says "multithreading", not necessarily simultaneous MT. The Sparc parts (now headed for extinction) do 8 way multithreading but only 2 way SMT.
IBM Power is the most interesting one. The article says 4 way MT, but it looks like they do 8 way on some parts. Is it SMT or not? IBM's performance claims indicate it is, and they deliver big parallel gains by increasing some per-core resources. IBM would be the one to do this right, with 20 more years of throughput optimization than anyone else. But they also tend to work in a space where the processor price is not very important.
Maybe we will see higher MT counts in PC cpus from Intel and AMD some time in the future. Maybe we will see 2 way SMT in the next high end ARM generation. My crystal ball doesn't come right out and tell me, and even for a chip architect, It seems this question is tough to call.
The one point where I would disagree is the implication that Intel is doing a deliberate defeature for marketing purposes. Everybody is constrained at the high end these days and if you could make more fully featured high-end SKUs you could sell them.
The problem with your argument is, AMD does ship an 8 core part with SMT (I thought everybody knew that?). So Intel is doing a deliberate defeature, and you are sufficiently gullible to believe otherwise.
What I suspect is really happening is that there is a timing problem that's affecting their binsplits and they discovered they can recover the timing if they disable HT. So they redefine the SKU so they can defeature HT rather than down-bin the silicon.
Long shot theory, marginally possible. I have trouble believing they would have enough parts failing in exactly that way to introduce a whole new SKU. Just market them as i5's.
This is clearly all about marketing. Intel ships few parts these days, so they obviously need to sell them for more money n'est ce pas?
Big winner here is AMD, and everyone who switches.
There is such a thing as MIPS MT supporting 4 SMT threads. While 2 thread SMT is clearly worth the extra chip real estate on average, it is not clear that the additional complexity to support 4 is worth it, and nobody else followed MIPS in that direction.
I am referring to some non-gaming tasks that can also move to the GPU.
Some can, most can't. Many parallel loads could in theory be ported to GPU but this is a specialized, prohibitively expensive engineering task. Many parallel loads do not parallelize at the SIMD level. Without SIMD, a GPU becomes a fairly small number of low-clocked and non-superscaler CPUs with crappy branching characteristics and severely limited cache, basically turning the GPU into a decellerator. For these and other reasons, the vast majority of parallel loads will stay on the CPU for the forseeable future.
The performance processor market is clearly not for you. For those of us who do care about performance because time equals money will continue to invest in high performance equipment. A rubbernecking bystander such as you should be perfectly fine with an Atom, it will suit you perfectly.
Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors.
You have it exactly backwards. The more RAM accesses you have, the more SMT helps. And I/O has almost nothing to do with SMT because the OS takes care of that... a thread waiting for I/O is not running, or in other words, not in any CPU core, so not affected by SMT.
And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
You are talking nonsense. I get my fastest compiles with 8x2 SMT cores, exactly what I my Ryzen part gives me. I just don't care about your other comparisons, they look like smokescreen to me. A decent compiler (gcc, llvm) will use as many cores as you have. You just tell it how many threads you want and away it goes. Compiling is embarrassingly parallel, it approaches best case for SMT. Linking was a serializing bottleneck historically but there is no good reason for it, and is now largely fixed.
Your evident confusion coupled with confident pronouncements that are flat wrong is a little concering. Is this somehow normal for the circles you move in?
Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.
These are 95W parts. Video encoding should be just fine with these high frequency non-HT parts.
But obviously, it would be better with HT. Going to the Arstechnica comments, the consensus is, this is just a marketing move by Intel. To be precise, i9 is the new i7, and open your wallets wider. It is possible that I am also right by saying that these non-HT i7's are targeted at mobile. Bragging rights, ok? "I have an i7 in my laptop, so cool [apple fan voice]". The catch being, i7 is the new i5.
This game is going to push a lot of folks to Ryzen. Intel must know that. Maybe they are trying to keep Apple from going to ARM?
You still need multiple CPU cores to drive the GPU efficiently, that is the entire point of Vulkan. If either CPU or GPU is not fully utilized at peak load then your hardware configuration is not optimal for the load.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
Will these still need to have Meltdown and Spectre patches?
Spectre, Meltdown and other speculative execution exploits can work more rapidly with Hyperthreading/SMT but they also work perfectly well with single threaded cores. Cache timings are the leakage point.
spectre-related attacks rely on predictive execution in hyperthreading. could this be a mitigation, while providing improved performance so the new part still exceeds the outgoing part?
A thought that occurred to me also, but I don't think so. Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation. This is about low power parts aimed at the ultraportable market, see my longer post in this thread.
I guess it depends on your workload. Video encoding or compiling will happily consume as many processors, including simulated processors, as you have, and both are known to benefit from Hyperthreading/SMT regardless of core count. The new generation of Vulkan-style game engines will also eat as many cores as you have, assuming a well designed engine.
So what you're saying is, you have no idea what hyperthreading is but you don't like it because it does not benefit all workloads? I hope you can see what's wrong with that argument. If not, I will try to help.
Hyperthreading (a simplified form of SMT is about putting cpu cores to work that would otherwise stall, e.g., waiting on a memory load. If your workload has everything in L1 cache then SMT won't do anything and just wastes transistors, which could have been better used by providing more cores or more cache memory. Most loads do hit enough memory that SMT is a win for parallel latency, however for those that don't, SMT can actually slow things down as multiple threads compete for limited superscalar resources such as register files. If there aren't too many parallel threads then it would be better to give each its own core.
So here is the thing: to make best use of SMT you need to know something about how SMT works, and something about your workload. Then you can potentially use CPU affinity to tune your application. If you are ignorant about either of these things, or you can't justify the time to do the necessary tuning, or you don't have the necessary access, then sometimes, yes, SMT is just going to bite. But it wins on average, which is why all modern general purpose processors implement it, with the notable exception of ARM.
Throughput is not the entire story about SMT, there is also power efficiency. Additional logic is required to fetch two independent instruction streams in parallel, keep them independent, and manage the additional cache complexity. This does not slow things down but eats power, which is why ARM so far does not implement it, and Intel does not use it for Atom. This sacrifices parallel throughput, and if you have any Atom devices, you will be painfully aware that they suck compared to their core arch cousins. Intel had to about face on this when AMD dropped Ryzen on them so now, some low end Intel parts also have hyperthreading.
Fast forward to today's rumor. It should be clear that not having Hyperthreading/SMT hurts performance on average, but can improve power efficiency. Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.
Einstein's theories were thoroughly validated in his own time, but he also made a number of predictions based on those theories, some of which were not verified within his lifetime. And some of what we call "Einstein's predictions" are not predictions by Einstein, but predictions developed by others as a consequence of Einstein's theory. You don't need to weep for Einstein about his predictions based on relativity, you should instead wish that he had managed to discover a theory that explains gravity in terms of the other forces.
at some stage (due to the increasing mass of the object), the force required to exceed C becomes infinite
There is no such thing as exceeding C, a universal constant. And you don't need to talk about "some stage", we know exactly at which velocity mass becomes infinite: infinity. So accelerating a mass to C requires infinite energy, which is why only a massless particle may travel at exactly C. (And there is only one such massless particle, the photon, that can do it. The only other massless particle, the gluon, is confined to the atomic nucleus, which has mass.)
if a gravitational field (such as that of a black hole) is creating an acceleration of x meters per second per second, an object should continue to accelerate to and beyond the speed of light
Where do you get this "beyond the speed of light thing from"? Are you inventing your own universe?
"To the speed of light" is a reasonable question, which I will take a run at: when your object goes past the event horizon it ceases to exist in any frame of reference of the universe we exist in, so velocity past the event horizon is meaningless, if the object can be said to exist at all. The question of what happens exactly at the event horizon exceeds my armchair physics knowledge. My intuition is, the distance from the object to the event horizon is finite, even with spatial distortion of the gravity well. Therefore, the object has a finite time to accelerate, therefore it can never reach C.
A ruling from an actual physicist would be appreciated.
Slashdot Mirror
You must not be using an enterprise version then. RedHat charges $299 per workstation license, per year.
Somebody uses Redhat for workstations? Who? The vast majority of Redhat installs are servers. Stupidly expensive maintenance subscriptions imho, but it makes sense to somebody. I suppose, the cost is nothing compared to managing more machines with fewer admins.
In healthcare, for example, patient care is all that matters, and whether that happens in Linux or Windows is typically a very minor concern.
Today, Windows computers are routinely exploited to gain access to such critical infrastructure as the power grid. Why would you want to put your life at risk by helping the bad guys get into your medical devices too?
What are you using? I use KDE Plasma. Doesn't suck, far from it.
Who benefits by replacing inherently secure Linux with malware magnet Windows? Russia does most certainly. And just need to coopt as few as one official, a few weeks of over-the-paunch sex should do it, easier than winning at Russian roulette.
Look in the mirror, what do you see, how much does it suck to be?.
OK, this pdf sheds some light on the Power 8 question: it has 2 instruction fetch units per core, therefore does only 2 way SMT like the others, with 8 threads per core. So now I think, nobody actually does more than 2 way SMT. I will guess that dividing the superscalar resources 3 ways is just too much of a hit to justify adding more instruction fetch units. But up to 8 threads per core via TMT looks like a somewhat popular idea, we might see it show up on day in mainstream processors.
POWER9 processors for those HPC jobs use up to 4-way SMT as well, although they go to 8 for normal server loads in the "scale up" versions. SUN/Oracle used 8-way SMT as well for some of their processors. Each of the implementations are different, of course, and often configurable to a particular load or even dynamic like in some Oracle cores.
Right, it says so in the Wikipedia article I linked, except it says "multithreading", not necessarily simultaneous MT. The Sparc parts (now headed for extinction) do 8 way multithreading but only 2 way SMT.
IBM Power is the most interesting one. The article says 4 way MT, but it looks like they do 8 way on some parts. Is it SMT or not? IBM's performance claims indicate it is, and they deliver big parallel gains by increasing some per-core resources. IBM would be the one to do this right, with 20 more years of throughput optimization than anyone else. But they also tend to work in a space where the processor price is not very important.
Maybe we will see higher MT counts in PC cpus from Intel and AMD some time in the future. Maybe we will see 2 way SMT in the next high end ARM generation. My crystal ball doesn't come right out and tell me, and even for a chip architect, It seems this question is tough to call.
Those who care about performance learn to code at the bare metal level and OPTIMIZE.
Whoosh. Those of us who code professionally want to do it on fast hardware so we don't waste our own time.
The one point where I would disagree is the implication that Intel is doing a deliberate defeature for marketing purposes. Everybody is constrained at the high end these days and if you could make more fully featured high-end SKUs you could sell them.
The problem with your argument is, AMD does ship an 8 core part with SMT (I thought everybody knew that?). So Intel is doing a deliberate defeature, and you are sufficiently gullible to believe otherwise.
What I suspect is really happening is that there is a timing problem that's affecting their binsplits and they discovered they can recover the timing if they disable HT. So they redefine the SKU so they can defeature HT rather than down-bin the silicon.
Long shot theory, marginally possible. I have trouble believing they would have enough parts failing in exactly that way to introduce a whole new SKU. Just market them as i5's.
This is clearly all about marketing. Intel ships few parts these days, so they obviously need to sell them for more money n'est ce pas?
Big winner here is AMD, and everyone who switches.
There is such a thing as MIPS MT supporting 4 SMT threads. While 2 thread SMT is clearly worth the extra chip real estate on average, it is not clear that the additional complexity to support 4 is worth it, and nobody else followed MIPS in that direction.
I am referring to some non-gaming tasks that can also move to the GPU.
Some can, most can't. Many parallel loads could in theory be ported to GPU but this is a specialized, prohibitively expensive engineering task. Many parallel loads do not parallelize at the SIMD level. Without SIMD, a GPU becomes a fairly small number of low-clocked and non-superscaler CPUs with crappy branching characteristics and severely limited cache, basically turning the GPU into a decellerator. For these and other reasons, the vast majority of parallel loads will stay on the CPU for the forseeable future.
The performance processor market is clearly not for you. For those of us who do care about performance because time equals money will continue to invest in high performance equipment. A rubbernecking bystander such as you should be perfectly fine with an Atom, it will suit you perfectly.
Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
Actually compiling would not be one of those rare instances. I/O and RAM are also huge factors.
You have it exactly backwards. The more RAM accesses you have, the more SMT helps. And I/O has almost nothing to do with SMT because the OS takes care of that... a thread waiting for I/O is not running, or in other words, not in any CPU core, so not affected by SMT.
And again, **diminishing returns**, 8 core vs 8 core + HT will probably be less helpful than 2 vs 4 cores or 4 vs 8 cores. 8 cores without hyper threading is not wimpy.
You are talking nonsense. I get my fastest compiles with 8x2 SMT cores, exactly what I my Ryzen part gives me. I just don't care about your other comparisons, they look like smokescreen to me. A decent compiler (gcc, llvm) will use as many cores as you have. You just tell it how many threads you want and away it goes. Compiling is embarrassingly parallel, it approaches best case for SMT. Linking was a serializing bottleneck historically but there is no good reason for it, and is now largely fixed.
Your evident confusion coupled with confident pronouncements that are flat wrong is a little concering. Is this somehow normal for the circles you move in?
Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.
These are 95W parts. Video encoding should be just fine with these high frequency non-HT parts.
But obviously, it would be better with HT. Going to the Arstechnica comments, the consensus is, this is just a marketing move by Intel. To be precise, i9 is the new i7, and open your wallets wider. It is possible that I am also right by saying that these non-HT i7's are targeted at mobile. Bragging rights, ok? "I have an i7 in my laptop, so cool [apple fan voice]". The catch being, i7 is the new i5.
This game is going to push a lot of folks to Ryzen. Intel must know that. Maybe they are trying to keep Apple from going to ARM?
You still need multiple CPU cores to drive the GPU efficiently, that is the entire point of Vulkan. If either CPU or GPU is not fully utilized at peak load then your hardware configuration is not optimal for the load.
Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation.
Doubtful. Increasing cores experiences diminishing returns. The difference between 8 cores and 8 cores + HT may be quite minimal except in very rare instances.
Those rare instances tend to the be ones you care about, like compiling or video encoding. If you don't care about performance then by all means accept a wimpy processor, it's right for you.
I was talking about GPU, This is what somebody means when they say "Vulkan". Hint: if you don't know the words then google before you post.
Anyways, who is the knuckledragger now?
You are, because anyone with hairless knuckles can see where the post was actually intended to be posted, and where it is now posted.
Will these still need to have Meltdown and Spectre patches?
Spectre, Meltdown and other speculative execution exploits can work more rapidly with Hyperthreading/SMT but they also work perfectly well with single threaded cores. Cache timings are the leakage point.
spectre-related attacks rely on predictive execution in hyperthreading. could this be a mitigation, while providing improved performance so the new part still exceeds the outgoing part?
A thought that occurred to me also, but I don't think so. Intel isn't going to drop Hypthreading on all its parts, or AMD will happily kick their tail with its superior SMT implementation. This is about low power parts aimed at the ultraportable market, see my longer post in this thread.
in a multi-core chip past 2-4? I guess not.
I guess it depends on your workload. Video encoding or compiling will happily consume as many processors, including simulated processors, as you have, and both are known to benefit from Hyperthreading/SMT regardless of core count. The new generation of Vulkan-style game engines will also eat as many cores as you have, assuming a well designed engine.
So what you're saying is, you have no idea what hyperthreading is but you don't like it because it does not benefit all workloads? I hope you can see what's wrong with that argument. If not, I will try to help.
Hyperthreading (a simplified form of SMT is about putting cpu cores to work that would otherwise stall, e.g., waiting on a memory load. If your workload has everything in L1 cache then SMT won't do anything and just wastes transistors, which could have been better used by providing more cores or more cache memory. Most loads do hit enough memory that SMT is a win for parallel latency, however for those that don't, SMT can actually slow things down as multiple threads compete for limited superscalar resources such as register files. If there aren't too many parallel threads then it would be better to give each its own core.
So here is the thing: to make best use of SMT you need to know something about how SMT works, and something about your workload. Then you can potentially use CPU affinity to tune your application. If you are ignorant about either of these things, or you can't justify the time to do the necessary tuning, or you don't have the necessary access, then sometimes, yes, SMT is just going to bite. But it wins on average, which is why all modern general purpose processors implement it, with the notable exception of ARM.
Throughput is not the entire story about SMT, there is also power efficiency. Additional logic is required to fetch two independent instruction streams in parallel, keep them independent, and manage the additional cache complexity. This does not slow things down but eats power, which is why ARM so far does not implement it, and Intel does not use it for Atom. This sacrifices parallel throughput, and if you have any Atom devices, you will be painfully aware that they suck compared to their core arch cousins. Intel had to about face on this when AMD dropped Ryzen on them so now, some low end Intel parts also have hyperthreading.
Fast forward to today's rumor. It should be clear that not having Hyperthreading/SMT hurts performance on average, but can improve power efficiency. Simple conclusion: these i7's are aimed at the notebook/ultrabook/chromebook market where battery life and weight are more important than performance. You don't want these for your server, desktop or fat ass laptop.
Einstein's theories were thoroughly validated in his own time, but he also made a number of predictions based on those theories, some of which were not verified within his lifetime. And some of what we call "Einstein's predictions" are not predictions by Einstein, but predictions developed by others as a consequence of Einstein's theory. You don't need to weep for Einstein about his predictions based on relativity, you should instead wish that he had managed to discover a theory that explains gravity in terms of the other forces.
at some stage (due to the increasing mass of the object), the force required to exceed C becomes infinite
There is no such thing as exceeding C, a universal constant. And you don't need to talk about "some stage", we know exactly at which velocity mass becomes infinite: infinity. So accelerating a mass to C requires infinite energy, which is why only a massless particle may travel at exactly C. (And there is only one such massless particle, the photon, that can do it. The only other massless particle, the gluon, is confined to the atomic nucleus, which has mass.)
if a gravitational field (such as that of a black hole) is creating an acceleration of x meters per second per second, an object should continue to accelerate to and beyond the speed of light
Where do you get this "beyond the speed of light thing from"? Are you inventing your own universe?
"To the speed of light" is a reasonable question, which I will take a run at: when your object goes past the event horizon it ceases to exist in any frame of reference of the universe we exist in, so velocity past the event horizon is meaningless, if the object can be said to exist at all. The question of what happens exactly at the event horizon exceeds my armchair physics knowledge. My intuition is, the distance from the object to the event horizon is finite, even with spatial distortion of the gravity well. Therefore, the object has a finite time to accelerate, therefore it can never reach C.
A ruling from an actual physicist would be appreciated.
General Relativity makes it an impossibility to exceed the speed of light
Special relativity did it first.