5 ms·

The details are all out there. The Pixelbook’s m3 is an 8100Y. This uses Kaby Lake cores. There are plenty of details on Kaby Lake here: https://en.wikichip.org

by skavi 4y ago

The details are all out there. The Pixelbook’s m3 is an 8100Y. This uses Kaby Lake cores. There are plenty of details on Kaby Lake here: https://en.wikichip.org/wiki/intel/microarchitectures/kaby_lake https://en.wikichip.org/wiki/intel/microarchitectures/kaby_l... There were also plenty of details released on Google’s Tensor SoC in the recent Pixels. Of the top of my head, I know it uses two X1 cores and is manufactured on a Samsung process.

rektide 4y ago
How did you/we find out it uses a 8100Y? What was the earliest date this was known? Was this knowable before the first devices started arriving at users doors? ARM in general has been pretty opaque. This article shows so wonderfully precisely how many details we used to be in tune to. There's so many buffers, caches, lookups, &c. We used to be able to know it all: the cpu makers used to often tell us what the architecture was, so we could make pretty pictures like this. Comapratively, knowing something is a Cortex A53 will tell you some of this general picture, but I think a decent bit of it is configurable too. Often we can go do the basic research, find out what chip a phone uses, go lookup L2 and L3 cache sizes, eventually (often after release, once people can test & find out). I don't know if any of these are knowable before devices start arriving, to be honest. I don't know how many more tuneable parameters a Cortex A53 has. Ex: can the caches have different associativities or are those fixed? Since we've talked about Tensor some, it might be interesting to go review & compare this article versus what Anandtech (a pretty fine deep-tech site) has been able to unearth on Tensor[1]. It's not clear what all their sources are, but to be fair it's not immediately obvious what cheese & chips's sources were here. The article itself cites a code-drop that they seemingly mined to find a bunch of the specifics. But again, I just have no idea how many parameters are tuneable- we know already from above Cortex A53 <> Cortex A53, that at least cache size can vary, but no idea if cache configuration or parameters can vary. The article itself highlights that not only do they not understand the memory caching subsystem, for example, they don't even know if it's the same or different than the Exynos: > Google also integrated 8MB of system cache, and for me it isn’t exactly clear if this is the same IP Samsung uses on the Exynos 2100. Seemingly they’re both 8MB, but I’m leaning towards saying that it’s a different IP, or at the very least a different version of the IP, as there are some real differences in the way it’s architected and how it behaves. I think of the Alex Russell tweets about Cortex A53[2], which can be anything from an awful forsaken terrible chip to an ok reasonable chip. Depending on how it's built up. Consumers generally just don't know much. Even the educated ones, in ARM land, have enormous fantastic limits of knowability: we take so much on faith. We can't assess what we are buying. ARM is opaque. Oh and it's also still sometimes selling us a 10 year old core (A53's decennial is October. Perhaps the upcoming A510 is "A5-10", a celebration of yet another decade of the same core? Frowny face.). [1] https://www.anandtech.com/show/17032/tensor-soc-performance-efficiency https://www.anandtech.com/show/17032/tensor-soc-performance-... [2] https://twitter.com/slightlylate/status/1180484877105483777 https://twitter.com/slightlylate/status/1180484877105483777
- eklitzke 4y ago
  I generally agree with your sentiment here, but one thing I will point out is that this stuff isn't always totally transparent with AMD and Intel either. Intel and AMD release a lot of technical details about new and upcoming microarchitectures, but still it isn't until the chips are released and people run specific benchmarks on them that details emerge. For example, if you've done any x86 micro-optimization you've probably used Agner Fog's instruction tables.^[1] These instruction tables and the uop breakdowns are generated empirically, so they aren't updated until after someone has real hardware to test with. Likewise for things like the branch predictor measurements, BTB latency, etc. presented in this article, these come from empirical testing not from data sheets disseminated by Intel. Things are certainly much worse with ARM partly because, as you point out, ARM is meant to be high customizable by vendors. Additionally there's an increasing trend of vendors creating even more highly differentiated ARM CPUs. At the same time though it's not that easy for users to empirically measure these CPUs the same way they can x86 hardware. With a regular Linux distro and a desktop x86 CPU it's pretty straightforward to set up some measurement environment for code by doing things like creating a dedicated cpuset for your tests and disabling frequency scaling. On the other hand I have no idea how I would do that on my Pixel 6. The same site that wrote this article recently did a breakdown of Amazon's Graviton 3 chips: https://chipsandcheese.com/2022/05/29/graviton-3-first-impressions/ https://chipsandcheese.com/2022/05/29/graviton-3-first-impre... . That's because you can actually set up a normal Linux environment on an AWS instance w/ Graviton CPUs and run benchmarks to figure out details about their microarchitecture, not because Amazon released detailed spec sheets on the CPUs. Again I agree with your overall sentiment and I also wish things were more transparent. But learning about the details of these CPUs using clever micro benchmarks has been the norm forever. If you're a huge purchaser (Google, Facebook, Amazon, etc.) you can get access to a lot more information but this hasn't really ever been an option for consumers. [1] https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf
  - rektide 4y ago
    Fully agreed everywhere, thanks. There used to be a little more bragging about the enhancements up front in x86 land, but yes, a lot of it comes down to reverse engineering. The one place I'd redouble my scorn is that so many modern devices don't even list their chip, not even it's generation. Google in particular has been a major force in reducing the "tech specs" down to "Intel i5" or some-such preposterously useless "description". Is this a 10W part? A 35W part? What generation? How many cores? But absolutely. A huge amount of these details have, for a long time, been carefully tested for &- I lack a better term- reverse-engineered, from shipped devices. But historically we'd at least know, before purchasing, what core it was we were purchasing.

by skavi 4y ago

rektide 4y ago

How did you/we find out it uses a 8100Y? What was the earliest date this was known? Was this knowable before the first devices started arriving at users doors? ARM in general has been pretty opaque. This article shows so wonderfully precisely how many details we used to be in tune to. There's so many buffers, caches, lookups, &c. We used to be able to know it all: the cpu makers used to often tell us what the architecture was, so we could make pretty pictures like this. Comapratively, knowing something is a Cortex A53 will tell you some of this general picture, but I think a decent bit of it is configurable too. Often we can go do the basic research, find out what chip a phone uses, go lookup L2 and L3 cache sizes, eventually (often after release, once people can test & find out). I don't know if any of these are knowable before devices start arriving, to be honest. I don't know how many more tuneable parameters a Cortex A53 has. Ex: can the caches have different associativities or are those fixed? Since we've talked about Tensor some, it might be interesting to go review & compare this article versus what Anandtech (a pretty fine deep-tech site) has been able to unearth on Tensor[1]. It's not clear what all their sources are, but to be fair it's not immediately obvious what cheese & chips's sources were here. The article itself cites a code-drop that they seemingly mined to find a bunch of the specifics. But again, I just have no idea how many parameters are tuneable- we know already from above Cortex A53 <> Cortex A53, that at least cache size can vary, but no idea if cache configuration or parameters can vary. The article itself highlights that not only do they not understand the memory caching subsystem, for example, they don't even know if it's the same or different than the Exynos: > Google also integrated 8MB of system cache, and for me it isn’t exactly clear if this is the same IP Samsung uses on the Exynos 2100. Seemingly they’re both 8MB, but I’m leaning towards saying that it’s a different IP, or at the very least a different version of the IP, as there are some real differences in the way it’s architected and how it behaves. I think of the Alex Russell tweets about Cortex A53[2], which can be anything from an awful forsaken terrible chip to an ok reasonable chip. Depending on how it's built up. Consumers generally just don't know much. Even the educated ones, in ARM land, have enormous fantastic limits of knowability: we take so much on faith. We can't assess what we are buying. ARM is opaque. Oh and it's also still sometimes selling us a 10 year old core (A53's decennial is October. Perhaps the upcoming A510 is "A5-10", a celebration of yet another decade of the same core? Frowny face.). [1] https://www.anandtech.com/show/17032/tensor-soc-performance-efficiency https://www.anandtech.com/show/17032/tensor-soc-performance-... [2] https://twitter.com/slightlylate/status/1180484877105483777 https://twitter.com/slightlylate/status/1180484877105483777

eklitzke 4y ago
I generally agree with your sentiment here, but one thing I will point out is that this stuff isn't always totally transparent with AMD and Intel either. Intel and AMD release a lot of technical details about new and upcoming microarchitectures, but still it isn't until the chips are released and people run specific benchmarks on them that details emerge. For example, if you've done any x86 micro-optimization you've probably used Agner Fog's instruction tables.^[1] These instruction tables and the uop breakdowns are generated empirically, so they aren't updated until after someone has real hardware to test with. Likewise for things like the branch predictor measurements, BTB latency, etc. presented in this article, these come from empirical testing not from data sheets disseminated by Intel. Things are certainly much worse with ARM partly because, as you point out, ARM is meant to be high customizable by vendors. Additionally there's an increasing trend of vendors creating even more highly differentiated ARM CPUs. At the same time though it's not that easy for users to empirically measure these CPUs the same way they can x86 hardware. With a regular Linux distro and a desktop x86 CPU it's pretty straightforward to set up some measurement environment for code by doing things like creating a dedicated cpuset for your tests and disabling frequency scaling. On the other hand I have no idea how I would do that on my Pixel 6. The same site that wrote this article recently did a breakdown of Amazon's Graviton 3 chips: https://chipsandcheese.com/2022/05/29/graviton-3-first-impressions/ https://chipsandcheese.com/2022/05/29/graviton-3-first-impre... . That's because you can actually set up a normal Linux environment on an AWS instance w/ Graviton CPUs and run benchmarks to figure out details about their microarchitecture, not because Amazon released detailed spec sheets on the CPUs. Again I agree with your overall sentiment and I also wish things were more transparent. But learning about the details of these CPUs using clever micro benchmarks has been the norm forever. If you're a huge purchaser (Google, Facebook, Amazon, etc.) you can get access to a lot more information but this hasn't really ever been an option for consumers. [1] https://www.agner.org/optimize/instruction_tables.pdf https://www.agner.org/optimize/instruction_tables.pdf
- rektide 4y ago
  Fully agreed everywhere, thanks. There used to be a little more bragging about the enhancements up front in x86 land, but yes, a lot of it comes down to reverse engineering. The one place I'd redouble my scorn is that so many modern devices don't even list their chip, not even it's generation. Google in particular has been a major force in reducing the "tech specs" down to "Intel i5" or some-such preposterously useless "description". Is this a 10W part? A 35W part? What generation? How many cores? But absolutely. A huge amount of these details have, for a long time, been carefully tested for &- I lack a better term- reverse-engineered, from shipped devices. But historically we'd at least know, before purchasing, what core it was we were purchasing.