The C1-ultra has a decode of 10 instructions but can issue up to 23 uop per cycle, that’s a good bit wider than any other CPU. In particular, I believe it’s the first CPU to have a 4th load pipeline.
All 10 cores support the same extensions. It’s silly to implement an SoC any other way, and it’s been a decade since someone has last made that mistake.
It's been a long time since anyone tried to actually ship a chip with different instruction set support enabled across its cores, but Intel has spent the past several years shipping consumer parts where they had to disable some features (AVX-512) on their P-cores to bring them down to the level of what their E-cores support, because they didn't plan ahead for doing a heterogeneous chip with those two microarchitectures. Toggling off some instructions in microcode for some cores is quite different from having two microarchitectures that are each designed to implement the same instruction set but with different performance and power characteristics.
Well the original article is also about RISC-V isn't a great ISA for embedded either, and how that's supremely disappointing because there's no inherent reason why the designers couldn't have learned from decades of ISA research and made it suck even a little less. OP doesn't even defend the ISA committee (unlike HN, somehow...)
As much as people complain about warts in other ISAs like x86, their design decisions made sense back when they were made (or at least, no one really knew better)
There's an order of magnitude difference in speed requirements between file format parsing and image decoding, then another order of magnitude difference to video decoding. Even rav1d reuses dav1d's assembly (most of the actual runtime) to approach its speed.
OP dances around the key context that this isn’t hidpi, but rather a 3rd party hack that uses hidpi rendering to supersample their “native” 4k resolution by 2x, since the end result looks more pleasing to them than the native 4k render.
It’s actually around 1.5x for the default resolution out of the box and 1.3x for “more space” setting on m1/m2 MacBook Air. 1.1x supersampling on Macs makes it worse because down sampling to pixel alignment becomes a hot mess.
Those numbers of 1470x956 are “points” or “looks like” values, not the size of the frame buffer. The frame buffer for “looks like 1470x956” is exactly 2x that, or 2940x1912. On a 2560x1664 display, that’s a 1.148x scale factor. Again, nowhere near 2x, even on the “more space” setting.
If you’re counting by the framebuffer than the only 2x is the hidpi-forced-into-lowdown like the link suggest. The ratios I’m referring to is the UI scaling against the physical display pixel dimensions.
Apple basically settles into 220 dpi physical displays (250 moc MacBook Pro), rendering UI at a 2x scale as a default, except for MacBook Airs.
And that itself is a recent policy change from just in the last two months; as of January United's official policy [1] matched the FAA's in only requiring checked devices to be powered down
reply