Azon azért csodálkozom, hogy a VirtualDub, illetle legalább a codecjei nem támogatják a multicore-t, de ma már nem csak XviD-ezni szokás, hanem HD-s anyagokat x.264-be tömcsizni (mpeg2-es adásokat, vagy nagy bitrátás h.264-es anyagokat kisebbre).
Optimálisabb 2 vinyó között ki-/betömöríteni, lehetõleg más vezérlõn. Így sem lesz 100%, de legalább gyorsabb. :) Meg közben mást is csinálhatsz. Mert azért eléggé fogja a gépet egy tömörítés is. (Persze a háttérbe lehet tenni, azaz alacsony prioritásra, de akkor meg jó lassú lesz.) Mondjuk itt vannak olyan bénaságok is, hogy a vinyókezelés is egy szálon fut.
Én sem az "AVI-TO-DVD" nevû programot használtam, csak olyan programot, ami azt csinálja. Mittom én már mit szedtem le, de elég drága lett volna, ha megveszem. Amúgy szerintem a VirtualDub+XVID codec nem annyira "gagyi" kombináció, mégsem futott két szálon nálam (egyik CPU 50%, másik 1-2%).
Amúgy akármit is csinálok otthon, jelenleg nem a CPU, hanem a HDD a kicsinyke sávszélesség. Mint mondtad pl a ZIP, RAR, 15%-on használja az egy magot, mikor a winyó mér nem bírja tovább.
Sokan renderelgetnek hobbiból. Hang-, video-, képfeldolgozással (rippelés, konvertálás) is sokan "szórakoznak" (a "warez" nem a szervereken terem :) ). Persze õk nem ilyen gagyi AVI-to-DVD-ket használnak. :) Aztán azt mind zippelni, rarolni... Másik oldalon meg kifelé... Miközben mondjuk valami mást is akarsz csinálni.
Temészetesen magamról beszéltem (otthoni gép) amikor azt mondtam, felesleges. Egy SQL-, Print-, Web-szerver vagy egy professionális felhasználás esetén (értem ezalatt renderelés, 3D tervezés, stb..) nagyon is jól a jön több mag. De itt akikrõl beszélnek a cikkben azok otthoni júzerek. Nekik minek 4 mag?
Ja, egyébként azért vacakolt annyit az az AVI-to-DVD, mert egyszerûen szar (esetleg hiperjó minõségben dolgozik, de nem hiszem). Ha azt a WinAVI-t írnák át többszálúra, mondjuk 7 perc alatt végezne. Szóval ennyit a programozókról.
Nekem 2 magos procim van ([email protected] GHZ). Leszedtem egy AVI to DVD convertáló programot, ami elvileg 2 magon dolgozik. Ment is minden szépen, mind a két mag izzott ezerrel, igaz 2 óra volt a konvertálási idõ. Felraktam a jól bevált WINAVI nevezetû konvertáló programot, ami igaz egy szálas, de 13 perc alatt átnyomta DVD-be. Ennyit a két magra optimalizációról...
Amúgy kipróbáltam fordítva is, konvertáltam DIVX-be, XVID-be, próbáltam mindennel, de az istenért sem akarták a másik magot használni. Én vagyok a hülye? Vagy mit kell átállítani?
Amúgy szerintem teljesen felesleges a 4 mag, a 2magot sem használom ki...
A Java programok ebbõl a szempontból nem különböznek a többitõl.
Az optimális gyors futásért általában elõbb felelõs a fordító program.
Ezen felül azt képzeld el, hogy van egy vödör feladatod, ami közül sok egymásra épül. Például hogyan párhuzamosítanál két összeadást, ami egymástól függ? Egyszerûen sok esetben nem lehet.
Te látod át a kódod logikáját, az algoritmust, hogy szálakra tudd szedni azt. A fordítók nem képesek erre. Olyan ez, mint a végtelen ciklus detektálása.
Ha az operációs rendszernek adsz egy problémát (program) akkor azt egyben fogja kezelni, mert honnan is tudná, hogy valójában mit futtat. NEKED kell tudnod, hogy hol tudod a problémát különálló, egymástól a lehetõ legkevésbé függõ részekre osztani. Ezeket lehet bedobálni az egyes procikba...
Ha én írok egy játékprogramot, vagy szövegszerkesztõt, tök mindegy, minek nekem azzal foglalkozni, hogy hány magos procija van a felhasználónak? Mûvész-programozóként ugyanis én az örökkévalóságnak írom a progit, amelyet majd ezer év múlva is leeht futtatni, adott esetben.
Most, az, hogy a futás optimális, gyors legyen, és más programok is megfelelõen kapjanak erõforrást, az kurvára nem kellene, hogy érdekeljen engem, ezt intézze el az operációs rendszer ("kernel").
Érdekes ez a vita. Nekem egy mezei core-duos gépem van, és tapasztalatból mondom a legtöbb program képtelen kihasználni a két mag elõnyét. Nem egyszer látom hogy csinálok valamit és pörög a proci 50%on mert ugye az egyik mag fullra le van terhelve a másik meg áll üresben. Ennek meg van az az elõnye hogy mellette mást is tudok csinálni a gépen, meg megvan az a hátránya hogy ugyannyi ideig tart a munka mint az egymagosakon.
2000-ben jopar jatekot megneztem, akkoriban a kozel 37 jatekbol, amiket megneztem, csak es kizarolag a microfostos jatekok voltak amik kepesek voltak kihasznalni a tobbmagos gepet /vagyis akkor 2 microfostos jatekom volt (3d-s), az egyik repcsis, a masik valami maszkalos/.
Ma mar valamelyest javult a dolog, de inkabb az alkalmazasok kepesek kihasznalni a kapacitast, mintsem a jatekok.
NB: gondolom a jatekok eseteben a gyors olcso jatekkeszites a lenyeg, es a sok primitiv jatekkeszito ceg a motorjaiban anno arra alapozott, hogy mivel grafikus fg-ket hivogatnak es valojaban nem programoznak, csak meglevo dxfg-ket hasznalnak, szval majd akik keszitik az alltaluk hasznalt fg-ket, majd azok lerendezik a kapacitas kihasznalast.
Magyarazat: mert minden balfasz arra var, hogy helyette vegzik el a munkat *esetleg segitsegkeres cimen kikuncsorogja ezen kegyet*
A Supreme Commander errõl a címrõl bõségesen lemaradt, lévén a Q3 motor a kezdetektõl fogva támogatja a több magon futást. Mikor is jelent meg? 1999-ben.
Nem csak drágább és bonyolultabb lett volna, a céljukat sem érték volna el. Ugyanis a sima proci elég rossz volt lebegõpontos számításokban (FPU -> Floating Point Unit), mivel az egészet szoftveresen kellett utánoznia, integer alapú kóddal...
1993-ban kérdeztem a számtech tanáromtól: Mi értelme van az XT-be tenni egy procit (4,6 Mhz) és mellé egy matematikai ko-processzort (ki emlékszik már erre az édes megnevezésre?), inkább tennének helyette két rendes 4,6 Mhz-es procit. Már nem emlékszem mi volt a válasz, talán az, hogy úgy drágább lenne.
Eloszor is hatalmas nagy marhasag hogy a windows nt kernelek nincsennek felkeszitve a tobb cpu magra. Mar az elso nt, a 3.51-es is eleve tobb cpu-ra keszult, ezt a teljes rendszer azota is tamogatja. Minden egyes i/o kerelem mehet kulon cpu-n, csak a kritikus reszek (amik a hardvert kezelik) futnak keszulekenkent egy-egy szalon. Az egyetlen alrendszer ami meg nem volt tobbszalu, az a gdi volt ami a grafikaert felel mivel ennek mukodese nem valtozott a windows 2.0 ota. Ezt a vista-ban korrigaltak.
A linux eredetileg egy szalon tudott csak dolgozni, de a fo kernel lock mar kezd eltunni, egyre tobb modul kepes kernelszintu tobbszalu mukodesre, bar eleg kaotikus a megoszlas. Van olyan resz ami tranzakcio szintu, mint windows nt sorozat, van ami modul szintu mint a macos, van ami meg mindig globalis lock-al megy, mint a regi linux-okban.
A solaris mindig is tobbszalu volt, csakugy mint a vms vagy winnt sorozat, tehat itt sem volt gond, sot meg jobban is skalazodik mint a tobbseg.
A macos-x jelenleg nem igazan tobbszalu, alrendszerenkent van egy-egy lock, tehat mondjuk a lemez es a halozati muveletek fuggetlenek, de ket halokartya meghajtoprogramja mar nem tud parhuzamosan dolgozni.
"Nem értem miért, vagy úgy oda microkernelekért. Részek közötti kommunikáción többet bukhatnál sebbeségben."
A mikrokernel csak azert jo, mert bar lassabb de stabilabb es egy bena driver programozo nehezebben szurja el az egesz rendszert. Mindezek melett sokkal konyebb es kenyelmesebb ugy driver-t fejleszteni, ha programozoi kornyezetben nincs kulonbseg a felhasznaloi programok es a driver-ek kozott. Egyebkent a sajat fejlesztesu mikrokernelem pl. egymagos egyszalu lett, mert ezt volt a legkonnyebb leprogramozni. A tobbszalusag nem a mikro/monolitikus architektura kerdese, hanem az, hogy milyen finom a kernel objektumok hozzaferesvedelme (lock-olasa). A lehetseges modok: minden szal egy ponton szinkronizal (kernel lock), minden szal a modulhatarokon szinkronizal (module or coarse grained lock), vagy minden szal az objektumhatarokon szinkronizal. (fine grained lock) Mindel fejlettebb egy rendszer annal bonyolultabb megirni. A legegyszerubb egy cpu-s, egy szalas megoldas osszesen ket assembly utasitas (cli/sti), a legbonyolultabb megoldas pedig komoly egyseges architekturat es kulon szinkronizacios modult igenyel. (winnt i/o request packets)
Dehogy használják ki. Mindenre ezt mondják, de mind kamu, ez csak reklám, de persze semmi sem igaz belõle.
Veszel egy több proci-foglalatos (szerver/munkaállomás-)alaplapot, és máris megteheted. Néhányszáz dolcsiból meg is van. Mármint az alaplap. Proci bele még párszáz. Per proci. :)
Mondja meg nekem egy guru, hogy miért nem lehet azt csinálni, hogy a prockókat is hálózatba szervezzék. Modularitásra gondolok. Tehát, ha csak 1 procira van szükségem, akkor annyi lesz, és ha nõnek az igényeim, akkor bedugdosok az alaplapba még egy-két-há.. procit, a RAM-hoz hasonlóan. Bõvíthetõség.
Core Servernél is lesz minimális GUI (egy ablakban fog futni a parancssor), illetve nem a Powershell lesz a parancssor (ahhoz .NET kell, ami nincs benne a Core változatban).
Akkor mar nem sokat kell varnunk a 8 magos procikra :D Ez jo uzlet lesz a gyartoknak :) Evente duplazni a magok szamat ketszer XD A sok birka meg rohan feljeszteni...
Nem értem miért, vagy úgy oda microkernelekért. Részek közötti kommunikáción többet bukhatnál sebbeségben. De ott Minix 3, ha minden áron micro kernel kell.
Linux-ot moduláris monolitikus kernelnek mondjuk. Másrészt az, hogy monolitikus nem jelenti azt, hogy egyszálas vagy, hogy egy magot használ. (Több kernel thread is van) Linux esetén egy rendszerhívást vagy megszakítást bármelyik mag kiszolgálhatja.
a 7-zip 2 magon biztosan szépen fut és ott már a winyó a szûk keresztmetszet. kíváncsi leszek, mit kezd majd 4 maggal.
A Linux is csinálhatná azt, amit a VMS, pl ha lehetne a kernellel párhuzamos szálba modulokat betölteni, akkor csak minden drivert modulba kéne forgatni, és az egyszeri kocka kapna egy mikrokerneles Linuxot :)
Ezeknek a játékoknak azért olyan nagy a memóriaigényük, hogy induláskor minél többmindent betöltsenek, mert ha menet közben is betöltenének ezt-azt, a Vista nem bírná szusszal, hiában van több mag a processzorban, csak egyet használ a kernel (a Linux is). Szerintem a Vista memóriaigénye is ezért ilyen hatalmas, a bloated monolitikus kernel miatt mindenféléket kénytelenek kitalálni, hogy megkerüljék ezt a szûk keresztmetszetet.
A Vistában még egyben van a grafika és a kernel, bár azt igérték, hogy külön jön. Most ott tartanak, hogy 2008 Server lesz ilyen, GUI nélkül használható, Powershell parancssoros Windows.
Solaris és a BSD is monolitikus, ezzel együtt az OS-X is.
Amirõl tudok, a VMS a 8-as verziótól már tud többszálas kernelt, ami gyakorlatilag megvalósítja azt, amit a mikrokerneltõl várnak, pl a fájl I/O kezelését több szálban képes elvégezni, de az csak Alpha és Itanium processzorokon fut. QNX-nek mikrokernele van (Neutrino), fut PC-n, de õket meg a valósidejû, beágyazott alkalmazások érdeklik, talán nem látnak pénzt az egyszerû userben. Gondolom Mikroszofttal nem akarnak bírkózni, a Linux és a BSD pedig elszívja elõlük a levegõt.
Ja, van Unicos is, azt a Cray (the Supercomputer Company) fejleszti, na azt sem fogják hamar laptopra portolni, pedig AMD procikon futó változata is van. IBM-nek van néhány oprendszere, majd ha egy manager azt álmodja, hogy lehetne kaszálni vele, talán :)
Hát igen. Ps9-ben is van már multiprocesszor támogatás, egyéb 3Ds progikban is. Asszem az elsõ játék a aaa nem jut eszembe a nevee naaa, megvaan a supreme commander volt. Aztán Bishock , Crysis is mind már kihasználják a multiprocit. Lehet kicsit megkésve de azért meglesz a szoftveres támogatása ezeknek.
Ezért variálták át a dolgokat grafika ügyben a Vistán, bár nem tudom, hogy sikerült. A Solaris milyen? Tudom, az is monolitikus, de amúgy? Csak mert az OpenSolaris felemelkedését jósolják egyesek. Hát a BSD, és változata? És ezzel együtt az OS-X?
Na igen. De nem hiszem, hogy ma ez lenne a fõ gond, késõbb már igen, de addigra csak lesz valami. (Vagy nem. :P) Mondjuk ma is tud akadni szépen, de más hülyeségek miatt, fõleg a Windows. A mai vinyókkal amúgy sem lehet kiszolgálni akár csak néhány file-mûveletet végzõ taszkot sem. Bár jönnek az SSD-k. Jópár dolog nem a kernelben van, hanem külön driverekben, stb. Pl. az Nvidia gfx driverek támogatják már a több magot, talán az ATI/AMD-sek is.
Pl. ilyenek vannak ma, hogy többprocis Opteron/2 procis FX rendszereknél, az IMC miatt sokkal gyorsabb a saját ram elérése, mint a szomszédoké, de pl. az XP erre egyátalán nincs tekintettel. Meg amúgy is körülményes elérni, hogy valami fixen az egyik, másvalami fixen a másik magon fusson.
Grafikus megjelenítésbe a GUI logikát is beleértem, pl ha felhasználó türelmetlenül kattintgat XY belassult alkalmazás oké gombjára, akkor Linuxon a külön szálon futó ablakkezelõt terheli, míg Windowson a kernelbe van építve az is. Szóval ezért hal le az ilyenkor. A Linux elõnye az, hogy a kernele vékonyabb, de sajnos több kritikus dolog egyben van benne. Szegény Tannenbaum nem véletlenül mérgelõdött annak idején, hogy mikrokerneles OS kellene.
A butácska enyhe kifejezés, ha belegondolunk, hogy minden fontos PC-s oprendszer monolitikus kernelû. A Linuxon legalább a grafikus megjelenítést felhasználói program felügyeli, ott van rá esély, hogy tehermentesítésként egy másik processzor foglalkozzon vele. De ha pl. több alkalmazás szeretne valamit a kerneltõl, pl. fájlokat írni/olvasni, eszközt inicializálni, vagy egyszerûen sok a taszk és le van terhelve a kernel shedulere, akkor hiába van 50 magos processzorom, az az egy mag fog izzadni, amin a kernelszál fut, a többi ül és nézi, és az egész rendszer akadni fog. Windowson elõbb, Linuxon késõbb, de ebbõl a szempontból a kettõ egykutya.
A fontosabb teljesítményigényes programok (3D renderelõk, médiafeldolgozók, tömörítõk küzül is több, stb.) többsége ki tudja már használni a több magot. Kivétel a játékok, mert ott nagy átalakításokra van szükség ehhez. De egyes játékok tudják.
Informatika és tudomány
