It easily runs slower. Do you think software performance improves faster than hardware performance?
Algorithms improvement? Like improving concurrent accesses tools? Memory management (malloc/free are expensive)? Optimizing hardware utilization and compatibility? This is the Linux kernel - a newer release\ might work faster (better) than an older one.
Unfortunately, the replacement could be the kind it was for Apple in 2011. Tim Cook is not that bad as a regular CEO, it's just that Jobs was exceptional.
Let's hope it doesn't also run slower than it did in 2011
That's what they try to do. Don't forget that besides the microcode, the kernel also has to integrate some Meltdown/Spectre "mitigation" code, which is likely to alter performances.
Other solution is clear the cache loaded during speculative execution *only* if the branch jump (or not) happens to be different (Spectre) or if an exception occurred (Meltdown). Voilà.
The issue is that some processors don't actually clean up after themselves when branch mis-prediction occurs.
More specifically [or maybe even correctly], that would be clean-up the part of the CPU cache, that was loaded *during* speculative execution, after mis-prediction is actually confirmed (or after exception is confirmed in the case of Meltdown). This is enough to fix both Meltdown and Spectre.
That would be catastrophic for any application iterating over an array or a linked list or a generic object graph ( so basically all )
No. The cache is big enough to keep a good chunk of the array in the CPU. Again, goal is not loading *uncached* data during speculative execution, which should only matter a small % of the work. Garbage code could suffer from that, though.
Not sure about your knowledge web programming wise, but javascript helps a lot in a highly dynamic page, allowing the user to stay on the same page and perform many operations, for instance. Javascript doesn't always mean crap - there's a lot of JS crap due to programmers incompetency (since "web programming" is said to be "easy"), but there is also well made applications where JS makes a lot of good local work and reduces the burden server side.
Considering how messy were the recent Intel-contributed patches applied to various servers (unexpected reboots for instance), Linus must be at least partially right.
The ideal and inexpensive (performance wise) fix is to *not* read from memory into the CPU cache during the speculative execution when that block of data is *not* there already. That cannot be done thanks to a microcode update.
Not the only reason. People use mainly browsers, and a lot of progress has been made in this area (optimizations, JIT compile,...). At the same time, web sites use more and more Javascript, which requires power from the client (more than on server).
The reason practically every processor has the same issues is because the same optimizations we used to make processors faster had the same fundamental design error.
I mean, either someone designed the core branch predictor block and everyone worldwide copied it for every processor, or everyone implemented it differently, yet it has the same Spectre flaw, implying that the flaw is inherent in the way branch predictors work.
No. The fix is to not read from memory into the CPU cache during the speculative execution when that block of data is not there already. Changing this in the CPUs core would solve both Spectre and Meltdown, at a reasonable cost (would not defeat much current optimizations).
Maybe the past year show of nuclear force and ballistic missile defense on the part of the US before North Korea gave Russia strong incentive to build something of importance.
Slashdot Mirror
Interesting, I always thought that of Audi owners.
It easily runs slower. Do you think software performance improves faster than hardware performance?
Algorithms improvement? Like improving concurrent accesses tools? Memory management (malloc/free are expensive)? Optimizing hardware utilization and compatibility? This is the Linux kernel - a newer release\ might work faster (better) than an older one.
This. Indeed.
Not sure "slowest process" is the appropriate term talking of a kernel. "Slowest release completion" might be better.
Unfortunately, the replacement could be the kind it was for Apple in 2011. Tim Cook is not that bad as a regular CEO, it's just that Jobs was exceptional.
Let's hope it doesn't also run slower than it did in 2011
That's what they try to do. Don't forget that besides the microcode, the kernel also has to integrate some Meltdown/Spectre "mitigation" code, which is likely to alter performances.
Other solution is clear the cache loaded during speculative execution *only* if the branch jump (or not) happens to be different (Spectre) or if an exception occurred (Meltdown). Voilà.
Why is there a deadline at all, anyway?
The issue is that some processors don't actually clean up after themselves when branch mis-prediction occurs.
More specifically [or maybe even correctly], that would be clean-up the part of the CPU cache, that was loaded *during* speculative execution, after mis-prediction is actually confirmed (or after exception is confirmed in the case of Meltdown). This is enough to fix both Meltdown and Spectre.
That would be catastrophic for any application iterating over an array or a linked list or a generic object graph ( so basically all )
No. The cache is big enough to keep a good chunk of the array in the CPU. Again, goal is not loading *uncached* data during speculative execution, which should only matter a small % of the work. Garbage code could suffer from that, though.
Not sure about your knowledge web programming wise, but javascript helps a lot in a highly dynamic page, allowing the user to stay on the same page and perform many operations, for instance. Javascript doesn't always mean crap - there's a lot of JS crap due to programmers incompetency (since "web programming" is said to be "easy"), but there is also well made applications where JS makes a lot of good local work and reduces the burden server side.
Considering how messy were the recent Intel-contributed patches applied to various servers (unexpected reboots for instance), Linus must be at least partially right.
it can be fixed with a microcode update!
The ideal and inexpensive (performance wise) fix is to *not* read from memory into the CPU cache during the speculative execution when that block of data is *not* there already. That cannot be done thanks to a microcode update.
Not the only reason. People use mainly browsers, and a lot of progress has been made in this area (optimizations, JIT compile, ...). At the same time, web sites use more and more Javascript, which requires power from the client (more than on server).
(note that this fix requires to change the CPU design)
The reason practically every processor has the same issues is because the same optimizations we used to make processors faster had the same fundamental design error.
I mean, either someone designed the core branch predictor block and everyone worldwide copied it for every processor, or everyone implemented it differently, yet it has the same Spectre flaw, implying that the flaw is inherent in the way branch predictors work.
No. The fix is to not read from memory into the CPU cache during the speculative execution when that block of data is not there already. Changing this in the CPUs core would solve both Spectre and Meltdown, at a reasonable cost (would not defeat much current optimizations).
It must be nice living somewhere with infinite bandwidth.
The server wouldn't keep up.
Difference being a GIF always plays, while a MP4 might be initially paused by some extension or the browser.
Stolen iPhones are locked by Apple. So why would people buy a stolen iPhone since it cannot be used?
leaked by Russian television in November 201
Old news indeed!
The speed of that torpedo is 100 knots (180 km/h), much less than an ICBM. However it could be launched from a submarine close to the US coast.
Maybe the past year show of nuclear force and ballistic missile defense on the part of the US before North Korea gave Russia strong incentive to build something of importance.
Most distribs should run decently with that hardware.
that's not rubber bullets, these are old unusable iPhones.
For what Slashdot could have been, go to https://www.soylentnews.com/
The site doesn't answer... slashdotted?