offloading je drahý na podobné typy úloh, tj. hlavně filtrování. Musíš totiž ty data do gpu dostat a použiješ je jen jednou. GPU získává na síle pokud nad jedněma datama potřebuji provést spousty operací, ne pokud potřebuji rychle něco filtrovat v dočasných datech.
awk je v tomhle šílená věc, snad můj neoblíbínejší nástroj na linuxu, používám často na podobnou úlohu, odstranit carriage return z desítek GB velkých csv souborů, člověk by ani nevěřil jak často takovýhle soubory vypadnou z db.
Nikdy jsem nezkoumal podrobně co awk dělá interně, ale právě na zpracování řádků od konce je o řád lepší než jakýkoliv nástroj, který jsem kdy zkoušel, často jsem nebyl schopný ani vlastním C kódem mít lepší časy. Vítě někdo v čem to vězí?
Ne, protože pokud je to rozumně napsané (e.g. nespouštíš nový proces pro každý řádek), tak je to limitované rychlostí čtení dat, případně když jsou v RAM, tak klidně rychlostí čtení z RAM. Poslat to do GPU a zpět by bylo dražší.
A rychlost čtení dat u opravdu velkých datasetů řeší mapreduce.
paradigma, které MR začal má svoje následovníky, ale sám MR umírá. Největší slabina MR je, že na dokončení map se čeká a až poté může započít další fáze, během té doby se musí alokovat obrovské množství prostředků a ty se drží. Při zpracování desítek, stovek PB dat je to slabě použitelné a už jsme dávno přešli na jiná řešení. I v malém českém prostředí jsem za posledních několik let ani na jednom projektu MR nepooužil.
Map a fold tady byly před MR a také tady zůstanou, o nich jsem nemluvil.
Aha, tak o MR tu pisete iba vy. Autor prispevku, na ktory ste reagovali, napisal "mapreduce" a vobec neni jasne, aku technologiu myslel.
Vy pod MR asi myslite konkretne Hadoopovske technologie HDFS, YARN, MR1, MR2 a spol. To ste mohli napisat hned.
Ozaj ma niekto v cesku dataset v stovkach PB? Aj ste ho videli alebo len tak placate?
mapreduce je snad MR, ne? Zkracuje se takhle i v jiných projektech než jen v hadoopu. Mluvím i o původní c++ implementaci, nebo třeba té v couchdb či v riaku, celý algoritmus je založený na jednotlivých fázích (stage), kdy musím mít předchozí dokončenou než začnu další a to je obrovská slabina.
Proč bych pod MR myslel YARN nebo HDFS? To je trochu něco jiného myslím.
V ČR vím jen o projektech většinou ve stovkách TB, vyjímečně v jednotkách PB pro zpracování dat (se Seznamem již nejsem v kontaktu, ti třeba už mají také hodně). Víc jsem viděl pouze v zahraničí, jinde se nedají získávat zkušenosti, ČR je na to hodně malá.
'Proč bych pod MR myslel YARN nebo HDFS? To je trochu něco jiného myslím.'
No preto, ze ta javovska implementacia, ktoru ste na zaciatku oznacili za umierajucu, je umierajuca preto, ze YARN mozno nie je az taky dobry scheduler a preto, ze asi nie je az tamy dobry napad jednotlive stage ukladat na fs (HDFS) lebo ste zvisli na IO. To je presne to, co robi MR2 implementacia z Hadoopu. Alebo ste mysleli nejku inu javovsku implementaciu?
Nikde nie je predsa napisane, ze nemozete mat PB cisto v in-memory gride a robit si mapreduce bez toho, aby ste boli zavisli na ukladani medzivysledkov na fs.
Apropo poslednych 5 znaku z kazdeho radku sa zaobide aj bez redukcnej fazy, ci?
Ano, získat posledních 5 znaků z každého řádku je přesně use case pro MR a může na to stačit pouze map. V současnosti se ale nad velkými daty MR pro tyhle úlohy nepoužívá, v téhle exceluje, ale to není běžná úloha.
Jak jsem psal, MR je na ústupu, vidím to na projektech. Nejde o rychlost uložení mezivýsledků, jde o neschopnost pokračovat dokud nebyla předchozí fáze dokončena, Palo psal, že reduce může začít dřív než se dokončí map, to ale neplatí vždy, neplatí to dál než do další fáze a liší se to podle implemtace, v praxi to je nepříjemná brzda, desítky minut čekám než doběhne map fáze a CPU se zatím nudí a za chvilku znovu a znovu, shodné chování napříč různými implementacemi.
Nechci tady rozvíjet offtopic, pokud si o tom chceš více pohovořit, napiš SZ.
S tymto suhlas. Nemusi ist o absolutne najrychlejsie riesenie v zmysle efektivity vyuzitia procesoroveho casu, ale skript, ktory schrume 5GB dat za 5 minut a napisem a odladim ho za dalsich 30 (to sa bavime o trocha komplikovanejsich veciach nez toto) je na hony uzitocnejsi, ako program v C-cku, ktory tie iste data schrume za 30 sekund, ale budem ho pisat a ladit tyzden.
Ja v praci realne z casu na cas nejaky taky skript zosmolim (a to som riadny C++ programator, nie admin pri ktorom by to bolo ocakavanejsie). Vnutro je mozno tak trocha na zvracanie, ale plni to svoj ucel, je to dane dokopy v kratkom case a dovoli to ziskat data, ktore su inac prevazne v stadiu "prilis komplikovane na ziskanie" alebo dokonca az "nevieme ako tieto data ziskat". V oboch pripadoch su samozrejme data velmi chcene a pomaly az strategicky dolezite.
Kromě zmíněného problému, že jen přesun dat na GPU a zpět je časově náročný (to by neplatilo, kdyby to bylo součástí delšího zpracování, které by probíhalo celé na GPU), tu vidím problém, jak to vhodně paralelizovat na GPU. (Předpokládám, že nemáme žádné zjednodušení jako třeba konstantní délka řádku.):
1. Hledání konců řádků paralelizovat půjde, ale na GPU se budou těžko zapisovat výsledky. Dostanu různě dlouhé seznamy konců řádků.
2. Potom bude potřeba dát výsledky dohromady. To už těžko paralelizujete. A bez toho bude GPU krutě pomalá. (Ještě by se to dalo celé odeslat CPU a nechat to na něm, ale to má samozřejmě nároky na přenos dat atd.)
3. Kód bude nejspíš plný větvení, což GPU nemá ráda. Když se různá vlákna vydají různými směry (jakože se to bude asi dít celkem často), Musejí vlákna, která nejdou touto cestou, čekat na ostatní (a naopak).
Namisto bashismu a externich commandu si myslim, ze by to slo v Posixu.
#!/bin/sh
while read line; do printf "%s\n" "${line#${line%%?????}}"; done < file
Je to psano rychle, ale im hoby to melo fungovat. Porovnavat se mi rychlost nechce. A je mi jedno, kdo co pouzije za shell ;-)
f.
Dekuji za uznani ;-) Posix shell scripting proste vysel z mody a GNU coreutils taky nejsou na kazdem unixu, stejne tak bash. Printf je externi command, ale v mnoha shellech je kvuli rychlosti (dash, bash etc.) stejne jako echo vestavene.
Viz man dash :
In addition to these, there are several other commands that may be builtin for efficiency (e.g. printf(1), echo(1), test(1), etc).
a man bash : SHELL BUILTIN COMMANDS -> printf [-v var] format [arguments]
Posix shell se mi nechce startovat, ale podivam se zitra ... myslim, ze to bude stejne.
Kazdopadne dik, jdu sbirat dalsi negativni body :-D
f.
proc? protoze pouzivam jak awk, tak lua
Nezbylo nez to vyzkouset
samozrejme na jinem compu a jinem file, ale da se z toho udelat predstava:
jet@rmint /tmp $ time awk '{print substr($0,length($0)-4,5)}' big2 >/dev/null
real 1m7.536s
user 1m0.277s
sys 0m5.243s
jet@rmint /tmp $ time cat big2 | lua -e 'for line in io.lines() do print(line:sub(-5)) end' >/dev/null
real 3m4.567s
user 2m17.618s
sys 0m56.296s
takze z toho vyplyva, ze lua je radove 3 krat pomalejsi nez vitez awk, takze by s prehledem obsadila druhe misto. Echo, ktere bylo na druhem miste bylo 10 krat pomalejsi.
Zkousel jsem to s 3G filem na 1.8G Intel core 2 duo.
je to neuveritelne, ale je to presne naopak. roura o par milisekund vede
$ time cat /tmp/biglog | lua -e 'for line in io.lines() do print(line:sub(-5)) end' >/dev/null
real 0m2.423s
user 0m1.860s
sys 0m1.150s
$ time lua -e 'file=io.open("/tmp/biglog") for line in file:lines() do print(line:sub(-5)) end' >/dev/null
real 0m2.576s
user 0m1.921s
sys 0m0.647s
Muzu potvrdit, ze perl opravdu vede.
Testovaci soubor o velikosti 1.6GB jsem vyrobil zretezenim kernel logu.
Tady jsou vysledky pro lua, awk a perl:
time cat /tmp/biglog | lua -e 'for line in io.lines() do print(line:sub(-5)) end' >/dev/null
real 0m9.187s
user 0m4.696s
sys 0m1.960s
time awk '{print substr($0,length($0)-4,5)}' /tmp/biglog >/dev/null
real 0m5.259s
user 0m4.976s
sys 0m0.256s
time cat /tmp/biglog | perl -ne 'print substr($_,-6);' > /dev/null 2>&1
real 0m2.526s
user 0m2.252s
sys 0m0.868s
Jen pro zajímavost jsem zkusil vytvořit kurzor z tabulky v databázi ve kterém bylo textové pole názvu položky - náhodně, nesetříděno , celkem 8 209 501 řádků - ve FOXPRO trvalo zpracování příkazu
replace ALL polout WITH RIGHT(ALLTRIM(nazov),5)
celkem 4.79 sec.
Když jsou data v paměti tak to jde celkem rychle.