[WIP] Micro architecture parsing by GuillaumeDIDIER · Pull Request #177 · gz/rust-cpuid

GuillaumeDIDIER · 2024-05-26T10:20:27Z

Implement micro-architecture parsing, as proposed in #176

This design attempts to capture the subtleties of Skylake and Alder Lake (Hybrid SoCs, and many different SoCs variation using the same core design).

Intel
AMD

This is meant to enable better API stability if we add partial support for other CPU vendors, such as VIA or Cyrix.

This module supports parsing the CPU family, model and stepping to identify the micro-architecture. This requires listing all the known micro-architecture in the library. (Recompilation will be needed to add support for new uarch) Because Intel micro-architecture are rather messy, especially around Skylake, microarchitecture are mapped onto a structure referencing - the vendor - the CPU core design (or core design for hybrid CPUs such as Alder Lake) - the micro-architecture codename of the SoC. For instance AlderLake is {Intel, Heterogeneous{P: GoldenCove, E: Gracemont}, AlderLake} All the different Skylake recycling are {Intel, Homogenous(Skylake), _) As teh set of combination recognized is fixed at compile time, they are encoded as constants and the function returns static references to the correct structure. All the known combination are included in an array (MICRO_ARCHITECTURE_LIST) The list of micro-architectures in the Enums is rather exhaustive but not definitive, but only a token number of architectures are currently parsed.

GuillaumeDIDIER · 2024-05-26T10:22:17Z

Before I implement the whole parsing, I wouldn't mind a review of the design.

I am also considering changing Heterogeneous to Hybrid, and Homogenous to something simpler to spell, if you have any idea.

@gz for a first review.

GuillaumeDIDIER · 2024-05-26T10:24:57Z

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive.

This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

- Export the uarch module - Export the Vendor enum

- Split NetBurst between 32-bit and 64-bit architectures (the latter identified as Prescott) - Fix typo on Willamette

gz

hey, nice work! I added some comments

gz · 2024-06-03T23:05:08Z

src/lib.rs

-where
-    F: Fn(u32, u32) -> CpuIdResult + Clone,
+    where
+        F: Fn(u32, u32) -> CpuIdResult + Clone,


is this from cargo fmt?

I will check, but I would bet on my IDE running rustfmt. (JetBrain’s Rust Rover)

gz · 2024-06-03T23:06:08Z

src/lib.rs

+#[non_exhaustive]
 #[derive(Debug, Eq, PartialEq, Clone, Copy)]
-enum Vendor {
+pub enum Vendor {


we should try to have docs for all public types

gz · 2024-06-03T23:06:16Z

src/uarch.rs

+use crate::Vendor::{Intel, Amd};
+
+#[non_exhaustive]
+pub enum CoreArch {


will need docs

gz · 2024-06-03T23:23:48Z

src/uarch.rs

+pub enum CoreArch {
+    // Not including Intel micro-architecture without CPUID suport, for now.
+    // Intel Micro-architectures (with CPUID support)
+    i486,


there is some naming warning for this

variant i486 should have an upper camel case name

Maybe we can make sure we match with information from here https://github.com/intel/perfmon?

gz · 2024-06-03T23:25:17Z

src/uarch.rs

+use crate::Vendor::{Intel, Amd};
+
+#[non_exhaustive]
+pub enum CoreArch {


This seems to be sometimes using the "prototype" names for the platform and sometimes the "official" product names, is there some guidelines you followed for picking them?

gz · 2024-06-03T23:26:01Z

src/uarch.rs

+#[non_exhaustive]
+pub enum Core {
+    Homogenous(CoreArch),
+    Heterogeneous { P: CoreArch, E: CoreArch },


this could maybe just be Vec<CoreArch> or &static [CoreArch]? seems tricky to be sure there are only two cores especially in the future

That was one of the options, I felt I was perhaps a bit more painful to handle, but I will make that change. I think ARM land has some CPUs with three types of core too.

gz · 2024-06-03T23:27:05Z

src/uarch.rs

+}
+
+#[non_exhaustive]
+pub enum UArch {


maybe call this MicroArchitecture?

gz · 2024-06-03T23:27:19Z

src/uarch.rs

+    Zen2,
+    Zen3,
+    Zen4,
+


drop empty line?

gz · 2024-06-03T23:27:46Z

src/uarch.rs

+
+}
+
+pub struct MicroArchitecture {


This seems to be the same name as UArch?

gz · 2024-06-03T23:30:32Z

src/uarch.rs

+// ===================
+// Micro-Architectures
+// ===================
+const INTEL_486: MicroArchitecture = MicroArchitecture {


maybe all this could be parsed at build time from some csv file and generated with the phf library or similar?

(not strictly necessary of course, just wondering if it maybe makes things easier)

I definitely remarked that my design required a lot of boilerplate that could be autogenerated.

Coming back to this after a bunch of hectic months, what exactly is the phf library ?

It seems it will be nicer to generate a bunch of things from CSV files.

mert-kurttutan · 2024-06-04T10:44:02Z

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive.

This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

Is this breaking change (due to non_exhaustive attribute on vendor) necessary? If not, it might be better to have at least one version without breaking changes (minor version update). Then, introduce this breaking change with major version update?

GuillaumeDIDIER · 2024-06-04T13:01:24Z

Note, because adding more vendor in the future seems possible, I've marked the Vendor enum as non_exhaustive, and all the micro-architecture ones will also be non_exhaustive.
This is a breaking change for users, a major version will be needed, but then adding new vendors or micro-architectures will not require breaking changes as they would otherwise have.

Is this breaking change (due to non_exhaustive attribute on vendor) necessary? If not, it might be better to have at least one version without breaking changes (minor version update). Then, introduce this breaking change with major version update?

I think currently the vendor enum is not public, which should make it non breaking (but I am not confident about it).

If it is, however, I agree with splitting this into 2 steps.

GuillaumeDIDIER · 2025-02-26T20:22:47Z

I have also found a very helpful source, which is Intel own code in the linux kernel https://github.com/torvalds/linux/blob/master/arch/x86/include/asm/intel-family.h

GuillaumeDIDIER added 2 commits May 26, 2024 12:05

Make Vendor non exhaustive

57db99a

This is meant to enable better API stability if we add partial support for other CPU vendors, such as VIA or Cyrix.

GuillaumeDIDIER added 3 commits May 27, 2024 14:50

Rust fmt on lib.rs

a71e2ff

Visibility changes:

6219fa8

- Export the uarch module - Export the Vendor enum

Add parsing support for P6 and Netburst

9792d3c

- Split NetBurst between 32-bit and 64-bit architectures (the latter identified as Prescott) - Fix typo on Willamette

gz reviewed Jun 3, 2024

View reviewed changes

Conversation

GuillaumeDIDIER commented May 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeDIDIER commented May 26, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeDIDIER commented May 26, 2024

Uh oh!

gz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mert-kurttutan commented Jun 4, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GuillaumeDIDIER commented Jun 4, 2024

Uh oh!

GuillaumeDIDIER commented Feb 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

GuillaumeDIDIER commented May 26, 2024 •

edited

Loading

GuillaumeDIDIER commented May 26, 2024 •

edited

Loading

mert-kurttutan commented Jun 4, 2024 •

edited

Loading