"This will be, it is claimed, Arm's first-ever multithreaded CPU core. "
You are missing the S from SMT, it should read:
"This will be, it is claimed, Arm's first-ever simultaneously multithreaded CPU core. "
Arm will today announce its Cortex-A65AE processor core aimed at powering self-driving cars and in-vehicle entertainment. Somewhat buried in the bumph we glimpsed ahead of the launch, though, is something very curious. This will be, it is claimed, Arm's first-ever simultaneous multithreaded CPU core. As in, each core can run …
Pray tell, does it have anything to ensure that car control commands cannot be overridden by the effing media player ?
Or by the Internet, due to the frakkin' "continuous connectivity" we're all going to bask in ?
Because if not, well, there won't be much improvement, right ?
Nope it has not. Same as the current. The real solution for that is called wire cutters.
Current ones are Arm by the way. You will have extreme difficulty finding a car stereo with a multifunction display which is not running some sort of Android on an ARM SOC. The give-away is the "Licenses" item in the settings menu which has to exist for legal reasons. So from that perspective I do not quite get it why the article is mentioning the display in future tense. It is already there (and we hate it).
Disclaimer - I am a bit biased because I had the stupid Pioneer P.O.S. called AVIC (the one that cannot even order MP3 tracks correctly) shut down my engine on the Autobahn near Karlsruhe while driving this summer. So I am a bit biased... Just a bit... As biased as one can get when the display lights up the Christmas tree and the car loses power when you are overtaking a long line of lorries at 85mph.
ARM now being a design-only business, the security measures listed are a bit pointless since it is left to the manufacturer to abide by them -or not. Running everything in duplicate is good for safety but bad for performance, so most implementations can be expected to go with the cheap alternative and bypass the hardware security because word of the street is that everything can be dealt with in software, innit?
On a sidenote, I read the article as if these chips were designed to run both the car and the entertainment system, on the same chip ? I'm sure I'm wrong because that would be incredibly stupid but I can't find any element to the contrary, and Voland's right hand￼'s comment seems to indicate that some manufacturers actually already went that route.
Icon for the obvious consequences.
This post has been deleted by its author
The way I understood it (which may be wrong), on Intel, effectively each core has two ALUs and one FPU. So hyperthreading increases throughput unless your work is mostly floating point - in which case the extra thread switches would be counterproductive. I don't know for sure, but I would've thought that a lot of things in a self-driving car are floating point. But maybe those are pushed off into a GPU.
Modern Intel CPU cores have a 14 stage pipeline, SMT2 (2 threads per 1 core) means that you can have 2 different processes being processed at 2 different stages of the pipeline. The POWER9 architecture has SMT8 (8 threads per 1 core) so 8 stages of the pipeline can be active at any one point.
There are rumors that AMD might be moving to SMT4 (4 threads per 1 core) with Zen 3 in 2020.
I thought the idea of “hyperthreading” was that you could swap from one thread to the other much more quickly once there were two program counters etc. in hardware, rather than having to context switch via the kernel, so you can switch to the other thread when you have a branch misprediction or cache miss.
Now that we care about one thread snooping on another’s branch predictor and cache behaviour for security reasons, things get more complicated. On one hand, a snooping thread that’s hyperthreaded on the same core is in a better position to snoop than one that is more decoupled. On the other hand, having hyperthreading means that you can get away with a worse (and hence more secure) branch predictor, since the core will be kept busy after mispredictions by the other thread - assuming that there is work for another thread to do. I’m curious to know if Arm have any security motivation for announcing this now.