Ниже мы разберёмся, насколько Р и Е ядра отличаются по скорости и почему. Америки мы не откроем — производительные ядра действительно быстрее, но более детальное понимание почему они быстрее может помочь использовать компьютер чуть более эффективно (но быстрее чем он есть, он, безусловно не станет, не ждите чудес). Это просто пятничное упражнение.

На самом деле всё началось с того, что я любопытства ради запустил мой любимый бенчмарк SHA256 (который использовался в предыдущей статье про гипер-трединг) и н��блюдал прекрасное:

>sha256b.exe
>Base Frequency 2303 MHz
9BC1B2A288B26AF7257A36277AE3816A7D4F16E89C1E7E77D0A5C48BAD62B360
8>225 MiB/s
11>225 MiB/s
2>66 MiB/s
22>71 MiB/s 
24>67 MiB/s
22>68 MiB/s
18>67 MiB/s
20>68 MiB/s
20>70 MiB/s

Бодро начавшись на Р ядрах и выдавая 225 МБ в секунду, тест довольно быстро "съезжал" на Е ядра и производительность падала втрое — до 70 МБ/с. Так быть не должно, при незагруженном процессоре однопоток должен лететь как по пустому автобану — "тапка в пол". Я погрешил на распоследнюю Windows 25H2, поставил обратно старую добрую LTSC 24H2, и проблема ушла, и я начал было писать злую статью, попутно разбираясь с 25Н2, но ларчик открывался просто — накатывая в обеденный перерыв обновления на 25Н2, я подключился к корпоративной сети, и мне прилетели не только обновления, но и политики электропитания (хоть комп и не был в домене), а админ наш, помешанный на "эко" технологиях, сумел выставить так, что любое приложение почти сразу после запуска автоматом переходило в "экономичный" режим (вот знайте, что так тоже можно). Лечится на самом деле просто — либо надо запускать с повышенным приоритетом, либо отключить powerthrottling для этого приложения через powercfg, а к версии Windows это не имело никакого отношения — что LTSC 24Н2, что свежая 25Н2 плюс минус одинаковы по производительности, но мне стало жаль выкидывать уже написанное "в помойку", так что я просто оставлю это здесь, может кому-то будет интересно.

А упражняться мы будем на ноутбуке "Lenovo ThinkPad P16 Gen 2". Сам по себе ноутбук ничего выдающегося не представляет, к покупке рекомендовать не буду по многим причинам (обзор этого поделия не входит в план статьи, от легендарного IBM ThinkPad тут лишь точечка над i). А вот процессор там довольно интересный. Как я уже писал, я начал с 25H2, даже на русский переключил:

Вот что показывает нам диспетчер задач сразу после установки:

Какая-то минимальная активность есть, но в основном загрузка по нулям и в целом примерно так и должна выглядеть "винда здорового компа" (пока она "из коробки").

Итак, мы тут видим два десятка ядер и 28 логических. ОС Windows особо не утруждает себя показом количества P и E ядер, тут (в предположении что производительные ядра гипер-тредированные) любопытному пользователю предлагается решить в уме несложную систему из двух линейных уравнений:

Откуда мы получаем, что у нас восемь Р ядер и двенадцать Е.

CPU-Z именно это и показывает (внизу в окошке Cores):

Здесь, кстати, любопытно не только количество ядер, но и кэш. Как мы помним из предыдущей статьи, у пар гипертредированных ядер кэш первого и второго уровня общий, поэтому у нас есть восемь раз по 48 КБ для данных и 32 КБ для инструкций для восьми Р ядер, а вот у Е ядер кеш данных поменьше, а вот инструкций — побольше и он индивидуальный для каждого Е ядра. С кэшем второго уровня тоже любопытно — у Р ядер тут просто по два мегабайта на ядро, а вот Е ядра сгруппированы в три группы по четыре ядра, и для каждой группы тут 4 мегабайта (интернет говорит, что примерно так устроены некоторые Атомы). Суммарно это даёт 16 МБ кэша второго уровня для Р ядер и 12 МБ для Е, что в менеджере задач и наблюдаем. В общем это, вероятно, лучше чем раскидать по мегабайту на ядро. Ну а кэш третьего уровня просто 30 мегабайт на всё про всё.

В том же CPU-z можно побенчмаркать эти ядра, причём Р и Е раздельно, вот что получится:

Результат в общем предсказуем, приятно видеть, что Е ядра реально независимы — двенадцать потоков дают почти двенадцатикратное ускорение, но они и медленнее чем Р, и судя по этому бенчмарку почти в два раза (784,1/430.0 = 1,823), но на самом деле всё не так плохо.

Информацию AIDA64 я оставлю под спойлером.

простыня скриншотов

AIDA P Core

AIDA E-Core

AIDA Benchmark

Леново "с завода" всегда поставит вам одну плашку, хоть на двухканальном ноуте, хоть на Xeon десктопе (а там ведь четыре канала).

Давайте для начала разберёмся, какие вообще ядра Р, а какие Е. В предыдущей статье про гипер-трединг я жёстко кодировал эти маски, но, как резонно заметили в комментариях, по фен-шую надо бы спросить у ОС о типах ядер через GetLogicalProcessorInformation(). Вот с этого домашнего задания мы и начнём наши упражнения, причём воспользовавшись ИИ, чего я совершенно не стесняюсь:

#include <windows.h>
#include <iostream>
#include <vector>
#include <bitset>
#include <iomanip> // For setw and setfill
#include <string>

using namespace std;
#define LTP_PC_SMT 0x1 // SMT (Hyperthreading) flag
#define CORE_INFO PSYSTEM_LOGICAL_PROCESSOR_INFORMATION_EX

int main() {
	cout << "Hello Processor!\n";
	DWORD len = 0;
	GetLogicalProcessorInformationEx(RelationProcessorCore, nullptr, &len);
	vector<uint8_t> buffer(len);
	auto info = reinterpret_cast<CORE_INFO>(buffer.data());
	int core = 0;
	if (GetLogicalProcessorInformationEx(RelationProcessorCore, info, &len)) {
		uint8_t* ptr = buffer.data();
		while (ptr < buffer.data() + len) {
			CORE_INFO lpInfoEx = reinterpret_cast<CORE_INFO>(ptr);
			DWORD_PTR mask = lpInfoEx->Processor.GroupMask[0].Mask;
			bool hasHT = lpInfoEx->Processor.Flags & LTP_PC_SMT;
			int eff = lpInfoEx->Processor.EfficiencyClass; // 0 for P, >0 for E
			string coreType = eff == 0 ? "P core" : "E core";

			bitset<28> maskBits(mask);
			cout << "Core " << setfill(' ') << setw(2) << dec << ++core 
				<< " mask: 0x" << hex << setw(7) << setfill('0') << mask 
				<< " | (b" << maskBits << ")" << " | Type: " 
				<< coreType << " | HT: " << (hasHT ? "On" : "No") << endl;
			ptr += lpInfoEx->Size;
		}
	}
	else cerr << "Failed acquiring logical processor info." << endl;
	return 0;
}

И вот результат, наши двадцать ядер, первые восемь гипертредированы:

>coreInfo.exe
Hello Processor!
Core  1 mask: 0x0000003 | (b0000000000000000000000000011) | Type: E core | HT: On
Core  2 mask: 0x000000c | (b0000000000000000000000001100) | Type: E core | HT: On
Core  3 mask: 0x0000030 | (b0000000000000000000000110000) | Type: E core | HT: On
Core  4 mask: 0x00000c0 | (b0000000000000000000011000000) | Type: E core | HT: On
Core  5 mask: 0x0000300 | (b0000000000000000001100000000) | Type: E core | HT: On
Core  6 mask: 0x0000c00 | (b0000000000000000110000000000) | Type: E core | HT: On
Core  7 mask: 0x0003000 | (b0000000000000011000000000000) | Type: E core | HT: On
Core  8 mask: 0x000c000 | (b0000000000001100000000000000) | Type: E core | HT: On
Core  9 mask: 0x0010000 | (b0000000000010000000000000000) | Type: P core | HT: No
Core 10 mask: 0x0020000 | (b0000000000100000000000000000) | Type: P core | HT: No
Core 11 mask: 0x0040000 | (b0000000001000000000000000000) | Type: P core | HT: No
Core 12 mask: 0x0080000 | (b0000000010000000000000000000) | Type: P core | HT: No
Core 13 mask: 0x0100000 | (b0000000100000000000000000000) | Type: P core | HT: No
Core 14 mask: 0x0200000 | (b0000001000000000000000000000) | Type: P core | HT: No
Core 15 mask: 0x0400000 | (b0000010000000000000000000000) | Type: P core | HT: No
Core 16 mask: 0x0800000 | (b0000100000000000000000000000) | Type: P core | HT: No
Core 17 mask: 0x1000000 | (b0001000000000000000000000000) | Type: P core | HT: No
Core 18 mask: 0x2000000 | (b0010000000000000000000000000) | Type: P core | HT: No
Core 19 mask: 0x4000000 | (b0100000000000000000000000000) | Type: P core | HT: No
Core 20 mask: 0x8000000 | (b1000000000000000000000000000) | Type: P core | HT: No

Теперь мы можем расставить буковки:

Под линуксом, кстати, порядок может быть совершенно другой.

Теперь нам нужен бенчмарк — выше был написан на ассемблере, но по ходу экспериментов ИИ набросал мне ещё один на Расте, тут всё просто, меньше тридцати строчек кода:

use std::time::{Duration, Instant};
use sha2::{Sha256, Digest};
use hex; // for hex encoding

fn main() {
    let data = vec![b'a'; 1024 * 1024]; // 1 MiB of 'a'

    // Compute the digest once and print it as hex
    let mut hasher = Sha256::new();
    hasher.update(&data);
    let result = hasher.finalize();
    println!("SHA-256 digest of 1 MiB 'a': {}", hex::encode(result));

    // Run continuous hashing speed measurement
    loop {
        let start = Instant::now();
        let mut count = 0;

        while start.elapsed() < Duration::new(1, 0) {
            let mut hasher = Sha256::new();
            hasher.update(&data);
            let _ = hasher.finalize_reset();
            count += 1;
        }
        println!("Hashing speed: {} MiB/s", count);
    }
}

Минус теста на языке высокого уровня — это то, что машинный код зависит от компилятора и библиотек, а тест на ассемблере — он всегда будет такой.

Как бы то ни было, давайте запустим оба теста SHA256 на Р и Е ядрах и для сравнения на старом Xeon и посмотрим на результат технического прогресса:

Тут, собственно, возникает два вопроса — почему тест на Расте вдесятеро быстрее теста на ассемблере и почему тест на ассемблере заметно проcедает на Е ядрах, а вот тест на Расте даже чуть быстрее?

На первый вопрос ответ прост, если посмотреть на CPU-Z выше и также просто дизассемблировать программу на Расте, сразу станет видно, что там используются аппаратные SHA инструкции, их собственно три — SHA256MSG1, SHA256MSG2 и SHA256RNDS2. Грубо говоря там, где нам на "чистом" ассемблере потребовалось десять простых инструкций, тут всего одна, вот она, сила аппаратного ускорения! И да, Раст рулит. Опять же на процессоре без аппаратной поддержки SHA вполне себе работает, корректно определяя тип процессора и переключаясь на другую ветку.

А вот чтобы ответить на второй вопрос, почему производительность Р и Е примерно одинакова на Расте и различается на Ассемблере, нам потребуется небольшой технический ликбез.

Давайте ещё раз внимательно подумаем, почему Е ядра медленнее в тестах на ассемблере и CPU-Z? Если посмотреть в спецификацию на процессор, то сразу будет видно, что в турбо бусте Р ядра в теории могут разгоняться аж до 5,3 ГГц, а вот Е ядра — только до 3,8 ГГц.

P ядра, кстати, не всегда будут работать на такой частоте, в отличие от Е ядер, если занять их все, то частота дропнется, а насколько, это AIDA показывает, мультипликаторы вот здесь:

Это очевидное различие объясняет разницу на ассемблере — 5,3 ГГц против 3,8 — примерно такая пропорция и есть, да, но почему тогда Раст не проседает? На самом деле потому, что есть и вторая причина и второе различие.

У инструкций нашего фон Неймановского процессора есть два архиважных параметра — латентность (задержка) и пропускная способность.

Латентность — это количество циклов процессора, которые необходимы ему для выполнения данной инструкции.

А пропускная способность — это максимальное количество команд одного типа, которые могут быть выполнены за один тактовый цикл, если эти команды независимы. Обычно в документации указывают обратное значение для облегчения сравнения с задержкой, то есть пропускная способность, скажем, в четыре команды будет иметь значение 0.25 (иногда этот параметр также называют задержкой выдачи).

Чем эти два параметра меньше, тем лучше. В прошлой статье мы упражнялись с IMUL, у этой инструкции на архитектуре Haswell задержка 3, а пропускная способность 1. Это значит, что чтобы перемножить два числа в регистрах, нужно три такта процессора. А пропускная способность 1 означает, что процессор может начать выполнение умножения на каждом такте процессора. Закончит-то он через три такта, а начать может именно на каждом. Если у нас идут подряд несколько независимых IMUL инструкций, то он начнёт выполнять первую, на следующем такте — вторую, затем третью и тут выполнится первая, а он начнёт следующую и так далее, то есть они выполняются "параллельно" и как бы сдвинуты по времени на один такт. Это именно то, чем мы пользовались в предыдущей статье про гипер-трединг — там параллелились умножения с двух потоков. Обратная пропускная способность может быть как больше единицы, так и меньше. Если взять примитивную ADD, которую процессору выполнять куда как проще, то у неё латентность один такт, а вот пропускная способность на Haswell 0,33 (и, забегая вперёд, 0,25 на Р ядрах). Это значит, что результат выполнения будет доступен уже на следующем такте, а вот начать выполнение подряд идущих и независимых сложений он может аж три штуки за один такт! Скорее всего вы уже поняли в чём тут дело — Р и Е ядра отличаются не только по максимальной частоте турбо буста, но также и по ТТХ отдельных инструкций.

В таблицах uops есть данные по Р и Е ядрам для архитектуры двенадцатого поколения Adler Lake (Р ядра там на архитектуре Golden Cove, а Е ядра — Gracemont), но у нас i7-13850HX, здесь Р ядра построены на архитектуре Raptor Cove, а Е ядра — те же Gracemont, но это две разные архитектуры в одном флаконе Raptor Lake (бытует мнение, что Е ядра — это "неудачные" Р ядра, но нет, это действительно две совершенно разные архитектуры, в этом и есть "гибридность" процессора). Данных по Raptor Cove в таблицы uops.info пока не завезли, но не беда, нам просто надо научиться мерить латентность и пропускную способность отдельных инструкций и всё станет ясно.

Метод измерения очень прост — для измерения латентности мы будем кормить процессор одинаковыми, причём зависимыми командами, когда результат выполнения следующей зависит от предыдущей, это не будет давать возможность им параллелиться и мы получим чистое значение латентности, просто поделив количество тактов процессора на количество обработанных инструкций. А для пропускной способности мы будет скармливать независимые команды, они как раз таки будут "параллелиться", насколько умеют и в этом случае результат деления даст нам пропускную способность. Всё просто.

Но есть нюанс. Дело в том, что посчитать количество реальных тактов ядра процессора не так-то легко, так как необходимый нам счётчик недоступен из пользовательского режима, это привилегированная инструкция RDPMC (в теории можно работать в предположении, что мы всегда крутимся на частоте турбо буста, но это не наш метод, мы ж не ищем лёгких путей). Кстати, очень часто с этим счётчиком тактов путают значение, возвращаемое инструкцией RDTSC. Так вот, этот таймер не имеет ровно никакого отношения к реальным тактам ядер, он работает постоянно независимо от частоты индивидуальных ядер и строго на одной частоте. Он будет использоваться для точного замера времени (нам ведь хочется также видеть реальную частоту индивидуального ядра). Частота RDTSC, кстати может быть определена на старых процессорах типа Haswell исключительно экспериментально и лишь на современных процессорах (к каким и наш относится) её можно запросить через CPUID. Не путайте это значение с базовой частотой, которое показывает нам Менеджер задач в Windows. Это значение берётся из BIOS, и там может быть зашито другое значение, нежели выставлено фьюзами на кристалле процессора. В конкретном данном случае, если вы промотаете статью наверх, нам показывают 2,1 ГГц, но реально таймер работает на 2,3 ГГц, и это можно получить как из CPUID:

    ; CPUID with leaf 0x16
    mov eax, 0x16
    xor ecx, ecx ; Some CPUs require ECX = 0
    cpuid ; EAX = Base; EBX = Max; ECX = Bus (MHz)

Так и просто отсчитав одну секунду используя любую доступную функцию ОС, лучше всего QueryPerformanceCounter, а не банальный и неточный Sleep(1000):

L1:
	RDTSCP
	SHL RDX, 32
	OR RAX, RDX
	SUB RAX, R13 ; Subtract previous stamp
	MOV R12, RAX ; R12 is the TSC difference
	WinABI QueryPerformanceCounter, Ticks
	MOV R11, [Ticks] ; r14 — was initial
	SUB R11, r14
	CMP R11, r15 ; Frequency, count one second
	JLE L1

EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2
gtcpuid PROGRAM Format=PE, Width=64, Model=Flat, IconFile=, Entry=main:
INCLUDE winscon.htm, winabi.htm, cpuext64.htm
BufEAX DB 8 * B
BufEBX DB 8 * B
BufECX DB 8 * B
BufTicks DB 32 * B
MsgEAX D "EAX = Base frequency (MHz): ",0
MsgEBX D "EBX = Max frequency (MHz): ",0
MsgECX D "ECX = Bus (reference) frequency (MHz): ",0
MsgUnsupported D "Unsupported",13,10,0
MsgTicks D "TSC Ticks/s = ",0
Ticks DB Q
Freq DB Q

main: nop
    ; CPUID with leaf 0x16
    mov eax, 0x16
    xor ecx, ecx ; Some CPUs require ECX = 0
    cpuid ; EAX = Base; EBX = Max; ECX = Bus (MHz)

    ; Check if EBX and ECX are non-zero
    test ebx, ebx
    jz .unsupported

    test ecx, ecx
    jz .unsupported

    ; Output values on the screen
	StoD BufEAX ; EAX
	StdOutput MsgEAX, BufEAX, Eol=Yes, Console=Yes
	mov eax, ebx
	StoD BufEBX
	StdOutput  MsgEBX, BufEBX, Eol=Yes, Console=Yes
	mov eax, ecx
	StoD BufECX
	StdOutput  MsgECX, BufECX, Eol=Yes, Console=Yes
    jmp .done

.unsupported:
	StdOutput MsgUnsupported, Eol=Yes, Console=Yes
.done:

	WinABI QueryPerformanceFrequency, Freq
	MOV R15, [Freq]
	WinABI QueryPerformanceCounter, Ticks
	MOV R14, [Ticks] ;
	CPUID
	RDTSC
	SHL RDX, 32
	OR RAX, RDX
	MOV R13, RAX ; R13 will hold initial Time Stamp counter value	
align 16
L1:
	RDTSCP
	SHL RDX, 32
	OR RAX, RDX
	SUB RAX, R13 ; Subtract previous stamp
	MOV R12, RAX ; R12 is the TSC difference
	WinABI QueryPerformanceCounter, Ticks
	MOV R11, [Ticks] ; r14 - was initial
	SUB R11, r14
	CMP R11, r15 ; Frequency, count one second
	JLE L1
	MOV rax, r12 ; R12 is now amount of TSC Ticks per second
	StoD BufTicks
	StdOutput  MsgTicks, BufTicks, Eol=Yes, Console=Yes


	TerminateProgram
ENDPROGRAM

Вот результат для данного процессора

>gtcpuid.exe
EAX = Base frequency (MHz): 2300
EBX = Max frequency (MHz): 5300
ECX = Bus (reference) frequency (MHz): 100
TSC Ticks/s = 2303994036 ; < Это 2304 МГц

AIDA, кстати, говоря, показывает обе частоты, вот то, что читается из BIOS/DMI, тут 2,1 ГГц (а у максимальной частоты хороший такой задел на будущее):

А вот реальная частота таймера, 2,304 ГГц, вот здесь:

И, кстати, 2304 МГц мне нравится куда как больше, чем ровно 2300 из CPUID, потому что все замеры дают что-то типа 2303994036 тиков (последние цифирки пляшут от запуска к запуску, но 230399... стоит достаточно стабильно), так что я буду пользоваться замером именно по времени.

Теперь нам потребуется ещё пара ингредиентов. Первый — это Intel Performance Counter Monitor (или коротко Intel PCM) — и это просто обязательный инструмент для постижения глубокого внутреннего мира процессора. Он обновился буквально месяц назад. Клонируйте репозиторий, аккуратно следуйте инструкции по сборке (понадобится Студия с SDK и DDK и cmake), и всё получится, но для наших нужд потребуется внести небольшое изменение в драйвер MSR.sys для того, чтобы использовать RDPMC. Чуть более подробно я писал в позапрошлой статье "Достучаться до RDPMC...".

Добавьте в msrmain.c пару функций:

VOID SetCR4PCE()
{
    ULONG_PTR cr4 = __readcr4();
    DbgPrint("PCE CR4 before setting PCE: %p\n", (PVOID)cr4);
    cr4 |= (1 << 8); // Set bit 8 (PCE)
    __writecr4(cr4);
    cr4 = __readcr4();
    DbgPrint("PCE CR4 after setting PCE: %p\n", (PVOID)cr4);
}

VOID SetCR4PCEOnAllCores()
{
    for (ULONG i = 0; i < KeQueryActiveProcessorCount(NULL); ++i) {
        GROUP_AFFINITY affinity = { 0 };
        affinity.Mask = (KAFFINITY)1 << i;
        affinity.Group = 0;

        GROUP_AFFINITY oldAffinity;
        KeSetSystemGroupAffinityThread(&affinity, &oldAffinity);

        SetCR4PCE();
        DbgPrint("PCE CR4 set for cpu %d\n", i);
        KeRevertToUserGroupAffinityThread(&oldAffinity);
    }
}

И вызов в конец DriverEntry:

    DbgPrint("Driver loaded\n");
    SetCR4PCEOnAllCores();
    DbgPrint("CR4 PCE has been set\n");

это изменение выставит бит CR4, так нужный нам для того, чтобы использовать RDPMC в нашей программе, которая само собой работает не в привилегированном режиме.

Второй ингредиент чисто технический. Дело в том, что нам потребуется выводить из кода на ассемблере дробные значения с плавающей точкой, а ЕвроАссемблер, который тут используется, умеет своими макросами StoD и StoH только в целые. Можно, конечно, написать самому, либо вкорячить сюда printf из стандартного рантайма Студии, но чтобы не продираться через дебри линковки, есть способ проще (для меня, во всяком случае) — можно позаимствовать функцию FmtOut из "эзотерического" компилятора CVI. Плюс тут в легковесности решения — нам всего-то надо слинковаться с cvirt.lib, а из всего рантайма потребуется лишь cvirte.dll. Чтобы разжиться этой библиотечкой, полностью CVI ставить не надо, достаточно бесплатного рантайма: LabWindows/CVI Runtime.

Давайте поделим пару чисел на ассемблере и напечатаем результат в консоль, тут кода всего ничего:

EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2
cvidemo PROGRAM Format=PE, Width=64, Model=Flat, IconFile=, Entry=Start:
INCLUDE winscon.htm, winabi.htm, cpuext64.htm
FmtMsg D "%%s<%%f[p1] divided by %%f[p1] is %%f[p2]",13,10,0

Dividend DO Q 42.0
Divisor DO Q 13.0

LINK cvirt.lib
    
Start: nop
    MOVQ XMM0, [Dividend]
    MOVQ XMM1, [Divisor]
    DIVSD XMM0, XMM1
    WinABI FmtOut, FmtMsg, [Dividend], [Divisor], XMM0
    TerminateProgram
ENDPROGRAM

Результат:

>cvidemo.exe
42.0 divided by 13.0 is 3.23

Счастье есть, мир заиграл новыми красками. К тому же FmtOut потокобезопасна, чего не скажешь о макросах StoD/StdOutput.

Теперь мы во всеоружии и можем покрутить циклы.

Для оценки пропускной способности нам нужно будет выдавать последовательность независимых команд типа

	IMUL R10, R10
	IMUL R11, R11
	IMUL R12, R12
	IMUL R13, R13
	IMUL R14, R14
	IMUL R10, R10
	IMUL R11, R11
	IMUL R12, R12
	IMUL R13, R13
	IMUL R14, R14
	...

Чтоб было удобнее, заведём вот такой макрос с переменной тестовой команды, чтобы менять её только в одном месте, если мы захотим тестировать ADD, IMUL и так далее:

%TCommand %SET IMUL 
MsgTP D "Throughput & Latency Test for %TCommand",0

ThroughputBench %MACRO L
mov r9, 200_000
%L:
i %FOR  0..1000
	%TCommand r10, r10
	%TCommand r11, r11
	%TCommand r12, r12
	%TCommand r13, r13
	%TCommand r14, r14
  %ENDFOR
	dec r9
	jnz %L
%ENDMACRO

Здесь пять независимых команд повторяются тысячу раз (это даст пять тысяч инструкций), а цикл крутится двести тысяч раз, что в общей сложности даст нам миллиард инструкций. Количество повторяющихся команд в развёрнутом цикле не должно быть очень большим, все они должны поместиться в кэш инструкций, но и не очень маленьким, чтобы влияние dec/jnz (они, кстати, макро фьюзятся в одну микрооперацию) не слишком влияло на результат.

А для оценки латентности вот так, тут всё проще:

LatencyBench %MACRO L
mov r9, 200_000
%L:
i %FOR  0..5000
	%TCommand r10, r10	
  %ENDFOR
	dec r9
	jnz %L
%ENDMACRO

Здесь одна и та же команда тупо повторена пять тысяч раз, и такой же цикл.

Это называется оценка методом развёрнутого цикла. Можно сделать ещё более "универсально", но мы не ставим перед собой задачи заменить таблицы Агнера или uops.

Количество исполненных инструкций и количество затраченных на это тактов мы будем получать из RDPMC счётчиков 0x40000000 и 0x40000001, а время исполнения из классической пары RDTSC/RDTSCP.

	StartBench RDPMC, 0x40000000
ThroughputBench L1
	EndBench RDPMC, 0x40000000, Msg0, TInstr
	StartBench RDPMC, 0x40000001
ThroughputBench L2
	EndBench RDPMC, 0x40000001, Msg1, TCycl
	StartBench RDTSC, 0x0
ThroughputBench L4
	EndBench RDTSCP, 0x0, MsgT, TTSC

И для RDPMC мы ведь не забыли выключить Secure Boot, включили разрешение на загрузку неподписанных драйверов "bcdedit /set TESTSIGNING ON" и хотя бы раз запустили pcm.exe, чтобы драйвер MSR.sys разблокировал RDPMC? Если нет, то нам будет выброшено исключение 0xc0000096 — STATUS_PRIVILEGED_INSTRUCTION. Я, кстати, сделал попытку интеллигентно поставить ловушку на это исключение, но на чистом асме это ох как непросто, тут надо SEH городить, с полпинка не получилось, при этом даже просто определить возможность исполнения никак, поскольку чтение бита через __readcr4() суть та же привилегированная инструкция. Отложим на долгие зимние вечера.

Попробуем для начала и для проверки, IMUL на старичке Haswell, смотрите, какая красота (поскольку я теперь умею делать форматированный вывод прямо из асма, я упоролся и сделал таки красивую табличку):

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   1.00   1.00   1.00 G   1.01 G   0.98 G   0.28 s   x1.03   3.49   3.58 GHz
 LAT   3.00   0.33   1.01 G   3.01 G   2.93 G   0.84 s   x1.03   3.49   3.59 GHz

Легенда: THR — это пропускная способность и она единица (колонка Value — это значение). LAT — это латентность и она три такта. IPC — это количество инструкция на такт. Instr — это собственно количество инструкций и оно миллиард в обоих тестах (при тестировании латентности гипер-трединг присунул нам немного инструкций в простаивающий конвейер), а Cycles — это количество тактов ядра, отсюда и такие значения IPC (это инструкции, делённые на циклы). TSCnt — это количество тиков таймера, который для этого процессора 3,5 ГГц. ExecT — это время выполнения миллиарда инструкций (в секундах), Boost — это насколько поднялась базовая частота, а Frequency — это истинная реальная частота ядра, до которой он дотурбобустился. Как в аптеке, я б сказал.

Ну давайте вернёмся к нашим ядрам на i7-13850HX:

Вот P ядро, ровно тот же тест:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   1.00   1.00   1.00 G   1.01 G   0.46 G   0.20 s   x2.20   2.30   5.07 GHz
 LAT   2.99   0.33   1.01 G   3.01 G   1.38 G   0.60 s   x2.18   2.30   5.03 GHz

Ровно та же латентность и пропускная способность, только на пяти гигагерцах

А вот Е ядро:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   1.00   1.00   1.00 G   1.00 G   0.61 G   0.27 s   x1.63   2.30   3.76 GHz
 LAT   5.00   0.20   1.00 G   5.01 G   3.09 G   1.34 s   x1.62   2.30   3.74 GHz

Здесь турбо буст заметно пожиже, а латентность аж пять тактов. И оцените время исполнения миллиарда команд — там, где P ядру требовалось всего 0.6 секунды, а старичку Haswell 0.84 здесь уже 1.34 секунды! Это практически вдвое медленнее, как и показывает CPU-Z.

А ну-ка, сложение ADD:

Р ядро, молотит как из пулемёта, оцените пропускную способность 0,25, это четыре команды в параллель:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   0.24   4.19   1.00 G   0.24 G   0.11 G   0.05 s   x2.19   2.30   5.04 GHz
 LAT   1.00   1.00   1.00 G   1.00 G   0.46 G   0.20 s   x2.18   2.30   5.03 GHz

А вот Е ядро, тут всё погрустнее:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   0.32   3.14   1.00 G   0.32 G   0.19 G   0.08 s   x1.64   2.30   3.78 GHz
 LAT   1.00   1.00   1.00 G   1.00 G   0.61 G   0.27 s   x1.63   2.30   3.76 GHz

Ну и старичок Haswell

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   0.33   3.01   1.00 G   0.33 G   0.32 G   0.09 s   x1.03   3.49   3.59 GHz
 LAT   1.00   1.00   1.00 G   1.01 G   0.98 G   0.28 s   x1.03   3.49   3.59 GHz

То есть "в среднем по больнице" производительность Е ядер на этом процессоре примерно сравнима с Haswell десятилетней давности. Но при этом не надо забывать, что тут их аж двенадцать штук.

Теперь можно погонять SHA256 инструкции и тут всё поинтереснее, SHA256MSG1 xmm, xmm:

Р ядро, он очень старается, но получается не очень:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   3.96   0.25   1.02 G   4.03 G   1.85 G   0.80 s   x2.18   2.30   5.02 GHz
 LAT   5.43   0.18   1.01 G   5.49 G   2.51 G   1.09 s   x2.19   2.30   5.04 GHz

А вот Е ядро

 THR   1.00   1.00   1.00 G   1.00 G   0.62 G   0.27 s   x1.63   2.30   3.75 GHz
 LAT   3.01   0.33   1.00 G   3.01 G   1.85 G   0.80 s   x1.63   2.30   3.75 GHz

Для этого ядра SHA256MSG1 — это раз плюнуть, всё равно что умножение двух регистров, здесь и пропускная способность вчетверо больше и латентность ниже, и по времени выполнения Е ядра обгоняют Р, даже несмотря на то, что работают на значительно меньшей частоте.

А вот инструкция SHA256RNDS2:

Е ядро, тут хорошая пропускная способность:

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   1.00   1.00   1.00 G   1.00 G   0.62 G   0.27 s   x1.63   2.30   3.76 GHz
 LAT   4.01   0.25   1.00 G   4.02 G   2.48 G   1.08 s   x1.62   2.30   3.74 GHz

И Р ядро, здесь пропускная способность заметно хуже, а вот латентность одинакова.

Test | VAL  | IPC  | Instr. | Cycles | TSCnt. | ExecT. | Boost | Base | Frequency
 THR   2.99   0.33   1.01 G   3.02 G   1.39 G   0.60 s   x2.17   2.30   5.00 GHz
 LAT   3.97   0.25   1.01 G   4.02 G   1.85 G   0.80 s   x2.17   2.30   5.00 GHz

Хотя прогресс на месте не стоит, у Golden Cove (что из предыдущего поколения Alder Lake) латентность была 6 тактов, а теперь у Raptor Cove стала четыре.

Вот вам и ответ, почему скорость теста на Расте примерно одинакова — частота-то ниже, зато лучше латентность и пропускная способность, оно взаимно нивелируется, "так на так" и выходит. Ну а Хасвеллу таких чудо команд не завезли.

Из всего этого можно сделать вывод, что общее замедление на Е ядрах спрогнозировать практически невозможно, это очень сильно зависит от машинного кода, можно и двукратное пенальти легко огрести, а можно и вровень с Р ядрами.

Память/Кэш

Тест был бы неполон без теста памяти. Ведь каждый программист должен хоть раз написать тудушник/заметочник, просмотрщик картинок и тест, показывающий размер кэшей.

Будем читать гигабайт памяти, но вначале из 16 килобайт (ну то есть мы будем читать 16384 одних и тех же байт 65536 раз), затем из 32 (32768 байт 32768 раз), и так далее, каждый раз когда мы будем забираться во всё более и более старшие адреса оно будет становиться медленнее и медленнее, а мы будем считать, сколько таких циклов мы успеем сделать за одну секунду.

Побайтово, как четверть века назад, память уже давно никто не читает, один из самых быстрых способов это воспользоваться серией команд VMOVDQA (если вы заглянете в потрошки memcpy, то увидите, что там копирование памяти примерно так и устроено), в предположении что указатель в RDX, мы будем читать по 32 байта за раз, каждые две команды будут выбирать всю кэш-линию в 64 байта (массив для чтения в памяти выровнен на границу страницы, само собой разумеется), вот так:

	vmovdqa ymm1, [rdx]
	vmovdqa ymm2, [rdx+32]
	vmovdqa ymm3, [rdx+64]
	vmovdqa ymm4, [rdx+96]

Вот результат и для сравнения пара Xeon процессоров (три первых строчки показывают размер кэшей для справки), хорошо видно ступенчатое падение производительности когда мы переходим на следующий уровень кэша:

По чтению памяти производительность Е ядер чуть ли не вдвое-трое хуже чем Р и это связано как раз с командами VMOVDQA — их пропускная способность на Р ядре 0,33, а на Е ядре 0,67, вот откуда основная разница.

Ну и не следует забывать, что кэш второго уровня сгруппирован в три группы по четыре ядра, так что если читать одну и ту же область памяти с двух потоков, то лучше это делать на соседних ядрах из одной группы, иначе нам будет мешать когерентность кэша а вот если читать/писать разные области памяти, то лучше это делать с разных групп, чтобы у каждого потока был собственный кэш — так можно избежать "загрязнения" кэша. В принципе это можно показать практически, но тут немного мешает раздельный кэш первого уровня. Но, скорее всего, если вы начали оптимизировать в этом месте, то всё, что было написано выше вам и так не нужно. Ну и опять же общая низкая пропускная способность памяти на Е ядрах таки предполагает расположение интенсивных операций с памятью на Р ядрах, а не на Е.

Тест экономичности

Е ядра позиционируются как экономичные. Я, некоторое время подумав, решил сделать вот какой тест "экономичности". Я отключу блок питания и запущу расчёт SHA-256 вначале на всех ядрах, то есть в 28 потоков, затем только на восьми производительных ядрах в 16 потоков, а потом на 12 экономичных и посмотрим, сколько мегабайт входных данных он сможет обработать на одном заряде аккумулятора (я буду смотреть до 10% остатка заряда) и с какой скоростью будет идти расчёт. Напомню, ��то однопоток выдавал примерно 2350 МБ/с что на Р что на Е ядрах. Между тестами аккумулятор будет заряжаться до 100%, это занимает примерно пару часов.

Суммарно мы смогли посчитать только на Е ядрах даже больше чем на всех, это связано с тем, что на максималках процессор постоянно троттлился, потому что он не может отдавать такую производительность чисто на аккумуляторе. Если подключить блок питания (а он, на секундочку, 230 Ватт и отдаёт почти двенадцать ампер), то тест начнётся примерно на 50000 МБ/с и через некоторое время снизится до 45000 МБ/с из-за термического троттлинга. Но в общем и целом неплохой результат. Код теста (как и всего остального, что было выше в статье) в репозитории pecores-habr.

Сейчас вот читаю про то, что в Panther Lake Интел вроде бы хочет отказаться от гипер-трединга, и в принципе с такими Е ядрами уже можно, но мне вот будет немножко жаль этой технологии, и хотя латентность и пропускная способность тоже потихоньку улучшаются, но кто же будет заполнять время от времени простаивающие конвейеры?

Вот, собственно и всё, чем хотелось бы поделиться в этот пятничный вечер. Всем хороших выходных и быстрого кода!