Az Intel részletezte az APX (Advanced Performance) Extensions előnyeit

Intel
[...] Intel APX doubles the number of general-purpose registers (GPRs) from 16 to 32. This allows the compiler to keep more values in registers; as a result, APX-compiled code contains 10% fewer loads and more than 20% fewer stores than the same code compiled for an Intel 64 baseline. Register accesses are not only faster, but they also consume significantly less dynamic power than complex load and store operations. [...]

Részletek itt és itt.

( DirtY_iCE | 2023. 07. 25., k – 15:17 )

Tok jo, megcsinaltak amit az arm, ppc, etc. mar 30 eve is tudott.

I hate myself, because I'm not open-source.

Mondjuk eleve a RISC architektúrák egyik jellemzője volt a több általános célú regiszter, kompenzálandó a kevesebb utasítást. Egyszerűbb kombinációs logikai háló (vagy hogy is hívták a felépítést, amit az utasításdekódoló is használt) több regiszterrel megtámogatva. Most meg amilyen bonyolult egy bármilyen processzor, sokat nem kér pár plusz regiszter.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Most meg amilyen bonyolult egy bármilyen processzor, sokat nem kér pár plusz regiszter.

Ezeket a regisztereket a címzési módokban is kódolni kell tudni, azaz az utasítások kódolása is változni fog (compilereket módosítani kell), emiatt változni fog az utasításdekóder is. Át kell alakítani emiatt persze nagyon sok alrendszert még, hogy tudjanak róla, hogy vannak ám az új regiszterek. Mivel ezen regiszterek részei a processz állapotterének, ezért ezt el kell menteni/visszatölteni context switchkor (ha az OS nem az XSAVE/XRSTOR utasításpárt használja erre, az OS-eket fel kell rá készíteni). Nem olyan triviális dolog egy ISA-t bővíteni új általános célú (gyakorlatilag bármilyen alap utasításban használható) regiszterekkel és a hozzájuk tartozó új utasításokkal, címzési módokkal.:
 

We significantly expand the conditional instruction set of x86, which was first introduced with the Intel® Pentium® Pro in the form of CMOV/SET instructions. These instructions are used quite extensively by today’s compilers, but they are too limited for broader use of if-conversion (a compiler optimization that replaces branches with conditional instructions).

Intel APX ultimately comes down to 16 more general purpose registers, three-operand instruction formats with a new data destination register for many integer operations, conditional ISA improvements, optimized register state save/restore operations, and a new 64-bit absolute direct jump instruction.

Jo de ez igaz volt amikor bejottek az mmx meg sse (meg talan mas is) regiszterek is. Sot, az tippre sokkal bonyolultabb, megmondani a compilernek hogy abbol a general purpose regiszterbol amibol idaig is hasznalhatott 8-at most hirtelen lett meg plusz 16 nem olyan nagy szivas, tekintve hogy idaig is kellett 38 fele CPU architekturat tamogatniuk. (Es CPUn belul se hiszem hogy olyan hu de nagy dolog lenne, ideig se direkt a regisztereken dolgozott a CPU, hanem volt benne vagy legalabb 2x annyi es register renaming-el szorakozott hogy jobban kihasznalja a pipelinet meg nem tudom en mit.) Az uj utasitasok amivel itt inkabb lesz problema compiler teren. OS-nel meg kb ahol elmenti a regisztereket, ott kell egy plusz par sort beirni, meg a strukturat nagyobbra venni.

Szerintem a nagyobb szivas az lesz, hogy ha ujraforditasz egy appot ami hasznalja ezeket a regisztereket, akkor az nyilvan nem fog futni regi procikon, ugyhogy nem hiszem hogy az elkovetkezendo 10 evben nagyon lesz hasznalva barmire (egy-ket specializalt, idaig is assemblyban irt es runtime cpu detektalt eljarast leszamitva). Nyilvan aki gentoot hasznal legujabb intel procin, az mas teszta :)

I hate myself, because I'm not open-source.

Mondjuk azért ott sem árt néha átnézni a kódot és átírni a kritikusabb részeket újabb API-kra, pl Stream meg Vector, biztos, ami biztos, hátha nem sikerül kapásból optimalizálni mindent. Valamint a futtatókörnyezetet át kell majd valakinek írni és nem biztos, hogy azonnal prioritás lesz pl az APX.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Igen, annal a kb 3 db programnal ami valami jit-elt nyelven van irva es szamit a teljesitmeny es beupdatelik erre a jitet. A legtobb hely ahol szamit a teljesitmeny mai napig valami nativ kodra van forditva, runtime CPU detection meg tobbfele valtozatban leforditott kod meg azert joval ritkabb; hogy javascriptben egy onclick handler 1ms helyett 0.999ms alatt fut le az meg kb tokmindegy.

I hate myself, because I'm not open-source.

Azert vannak emlekeim rola, hogy ARM-on es POWER-en mennyire lassu volt a Java eveken at (x86 es x86-64-on futo JVM-hez kepest, mielott megint altalanos "lassuajava" topicot csinal belole valaki). Az egy dolog, hogy JIT compiler egyaltalan tamogatja az uj architekturat, egy masik meg hogy mennyi kezi optimalizacios munkat tesznek bele a kodgeneratorba.

Régóta vágyok én, az androidok mezonkincsére már!

Jó régen volt, a pontos számok nem hiszem hogy megvannak bárhol is, de arra emlékszem, hogy ugyanazt a Java-s benchmarkot nyomtuk végig egy IBM HS22-n (kb 2.4GHz-es Nehalem-generációs Xeon volt benne) és egy JS12-n (3.8GHz-es Power6 volt benne). A processzorokból sejthető, hogy ez mikor volt. Ennek a Power6-nak papíron kb minden szempontból rommá kellett volna vernie a Xeon-t, ehhez képest a Java-s tesztek a Xeon-on kb 3-5x voltak gyorsabbak. Egyszerűen nagyságrendi előnye volt az x86-os java-nak. (Volt mindenféle próbálkozás IBM-es saját JVM-mel, meg openjdk-s java-val, hogy melyik volt gyorsabb arra már nem emlékszem, de egyiknek sem volt jó eredménye power-en)

Régóta vágyok én, az androidok mezonkincsére már!

Igazából nem sokat próbálgattuk más nyelvekkel, nekünk kifejezetten a Java lett volna érdekes. C-s benchmarkokkal mértük össze, aszerint a Power6 (nem meglepő módon) jobb volt a Xeon-oknál. (Egy akkori szinten is alsó-középkategóriás Xeonról beszélünk...)

De ez egy 10+ évvel ezelőtti állapot volt, a mondanivalóm lényege pont az, hogy kellett az idő, mire kikupálódott a mai szintre, hogy az openjdk nem-x86 platformokon is rendesen megy.

Régóta vágyok én, az androidok mezonkincsére már!