SG.hu·

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.

Kapcsolódó cikkek és linkek

Hozzászólások

Jelentkezz be a hozzászóláshoz.

© dez2006. 09. 29.. 17:47||#116
Épp ezért csak magasabb jogokkal használható, asszem.
© BiroAndras2006. 09. 29.. 12:15||#115
Érdekes. Ezek szerint elég idõnként meghívnom a setpriority-t, és máris legyõztem a scheduler-t.
© dez2006. 09. 28.. 22:59||#114
"A felhasználó szempontjából a nice megfelel a win-es prioritásnak."

Egyébként ez sem igaz így, de mindegy.
© dez2006. 09. 28.. 19:53||#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.
© BiroAndras2006. 09. 28.. 12:27||#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.
© dez2006. 09. 27.. 18:26||#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.
© BiroAndras2006. 09. 26.. 14:14||#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.
© dez2006. 09. 25.. 19:45||#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).
© dez2006. 09. 25.. 18:38||#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.
© BiroAndras2006. 09. 25.. 14:57||#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.