Názory k článku Programovací jazyk Go a assembler (3.část)

Dobrý den, určitě jsou len a cap na amd64 a arm64 32-bitové? Já jen že unsafe.Sizeof vrací pro proměnné typu int 8 (a pro řez tedy 24). Ostatně v tom strojáku je pak MOVQ.

Jinak argumenty funkcí se na zásobníku předávají na všech architekturách, mají to tak schválně, aby přepnutí gorutin bylo levné.

To ještě jednou zkontroluji. Předává se (z hlediska Go) int, takže by to mělo být int64 na 64bitových platformách, ale četl jsem, že interně to omezují na 2G prvků. Ale možná to už je neomezené (tedy já z tohoto pohledu považuji 64bitový index za prakticky neomezený :-)

Tohle fixli v září 2012, myslím, že v Go 1.1 :)

(Typ int byl původně v Go 32-bitový i na amd64, ale lidi si furt dokola stěžovali.)

Jo tak to už je skutečně prehistorie :)

Právě, teď už tam to omezení není.

Pardon, že ještě otravuju, ale v části 6 nemá být XORQ místo XORL? Následný inkrement a porovnání je pak quad, takže se asi nevynuluje celý registr.

Tedy v architektuře AMD64 nejsem kovaný, ale dost mě překvapuje, že ta starodávná instrukce REP STOSD je stejně rychlá jako moderní VMOV.... s 64bitovými přenosy. Tak mě napadá - zarovnává Go správně ta pole pro bitmapy? Nebo je problém v tom, že se to testovalo na mašině s 32bitovými paměťmi?

U těch větších rastrových obrázků se už projevilo úzké hrdlo paměti. Ta data se (IMHO) stejně přenášela v burst režimu.

Ten minimalni rozdil mezi STOSx a VMOV/MOV zase takove prekvapeni neni, nebot prinejmensim na Ivy Bridge a lepsich CPU uz je ERMSB, tzn. ze STOSx /MOVSx instrukce maji vylepseny mikrokod, jehoz funkci si lze v tomto konkretnim pripade predstavit jako sdruzovani 32bitovych zapisu STOSD do jednoho realneho n-bitoveho jiz v jadru. Pak je rychlost brzdena busem, a tedy priblizne stejna, jako pri pouziti 8bajtovych VMOV. Samozrejme to chce ty veci okolo, tzn. zarovnani na 16 bajtu, >= 128 bajtu pro REP prenos...
Mimo jine si toho lze take povsimnout v modernich knihovnach pro memsety a memmovy, kde puvodni kombinace STOSD + (1...3)STOSB, resp. MOVSD + (1...3)MOVSB, jsou nahrazeny STOSB, resp. MOVSB, nebot mikrokodem provadene sdruzovani pristupu na bus do sirky datove sbernice, mensi overhead pri startu REPu a moznost inlajnovani maleho useku kodu tuto konstrukci jasne favorizuje.
Jinymi slovy, s ERMSB je ECX = N, REP STOSD stejne rychle jako ECX = 4*N, REP STOSB.

Z "Intel 64 and IA-32 Architectures Optimization Reference Manual":
3.7.7.3 Memset ConsiderationsThe consideration of code size and throughput also applies for memset() implementations. For processors supporting ERMSB, using REP STOSB will again deliver more compact code size and significantly better performance than the combination of STOSD+B technique described in Section 3.7.6.When the destination buffer is 16-byte aligned, memset() using ERMSB can perform better than SIMD approaches. When the destination buffer is misaligned, memset() performance using ERMSB can degrade about 20% relative to aligned case, for processors based on Intel microarchitecture code named Ivy Bridge. In contrast, SIMD implementation of memset() will experience smaller degradation when the destination is misaligned.

jj me se to libi, Kdyz uz tam ty vysokourovnove instrukce maji, tak at jsou mega optimalizovany, toto si jadro muze krasne upravit podle architektury.

pěkně to je popsáno. Netušíte, jak je to na AMD? Teď tady máme samé i7, takže to nemám kde vyzkoušet (i kdybych dnes kupoval desktop, tak je volba jasná)

Taktez nemam aktualne pristup k AMD, ale treba na odkazu nize jsou nejake statistiky z 2017. Je pekne videt, jak pocinaje Ivy Bridge (Haswell, Skylake) REP MOVSB drti ostatni techniky memmove (pri zarovnani, >=1k bloky; REP MOVSB ma jistou uvodni rezii). U Ryzen 5 (na konci statistik) se nic prevratneho nekona a namatkou podle cpu-world.com Ryzen 3/5/7/Threadripper Enhanced REP MOVSB/STOSB nenabizi (zdroj CPUID?). Je to ale Intelacka feature, takze to neznamena, ze u AMD nejake to vylepseni neni. Nenasel jsem vsak nic, s cim by se v tomto smeru AMD explicitne chlubilo.
https://groups.google.com/forum/#!topic/comp.arch/ULvFgEM_ZSY