Portál AbcLinuxu, 20. září 2019 07:18

Škálování procesorů při kompilaci jádra

28.10.2009 15:29 | Přečteno: 2467× | Linux | poslední úprava: 28.10.2009 15:31

Tento zápisek volně navazuje na víc jak dva roky starý (ten čas ale letí...) článek Škálování quadcore při kompilaci jádra. Nevím kdy přesně v jádře přibyla volba pro hotplugování procesorů, každopádně nyní tam je a to nám umožňuje snadno emulovat počítač s méně jádry a docílit tím přesnějšího srovnání. Z hlediska CPU se změnilo za ty dva roky poměrně málo- stále zde máme čtyřjádrové procesory, frekvence se nehla ani o píď a zlepšení v architektuře nejsou ani na straně intelu (Nahalem) ani AMD (novější Phenomy) ničím, kvůli čemu by musel člověk sbírat čelist z podlahy. Snad jen servery s 2x čtyřjádrovými procesory jsou nyní častějším jevem, na desktopu to je ale relativně vzácnost.

Hardware

2x X5482 (3.2 GHz), tyto procesory jsou více známy pod názvem Core 2 Extreme QX9775, protože pod tímto značením se prodávaly v Intel SkullTrail sestavách, 16 GiB DDR2 800 MHz FB DIMM

 

Software

Jádro 2.6.31.5, vanilkové. gcc  4.3.4

 

Metodika

Metodika se od  minula nijak nezměnila akorát jsem neměřil kompilaci jádra se všemi volbami, neboť časy byly příliš dlouhé a já potřeboval provést spoustu měření. Použil jsem tedy .config jádra, které běžně používám. Pro simulaci počítače s méně jádry jsem použil "hotplug"

echo 0 > /sys/devices/system/cpu/cpuN/online  //místo N se dosadí číslo jádra

kernel z něho odmigruje všechny procesy, zamorduje příslušné kernel thready a snad i přepne do nějakého úsporného režimu. Pro systém dané jádro přestane existovat, není ani v /proc/cpuinfo. Starší metodou je předání jádru parametru maxcpus při bootu a ještě starší omezení počtu procesorů v .config. Ne-SMP jádra, tedy s efektivnějšími implementacemi některých zámků, se už dneska v žádné distribuci nevyskytují ale ta volba v konfiguraci jádra stále je. Záměrně jsem tedy vynechal měření "jednojádra".

 

Výsledky

graf říká vše :-) Opticky se zdá, že osmijádro oproti čtyřjádru nedává výrazně lepší výsledky ale je to jen optický klam, osmijádo zvládne kompilaci 1.87x rychleji. Celkově vzato kompilace jádra škáluje velmi pěkně. Docela by mě zajímalo, jak by vypadala situace na i7 procesoru s aktivovaným hyperthreadingem.

Zajimavé poznatky přináší ješte hodnota user+sys, jinými sklovy kolik času procesory skutečně "odedřou". ta roste z 317 vteřin při -j1 lineárně k 350 při -j16. Jinými slovy o celých 33 vteřin práce procesoru příjdeme kvůli tomu, že se procesy točí ve spinlocku, počítají pomaleji kvuli tahanici o paměťovou sběrnici a L2 cache.

 

Závěr

Pokud od rána do večera neděláte nic jiného, než že kompilujete jádo, tak běžte pro osmijádrový počítač. Pozor, tento test říká právě to a nic jiného. Vyvozování jakýchkoliv dalších závěrů jen na vlastní nebezpečí.

       

Hodnocení: 92 %

        špatnédobré        

Obrázky

Škálování procesorů při kompilaci jádra, obrázek 1

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

Komentáře

Nástroje: Začni sledovat (0) ?Zašle upozornění na váš email při vložení nového komentáře. , Tisk

Vložit další komentář

vlastikroot avatar 28.10.2009 16:01 vlastikroot | skóre: 24 | blog: vlastikovo | Milevsko
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Odpovědět | Sbalit | Link | Blokovat | Admin
Lidi tady zkoušejí 8mi jádrové procesory a já nikdy neměl ani dvoujádro :-( Ale pěkné, je vidět, že pres make se dají věci pěkně paralelizovat.
Sg1-game | We will destroys the Christian's legion ... and the cross, will be inverted | IP 80.188.182.6
Nicky726 avatar 28.10.2009 16:28 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Nejsi sám.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
Grunt avatar 28.10.2009 16:30 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
No nádherně. Fakt. Člověk by přitom řekl, 8x 2Ghz = 8x 2Ghz a přitom může být rád aspoň za něco.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.10.2009 16:52 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Ve skutečnosti je šestinásobné zrychlení na osmi jádrech velice hezkým výsledkem... Proč tomu tak je viz jeden můj starší článek.

Komu se nechce nic číst, si může raději spočítat, jaká část výpočtu musí být paralelizovatelná aby došlo k takovému zrychlení. Nápověda1: Amdahlův zákon, Nápověda2: výsledek je 95 % :-)
Grunt avatar 28.10.2009 17:09 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
No tak to je ještě lepší. Takže vlastně narážíme na další limit. Zato čím víc jader o to dražší procesor, ale o to menší reálná rychlost zpracovávání a o tom větší marži necháváme obchodníkům. Doufám, že se honem něco vymyslí, protože vypadá to, že s frekvencí už se nikomu hýbat nechce, ten počet jader je takový…no. Zbyde už max. tak jenom optimalizace což je bohužel horší než s tou frekvencí a počtem jader.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.10.2009 18:42 CET
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
A nebo si koupit vic masin, jednu normalni s diskama, dalsi jenom nejaky minicase se sitovkou bez disku. Hlavne vsechny s levnyma CPU. Pak pres NFS udelat disky pro ty malinky bezdiskovy, nahodit distcc a jede se jako na SMP. Je to srovnatelny? Pripadne, aby to nebrzdil soucasny pristup na disk pres NFS z tech malych stanic, tak lokalne pouzivat ramdisk.
Grunt avatar 28.10.2009 18:49 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Já bych řekl, že u jednoho úkolu je vcelku jedno jestli na tom pracuje jedno jádro, jeden procesor nebo jeden počítač. Ten problém s paralelismem trvá furt dál.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.10.2009 17:49 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: Škálování procesorů při kompilaci jádra
amdahluv ,,zakon'' je sice priserna bestie... ale dikybohu neplati obecne. problem je nasledujici. amdahluv zakon se uvazuje ve forme, ze maximalni zrychleni v zavislosti na poctu procesoru je S(N) = 1/((1 - P) + (P / N)), kde P je cast algoritmu, ktera musi bezet sekvencne a N je pocet procesoru.

problem je, ze P nemusi byt konstanta. hodnota P je dana vstupnimi daty. coz je vicemene intuitivni, ma cenu paralelizovat velke ukoly nez male. a taky a to je hlavni, jsou pripady kdy P je funkci N... coz meni vyzneni celeho ,,zakona'', i.e., jde dosahnout linearniho i super-linearniho zrychleni! to znamena, ze v nekterych pripadech jde treba na dvoujadrovem procesoru dosahnou 10x zrychleni.

na druhou stranu, v pripade parallelniho programovani je potreba prehodnotit cely pristup k navrhu algoritmu a programu... protoze zkusenosti ze sekvencnich algoritmu jsou v pripade parallelnich algoritmu vicemene k nicemu.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
28.10.2009 18:43 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Proč ach proč se mi pokaždé, když píšu o škálování takové věci jako třeba kompilace, stává, že se někdo vytasí se superlineárními algoritmy? Je to tím, že naše vysoké školství produkuje praxií nepolíbené teoretiky-idealisty? Jinak si to neokážu vysvětlit :-) Ale tady asi ani to ne páč 10x zrychlení na dvoujádru to ned8 ani backpruning, to je něco naprosto z jine galaxie řekl bych :-)

28.10.2009 19:53 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: Škálování procesorů při kompilaci jádra
a proc kazdy, kdo si parallelne skompiluje kernel a precte par veci na wikipedii, si mysli, ze rozumi parallelnimu programovani?
vysoké školství produkuje praxií nepolíbené teoretiky-idealisty
:-]]
to je něco naprosto z jine galaxie řekl bych :-)
to je jasne... svuj notas jsem koupil od dvou ferengu pri ceste po gama-kvadrantu! puvodne jsem ho ani nechtel, ale nakonec jsem se nechal ukacat. :-]
Ale tady asi ani to ne páč 10x zrychlení na dvoujádru to ned8 ani backpruning,

takze taky teoretik? v praxi lze dosahnout superlinearniho zrychleni i s ,,beznyma parallelnima'' programama. staci si uvedomit, ze realny program nepouziva jenom CPU... a nadesignovat pak experiment, kde vyjde desetinasobne zrychleni na dvoujadru je uz jenom otazka cviku a trochy praxe. ;-]
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
28.10.2009 20:21 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Netvrdím nikde, že jsem odborník na paralelní programování, ale alespoň to nepíšu se dvěmi l :-) To není k smíchu s tím školstvím, já jsem také jeho produktem, vím o čem mluvím :-)

Tak mi nějaký takový experiment vycházejiící z praxe na reálném hardware a ne z akademického myšlenkového pokusu ukaž. Už jsem viděl i pokus o naprosto vyumělkované vytvoření algoritmu, který sázel na to, že se jeho working set vejde do L2 procesorů při rozdělení na víc části ale jako celek ne. Teoreticky vysněný případ. V praxi byl zisk jen nějakých 60 % páč se nepočítalo s n-asociativitou cache v reálných procesorech takže docházelo k přecpání některých řádků a na tom to celé zvadlo.
28.10.2009 22:38 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: Škálování procesorů při kompilaci jádra
To není k smíchu s tím školstvím, já jsem také jeho produktem, vím o čem mluvím :-)
ja jsem se smal necemu uplne jinemu... :-]]
Tak mi nějaký takový experiment vycházejiící z praxe na reálném hardware
vezmi si nejaky program a do jeho vlaken si pridej parkrat volani sleep(). uvidis, jaky to bude mit vliv na skalovani. ted si vem ten program a misto volani sleep si tam domysli, cekani na diskove I/O, cekani na sit, atd. bohuzel, z jistych duvodu nemuzu byt konkretnejsi...
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
28.10.2009 23:17 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Tak tim jsi to zabil naprosto. Čím víc bude aplikace čekat na I/O a méně počítat tím bude škálovat hůře protože bude stale více a více bržděná úzkým hrdlem I/O. Ale i kdybys magiky přidáním threadu namnožil i celý diskový subsystém tak stále víc jak dvojnásobek výkonu ze dvou threadů nevymáčkneš.

29.10.2009 00:34 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: Škálování procesorů při kompilaci jádra
Tak tim jsi to zabil naprosto.
to si jen myslis, nebo jsi to i zkousel? na I/O se musi cekat za vsech okolnosti v sekvencni i nesekvencni variante. jenomze v pripade nesekvencni varianty, zatimco jeden proces ceka na vyrizeni I/O, dalsi muze vyuzivat procesor. jeste bych mel dodat, ze aby to fungovalo (mimo amdahluv zakon) je potreba, aby pocet procesu byl vetsi nez procesoru.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
29.10.2009 02:20 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Pořád to v tom nevidím. Pokud je celek omezen I/O (většina procesů čeká na I/O a stává se často, že je procesor nevyužitý) tak přidání dalších procesorů a procesů nepřinese prakticjky žádný zisk protože úzké hrdlo zůstane stejné. Pokud naopak většina procesů čeká na procesor tak se logicky (téměř) nikdy nefláká a přidání procesoru a procesů sice pomůže výkonu ale zase maximálně na dvojnásobek protože zvětěíme úzké hrdlo na dvojnásobek.

Což takhle ukázka, do kostry pthreads aplikace napasovat nejskou simulaci výpočtu a IO a počítadlo iterací... půl hodinky. Nebo alespoň odkaz na něco, co takhle krásně škáluje.
29.10.2009 03:22 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: Škálování procesorů při kompilaci jádra
Pořád to v tom nevidím.
pointa je v tom, ze I/O se zacne chovat jako dalsi procesor. vezmi si jako trivialni pripad treba jednoprocesorovy stroj s dvema vlaknama, kdy se musi stridave cist a zpracovavat data... zatimco jedno vlakno cte data (nepotrebuje procesor), druhe pracuje... takze uloha skaluje i kdyz by vlastne nemela.
Což takhle ukázka, do kostry pthreads aplikace napasovat nejskou simulaci výpočtu a IO a počítadlo iterací... půl hodinky. Nebo alespoň odkaz na něco, co takhle krásně škáluje.
zkus si to naprogramovat sam, hint jsem dal vys. ja uz jsem touto diskuzi zabil vic casu nez je zdravo. a taky diskuzi o tom, ze ten a ten priklad neni optimalni nebo ze neodpovida realite jsem si uzil uz vic nez dost.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
default avatar 28.10.2009 19:26 default | skóre: 22 | Madrid
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
A mně celej den vyměňovali stoupačky. Voda teče z prdele, ale kafe si uvařim a umejt se umeju.
Grunt avatar 28.10.2009 16:33 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Odpovědět | Sbalit | Link | Blokovat | Admin
Přesné hodnoty někde dostupné jsou?
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.10.2009 16:43 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Tady.
Grunt avatar 28.10.2009 17:09 Grunt | skóre: 23 | blog: Expresivní zabručení | Lanžhot
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Děkuji.
Na co 64-bitů když to jde i s jedním? | 80.78.148.5 | Hack (for) free or Die Hard!
28.10.2009 16:51 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Propad dvoujádra při -j2
Odpovědět | Sbalit | Link | Blokovat | Admin
Čím si vysvětlujete, že při -j2 se dvoujádro propadlo? Je to tím, že I/O dělají jiná jádra, než na kterých jede výpočetní proces? Nebo to je tím, že dva procesy rotují přes více procesorů? (U čehož bych pochyboval o kladném vlivu na cache, nebyla to NUMA, že?)
28.10.2009 17:10 miho | skóre: 22 | blog: Mihovy_sochory | Orlová
Rozbalit Rozbalit vše Re: Propad dvoujádra při -j2
Stejně tak došlo k poklesu čtyřjádra při -j4 oproti osmijádru. Měřeno bez grafického prostředí, všechno jsem povypinal včetně věcí jako syslog-ng aby byl výsledek co nejméně ovlivněn, takže v tom problém není. Jediné vysvětlení, ktré mě napadá je, že dvoujádro má 6 MiB L2, čtyřkádro 12 MiB a "osmijádro" 24 MiB. Když se 4 procesy rozdělí rovnoměrne mezi procesory tak maji efektivně dvojnásobek L2 k dispozici. Ale jen hádám.
28.10.2009 20:11 cthulhu
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Odpovědět | Sbalit | Link | Blokovat | Admin
rychlosti RAM / disku behem poslednich let stagnovaly a CPU tak permanentne ceka na data. Proto se par chytrych hlav v Sunu dalo dohromady a vyvinuli pred peti lety CPU pod kodovym oznacenim Niagara (v soucasnosti 64 threadu per CPU tj. az 128 hw vlaken v 1U serveru). idealni na masivni multithreading (web servery, OLTP, LDAP, mail..) v kombinaci se Solarisem, ktery je s featurami a supportem stale pred jakymkoliv linuxem - bohuzel i cenou..No jeste maj x86 co dohanet.
28.10.2009 22:45 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: Škálování procesorů při kompilaci jádra
niagara jsou, co se tyce skalovani, hodne dobre procesory. mam k dispozici jednu niagaru T1 a skaluje fakt pekne, ale vykon jednotlivych ,,procesoru'' za x86 hodne kulha.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
29.10.2009 09:06 cthulhu
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
tento nedostatek castecne dohani inovovana T2ka, ktera ma 1 FPU per core (T1 mela 1 FPU na cely procesor) a frekvence je az 1.6Ghz a vyssi L2 cache. floating point operace jsou pak i 10x rychlejsi. Na aplikace typu data warehouse je porad lepsi "klasicky" SPARC64 s vyssi frekvenci; nicmene porad je zde moznost volby, ktery server vybrat pro konkretni aplikaci na stejne architekture. viz. napr. tento blog
29.10.2009 11:30 RoJ
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Vskutku castecne. Jinak je v single-thread vykonu porad horsi, nez stara UltraSPARC-III na 1.2GHz. Nicmene proste to je o druhu prace. Web + DB backend je proste to, na co je T-rada delana. Mraky kratkych dotazu. Takze CPU se stejne flaka protoze tu cte ze site, tu posila na sit, tu cte z disku, tu zapise, vykonu netreba, je treba neztracet cykly cekanim a nezdrzovat tak frontu.

Vetsi zlepseni v T2 je fakt, ze kazde jadro ma dve instrukcni pipeline, pro kazdou ctverici HW threadu jednu.

Ale porad, pokud mate load a/nebo context switche na starsich cpu nizke, tak T2 nevyuzijete. Na zakladni prehled, jestli vase aplikace je vhodna na T radu CPU maji SUNove "cooltst", skript pro pouziti na Solarisu a Linuxu, ktery vam sleduje zatez a podle par jednoduchych pravidel vyplivne odhad, jestli ma nebo nema smysl prechod na T procesory.

Jsou to dobre procesory, ale do serveru a na specifickou zatez. Web, sitove sluzby, myriady kratkych transakci. Kdo nevidel, neoceni.
29.10.2009 00:47 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Otázkou je, jestli to vůbec mají v úmyslu dohánět. Většina x86 procesorů je v počítačích, kde by se něco takového ani zdaleka nevyužilo. Připomíná mi to jeden článek, kde autor tvrdil, že hlavní problém architektury K10 spočívá v tom, že marketing neuhlídal inženýry a nechal je, aby sobě pro radost navrhli výborný serverový procesor, který se ale prodává jako desktopový…
29.10.2009 09:26 cthulhu
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
v casech konsolidaci, virtualizaci a naslednych uspor na misto a chlazeni v datacentrech jsou vypocetni naroky na 1U cim dal vyssi. Co se tyce x86 PC, tak vetsine uzivatelu by levne dvoujadro v kombinaci s rychlym SSD diskem udelalo daleko lepsi sluzbu nez mamuti quad core. Ale nyni je holt takova doba - vic jader, vic adidas.
vlk avatar 29.10.2009 01:17 vlk | skóre: 23 | blog: u_vlka
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Odpovědět | Sbalit | Link | Blokovat | Admin
na i7 je to velmi podobne, ale HT sa tam predsa len trocha podpisal... a to, ze ked kompilujem na -j 8 (aj viac) tak nikdy sa nevytazia vsetky jadra na maximum, stale je to asi na 90 - 95% zrejme je to koli zdielanej L1 a L2 cache, ktora je vzdy pre dvojicu HT jadier.

a co som skusal, v pripade core quad a -j 4, su vytazene vsetky jadra v priemere na 99%

You don't exist, Go away !
29.10.2009 12:26 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Odpovědět | Sbalit | Link | Blokovat | Admin
Zajímavé je, že časy se liší, ač ne o mnoho, už když j se blíží počtu cores, ale není větší.
Např. 4- a 8-jádro je výkonější než 2-jádro už při -j2 (přitom procesor je furt ten samej).
Stejně tak 8-jádro je výkonější než 4-jádro i pří j<8.

Vysvětluju si to tím, že na více jádrech méně překáží kernel, systémové procesy atd, prostě všecky ty ostaní procesy. Nebo je to něčim jiným?
29.10.2009 14:12 Kvakor
Rozbalit Rozbalit vše Re: Škálování procesorů při kompilaci jádra
Ne, myslím, že je to přesně tak, všechny asynchronní vlákna jádra, co zajišťují I/O (třeba pdflush), mohou běžet na volných procesorech, takže nejen že neubírají procesorový část uživateslkým procesům, ale ješte se ušetří režie přepínání úloh na procesoru (uložení a načtení všech registrů, prohozeni TSS+LDT a pod.).

Založit nové vláknoNahoru

ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.