A Sun segít majd az AMD-nek Opteront fejleszteni?

Címkék

Csak idő kérdése, hogy a Sun mikor fog az AMD segítségére lenni abban, hogy tovább fejlesszék az AMD vállalati környezetbe szánt Opteron processzorcsaládját. Egy riportereknek tartott beszéd alkalmával utalt arra David Yen, a Sun skálázható rendszerek csoportjának vezető alelnöke, hogy elképzelhető egy együttműködés a Sun és az AMD között, amelynek célja az Opteron processzorok jobbá tétele.

Az AMD szóvivőasszonya nem kommentálta, hogy a Sun milyen mértékben folyna bele az Opteron processzorok jövőbeli fejlesztéseibe, de azt elmondta, hogy a felek jelenleg is dolgoznak bizonyos technikai problémák megoldásán és a termékek promócióján.

A címben olvasható "hírnek" vajon mennyi a valóságtartama? Mivel a Sun egyik felelős pozícióban levő emberének szájából hangzottak el olyan kijelentések, amelyekből a News.com ezt vélte kihámozni azt mondhatnánk, hogy nagy. De mivel ismerjük a Sun nyilatkozó embereit, azt is mondhatnánk, hogy pletyka.

Mindenesetre ha valósággá válna a szövetség, azzal AMD valószínűleg csak nyerne. A Sun-nak nagy gyakorlata van a 64 bites processzorok fejlesztésében, és egyben továbbra is az egyik piaca lehetne lehetne a legyártott AMD porcesszoroknak.

A News.com cikke itt.

Hozzászólások

_Joel wrote:
> Azért cache-koherens multiprocesszoros SMP rendszereket építeni nem olyan
> egyszerű...
Hülye vagyok én ezekhez, mesélsz kicsit?

Miben jobb/más a Sun megközelítése, mint az AMD-é?

Az Opteron problémáiról és egy lehetséges megoldásról pld. itt lehet
olvasni: http://www.itjungle.com/tlb/tlb083104-story01.html

CPU és SMP mese:)

A problema ekvivalens mondjuk azzal, hogy ulsz otthon es papircetliken erkezo szamokkal vegzel muveleteket. Eloszor jon egy papircetli amin az van, hogy az 56345. papircetli erteket add hozza a 56346. papircetli ertekehez es az eredmenyt ird ra a 87345. papircetlire. A papircetlik egy toled 20 km-re levo varos konyvtaraban helyezkednek el, es motoros futarok rohangalnak veluk a ket varos kozott: kb 20 percet kell varnod arra, hogy egy lekert cetli masolataval ideerjen a user. Neked, mivel az altalanos iskolat elvegezted kb 20 masodpercedbe telik elvegezni a muveletet.(Persze ha ti egy szuperskalar csalad vagytok, akkor otthon a harom gyerek, es a muvelet elvegzeset is szepen felbontjatok tobb alfeladatra: pistike elolvassa a papirlapra irt sorszamokat, es utasitja a futart, hogy mar akkor induljon el a cetlikert amikor meg nem is tudod, hogy mit kell csinalni az adatokkal. Jozsika meg nagyon okos fiu: meg tudja becsulni, hogy az adott cetli utan melyik masik cetlin kell majd folytatni a vegrehajtast (ugyebar a feladatot jelento cetliket is a masik varosbol kell lekerdezgetni). A harmadik gyerek hozza a sort.)

Namost, a cache nem mas, mint a szomszedod, aki vallalta, hogy ha tobb doboznyi cetlit hoz a futar, akkor azt az o sufnijaban el lehet tarolni, es elso korben eleg hozza fordulnod, ha egy cetli kell: nem kell a motoros futart csesztetni ezzel. Ha nincs nala az adott cetli, majd o beszel a futarral, es kicsit lassabban, de leszallitja neked a kert cetlit (meg esetleg az osszes korulotte levo cetlit is, hatha szukseged lesz ra) . Igy eselyed van ra, hogy nem kell minden cetli utan negyedoras kenyszerszunetet tartani, mig megjon a kovetkezo cetli a kovetkezo feladattal, sot egesz jo kihasznaltsagot is el tudsz erni.

Mi tortenik, ha a ceg akinek dolgozol parhuzamositani akarja a feldolgozast es megbiz meg 1-3-5-10 tavmunkast ugyanebben a felallasban? Elkepzelheto, hogy a felesegedet meg lehet bulizni, hogy dolgozzon ezen otthon veled parhuzamosan: talan meg pistiket is tudjatok kozosen hasznalni bizonyos feladatokra: ezt hivhatjuk mondjuk multithreadingnek: egyetlen core-on (hazban) belul a vegrehajtoegysegek tobb szalon tudnak dolgozni egymas mellett. Elkepzelheto, hogy a szomszedod szomszedja vallalja a munkat, es ketten osztozhattok a cache-en (egyes dual core CPU-k igy csinaljak). Persze ha tul kicsi a szomszed sufnija, akkor ez akar gondot is okozhat.

Teljesen mas a kep, ha egy masik varosban dolgozo csaladdal es szomszedjaval kell egyuttmukodnotok. Innen kezdve a szomszedodnal tarolt adathalmaz tartalmazhat olyan cetlimasolatokat, amiknek a tartalma mar nem igaz: elkepzelheto, hogy a masik jomunkasember feldolgozas kozben atirta. Annak biztositasa, hogy az ilyen muvelet hatasara a szomszedod sufnijaban levo ugyanarra a cimre vonatkozo cetlimasolat eltunjon: na ez a cache koherencia. Alapvetoen meg lehet ugy valositani, hogy amikor egy cetlit atirsz, akkor nem csak a kozpontba kuldod vissza az uj erteket, hanem a cimet/erteket atkuldod az osszes tobbi kolleganak is. Erre mondjuk egy masik motoros futartarsasagot hasznalsz, es felallitasz egy protokollt, hogy a cetlik ertekenek lekerese es a modositott cetlik cimenek propagalasa ne zavarja egymast, ne johessen letre rossz allapot. Ahogy novekszik a CPU-k szama, ugy bonyolodik ez a protokoll...

Valaki másnak megvan az a 80-as évek elején kiadott gyerekkönyv ami a számítógépek működését ilyen gyerekmeseként írja le? Valami főpisták meg pista 1-2-ők tologatják benne a szekrényfiókokat és még főpista is csak összeadni tud...

_Joel wrote:
> CPU és SMP mese:)
> ne zavarja egymast, ne johessen letre rossz allapot. Ahogy novekszik a
> CPU-k szama, ugy bonyolodik ez a protokoll...
[...]
Fantasztikus apa leszel, képes leszel elmesélni az egész napodat otthon,
úgy, hogy még a karonülő is megértse. Őszinte tiszteletem (virtuális
kalapemelés) érte! :)

A cache koherencia fogalmával és problémájával a magam egysejtű szintjén
tisztában vagyok, ami nem világos az az, hogy a Sun és az AMD
megközelítése miben más.

Az Intelé ha jót olvastam az, hogy invalidálják a cache adott tartalmát,
az AMD-é inkább az, hogy tulajdonosa is van az adatoknak, így a másik
proci elkérheti a gyors hypertansporton (vagy tokon belül méggyorsabban) át.

És persze "hirdetik" a változásokat, a 8 processzor feletti extra
forgalom pedig kezd problémákat okozni, ezért erre a feladatra külön
áramköröket lehet betolni (erről szólt a cikk).

Mi a Sun megközelítés? Olvastam ilyenről, hogy snoop, meg directory és
hogy ezek a nagyobb vasakban kombinálva vannak.

Jelentősen más ez, mint az AMD-é mondjuk egy ilyen Horus chippel?

Ha egy proci egy ilyen "domainen" belül szemétkedik az adattal,
szétbroadcastolja domainen belül (vagy/plusz a fent említett chipnek), a
domainek között pedig valami egyéb, hatékonyabb algoritmussal "osztódik
az ész". :)

> Valaki másnak megvan az a 80-as évek elején kiadott gyerekkönyv ami a
> számítógépek működését ilyen gyerekmeseként írja le? Valami főpisták meg
> pista 1-2-ők tologatják benne a szekrényfiókokat és még főpista is csak
> összeadni tud...
Úristen. :)

Jovanna, egesz napos meetinghadjarat utan valahol le kell vezetni a kreativitast:)

Sun:

A FirePlane az, ami erdekes lehet:

http://www.sc2001.org/papers/pap.pap150.pdf

Horus: ez kicsit olyannak hangzik, mint ahogy a FirePlane ki lett terjesztve a 15K/25K platformokon (noha azt nem irja, hogy a Horusok hogy vannak osszekotve: gondolom a 15k/25k-hoz hasonloan full star osszekottetessel van ertelme). A fo kulonbseg talan az, hogy a nagy es draga Sun gepekben erre csak 24 CPU felett van/volt szukseg (de mondjuk ott is a 4 CPU-s board lett ilyen szervezesnel 1 cache koherens domain)... Mondjuk Sun eseten a ketfajta megkozelites ketfajta snooping protokollt is jelent.

(Erik biztos megkovez, ha ezt valaha elolvassa, de tenyleg reg volt, hogy en utoljara ilyesmivel foglalkoztam)

Amivel meg erdemes lehet osszehasonlitani, az a JBus. Ez a V210/240 es leszarmazottaiban hasznalt buszrendszer (UltraSPARC IIIi CPU-knal volt/van hasznalatos):

http://www.sun.com/processors/whitepapers/JBus_External.pdf

Ez max 4 CPU-ig "skalazodik". Ez is csomagkapcsolt, mint a FirePlane, de annal egyszerubb, alacsonyabb latency-ju, bar kisebb a savszelessege is (3.2 Gbyte/s).

A Sun kb 15 eve abbol el, hogy SMP rendszereket rak ossze, ugyhogy ha valamihez van know-how-ja, az az SMP buszrendszerek/cache koherencia protokollok tervezese. Mas kerdes, hogy a single CPU teljesitmeny manapsag eleg sokmindenre eleg, amihez meg csak par eve is 4-8 CPU-s masinak kellettek...

No, az a Gateway-es faszi nagyon felidegesitette a fel Sun blogger community-t. Mondjuk Craig (blogs.sun.com/thinguy) valasza eleg jo volt (o most amugyis hires lett a taliban unix parody-javal:).

Felvasarlasok:

- a SeeBeyond abszolute tuti maxi jo. Regota vartuk, es orulunk neki. Vegre egy normalis SOA platform, BPEL-lel, fejlesztoeszkozokkel, mindennel, ami egy vallalati integraciohoz elvarhato lenne Web Services temaban.

- StorageTek: naja. Az elemzok ezt vitatjak a legjobban. Who am I to blame them?

- Tarantella: az RDP technologia licencelesevel egyutt nem egy rossz vetel. Ami negativ: a Citrix azota kicsit huvosebb lett a Sun fele. Elvileg augusztus vegen lesz egy kis idom jatszani vele, meglatjuk...

Volt meg valami?

ZFS, Janus: maximalisan igazad van

blade szerver: ebben meg a Sun-nak volt igaza, hogy kivonta a pengejet:)

gagyi notebook: oem viszonteladasi szerzodes 2, alapvetoen nem mass marketre szant termekre vonatkozoan. Majd ha a HVG-bol olyan leaflet potyog, hogy pistike vegyen ilyen notebookot, akkor igazad van, hogy legagyizod).

"mondjuk az AMD gyartana a processzoraikat."

Kapaszkodj meg, a Sun SOHA nem gyartott CPU-t. Tervezni tervezett, de a gyartast soha nem o csinalta...

_Joel wrote:

> Valaki másnak megvan az a 80-as évek elején kiadott gyerekkönyv ami a számítógépek működését ilyen gyerekmeseként írja le? Valami főpisták meg pista 1-2-ők tologatják benne a szekrényfiókokat és még főpista is csak összeadni tud...

Erre gondolsz? :

Varga Tamas Jatszunk matematikat I - 2, 1976, 19Ft

A hetvegen lattam sogoromeknal, elokerult mert olyan idosek

a gyerekek, de csak 1 percre volt idom belenezni. Bar ezek inkabb munkafuzet jelleguek.

Ezek maradtak meg az emlekeimben:

primszamok kiszamitasa, Fibonacci sorozat, lyukkartya, kettes

szamrendszer.

_Joel wrote:
> http://www.sun.com/processors/whitepapers/JBus_External.pdf
Köszi, elolvasom őket.

> A Sun kb 15 eve abbol el, hogy SMP rendszereket rak ossze, ugyhogy ha
> valamihez van know-how-ja, az az SMP buszrendszerek/cache koherencia
> protokollok tervezese. Mas kerdes, hogy a single CPU teljesitmeny manapsag
> eleg sokmindenre eleg, amihez meg csak par eve is 4-8 CPU-s masinak
> kellettek...
No igen, ma már nem ritka, hogy egy jópár évvel ezelőtti
szuperszámítógép teljesítménye lehet az asztalomon.

Ja. Ötvözik a Niagarát és a Rockot az Opteronnal (Viagra és Spock lesz a kódnevük) és beköszönt az új világ. Opteron lesz nem csak a Sun low end, hanem a high end gépeiben is, amelyek a Javában írt Solaris 11-et futtatják CMT-vel, meg egyebekkel.

Az új platform neve sun4v helyett sun4o (mint Opteron) lesz? :)

Nem tartom kizartnak. A Sunban nem latok ujabban tartast. Ossze-vissza vasarolnak fel minden ceget (kicsit ugy tunik, hogy rendszertelenul, egyesek azon spekulalnak, hogy elkepzelheto, hogy a Gateway lesz a kovetkezo [www.technewsworld.com] felvasarlasuk), nincs szerintem normalis jovokepuk, a nagy hangon bejelentett technologiaik (Zettabyte FS, Janus) eveket csusznak, a blade szervert kivonjak, gagyi notebookot bejelentik (azt sem ok gyartjak). Azon sem csodalkoznek, ha egyszercsak bejelentenek, hogy teljesen befejezik a hardvergyartas vonalat es a jovoben mondjuk az AMD gyartana a processzoraikat.

>nincs szerintem normalis jovokepuk

minden egyes VP-nek sajat jovokepe van. a nagyfonok meg kockadobassal valasztja ki, hogy melyik nap eppen melyiket tamogatja:) VP-bol meg van vagy 15:)

egyaltalan nem erdemes arra figyelni mirol beszel a SUN.

sot mar az sem igazan erdekes amit a sok bejelentes kozul valojaban meg is csinalnak.(lasd pl. a laptop)

Kubinszky Ferenc wrote:
> Valoszinuleg ez lesz. Az uj AMD procik magja nagyon jol sikerult, ezt el
> kell ismerni. Multiprocesszoros kornyezetben (n>4) viszont nem kielegito ez
> a hypertransport megoldas, de a SUN ebben azert profi.
Na de miért is? Ha jól sejtem betehetnének egy hypertransport switchet
is és arra akaszthatnák a memóriát és a procikat, így pedig
gyakorlatilag akárhány processzorig bővíthető a rendszer, a sebesség
jelentősebb csökkenése nélkül. Persze optimalizálni kell rá, de a
sávszélesség meglenne.