Szavazás

Milyen virtualizációt használsz?

Online felhasználók

Jelenleg 0 felhasználó van a webhelyen

Új felhasználók

  • Morello
  • gyo
  • jbaksa
  • tomassy
  • Kalacska13

Ajánlott böngészők

Google Chrome

Jelenlegi hely

Dual Core-s proci

Hali!
Gép vásárlás előtt állok és a következő prockót néztem ki
Athlon64 X2 3800
Ami engem érdekelne, hogy a duálos procit hogyan tudnám maximálisan kihasználni?? Amit találáltam a neten az alapján slamd
64 kerülne a gépre, de lehet ti tudtok más okosságot is.. Slakit szeretnék rá tenni, vagy, a közvetlen leszármazottját (slamd64)

Fórumok: 

Maximalisan akkor tudod kihasznalni ha a programokat ujraforditanad, hogy tobbszalon mukodjenek (gcc -j3 ...). Tehat a teljes slamd64-et ujraforditod. Erre inkabb a Gentoo hasznalatos, ott egyszerubben megoldhato.
Felreertes ne essek Szeretem a Slackware-t :)
A lenyeg, hogy mire kell a dualcore. Ha nem forditassz forrasbol sokat vagy kodolsz filmeket, akkor nem fogod igazan erezni a kulonbseget, tehat nem fontos a tobbszalusag. A szuk keresztmetszet egyebkent is a hdd.

>Maximalisan akkor tudod kihasznalni ha a programokat >ujraforditanad, hogy tobbszalon mukodjenek (gcc -j3 ...). Tehat a >teljes slamd64-et ujraforditod. Erre inkabb a Gentoo hasznalatos, ott >egyszerubben megoldhato.

Erre egy sima slamd64 és abban egy kernel forgatás smp-s kernellel nem uaz???

Szia

Nem ugyanaz, mert így csak a kernel tudd a 2 magrol. A felhasználoi alkalmazások továbbra is csak az egyik magot fogják "látni". Pl. a családi VHS kazettán lévő felvéleket beakarod digitalizálni, és DVD-re kiirni. A rippelő program csak az egyik magot fogja használni, miközben a másik nem csinál semmit, igy lehet nem tudsz nagy felbontású, jó minőségű felvételt készíteni. Valamilyen nagy erőforrás igényű játokot akarsz játszani amihez egy mag kevés, így lassú lesz a játék, ha meg a progi mind kettő magon futhatna egyszerre, párhuzamossan akkor lehet hogy akadás mentessen futna. Persze ha egyszerre legalább kettő alkalmazást futatsz, akkor az egyik használja az egyik magot, a másik a másikat, amennyiben ezek erőforrás igénye ezt szükségessé teszi, mert a kernel a kettő proceszt kettő külön magon futatja. Én pár hete vettem egy Athlon64 3200+ procit (egy mag, max. valós órajel 2GHz).+alaplapot+...stb. mert a régi gépen alaplapja meghalt. A rendszerbe beállítottam az energia gazdálkodási lehetőségeket, így a proci ha nincs nagy teljesitményre igény csak 1GHz(1600+) fut. DVD nézés közben is ez az órajel a proci terhelés meg 15%-ék körül alakul. Szóval attól függ mire kell az a gép, így vagy kihasználod a lehetőségit,de akkor mindent optimalizálni kell, vagy nem. Nem akarok "distrowar"-t inditani. A notebookomra (Centrino technológia, Pentium-M proci...stb.)én is telepítettem Gentoo linuxot. A teljes rendszer erre az architekturára lett optimálizálva. A KDE grafikus munka környezetet a gép kb. 50 óra alatt fordította, telepítette. A teljes rendszer telepítése így majdnem egy hétig tartott. Gyorsabbnak gyorsabb lett a rendszer mint a Slackware, annyival viszont nem, hogy azt mondjam megérte. Persze a kiváncsiság is hajtott, milyen a Gentoo linux.

Bye

Még mindig nem tiszta.. :))

>Nem ugyanaz, mert így csak a kernel tudd a 2 magrol. A felhasználoi >alkalmazások továbbra is csak az egyik magot fogják "látni".

Szal adott egy Amd X2 és a Slamd64 feltelepszik a gépre az op. rendszer és megtörténik a kernelforgatás smp-s kernel beforgatva.. Szal ebben az esetben van egy 64 bites oprendszerem amiben az oprendszerrel szállított progik a dual procis prockót nem tudják kihasználni?? Csak az utána (később) pld forrásból telepített progik képesek erre??? Mert ha igen, akkor nyerő a dolog :)

... Szal ebben az esetben van egy 64 bites oprendszerem amiben az oprendszerrel szállított progik a dual procis prockót nem tudják kihasználni??

Korulbelul igen. Pontosabban egy prg. nem tudja kihasznalni a ket magot. Tobb mar igen.

Csak az utána (később) pld forrásból telepített progik képesek erre???

Ha megfeleloen parameterezed, akkor igen. Nem elegendo a

configure
make
make install

Mert ha igen, akkor nyerő a dolog :)

:))
Izlesek es pofonok. En azert egy dualmagos procit szeretnek a leheto legjobban kihasznalni. Kulonben minek a 2 mag. Persze ez mar csak az en elvarasom. :) Azert a glibc, gcc, kde ujraforgatva erezheto gyorsulast eredmenyezne. Bar akkor meg a tobbit is kellene. Forditsd ujra a slakit, legalabb tanulsz is belole. :)

>Ha megfeleloen parameterezed, akkor igen. Nem elegendo a
>configure
>make
>make install

Hali!
Ezt konkretizálnád??

kérdezném h a dual procis rendszereknél is ez a helyzet? h alapbol csak 1 procit használ és ujra kéne forditani linuxot?

Ezt konkretizálnád??

A "configure" nem elegendo igy csupaszon. Szukseges lenne parameterezni a CFLAGS segitsegevel. Pl.:

configure CFLAGS="-O3 -march=k8 -msse2 -m3dnow -j3"
make
make install

Mit is jelent ez?

  • -march-al az architekturat tudod megadni. A k8 az amd k8-at jelenti.
  • -O3 az optimalizacio merteket jelenti. Tetszes szerint valaszthatsz a(z): OS, O1, O2, O3 kozul. A O2 a gyakori. A OS meretre optimalizal az O3-nal instabil lehet a rendszer. Errol rengeteget szoktak vitazni.
    Igen, amit el szoktak nezni: nem 0(nulla), hanem nagy O(Ó) betu.
  • -msse2 a -mxyz plusz tamogatast tudsz megadni itt pl. az sse2-ot.
  • -j3 ez a lenyeg tobb magnal v procinal. A szokas, hogy a proci (v mag) szama +1 a j utani ertek. Van hogy egyenlo vele, attol fuggoen, hogy mukodik e rendesen +1-el.

A gcc-t erdemes atnezned. Ott az opciok szebben le vannak irva.
Be tudod allitani rendszerszinten a CFLAGS valtozot. En manualisan jobban szeretem.
Nem tudom ertheto voltam-e. Kicsit faradt vagyok.

konkrétan dual p3 coppermine

A kernelt mindenkeppen jo lenne. Ha teljesen ki akarod hasznalni, akkor erdemes a tobbit is ujraforgatni. Amennyiben ez szerveren van ott megvan az az elonye, hogy egyszerre tobb process fut, igy eleg jol ki van hasznalva. Otthon ez ritkabban tortenik meg. Alkalmazasfuggo, hogy mennyire eri meg, hiszen nem keves idot vesz el. Attol fug mire hasznalod.

u.i.: ejfel korul eppen megirtam a valaszt de elkuldeni mar nem tudtam

Sziasztok

A processzor által támogatott utasitásokat (flags) a
cat /proc/cpuinfo
paranccal tudod megnézni. Egész szép lista amit egy A64 tud. Fordításnál azért óvatossan kell bánni ezekkel (Gentoo-s tapasztalat). Rossz esetben nem fordul a program, még rosszabb esetben lefordul csak bug-os lesz. Jó lesz ha vezetsz egy listát az általad telepített, optimalizált programokról, mert a swaret,- slapt-get -update, -upgrade felrakja az ujabb csomagokat amik 1 magos optimalizációval készültek, igy ezeket szintén fordíthatod újra. Szóval az ilyen "buherált slamd64" karbantartása nem egyszerü feladat. Amennyiben "über-optimalizált" rendszert akarsz, mert szükséged van rá (szerver, vagy digitalizálod a VHS kazettákat, videószerkesztés...stb) akkor inkább Gentoo-t tegyél a gépre, ott a "portage" rendszer miatt a karbantartás egyszerübb,további infot tudok adni a tapasztalatokról privátba. Belépsz -> Tagok között megkeresel -> levél küldés.

UI. "Please no distrowar"

Bye

szal ha slapt-get-el lehuzom az 1procis progit akkor azt ujralehet forgatni vagy azt felejtsem el és vadásszak a neten forrást?

Szia

Ami a telepítő CD-n megtalálható program csomag, valamint az amit a slapt-get frissités során letölt az egy elöre lefordított futatható állomány (kész program) tömöritett formátumban. Pl.: aumix-2.8-x86_64-1.tgz -re ha ránézel egy fájlkezelövel (MC,Krusader,Konqueror) láthatod, hogy mi van benne. /usr/bin/aumix, /usr/doc...stb. + egy install script ami az egészet felrakja. Amennyiben ez neked nem jó mert optimalizált programot akarsz, akkor meg kell keresned ennek a programnak a forrás kódját a neten, letölteni, optimalizáltan lefordítani, telepíteni. Ez egyböl felvett egy újabb problémát, nevezetessen mi legyen a fent lévő csomaggal?
1. lehetőség a csomagkezelővel törlöd a csomagot, majd ezután fordítasz,így frissitéskor ez a csomag nem lesz frissitve mert nem szerepel a csomag listában, fent marad a te általad forrásból telepített optimalizált verzió. Mi van akkor ha a frissités egy súlyos biztonsági hibát javit? Nos ez a gépre így nem fog felkerülni, neked kell figyelni a program verzió változását, telepíteni a javítást.
2. lehetöség nem törlöd a csomagot csak egy optimalizált fordítással és telepitéssel felülírod az eredeti állományt. Ez esetben frissitéskor letöltödik az újabb verzió, települ, és felülírja az általad fordított, optimalizált, telepített állományt, de igy legalább a hiba javitás megtörténténik. Ezek után lehet nézegetni a csomag listát, mi lett frissitve , mit kellene újra forgatni optimalizálva ..stb.
Bármelyik megoldást is választod sok gondod lesz vele. Arról nem is szólva, hogy egy-egy programot telepíteni optimalizálva, miközben a rendszer többi összetevője optimalizálatlan programokból áll szerintem értelmetlen. Minden disztribúciónak van előnye, és hátránya. Az előre lefordított csomagokból felépülő rendszereknél az utólagos optimalizáció nagyon nehéz. A SGI cég szuperszámítógépek építésével foglalkozik. Pár éve készítettek egy gépet a NASA-nak, ami 10240 db. Itanium 2 procit tartalmaz és erre a NASA+SGI mérnökei egy "saját" linuxot tettek azért, hogy kitudják használni maximálisan a gép lehetőségeit.

Bye

de viszont ha nem optimalizálom csak a kernelt akkor annak mien hatása lesz? ugyan olyan sebességgel megy mintha csak 1 proci van benne vagy összeadodik a mhz vagy mien lesz?:)

Hogy mik vannak!!!!

extra/linux-smp-2.6.17.13/kernel-generic-smp-2.6.17.13-i686-1.tgz:
This is an optional kernel with support for SMP (up to 16), dual core
optimizations, and SMT (Hyperthreading). Fully tuned and ready to go.
extra/linux-smp-2.6.17.13/kernel-headers-smp-2.6.17.13-i386-1.tgz
Optional kernel headers. There will only be needed to compile a few things,
such as apps and libraries that use ALSA (it contains the /usr/include/sound
directory that for 2.4.x kernels is supplied in the alsa-driver package).
extra/linux-smp-2.6.17.13/kernel-modules-smp-2.6.17.13-i686-1.tgz:
Kernel modules for Linux 2.6.17.13-smp, including ALSA modules.
These install into /lib/modules/2.6.17.13-smp/.

http://www.slackware.com/changelog/current.php?cpu=i386

ÁÁÁÁ paca, ha tudnád h mennyit vadásztam én erre... Pedig csak a szememet verte ki :).

Thx: Fiber

Na de jó, hogy ide is be vagyok regelve.

Amit mondtál, az egy nagy baromság. A make -jxx azt mondja meg, hogy a fordítás hány szálon történjen. Ergo hány darabb gcc -t indítson. Minden gcc 1 fájlt fog fordítani egyszerre aztán a végén linkelni. Viszont semmi nem változik futási sebességben, mert ugyanaz a bináris lesz a végeredmény bitre pontosan (ha nem, akkor ott valami nagyon el van baszarintva).

Ha egy alkalmazást nem úgy írnak meg, hogy az képes legyen több szálon futni, akkor az isten se veszi rá arra, hogy két magon fusson, maximum, ha kettőt indítasz belőle, de az meg megint nem ugyanaz.

Előre bocsátom, hogy se programozó nem vagyok, se "nagy" linux user, de:

Amikor megírnak egy programot sokszor ún. szálakat használnak benne. Ez egy magos rendszeren pl. azért jó, mert ha az egyik szál valami olyat csinál ami időigényes és a procit nem / alig használja (tipikus példa: I/O), akkor addig a másik szál feldolgozása tud folyni. A szálváltások kezelése az OS feladata.

Egy típikus iskola példa: Csinálsz egy GUI-s progit, amit mondjuk egy gomb lenyomásra időigényes feladatot csinál - pl. számol vmit pl. fél percig. Ha ezt nem külön szálban oldod meg, akkor a program úgy néz ki mint ha "lefagyott" volna. Ha külön szálba teszed, akkot a program képes reagálni pl. az egér klikkelésekre.

Nyilvánvaló, ha egy többszálú programot többmagos CPU-n futtatsz, akkor az gyorsul(hat).

Ha nem így lenne, akkor egy már lefordított programnál - más OS-eknél tipikusan nem szokás a forráskódot odaadni a usernek, hogy ő forgassa le - nem tudnád kihasználni, hogy többmagos a procid?
Pl. Játékos kedvű Gipsz Jakab megveszi Windows alá kedvenc FPS-ét. Egy lefordított binárist kap, de ha procit cserél, pl. többmagosra, akkor a játék gyorsulni fog - legalábbis ha nem túl régi ez a játék:)

A fentiek alapján tehát saxus-val értek egyet, azt hiszem ő is ezt mondta.

Ha valamit rosszul mondtam volna kérlek javítsatok.

voloferenc képe

Én programozó vagyok ezért most megmondom a tutit. :)
Szóval a hivatalos megfogalmazás:

"A többszálú programozás jóvoltából programunkban egyre több programszál (utasítássorozat) is futhat. A program ezáltal sokkal jobban kihasználja a processzort, vagyis sokkal rugalmasabb és hatékonyabb lehet. Egy programszál időről időre blokkolt állapotba jut: ha például adatot vár a felhasználótól, akkor lényegében nem csinál semmit. A felhasználóknak ma már természetes, hogy számítógépe egyszerre több feladatot lát el: miközben a gép betölt egy képet, ő átkapcsol a szövegszerkesztőbe, és levelet ír. A többszálú programozás különösen jól használható animációk készítésére."

És az igazán lényeges:

"A folyamat (process, task, job) a számítógép által végrehajtott utasítássorozat. Az egyfeladatos operációs rendszerben egyszerre csak egy folyamat futhat, a többfeladatos operációs rendszerben egymással párhuzamosan több is. A párhuzamos működést a felhasználó alighanem egyidejűnek látja; pedig ha a számítógépben csak egy processzor van, akkor szó sincs egyidejűségről: az operációs rendszer megfelelő szabályok szerint bizonyos időtartamokra - "időszeletekre" - odaadja a vezérlést a programoknak.

A programszál (thread) hasonlít az operációs rendszerben futó folyamatra: ő is csak időnként kapja meg a vezérlést. A folyamatok szálakból állnak. Amikor ez vagy az a folyamat (program) fut, akkor az ő szálai közt oszlik meg a vezérlés. Ha a folyamat éppen blokkolva van (valami miatt nem futhat, még ha megkapná is a CPU-tól a vezérlést), akkor nem futhat a benne "futó" programszál sem."

Ez lenne röviden. :)

Gollam képe

Azért én még javasolnék egy harmadik megoldást is.
Nevezetesen azt, hogy fordít az ember magának, majd csomagot csinál belőle és feltelepíti ezt a csomagot.

Belépés

Friss hozzászólások