Skrivet av mpat:
Skummade precis Agner Fog’s optimeringsmanual för första gången på ett tag, letade efter Ice Lake. Den var inte med, men Zen var det. Han tycker att man bör klara 4 instruktioner/6 uop också för kod som inte får plats i uop-cachen. Nu är ju uops inte identiska mellan AMD och Intel, men lite intressant ändå.
Satt och lekte lite med mikro-benchmarks i morse. Det är helt klart möjligt att nå >4 instruktioner per cykel i tighta loopar på Zen 2, men det fungerar bara i extremt specifika fall ("tricket" är att blanda minnesoperationer, heltal och flyttal då Zen 2 har totalt 3+4+4=11 exekvering-portar att jobba med).
Enligt Agner är det inte omöjligt att även Skylake kan peak:a på >4, närmaste jag kom här var uppmätt IPC 4,0.
"However, the throughput of the whole design rarely exceeds four instructions per clock."
Att det finns en begränsning på 4 "renames" per cykel är i sig ingen barriär för >4 μps, det finns absolut hopp samt x86 kan även göra jämförelser direkt mellan minne och konstanter. Angner nämner också att han inte alls ser detta som en flaskhals
"Register renaming is controlled by the reorder buffer and the scheduler. Register allocation and renaming has not been observed to be a bottleneck."
För Skylake fungerar inte Zen 2 tricket då ALU för flyttal och heltal delar exekvering-portar, möjligen kan man få till det med större andel minnesoperationer (som måste ge 100 % L1D$ hit for att ens teoretisk nå dessa IPCer) då det finns totalt 4 portar för minnesoperationer (mot 3 i Zen 2 och 6 i Sunny Cove).
Fast ens fyra instruktioner per cykel är extremt akademiskt på båda dessa CPUer. Kör man något som är stort nog att börja trilla ur CPU-cache är det svårt att ens nå IPC på 1,0. I "normala" program som har väldigt god cache-hit rate (d.v.s. de flesta desktop-applikationer) ligger dessa CPUer på IPC mellan 1,0 och 2,5 utan SMT och ~20-30 % högre med SMT (då lägre IPC per tråd men refererar till IPC per fysisk kärna).
Att Apple, och nu också ARM med Cortex A77 och senare, kan utför så pass mycket mer per cykel måste bero mycket på ISA. Men Agner Fog pekar på andra begränsningar för x86, som inte gäller för ARM
"A memory write may not be able to execute before a preceding write, but the write buffers can hold a number of pending writes, typically four or more."
x86 specifikationen tillåter inte read/read, read/write eller write/write reorder (verkar nog vettig när man spikade detta, men det var när ens två CPU-kärnor var exotiskt...). ARM garanterar enbart en specifik ordning efter explicit synkronisering (vilket är precis hur man definierat det hela i C, C++, Java, m.fl.).
"A memory read can execute before or simultaneously with another preceding read on most processors"
Det är bara delvis sant på x86. I praktiken fungerar high-end x86 så, men de måste ha extra house-keeping då specifikationen kräver att read/read sker i den ordning det specificerades i programmet. Så detta är spekulation på x86 och kommer ibland behöva köras om, det är inte fallet på ARM (så enklare att köra väldigt många samtidiga läsningar).
Måste vara dessa begränsningar i x86 som rejält börjar visa sig som IPC-ankare. Har väldigt svårt att se varför AMD/Intel annars skulle rent slumpmässiga hamna på så väldigt snarlik IPC med på vissa sätt rätt olika design.
Skrivet av EntropyQ3:
[i]SVE är trevligt, men dess main claim to fame, att den tillåter hårdvaruvektorlängder från 128 till 2048 bitar är kanske inte så tillämpbart för Apple. Noterbart är att Fujitsus A64FX superdator har en vektorlängd på 512 bitar. Mer är absolut inte generellt bättre vad gäller vektorlängd, ens för den klassen av datorer.
För en bra artikel med måttligt omfång angående vektorlängd, inkluderande cache effekter, längdspecifik vs. agnostisk kod osv och till och med en liten jämförelse med NEON prestandamässigt (ingen reell skillnad) rekommenderar jag varmt en liten femsidig artikel av Angela Pohl et. al.
Nu är iofs SVE trevligt, och jag hoppas att Apple så småningom byter till den vektorlösningen av rent estetiska skäl, men med tanke på att Apple implementerar inte bara egna co-processorer, utan också lägger till egna instruktioner (AMX) till AArch64, så vete fasen hur stor den praktiska nyttan skulle vara.
Var inte så att jag direkt önskar SVE stöd i de kretsar tänka för mobiler och desktop, precis som du ställer jag mig lite frågande till hur stort värdet är.
I "generell" kod undrar jag inte om 128-bitars SIMD ger bäst tradeoff mellan prestanda och effekt. AVX2/AVX-512 med >=256 bit bredd tenderar dra så pass mycket ström att frekvensen minskas, vilket då minskar prestanda för all skalär heltalskod som normalt är lejonparten i "generell" kod. Finns en del fördelar med AVX/AVX-512, dessa kan även utnyttjas i 128-bitars läge som då inte påverkar frekvensen!
Frågan är hur långt ARM-gänget kan någorlunda effektivt kan addera pipelines för NEON sett till effektivitet. Apples 3 pipelines över ARM Cortex 2 verkar ju ändå fungera, så blir intressant att se hur Cortex X1 presterar med sina 4 NEON pipelines.
Dokumentet du länkar pekar ju på att ökad vektorbredd ser rejäl dimishing returns redan vid 256-bitar i de tester man gjorde där. Tror mer på att köra saker som effektivt kan utnyttja sådan med GPGPU (typiskt långt högre bandbredd) eller specialkretsar som NPUer.
Finns ju ett mellanting mellan NEON/SSE/AVX där instruktionen dikterar bredden och SVE (och motsvarigheten för RISC-V) med variabel vektorbredd. Intels GPU kan variera effektiv registerbredd per instruktion, ändå används en och samma registerbank. Vi lär få se med Xe hur bra/dåligt detta är för grafik, men det verkar fungera väldigt bra för GPGPU (Intels GPUer har väldigt bra prestanda ställd mot teoretisk kapacitet i GPGPU).
