Paralelizace a zrychlení v Pythonu

[Logik]

Prýmek: cython a numpy není alternativa, ale doplněk.

Numpy slouží k "dávkovém zpracování" velkého množství dat najednou. Ideálně se zakompilovanou dobrou
matematickou knihovnou, by byl paralelní.

Někdy je ale třeba data zpracovávat "element" po elementu, tak tam je numpy k ničemu. Cython tady naopak
udělá dobrou službu, včetně paralelizace alá openmp.

[Reklama]

[Mirek Prýmek]

Někdy je ale třeba data zpracovávat "element" po elementu, tak tam je numpy k ničemu. Cython tady naopak
udělá dobrou službu, včetně paralelizace alá openmp.

Ok, nehádám se. Numpy používám jenom na drobnosti, náročnější věci zkouším spíš v Rku. Myslel jsem spíš to, že pokud člověk dělá nějaké hodně profláknuté operace (což ta zmíněná hustota je), tak na to nejspíš pro numpy bude existovat způsob, jak to udělat efektivně a ne forloopovat v pythonu

Pokud dělá něco specifického, tak mu samozřejmě numpy nepomůže, pokud bude forloopovat, akorát přes dataframe

[tojsemja]

zkousel jsi Hadoop?

[txt]

Tak tohle rozhodně v žádném případě nedělej v čistém Pythonu. Podívej se na http://www.numpy.org/ http://pandas.pydata.org/ anebo rovnou http://www.scipy.org/

Ze začátku se asi budeš cítit jak Alenka v říši divů, ale to se poddá A s konkrétními dotazy určitě někdo rád pomůže.

Z vlastní zkušenosti mohu říct, že načítání csv souboru se po přechodu z čistýho Pythonu na knihovnu Pandas (nadstavba Numpy) zrychlila mnohonásobně, snad 10x a paměťová náročnost se snížila. Požadavek na čas programátorův se dramaticky snížil. Tyhle knihovny můžou bejt napsaný v C, nebo fortranu. A to se o nativní podpoře paralelizace knihovny Pandas (víc procesů v 1PC) zatím jenom diskutovalo (stav před cca rokem). Jo, podporovalo to nějakej file systém, kterej může jet paralelně (stejnej používá tušim Matlab).

zkousel jsi Hadoop?

Výzva v podobě Big data problému, data science, conversion scientist
Když sleduješ videocasty ze strata conferencí, tak tam to prezentujou stylem: "vy to ještě nemáte?"

[Kolemjdoucí]

Mám skript v pythonu, který dělá analýzu dat.
Analýza přes tento soubor dat trvá cca 1.5h.
Dat mám velké množství a rád bych analýzu urychlil.

Mám vozítko poslepované z dílů z vrakoviště a z kovošrotu.
Vozítko po naložení nákladu jezdí jako šnek.
Nákladu mám velké množství a rád bych vozítko zrychlil.

[Reklama]

[mmrnustik]

Prýmek: cython a numpy není alternativa, ale doplněk.

Numpy slouží k "dávkovém zpracování" velkého množství dat najednou. Ideálně se zakompilovanou dobrou
matematickou knihovnou, by byl paralelní.

Někdy je ale třeba data zpracovávat "element" po elementu, tak tam je numpy k ničemu. Cython tady naopak
udělá dobrou službu, včetně paralelizace alá openmp.

Pokud potrebuji zpracovat numpy matici nebo vektor v cyklu tak pouzivam https://github.com/iskandr/parakeet.

Pokud sledovana data cast dat tvori jen malou cast vstupnich souboru, tak by stalo za to nejdriv pomoci grepu vypsat jen sledovane radky.

[karel]

1. numpy na nasobeni, pomuze ti s nasobenim vektoru a matic
2. na nacitani csv existuje knihovna
3. nediv se ze to trva kdyz ho nutis delat dokola blbiny, ten opakovany split za to bych te hnal, ono neustale volani range take neni nic hezkeho a pro vetsi cisla je lepsi pouzit generator xrange

[droben]

ahoj,

co to zkusit nejakym ETL nastrojem?

pokud potrebujes vysekat jen par hodnot, sledovat cetnosti vyskytu, pripadne zagregovat par hodnot, tak by mohla dobre poslouzit community edition z cloveretl (http://www.cloveretl.com/download/community-edition). vytvorit jednoduchy graf, co ti nacte csv soubor a pak nad nim udela par vypoctu by nemelo byt nijak extra slozite. vzhledem k tomu, ze to beha na jave, tak by ti to melo jit spustit temer vsude

[začátečník]

1. numpy na nasobeni, pomuze ti s nasobenim vektoru a matic
2. na nacitani csv existuje knihovna
3. nediv se ze to trva kdyz ho nutis delat dokola blbiny, ten opakovany split za to bych te hnal, ono neustale volani range take neni nic hezkeho a pro vetsi cisla je lepsi pouzit generator xrange

díky, odstraněním zbytečností se čas běhu značně redukoval (ještě nikdy předtím jsem čas běhu neřešil .. teď na to budu myslet)
testovací vzorek 100 souborů, původně = 55s, nyní 17s

zkoušel jsem načítání pomocí numpy.loadtxt a numpy.genfromtxt ... jen tato operace zabrala 24s při 100 souborech

- ostatní odkazy projdu, díky za ně

[Honza1Ubuntu]

To také docela řeším, někdy zpracování trvá opravdu dlouho.

1. Nejpomalejším může být načítání dat s disku. Načte se te soubor jednou, nebo při každém řádku znova (120 M Request). Načítání z disku nebo dokonce z internetu může být nejpomalejší část. Lze načíst obsah celého souboru do proměnné, která je v RAM a načítat data odtud.
Někdy pomůže i změna způsobu ukládání původních dat (jiné třídění, víc nebo míň souborů).

2. Rozdělit data do více složek, pokud je nejpomalejší část CPU (a máš víc jader), pro každou složku spustit skript. Pokud je nejpomalejší čtení z disku, tak na více disků nebo strojů.

3. Python i Pascal jsou na výpočty docela pomalé, nejlepší je Fortran nebo C,  případě že program obsahuje hodně výpočtů. Ve Fortranu lze i spouštět např. bash skript v průběhu běhu (pro vykreslení grafu).

[jenda]

na experimenty skvely - dva ssd v raid 0
cteni 950 MB/sec
rychla grafika - 6kKc +

ipython qtconsole

import numpy
import matplotlib
import pyOpenCL


a nasobite 2 matice s milionem prvku za vterinu.
python paralelni neni a nebude
ke studiu sikovne ulohy na codility.com/lessons - jednoduche reseni s casovou slozitosti O(n**3) da kazdy ale na O(n) uz musite studovat, pdf tam jsou

[Honza1Ubuntu]

Paralelní neni a nebude, pravda. Jak a v čem paralelní úlohu napsat, to e mi nikdy nepodařilo. Proto jsem spíš dával tipy, jak zrychlit to jedno vlákno (nebo to paralelizovat na víc nezávislých úloh). Často největší doba bývá u disku a tam paralelizace nepomůže.

[JSH]

Pokud se ty soubory dají zpracovávat nezávisle na sobě, tak je nejjednodušší paralelizace pomocí makefile. Ale to funguje jenom pokud je start procesu relativně levný v porovnání se zpracováním jednoho souboru. Ještě kdyby tak makefily neměly tak pitomou syntaxi.

[txt]

Paralelní neni a nebude, pravda. Jak a v čem paralelní úlohu napsat, to e mi nikdy nepodařilo. Proto jsem spíš dával tipy, jak zrychlit to jedno vlákno (nebo to paralelizovat na víc nezávislých úloh). Často největší doba bývá u disku a tam paralelizace nepomůže.

Co ce nevejde do RAM jednoho stroje, to rozdělit do ram více strojů. Tím se dostáváme k výše zmíněnému kanonu na vrabce.

Někdy je ale třeba data zpracovávat "element" po elementu, tak tam je numpy k ničemu. Cython tady naopak
udělá dobrou službu, včetně paralelizace alá openmp.

Ok, nehádám se. Numpy používám jenom na drobnosti, náročnější věci zkouším spíš v Rku. Myslel jsem spíš to, že pokud člověk dělá nějaké hodně profláknuté operace (což ta zmíněná hustota je), tak na to nejspíš pro numpy bude existovat způsob, jak to udělat efektivně a ne forloopovat v pythonu

Pokud dělá něco specifického, tak mu samozřejmě numpy nepomůže, pokud bude forloopovat, akorát přes dataframe

Jak moc uživalelsky pohodlná je paralelizace v R? Byly by to body, o který by R porazilo Pandas.

[Ondra Satai Nekola]

Jak moc uživalelsky pohodlná je paralelizace v R? Byly by to body, o který by R porazilo Pandas.

Cokoli vetsiho v R je peklo. Je to prima nastroj na "otevru CSV, profiltruju na NA, namaluju obrazek, prozenu ANOVOU", ale na nejake programovani R nefunguje moc dobre. Zoufaly nedostatek pouzitelnych nastroju (uz jenom debugger je problem a nasi researcheri to obchazeji pomoci View v RStudiu), blbe navrhnuty jazyk (pro statistika dobre, ale na vetsi projekty nema dobre vlastnosti) a spousta ruznych necekanych pasti.