Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: začátečník 04. 03. 2015, 21:32:17
-
Ahoj,
chtěl bych Vás poprosit o nasměrování. Mám skript v pythonu, který dělá analýzu dat. Data jsou uložena v txt souboru. Každý soubor má cca 40.000 řádků, souborů je cca 30.000. Analýza přes tento soubor dat trvá cca 1.5h. Dat mám velké množství a rád bych analýzu urychlil.
Skrip načítá soubor po souboru a čte řádek po řádku. Napadlo mě proces rozdělit na n paralelních běhů, kde by každý proces zpracovával pouze danou část souborů-dat (v rámci jednoho skriptu). Myslíte, že to urychlí zpracování dat. Jak byste to řešili Vy? Díky za tipy a nasměrování k paralelnímu zpracování.
Díky
-
Zistit,kde a preco je to pomale...
Treba "profiling"... Zistit, kde ti program travi najviac casu...
Zamysliet sa, ci nahodou netravi kopu casu blbostami..
Potom sa zamysliet nad zlozitostou algoritmov ( ci nemas kvadraticku, ci nebodaj expomencialnu zlozitost tam, kde by mohla byt nebodaj linearna. Cize napriklad, pouzivas vhodne datove struktury? Optimalizovane na tvoj typ pouzitia?)
A nakoniec, vzdy sa daju najpomalsie casti prepisat do C-ka, a moze ti to potom ist este rychlejsie...
Ale zasada pri optimalizacii: meraj!!!
-
Zdravím,
obecný postup analýzy je -> pre-procesing dat -> procesing dat -> post-procesing. Tak jak chápu popsaný problém a možné úzké místo je konverze hodnot z txt souborů na reálné číslo, což aktuálně máte nastaveno takto -> 30.000 souborů x cca 40.000 řádků, což je cca 12xE+8 volání funkce "str_to_float" (možná je ta funkce nazvána v Pythonu jinak) na konverzi textového čísla na skutečné float číslo. Pak čas 1.5h je 5400 sekund, což Vám dává performance cca 2.22E+5 zpracovaných řádků/sec. To mi na Python připadne slušné.
Pokud chcete zrychlovat tak:
1) zvažte jak paralelizovat celé workflow pre-procesing dat -> procesing dat -> post-procesing.
2) urychlete konverzi čísel z TXT formátu na reálné číslo.
3) zamyslete se, zda-li část Python skriptu neumí lépe jiný nástroj, např. R-Plot.
Více lze poradit, až když uvedete typický řádek z jednoho souboru.
Tož tak.
-
díky, vyzkouším
první co mě napadlo byla hrubá síla -> rozdělit úlohu na n dalších
-
typický řádek:
109045.09;-0.0251;0.0465;0.0211;76
-
Můžes být trochu konkrétnější ohledně toho co děláš a nad jakými daty? Ukázat pár řádků (je to číslo, text či co?), nebo alespoň popsat strukturu a popřípadě i nějak zpřístupnit ten pomalý skript? Obecně se dá těžko poradit něco konkrétního, takže podívat se na použité datové struktury a algoritmus.
-
typický řádek:
109045.09;-0.0251;0.0465;0.0211;76
A co má být výstupem?
-
Myslíte, že to urychlí zpracování dat. Jak byste to řešili Vy? Díky za tipy a nasměrování k paralelnímu zpracování.
Jak říkali kolegové, především si musíš změřit, kde vlastně trávíš nejvíc času. Pokud to chceš dělat na jednom stroji a nejvíc času trávíš čekáním na disk, tak ti logicky paralelizace nepomůže že jo :)
Takže jako první krok určitě změřit, kolik trvá načítání a kolik to vlastní zpracování (vůbec nepíšeš, jaký výpočet nad těmi daty probíhá).
Pokud bude zádrhel ve výpočtu, tak v první fázi rozhodně použít numpy, pandas a podobné balíky specializované na hromadné výpočty (pokud už je nepoužíváš), ve druhém kroku pak případně přepsání nějakých kritických částí do C.
Každopádně dej vědět, jak pokračuješ, zpracování dat je hodně zajímavá a žhavá parketa, určitě si o tom víc lidí rádo něco přečte.
-
provádím postprocessing nad daty ze simulace
struktura řádku:
sledovana_hodnota;X;Y;Z;id - float;float;float;float;int
109045.09;-0.0251;0.0465;0.0211;76
Výstupy z analýzy:
a) nalezení definovaných bodů X,Y,Z - uložení sledované hodnoty do matice; matice = [int;hodnota]
- v každém souboru jsou nalezeny body dle definice a hodnoty uloženy do matice
b) četnost výskytu sledované hodnoty v definovaném intervalu rozsahu hodnot, 8 rozsahu hodnot, 5 časových intervalů, tj. názvu souborů
část skriptu:
# Definice sledovanych bodu
POINT_1 = ( 69, -0.0293, 0.0404, 0.0089)
POINT_2 = ( 69, -0.0288, 0.0400, 0.0092)
POINT_3 = ( 69, -0.0284, 0.0395, 0.0097)
POINT_4 = ( 69, -0.0286, 0.0401, 0.0084)
POINT_MATRIX = [ [POINT_1], [POINT_2] ], \
[ [POINT_3], [POINT_4] ]
# cast pro generaci nazvu souboru preskocena
# ----- cteni souboru
infile = open(filename,"r")
print it,': ',filename
for line in infile:
pressure = float(line.split(";")[0]) + const
x = float(line.split(";")[1])
y = float(line.split(";")[2])
z = float(line.split(";")[3])
pidID = int(line.split(";")[4])
for xx in range(xPM): #pocet bodu v Y (je definovana matice sledovanych bodu - Y = 4)
for yy in range(yPM): #pocet bodu v X v Y (je definovana matice sledovanych bodu - X = 0)
if (pidID == POINT_MATRIX[xx][yy][0][0]):
if (x == POINT_MATRIX[xx][yy][0][1] and y == POINT_MATRIX[xx][yy][0][2] and z == POINT_MATRIX[xx][yy][0][3]):
RES_POINT_MATRIX[xx,yy,it] = pressure
infile.close()
.. způsob zpracování dat jak čtu Vaše připomínky primitivní .. rád to však zkusím lépe
-
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.
-
for line in infile:
pressure = float(line.split(";")[0]) + const
x = float(line.split(";")[1])
y = float(line.split(";")[2])
z = float(line.split(";")[3])
pidID = int(line.split(";")[4])
...
co například začít už tím, že jeden a týž řádek nebudeš porcovat pětkrát?
-
co například začít už tím, že jeden a týž řádek nebudeš porcovat pětkrát?
Třeba spolíhal na to, že má Python líný vyhodnocování :)
-
Koukni sem:
http://docs.scipy.org/doc/numpy/reference/generated/numpy.loadtxt.html
načti tím soubor najednou a pak s ním nějak rozumně - tj. pokud možno ne tak, aby pro každý řádek matice běželi dva cykly (přinejmenším si např. udělej slovník pro pid - x,y,z, ať Ti stačí zkontrolovat jen
jednu věc a ne xPM * yPM).
-
Jak uz nekdo rikal, 1
1) profiling - python -m cProfile --sort cumtime tvujScript.py
2) ta paralelizace si o to jasne rika - zkus google "parallel python " :)
3) alternativni (ryhlejsi) interpretery pythonu - pypy, cython ... muze to udelat docela dost muziky za malo penez
-
3) alternativni (ryhlejsi) interpretery pythonu - pypy, cython ... muze to udelat docela dost muziky za malo penez
Naprosto zbytecny. Ty zminovany matematicky baliky maji samozrejme potrebne casti udelane v C/C++.
-
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.
-
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 :)
-
zkousel jsi Hadoop? :D :D
-
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? :D :D
Výzva v podobě Big data problému, data science, conversion scientist :D
Když sleduješ videocasty ze strata conferencí, tak tam to prezentujou stylem: "vy to ještě nemáte?"
-
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.
-
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 (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.
-
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
-
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
-
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ě
-
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).
-
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
-
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.
-
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.
-
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.
-
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.
-
Paralelní neni a nebude, pravda.
Není to tak úplně pravda. Python může volat C funkce, které mohou být paralelizované, viz numpy. Okolnosti mě donutily přepsat nejpomalejší část mého kodu do C, tu jsem paralelizoval pomoci omp. Doba řešení se zkrátila z hodin na minuty. Řešení je to jednoduché a spolehlivé, pokud je možné úlohu zadat pomocí několika ctypes.
-
Jak moc uživalelsky pohodlná je paralelizace v R? Byly by to body, o který by R porazilo Pandas.
Vyzkoušení paralelizace mám na TODO listu, takže nepovím :) Nástroje na to jsou, ale jak pohodlné to ještě nevím.
Jo počkat, myslíš paralelizaci přes víc strojů nebo v rámci jednoho? Jestli myslíš v rámci jednoho, tak to je v pohodě - Rko je docela funkcionálně orientovaný, takže klasika parallel map atd. Samozřejmě balíčků je na to X (jako ostatně v Rku na všechno ;) ). Ale v tom žádnej rozdíl oproti Pythonu nebude, tam to jde určitě taky (vyzkoušený nemám).
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.
Jémine, tyhle jazyky přece nejsou určený k tomu, abys v tom psal informační systém (i když i http server v Rku existuje ;) ). Jsou to jazyky primárně na interaktivní práci s datama. Prostě vezmu dataset, dotlačím ho do správnýho formátu a vrazím do nějaké knihovny. Je to prostě lepidlo na knihovny, nic víc od toho nelze očekávat. Rozhodující pro tuhle práci je množství a kvalita knihoven a v tom je Rko dost slušný bych řekl.
Python je sice bezva, že to je univerzální jazyk, jenže jako lepidlo právě (imho) zas tak dobře nefunguje. Protože ho prostě ohýbáš na něco, na co nebyl určenej. A speciální nevýhoda je, že nemá rozumný makrojazyk. Takže předat parametr tak, aby se nevyhodnotil v době volání, je opruz. Viz krkolomná syntaxe selectu (narozdíl od Rka, kde samozřejmě selectem design jazyka začali - a téměř u něj skončili :)) ).
-
Paralelní neni a nebude, pravda.
Není to tak úplně pravda. Python může volat C funkce, které mohou být paralelizované, viz numpy. Okolnosti mě donutily přepsat nejpomalejší část mého kodu do C, tu jsem paralelizoval pomoci omp. Doba řešení se zkrátila z hodin na minuty. Řešení je to jednoduché a spolehlivé, pokud je možné úlohu zadat pomocí několika ctypes.
Python je úplně normálně paralelní jako ostatní jazyky. Nevím, proč něco přepisovat. Hlavně většina věcí stejně už v C je, proto je Python je tak rychlý.
-
Python je úplně normálně paralelní jako ostatní jazyky. Nevím, proč něco přepisovat.
Myslíš úplně stejně jako všechny ostatní OOP jazyky? :))
A vůbec ze všeho nejparalelnější je GIL :))
-
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.
Jémine, tyhle jazyky přece nejsou určený k tomu, abys v tom psal informační systém (i když i http server v Rku existuje ;) ). Jsou to jazyky primárně na interaktivní práci s datama. Prostě vezmu dataset, dotlačím ho do správnýho formátu a vrazím do nějaké knihovny. Je to prostě lepidlo na knihovny, nic víc od toho nelze očekávat. Rozhodující pro tuhle práci je množství a kvalita knihoven a v tom je Rko dost slušný bych řekl.
V tom nejsme ve sporu. Jak je to trivilani filtrovani a takove to domaci interaktivni solichani dat, tak ma R svoje kouzlo (pokud clovek pretrpi to, ze co pes, to jina ves). Ale jak se po nem zacne chtit neco vic, tak je to dost tvrde pristani (prestoze tam teoreticky je spousta veci, prakticky uz jenom pitome unittestovani je bolest a utrpeni, o cemkoli serioznejsim nemluve).
Problem toho mnozstvi knihoven pak je dost nevyrovnana kvalita. Ostatne vetsinu z nich nepsali programatori, ale lide z jinych oboru, ktere jen nouze dounutila housti a Rko pouzivati.
-
Python je úplně normálně paralelní jako ostatní jazyky. Nevím, proč něco přepisovat.
Myslíš úplně stejně jako všechny ostatní OOP jazyky? :))
A vůbec ze všeho nejparalelnější je GIL :))
Jasně, pokud umíš programovat. Když bys chtěl Java styl, použiješ hotový framework.
-
Myslíš úplně stejně jako všechny ostatní OOP jazyky? :))
Jasně, pokud umíš programovat. Když bys chtěl Java styl, použiješ hotový framework.
Ja ti nevim, ale tam, kam se nas snazis poslat, jsme byli pred deseti lety a zadny med to neni. Ne, ze by to bylo nemozne, ale preci jenom dneska uz je metodologie nekde trochu jinde.
-
Nikam neposílám, jen Python umí všechno, co ostatní jazyky a ještě máš lepší flexibilitu. Nemusíš ji použít, ale počítá se s ní a funguje dobře. Je to jako Linux. Záleží na tobě, co si z toho postavíš.
-
V tom nejsme ve sporu. Jak je to trivilani filtrovani a takove to domaci interaktivni solichani dat, tak ma R svoje kouzlo (pokud clovek pretrpi to, ze co pes, to jina ves). Ale jak se po nem zacne chtit neco vic, tak je to dost tvrde pristani (prestoze tam teoreticky je spousta veci, prakticky uz jenom pitome unittestovani je bolest a utrpeni, o cemkoli serioznejsim nemluve).
Ale co, neco vic? To je proste jazyk pro interaktivni solichani dat, co bys po nem chtel? Uz to, ze pises o debuggeru a unit testech, dost ukazuje - takova prace, ktera vyzaduje unit testy, by se v R nejspis vubec delat nemela. Pro serverove davkove zpracovani jsou jine jazyky. Nemam nic proti tomu, kdyz takhle nekdo Rko pouzije, ale pak at si nestezuje, ze je Rko na prd...
Problem toho mnozstvi knihoven pak je dost nevyrovnana kvalita.
To je pravda. Ostatně jako u jakékoliv jiné obrovské kolekce knihoven zdarma :)
-
Nikam neposílám, jen Python umí všechno, co ostatní jazyky a ještě máš lepší flexibilitu. Nemusíš ji použít, ale počítá se s ní a funguje dobře. Je to jako Linux. Záleží na tobě, co si z toho postavíš.
No prave (nic proti Pythonu, na dost veci ho mam rad).
Nekdy je lepsi jazyk, ktery te vic drzi zkratka. Silne typy, immutable typy, zajistena pure evaulace... (Opet zduraznuju - NEKDY)
-
Nikam neposílám, jen Python umí všechno, co ostatní jazyky a ještě máš lepší flexibilitu. Nemusíš ji použít, ale počítá se s ní a funguje dobře. Je to jako Linux. Záleží na tobě, co si z toho postavíš.
Ehm. To bys n8m asi musel ozřejmit, jaké "ostatní jazyky" máš namysli.
Jenom namátkou, co python nemá: ze zásadních věcí: makra (a tímpádem ani rozumnou podporu DSL), pattern matching, paralelnost. Ze specialit: třeba snadno implementovatelnou obecnou lazy evaluaci (ne, to fakt není xrange) nebo jánevím třeba podporu pro http://en.wikipedia.org/wiki/Definite_clause_grammar
Python je určitě prima jazyk, rád ho používám. Ale jestli si myslíš, že má "všechno", tak to jsi toho v programování asi moc nezkusil ;)
-
jen Python umí všechno, co ostatní jazyky
Poprosil bych jeden kernel-driver 8)
-
Poprosil bych jeden kernel-driver 8)
Nestraš prosímtě, nebo to fakt někdo udělá. Viz http://micropython.org/ ;)
-
většina věcí stejně už v C je, proto je Python je tak rychlý
Tedy poté co jsi přepsal kód z Pythonu do C, tak je Python rychlý. Vskutku brilantní úvaha ;D
-
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.
Zajímá mě to spíš z pohledu statistika než programátora (kompilátory nechám informatikům, mě zajímají víc aplikační domény). Tzn. aby to efektivně na procesorový čas i lidské zdroje vyřešilo datovou / statistickou úlohu. Jak psal Mirek, nejde o IS. Btw dost jsou slyšet názory, že ani Python se moc nehodí na větší projekty. Takže se klikátka nakonec napíšou v Javě/C#, či masochisti v C++.
Paralelní neni a nebude, pravda.
Není to tak úplně pravda. Python může volat C funkce, které mohou být paralelizované, viz numpy. Okolnosti mě donutily přepsat nejpomalejší část mého kodu do C, tu jsem paralelizoval pomoci omp. Doba řešení se zkrátila z hodin na minuty. Řešení je to jednoduché a spolehlivé, pokud je možné úlohu zadat pomocí několika ctypes.
Začátečnickej dotaz - to potom běží víc interpreterů, nebo se paralelizuje na úrovni dynamický knihovny?
Jo počkat, myslíš paralelizaci přes víc strojů nebo v rámci jednoho? Jestli myslíš v rámci jednoho, tak to je v pohodě - Rko je docela funkcionálně orientovaný, takže klasika parallel map atd.
V tomhle dobrý, asi bych to měl vyzkoušet. Právě ty PARALELNÍ data v Pythonu, mi přišlo že se člověk musí věnovat víc implementaci paralelního modelu, než samotnýmu významu dat. Prostě si to v OpenMP, či pomocí socketů napsat sám.
Ohledně distribuované verze, tam jenom vim že by to prej asi mělo jít, ale teď se věnuju něčemu jinýmu.
-
většina věcí stejně už v C je, proto je Python je tak rychlý
Tedy poté co jsi přepsal kód z Pythonu do C, tak je Python rychlý. Vskutku brilantní úvaha ;D
Neni tajemství že je Python lepidlo C knihoven. Takže výsledná kombinace by měla bejt přijatelně rychlá, napsaná v přijatelným čase a oproti C přehlednější.
-
V tomhle dobrý, asi bych to měl vyzkoušet. Právě ty PARALELNÍ data v Pythonu, mi přišlo že se člověk musí věnovat víc implementaci paralelního modelu, než samotnýmu významu dat. Prostě si to v OpenMP, či pomocí socketů napsat sám.
Ono s tou paralelizací je to těžký - nemám moc rád v tomhle ohledu obecný tvrzení, protože víc zamlžují než odhalují. Primárně je paralelizace o tom, jak vypadá ten proces, že jo. Pokud máš operace, který na sebe z principu musí čekat, tak s tím nic nenaparalelizuješ. A naopak pokud máš triviální SIMD operace, tak to nějak půjde paralelizovat prakticky v jakýmkoli jazyce... A někde mezi tím je programátorská kultura - když máš brutálně propojenou haldu objektů, tak seš v pytli každopádně. Pokud máš oddělený datový struktury, je zas šance větší... Prostě no silver bullet, většinou je to stejně nakonec o kvalitě analytika ;)
Ohledně distribuované verze, tam jenom vim že by to prej asi mělo jít, ale teď se věnuju něčemu jinýmu.
Jo, vím že existuje třeba http://www.ebi.ac.uk/Tools/rcloud/ a různý jiný balíčky, ale vyzkoušený to právě nemám a ani to zatím není úplná priorita...
Neni tajemství že je Python lepidlo C knihoven. Takže výsledná kombinace by měla bejt přijatelně rychlá, napsaná v přijatelným čase a oproti C přehlednější.
Jenže to právě nic neříká o kvalitě jazyka. To bys taky mohl mít jazyk, ve kterým by se OS Windows implementoval takhle:
new Windows();
...a zbytek by byl v C++ ;)
-
Není to tak úplně pravda. Python může volat C funkce, které mohou být paralelizované, viz numpy. Okolnosti mě donutily přepsat nejpomalejší část mého kodu do C, tu jsem paralelizoval pomoci omp. Doba řešení se zkrátila z hodin na minuty. Řešení je to jednoduché a spolehlivé, pokud je možné úlohu zadat pomocí několika ctypes.
Začátečnickej dotaz - to potom běží víc interpreterů, nebo se paralelizuje na úrovni dynamický knihovny?
Je to paralelizované na úrovni knihovny. Například zkuste použít OpenBLAS misto ATLAS a pak řešit soustavu rovnic pomocí scipy.sparse.linalg.gmres . Řešení bude probíhat na více CPU (pokud máte OpenBLAS zkompilovaný jako multithread)
-
Nie je na matice a take veci najlepsi octave? Kedysi som v tom daco robil a vykon bol pre mna dostatocny. Ale treba to vsetko dostat do tych matic. Ked tam zacnes cpat cykly, tak to bude este pomalsie.. (konkretne som nacitaval nejake zvukove subory a robil fft)
-
Neni tajemství že je Python lepidlo C knihoven. Takže výsledná kombinace by měla bejt přijatelně rychlá, napsaná v přijatelným čase a oproti C přehlednější.
Dneska mě to tady baví ;D
--- Kód v C se použitím v Pythonu stává přehlednějším.
--- Přepsáním kódu z Pythonu do C se Python stane rychlým.
-
gc.disable()
rngy = range(yPM)
rngx = range(xPM)
for line in infile:
lst = line.split(";")
pressure = float(lst[0]) + const
x = float(lst[1])
y = float(lst[2])
z = float(lst[3])
pidID = int(lst[4])
for xx in rngx: # pocet bodu v Y (je definovana matice sledovanych bodu - Y = 4)
for yy in rngy: # pocet bodu v X v Y (je definovana matice sledovanych bodu - X = 0)
tmp = POINT_MATRIX[xx][yy][0]
if pidID == tmp[0]:
if (x == tmp[1] and y == tmp[2] and z == tmp[3]):
RES_POINT_MATRIX[xx, yy, it] = pressure
infile.close()
gc.enable()
ak by to bolo stale pomale, tak pouzit pypy.
pripadne pustit paralerne tolko skriptov kolko je cpu.
-
Nie je na matice a take veci najlepsi octave? Kedysi som v tom daco robil a vykon bol pre mna dostatocny. Ale treba to vsetko dostat do tych matic. Ked tam zacnes cpat cykly, tak to bude este pomalsie.. (konkretne som nacitaval nejake zvukove subory a robil fft)
Není, to co uvádíte lze řesit přes numpy, scipy které většinou využívá stejných knihoven jako octave. Výkon je tedy skoro stejný.
Někdy nejde úloha vektorizovat, cyklům se potom nelze vyhnout. Pokud to lze "dostat do tych matic", pak to výjde na stejno.
-
Neni tajemství že je Python lepidlo C knihoven. Takže výsledná kombinace by měla bejt přijatelně rychlá, napsaná v přijatelným čase a oproti C přehlednější.
Dneska mě to tady baví ;D
--- Kód v C se použitím v Pythonu stává přehlednějším.
--- Přepsáním kódu z Pythonu do C se Python stane rychlým.
Taková je praxe. Zkuste se podívat na scipy. Většina je obal okolo Fortranovských a Cčkovýh knihoven LAPACK, ARPACK, FITPACK apod.
U numerických výpočtu je skutečně nesmysl reprezentovat každé číslo pomocí ukazatele na PyObject, když jde o každou tisícinu vteřiny.
Výsledná kombinace nabízí rychlost Cčkového kodu a pohodlné uživatelské rozhraní přes pythonovské objekty, při použití dobrého interaktivního interpreteru (např. ipython) je s tím radost pracovat.
-
Čtvrt roku píšeš 50 000 řádků v C, pomalu se v tom začínáš ztrácet, ale 50 řádků v Pythonu na zapouzdřující objekt to zázračně zpřehlední a rozradostní ;D Není ten Python ze SSSR ? ;-)
-
Čtvrt roku píšeš 50 000 řádků v C, pomalu se v tom začínáš ztrácet, ale 50 řádků v Pythonu na zapouzdřující objekt to zázračně zpřehlední a rozradostní ;D Není ten Python ze SSSR ? ;-)
Vtip je v tom, že těch 50K řádků nepíšeš ty, ale specialisti na implementaci fest rychlých algoritmů. Ty řešíš, jak pomocí těch algoritmů vypočítat něco aplikačně specifickýho.
-
No nevim co tu maji nekteri za problem s paralelismem v pythonu, ale odpoved na puvodni otazku je celkem snadna
pokud potrebujes x souboru/dat zpracovat tou samou funkci paralelne tak pouzi multiprocessing pool proste se ti vytvori tolik procesu kolik zadas nebo pokud nic nezadas tak si to veme podle poctu jader a sup uz to leti.
-
No nevim co tu maji nekteri za problem s paralelismem v pythonu
S paralelismem v Pythonu nikdo problém nemá, protože v Pythonu žádný paralelismus není ;)
One of the most frequently asked questions from beginning Python programmers when they explore multithreaded code for optimisation of CPU-bound code is "Why does my program run slower when I use multiple threads?".
http://www.quantstart.com/articles/Parallelising-Python-with-Threading-and-Multiprocessing
In CPython, the global interpreter lock, or GIL, is a mutex that prevents multiple native threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)
https://wiki.python.org/moin/GlobalInterpreterLock
pokud potrebujes x souboru/dat zpracovat tou samou funkci paralelne tak pouzi multiprocessing pool proste se ti vytvori tolik procesu kolik zadas nebo pokud nic nezadas tak si to veme podle poctu jader a sup uz to leti.
...což je skoro to samý, jako by si spustil tolik interpreterů, kolik má jader :)
-
baba :)
jen pro inspiraci, kdyz uz to mam pusteny ... je to jen scitani, takze rychlejsi - milion pod desetinu vteriny :
ipython qtconsole
In [1]: import pyopencl as cl
...: import numpy
...: import numpy.linalg as la
...: import time
...:
...: _tlast = 0
...:
...: def TimingInit():
...: global _tlast
...: _tlast=time.clock()
...:
...: def Timing():
...: global _tlast
...: t0=time.clock()
...: print t0-_tlast
...: _tlast=t0
...:
...: ### ----- main ---
...:
In [2]: TimingInit()
...: a = numpy.random.rand(1e6).astype(numpy.float32)
...: Timing()
...: b = numpy.random.rand(1e6).astype(numpy.float32)
...: Timing()
...: ctx = cl.create_some_context()
...: Timing()
...: queue = cl.CommandQueue(ctx)
...: mf = cl.mem_flags
...: a_buf = cl.Buffer(ctx, mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf=a)
...: b_buf = cl.Buffer(ctx, mf.READ_ONLY | mf.COPY_HOST_PTR, hostbuf=b)
...: dest_buf = cl.Buffer(ctx, mf.WRITE_ONLY, b.nbytes)
...: Timing()
...: prg = cl.Program(ctx, """
...: __kernel void sum(__global const float *a,
...: __global const float *b, __global float *c)
...: {
...: int gid = get_global_id(0);
...: c[gid] = a[gid] + b[gid];
...: }
...: """).build()
...: Timing()
...: prg.sum(queue, a.shape, None, a_buf, b_buf, dest_buf)
...: Timing()
...: a_plus_b = numpy.empty_like(a)
...: Timing()
...: cl.enqueue_copy(queue, a_plus_b, dest_buf)
...: Timing()
...: print(la.norm(a_plus_b - (a+b)), la.norm(a_plus_b), a_plus_b.size)
...:
0.012044
0.011675
0.061999
0.00342
0.003968
0.001592
8.8e-05
0.000712
(0.0, 1080.2306, 1000000)
-
...což je skoro to samý, jako by si spustil tolik interpreterů, kolik má jader :)
omlouvam se obcas zapomenu ze spravny programator misto toho aby nechal robit pocitac tak radeji sam rucne rozdeli data na podobne hromadky a nasledne nad daty pusti per hromadka script, pak to hezky cekuje kdy uz to dojede a nasledne sleje vysledky dohromady pokud mozno do excelu
-
Správný programátor použije technologii podporující SMP, jedna funkce běží klidně 16x paralelně nad tou stejnou hromadou dat.
http://en.wikipedia.org/wiki/Symmetric_multiprocessing
SMP se v konzumním IT vyskytuje od Pentia D asi tak 10 let, ale nepřekvapivě to zatím asi žádný skriptovací jazyk nepodporuje.
-
Tohle python samozřejme umi.
-
Tohle python samozřejme umi.
Umí vlákna s GIL a multiprocessing s omezeným sdílením dat, ani jedno nedosahuje potřebných kvalit.
-
Tohle python samozřejme umi.
Umí vlákna s GIL a multiprocessing s omezeným sdílením dat, ani jedno nedosahuje potřebných kvalit.
Tohle umi cpython
-
JA sa spytam trochu off topic.
K comu je dobry python? Kde mi moze nahradit C#, JAVU?
-
Tohle umi cpython
Potřetí to psát nebudu, přečtete si to sám https://wiki.python.org/moin/GlobalInterpreterLock.
Kde mi moze nahradit C#, JAVU?
C#, Javu nenahradí, ale s úspěchem nahradí bash.
-
JA sa spytam trochu off topic.
K comu je dobry python? Kde mi moze nahradit C#, JAVU?
K cemu je dobry tobe, to nevim.
Ja ho mam celkem rad na takove ty stredni veci. Kde je shell malo, ale zakladat plnotucny projekt jeste moc.
Uz se v tom da doopravdy programovat (testovaci frameworky, IDE), ma to primocare API pro dost veci (zadna tovarna na vyrobu tovaren, abych nacetl tri radky konfigurace), celkem rozumny REPL... ale na druhou stranu na vetsi veci mi Java kryje zadek dost dalsimi vecmi.
-
na rychle prototypy je python fakt super, tady http://forum.root.cz/index.php?topic=10810.msg123997#msg123997 (http://forum.root.cz/index.php?topic=10810.msg123997#msg123997) je volani opencl a soucet dvou matic s milionem prvku, vcetne generovani a kontroly hotovo za mene nez desetinu vteriny.
jak se to napise v jave nebo c# ? a jak dlouho to budete ladit ?
-
jak se to napise v jave nebo c# ? a jak dlouho to budete ladit ?
Součet jednoho milionu čísel se napíše v C# jako prostá smyčka a výkon je v tomto množství ještě natolik dostatečný že na otázku rychlosti jednoduše nedojde, ladit není co.
-
na rychle prototypy je python fakt super, tady http://forum.root.cz/index.php?topic=10810.msg123997#msg123997 (http://forum.root.cz/index.php?topic=10810.msg123997#msg123997) je volani opencl a soucet dvou matic s milionem prvku, vcetne generovani a kontroly hotovo za mene nez desetinu vteriny.
jak se to napise v jave nebo c# ? a jak dlouho to budete ladit ?
Může být v C++?
#include <boost/numeric/ublas/matrix.hpp>
int main()
{
boost::numeric::ublas::matrix<float> a(1000, 1000);
boost::numeric::ublas::matrix<float> b(1000, 1000);
std::generate(a.data().begin(), a.data().end(), rand);
std::generate(b.data().begin(), b.data().end(), rand);
a += b;
return 0;
}
g++ -O3 -DNDEBUG -DBOOST_UBLAS_NDEBUG main.
time ./a.out
real 0m0.031s
user 0m0.029s
sys 0m0.000s
31 ms, z toho 25 ms je generování náhodných čísel, vlastní sčítání je 6 ms. Ladit nevím, co bych na tom měl ladit?
-
na rychle prototypy je python fakt super, tady http://forum.root.cz/index.php?topic=10810.msg123997#msg123997 (http://forum.root.cz/index.php?topic=10810.msg123997#msg123997) je volani opencl a soucet dvou matic s milionem prvku, vcetne generovani a kontroly hotovo za mene nez desetinu vteriny.
jak se to napise v jave nebo c# ? a jak dlouho to budete ladit ?
tvaris sa ako keby si ty sam osobne odladil cele NumPy :-)
C#
using MathNet.Numerics;
using MathNet.Numerics.LinearAlgebra;
using System;
void Main()
{
var timer=new Stopwatch();
timer.Start();
var m1 = Matrix<double>.Build.Random(1000, 1000);
var m2 = Matrix<double>.Build.Random(1000, 1000);
Console.WriteLine(timer.ElapsedMilliseconds);
var z=m1+m2;
Console.WriteLine(timer.ElapsedMilliseconds);
}
generovanie matic: 60ms
sucet: 3ms
-
Tohle umi cpython
Potřetí to psát nebudu, přečtete si to sám https://wiki.python.org/moin/GlobalInterpreterLock.
Myslis "In CPython, the global interpreter lock, or GIL, is ..."?
-
Tohle python samozřejme umi.
Umí vlákna s GIL a multiprocessing s omezeným sdílením dat, ani jedno nedosahuje potřebných kvalit.
Aha a jak by ta kvalita měla být lepší, když to umí v podstatě to stejné co Java?
-
Ja bych pouzil multiprocessing modul a pool workeru. Je to velmi pohodlne. Proste si velmi jednoduse nastartujes procesu kolik chces, naladujes do fronty tasky (soubory) a on je vykona. Dokonce maji velmi jednoduche predavani vysledku (pripadne si predej nazev vystupniho soubor, ktery si nactes).
https://docs.python.org/2/library/multiprocessing.html
Odstranis tim problemy s GIL a muzes pouzivat cokoliv te napadne vcetne numpy apod.
-
proto je Python je tak rychlý
V ranku skriptovacích jazyků je Python jeden z nejpomalejších. To už i PHP je rychlejší. No a takový vysmívaný JavaScript ho co do rychlosti vyloženě drtí. Samozřejmě při použití čistě pro volání knihoven psaných v céčku bude "rychlý" libovolný jazyk, o tom žádná...
-
Tohle python samozřejme umi.
Umí vlákna s GIL a multiprocessing s omezeným sdílením dat, ani jedno nedosahuje potřebných kvalit.
Aha a jak by ta kvalita měla být lepší, když to umí v podstatě to stejné co Java?
V podstate umi i to, co cecko, haskel, nebo brainfuck.
Java ma vyrazne lepsi garbage collector, diky tomu nemusi mit GIL a vlakna jedou ve skutecnosti paralelne (u cpythonu ne, kdyz pouzijes jiny interpreter, treba jython, nebo ironpython, tak ty GIL nemaji)
-
Myslis "In CPython, the global interpreter lock, or GIL, is ..."?
Již to tady bylo 3x.
Aha a jak by ta kvalita měla být lepší, když to umí v podstatě to stejné co Java?
Java umí standardní multithreading, Python ne.
V podstate umi i to, co cecko
Poslúchajte, Kefalín, čo vy si predstavujete pod takým pojmom "cecko" ? :-)
u cpythonu ne, kdyz pouzijes jiny interpreter, treba jython, nebo ironpython, tak ty GIL nemaji
Tak máme tady nové resumé ;D
--- Kód v C se použitím v Pythonu stává přehlednějším.
--- Přepsáním kódu z Pythonu do C se Python stane rychlým.
--- Přepsáním interpretu Pythonu do Java nebo C# se Python stane lepším.
-
Myslis "In CPython, the global interpreter lock, or GIL, is ..."?
Již to tady bylo 3x.
Tak proc porad trvate na tom, ze i jine interprety maji GIL?
V podstate umi i to, co cecko
Poslúchajte, Kefalín, čo vy si predstavujete pod takým pojmom "cecko" ? :-)
Odpovidal jsem na tu blbost "když to umí v podstatě to stejné co Java?"
u cpythonu ne, kdyz pouzijes jiny interpreter, treba jython, nebo ironpython, tak ty GIL nemaji
Tak máme tady nové resumé ;D
--- Kód v C se použitím v Pythonu stává přehlednějším.
--- Přepsáním kódu z Pythonu do C se Python stane rychlým.
--- Přepsáním interpretu Pythonu do Java nebo C# se Python stane lepším.
To tvrdite vy. Ja tvrdim pouze jedine - pouzitim jineho interpretu, ktery nema GIL, se paralelni zpracovani zrychli
-
Ta úplně původní otázka, trvá cca 1,5 hod jeden soubor, nebo všech 40 000 souborů ? To první bych tolik neřešil, to druhé je docela problém a potřeba řešit. Je značně jatěžován disk nebo jedno vlákno procesoru ? V prvním případě paralelizace jenom zhorší (a oddělá disk ještě před koncem záruky).