Comments / Profile of AndreyDmitriev / Habr

Андрей Дмитриев @AndreyDmitriev

Пользователь

Не смотрите на % использования процессора при гиперпоточности

спин ожидание в двух конкурентных очередях

Я поиграл со спинлоком и, думаю, могу показать промежуточные результаты, они довольно интересны. В сухом остатке — он работает реально быстрее на гипертредированных ядрах, нежели на физических.

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

EUROASM AutoSegment=Yes, CPU=X64, SIMD=AVX2
spin_lock PROGRAM Format=PE, Width=64, Model=Flat, IconFile=, Entry=Start:

INCLUDE memory64.htm, wins.htm, winscon.htm, winabi.htm, cpuext64.htm

MsgEnd D " Ticks; Check = ",0
Buf_t DB 32 * B		; Buffer for Ticks string
Buf_c DB 32 * B     ; Buffer for Counter string
hThreads DQ 0, 0         ; Space for two thread handles
SpinLock DD 0            ; Shared spin lock (0 = unlocked, 1 = locked)
Counter  DQ 0            ; 64-bit shared counter

ThreadProc PROC
    WinABI GetCurrentThread ; This one will be in RAX
    WinABI SetThreadAffinityMask, RAX, RCX ; RCX is thread param (core#)

	mov r8, 500_000_000
	align 16
SpinWait:  ; Spin lock acquire
    mov eax, 1
    xchg eax, [SpinLock] ; Atomically try to acquire lock
    cmp eax, 0           ; Was lock previously 0 (unlocked)?
    je LockAcquired      ; If yes, we acquired the lock
    ; If not acquired, wait and retry
    PAUSE                ; Hint to CPU that we are in a spin-wait loop
    jmp SpinWait

LockAcquired:
    ; Critical section begins - Increment 64-bit counter
    mov rax, [Counter]
    inc rax
    mov [Counter], rax
    ; Critical section ends - Release lock
    mov [SpinLock], 0
	dec r8 ; total increments counter
	jnz SpinWait ; loop to the start

    xor eax, eax
    ret
ENDPROC ThreadProc

Start: nop
    ; Two Threads, the first one always 1st core 0x1 (0x4 - CREATE_SUSPENDED)
    WinABI CreateThread, 0, 0, ThreadProc, 0x1, 0x4, 0
    mov [hThreads], rax     ; Save handle
    ; Second thread - change 0x2 to 0x4 below for Physical core instead of HT
    WinABI CreateThread, 0, 0, ThreadProc, 0x2, 0x4, 0 ; *
    mov [hThreads+8], rax

	RDTSC
	shl rdx, 32
	or rax, rdx
	mov r9, rax

    WinABI ResumeThread, [hThreads]   
    WinABI ResumeThread, [hThreads+8] 
    WinABI WaitForMultipleObjects, 2, hThreads, 1, 0xFFFFFFFF ; INFINITE

	RDTSCP
	shl rdx, 32
	or rax, rdx
	sub rax, r9
	StoD Buf_t
    mov rax, [Counter]
	StoD Buf_c
	StdOutput Buf_t, MsgEnd, Buf_c, Eol=Yes, Console=Yes

    WinABI CloseHandle, [hThreads]
    WinABI CloseHandle, [hThreads+8]
    TerminateProgram
ENDPROGRAM spin_lock

И вот какое дело — на гипертредированных ядрах это бежит весьма быстро:

> spin_lock_HT.exe
69_126_916_200 Ticks; Check = 1000000000

Я заказал 500 миллионов инкрементов счётчика в двух потоках, состояния гонки нет, всё пучком, но насколько это медленнее на двух физических ядрах, больше чем в четыре раза:

> spin_lock_PH.exe
294_057_181_026 Ticks; Check = 1000000000

Код ровно тот же самый, только второй поток сажается на другое ядро в строке 47

WinABI CreateThread, 0, 0, ThreadProc, 0x4, 0x4, 0 ; *

Если вас интересует, где самая "горячая точка", то вот из VTune, это для гипертредированных:

Для физических всё выглядит примерно также, только время сильно больше — там где 24 секунды в отмеченной строчке они улетают за сотню (и там, где инкремент счётчика тоже). Единственное моё предположение в том, что мы тут налетели на когерентность кеша, ведь спинлок и счётчик расшарены между потоками, только в случае гипертредированных ядер у нас кеш общий на два ядра, а вот для физических он раздельный и при чтении мы само собой должны получать "правильное" значение, и как-то железо должно это согласовывать, чтобы все ядра видели одни и те же данные. Как-то так.