abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 23:55 | Komunita

LTS (Long Term Support) podpora Ubuntu 12.04 LTS (Precise Pangolin) skončila po 5 letech od jeho vydání, tj. v dubnu 2017. V březnu 2017 ale Canonical představil placenou ESM (Extended Security Maintenance) podporu, díky které je Ubuntu 12.04 podporováno do dubna 2020. Dnes Canonical potvrdil ESM podporu také pro Ubuntu 14.04 LTS (Trusty Tahr), jehož LTS podpora skončí v dubnu 2019.

Ladislav Hagara | Komentářů: 0
včera 15:00 | Nová verze

Byla vydána verze 3.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (YouTube, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

Ladislav Hagara | Komentářů: 0
včera 14:44 | Nová verze

Po půl roce vývoje od vydání verze 6.0.0 byla vydána verze 7.0.0 překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, clang-tools-extra a LLD.

Ladislav Hagara | Komentářů: 0
včera 13:44 | Nová verze

Byla vydána verze 3.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu. Zrušena byla podpora Pythonu 2.

Ladislav Hagara | Komentářů: 0
včera 00:22 | Komunita

V Norimberku probíhá do pátku ownCloud conference 2018, tj. konference vývojářů a uživatelů open source systému ownCloud (Wikipedie) umožňujícího provoz vlastního cloudového úložiště. Přednášky lze sledovat online. Videozáznamy jsou k dispozici na YouTube. Při této příležitosti byl vydán ownCloud Server 10.0.10. Z novinek lze zdůraznit podporu PHP 7.2. Vydán byl také ownCloud Desktop Client 2.5.0. Vyzkoušet lze online demo ownCloudu.

Ladislav Hagara | Komentářů: 1
včera 00:11 | Pozvánky

Zářijový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 20. 9. 2018 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tentokrát bez oficiální přednášky, ale zato s dobrým jídlem a pivem – volná diskuse na téma IoT, CNC, svobodný software, hardware a další hračky.

xkucf03 | Komentářů: 0
18.9. 16:11 | Komunita

Vývojáři relačního databázového systému PostgreSQL oznámili, že schválili svůj Code of Conduct (CoC) aneb kodex chování vývojářů PostgreSQL.

Ladislav Hagara | Komentářů: 26
18.9. 14:44 | Nová verze

Byla vydána verze 1.0 poštovního serveru Courier (Wikipedie). Aktualizovány byly také související balíčky jako Courier authentication library, Courier-IMAP, SqWebMail, maildrop nebo Cone.

Ladislav Hagara | Komentářů: 1
18.9. 02:22 | Zajímavý software

Společnost ​Versity Software otevřela svůj archivační souborový systém ScoutFS. Zdrojové kódy jsou k dispozici na GitHubu (kernel space, user space) pod licencí GPLv2.

Ladislav Hagara | Komentářů: 29
18.9. 00:44 | Nová verze

Byla vydána verze 4.2 programovacího jazyka Swift (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu. Ke stažení jsou oficiální binární balíčky pro Ubuntu 18.04, Ubuntu 16.04 a Ubuntu 14.04. Přehled novinek ve videozáznamu přednášky z WWDC 2018.

Ladislav Hagara | Komentářů: 6
Na optické médium (CD, DVD, BD aj.) jsem naposledy vypaloval(a) data před méně než
 (13%)
 (15%)
 (20%)
 (23%)
 (25%)
 (4%)
 (1%)
Celkem 371 hlasů
 Komentářů: 33, poslední 16.9. 11:55
Rozcestník

GCC umí assembler lépe než já

10.11.2010 23:31 | Přečteno: 2461× | Programování

Bohužel, GCC je všemocné a i ten assembler umí lépe než já. Ve svém programu potřebuji převádět čísla na řetězce (až 99999999 krát v cyklu). Řetězec musí bít zarovnané vpravo v poli zaků (velikost 8) a obsahovat úvodní nuly, pokud je kratší než 8.

Nejprve jsem použil funkci sprintf(), jenže můj algoritmus byl příliš pomalý - funkce je příliš mocná a tedy i pomalá k takovémuto účelu. Napsal jsem si tedy vlastní funkci a najivně jsem použil inline assembler, že když už to píšu, tak to napíšu nejlépe, jak dokážu. Toto jsem napsal:

void IntToStr8(uint32_t num, char* str)
{
	asm volatile(
		"mov $10, %%ecx\n"
		
		"mov %1, %%eax\n"
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 7(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 6(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 5(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 4(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 3(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 2(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, 1(%0)\n"
		
		"xor %%edx, %%edx\n"
		"div %%ecx\n"
		"add $0x30, %%edx\n"
		"movb %%dl, (%0)\n"
		: 
		: "r"(str), "r"(num)
		: "%eax", "%ecx", "%edx"
	);
}

Pro přehlednost ještě v Intel syntax z objdumpu:

;;;;; IntToStr8
;;;;; Input edi = number, rsi = char[8]  
  405930:       b9 0a 00 00 00          mov    ecx,0xa
  405935:       89 f8                   mov    eax,edi
  405937:       31 d2                   xor    edx,edx
  405939:       f7 f1                   div    ecx
  40593b:       83 c2 30                add    edx,0x30
  40593e:       88 56 07                mov    BYTE PTR [rsi+0x7],dl
  405941:       31 d2                   xor    edx,edx
  405943:       f7 f1                   div    ecx
  405945:       83 c2 30                add    edx,0x30
  405948:       88 56 06                mov    BYTE PTR [rsi+0x6],dl
  40594b:       31 d2                   xor    edx,edx
  40594d:       f7 f1                   div    ecx
  40594f:       83 c2 30                add    edx,0x30
  405952:       88 56 05                mov    BYTE PTR [rsi+0x5],dl
  405955:       31 d2                   xor    edx,edx
  405957:       f7 f1                   div    ecx
  405959:       83 c2 30                add    edx,0x30
  40595c:       88 56 04                mov    BYTE PTR [rsi+0x4],dl
  40595f:       31 d2                   xor    edx,edx
  405961:       f7 f1                   div    ecx
  405963:       83 c2 30                add    edx,0x30
  405966:       88 56 03                mov    BYTE PTR [rsi+0x3],dl
  405969:       31 d2                   xor    edx,edx
  40596b:       f7 f1                   div    ecx
  40596d:       83 c2 30                add    edx,0x30
  405970:       88 56 02                mov    BYTE PTR [rsi+0x2],dl
  405973:       31 d2                   xor    edx,edx
  405975:       f7 f1                   div    ecx
  405977:       83 c2 30                add    edx,0x30
  40597a:       88 56 01                mov    BYTE PTR [rsi+0x1],dl
  40597d:       31 d2                   xor    edx,edx
  40597f:       f7 f1                   div    ecx
  405981:       83 c2 30                add    edx,0x30
  405984:       88 16                   mov    BYTE PTR [rsi],dl
  405986:       c3                      ret

Čas běhu mého algoritmu se zkrátil z 31s na 24s. Docela slušné, říkal jsem si. Jen tak ze zvědavosti jsem si však zkusil napsat něco přímo v C a vyzkoušet rychlost.

void IntToStr8(uint32_t num, char* str)
{
	uint32_t rem;
	
	rem = num % 10;
	str[7] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[6] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[5] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[4] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[3] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[2] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[1] = (char)(unsigned char)(rem + 0x30);
	num /= 10;
	
	rem = num % 10;
	str[0] = (char)(unsigned char)(rem + 0x30);
}

GCC vygenerovalo toto:

;;;;; IntToStr8 - GCC from C++ code
;;;;; Input edi = number, rsi = char[8]
  405930:       b9 cd cc cc cc          mov    ecx,0xcccccccd
  405935:       89 f8                   mov    eax,edi
  405937:       f7 e1                   mul    ecx
  405939:       41 89 d1                mov    r9d,edx
  40593c:       41 c1 e9 03             shr    r9d,0x3
  405940:       43 8d 04 89             lea    eax,[r9+r9*4]
  405944:       01 c0                   add    eax,eax
  405946:       29 c7                   sub    edi,eax
  405948:       44 89 c8                mov    eax,r9d
  40594b:       f7 e1                   mul    ecx
  40594d:       83 c7 30                add    edi,0x30
  405950:       40 88 7e 07             mov    BYTE PTR [rsi+0x7],dil
  405954:       41 89 d0                mov    r8d,edx
  405957:       41 c1 e8 03             shr    r8d,0x3
  40595b:       43 8d 04 80             lea    eax,[r8+r8*4]
  40595f:       01 c0                   add    eax,eax
  405961:       41 29 c1                sub    r9d,eax
  405964:       44 89 c0                mov    eax,r8d
  405967:       f7 e1                   mul    ecx
  405969:       41 83 c1 30             add    r9d,0x30
  40596d:       44 88 4e 06             mov    BYTE PTR [rsi+0x6],r9b
  405971:       89 d7                   mov    edi,edx
  405973:       c1 ef 03                shr    edi,0x3
  405976:       8d 04 bf                lea    eax,[rdi+rdi*4]
  405979:       01 c0                   add    eax,eax
  40597b:       41 29 c0                sub    r8d,eax
  40597e:       89 f8                   mov    eax,edi
  405980:       f7 e1                   mul    ecx
  405982:       41 83 c0 30             add    r8d,0x30
  405986:       44 88 46 05             mov    BYTE PTR [rsi+0x5],r8b
  40598a:       41 89 d0                mov    r8d,edx
  40598d:       41 c1 e8 03             shr    r8d,0x3
  405991:       43 8d 04 80             lea    eax,[r8+r8*4]
  405995:       01 c0                   add    eax,eax
  405997:       29 c7                   sub    edi,eax
  405999:       44 89 c0                mov    eax,r8d
  40599c:       f7 e1                   mul    ecx
  40599e:       83 c7 30                add    edi,0x30
  4059a1:       40 88 7e 04             mov    BYTE PTR [rsi+0x4],dil
  4059a5:       89 d7                   mov    edi,edx
  4059a7:       c1 ef 03                shr    edi,0x3
  4059aa:       8d 04 bf                lea    eax,[rdi+rdi*4]
  4059ad:       01 c0                   add    eax,eax
  4059af:       41 29 c0                sub    r8d,eax
  4059b2:       89 f8                   mov    eax,edi
  4059b4:       f7 e1                   mul    ecx
  4059b6:       41 83 c0 30             add    r8d,0x30
  4059ba:       44 88 46 03             mov    BYTE PTR [rsi+0x3],r8b
  4059be:       41 89 d0                mov    r8d,edx
  4059c1:       41 c1 e8 03             shr    r8d,0x3
  4059c5:       43 8d 04 80             lea    eax,[r8+r8*4]
  4059c9:       01 c0                   add    eax,eax
  4059cb:       29 c7                   sub    edi,eax
  4059cd:       44 89 c0                mov    eax,r8d
  4059d0:       f7 e1                   mul    ecx
  4059d2:       83 c7 30                add    edi,0x30
  4059d5:       40 88 7e 02             mov    BYTE PTR [rsi+0x2],dil
  4059d9:       89 d7                   mov    edi,edx
  4059db:       c1 ef 03                shr    edi,0x3
  4059de:       8d 04 bf                lea    eax,[rdi+rdi*4]
  4059e1:       01 c0                   add    eax,eax
  4059e3:       41 29 c0                sub    r8d,eax
  4059e6:       89 f8                   mov    eax,edi
  4059e8:       f7 e1                   mul    ecx
  4059ea:       41 83 c0 30             add    r8d,0x30
  4059ee:       44 88 46 01             mov    BYTE PTR [rsi+0x1],r8b
  4059f2:       c1 ea 03                shr    edx,0x3
  4059f5:       8d 14 92                lea    edx,[rdx+rdx*4]
  4059f8:       01 d2                   add    edx,edx
  4059fa:       29 d7                   sub    edi,edx
  4059fc:       83 c7 30                add    edi,0x30
  4059ff:       40 88 3e                mov    BYTE PTR [rsi],dil
  405a02:       c3                      ret
O poznání delší (a hnusnější) vygenerovaný kód. Jaké bylo mé překvapení, když se čas běhu algoritmu byl 19s. Ty x86-* procesory jsou asi nějaký šmejďárny, když mají takové pomalé dělení ...        

Hodnocení: 75 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Josef Kufner avatar 10.11.2010 23:46 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Zkus ještě změřit když to bude v cyklu v C. Docela by mne zajímalo, jak si s tím gcc poradí.
Hello world ! Segmentation fault (core dumped)
Jardík avatar 11.11.2010 00:44 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Asi nechápu jak v cyklu v C myslíte. To volání té funkce v cyklu je a volá se to v nejhorším případě 99999999x společně s funkcí na výpočet MD5 tohoto řetězce. Pro mnou měřený běh to bylo uměle nastaveno na 50000000x. To počítání md5 taky nebude rychlé, momentálně používám GChecksum z GLib knihovny. Jinak klidně to zkusím spustit i bez toho MD5.
Věřím v jednoho Boha.
Jardík avatar 11.11.2010 01:12 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tak to je síla :-)
for (uint32_t j = 0; j < 10; ++j)
{
	for (i = 0; i <= 99999999u; ++i) {
		IntToStr8(i, pwd);
	}
}
V případě C funkce 19s, v případě mé funkce v assembleru 2m4s a při použití sprintf() 3m48s. A to se opravdu vyplatí :-)
Věřím v jednoho Boha.
11.11.2010 07:29 CET
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Nebylo mysleno tohle?
void IntToStr8(uint32_t num, char* str)
{
  uint32_t rem;

    for (int i=7;i>=0;i--) {
      rem=num%10;
      str[i]=(char)(unsigned char)(rem + 0x30);
      num /= 10;
    }
}
Jardík avatar 11.11.2010 11:39 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Mně se to teď nechce moc zkoušet, ale naposledy, když jsem měl tato podobný cyklus, kde kompilátor zná počet iterací a není moc velký, tak ho GCC vyhodí a stejně to naskládá za sebe.
Věřím v jednoho Boha.
11.11.2010 11:53 CET
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jojo, tomu bych veril, taky me to napadlo, ze to stejne rozepise jako jsi to napsal. Prakticky je to neco jako makro.
11.11.2010 15:23 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Loop unrolling, sleduješ každou sekundu, teď zmínka o md5 v cyklu... Ty píšeš lamač hesel! ;-) Googluj BarsWF.
Jardík avatar 11.11.2010 15:44 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
:-)
Věřím v jednoho Boha.
Jardík avatar 11.11.2010 15:53 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tam neni zdroják :-(
Věřím v jednoho Boha.
11.11.2010 00:27 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Je třeba si konečně uvědomit, že to co platilo v asm před 10 lety je dnes volovina.

Základní dnešní pravidlo je: nejkratší stroják je až zpravidla několikrát pomalejší, než nejrychlejší stroják.

Mnoho lidí honí bajtíky, předhánější se kdo nepíše nejkratší program ve strojáku, ale takto vznikají ukrutně pomalé programy.

x86 asm je zcela normální. Ukazuje, že zvolit správnou cestu je důležitější, než nejjednodušší přímou cestu.

Například vezmete-li si mapu a uděláte přímku vzdušnou čarou, pak to nebude nejrychlejší cesta z bodu A do bodu B. Například panelák se přelézá dost špatně, kdo má dnes lézt 10 pater nahoru na střechu a pak z ní slaňovat dolů - nehledě na to, že to postup zpomalí.

V reálném životě jsou nejkratší cesta, nejjednodušší cesta a nejrychlejší cesta - tři různé cesty. Proč se tedy divíte že je tomu tak i v asm?

x86 umí, pokud se instrukce vhodně naskládají vykonat v jednom taktu paralelně několik instrukcí naráz a v příznivém případě tím získáte i přes deset operací.

Psát dobře nejrychlejší algoritmy v asm pro x86, nebo pro jakýkoli výkonnější cpu je velmi složité, nedokáže to ani většina assembleristů. Psát v asm nějak je jednoduché, to se naučíte rychle.
11.11.2010 08:06 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Konkrétně problém dělení a zneužití instrukce pro výpočet efektivní adresy je na 80x86 záležitost starší než 10 let. Jen mám takový pocit, že v dávných dobách výrobce dodával stručnou, srozumitelnou a přesto obsáhlou dokumentaci, jejíž součástí byla například tabulka doby zpracování jednotlivých instrukcí. Naposledy když jsem něco hledal pro nové procesory, tak to byly stohy PDF, kde sice všechno bylo systematicky formalizované, ale popis jedné instrukce zabíral i několik stránek.
11.11.2010 16:36 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Problém DIV je problém většiny procesorů. Je to proto, že dělení je náročnější operace a fyzikální zákony prostě neokecáte ani neovlivníte volbami, či propagandou.

Tabulka doby zpracování instrukcí je dnes hovadina, protože instrukce mají proměnnou dobu zpracování instrukcí.

Procesor má dnes několik nezávislých jednotek, které provádějí instrukce paralelně, přesněji řečeno ne instrukce, ale mikroinstrukce, které vniknou překladem instrukcí.

Dnešní x86 procesor je v podstatě virtuální stroj s JIT překladem do mikroinstrukcí, které rozposílá mikroinstrukce paralelně na právě volné výkonné jednotky v procesoru. Takže velmi záleží na pořadí instrukcí, na tom, které instrukce byly předtím a které budou potom.

Dále do toho tvrdě zasahuje cache, protože paměť je dnes mnohem pomalejší, než samotný procesor.

Například memcpy(), které je diskutováno v jakési zprávičce vedle, které kopíruje odzadu samozřejmě bude neoptimální, protože processor je lépe optimalizován a bude rychlejší když bude paměť kopírována odpředu, než odzadu.

Každý model procesoru má jiné mikroinstrukce, jiný počet jednotek, jinak interpretuje závislosti, má jiné množství a trochu jiné mechanismy jak rozdělovat instrukce.

Z toho vyplývá, že doba provedení jedné instrukce se může měnit klidně v rozsahu 1:100 i více podle aktuálního stavu procesoru.

A ta machrovina je umět psát asm tak, abyste nažhavili procesor tak, aby všechno jelo max. rychlostí na plné kule. Jde to, ale nedá se to naučit za odpoledne a ani většina assembleristů to neumí. Proto často kompilátor vygeneruje delší, hnusnější, ale ve svém důsledku rychlejší kód.

Jinak řečeno, tabulka rychlosti isntrukcí je dnes hovadina.
11.11.2010 00:39 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Přirozeně, DIV dokonce nejde pro jiné než defaultní registry EAX a EDX :-D. Škoda, že x86 nemá nějaký pořádný instrukce pro převody mezi bin a dec. Vím, že existují nějaký AAM AAD apod. ale ty nejsou pro větší registry než 8bit :-( (teda aspoň u CPU tak do pentia2, novější jsem nestudoval...).
11.11.2010 00:46 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
DIV je pomalá instrukce už z principu. To není tím, že by fungovala jen pro určité registry, ale tím, že je prostě náročná.

Pokud jste někdy dělil v základní škole čísla ručně, tak jistě víte, že je to složitější, než násobení.

Proto se vyplatí v jednodušších případech dělení nahradit rotacemi a případně s pomocí násobení.
11.11.2010 02:37 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Když jsem ve škole celočíselně dělil 10, tak to bylo mnohem jednodušší než násobení, stačilo vymazat poslední číslici. Kdežto u násobení jsem musel pracně dopsat nulu ;-). Já jsem totiž mluvil o instrukci DIV jen v části o omezenosti na registrech, to se dá v mikrokódu krásně obejít. Pro zmiňovanou úlohu pak zase není DIV potřeba, tam jsem psal o dělení 10 což je úplně jiná úloha.

Jinak dělička v počítači může mít mnoho podob, jedna z nich může být třeba tabulka, ale to už je dost extrém :-). Nicméně ta pak má dobu trvání jeden takt.

11.11.2010 08:07 Stevko | skóre: 3 | Praha
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
A keby sa v škole používala sedmičková sústava, tak bude takto triviálne delenie a násobenie siedmimi (a na násobenie a delenie desiatimi sa bude nadávať). Pre počítač je pre zmenu jednoduché deliť a násobiť dvomi (pripíše alebo škrtne nulu).
Príspevok nemá byť ukončený spojením „môj názor“.
11.11.2010 16:20 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Imho dělení jedním konkrétním číslem je rychlý všude. Nicméně moje věta pro daný příklad od MP platí :-D.
11.11.2010 00:44 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jinak se dá také hodně optimalizovat algoritmem. Například poslední % operace je zbytečná, a pokud nechcete rychlost jen přibrzdit, pak je k ničemu.

Dále pokud předpokládáš, že většina čísel bude menších, než plný rozsah typu, pak se hodí aspoň někde porozhazovat několikrát dotaz, zda už je číslo nula a pak případně přeskočit další zbytečné / a % operace a rovnou nasázet do řetězce nuly. Už jen to Vám v průměrné aplikaci zrychlí převod výrazně.

Jinak fpu dělení je rychlejší, než integer dělení na x86 a navíc fpu výpočty jdou paralelně k integer jednotce.

Možná by se také dal přepsat algoritmus do simd instrukcí, kde by asi další zrychlení bylo několikanásobné. To už ovšem gcc nevymyslí, to je ruční práce.
Jardík avatar 11.11.2010 01:13 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Děkuji za vysvětlení. Už jsem zase o trochu chytřejší :-)
Věřím v jednoho Boha.
11.11.2010 14:41 extremni lama | skóre: 14 | blog: e_lama
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ja jsem kdysi delal algoritmus na konvoluci obrazu s matici 4x4 (plus par dalsich operaci) a zkusil jsem to napsat v asm. Pouzival jsem tam SSE takze teoreticky by to melo byt o dost rychlejsi, snazil jsem se aby mezi po sobe jdoucima instrukcema nebyly datovy zavislosti, dal jsem si dost prace s odstranenim podminenyho skoku ve vnitrni casti (nahradil jsem to pomoci nekolika AND/OR, uz presne nevim jak to bylo...) a vysledek? Obycejnej for v C++ byl rychlejsi...

The enemy of my enemy is still my enemy.
11.11.2010 16:47 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Já jsem zkoumal měsíc a hrál jsem si s benchmarkem, než jsem přišel na to, co x86 potřebuje.

Pak to ale začalo lítat.

Nemyslete si, že na to přijdete rychle a vlastním pokusem. Není to jak jednoduché a nedá se to tak rychle naučit, je třeba se v tom nějakou dobu vrtat, než budete schopen psát rychlé věci v asm.

A na co lidé zapomínají, úpravou algoritmu jde získat neuvěřitelné zrychlení. Já v každém programovacím jazyce napíše stejný algoritmus trochu jinak. Je třeba v C psát pro C, v Javě psát pro Javu, v asm psát pro asm. Když se na to podíváte, ani to gcc do strojáku nepřeloží přesně Vás zdroják a snaží se to změnit, pokud to dokáže analyzovat.

Rychlost v asm se nepoddá hned, to je jak ženská, musíte strávit dost času, než přijdete na to jak jí sbalit, pokud to děláte prvně v životě. Některé věci prostě chtějí praxi a zkoušet. Znovu říkám, neumí to každý, ani většina lidí co dělá asm.

Každý výkonný procesor je o tom, že když znáte asm dobře, můžete ho rozlítat do neuvěřitelných obrátek. x86 má neuvěřitelný výkon, pokud to potřebujete. A také má dost výkonu na to, aby uchodil špatný, nebo neoptimální asm, nebo to co vychází z kompilátorů. Asm je o tom, že máte tu možnost vymáčknout maximum, ale není to sranda. Je to docela věda a dost složitá.
11.11.2010 01:50 __dark__
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To je jednoduché, vypadl DIV;-) Jinak asi vím, jak by ten kód šel ještě zrychlit, pokud jsou vstupní hodnoty malé, ale nechce se mi to zkoušet :)
11.11.2010 02:16 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Btw ještě k samotnému programu: Proč vlastně potřebuješ převádět integery na řetězce a proč zrovna do desítkovýho kódu? A proč se bude konat právě 100M-1 cyklů? Například pokud by ti stačily čísla v hexa, tak by to šlo možná ještě víc zrychlit...
Jardík avatar 11.11.2010 02:54 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
kuk, ale nikomu neříkat. :-) Přišlo mi to pomalé a potřebuju zrychlení.
Věřím v jednoho Boha.
11.11.2010 03:09 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
OMG co třeba inkrementovat znaky v řetezci (jedno odkud) a to pro 0x30 a při 0x39 přetýct do dalšího. Dokonce by na to šlo možná i použít ty instrukce AAM apod...
Jardík avatar 11.11.2010 12:12 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
No jo, jsem blbej, trvá to několikanásbně méně, konkrétně 4s.
Věřím v jednoho Boha.
11.11.2010 15:23 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Aneb pokud už kompilátor dostatečně neoptimalizuje, tak je třeba změnit zadání ;-).

P.S. Jak dlouho trvá vygenerování rainbow tabulky? :-D
11.11.2010 15:30 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jinak samozřejmě pokud chceš časovou náročnost O(1), tak nevymýšlej znova kolo: http://md5hashcracker.appspot.com/status
12.11.2010 12:39 flexo
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Vygenerování rainbow tabulky trvá dlouho, už dva dny generuju tabulku pro ntlm, která bude mít ve výsledku tak 2GB, a pořád jsem někde na začátku.:)
11.11.2010 15:26 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
:-D
11.11.2010 05:12 JS
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Za prve, to neni zadna novinka, ze kompilator je v assembleru lepsi nez programator. Existuje par vyjimek, ale ty pokryva za druhe, ze to temer nikdy neni dobry napad, snazit se psat si vlastni knihovni funkce. Z toho existuje vyjimka, ze to ma smysl tehdy, pokud explicitne vite, v cem jsou pomale.
11.11.2010 16:52 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Kompilátor je v asm lepší, než 99% asm programátorů. To jsem psal už mnohokrát.

Je možné ho překonat, ale stojí to moc času, a chce to vysoké znalosti. Vyšší, než si je většina lidí schopna připustit. Ergo člověk musí vědět proč to dělá - jak píšete, vědět jak na to a v čem je to pomalé.

Psát si vlastní knihovní funkce nemusí být od věci, je to jedna ze smysluplnějších použití asm. Například pokud potřebujete skutečně rychlost a memcpy() kopíruje odzadu, pak je lépe si napsat vlastní implementaci memcpy(), která bude rychlejší,než co předvádí libc, pokud má pravdu ta zprávička vedle.
11.11.2010 16:59 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Hmm proč se vůbec na memcpy nepoužívá paměťový přenos bez účasti procesoru?
11.11.2010 17:29 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
1) pokud vim, zadna takova jednotka obecne v beznych pocitacich neni

2) nastaveni transferu takovou jednotkou (zejmena pro userspace programy) by trvalo o nekolik radu dele nez samotny transfer udelany procesorem. (pro obvykla mnozstvi dat). O trochu lepsi by to bylo, kdyby slo o jednotku, ktera by byla primo soucasti CPU ovladana specialni instrukci (podobne jako treba FPU), odpadly by problemy s MMU, ale zase je otazka, zda by to necemu pomohlo.
11.11.2010 17:48 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To fakt na novějších x86 nejsou nějaký DMA enginy pro celou RAM? Jinak samozřejmě účinnost by se zvyšovala s délkou přenášené oblasti. Takovejch 1024B by byl rychlejší přes DMA.
11.11.2010 18:09 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jen taková poznámka: Fyzická paměť a paměť, kterou vidí program není totéž.

Takový DMA by musel počítat s tím, že souvislý blok paměti z heldiska procesu není souvislý blok ve fyzické paměti.

Dále by DMA musel počítat s tím, že fyzická paměť dokonce vůbec nemusí existovat, ale může být ve swapu.

Dále DMA může umět zapsat někam, kde to proces nemá povoleno.

Nevěřte tomu, že by 1KB DMA byl obecně rychlejší. Se vším tím servisem kolem by zoufale zaostával.

A nebo byste musel procesu a jeho paměti dát další podmínky.
11.11.2010 19:04 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Takový DMA by musel počítat s tím, že souvislý blok paměti z heldiska procesu není souvislý blok ve fyzické paměti.
To je fakt, granularita po stránkách ujde. Jinak scatter gather.
Dále by DMA musel počítat s tím, že fyzická paměť dokonce vůbec nemusí existovat, ale může být ve swapu.
To je fakt. Ale to je stejný jako u memcpy imho.
Dále DMA může umět zapsat někam, kde to proces nemá povoleno.
Tak to je na OS :-D.
Nevěřte tomu, že by 1KB DMA byl obecně rychlejší. Se vším tím servisem kolem by zoufale zaostával.
Tak samozřejmě musely by být nějaký semafory apod. Ale je celkem blbý v době, kdy probíhá po světě paralelizace úloh kopírovat celým jádrem bajt po bajtu. Jinak ten kilobajt jsem prostě jen tak nadhodil, klidně to může být ona stránka.

Ale je fakt škoda, že DMA neumí spolupracovat s MMU :-(.
11.11.2010 20:26 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
>> Dále by DMA musel počítat s tím, že fyzická paměť dokonce vůbec nemusí existovat, ale může být ve swapu.

> To je fakt. Ale to je stejný jako u memcpy imho.

memcpy to dělá po bytech, u každého z nich se testuje výpadek paměti a ten je v případě potřeby ošetřen. DMA by musela to přemapovávání dělat v podstatě taky pro každý byte aby zjistila, jestli už nevypadla, což je něco zcela jiného, než dělá teď.

>> Dále DMA může umět zapsat někam, kde to proces nemá povoleno.

> Tak to je na OS :-D.

Právě že zas tak moc ne, protože když DMA obejde CPU, tak si toho OS prostě nevšimne
11.11.2010 21:23 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Právě že zas tak moc ne, protože když DMA obejde CPU, tak si toho OS prostě nevšimne
Myslel jsem to tak, že by měl OS vědět kam se může zapisovat a kam ne a tedy znát, že celej rozsah je validní a lze do něj zapisovat. Jinak třeba na takovým OMAPu se používá DMA na triviality jako rotace bitmapy.
11.11.2010 21:33 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To by OS buď musel analyzovat ten spuštěný kód za běhu, nebo by se to DMA muselo používat jako volání OS, nikoli jako funkce v programu.
11.11.2010 21:40 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
nebo by se to DMA muselo používat jako volání OS, nikoli jako funkce v programu.

To tak ale obvykle bývá, že když využíváš nějaké zařízení, používáš k tomu volání jádra. (Další zdroj zdržení a důvod dělat to rovnou.)
Quando omni flunkus moritati
11.11.2010 21:41 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jj myslel jsem volání OS, ale to by bylo asi fakt dost pomalý :-/.
11.11.2010 22:05 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Jinak třeba na takovým OMAPu se používá DMA na triviality jako rotace bitmapy.“

Koukejte, pro ochranu paměti a vyšší funkce a větší luxus procesoru je třeba něco obětovat.

V takovém MS-DOSu na x86 byste s DMA neměl sebemenší problémy.

Stejně tak si můžete pro x86 napsat svůj vlastní hloupý, primitivní operační systém, na kterém rovněž nebudete mít s DMA problémy.

ARM jádro pracuje s pamětí setsakra blbě a setsakra pomalu. Jeho RISCová architektura typu load/store potřebuje třeba i několik instrukcí na paměťovou operaci ve strojáku na to, co x86 dokáže často jednou instrukcí.

Tudíž z hlediska ARMu je DMA skoro nutnost, má-li mít rozumný výkon. Jeho přístup k paměti výkon ARMu diskvalifikuje pro nějaké rychlejší operace.

x86 je jiná architektura, navíc na ní jsou provozovány chytřejší operační systémy, které počítají se stránkováním, ochranou paměti, swapováním a ochranou procesů mezi sebou. Pokud se toho všeho vzdáte, tedy napíšete ten blbý operační systém, nebo uděláte MS-DOS, pak nemáte sebemenší problém s DMA.
11.11.2010 22:18 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
ARM jádro pracuje s pamětí setsakra blbě a setsakra pomalu. Jeho RISCová architektura typu load/store potřebuje třeba i několik instrukcí na paměťovou operaci ve strojáku na to, co x86 dokáže často jednou instrukcí.
... až na to, že těch i několik instrukcí zvládne provést rychleji než odpovídající x86. To, že odpovídající x86 je dneska zastaralá šunka, je důsledek faktu, že x86 má mnoholetý náskok ve vývoji (než se zjistilo, že pro mobilní stroje apod. se x86 nechytá a že to chce něco jiného - efektivnějšího.)
x86 je jiná architektura, navíc na ní jsou provozovány chytřejší operační systémy, které počítají se stránkováním, ochranou paměti
Používání ARM nic takového nevylučuje.
Quando omni flunkus moritati
12.11.2010 06:17 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Používání ARM nic takového nevylučuje“

To nevylučuje, protože ochranu paměti, či stránkování si de facto můžete navěsit třeba i na feritovou paměť z doby vzniku FORTRANu. Externí čip to umožňuje.

Nicméně každý x86 cpu má přímo jako součást jádra ochranu paměti, stránkování a další features. A také o tom procesor ví a řídí to.

U ARMu je to z hlediska jádra cpu externí součást, kterou neřídí a nezná o ní přímo podrobnosti.

12.11.2010 09:55 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
U ARMu je to z hlediska jádra cpu externí součást, kterou neřídí a nezná o ní přímo podrobnosti.
[citation needed] Nebo jinak - co je podle tebe externí součást? Čip o kousek vedle procesoru? Kdy žiješ?

A btw. i kdyby to tak bylo, nic to nemění na tom, že bude fungovat stránkování, ochrana paměti atd.
Quando omni flunkus moritati
11.11.2010 22:21 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
x86 je jiná architektura, navíc na ní jsou provozovány chytřejší operační systémy, které počítají se stránkováním, ochranou paměti, swapováním a ochranou procesů mezi sebou.
No já nevím, thumb módy v ARMu jsou imho dost velkej hi-tech ;-).
co x86 dokáže často jednou instrukcí
I po rozložení do vlastního mikrokódu?

Já si osobně myslím, že DMA by šla pro memcpy použít a i přes náročný servis by to pro tisíce bajtů bylo větší zrychlení, i když možná jen pro speciální případy. Kopírování textu do konzole uživateli stačí imho bit po bitu :-D, pro periodické kopírování by to význam mělo určitě (nebylo by potřeba nastavovat vše znova).
11.11.2010 23:00 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Aplikace, která periodicky potřebuje stejně kopírovat stejné tisíce bajtů, je dost pravděpodobně rozbitá. A pokud se něco takového vyplatí jenom ve speciálních případech, nevyplatí se tím vůbec zabývat na architektuře/OS, které mají sloužit univerzálně.
Quando omni flunkus moritati
11.11.2010 23:11 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Co třeba vykreslování GUI?
12.11.2010 00:21 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Vykreslování GUI moc kopírování z hlavní paměti do hlavní paměti používat nebude.

Quando omni flunkus moritati
12.11.2010 00:29 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Co manipulace s bitmapou v "malování" ?

Ale jinak asi jo bylo by to dost speciální použití. BTW takový multimedia taky mají svojí podporu v CPU.
12.11.2010 00:39 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
BTW takový multimedia taky mají svojí podporu v CPU.

To jo, ale to už je trochu něco jiného.

U multimediálních instrukcí je to použít nejstarší x86 instrukce a dělat něco dlouho vs. použít mutimediální instrukce a dělat to rychleji.

U kopírování pomocí DMA chceš kopírovat pomocí DMA enginu a zároveň dělat něco jiného.

V tom prvním případě se mění jenom to, jak něco děláš z hlediska instrukční sady. V tom druhém se pokoušíš paralelizovat něco, co dost dobře paralelizovat nejde (viz. ten kus kódu níže), tzn. v praxi by ti stejně nezbylo nic jiného, než během kopírování buď čekat*, nebo zpracovávat úplně jinou úlohu (nevýhody jsem popisoval jinde)

* tohle by mohlo mít smysl třeba v případě, že bychom chtěli šetřit energii. Během kopírování by se CPU přepnul do nějakého úsporného režimu (malá úspora, rychlé probuzení) a kopírování by zajistil na energii méně náročnější DMA engine. I v tomhle případě bych ale řekl, že by bylo jednodušší prostě umožnit uspávání těch částí CPU, které se při kopírování nevyužijí.

I když tady se zase objevují záležitosti typu jak poznat, že teď je možné se uspat atd.
Quando omni flunkus moritati
12.11.2010 00:52 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
a = cekej_na_nejaka_data_a_vrat_na_ne_ukazatel();
b = dej_mi_ukazatel_na_cilovy_blok();
c = rekni_mi_kolik_bytu_mam_kopirovat();
memcpy(b, a, c); // implementováno neblokující instrukcí, která používá DMA
udelej_neco_s_daty_v_bloku(b);
Ještě mě napadlo, že vlastně by ten příklad šel i s DMA, například pokud by bylo vyžadováno malé latence, ale vyžadovalo by to paralelnější přístup k kódu. Ta memcpy totiž pro určité funkce udelej_neco_s_daty_v_bloku() nemusí nutně kopírovat celý béčko. Pokud by zkopírovala jen třeba prvních 64bajtů, tak by se během dalšího přenosu 64bajtů mohlo současně zpracovávat tou funkcí těch prvních 64B. Což by ve výsledku mohlo znamenat třeba i dvojnásobný zrychlení.

11.11.2010 21:38 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To je fakt. Ale to je stejný jako u memcpy imho.

Není (a Gilhad v #40 o kousek vejš nemá pravdu). Memcpy běží v userspace, takže když se pokusí sáhnout na paměť, která je zrovna odswapovaná, CPU hodí výjimku, jádro ji chytí, stránku někam nahraje a pak se program nechá běžet dál.

Nic takového, jako že by memcpy po bytech kontrolovala, jestli nedošlo k výpadku paměti, se neděje. Dokonce AFAIK ani nemůže (proces neví, které jeho stránky v paměti jsou a které ne)
Tak samozřejmě musely by být nějaký semafory apod.
Hádám, že servisem je myšleno nastavit to DMA zařízení atd. To bude trvat relativně dlouho (I/O), dost dlouho na to, aby se vyplatilo udělat to přímo.
Ale je celkem blbý v době, kdy probíhá po světě paralelizace úloh kopírovat celým jádrem bajt po bajtu.
a) nevim, kde jste přišli na to byte po bytu. Na moderních procesorech to pravděpodobně bude v o něco větších kusech.

b) klidně můžeš udělat paralelní kopírování. Nastavení vláken a jejich vzájemné čekání atd. atp., zkrátka to zase bude trvat déle než to zkopírovat sériově jedním CPU.
Quando omni flunkus moritati
11.11.2010 22:05 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Není (a Gilhad v #40 o kousek vejš nemá pravdu). Memcpy běží v userspace, takže když se pokusí sáhnout na paměť, která je zrovna odswapovaná, CPU hodí výjimku, jádro ji chytí, stránku někam nahraje a pak se program nechá běžet dál.
Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapu (btw už to samotný natažení ze swapu pravděpodobně koná DMA).
Nic takového, jako že by memcpy po bytech kontrolovala, jestli nedošlo k výpadku paměti, se neděje. Dokonce AFAIK ani nemůže (proces neví, které jeho stránky v paměti jsou a které ne)
Jo to mě trochu zmátlo... :-D.
Hádám, že servisem je myšleno nastavit to DMA zařízení atd. To bude trvat relativně dlouho (I/O), dost dlouho na to, aby se vyplatilo udělat to přímo.
Tak na x86 asi jo, někde jinde nemusí ;-).
a) nevim, kde jste přišli na to byte po bytu. Na moderních procesorech to pravděpodobně bude v o něco větších kusech.
To byla nadsázka, ale klidně můžeš nahradit bajt skalárem a bude to mít stejnej význam. Právě jsem myslel, že by se hodilo v tomhle případě pracovat s vektorem. Teoreticky by šla substituovat současná instrukce REP MOVSD na nějakej triviální automat skalárního kopírování, pro program by se to jevilo jako vektor.
b) klidně můžeš udělat paralelní kopírování. Nastavení vláken a jejich vzájemné čekání atd. atp., zkrátka to zase bude trvat déle než to zkopírovat sériově jedním CPU.
Jj, ale to dneska znamená plýtvat ALU jednoho jádra na kopírování, při DMA by byl celý ALU k dispozici a mohl třeba Jardíkovi louskat md5 :-D.

11.11.2010 22:11 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Tak na x86 asi jo, někde jinde nemusí“

Třeba na tom Vámi zmiňovaném ARMu je rychlost I/O katastrofa. I/O je tam realizováno mapováním do paměti. Pravidelně mají hardwaráři protáhnuté obličeje zklamáním když zjistí, jak rychlej běhalo I/O na primitivních 8mi bitových procesorech a jak pomalé reakce se dočkávají na ARMu.

Sem tam někomu rupnou nervy a pak raději na ARMu simuluje I/O jako koprocesor. ARM si myslí, že posílá strojové instrukce koprocesoru a elektronika tím maskuje I/O aby dosáhla aspoň nějak rozumné I/O rychlosti.

Nedělejte si iluze, x86 je hodně nalepovák, ale z hlediska výkonu je to excelentně dobrá architektura. Není to tak dávno, kdy se řada odpůrců těšila na to, že x86 architektura a celé CISC půjde do háje z důvodů nedostatečného výkonu. Nakonec se ukázalo, že právě univerzalita a vysokoúrovňovost x86 strojáku je mocná zbraň pro dosahování výkonu.
11.11.2010 22:32 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Třeba na tom Vámi zmiňovaném ARMu je rychlost I/O katastrofa. I/O je tam realizováno mapováním do paměti.
Fuj, radši pomalejší zápis do MMIO než používání brutálně neflexibilního IN/OUT na x86, navíc když to fyzicky používá tak jako tak stejný adresní dráty do procesoru. Věci jako MMU na IO je pak pozitivní vedlejší produkt.

Programování I/O ve stylu 8bit je humus. Typově třeba uart řadič na způsob tady je registr na vysílaný bajt, ale pokud je v tom a tom registru v tom a tom bitu tahle hodnoa, tak to je nastavení děličky hodin, ale jen jedna polovina, druhá polovina (8bit) je zase v jiným registru, kterým se jinak ovládá něco jinýho. Když pak člověk pracuje třeba v 32bit prostředí a má 32bit registry, tak si rve vlasy proč to prostě nemohli dát do 32bit registru, kde by dělička měla rezervu na tisíc let dopředu :-D.
Nedělejte si iluze, x86 je hodně nalepovák, ale z hlediska výkonu je to excelentně dobrá architektura.
No moje priority jsou: nalepovák → určitě ne nejlepší řešení.
Není to tak dávno, kdy se řada odpůrců těšila na to, že x86 architektura a celé CISC půjde do háje z důvodů nedostatečného výkonu. Nakonec se ukázalo, že právě univerzalita a vysokoúrovňovost x86 strojáku je mocná zbraň pro dosahování výkonu.
To spíš kvůli vendor lock-inu.
12.11.2010 06:33 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Programování I/O ve stylu 8bit je humus.“

Na x86 architektuře klidně můžete mít I/O mapované do paměti. Naprosto nic tomu nebrání. A také se to v řadě případů dělá.

Na ARMu se rychlé I/O musí doslova ochcat. ARM prostě nepočítá s rychlými I/O.

Nebo si pročtěte v manuálu kolik taktů hodin u ARMu trvá reakce na přerušení. Budete zvracet. Když ARM na FIQ (fast interrupt request) zareaguje do 30 taktů hodin, jste zhruba na nejnižší možné hodnotě zpoždění.

ARM není silný v rychlosti I/O, ani v rychlosti reakce na vnější podněty. Věřím, že by šlo na x86 najít leccos špatného, ale rychlost I/O je něco, kde jde o ARMu střílet velmi úspěšně. Tak špatně jako ARM na tom není 99% jiných druhů procesorů.

„No moje priority jsou: nalepovák → určitě ne nejlepší řešení.“

V tom případě si ARM také rovnou škrtněte. ARM je poměrně dosti nalepen.

Od doby prvního modelu před cca 26 lety a první verze ARMu se leccos muselo opravovat, přelepit. Prznit instrukce, které měly jiný význam a nacházet volné strojové kódy pro nové instrukce. Úplně stejně jako x86.

Jestli si myslíte, že budete mít někdy architekturu starou 20 let a nebude v ní hafo nalepováků, tak jste naivní.
12.11.2010 18:28 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Na x86 architektuře klidně můžete mít I/O mapované do paměti. Naprosto nic tomu nebrání. A také se to v řadě případů dělá.
Takže tu je IN/OUT a ještě MOV? teda dva různé cykly generované chipsetu. To je ještě horší ;-).
Nebo si pročtěte v manuálu kolik taktů hodin u ARMu trvá reakce na přerušení. Budete zvracet. Když ARM na FIQ (fast interrupt request) zareaguje do 30 taktů hodin, jste zhruba na nejnižší možné hodnotě zpoždění.
To bude hlavně kvůli tomu, že má každý blok vlastní hodiny ne? BTW v manuálu OMAP3 je u interrupt latency hodnota 10 (ale je možný se se ještě někde nabere).

Jinak já mám Duron 600MHz a stačí mě to. Mě o nějaké latence přerušení fakt nejde. Za to mě jde třeba o dokumentaci čipu, takový zamknutý násobiče u Intelu je fakt opruz.
V tom případě si ARM také rovnou škrtněte. ARM je poměrně dosti nalepen.
Ale já nechci škrtat. Jen v případě nalepováku se prostě sníží priorita meho zájmu.
Jestli si myslíte, že budete mít někdy architekturu starou 20 let a nebude v ní hafo nalepováků, tak jste naivní.
S tím počítám.

11.11.2010 22:55 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Není to tak dávno, kdy se řada odpůrců těšila na to, že x86 architektura a celé CISC půjde do háje z důvodů nedostatečného výkonu. Nakonec se ukázalo,
...že když x86 převezme nějaké myšlenky RISC architektury, že může existovat dál. Což se stalo asi tak před pěti - deseti lety.

Hlavní výhoda RISC architektur je v tom, že má sice jednoduché instrukce, takže na stejnou věc jich je potřeba víc, ale ty instrukce se vykonávají mnohem rychleji, takže celkově je ten procesor podstatně rychlejší.

Mimo jiné, srovnávat dnešní ARM s dnešními x86 není úplně fér, protože x86 se přece jenom vyvíjelo déle. A krom toho - kdyby x86 uměla všechno, co je potřeba, ARM by nikdo nepoužíval. Vývoj není zadarmo, přesto se ARM vyvíjí a používá, což nějaký důvod asi mít bude.

Quando omni flunkus moritati
11.11.2010 23:04 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
A krom toho - kdyby x86 uměla všechno, co je potřeba, ARM by nikdo nepoužíval. Vývoj není zadarmo, přesto se ARM vyvíjí a používá, což nějaký důvod asi mít bude.
+1 a vendor lockin, nezapomínej na vendor lockin :-D.
12.11.2010 06:05 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Hlavní výhoda RISC architektur je v tom, že má sice jednoduché instrukce, takže na stejnou věc jich je potřeba víc, ale ty instrukce se vykonávají mnohem rychleji, takže celkově je ten procesor podstatně rychlejší.“

Je se to v praxi nepotvrzuje, takový drobný detail. Ale nenechte se realitou nikterak zneklidnit.
12.11.2010 09:45 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ale nenechte se realitou nikterak zneklidnit.
... říká astrolog, co tu nedávno tvrdil, že dělení na FPU je rychlejší než pomocí SSE2 a trvá jeden tik hodin. (Nebo tak nějak to bylo, že?)
Je se to v praxi nepotvrzuje, takový drobný detail.
V praxi se to potvrdilo velmi dobře, třeba v době, kdy ještě byly peníze na vývoj (řekněme rok '95), PowerPC naprosto válcovalo x86. Co se výkonu týče, x86 bylo za PowerPC opožděno o nějaké dva až tři roky.

Ano, svět x86 nakonec to zpoždění dohnal, jenže ne díky CISC architektuře, ale díky tomu, že jistý majoritní OS PowerPC nepodporoval, takže trh s těmito CPU byl menší a tím bylo i míň peněz na vývoj.
Quando omni flunkus moritati
12.11.2010 10:22 Randy_Sh
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já

Ano, svět x86 nakonec to zpoždění dohnal, jenže ne díky CISC architektuře, ale díky tomu, že jistý majoritní OS PowerPC nepodporoval, takže trh s těmito CPU byl menší a tím bylo i míň peněz na vývoj.

Není to hlavně tím, že x86 CPU jsou od jisté doby uvnitř RISCové? Pokud se pamatuji, tak uvnitř se dělá překlad x86 instrukcí na RISCové. Tedy aspoň to tak výrobci prezentovali.

12.11.2010 11:54 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Není to hlavně tím, že x86 CPU jsou od jisté doby uvnitř RISCové?
Viz první odstavec v #58 (o kousek výš) ;-)

Všechno souvisí se vším. Kdyby nebylo tolik peněz na vývoj, respektive kdyby výchozí postavení těch procesorů bylo rovnocenné, těžko by si někdo mohl dovolit udělat takový převrat v architektuře. Neměl by na to prachy.
Quando omni flunkus moritati
12.11.2010 13:02 Randy_Sh
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Myslím, že těch převratů v architektuře bylo víc. Všechny ty triky pro zvýšení výkonu jako pipelining, superskalární zpracování, out-of-order také musely znamenat kompletní překopání CPU. Proti tomu mi přijde rozklad CISC instrukcí na RISC jako poměrně jednoduchý úkol.
12.11.2010 11:16 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
V praxi se to potvrdilo velmi dobře, třeba v době, kdy ještě byly peníze na vývoj (řekněme rok '95), PowerPC naprosto válcovalo x86. Co se výkonu týče, x86 bylo za PowerPC opožděno o nějaké dva až tři roky.
Ono je to vidět i nedávno/dnes. Viz třeba obliba PS3 s Cellem.
12.11.2010 12:32 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ono je to vidět i nedávno/dnes.
A nejenom na "velkých" procesorech typu x86... u malých jednočipů to platí úplně stejně
Quando omni flunkus moritati
12.11.2010 06:24 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Mimo jiné, srovnávat dnešní ARM s dnešními x86 není úplně fér, protože x86 se přece jenom vyvíjelo déle. A krom toho - kdyby x86 uměla všechno, co je potřeba, ARM by nikdo nepoužíval. Vývoj není zadarmo, přesto se ARM vyvíjí a používá, což nějaký důvod asi mít bude.“

ARM se používá pro nízkou spotřebu a vyšší poměr cena / výkon. Nicméně v absolutním výkonu ARM nemůže x86 konkurovat.

Při všem Vašem svatém zaujetí pro RISC a ARM Vám uchází jedna věc. ARM je navržen tak, aby se dal zadrátovat přímo a snadno architekturou hw. Bohužel ani návrháři ARMu netušili a netuší, kam se monožsti hw vyvinuli a vyvinou. Postupně v ARM narůstá spousta věcí, které jsou tam pouze z historických důvodů (protože pro to byl před lety dobrý důvod, dnes už nikoli).

Znovu zdůrazňuji, ARM instrukce jsou pomaleji vykonávány, než x86 instrukce a to přesto, že x86 instrukce nahradí často několik ARM.

Kdyby ARM chtěl vykonávat instrukce tak rychle, jako x86, neměl by smysl a zanikl by. Musel by to totiž doplnit řadu predikčních, paralelních a dalších jednotek jako to má x86. Čímž by jeho spotřeba vzrostla a žral by víc jak x86, ale stále by měl menší výkon, protože dřevěnost jeho instrukcí by výkon hodně stahovala. Pak by ARM neměl smysl. V neposlední řadě do vývoje a zdokonalování x86 byly vraženy takové prachy, jaké ARM mít nikdy nebude.

12.11.2010 09:54 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Nicméně v absolutním výkonu ARM nemůže x86 konkurovat.

Jo, tady se projevuje ten několikaletý náskok ve vývoji.
Znovu zdůrazňuji, ARM instrukce jsou pomaleji vykonávány, než x86 instrukce a to přesto, že x86 instrukce nahradí často několik ARM.
Jestli to náhodou trochu nesouvisí s tím, že ARM CPU bývají taktovány na ~500MHz, kdežto x86 na 2GHz a více.
V neposlední řadě do vývoje a zdokonalování x86 byly vraženy takové prachy, jaké ARM mít nikdy nebude.
Hvězdy promluvily...
Quando omni flunkus moritati
12.11.2010 17:55 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jestli to náhodou trochu nesouvisí s tím, že ARM CPU bývají taktovány na ~500MHz, kdežto x86 na 2GHz a více.

Dle mych zkusenosti maji bezne ARMy vyrazne nizsi vypocetni vykon/MHz i pri srovani s Atomem, a ten ma zase vyrazne nizsi vykon/MHz nez mainstreamove x86 procesory. Jina vec je ale vypocetni vykon/Watt prikonu.
Grunt avatar 12.11.2010 17:59 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
K tomu bych se přidal.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 11:59 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
ARM se používá pro nízkou spotřebu a vyšší poměr cena / výkon.

Takže jeho hlavním konkurentem budou platinové abakusy s kuličkami ze zlata? Ty mají poměr cena/výkon ještě o několik řádů vyšší :)
12.11.2010 19:19 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ovšem na kuličky abakusu z ostrůvku stability (protonové číslo okolo 108) to nemá :-D.
12.11.2010 19:08 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Postupně v ARM narůstá spousta věcí, které jsou tam pouze z historických důvodů (protože pro to byl před lety dobrý důvod, dnes už nikoli).
Samozřejmě se ani jako zastánce ARMu redukční dietě nebráním.
Nicméně v absolutním výkonu ARM nemůže x86 konkurovat.
Ovšem ale takovej Atom na 800MHz má víc než čtyřnásobnou spotřebu než OMAP3 na 800MHz. Takže na stejný zdroj jako Atom se může zapojit čtyřnásobek OMAPů ;-).
V neposlední řadě do vývoje a zdokonalování x86 byly vraženy takové prachy, jaké ARM mít nikdy nebude.
No právě vendor lockin.
11.11.2010 22:18 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
„Jj, ale to dneska znamená plýtvat ALU jednoho jádra na kopírování, při DMA by byl celý ALU k dispozici a mohl třeba Jardíkovi louskat md5“

V zásadě je ALU škoda na všechno. Mimochodem, klidně si můžete kopírování provést na SIMD instrukcích, pak ALU je nezatěžovaná a cpu x86 bude paraleleně najednou na jednom jádře kopírovat a najednou počítat výpočty. Aniž byste se to nějak staral.

Na SIMD a jenom na SIMD můžete samozřejmě i vypnout zápis do paměťových keší při kopírování (asi 5× rychlejší kopírování, než pokud cpu obsluhuje i cache). A vzhledem k tomu, jak velké bloky se běžně memcpy kopírují, Váš DMA by dostal na zadek. Jako bonus je vše pod kontrolou cpu (tedy funguje stránkováním ochrana paměti, swap, …) a navíc to nezatěžuje cpu, protože to neběží na ALU, takže to jede paralelně s výpočtem.

DMA je operace, která patří do kernelu, a i tam je trochu opruz s ní zacházet. Procesor toho dělá docela dost a u DMA to chybí.
11.11.2010 22:55 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ano to je regulérní řešení, teď jen aby danou verzi SIMD všechny procesory uměly :-D.
12.11.2010 06:42 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Myslím, že je čas, abych v této debatě skončil.

Pokud jedete na 386, pak se SIMD rozlučte. Ovšem SSE2 má dnes i hodně zastaralej křáp.

Jinak možná Vám to uniklo, ale autor příspěvku používal 64bitový asm. A každý 64bitový x86 disponuje SSE potřebnou verzí na takového kopírování.

Nicméně debata se už dostala do slepé uličky. Co mělo být řečeno už bylo.

Vy jste tu přispěl spoustou nesmyslných tvrzení, o kterých nemáte moc ponětí. Další Vaše taktika je jen se politicky prosadit a někoho dostat. Nejvyšší čas skončit.

12.11.2010 09:59 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Myslím, že je čas, abych v této debatě skončil.

Myslím, že je čas si vzpomenout, jak jsi říkal něco o tom, že už tu nebudeš přispívat. Ale jasně, jestli jsi to vyčetl z hvězd, tak je pochopitelné, že ani tahle předpověď ti nevyšla...
Quando omni flunkus moritati
12.11.2010 19:25 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ovšem SSE2 má dnes i hodně zastaralej křáp.
To můžu rovnou napsat pro SSE3...
Jinak možná Vám to uniklo, ale autor příspěvku používal 64bitový asm.
Což ovšem k řešení vůbec nebylo potřeba. Řešený problém lze naprogramovat klidně v BASHi, kde se bude wgetem volat server, který má už dávno rainbow tabulku předgenerovanou.
Vy jste tu přispěl spoustou nesmyslných tvrzení, o kterých nemáte moc ponětí.
Muhehe vyhrál jsem :-D, vydržel jsem dýl a nesnížil jsem se k snižování oponenta :-D (hmm ne že by to nutně nebyla pravda).
Další Vaše taktika je jen se politicky prosadit a někoho dostat.
Přirozeně. Pokud se o ARM bude zajímat víc lidí, tak bude mít aspoň x86 konkurenci a třeba na to zapracuje. Navíc to může mít taky důsledek, že lidi budou lépe řešit úlohy zmíněné v zápisku.
11.11.2010 22:31 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Není (a Gilhad v #40 o kousek vejš nemá pravdu). Memcpy běží v userspace, takže když se pokusí sáhnout na paměť, která je zrovna odswapovaná, CPU hodí výjimku, jádro ji chytí, stránku někam nahraje a pak se program nechá běžet dál.

Uznávám, blbě jsem to vyjádřil. "se testuje" se samozřejmě děje v rámci mikrokódu CPU a "je ošetřeno" samozřejmě probíhá přez ty vyjímky.

Mě šlo spíš o to vyjádřit ten rozdíl, kdy memcpy běží na CPU jako proces uživatele (se všemi omezeními a "iluzemi" o souvislé dostupné paměti, nepřerušovaném běhu atd atd), na rozdíl od DMA, které běží hardwarově jinde a "sahí si přímo na železo", takže ho ty "iluze" ani neomezují (a tudíž by měl OS problémy testovat oprávněnost přístupu do paměti) ani mu nepomáhají (takže neví, kde a zda má který proces namapované stránky).

Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapu (btw už to samotný natažení ze swapu pravděpodobně koná DMA).

A taky zda jde o jednu stránku, nebo třeba několik, zda a jaké práva k přístupu má uživatel ke kterým z nich a po natažení ze swapu by se dotaz rozdělil na několik, podle toho, kam by se to natáhlo a pak by se to po dokončení dotazu zase muselo označit jako modifikované - ono toho není málo, co je pro takovou věc potřeba zařídit, aby "iluze" víceuživatelského OS fungovala bezchybně.

Výhoda memcpy je, že má všechny tyhle věci ošetřené přez cetrální mechanizmus (čili jednotně se zbytkem systému), který ani nevidí (takže to nemůže poškodit)
11.11.2010 22:49 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tak by se před inicializací provedl test dané stránky zda existuje na určeném místě a případně jí natáhl ze swapu
Což musí udělat jádro, čímž se zase dostáváme k syscallům a k tomu, že to rychlejší nebude.
Jj, ale to dneska znamená plýtvat ALU jednoho jádra na kopírování, při DMA by byl celý ALU k dispozici
To jo, ale pro nějakou jinou úlohu; většina programátorů ale chce spíš, aby jejich program běžel rychle. Navíc započítej přepnutí kontextu, spuštění jiného programu, který nemá data v cache, návrat k původnímu programu, který už také nemá data v cache (použití toho enginu manipuluje přímo s pamětí; to, co bylo v cache CPU, už není pravda), celkově to dost snadno bude pomalejší, než prostě ta data přesunout.
Quando omni flunkus moritati
11.11.2010 22:59 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Prostě by to chtělo architekturu, kde není třeba autonomní paměťové přesuny složitě nastavovat, kde tato jednotka pracuje přes MMU a nejlépe je přímo v instrukční sadě CPU.
11.11.2010 23:04 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
A k čemu to pak bude dobré? Když to bude v instrukční sadě CPU, tak po vykonání té instrukce se program zastaví a bude čekat, než kopírování doběhne (málokdy budeš mít k dispozici luxus nastavit a spustit to kopírování dlouho předtím, než budeš potřebovat, aby bylo hotové) Ergo: přidal jsi do procesoru spoustu tranzistorů, logiky navíc a nezrychlil jsi nic.
Quando omni flunkus moritati
11.11.2010 23:09 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Aha zapomněl jsem, sorry. ..jako neblokující instrukce.
12.11.2010 00:29 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Což to jo, s tím počítám, že bysme chtěli, aby ta instrukce byla neblokující. Jenže vem třeba tenhle kus kódu:
a = cekej_na_nejaka_data_a_vrat_na_ne_ukazatel();
b = dej_mi_ukazatel_na_cilovy_blok();
c = rekni_mi_kolik_bytu_mam_kopirovat();
memcpy(b, a, c); // implementováno neblokující instrukcí, která používá DMA
udelej_neco_s_daty_v_bloku(b);
...
Zpracování té instrukce implementující memcpy bude chvíli trvat, jenže my v následujícím příkazu už potřebujeme, aby byla hotová. To znamená, že i když instrukce sama neblokuje, bude potřeba použít jinou, která zablokuje běh programu do doby, než se kopírování dokončí. Z kódu je přitom vidět, že memcpy dřív zavolat nemůžeme, protože nemáme všechna potřebná data.

A takhle bude s velkou pravděpodobností vypadat hodně případů použití memcpy(), tím pádem se moc času neušetří a tranzistory investované do dané instrukce by bylo pravděpodobně lepší využít na něco jiného.
Quando omni flunkus moritati
12.11.2010 00:37 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tak by mohl být kód za DMA instrukcí zastaven a spuštěn až po dokončení DMA, mezitím by byl CPU prakticky volnej pro jiný vlákno. Takhle nějak je snad dokonce řešenej třeba DMA zápis na parport v jádru. Časem by se vývojáři naučili využívat toho času co maj navíc (jako se naučili využívat víc jader, superskalaritu, FPU a jiné).
12.11.2010 00:46 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
mezitím by byl CPU prakticky volnej pro jiný vlákno.
Psal jsem jinde. Podle mě by to nefungovalo dobře kvůli přepínání kontextů - přepnutí kontextu nějakou dobu trvá a není to málo. U vlákna to možná není takový problém jako u procesu, ale i tak.

Nové vlákno by ti vytěsnilo z cache data původního vlákna, přičemž by samo čekalo na data z paměti (jestliže kopírujeme tak velký objem dat, že se nám vyplatí přepnutí na jiné vlákno/proces, je to druhé vlákno/proces pravděpodobně cache-cold). Po přepnutí zpátky by na načtení dat muselo čekat původní vlákno. Do toho si předej, že to jiné vlákno předtím možná běželo na jiném CPU a musí se tedy počkat, až původní CPU vypíše data za svých cachí do paměti, aby je bylo možné načíst na nové CPU

Tohle všechno by IMO v součtu zabralo mnohem víc času, než prostě udělat staré dobré kopírování kousek po kousku.

Quando omni flunkus moritati
12.11.2010 00:55 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ale taky nemuselo, stejně jako nás může během REP MOVS přepnout task manager. Tady by ale na rozdíl od REP MOVS běželo kopírování + druhej program.
12.11.2010 09:59 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Čímž se ovšem dostáváme na zajímavou otázku: měl by jeden program mít právo spustit nějaké podobné kopírování, když tím vlastně zpomalí program, který je naplánován po něm? Podle mě teda ne.
Quando omni flunkus moritati
12.11.2010 19:29 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Souhlasím, zajímavý problém. Ale při sdílené sběrnici se tomu nevyhneme, koneckonců DMA funguje taky na sdílené sběrnici (většinou teda :-D). Jinak já uvažuju těch kopírovacích jednotek víc (i DMA má víc kanálů).
13.11.2010 00:20 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ale při sdílené sběrnici se tomu nevyhneme, koneckonců DMA funguje taky na sdílené sběrnici
No nevim, podle mě je rozdíl mezi situací, kdy DMA vyvolá zařízení (mám smůlu, zrovna to padlo na mě a ne na Frantu) a kdy ho vyvolá Frantův proces (Franta mi užírá můj čas CPU)
Quando omni flunkus moritati
13.11.2010 02:43 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jakákoliv DMA má být z definice transparetní tedy neužírá žádný čas CPU. Frantův proces se po zavolání DMA zcela vzdá procesoru a nebo pokračuje nezávisejícími daty. Z hlediska task manageru nijak nesedí na procesoru. Samozřejmě je občas sběrnice zablokována DMA burstem, ale to bude i když Franta požádá o načtení souboru. Po sběrnicích CPU běhaj i horší věci než hypotetický DMA.
13.11.2010 02:47 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jakákoliv DMA má být z definice transparetní tedy neužírá žádný čas CPU
To je pravda. Jenže k čemu je mi dobrý čas CPU, když nemám instrukce/data, protože se musí dodat z paměti.
Quando omni flunkus moritati
13.11.2010 15:11 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To může říkat i superskalární jednotka nebo pipelajna na dvojici instrukcí:
MOV AX,[0x4242]
DIV BL
A přece se to dá ve větším kontextu optimalizovat pro co nejmíň "bublin".

I kdyby se proces po spuštění DMA zastavil, tak s DMA jako instrukcí bude task manager konat efektivněji, protože mu ubyde proces, na kterým má přepínat (a tedy i přepínací overhead).
Grunt avatar 12.11.2010 14:22 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Sorry, že jsem tak smělý, ale který že DMA řadič to bere jako parametr dvě adresy v paměti a neotravuje s takovýma kravinama jako kanál přerušení nebo cílové zařízení? Já bych to i klidně odzkoušel, ale na starém Celeru žádný takový nemám.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 19:35 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
xps_central_dma třeba :-D. Ale to je extrém. Jinak jestli chápu dobře kontext, tak jsme se tam bavili o hypotetické optimalizované DMA.
Grunt avatar 12.11.2010 20:14 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
No, ne. Chtěl jsem si vyzkoušet a pěkně vizualizovat v grafu od které hodnoty délky bufferu se vyplatí používat DMA místo memcpy (vždycky lepší varianta než se tady hádat s Ponkrácem o pojmech obecných a rybaření), jenomže jsem narazil na dva problémy: Neexistující user-space funkce nebo volání (nebo aspoň Luk o ničem nemluví a Google krom pár experimentů též mlčí), která by se pro test dala použít a zadruhé všechny funkce, které jsou dostupné v jádře vyžadují paměť a buffer nějakého zařízení. Žádný z nich nenabízí zdroj místo v paměti a cíl též místo v paměti (a nebo aspoň Luk o nich zase mlčí – ale IMHO to bude dáno konstrukcí I/O řadičů).
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 20:24 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tak na x86 nevím, na OMAPu je v jádře tohle. Paměť se pak může sebrat pomocí dma_pool_create/dma_pool_alloc, nebo alokace s flagem GFP_DMA. Ale v userspace fakt nic není, právě jsem psal, že by bylo dobrý to tak udělat.
Grunt avatar 12.11.2010 20:33 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
OMAP kolík?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 21:06 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Eh? :-D
Grunt avatar 12.11.2010 21:07 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
No na OMAP kolik je to?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 21:14 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Aha mě zarazilo to dlouhý "i" (už jsem si říkal kolík na co???) :-D. V OMAPu 3 to jede určitě, ale podle if konstrukcí v .c bude základní funkcionalita všude. Ten plat-omap adresář je společnej.
Grunt avatar 13.11.2010 00:29 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Ok, dík. Jak budu mít čas, tak na to mrknu.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
12.11.2010 17:48 Ondrej 'SanTiago' Zajicek
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
ak by mohl být kód za DMA instrukcí zastaven a spuštěn až po dokončení DMA, mezitím by byl CPU prakticky volnej pro jiný vlákno
Tohle vicemene resi hyperthreading. Pokud bude nejaky program kopirovat spoustu pameti, tak bude vecne blokovany pristupem do pameti a nevyuzivane ALU jednotky mezi tim pouzije jine 'hypervlakno' bezici na stejnem jadre.
Xgamer avatar 11.11.2010 08:17 Xgamer | skóre: 4
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Neskušali ste binárne delenie, teda aby som bol presnejší posunom bitov myslim v lavo?:D Kedysi som to robil a bolo to celkom efektivnejšie ...
Jardík avatar 11.11.2010 11:47 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Jenže to jde jen 2, 4, 8, 16, atd...
Věřím v jednoho Boha.
11.11.2010 17:07 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
jde to i pro slozitejsi konstanty... viz to, co dela prekladac. nicmene, rozhodnuti ktera optimalizace je lepsi, je bez nejakych experimentu nesnadne. vezmi si treba nasobeni konstantou... v nekterych pripadech muzes pouzit MUL, v jinych LEA a v jinych kombinaci SHL+ADD/LEA a ty rychlosti se muzou zasadnim zpusobem lisit. napr. na sparcu se mi ukazalo, ze pokud nasobis konstantou, ktera ma mene jak pet jednicek, tak je lepsi vypocet rozlozit na SHL+ADD, jinak je MUL rychlejsi (i presto, ze je to na SPARCu zoufale pomala operace). ja teda verim, ze autori prekladace si daly tu praci a udelali ty experimenty za me.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
11.11.2010 16:42 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
:-]] neni to tak davno, co jsem mel pripominky k tomu, ze misto nasobeni pouzivas bitove posuny... a ajhle... on ten prekladac neni az tak blby...

jinak pokud to neni vylozene neco drsneho, co vede na nejake sverazne SSEX operace, tak je prekladac v drtive vetsine efektivnejsi. obzvlast s -O3 se obcas divim, co vsechno dokaze zoptimalizovat.

pokud by te zajimaly nejake triky vztahujici se k nizkourovnovemu programovani, doporucuju knizku Hacker's Delight. je tam mimo jine i popsane jak deleni konstantou prevest na nasobeni, i.e., zrovna ta optimilizace, co dela prekladac.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
11.11.2010 22:35 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Btw kdysi jsem napsal md5 pro ATi grafárnu, zdroják bych vyhrabal... Umělo to na jednu iteraci výpočtu v jednom jádře spočítat 4 md5 hashe najednou, díky tomu, že ta grafárna se 4-rozměrnými vektory dělá (skoro) stejně rychlý operace jako s integery...
Ale nevim, jestli by to bylo použitelný ještě dneska...
Jardík avatar 12.11.2010 00:16 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Já jsem našel zdrojáky na md5 pomocí OpenCL a CUDA, ale vypadá to naprosto děsně a je to omezený právě na některé "vyvolené" grafiky. Nezkoušel jsem to, ale údajně to zvládá pár Mega-hashů za sekundu :-)
Věřím v jednoho Boha.
12.11.2010 00:30 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tohle co jsem odpoledne víceméně linkoval fakt nestačí?
Jardík avatar 12.11.2010 02:26 Jardík | skóre: 40 | blog: jarda_bloguje
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
To je taková jednoúčelová utilitka, ale já to potřebuju mít součástí mé aplikace.
Věřím v jednoho Boha.
12.11.2010 19:38 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Tak pokud ti nevadí si počkat na výsledek, tak OK. Já jen že na tom webu je 8 numerických cifer ještě free, což je vzhledem k tomu, že imho maj už hotovou tabulku velmi dobrý.
tsLnox avatar 13.11.2010 11:50 tsLnox | skóre: 31 | blog: Blog jednoho ukecaného Gentoolemana | Žďár nad Sázavou
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
Řetězec musí bít zarovnané vpravo
A sakra. Jdu se zarovnat vlevo, nerad bych dostal řetězcem :-D
13.11.2010 15:13 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
13.11.2010 15:48 oryctolagus | skóre: 29 | blog: Untitled
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
:-D :-D
4.7.2012 14:40 Tomas
Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
tento kod je asi tak 10x rychlejsi ako tvoj:
int lkp[10000];

void IntToStr8init()
{
	int a0,a1,a2,a3;
	for (a3=0;a3<10;++a3) for (a2=0;a2<10;++a2) for (a1=0;a1<10;++a1) for (a0=0;a0<10;++a0) lkp[a3*1000+a2*100+a1*10+a0]=((a3+'0'))+((a2+'0')<<8)+((a1+'0')<<16)+((a0+'0')<<24);
}

void IntToStr8j(int num, char* str)
{
	int p,q;
	p=num/10000;
	q=num%10000;
	*(int*)str=lkp[p];
	*(1+(int*)str)=lkp[q];
}

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.