[Matteo] bought a new Raspberry Pi 4. Why not? You get a quad-core ARM processor, up to 4 GB of RAM, and a gigabit Ethernet port for $35 $35-55. However, the default operating system is still a 32-bit system and doesn’t take advantage of the Pi 4’s 64-bit capable CPU. So he installed a light version of 64-bit Debian and ran some benchmarks for the Raspberry Pi 4 running both 32-bit and 64-bit operating systems.
It really shouldn’t be surprising that the 64-bit OS did better in nearly every test. If anything is surprising, it may be that the difference is so pronounced. Some of the benchmarks, like Dhrystones, probably don’t relate much to real-life usage. But some things, like computing a hash, is something you probably do pretty often in normal usage, and the timing difference is pronounced.
The new Raspberry Pi 4 is out, and slowly they’re working their way from Microcenters and Amazon distribution sites to desktops and workbenches around the world. Before you whip out a fancy new USB C cable and plug those Pis in, it’s worthwhile to know what you’re getting into. The newest Raspberry Pi is blazing fast. Not only that, but because of the new System on Chip, it’s now a viable platform for a cheap homebrew NAS, a streaming server, or anything else that requires a massive amount of bandwidth. This is the Pi of the future.
The Raspberry Pi 4 features a BCM2711B0 System on Chip, a quad-core Cortex-A72 processor clocked at up to 1.5GHz, with up to 4GB of RAM (with hints about an upcoming 8GB version). The previous incarnation of the Pi, the Model 3 B+, used a BCM2837B0 SoC, a quad-core Cortex-A53 clocked at 1.4GHz. Compared to the 3 B+, the Pi 4 isn’t using an ‘efficient’ core, we’re deep into ‘performance’ territory with a larger cache. But what do these figures mean in real-world terms? That’s what we’re here to find out.
The computer security vulnerabilities Meltdown and Spectre can infer protected information based on subtle differences in hardware behavior. It takes less time to access data that has been cached versus data that needs to be retrieved from memory, and precisely measuring time difference is a critical part of these attacks.
Web browsers can’t change processor cache behavior, but they could take away malicious code’s ability to exploit them. Browser makers are intentionally degrading time measurement capability in the API to make attacks more difficult. These changes are being rolled out for Google Chrome, Mozilla Firefox, Microsoft Edge and Internet Explorer. Apple has announced Safari updates in the near future that is likely to follow suit.
After these changes, the time stamp returned by performance.now will be less precise due to lower resolution. Some browsers are going a step further and degrade the accuracy by adding a random jitter. There will also be degradation or outright disabling of other features that can be used to infer data, such as SharedArrayBuffer.
These changes will have no impact for vast majority of users. The performance API are used by developers to debug sluggish code, the actual run speed is unaffected. Other features like SharedArrayBuffer are relatively new and their absence would go largely unnoticed. Unfortunately, web developers will have a harder time tracking down slow code under these changes.
Browser makers are calling this a temporary measure for now, but we won’t be surprised if they become permanent. It is a relatively simple change that blunts the immediate impact of Meltdown/Spectre and it would also mitigate yet-to-be-discovered timing attacks of the future. If browser makers offer a “debug mode” to restore high precision timers, developers could activate it just for their performance tuning work and everyone should be happy.
2016 was a great year for Open Hardware. The Open Source Hardware Association released their certification program, and late in the year, a few silicon wizards met in Mountain View to show off the latest happenings in the RISC-V instruction set architecture.
The RISC-V ISA is completely unlike any other computer architecture. Nearly every other chip you’ll find out there, from the 8051s in embedded controllers, 6502s found in millions of toys, to AVR, PIC, and whatever Intel is working on are closed-source designs. You cannot study these chips, you cannot manufacture these chips, and if you want to use one of these chips, your list of suppliers is dependent on who has a licensing agreement with who.
We’ve seen a lot of RISC-V stuff in recent months, from OnChip’s Open-V, and now the HiFive 1 from SiFive. The folks at SiFive offered to give me a look at the HiFive 1, so here it is, the first hands-on with the first Open Hardware microcontroller.
The spec bullet list for the latest Raspberry Pi begins as you’ve already heard: WiFi and Bluetooth, now standard. While this is impressive itself, it doesn’t tell the whole story. The Pi 3, with an ARM Cortex A53, is up to 50% faster than the Pi 2 from last year. That’s an astonishing improvement in just 12 short months.
In playing with the Pi 3 for a few hours, it’s apparent the Pi 3 is fast. It passes a threshold of usability. The Raspberry Pi isn’t a computer that just sits on a shelf and runs a few cron jobs and blinks LEDs anymore – this is a computer that’s usable as a computer. But how fast is it? By stroke of luck, the official website for the Cortex A53 gives us a direct comparison between this chip and the CPU in the Raspberry Pi 2:
In real devices, the performance improvement from the Pi 2 to the Pi 3 is somewhere between 40 and 60 percent. At least that’s what ARM and the Raspberry Pi foundation are claiming. Is this true? There are tests we can run, and the marketing speak, for once, isn’t too terribly off the mark.