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 01:33 | IT novinky

    Microsoft se vyhnul pokutě od Evropské komise za zneužívání svého dominantního postavení na trhu v souvislosti s aplikací Teams. S komisí se dohodl na závazcích, které slíbil splnit. Unijní exekutivě se nelíbilo, že firma svazuje svůj nástroj pro chatování a videohovory Teams se sadou kancelářských programů Office. Microsoft nyní slíbil jasné oddělení aplikace od kancelářských nástrojů, jako jsou Word, Excel a Outlook. Na Microsoft si

    … více »
    Ladislav Hagara | Komentářů: 1
    včera 14:00 | Nová verze

    Samba (Wikipedie), svobodná implementace SMB a Active Directory, byla vydána ve verzi 4.23.0. Počínaje verzí Samba 4.23 jsou unixová rozšíření SMB3 ve výchozím nastavení povolena. Přidána byla podpora SMB3 přes QUIC. Nová utilita smb_prometheus_endpoint exportuje metriky ve formátu Prometheus.

    Ladislav Hagara | Komentářů: 0
    včera 12:00 | Zajímavý článek

    Správcovský tým repozitáře F-Droid pro Android sdílí doporučení, jak řešit žádosti o odstranění nelegálního obsahu. Základem je mít nastavené formální procesy, vyhrazenou e-mailovou adresu a být transparentní. Zdůrazňují také důležitost volby jurisdikce (F-Droid je v Nizozemsku).

    🇵🇸 | Komentářů: 12
    včera 05:33 | Bezpečnostní upozornění

    Byly publikovány informace o další zranitelnosti v procesorech. Nejnovější zranitelnost byla pojmenována VMScape (CVE-2025-40300, GitHub) a v upstream Linuxech je již opravena. Jedná se o variantu Spectre. KVM host může číst data z uživatelského prostoru hypervizoru, např. QEMU.

    Ladislav Hagara | Komentářů: 0
    11.9. 22:00 | Komunita

    V červenci loňského roku organizace Apache Software Foundation (ASF) oznámila, že se částečně přestane dopouštět kulturní apropriace a změní své logo. Dnes bylo nové logo představeno. "Indiánské pírko" bylo nahrazeno dubovým listem a text Apache Software Foundation zkratkou ASF. Slovo Apache se bude "zatím" dál používat. Oficiální název organizace zůstává Apache Software Foundation, stejně jako názvy projektů, například Apache HTTP Server.

    Ladislav Hagara | Komentářů: 11
    11.9. 17:33 | Nová verze

    Byla vydána (𝕏) srpnová aktualizace aneb nová verze 1.104 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.104 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.

    Ladislav Hagara | Komentářů: 0
    11.9. 15:33 | IT novinky

    Spotify spustilo přehrávání v bezztrátové kvalitě. V předplatném Spotify Premium.

    Ladislav Hagara | Komentářů: 0
    11.9. 15:00 | IT novinky

    Spoluzakladatel a předseda správní rady americké softwarové společnosti Oracle Larry Ellison vystřídal spoluzakladatele automobilky Tesla a dalších firem Elona Muska na postu nejbohatšího člověka světa. Hodnota Ellisonova majetku díky dnešnímu prudkému posílení ceny akcií Oraclu odpoledne vykazovala nárůst o více než 100 miliard dolarů a dosáhla 393 miliard USD (zhruba 8,2 bilionu Kč). Hodnota Muskova majetku činila zhruba 385 miliard dolarů.

    Ladislav Hagara | Komentářů: 5
    10.9. 21:22 | Nová verze

    Bylo vydáno Eclipse IDE 2025-09 aneb Eclipse 4.37. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.

    Ladislav Hagara | Komentářů: 0
    10.9. 18:22 | IT novinky

    T-Mobile od 15. září zpřístupňuje RCS (Rich Communication Services) zprávy i pro iPhone.

    Ladislav Hagara | Komentářů: 3
    Pro otevření více webových stránek ve webovém prohlížečí používám
     (83%)
     (7%)
     (2%)
     (2%)
     (4%)
     (2%)
    Celkem 167 hlasů
     Komentářů: 12, poslední 10.9. 13:00
    Rozcestník

    Grand Central Dispatch: jednoduchý test

    5.9.2009 22:20 | Přečteno: 1583× | poslední úprava: 5.9.2009 23:23

    Byl jsem požádán abych udělal jednoduchý test GCD, ze kerého by bylo poznat jak se to v reálu chová, jaký to má overhead a podobně.

    #include < stdio.h>
    #include < stdlib.h>
    #include < stdint.h>
    #include < inttypes.h>
    #include < math.h>
    #include < dispatch/dispatch.h>
    
    int main(void) {
    
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    
    int count = 100;
    
    #ifdef GCD
    
    dispatch_apply(count, queue, ^(size_t i) {
    
       printf("start %i\r\n",i);
       double suma =0;
    
    
       for(int y=1;y<=1000;y++)
          for(int x=1;x<100000;x++)
             suma += i*sin(y/x);
    
       printf("konec %i vysledek %e\r\n",i, suma);
    
    });
    
    #else
    double suma;
    
    
    for(size_t i=0;i< count;i++) {
       printf("start %i\r\n",i);
       suma =0;
    
       for(int y=1;y<=1000;y++)
          for(int x=1;x<100000;x++)
             suma += i*sin(y/x);
       printf("konec %i vysledek %e\r\n",i, suma);
    
    }
    
    #endif
    
      return 0;
    }

    Uznávám, že ten výpočet je nezajímavý, ale je to vyloženě jen za účelem jednoduchého testu. Pokud máte nějaký nápad co tam místo suma += i*sin(y/x); dát tak sem s tím :)

    Pokud to přeložíme s direktívou GCD tak se provede výpočet paralelně s využitím GCD jinak se provede výpočet sekvenčně.

    Výstup s GCD:
    start 0
    start 1
    start 2
    start 3
    start 4
    start 5
    start 6
    start 7
    konec 1 vysledek 2.638081e+05
    start 8
    konec 4 vysledek 1.052888e+04
    start 9
    ...
    
    jinými slovy namnoží to 8 threadů, což dává na osmijádru smysl. Výstup time s GCD:
    real	0m9.659s
    user	1m12.893s
    sys	0m0.102s
    Výstup time bez GCD:
    real	1m12.919s
    user	1m12.874s
    sys	0m0.033s

    Speedup je tedy 7.55 což je na osmijádru adekvátní výsledek pro zcela paralelizovatelnou úlohu, která se vejde do L1 cache.

    Nyní omezíme cyklus y z 1000 na 100 iterací a count zvedneme ze 100 na 1000, vyřadíme printf aby výsledek nebyl ovlivněn výstupem na konzoli a změníme deklaraci sumy na volatile aby nám ji mrcha-překladač neodpotimalizoval. Jinými slovy zkrátíme jednu úlohu desetinásobně ale vyrobíme jich desetkrát víc.

    Výstup time s GCD:
    real	0m9.324s
    user	1m10.831s
    sys	0m0.137s
    Výstup time bez GCD:
    real	1m10.870s
    user	1m10.806s
    sys	0m0.046s

    Speedup je 7.6 tedy lepší než v minulém případě. To se dá vysvětlit tak, že ke konci výpočtu se už nudí jelikož pro ně není připraven žádný výpočetní blok, po kratičký okamžik počítá dokonce jen jedno jádro. Když zmenšíme dobu výpočtu jednoho bloku tak tuto dobu relativně k době celého výpočtu zkrátíme. Je také vidět, že bloků, jejichž výpočet trvá 7ms se vůbec nemusíme bát, réžie zařazování do fronty a přiřazování k threadům se zjevně příliš neprojeví. Takto lze dál zmenšovat vnitřní cykly a zvětšovat count a zjistíme, že karta se obrací až u bloků s trváním pod 0.05ms. Z toho lze usoudit, že výkonnostní réžie GCD je velmi malá.

    Vraťme se ale k původnímu programu, vyrobme 4 instance každá bude vypisovat jiné písmeno a spustíme je současně. Jak bude vypadat výstup?

    C: start 0
    C: start 1
    C: start 2
    B: start 0
    D: start 0
    B: start 1
    D: start 1
    A: start 0
    B: start 2
    C: start 3
    C: start 4
    D: start 2
    C: start 5
    B: start 3
    C: start 6
    D: start 3
    B: start 4
    C: start 7
    D: start 4
    A: start 1
    B: start 5
    D: start 5
    D: start 6
    B: start 6
    A: start 2
    D: start 7
    B: start 7
    A: start 3
    A: start 4
    A: start 5
    A: start 6
    A: start 7
    D: konec 7 vysledek 1.842554e+04
    D: start 8
    ...
    

    Jinými slovy nedělá to to, co bylo slibováno- vytvoří to 32 threadů :-(

           

    Hodnocení: 89 %

            špatnédobré        

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

    Komentáře

    Vložit další komentář

    Marek Bernát avatar 6.9.2009 12:20 Marek Bernát | skóre: 17 | blog: Arcadia
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test
    Čo sú presne tie inštancie? A čo bolo sľubované, že to bude robiť? :-)
    physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
    6.9.2009 12:48 miho | skóre: 24 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test
    Marek Bernát avatar 6.9.2009 13:12 Marek Bernát | skóre: 17 | blog: Arcadia
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test
    No, nevidím tam priamo nič o inštanciách, ani žiadne sľuby, ale ak tomu správne rozumiem, inštancie sú rôzne procesy, o ktorých by GCD malo vedieť a vlákna by mali byť ešte nad tým? To je 8 GCD vlákien, ale priraďujú sa medzi tie 4 procesy (=inštancie?). Ak píšem kraviny, tak ma prosím oprav, ale fakt z toho nie som extra múdry, ani po tom minulom zápisku a diskusii :-)
    physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
    6.9.2009 13:25 miho | skóre: 24 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Aha pardon, ja si neuvědomil na co se vlastně ptáš. Ty čtyři instance, které jsem zmínil to jsou 4 současně spuštěné procesy lišící se jen písmenkem které na začátaku vypisují. Prostě

    time ./p1 & time ./p2  & time ./p3  & time ./p4

    (nechtělo se mi hrát s va_args :-) )

    Teorie je taková, že by měl GCD inteligentně zasáhnout a pro každý proces povolit jen 2 thready ale neudělá to a povolí pro každý 8 threadů- Kdyby ty procesy více komunikovaly s pamětí tak by si navzájem přepisovaly TLB a obsah cache. Tohle určitě není optimální řešení...

     

    Marek Bernát avatar 6.9.2009 13:52 Marek Bernát | skóre: 17 | blog: Arcadia
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Ok, takto som to aj pochopil, ale je-lepší-si-bejt-jistej-než-potom-litovat :-)

    physics.stackexchange.com -- Q&A stránky o fyzike v štýle StackOverflow.
    7.9.2009 03:56 dark
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Podle mě to je fér. Jak chcete ošetřit třeba to, že na začátku spuštění úlohy jsou využité sice všechny jádra jiným procesem, který se ale za chvilku uklidní. Takto se sice vytvoří hodně vláken, které může OS spustit každé po sobě, takže v nejhorším případě by to mělo trvat jen o trochu dýl, než v případě jedno vlákna (o čas potřebný na synchronizaci / spuštění úloh).

    Jediná možnost jak využít pouze dostupný potenciál je nějaká komunikace s OS (něco takového existuje zatím jen pro Windows 7).

    7.9.2009 08:42 miho | skóre: 24 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Přesně to Apple ve svých materiálech (nejen těch marketingových) slibuje - GCD má mít přehled o stavu front v celosystémovém měřítku a přidělovat prostředky na základě momentálního vytížení a znalosti všech front. Když spustím 8 instancí té aplikace tak se dostanu na load 64. Epic fail actually.

     

    7.9.2009 13:41 mb
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Jste si jist, ze to skutecne vytvorilo 32 threadu? Vidite to v process manageru nebo to jen odhadujete z toho, ze se Vam spustilo 32 uloh pred prvnim ukoncenim?

    Bude se to chovat stejne, kdyz globalni (konkurentni) frontu vymenite za vlastni serializovanou?

    7.9.2009 14:33 miho | skóre: 24 | blog: Mihovy_sochory | Orlová
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Jsem, Mac OS ochotne praskne kolik ma proces threadu navic při 4 procesech load spolehlivě vyleze až na 32 a při 8 procesech na 64.

    Když vyměním frontu za serializovanou tak se spustí jediný thread.

    7.9.2009 16:29 mb
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    OK. O to mi slo. Ze samotneho vystupu programu to totiz bez znalosti implementace globalni (konkurentni) fronty urcit nelze.

    Cili to znamena, ze GCD optimalizuje nikoliv pro system, nybrz pro proces. Otazkou ale je, zda je to spatne ci ne -- priklad:

    Procak se 4 jadry.

    V systemu bezi 8 procesu, ktere aktivne vyuzivaji asynchronni GCD.

    i) V pripade optimalizace pro system dle Vasi predstavy: GCD vytvori (az) 4 vlakna, na nichz se bude tech 8 procesu nejakym zpusobem stridat.

    ii) V pripade optimalizace pro proces: GCD vytvori az 4 vlakna pro kazdy proces (dle aktualniho vyuzivani async dispatche kazdym procesem), ktere jsou dedikovany pro dany proces. Celkove v systemu v jeden cas az 32 vlaken specialne pro GCD.

    ad i) Dovedu si predstavit, zvlaste tehdy, kdy exekuce jednoho tasku je casove netrivialni zalezitosti, ze nektere aplikace by naopak mohly ztratit na responsivite.

    ad ii) Muzou existovat pripady, kdy bude v jednu dobu v systemu pomerne znacne mnozstvi vlaken specialne jen pro GCD, ktere budou vsechny aktivni. Scheduler se z toho pak mozna zblazni a responsivita aplikaci pujde zrejme take ke dnu. Otazkou je, zda je pocet GCD vlaken pro proces dynamicky menitelny ci nikoliv, tj. zda maji vzdy staticky thread pool nebo jeho kapacitu v runtimu prizpusobuji.

     

    Pocitam, ze vysvetleni bude asi takove:

    1) Bud je to jiz finalni verze implementace GCD presne podle predstav Apple vyvojaru. A pak bych jim veril, ze maji jednotlive varianty zmerene skrz naskrz a vysledkem je ta nejlepsi.

    2) Nebo jde o prvni, neuplnou implementaci GCD, ktera jeste muze v dalsich (sub)releasech Mac OS X doznat zmen.

    7.9.2009 16:34 mb
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Ha, nasel jsem na applovskym mailing listu pomerne rozsahlou diskusi na prakticky stejne tema. Jeste jsem se ji neprokousal, takze zatim bez komentare jen odkaz:

    lists.apple.com/archives/PerfOptimization-dev/2009/Sep/msg00003.html

    7.9.2009 20:10 dark
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    Aha, pak je ale otázka, jestli je to vůbec možné. Podle mě není problém 8 vláken na proces, který něco počítá. Pokud má OS mnoho běžících procesů, tak ty vlákna zavolá sekvenčně, a výsledek bude trochu horší, než optimalizovaný pro jedno vlánko (ale asi né o moc horší).

    V knihovně Fog jsem dělal multivláknové vykreslování, celkem jsem s tím experimentoval (nastavoval jsem u vláken i affinity a tak), ale dospěl jsem k závěru, že je lepší to nechat na OS. Pokud je OS zatížený, tak si ty vlákna zavolá postupně a je z toho prakticky jednovláknové vykreslování. Pokud má volné prostředky, tak to pustí na všechny jádra a výsledný čas je lepší.

    Zjistil jsem, že pro náročnější úlohy (momentálně je to rasterizer) je největší problém memory management a L1/L2/L3 cache. Například u některých benchmarků na noťasu mi vychází, že při použití více vláken na jednodádru je vykreslení rychlejší, než při použití jen jednoho vlákna (hlavního). Vysvětlení je takové, že jednotlivé vlákna sice byly spuštěné postupně (sekvenčně), ale jejich práce se vešla do cache procesoru, takže výsledný čas byl třeba o 40% lepší (i přes minimální overhead způsobený synchronizací).

    Troufám si dokonce tvrdit, že všechny SW grafické knihovny (je to můj obor:) ), co jsem viděl, jsou navržené s ohledem na dnešní procesory špatně, a teď nemluvím jen o cairu nebo GDI+, ale zapadá sem přes veškeré optimalizace i Fog a mnoho dalších knihoven / rasterizerů, které vykreslují věci postupně (bez analýzy). Možná se i někdy dopracuju k ideálnímu řešení.

    7.9.2009 23:08 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: Grand Central Dispatch: jednoduchý test
    Zjistil jsem, že pro náročnější úlohy (momentálně je to rasterizer) je největší problém memory management a L1/L2/L3 cache.
    ve svem dusledku tady tyto veci nema moc cenu resit... protoze kazdy procesor si to resi po svem... je rozdil, jak se chova k pameti vicejadrovy notebookovy procesor typu core duo a jak se chova viceprocesorovy stroj s xeony... a to nemluvim o tom, ze uplne jinak se chovaji opterony. a to se pohybujeme jenom v ramci jedne architektury...
    Například u některých benchmarků na noťasu mi vychází, že při použití více vláken na jednodádru je vykreslení rychlejší, než při použití jen jednoho vlákna (hlavního).
    docela casto podobne situace nastavaji pokud je potreba delsi dobu cekat na nejake I/O.
    Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
    8.9.2009 05:56 dark
    Rozbalit Rozbalit vše Re: Grand Central Dispatch: jednoduchý test

    V mém případě se jedná o čistý benchmark bez IO atd. Ten memory management jsem zmínil proto, protože u některých úloh hodně záleží na velikosti cache (a v grafické knihovně je celkem silný předpoklad, že data se do cache nevejdou), takže i celkem triviální přepis může znamenat výkonnostní rozdíl v desítkách procent.

    Ještě bych upřesnil, že používám architekturu x86/x64. Ostatní architektury pro mě v současnosti nejsou zajímavé.

    Založit nové vláknoNahoru

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