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í
×

dnes 14:44 | Nová verze

Byla vydána nová verze 42.3 linuxové distribuce openSUSE Leap. Jedná se už o třetí vydání, které staví na SUSE Linux Enterprise (SLE). Výchozím jádrem je opět poslední LTS verze, tedy řada 4.4. Podrobnosti v oznámení o vydání a v poznámkách k vydání.

Ladislav Hagara | Komentářů: 12
dnes 14:30 | Nová verze

Google Chrome 60 byl prohlášen za stabilní. Nejnovější stabilní verze 60.0.3112.78 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 40 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 0
včera 22:33 | IT novinky

Společnosti Adobe, Apple, Facebook, Google, Microsoft a Mozilla společně oznámily konec Flashe. Podpora Flashe oficiálně skončí na konci roku 2020.

Ladislav Hagara | Komentářů: 13
včera 05:55 | Komunita

Před 10 lety, v červenci 2007, se začal prodávat svobodný chytrý telefon Neo 1973 (vnitřní označení GTA01). Za jeho vývojem stáli vývojáři projektu Openmoko (Wikipedie). O rok později bylo možné koupit jejich druhý telefon Neo FreeRunner (GTA02). V roce 2011 byl představena platforma GTA04. Tuto platformu využívá také projekt Neo900, jehož cílem je vývoj nástupce telefonu Nokia N900. Nahlédnutí do historie Openmoko a další informace v článku na Vanille.de [Hacker News].

Ladislav Hagara | Komentářů: 22
včera 04:44 | Komunita

Tým Debianu zabývající se reprodukovatelnými sestaveními (Reproducible Builds), tj. kdokoli může nezávisle ověřit, že daný binární .deb balíček vznikl překladem daných zdrojových kódů, oznámil, že 94 % balíčků Debianu lze přeložit a sestavit reprodukovatelně. V únory 2015 to bylo 83 % [reddit].

Ladislav Hagara | Komentářů: 4
24.7. 11:22 | Komunita

Mozilla.cz informuje, že na blogu Mozilly věnovaném bezpečnosti byly zveřejněny výsledky bezpečnostního auditu služby Firefox Accounts, v českých překladech účet Firefoxu, sloužící hlavně k přihlašování k synchronizaci Firefox Sync. Nalezeno bylo celkem 15 bezpečnostních chyb, z toho jedna byla označena jako kritická a tři jako vážné.

Ladislav Hagara | Komentářů: 0
24.7. 11:00 | Nová verze

Byla vydána první stabilní verze 1.0 svobodného komunikačního softwaru Ring (Wikipedie). Ring, původně SFLphone, je součástí projektu GNU [reddit].

Ladislav Hagara | Komentářů: 3
24.7. 06:00 | Zajímavý projekt

Warner Skoch na svých stránkách zveřejnil návod (YouTube) na zhotovení kapesní herní konzole MintyPi. Konzole MintyPi je postavena na Raspberry Pi Zero W a RetroPie. Jako obal slouží plechová krabička od mentolek.

Ladislav Hagara | Komentářů: 0
23.7. 02:00 | Nová verze

Byl vydán Debian 9.1, tj. první opravná verze Debianu 9 s kódovým názvem Stretch a Debian 8.9, tj. devátá opravná verze Debianu 8 s kódovým názvem Jessie. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 9 a Debianu 8 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 38
22.7. 15:50 | Zajímavý článek

Nadace The Document Foundation (TDF) zastřešující vývoj svobodného kancelářského balíku LibreOffice zveřejnila čtyřiačtyřicetistránkovou výroční zprávu za rok 2016. K dispozici je ve formátu pdf ve vysokém (21,68 MB) a nízkém (7,1 MB) rozlišení. Zpráva byla vytvořena ve Scribusu.

Ladislav Hagara | Komentářů: 0
Těžíte nějakou kryptoměnu?
 (4%)
 (2%)
 (19%)
 (75%)
Celkem 100 hlasů
 Komentářů: 6, poslední dnes 18:53
    Rozcestník

    GCC umí assembler lépe než já

    10.11.2010 23:31 | Přečteno: 2429× | 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: 67
    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.
    oryctolagus avatar 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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    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: 33 | 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...).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.

    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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...
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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...
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    11.11.2010 15:30 pc2005 | skóre: 33 | 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
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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.:)
    oryctolagus avatar 11.11.2010 15:26 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
    :-D
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    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: 33 | 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?
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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 :-(.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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ý :-/.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
    Co třeba vykreslování GUI?
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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í.

    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.

    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.

    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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.
    oryctolagus avatar 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.
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    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: 22 | 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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    12.11.2010 19:08 pc2005 | skóre: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
    Aha zapomněl jsem, sorry. ..jako neblokující instrukce.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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é).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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ů).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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).
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 12.11.2010 14:22 Grunt | skóre: 22 | 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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 12.11.2010 20:14 Grunt | skóre: 22 | 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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 12.11.2010 20:33 Grunt | skóre: 22 | 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: 33 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
    Eh? :-D
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 12.11.2010 21:07 Grunt | skóre: 22 | 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: 33 | 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.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    Grunt avatar 13.11.2010 00:29 Grunt | skóre: 22 | 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.
    oryctolagus avatar 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...
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    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: 33 | 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čí?
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | 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ý.
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    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: 33 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: GCC umí assembler lépe než já
    :-D
    Chuck Norris řekl babičce, že si dá jen 3 knedlíky. A dostal 3 knedlíky. | 帮帮我,我被锁在中国房
    oryctolagus avatar 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
    Shell v kostce: echo -e "\e[1;2r\e[?2l"  |  Java v kostce  |  Haskell v kostce  |  RESOLVED FIXED
    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.