191–200 of 232 posts
> In the good old days*, the speed of processors was well matched with the speed of memory access...Over the ensuing 35 years, processors have become very much faster, but memory only modestly so: a single Cortex-A53 in a Raspberry Pi 3 can execute an instruction roughly every 0.5ns (nanoseconds), but can take up to 100ns to access main memory. In real-world terms, what's the fastest processor we could build today wh…
Modern DDR4 SDRAM can run up to 2133Mhz, but DDR SDRAM is designed to increase speed by taking advantage of CPU caches. For peak performance reads occur in batches so one read command also fill the cache with nearby data. SRAM can go fast since that’s what caches are made with, but that’s expensive. Also it would need to be close to the CPU as wire latency is non-trivial at high clock speeds.
I was already on the lookout for a small ARM-based mini PC, just for doing financial transactions and record-keeping. Now that seems more pressing but I don't know of any such thing in existence. I tried doing that on RPi 3, but the IO seemed not up to the job -- the CPU appeared to be just about tolerable, but using micro SD as a disk was too slow and prone to failure (I'd have tried an external USB disk but I belie…
Earlier quoted context omitted.
Modern DDR4 SDRAM can run up to 2133Mhz, but DDR SDRAM is designed to increase speed by taking advantage of CPU caches. For peak performance reads occur in batches so one read command also fill the cache with nearby data. SRAM can go fast since that’s what caches are made with, but that’s expensive. Also it would need to be close to the CPU as wire latency is non-trivial at high clock speeds.
Something I don't understand is why SRAM is more expensive than SDRAM. Is it just the manufacturing volumes and/or manufacturing yield, or are there architectural differences that make SRAM more expensive?
Earlier quoted context omitted.
Something I don't understand is why SRAM is more expensive than SDRAM. Is it just the manufacturing volumes and/or manufacturing yield, or are there architectural differences that make SRAM more expensive?
Each "bit" in SRAM is bigger than each "bit" in DRAM. Typical SRAM uses six transistors for each "bit", while typical DRAM uses one transistor and one capacitor. Bigger chips means less chips per wafer, and a larger chance for a chip to have a manufacturing defect.
Earlier quoted context omitted.
It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747, even if it is factually correct. I didn't downvote you (can't even do it), but I suspect you are getting downvoted because your analogy is so off the mark that it can't even be called "Apples vs Oranges". edit: replying to the "why the downvotes" which has since been edited away
> It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747 Actually, if it's true that a car gets a better mileage than a big airplane (more in one vehicle = more efficient, people seem to believe) I would find that interesting. Similarly, I can see how OP thinks it's ironic that a very cheap machine is not vulnerable whereas a quite expensive piece of equipment is, making it seeming…
Earlier quoted context omitted.
> It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747 Actually, if it's true that a car gets a better mileage than a big airplane (more in one vehicle = more efficient, people seem to believe) I would find that interesting. Similarly, I can see how OP thinks it's ironic that a very cheap machine is not vulnerable whereas a quite expensive piece of equipment is, making it seeming…
Transatlantic flights average 75 mpg per passenger, but can be up to almost 100 mpg per passenger: https://en.wikipedia.org/wiki/Fuel_economy_in_aircraft Jet fuel is 37.4 MJ/L; compare to gasoline at 34.2: https://en.wikipedia.org/wiki/Energy_density#Energy_densitie... An electric car will have up to 150 miles-per-gallon equivalent (aka 150 miles per the same amount of energy that's in one gallon of gasoline): https:…
Of course a 747 in a domestic Japan configuration will have more passengers than a typical BA 747 tatl flight with 100+ beds.
This is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space!…
This covers both Meltdown and Spectre. > Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use. The reason why Spectre is not a problem is because there is no branch predictor in these si…
Earlier quoted context omitted.
There is almost certainly a branch predictor even in these simple ARM cores.
There's no reason to predict a branch if you're not going to execute speculatively. I need to re-read the papers but I think the real problem isn't even speculative execution but allowing speculative cache changes. The notion that "gadgets" didn't even need to return properly was both amusing and eye opening for me. It doesn't matter because the result will be flushed anyway! ;-)
(Simplest cores have only static branch prediction though)
Earlier quoted context omitted.
Considering that on average you have a branch every 5 instructions and the reorder buffer of high performance OoO CPU is in the order of a hundred of instruction, such a CPU is pretty much running under speculation all the time (often of multiple branches at the same time). Not being able to fetch new cachelines when under speculation would be a huge blow, as exposing memory level parallelism is one of the most impor…
"Considering that on average you have a branch every 5 instructions and the reorder buffer of high performance OoO CPU is in the order of a hundred of instruction, such a CPU is pretty much running under speculation all the time (often of multiple branches at the same time)." Yes, it is. Remember, again, that the vast majority of those instructions can still be speculated, because the vast majority of instructions ar…
I think realistically the only safe and not completely performance crippling workaround will be, at the very least, to run any untrusted code under a separate address space (assuming that the cpu is immune from meltdown). That doesn't necessarily require a full blown separate process, but something like memory protection keys might work.
The alternative is full static analysis and source level annotations, which realistically is only going to be done for very few programs and will still be error prone.