3 ms·
Basically every CPU with a pipeline -- even simple, in-order cores -- speculate by way of branch prediction. I think with the Cortex A53 the pipeline is short e
by baobrien 8y ago
Basically every CPU with a pipeline -- even simple, in-order cores -- speculate by way of branch prediction. I think with the Cortex A53 the pipeline is short enough and the branch predictor simple enough that you can't build a useful spectre attack. It's also common in simpler in-order cores to speculate a little bit around memory accesses.
- dnautics 8y agoThere are architectural choices for pipelined systems you can make that don't specex, but it requires compiler level optimization to take advantage of them, so it's a chicken and egg problem to get adoption
- ajross 8y agoBeen there, done that, didn't work. VLIW has been tried a dozen times and failed every time.
- dnautics 8y agomachine learning has been tried a dozen times and failed every time. Other developments catch up, like compiler technology. Not directly related to branch prediction, but: We are much better at polyhedral optimization than the last time people tried VLIW, for example. Besides, the last major VLIW push (itanium) DID have SpecEx AND Branch Prediction, and did NOT have delay slots.
- ajross 8y agoShrug. To paraphrase, your argument for "this can be done" is "THIS time will be different I swear!". What will actually happen, of course, is that everyone will put a ASID/PCID as a tag word into all the relevant caches, they'll stop being probe-able from other contexts, and we'll all keep our deep pipelines and speculation and the cache crisis of 2018 will be just a story we tell our grandkids. Much cheaper than a paradigm shift based on long-since tried and rejected technology.
- dnautics 8y agoyou are fundamentally misunderstanding my argument: sometimes it is different. When it is different, it's usually because associated technologies has changed. For ML, it was GPUs and large amounts of data harvestable from the internet (arguably the second one more than the first). The evolutionary development in compilers is a strong argument that it MIGHT happen to end SpecEx. If it doesn't it's probably mostly due to technical debt and engineering inertia, difficulty convincing end users to adopt. There are definitely cases where non specex (vliw or otherwise) can outperform, I have seen it with my own eyes.
- ajross 8y ago> If it doesn't it's probably mostly due to technical debt and engineering inertia You jumped straight from "absence of proof must be proof of the opposite" into as bald a no true scotsmanism as I've seen recently. It's like fallacy central here.
- Dylan16807 8y agoAn argument of the form "many X failed, but a new X might not" is not a form of no true scotsman. It would only be no true scotsman if the claim was "X always wins, and Itanium wasn't X" But anyway I think they're making a fair argument. If something takes an enormous technical effort to switch to, and is similar in performance, nobody is going to put in that effort. This is emphatically not evidence that the idea "doesn't work". I believe if you could retroactively wipe out the last decade of improvement on x86 and Arm, and redirect all of that development effort to VLIW, the resulting chips and software would perform just fine by current standards.
- Symmetry 8y agoI think you're being too dismissive here. First of all, VLIW has been hugely successful in DSP cores. Your phone probably has a few in it. Second, Itanium wasn't great but it wasn't terrible either. And the Transmeta/NVidia lineage have also been not terrible. There isn't any reason to choose them over a conventional OoO processor absent security concerns but if they really do help with security concerns then these approaches bear careful investigation.