Názory k článku Pohled pod kapotu JVM – základy optimalizace aplikací naprogramovaných v Javě (3)
-
Super, díky za článek.
Po předchozím dílu mi ty výsledky přišly docela pomalé. Dneska letmým pohledem na první ArrayTest3.test() to vypadá, že kompilátor má sice snahu unrollovat, ale neuvědomuje si nedostatek registrů. Navíc ani nemá žádnou větší snahu popřeházet instrukce, aby nebyly závislé na předchozí (tedy nevím, jak velkou roli to hraje pro dnešní procesory).
Má tyhle informace kompilátor (včas) k dispozici, nebo to tam na nějaké vyšší vrstvě naplácá bez ohledu na specifika cílové platformy? Skoro mi přijde, že bez unrolling by byl ten cyklus rychlejší...
-
Pavel TišnovskýZlatý podporovatelNo na i386 je to docela problem, hotspot na to neni moc staveny, ja zkusim do pristiho dilu dat ukazky,jak to vypada na skutecnych procesorech^W^W RISCech - SPARC apod.
Prehazovani instrukci - to me taky neustale prekvapuje, ne nedela to.
Co se tyce C1 prekladace, tak ten ma takzvanou linearni alokaci registru, coz je na i386 zlo, C2 pouziva pro alokaci registru obarvovani grafu - trosku slozitejsi vec, zkusim to nekdy popsat vice do hloubky.
-
Pavel TišnovskýZlatý podporovatel
No taky si nekdy s nadsazkou rikam, jestli by nebylo daleko lepsi, kdyby Sun byl koupenej Intelem :-)) [icc]
-
Pavel TišnovskýZlatý podporovatel
Ale podle toho kodu to vypada tak, ze chteji, aby ALU instrukce bezely paralelne s load-store instrukcema, coz by v pripade LEA bylo obtizne ne?
-
Pavel TišnovskýZlatý podporovatel
Architekturu Core2 Duo neznam, ale na predchozich cipech to bylo tak, ze LEA byla vykonavana v AGU, zatimco ADD v ALU, takze ne ze by LEA byla nejak extra rychlejsi, ale vypocet se dokazal provest uz v decode fazi a navic bez zatizeni ALU (+cekani na vysledek). Ale dneska uz to asi chce benchmark, chovani modernich cipu je slozite :)
-
deda.jabko (neregistrovaný)
Ono je to slozitejsi. Napriklad ve zdrojacich GCC je "...it is ok to optimize an ADD operation to LEA operation to avoid flag register consumation. For most processors, ADD is faster than LEA. For the processors like ATOM, if the destination register of LEA holds an actual address which will be used soon, LEA is better and otherwise ADD is better." Vzhledem k tomu, ze u patche je podepsan clovek @intel.com asi bych to bral jako docela duveryhodnou informaci.
GCC jeste dela to, ze se diva, jestli AGU bude nebo nebude pouzivat jina instrukce a pripadne pouzije LEA nebo ADD. Hrozna alchymie.
-
Pavel TišnovskýZlatý podporovatel
Co jsem se dival na zdrojaky HS, tak v tomto ohledu se bohuzel zadne zazraky nekonaji :/ Zjisteni zakladnich parametru CPU tam je, pocet jader atd. ovlivni hlavne GC, ale C1/C2 uz ne do takove miry, jak v cecku ruzne -march= apod.
