191–200 of 203 posts
Earlier quoted context omitted.
Uh. I thought that micro-ops were literally microcode instructions/operations?
In a modern processor they are however microcode as a general term is a catch-all term which basically means non-trivial configuration logic stored in somewhere not meant to be touched by people other than the vendor. I think IBM have millicode.
I've been saying this from the start: the well of issues is infinitely deep as soon as you decide that multiple tenants running on the same physical hardware inferring something about another is a vulnerability. I assert, but cannot rigorously prove, that it is not possible to design a CPU such that execution of arbitrary instructions has no observable side-effects, especially if the CPU is speculating. I don't know…
You could very much design and verify that a CPU such that execution of arbitrary code has no observable side effects. However attempting to do so is multi year, for modern CPUs certainly multi decade project. This is not feasible as long as Moore's Law goes on. Formal verification of kernels (SEL4) and a micro processors it runs on have been performed together to proof properties. Large ALU blocks and vector units (…
And therefore M1 seems so much more faster than it otherwise would?
Out of curiosity, is Apple's M1 processor seemingly faster because it is actually more similar to a normal CPU progression but all the other common CPU's - x86 - had retroactive performance hits due to patching Spectre. And therefore M1 seems so much more faster than it otherwise would?
Out of curiosity, is Apple's M1 processor seemingly faster because it is actually more similar to a normal CPU progression but all the other common CPU's - x86 - had retroactive performance hits due to patching Spectre. And therefore M1 seems so much more faster than it otherwise would?
In particular, the design uses a memory hub with the memory chips very close to the CPU core. And it has a massive L2 cache on top.
Earlier quoted context omitted.
It sounds like a dream, but going back towards interpreted JS instead of JIT may finally stem the insanity of bloat that JS has evolved in an environment of increasingly fast implementations.
The problem of Javascript bloat doesn't have a technical solution. Javascript bloat exists because of a social problem: the guy who fixes the corporate webpage's javascripts is called a "webdesigner", and "webdesigners" are the lowest rung on the corporate IT ladder, maybe only a bit above first-tier techsupport. If you want to make some sort of career you need to upgrade from "webdesigner" to "frontend developer", a…
Earlier quoted context omitted.
The problem of Javascript bloat doesn't have a technical solution. Javascript bloat exists because of a social problem: the guy who fixes the corporate webpage's javascripts is called a "webdesigner", and "webdesigners" are the lowest rung on the corporate IT ladder, maybe only a bit above first-tier techsupport. If you want to make some sort of career you need to upgrade from "webdesigner" to "frontend developer", a…
I posit something even simpler. JavaScript bloat exists because it's easy to learn and put something real on a screen for a newb, and it's a pleasure to write in. Writing these frameworks/libraries/websites/whatevers is literally its own reward, and the barrier to sharing tools is low. That, coupled with enthusiastic developers across the entire spectrum of niavete and experience finding new tools fun and exciting to…
Since that isn't getting fixed any time soon, most people have tried to take matters into their own hands, with varying degrees of success.
Earlier quoted context omitted.
Not really. So far these mostly haven't been able to cross process boundaries, and most browsers have tripled-down on process-sandboxing by this point (iframe sandboxing was the last major push here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if... ) So process-based sandboxing will continue to be the defense here, and process switching will just get a little bit slower as increasingly more caches are…
> So far these mostly haven't been able to cross process boundaries Actually, most Spectre vulnerabilities, including this one, do cross process boundaries when they are first discovered, and kernel and microcode patches are needed to implement mitigations against this -- typically flushing some cache or something when switching between kernel and userspace. Often these mitigations hurt performance. > things like Clo…
Earlier quoted context omitted.
Chrome had 7 exploits caught in the wild within 7 weeks in 2020. I believe it is going towards JIT being disabled, or most severely limited.
That would pretty much instantly kill the web, no matter how lean they make websites.