Gyurkity Péter

Novemberben jön az Intel négymagosa

A tervezettnél korábban, január helyett már novemberben bemutatkozhat az Intel négymagos processzora, ami a jó gyártási eredményeknek köszönhető. Az AMD eközben az Athlon 64 X2 5200+ révén kapaszkodik.

A nagyobbik processzorgyártó háza táján történő fejleményekről ezúttal az eWeek számolt be egy rövidebb hírben. Eszerint a sokak által vált Kentsfield kódnevű négymagos asztali processzor - amely egyben felteheti a koronát a jól sikerült Core 2 Duo sorozatra - már két hónapon belül, novemberben megjelenhet, vagyis ha minden jól alakul, még az ünnepek előtt belekóstolhatunk az új generációba. Óriási újításokat ugyan nem várhatunk, de mindenképpen érdekes lesz megtapasztalni a négy mag erejét, illetve azt, hogy a szoftveres oldal hogyan viszonyul majd ehhez.

Ahogy arról már korábban beszámoltunk, a Kentsfield gyakorlatilag két Conroe összeolvasztásából született meg, jelentős architektúrális változások itt nem játszanak szerepet. Az első négymagos példányok 2,66 GHz-en futnak majd, 1066 MHz-es rendszerbuszra és 4, illetve 8 MB másodszintű gyorsítótárra támaszkodnak, helyüket pedig a már korábban bejelentett 3,2 GHz-es kétmagos Core 2 Extreme környékén, vagy éppen ott kell keresni. Az alacsonyabb órajel egyfajta kompromisszumot jelent: nyilvánvaló, hogy nem minden alkalmazás használja ki a négy magból fakadó előnyöket, így könnyen előfordulhat, hogy bizonyos esetekben az új erőmű lassabb lesz elődeinél.

A megjelenés előre hozása alapján többen arra következtetnek, hogy az Intel az órajel helyett ezúttal a processzormagok számára helyezné a hangsúlyt, ezzel szeretné igazolni a vásárlók szemében, hogy vetélytársa előtt jár. A chipek számozása, jelzései nem elég egyértelműek, viszont a magok száma világosan jelzi, hogy mely fejlesztésekbe érdemes befektetni, igaz, a nagyobb érték még nem jelenti automatikusan a jobb időtállóságot.

Természetesen az AMD is igyekszik bebizonyítani, hogy nem kell lemondanunk róla, bár a kisebbik cég eredendően kevesebb eszközből válogathat. Egyelőre a meglévő asztali sorozat kibővítésére futotta, ezt is egyetlen példány, az Athlon 64 X2 5200+ jelenti. A 2,6 GHz-en futó chip órajelben nem jelent előrelépést a korábbi listavezetőhöz (5000+) képest, másodszintű gyorsítótára azonban a duplájára, 2 MB-ra nőtt, így kísértetiesen hasonlít a már visszavonultatott FX-60 processzorokra. Ára ennél jóval kedvezőbb, 1000 darabos megrendelésnél 403 dollárt, azaz mintegy 86 ezer forintot kérnek el érte, míg az előd esetében ez 1000 dollárt jelentett.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • dez #116
    Épp ezért csak magasabb jogokkal használható, asszem.
  • BiroAndras #115
    Érdekes. Ezek szerint elég időnként meghívnom a setpriority-t, és máris legyőztem a scheduler-t.
  • dez #114
    "A felhasználó szempontjából a nice megfelel a win-es prioritásnak."

    Egyébként ez sem igaz így, de mindegy.
  • dez #113
    Nem. Unixon/Linuxon is állítható az alap prioritás. Lásd getpriority()/setpriority(). Csak ez bizonyos feltételekkel használható, miközben a nice szabadabban, viszont maga a nice korlátozottabb.
  • BiroAndras #112
    "Egy prioritás van, amit a nice is befolyásol."

    win-en a prioritás állítod. Linuxon te a nice-t állítod (meg a class-t), amiből a scheduler számol egy dinamikus prioritást. A felhasználó szempontjából a nice megfelel a win-es prioritásnak. A többi az eltérő scheduler algoritmusból adódik.
  • dez #111
    "Igen, de ez a prioritás nem az a prioritás, mint win-en."
    -- Egy prioritás van, amit a nice is befolyásol.

    "Annak a nice felel meg"
    -- Csak távolról felel meg neki.

    "amit viszont kizárólag a programozó állít."
    -- Láttam én már olyat, ahol a nice-t állították.

    "A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést."
    -- Lásd, amit fent írtam.

    "Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket."
    -- Aham, jó.

    "Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük."
    -- Természetesen. De ehhez hozzátartozik a prioritás-állítás engedélyezése/tiltása is.

    "Win-en hasonlóan működnek a prioritások, csak ott a scheduler algoritmus fix."
    -- Távolról hasonlít, közelről eléggé más.
  • BiroAndras #110
    "Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást."

    Igen, de ez a prioritás nem az a prioritás, mint win-en. Annak a nice felel meg, amit viszont kizárólag a programozó állít. A prioritás itt a kernel által dinamikusan számolt érték, ami segíti az ütemezést.

    "Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között"

    Le van írva pontosan, hogy mi a nice. A kernel által számolt prioritáshoz adódik hozzá, így a júzer tudja befolyásolni a számolt értéket.

    "Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg)."

    Ezek az osztályok azt mondják meg, hogy hogyan kezelje a scheduler az adott process-t, nem a prioritás állítás/nem állítás a lényegük.
    És egyébként, ha akarom így is el tudom venni teljesen a CPU-t a többiektől.
    Win-en hasonlóan működnek a prioritások, csak ott a scheduler algoritmus fix.
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/scheduling_priorities.asp
    Érdemes elolvasni a többi részt is.
  • dez #109
    Na nézzük:
    "Early Unix implementations use a scheduler with Multilevel Feedback Queues with round robin selections within each Feedback Queue. In this system, processes begin in a high priority queue (giving a quick response time to new processes, such as those involved in a single mouse movement or keystroke), and as they spend more time within the system, they are preempted multiple times and placed in lower priority queues. Unfortunately under this system older processes may be starved of CPU time by a continual influx of new processes, although if a system is unable to deal with new processes faster than they arrive, starvation is inevitable anyway. Process priorities could be explicitly set under Unix to one of 40 values, although most modern Unix systems have a higher range of priorities available (Solaris has 160). Instead of the Windows NT 4.0 solution to low priority process starvation (bumping a process to the front of the round robin queue should it be starving), early Unix systems used a more subtle aging system, to slowly increase the priority of a starving process until it was executed, whereupon its priority would be reset to whatever it was before it started starving."

    (Hozzátenném: későbbi unix verziókban és implementációkban újabb megoldások születtek, de többnyire mindnek sajátja ez a dinamikus módosítás.)

    Itt nincs félreértés. Mint látod, dinamikusan állítja az OS a prioritást.

    Most az, hogy prioritásnak vagy nice-nak hívjuk, egy másik kérdés. Azt hiszem, a nice is a tulajdonképpeni prioritást állítja, csak korlátok között (magát a számot tekintve, illetve csak user processeké állítható, stb.). Mindenesetre általában nice-ként szokták emlegetni a unix-os prioritást, mivel user szinten az az.

    Ja, és még kérdezted, hogy jelzi a program, hogy átállíthatja-e az OS a prioritását. Nos, két módja is van. 1. különféle classok vannak, úgy mint realtime, time-sharing, fair-share, fixed-priority. Továbbá ezeken belül is beállíthatók bizonyos policy-k erre vonatkozólag (pl. átmenetileg).
  • dez #108
    Jahh, hogy már itt a végefelé...

    Nos azért számít az év, mert idő kell, amíg a felhasználók hiányolni kezdenek valamit. Talán nem is lehet az aktuális implementációt csak úgy megváltoztatni, de egy új eltérhet. Persze ha a gyártó nem figyel oda a részletekre, akkor neki mindegy.
  • BiroAndras #107
    "És? Két dolog van odaírva: 1. dinamikus prioritás-állítás az OS részéről, 2. pontosítás, miszerint unixon nem a prioritást, hanem a nice-t állítja át (mint később írtam, a prioritás helyett van a nice, ami nem teljesen ugyanaz)."

    1. Az OS nem állítja a nice-t.
    2. A nice nem a prioritás alparamétere, hanem tulajdonképpen a user által állítható prioritás.

    Itt le van írva a win és unix scheduler működés:
    http://en.wikipedia.org/wiki/Scheduling_(computing)
    http://www.cs.unt.edu/~jacob/classes/5640/notes/chapter5.html

    Jól látszik szerintem, hogy mit értettél félre.