Portolták a Grand Central Dispatch-et FreeBSD-re

FreeBSD

Az Apple szeptemberben úgy döntött, hogy Apache 2.0 licenc alatt nyílt forrásúvá teszi a Snow Leopard Grand Central Dispatch komponensét. A FreeBSD-nél pedig úgy gondolták, hogy érdemes lenne a rendszerükhöz illeszteni. Robert Watson és Stacey Son portolták a GCD-t FreeBSD-re. A portot szeptember közepén mutatták be a Cambridge-ben megrendezett FreeBSD Developer Summit rendezvényen (diák). A port jelenleg elérhető a FreeBSD port gyűjteményben. A FreeBSD 8.0-RELEASE elérhetővé válása után az új kqueue primitives-ek MFC-zésre kerülnek, így a libdispatch out-of-the-box működni fog a FreeBSD 8.1-RELEASE-en.

( bervi | 2009. 10. 13., k – 22:30 )

linuxon lesz ebből valami?

szerintem.

( log69 | 2009. 10. 13., k – 22:42 )

szuper :)

makkosoknak nincs valami tapasztalat amit megosztanának, hogy mennyire érzékelhető a plussz sebesség a többi mag kihasználása miatt deszktopon?

Már két mag esetében rendesen érződik, persze a minimális 2 GB RAM után. Mac Mini Core Solo és a vele egy súlycsoportban levő MacBook Core Due összehasonlításáról tudok nyilatkozni: mezei felhasználó által is érezhető, zongorázható. Kapásból ha az egyik program kegyetlen módon húzza a procit, addig a többi rendesen reagál, feltéve, hogy az előbbi processz nem gyilkolja közben a diszket is, mert akkor a négy mag se ment meg a döglődéstől.

OFF

"plussz" <-- ezt ugye nem gondoltad komolyan? Talán "plusz" helyesebb lenne.

--
Kinek nem inge, ne vegye gatyára

"ha az egyik program kegyetlen módon húzza a procit, addig a többi rendesen reagál..."

Ez más rendszeren is így van imho több mag és több processz esetében. Arra lennék kíváncsi, hogy 1 folyamatba is be tud-e segíteni a GCD? Persze gondolom eleve úgy kell megírva (vagy fordítva) lennie a proginak, ezért jelenleg leginkább talán a rendszer komponenseket gyorsíthatja. de FIXME

Esetleg olyan progival nincs tapasztalat, ami rendesen eszi a CPU-t 1 szálon? Szétdobja-e több szálra?

szerk.: "plusz" +1 pont oda :)

ezzel szemben ha nincs több szál és úgy van leprogramozva, abba az 1 szálba is besegít több maggal tudtommal a GCD - a wiki szerint is 1 szálban lévő feladatokat párhuzamosít és állít sorba (most még egyszer megnéztem), tehát nem írtam hülyeséget szerintem a kávéfőzős sztori előtt sem ;)

tudtommal ezt normál direktívákkal nem oldod meg, vagy neked kell körülményesen szétdobatni a feladatokat több szálra - az "ősöreg" schedulernek itt annyi szerepe van, hogy a már meglévő folyamatokat szép elfuttatja több magon, viszont nem segít a folyamatok létrehozásában

egyetértek, a programozó jelöli ki meg a részfeladatokat, viszont a GCD állítja sorba hatékonyan -ez GCD nélkül annyit jelentene, hogy a programozónak meg kellene hivogatni a függvényeket és ténylegesen létrehozni a thread-et, majd vizsgálgatni az élettartamát, meg minden egyebet - most GCD-nél tudtommal elég a makrókat megadni, és a részfeladatok több szálon végrehajtódnak és (ezt gondolom) a program végrehajtás utána megy tovább - tehát nem kell vizsgálgatni meg leprogramozni az egész hóbelebancot.

gondolom GCD-vel azért gyorsan átformázzák a lényegesebb kódrészeket.

Legalábbis az Apple marketing szerint. Az mindenképpen előrelépés, hogy nem minden alkalmazás a saját, fix méretű threadpooljával mesterkedik, hanem az OS az egész rendszer terheltségét figyelmbe véve próbálja megfelelően ütemezi a párhuzamosan végrehajtható blokkokat. De hogy képes lenne ezeket optimálisan ütemezni, mint ahogy a marketing hirdeti? Ugyanmár, sokan akartak már optimális schedulert csinálni az utóbbi évtizedekben, de valahogy nem igazán akart összejönni.

Én inkább azok táborába tartozok, akik aggódni kezdenek, ha az "egyszerű" és "párhuzamos" szavakat egymás mellett látják.

szerk.: még egy érdekes aspektus: jelenleg a szoftver ipar nagyobb részét objektum-orientáltság uralja, az iskolák ontják az OO nyelveken és UML-en nevelkedett fiatalokat. A GCD mennyire illeszkedik az OO koncepciókhoz a blockjaival és queue-jaival? Hát nem nagyon.

Igazából én jobban el tudnám képzelni a párhuzamosítást objektum orientált szemlélettel programozott szoftvereken / rendszeren ha így belegondolok, mert ott az objektumkezelés szintjén talán lehetne automatikus többszálúsítást végezni (pl. külön objektum instance-ek külön szálon stb.). És talán inkább ott, mert egy lineáris kódrésznél nem nagyon van valószínűleg elég ismeret alap annak eldöntésére az ütemező szemszögéből, hogy milyen rész feladatok választhatóak szét főleg hatékonyság szempontjából meg egyáltalán hogyan szabdalható szét. Viszont egy objektum élettartama alatt sok "hasonló" művelet történik és az osztályok kódrészei is nagyon elkülöníthetőek lennének szerintem. De persze nem tudom, ez már okoskodás részemről.

Nem próbáltam és nem ismerem a GCD-t, én is arra lennék kíváncsi hogy a marketingből mennyi az annyi :)

Mondjuk talán a jövőben egy nyílt FreeBSD port-tal talán jobban ki lehet majd kísérletezni és teszteket végezni "házilag".

( dikki | 2009. 10. 13., k – 22:43 )

"az új kqueue primitives-ek MFC-zésre kerülnek, így a libdispatch out-of-the-box működni fog a FreeBSD 8.1-RELEASE-en" ezt már a 7 vezér se mondta volna szebben ;D

( tr3w v | 2009. 10. 14., sze – 02:15 )

"Block" nélkül ez hogyan használható? Fv. pointerrel?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"FreeBSD questions:
·what is required to get C Blocks working --
libgcc, compiler-rt, etc"

Biztos, hogy van?

clang (LLVM) alól esetleg, no de mikor állt át a FreeBSD clang-ra?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o