GCC rychle kopirovani pameti

[Jan Waclawek]

No, specs je osemetna zalezitost, naviac pan kolega Buchta spominal, ze -O3
to optimalizovalo... takze neviem ci je to tak jednoducho odhalitelne. Asi
by sa dalo ist cestou skumania jednotlivych flagov, ktore sa v tom -O3
schovavaju, ak by bolo treba blizsie zistit nejake podrobnosti. 

Inak ja som pocas rokov nadobudol pocit, ze gcc nevola kniznicne memcpy, ak
ma pocit, ze to vie prelozit sam, ale zatial som nemal potrebu skumat
blizsie. Osobne sa domnievam, ze ak ide o casovo kriticku zalezitost,
netreba sa snazit kompilator dotlacit do niecoho ale treba rovno siahnut
po asembleri a hotovo. V disasembleri som videl uz rozne divociny v tejto
suvislosi. A urcite to bude silne zavisiet aj od verzie gcc; ja sa drzim
pomerne predpotopnej z cias, ked som s tymi armami zacal, lebo nemam rad
prekvapenia.

> Na CM3/4 se dá pracovat pomocí ldr a str i s celým 32.bitovým slovem, 
> které nemusí být zarovnáno, ale patrnì to bude o nìco pomalejší než když 
> to slovo zarovnané je. Kompetentnìji by se k tomu musel vyjádøit asi 
> nìkdo lépe obeznámený s architekturou ARM (wek), 

Cheche, dakujem.

Toto je vlastnost ARMv6, t.j. ano, je to aj v CM3/4, na D a S porte
procesora (instrukcie su vzdy halfword zarovnane a citaju sa vzdy word
zarovnane, pipeline si to potom rozbije na prislusne halfwordy). A je to
pomerne zlozita zalezitost s vychytavkami - kedze AHB zbernica vie len
zarovnane pristupy, tak najzlozitejsi pripad je pristup k wordu ktory nie
je zarovnany ani na halfword (t.j. je na neparnej adrese) - tam procesor
rozbije ten pristup na 3 pristupy - jeden byte, jeden halfword, jeden
byte. Inaksie povedane, do/z "normalnej" pamate ma takyto pristup penaltu
2 cykly oproti plne zarovnanemu pristupu.

wek


 

----- Original Message ---------------

Subject: Re: GCC rychle kopirovani pameti
   From: Miroslav Mraz <mrazik at volny.cz>
   Date: Sun, 10 Jun 2018 14:19:19 +0200
     To: hw-list at list.hw.cz

Letmý pohled do zdrojákù memcpy v newlib a pár pokusù odhalí pøíèinu.

1. Knihovna newlib musí být optimalizována na rychlost. Pokud napø. 
používáte --specs=nano.specs, pak se bude kopírovat byte po byte vždy.
2. Optimálnì jsou kopírovány jen bloky delší než 16 (resp. 64) bytù.
3. Zaèátek jak zdrojového, tak cílového operandu musí být zarovnán na 4 
byte. To není zcela samozøejmé i když samotná délka operandù v bytech je 
dìlitelná 4. Ten linker s tím mùže dìlat rùzné pitomosti podle nastavení 
a struktury prostì nezarovná. V GCC je pomìrnì dobré udìlat nìco jako

struct foo {
   uint8_t a [100];
}__attribute__((aligned(4)));

Tohle se dost dobøe osvìdèilo, nìkteré algoritmy se dají takto zrychlit 
nìkolika násobnì. Jsem líný to mìøit, ale pøedpokládám, že to zabere i u 
toho memcpy() a asi lépe než tím vaším programem.
Na CM3/4 se dá pracovat pomocí ldr a str i s celým 32.bitovým slovem, 
které nemusí být zarovnáno, ale patrnì to bude o nìco pomalejší než když 
to slovo zarovnané je. Kompetentnìji by se k tomu musel vyjádøit asi 
nìkdo lépe obeznámený s architekturou ARM (wek), já jen vím, že na CM0 
to spolehlivì zbuchne na unaligned access.

Mrazík

Dne 9.6.2018 v 11:20 Jaroslav Buchta napsal(a):
> To je mi jasne, ze ten kod neni univerzalni ale je to urceno specialne 
> pro kopirovani jedne struktury dlouhe cca 100B v casove kriticke ISR , 
> ktera je zarovnana na 4B a tim padem OK. Predpokladam tedy, ze 
> instrukcim ldrd a strd neni potreba zarovnat adresu modulo 8 ? Ten druhy 
> while ma byt samozrejme take if, ale prelozi se to stejne. memcpy trvalo 
> tusim pres 10us a tato funkce to zvladne pod 3us (STM32F3)
> 
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list at list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list