Multithreading

Ma már volt egy csörtém megint, hogy totál érdektelen, hogy mennyire takarékos az erőforrásokkal egy program, hanem sokkal érdekesebb az, hogy a meglévőket mennyire jól használja ki. Itt egy példa, feladat: SOS-ben transzkódolni FLAC-ból MP3-ba, mert a telefon csak azt ismeri. Adott egy Xeon E5-1620, 4 core 8 thread, ~40-50 fájl. Ez 8 threaddal megindítva egész gyorsan megvan. Ahaaaam, ha nem egy fogyaték írta volna a programot és írt volna bele multithread supportot, amit kiegészített volna annyival, hogy hány CPU mag van. A még nagyobb probléma, hogy valami csicsa szart sikerült elsőre találnom, amiben viszont azt megoldották, hogy ellenőrizze már le, hogy nem fut-e belőle egy példány. Hurrá. (De legalább ezt a posztot meg tudtam írni, haha.)

Na ezért lassúak a programok. Ahelyett, hogy a géphez adaptívan alkalmazkodó programokat írnánk, ugyanúgy kódol mindenki, mint 40 évvel ezelőtt.

Hozzászólások

Ha jól emlékszem, erre jó a parallel nevű utility.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ezt a feladatot pont lehet jol parhuzamositani tobbszalusag nelkul:

# Makefile
FILES := $(shell find . -name '*.flac')

all: $(FILES:.flac=.mp3)

%.mp3: %.flac
ffmpeg -i $< $@

make -j 8

:D

Btw, multithreading != concurrency != parallelism

--
NetBSD - Simplicity is prerequisite for reliability

Soundconvertert használom erre sok éve. 4 magos cpu-m van, 4 szálon kódol. 1p15s alatt kódolt át 14 számot tartalmazó flac formátumú albumot mp3-ba. Alkalmazást is tudni kell választani.

---
A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.
Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!
Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

Ahelyett, hogy a géphez adaptívan alkalmazkodó programokat írnánk
Ebben tokeletesen igazad van, de egy adott program honnan tudja hogy a tobbi x processz ami fut az milyen style-ban hasznalja ki a cpu-mag-eroforrasokat? Load-ot vagy ekvivalens dolgot persze lehet nezni de az meg nem eleg dinamikus.

Anno (`pexec` fejlesztes kozben) ez elegge elojott. Marmint hogy ezt kulturaltan megoldani nem annyira egyertelmu. Ha tobben (tobb juzer, tobb program-rendszer, ...) akar nekiesni _egymastol_fuggetlenul_ a 4-8-x magnak, akkor ott mar komolyan gondolni kell a mindenre.

Arra van az oprendszer schedulere. Vagy pl. egy VM-et használó nyelv esetén simán lehet olyan task api-t csinálni, ami ezeket okosan időzíti.

Egyebkent koszonom a sok write only jotanacsot, de irtam, hogy a program ellenőrzi, hogy fut-e mar egy példányban. (Erre bezzeg volt eszuk). tovabbra sem hasznalok Linuxot desktopnak.

---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Hat, jotanacsot nehezen adhattunk volna hiszen se a kornyezetet, se a konkret programot nem ismerhettunk meg, amirol szo van ;] Ha pl linux/unix-os, akkor lehet hogy volt annak is egy --use-the-force-luke kapcsoloja ami minden problemadat megoldotta volna ;)

Ellenben teny, hogy az eredeti problemad az nem problema. Linux/unix alatt semmikepp, mas rendszerben nem csinaltam ilyen tobbszalu flac -> mp3 konverziot. Ez tapasztalat.

Az altalam irt hozzaszolasok meg azt tukrozik, max, hogy a problemad szamos, szerintem sok szempontbol erdekes kerdest felvet(het), indukal.

ffmpeggel tovabbi probléma, hogy nagyon jol használható eszköz, de ha gyorsan kell valami, amit nem használtam korabban, akkor egy 1M-as doksival rendelkezo CLI-s eszköz nem megoldas, ha nincs hozza egy intuitív frontend.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"se a konkret programot nem ismerhettunk meg

Nem jótanács kellett, az igazi probléma (flac->mp3 konvertálás) is megoldodott, csupan értekeztem egy ropket egy karos programozói mentalitasról. Emiatt érdektelen, hogy milyen OS, milyen program (Fogalmam sincs mar, kb. az első szembejövő freeware, toolbart telepíteni nem akaró ize).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™"""