-
Mobilarena
Új hozzászólás Aktív témák
-
#8420
beleszólok
senior tag
emvy
#8419
beleszólok
senior tag
Nem a szoftver a lényeg, csak tanulgatok. Próbálom pótolni az elmúlt húsz évet
Igazából csak "ötletelgetek", hogy hogyan is lenne érdemes összerakni egy olyan szoftvert, aminek a feldolgozó és UI része bármikor cserélhető.
Az eredetileg tervezett funkcionalitást egy kb ötven soros python szkriptbe sikerült belezsúfolni.(Nem "annyira", hanem egyáltalán nem vagyok tapasztalt. Valaha programozó voltam, de azt a munkát manapság code monkey-nek nevezik, tervezéssel sosem volt dolgom.)
Zeromq-t nézegettem, de az már az ágyúval verébre kategóriának tűnt. Majd megnézem újra.
[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8418
beleszólok
senior tag
emvy
#8417
beleszólok
senior tag
Amíg közös nyelvet használok, addig talán működik is - bár az alap eleve multiprocessz felépítésű.
De olyan elképzelésem volt, hogy az adatgyűjtést első menetben pythonban írom, de GUI-t esetleg javaban vagy PHP-ben. Emiatt kellene valami, ami nem csak adott nyelven működik, mint a python threading.Queue.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8416
beleszólok
senior tag
emvy
#8415
beleszólok
senior tag
Mihez képest?
Processzor stackre úgy emlékszem, nem illik 100MB-okat pakolni, sűrű, tömött sorokban.
Igen, tudom, hogy nincs sok közük egymáshoz. Viszont valami halvány emlékem van a régmúltból, hogy az ipc csak apró üzenetek továbbítására való.És igen, egyelőre úgy tervezem, csak lokális processzeket szeretnék kiszolgálni.
Abból is csak egyet, nem akarok komplett szerver szoftvert gyártani.[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8414
beleszólok
senior tag
emvy
#8413
beleszólok
senior tag
OK, rosszul kérdeztem, kicsit szétszórt vagyok: az érdekelne valójában, hogy nagyobb adatmennyiség továbbítására illik-e használni (nagyobb alatt 10-100MB-okat értek) vagy ilyesmire nem szokták használni?
A másik, ehhez kapcsolódó dolog: mi van, ha egy platformfüggetlen alkalmazást akarok írni, aminek elvben ki kellene szolgálnia PHP, Java, Python stb. frontendeket is? Mit lehet erre használni, ami még nem ágyúval verébre kategória? (fel akarok dolgozni logfájlokat, de a megjelenítést szeretném teljes mértékben leválasztani a tényleges feldolgozásról)
A POSIX queue már eleve ott elvérzik, hogy egy alapkiépítésű windows-on (tudtommal) nincs ilyen - így a POSIX már csak érdekességképp jön szóba.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8412
beleszólok
senior tag
beleszólok
senior tag
Tudja valaki, hogy a POSIX message queue mire használatos?
Feltételezem, egyéb célja van, mint mondjuk a Websphere MQ-nak vagy a BEA MessageQ-nak.
(nem az érdekel, hogy egy message queue mire való, hanem konkrétan a POSIX-os megvalósítást mire szokás használni, milyen jellegű/méretű üzenetek közvetítésére használják)[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8403
beleszólok
senior tag
McSzaby
#8402
beleszólok
senior tag
válasz
McSzaby
#8402
üzenetére
http://stackoverflow.com/questions/8481345/perl-split-and-regular-expression
Esetleg ezt nézd meg, hátha segít.
Kicsit később talán tudok valami konkrétabb tippet is, de ahhoz elő kell szednem a perl ismereteimet, ami már bányászati módszereket igényel.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8392
beleszólok
senior tag
PumpkinSeed
#8391
beleszólok
senior tag
válasz
PumpkinSeed
#8391
üzenetére
Kerestem egy tutorialt, abból úgy tűnik, ez lehet a helyzet.
Név:=érték; ugyanaz, mint var Név=érték;Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8372
beleszólok
senior tag
Jester01
#8352
beleszólok
senior tag
válasz
Jester01
#8352
üzenetére
Most jutottam el odáig, hogy a java-t újra előszedjem. Abban ki tudtam próbálni, hogy UTF-8-asként vagy Latin1-ként kezelje az inputot (valójában Latin1 kódolású azt hiszem, vagy még inkább ASCII)
A java esetében nincs mérhető különbség az UTF8 és a Latin1 használata között. Vagy ha van, akkor is kb. a mérési hiba szintjén mozog.Most pythonból 5.5-5.9mp-et mérek a sorok megszámolásakor, java-ból ugyanez 6.1-6.5mp.
Erre már azt mondom, hogy nincs jelentősége. A C# sebességén viszont nem tudtam változtatni (más kérdés, hogy windows-on futtatva jóval gyorsabb, mint mono alatt )Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8370
beleszólok
senior tag
amargo
#8369
beleszólok
senior tag
Elvileg jó, de gyakorlatilag keress rá a "GIL python" kifejezésre (egyébként ugyanez igaz több más nyelvre is - GIL=Global Interpreter Lock)
Szerettem volna több szálon futtatni bizonyos dolgokat, aztán kiderült, hogy több processz még OK, több szál, ilyen feladványoknál nem. Erre javasolta valaki a C#-t, de mono alatt nem egy sebesség rekorder. És akkor arról nem beszéltem, hogy meg is kellene tanulni, legalább olyan szinten, ahogy most a pythont ismerem.[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8368
beleszólok
senior tag
amargo
#8367
beleszólok
senior tag
Nem, az másról szól.
Itt annyi volt a történet, hogy kerestem valami olyan eszközt, ami gyorsabb a pythonnál és megy benne a multithreading akkor is, ha cpu igényes szálakat futtatnék (lásd még GIL!) és fut linuxon is.
(Mindezt úgy, hogy a Python rugalmasságát, könnyű használatát megtartsam)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8366
beleszólok
senior tag
Jester01
#8365
beleszólok
senior tag
válasz
Jester01
#8365
üzenetére
Értelme? Amikor tanulgatok, kipróbálok ezt-azt, akkor bizony van, mert nem sok fájlból álló, óriási projekteken akarok dolgozni, hanem önállóan futtatható, pár soros kódokat futtatnék. (lásd https://github.com/haa-zee/python-sandbox/tree/master/probak)
Ilyenkor macerás minden futtatás előtt átállítani, még gázosabb minden egyes programot új projektbe tenni.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8364
beleszólok
senior tag
Jester01
#8363
-
#8362
beleszólok
senior tag
Alexios
#8361
beleszólok
senior tag
válasz
Alexios
#8361
üzenetére
OK, de épp az a gond, hogy nem tudok apróbb, önálló programokat gyártani benne úgy, ahogy pl. Eclipse-ben vagy bármely egyéb IDE-ben. Nem áll kézre a tanuláshoz.
Fejlesztéshez lehet, hogy jó, de számomra per pillanat... nem igazán.
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8360
beleszólok
senior tag
Jester01
#8359
beleszólok
senior tag
válasz
Jester01
#8359
üzenetére
Szerintem a for, de már nem vagyok biztos benne.
Monodevelop? Megszoktam, hogy egy projekten belül akárhány önálló programom lehet, ebben a nyomorultban meg, ha indítok egy "solution"-t, akkor abban csak egyetlen public static Main() lehet.
Kénytelen vagyok parancssorból bohóckodni.
Ha meg solution nélkül csinálom, akkor a rendszerkönyvtárakat sem találja valamiért.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8357
beleszólok
senior tag
sztanozs
#8356
beleszólok
senior tag
-
#8355
beleszólok
senior tag
Jester01
#8352
beleszólok
senior tag
válasz
Jester01
#8352
üzenetére
Kipróbáltam (monodevelop-t a pokolba kívánom úgy mellesleg
), valóban... a te verziód kb. 7mp, míg a python kb. 3, a saját C# változatom meg 19.
A tiédet nem tudtam több szálon futtatni, ennyire (gyakorlatilag egyáltalán ) nem értek a C# lelkéhez. A múltkorit valami tutorialból másoltam ki.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8351
beleszólok
senior tag
Jester01
#8350
beleszólok
senior tag
válasz
Jester01
#8350
üzenetére
Na jó, de egy i5-2520m procin, ne okozzon már ekkora eltérést az a konverzió!
Nem írtad, milyen rendszeren tesztelted: linuxon, python 2.7 vs mono, a python nagyságrenddel gyorsabb.
Windowson Activestate python vs .net, nagyjából hasonló, de a cygwines python mindkettőnél gyorsabb, nem is kicsivel.
Próbáltam megfejteni strace segítségével, hogy mit művel a python, de nem találtam érdemi magyarázatot az eltérésre.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8349
beleszólok
senior tag
beleszólok
#8348
beleszólok
senior tag
válasz
beleszólok
#8348
üzenetére
Közben kipróbáltam, hogy a linuxon fordított .exe-t átvittem windows-ra a loggal együtt. Ott már csak 8mp.
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8348
beleszólok
senior tag
Peter Kiss
#8347
beleszólok
senior tag
válasz
Peter Kiss
#8347
üzenetére
Java-val nekem is annyi. Pythonban meg három. (mindkettő csak olvasás. Pythonnál alig villan a hdd led, java futtatáskor folyamatosan világít)
A #8316-ban ott a forrás, azzal mennyi ideig fut?
Ja! Az ugye tiszta, hogy nálam nem windows-on fut, hanem linuxon, mono segítségével?[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8346
beleszólok
senior tag
Peter Kiss
#8345
beleszólok
senior tag
válasz
Peter Kiss
#8345
üzenetére
Python nem olvas unicode-ot (tudtommal), de ebben az esetben nincs is jelentősége, mivel egy alapjában véve ASCII, max. Latin1 kódkészletű logon kellett végigmászni.
Ha a C#/Java/stb. ráerőszakolja a unicode-ot és ettől lassú valamennyi, az számomra közömbös, nem fogom a többihez lassítani a pythont csak azért, hogy a tesztben esetleg azonos feltételekkel induljanak.Nem csak a .net verziót, hanem valamennyi kipróbált változatot sokszor futtattam, részben mert virtuális gépen fut, részben mert az op.rendszer cache, illetve a futtató rendszerek saját bufferelési módszerei is befolyásolhatják az eredményt. Az eltérés következetesen megmaradt.
Mérni, amikor pontosabban akartam, akkor a programon belülről, induláskor tároltam az időt, befejezéskor is és a kettőt egymásból kivonva számoltam ki, hogy mennyi ideig futott, jelentősebb eltéréseknél meg csak kívülről, a linux time parancsával.
Mielőtt még beleesnél abba a hibába, hogy "de az interpreter/vm indításának idejét is hozzámérem", jelezném, hogy nem egy-két másodperces eltérésekről van szó. A futtató környezet indítása nem több 1-2 mp-nél még a leglassúbb rendszer esetében sem, a fordítást meg max. a python esetében mérem bele, mivel az mindig forráskódból fut, a java, C#, haskell, erlang elvileg minimum bájtkódból indulnak, a haskell ráadásul futtatható binárist készít, elvben gépikódra fordítva... (és eddig az tűnt a leglassabbnak)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8343
beleszólok
senior tag
Sk8erPeter
#8341
beleszólok
senior tag
válasz
Sk8erPeter
#8341
üzenetére
Esetemben ez nem játszik. Egyetlen dokumentum van csak a repoban.
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8342
beleszólok
senior tag
Jim-Y
#8340
-
#8339
beleszólok
senior tag
beleszólok
#8338
beleszólok
senior tag
válasz
beleszólok
#8338
üzenetére
Nincs.
Nem én vagyok az oka, hogy nem találtam: volt lehetőség privát üzeneteket küldeni, de megszüntették.
E-mail meg csak az látszik, amit a user külön megad, amivel regisztrált, az nem jelenik meg sehol.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8338
beleszólok
senior tag
beleszólok
senior tag
Github... van rá valami lehetőség, hogy az ember kapcsolatba lépjen egy repo gazdájával anélkül, hogy hibát jelentene? (A pull request nem tudom mi, de gondolom, az sem erre való)
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8323
beleszólok
senior tag
martonx
#8321
beleszólok
senior tag
válasz
martonx
#8321
üzenetére
Végigpörgeti, különben nem tudnám pl. a sorok hosszának átlagát megszámolni.
(nekem is ez volt gyanús, ezért beleraktam egy átlagszámítást, hogy biztosan szüksége legyen a beolvasott adatokra)
Az a 3mp nem lehetetlen: a C-ben íródott wc (alias Word Count) ennél gyorsabb, kb. 1.5mp alatt olvassa végig második nekifutásra (ekkor már a fájl egy része cache-ben van)
A python nagy része mögött meg C-ben írt programok vannak.
Az egyetlen, de súlyos szépséghibája, hogy a cPython-ban van egy ú.n. GIL, ami miatt a többszálú működésnek csak akkor van értelme, ha a szálak I/O műveletet végeznek, mert ha mind CPU-t használ, akkor egymásra várnak állandóan. (és látszik is, hogy csak az egyik magon van terhelés)[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8322
beleszólok
senior tag
martonx
#8319
beleszólok
senior tag
válasz
martonx
#8319
üzenetére
Kipróbáltam: egy szálon ugyanaz, több szálon meg nem működőképes úgy, ahogy elképzeltem (a foreach helyett Parallel.Foreach ...), mert úgy fest, ilyenkor számolni sem tud, a doksiban talált példa alapján a a ForEach második paramétereként átadott lambda fv. úgy tűnik nem képes szálbiztosan kezelni a változókat.
Illetve ez csak feltételezés, az viszont biztos, hogy a fájl eredeti méreténél néggyel kevesebb sort számolt meg.
Az csak mellékes, hogy mindezt még lassabban is csinálta, mint az egy szálon futó változat.
(mindezt linux alatt, mono-val, virtualbox-ban, szóval nem állítom, hogy ez kizárólag a C# hibája)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8318
beleszólok
senior tag
Oppenheimer
#8317
beleszólok
senior tag
válasz
Oppenheimer
#8317
üzenetére
(értelmetlennek tartom ugyan, de kipróbáltam)
Semmi változás.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8316
beleszólok
senior tag
Sk8erPeter
#8315
beleszólok
senior tag
válasz
Sk8erPeter
#8315
üzenetére
Sokra nem mentek vele
namespace monosandbox
{
public class Hello
{
public static void Main(string[] argv){
int n = 0;
Console.WriteLine (System.IO.Directory.GetCurrentDirectory ());
using (StreamReader sr=File.OpenText("kern.log")) {
String s;
while ((s=sr.ReadLine()) != null) {
n++;
}
}
Console.WriteLine (n);
}
}
}Ennél primitívebb kódot nehéz lenne összehozni.
A StreamReader bufferelésével játszadoztam egy sort, de csak rontani tudtam rajta.
A fenti kód, így ahogy van, picit több, mint 22mp-ig fut - most lemértem.
Ugyanez a feladvány, csak pythonban 3.6mp.f=open("kern.log","r")
n=0
for i in f:
n+=1
print nValamit nagyon trükkösen csinál, mert ha a fenti kód helyett egy ilyet csinálok:
f=open("kern.log","r")
l=f.readlines()
print(len(l))akkor elvileg betölti memóriába az egész fájlt, gyakorlatilag iszonyat gyorsan végig tud menni rajta, még sincs bent minden, mivel a fájl közel akkora, mint a teszteléshez használt virtuális gép memóriája és az elég feltűnő, ha megtöltöm.
A readlines() helyett read()-t használva elég szembetűnő a különbség.
(1.6GB a fájl és 2GB-ja van a VM-nek)[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8314
beleszólok
senior tag
Karma
#8313
beleszólok
senior tag
Persze, ez nem is kérdés volt, csak amolyan blog-jellegű panasz
Anno méricskéltem és egészen vad dolgokat találtam.
Pl. hogy python + egy bizonyos regexp illesztése valamennyi sorra, jóval gyorsabb, mintha ugyanezt C-ben a perl RE könyvtárat használva csinálom.
Gyakorlatilag az adott kifejezéssel a python volt a leggyorsabb valamennyi kipróbált nyelv közül (python, java, C, ruby stb. A mono akkor kimaradt)
Aztán persze kiderült az is, hogy ha a regexp végéről lehagyom a ".*$" mintát, akkor máris nem ennyire egyértelmű a python (cPython) előnye, de összességében még nem találtam olyan eszközt, ami alkalmas lenne szövegfeldolgozásra és elég gyors is ahhoz, hogy több millió soros logokat gyorsan fel tudjak vele dolgozni.
Nemrég belebotlottam ilyenekbe, mint erlang, haskell, rövid ideig azt hittem, hogy ők hozzák az igazi megoldást, de utóbb kiderült, hogy a meglévő python kódom a feldolgozással együtt is gyorsabb, mint az említett, funkcionális nyelveken készített sorszámláló ("wc -l" klón)Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8312
beleszólok
senior tag
beleszólok
senior tag
Korai volt az örömöm.
Ugyanazt a file-t (cca 7millió sor), pythonból kb. 1.5mp alatt olvasom végig és számolom meg, miután egyszer valamivel végigolvastattam, monoból valamiért kb. 20-30mp ugyanennek a feladványnak a futásideje.
Fura... lehet, hogy a múltkor mellényúltam, amikor úgy tűnt, hozza a python sebességét a C#?Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8307
beleszólok
senior tag
martonx
#8306
beleszólok
senior tag
válasz
martonx
#8306
üzenetére
Nem, valamelyik menüben kifejezetten workspace szerepelt. Eredetileg úgy akartam használni, hogy nem volt "solution", mert a neve alapján arra gondoltam, hogy az valamiféle bugtracking eszköz lehet
Ezt látszott megerősíteni az a workspace szó valahol.De ettől függetlenül érthetetlen dolognak tartom a duplázott könyvtárnevet. Szóval ezt még emészteni kell.
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8304
beleszólok
senior tag
Karma
#8301
beleszólok
senior tag
Na ettől kezdve végképp nem értem a dolgot, mert ugyanakkor van benne workspace is.
Számomra elég fura az egész egyelőre.Az üresen maradó tab linuxos, talán ubuntus bug lehet, mert szöveges panaszt egyet vagy kettőt találtam, screenshotot meg csak egy unity-s példányt.
Említettek valami icairo2 bugot, hogy az okozhatja, de alaposabban nem néztem utána.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8299
beleszólok
senior tag
martonx
#8297
beleszólok
senior tag
válasz
martonx
#8297
üzenetére
Azért az érdekelne, hogy a monodevelop...
- miért duplázza a projekt nevet a könyvtárak létrehozásakor? (new solution -> kap egy nevet, mondjuk azt, hogy teszt, erre létrehoz a megadott könyvtár alatt egy teszt könyvtárat, abban meg még egy teszt könyvtárat.
- miért nem rakja ki a megnyitott tabokra a forrás fájl nevét, ahogy pl. az eclipse? Több fájlt megnyitok, kapok annyi "fület", de egyiken sincs rajta, hogy mi van benne megnyitva. Sok fájl esetében elég kényelmetlen.
És azt sem tudom eldönteni, hogy ez bug vagy szimplán ilyen.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8298
beleszólok
senior tag
martonx
#8297
beleszólok
senior tag
válasz
martonx
#8297
üzenetére
Egyébként olyan szempontból kellemes meglepetés volt, hogy a python mellett az egyik leggyorsabb rendszer a modern nyelvek közül. (C++-t kihagytam, arra nincs energiám, de a C# valahol félúton van a PHP és a Python logikája, szintaxisa közt, viszonylag könnyű egy alaptudást felszedni)
Szóval kíváncsi vagyok, az egyéb dolgokban, amikben eddig toronymagasan vezet a cPython, mit sikerül vele elérni. De ehhez minimum egy hét kell, hogy kiderüljön és az is lehet, hogy a végén hagyom a fenébe az egészet
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8296
beleszólok
senior tag
beleszólok
#8295
beleszólok
senior tag
válasz
beleszólok
#8295
üzenetére
Na, egy hiba kilőve: ha létrehozok neki "project"-et (a fene gondolta, hogy a "solution" jelenti azt, amit máshol a project), akkor már megtalálja a monodevelop is a regexp könyvtárat.
És így megvan az a References is, amit korábban nem találtam, mivel nem hoztam létre ezt a solution-nek nevezett dolgot.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8295
beleszólok
senior tag
martonx
#8293
beleszólok
senior tag
válasz
martonx
#8293
üzenetére
Hm. Hát végül rászántam magam, hogy kipróbáljam a mono-t, de a monodevelop... izé... hozza a "várt" formáját
Ctrl-F5 lenne a start without debugging, de tojik a fejemre.
Ha a System.Text.RegularExpressions-t használnám, azt mondja, hogy nem létezik. Állítólag van rá megoldás, valami jobb klikk a "References"-re és ott, épp csak fogalmam sincs, hol van a monodevelop-ban ez a References...
Szóval továbbra sem az esetem.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8294
beleszólok
senior tag
martonx
#8293
-
#8292
beleszólok
senior tag
sztanozs
#8291
beleszólok
senior tag
válasz
sztanozs
#8291
üzenetére
Sajnos egyébként sem, mint kiderült.
https://wiki.python.org/moin/GlobalInterpreterLock
Erről eddig nem tudtam. Gyakorlatilag a multithreading felejtős, ha pythont használok és nem valamelyik mutációt (jython, iron python etc.)
Ha I/O igényes a feladat, akkor tapasztalatom szerint jobb az I/O-t egy szálon intézni, mert a thread-safe eszközök lassúak. Ha cpu igényes, akkor sem nyerő a multithread, mert ott a GIL.
Hát ez van, szomorú vagyok.Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8290
beleszólok
senior tag
beleszólok
senior tag
Rég foglalkoztam ilyesmivel: ha egy hosszú text fájlt több szálon akarok feldolgozni, van rá valami bevált módszer, hogy ne lassítsak a párhuzamosított feldolgozással?
Pythonnal szórakozom, de mint "jó" módszert, azt találtam, hogy van egy reader szál, aki queue-ba pakolja a beolvasott sorokat, míg több feldolgozó, akik a queue-ból szedik kifelé a feldolgozandó adatokat.
Az a baj, hogy ez így, kb. egy-két nagyságrendet lassít a feldolgozáson.
Tehát egy sima végigolvasás a kevesebb, mint egy másodperc helyett 30-40mp-ig fut.Magát az olvasást sajnos nem lehet párhuzamosítani, mivel a pythonba beépített I/O funkciók nem szál-biztosak, ami meg erre lett kitalálva, annak a sebessége elfogadhatatlan. (kb. 10-15 percig futna a fenti feladat) Pedig ez lett volna az eredeti elképzelésem, mivel egy két magos gépen a CPU igényes műveleteket max. két szálra érdemes szétdobni, azon túl már számolgatni kell, meddig éri meg.
O.K., hogy van egy optimális szám, aminél több szálat elindítva csak lassítok a dolgon, az is tiszta, hogy a queue-val közvetített sorok eleve lassítanak, de hogy ennyire... ez egy kicsit túlzásnak tűnik.[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8284
beleszólok
senior tag
beleszólok
#8283
beleszólok
senior tag
válasz
beleszólok
#8283
üzenetére
Nem kéne ennyire keverni a nyelveket...
while($infile)-t írtam while(<$infile>) helyett...
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8283
beleszólok
senior tag
beleszólok
senior tag
No, erlang mellé egy kis perl
#!/usr/bin/env perl
use strict;
my $infile;
print $ARGV[0];
if($#ARGV==-1){
open($infile,"<-") or die "Hiba1 $!";
} else {
print $#ARGV,"\n";
print $ARGV[0],"\n";
open($infile,$ARGV[0]) or die "Hiba2 $!";
}
while($infile){
chomp;
print "xxx:",$_,"\n";
}
close($infile);Ez így végtelen ciklusban írja az xxx:-eket üresen, nem foglalkozik az stdin tartalmával.
Doksi szerint ha az open-nek nem adok második paramétert vagy ott "-" vagy "<-" stringet adok meg, akkor a stdin-t használja. Nekem úgy tűnik, hogy mégsem. De miért?
Ha nem szórakozok open-nel, csak while(<>) formában használom, akkor nincs vele gond.
(szeretném, ha a program a stdin-t olvasná ha nincs paraméter és a paraméterben megadott fájlt, ha van)[ Szerkesztve ]
Tiszavirág: http://youtu.be/YdcsiW0kfso
-
#8282
beleszólok
senior tag
Oppenheimer
#8281
beleszólok
senior tag
-
#8280
beleszólok
senior tag
beleszólok
senior tag
Van itt valaki, aki használ erlang-t?
Valami használható tutorialt keresek hozzá, ha van jobb, mint amit az erlang.org-on találtam.
(van egy a nyelvek.inf.elte.hu-n is, de az valahogy nem az igazi, hiába magyar)Tiszavirág: http://youtu.be/YdcsiW0kfso
Új hozzászólás Aktív témák
Hirdetés
● olvasd el a téma összefoglalót!
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest