[special]

Az Intel a jövõben a következõ taktikát fogja követni:

single die x-core@y node ---> dual die 2x core@y node ---> single die 2x core@y node --->single die 2x core@y+1 node ---> dual die 4x core@y+1 node

azaz

kétmagos chip@65nm ---> négy mag MCP@65nm --> négymagos chip@65nm-->négymagos chip@45nm--->nyolc mag MCP@45nm--->nyolcmagos chip@45nm

[Zollka]

Idézet: hvuk - Dátum: 2006. jan. 28., szombat - 18:24

Véleményem szerint az AMD elõrébb jár a hatékony 4 magos processzorok tervezésében, mint az Intel. Szerintem kb. fél év elõnye lesz a megjelnést tekintve. Még egyszer: itt a hatékony architektúráról beszélek,  tehát nem a Paxville-féle presztizsfoltozó megoldásokra gondolok. Persze lehet, hogy a Merom és deriváltjai már quad-core ready-k helybõl és gyakorlatilag semmiféle komoly fejlesztésre nincs szükség a piacra dobáshoz, de az is lehet, hogy sok gondot meg kell oldani. A kérdés az, hogy az AMD meg tudja-e részben õrizni a kb. 1 éves megszerzett elõnyét vagy elolvad a 4 magos processzorokra (teljesen biztos nem tudja, hiszen az egy évi elõny biztos nem tartható). Most persze végig a szerver processzorokról beszéltem, mielõtt valaki még félreérti a szavaimat. Desktopon 2008-ig nem lesz nagy jelentõsége a quad-core processzoroknak.

Minden azon múlik a Woodcrest és társai mit tudnak...Ha ütnek dualban,akkor még a szerver piacon a quad chipes AMD procik üthetik õket bõségesen teljesítményben...Node a másik kérdés az ,hogy mennyire van a Woodcrest technológiailag felkészítve 4 magra és ha fel is van készítve milyen hatékonyan...Ettõl függ totálisan az ,hogy az AMD elõnye mennyire csappan meg...Vagy nõ??? Akár ez is lehet a legrosszabb (vagy legjobb ,melyik oladlról nézzük ) esetben...Azért azt se feledjük el ,hogy az Intel 65 nanoval nagyon jó eredményeket ért el a DC P4-ek esetében is...Lehet ,hogy az AMD-nek SOI mellett 65 nanon magonként 2,4Ghz-es Opteronok jönnek majd össze...Végülis most a max. TDP 120 wattra fog nõni az új socketeknél...Ebben 4 darab 30 wattos proci fér kb. (jó ez nagyon sarkítva van de kb )...

Szal kérdéses is ,hogy 30 watt TDP-be milyen single core opteron férne bele 65 nanon...A Bladekben asszem vannak hasonló TDP-jû opteronok ,azok mekkora órajelûek így most 90 nanon???

[SFIJ]

Idézet: hvuk - Dátum: 2006. jan. 28., szombat - 18:19

Jó, persze nyilván kérdés, hogy az egyedi alkalmazásokról beszélsz-e, tehát a nagyjából "játék" kategóriáról vagy a komoly programokról. MySQL vagy DB2? Ugye nem kell magyaráznom, hogy melyik hogyan skálázódik? SAÕ, Oracle Finance, Baan vagy valamelyik kis cég által egy szûk piacra készített terméke? Ugye itt sem kell részletes tesztelést és elemzést végeznem? Itt nyilván nem a kis fejlesztõk, meg az opensource ellen beszélek (márcsak a Linux miatt sem tehetném, hiszen az elég jól skálázódik, legalábbis MS mércével ), nyilván a kis cégeknek, illetve általában az opensource közösségeknek kevesebb az erõforrásuk, mint az IBM-nek, meg esetleg kevésbé is törõdnek vele.

Ettõl függetlenül abban igazad van, hogy a párhuzamos programozás technikájának elterjesztéséért a játékprogramozás fog nagyon sokat tenni, emiatt lesz a hatékony programozás elterjedt és "közkincs". Illetve ez nem a játékpiacnak lesz köszönhetõ, hanem annak, hogy az Intel nem tudta 4 GHz felé növelni a P4 órajelét.

mysql, db2, oracle, sybase skálázódásban és teljesítményben iszonyat elmarad attól, mit ameri egy mai dc/mt processzor képes.  a kraft felét ha hozzák. baan és sap meg a többi midleware meg alaphangon ront csak a dolgon. nem viccelek. ezek nem "vérbei" MT appok, ami valahol logikus is maint az AB-k lockolásait, pre-prostcheck-jeit és tranzakcióit nézzük. nem véletlen, hogy bengaállat gép kell, még kicsi 100-200-as user base esetén is.

hogy értsd mirõl beszélek. a világ léegdúrvább adabázisait az internet core routerekben találod: tipikus méret 400-600 ezer routing decision record. ebben keres a kincsem úgy, hogy max 10-15 ms delayt szenved a TCP csomag 1 hop alkalmával. A cuccban van tipikusan 8-16 db PPC405 processzor. Na ehhez mérd a  SAP, Oracle Finance, Baan, mysql, oracle, db2, postgres, sybase hatékonyságát és teljesítményét. Jaaa, hogy a cisco meg a juniper tud rendes masszívan parallel és lineáriasn (kártyánként) skálázódó szoffert írni? hogy mik nincsenek?

Szerkesztette: SFIJ 2006. 01. 28. 19:59 -kor

[Haderach]

Idézet: SFIJ - Dátum: 2006. jan. 28., szombat - 19:52

hogy értsd mirõl beszélek. a világ léegdúrvább adabázisait az internet core routerekben találod: tipikus méret 400-600 ezer routing decision record. ebben keres a kincsem úgy, hogy max 10-15 ms delayt szenved a TCP csomag 1 hop alkalmával. A cuccban van tipikusan 8-16 db PPC405 processzor. Na ehhez mérd a  SAP, Oracle Finance, Baan, mysql, oracle, db2, postgres, sybase hatékonyságát és teljesítményét. Jaaa, hogy a cisco meg a juniper tud rendes masszívan parallel és lineáriasn (kártyánként) skálázódó szoffert írni? hogy mik nincsenek?

  azert ez egy kis ferdites, egy specialis celu szoftvert es hardvaert (amely tervezesenel kvazi a semmisemdraga nezet uralkodott) hasonlitasz ossze altalanos celu szoftverekkel, amelynek a feature-listajat is boviteni kell ket relasi kozott, nem csak a sebessegen javitani, raadasul multiplatformnak is kell lenni, atlag hulye programozo szamara is erthetoen kell mukodnie, es hulyeusert kell felteteleznie, akinek a parancsain meg lehet optimlaizalni...

[SFIJ]

Idézet: Haderach - Dátum: 2006. jan. 28., szombat - 20:39

  azert ez egy kis ferdites, egy specialis celu szoftvert es hardvaert (amely tervezesenel kvazi a semmisemdraga nezet uralkodott) hasonlitasz ossze altalanos celu szoftverekkel, amelynek a feature-listajat is boviteni kell ket relasi kozott, nem csak a sebessegen javitani, raadasul multiplatformnak is kell lenni, atlag hulye programozo szamara is erthetoen kell mukodnie, es hulyeusert kell felteteleznie, akinek a parancsain meg lehet optimlaizalni...

Haderach nézheted így is, meg úgyis,hogy ésszel tervezett informatikai rencer hogyan teljesít egy szuboptimális tömegszoferrel szemben amit telepakolank buzwordökkel és úgy csinálják meg, hogy valóban, még hülyék is tudják programozni   De amúgy igzad van: az egyik rendszert nagytudású szakemberek készítik a másikat meg "jómunkásemberek" órabérben.

[hvuk]

Idézet: SFIJ - Dátum: 2006. jan. 28., szombat - 19:52

mysql, db2, oracle, sybase skálázódásban és teljesítményben iszonyat elmarad attól, mit ameri egy mai dc/mt processzor képes.  a kraft felét ha hozzák. baan és sap meg a többi midleware meg alaphangon ront csak a dolgon. nem viccelek. ezek nem "vérbei" MT appok, ami valahol logikus is maint az AB-k lockolásait, pre-prostcheck-jeit és tranzakcióit nézzük. nem véletlen, hogy bengaállat gép kell, még kicsi 100-200-as user base esetén is.

hogy értsd mirõl beszélek. a világ léegdúrvább adabázisait az internet core routerekben találod: tipikus méret 400-600 ezer routing decision record. ebben keres a kincsem úgy, hogy max 10-15 ms delayt szenved a TCP csomag 1 hop alkalmával. A cuccban van tipikusan 8-16 db PPC405 processzor. Na ehhez mérd a  SAP, Oracle Finance, Baan, mysql, oracle, db2, postgres, sybase hatékonyságát és teljesítményét. Jaaa, hogy a cisco meg a juniper tud rendes masszívan parallel és lineáriasn (kártyánként) skálázódó szoffert írni? hogy mik nincsenek?

Az oké, hogy az új processzorral ezek a rendszerek nem 100%-ban skálázódnak, de a kódméret és bonyolultság sem összemérhetõ. A routerek progijai néhány megabájtosak lehetnek (erõs felsõ becslés, inkább néhány száz kilobyte tartományban lehetnek), ezek a rendszerek meg (DB2, SAP, Oracle, ...) néhány száz megabájtosak. Alsó hangon. A másik, hogy - amirõl Haderach is írt -, hogy az elõbbiek nagyon specializáltak, utóbbiak meg nagyon általánosak. Mind funkcióikat, mind futási környezetüket tekintve. Innentõl gondolom nem kel tovább ragoznom a dolgot.

A másik, hogy ezek azok amik a tipikusak. Ezek azok, ameddig érdemes elmenni -  a spéci eseteket, mint az általad hozott router leszámítva -, innentõl a hatékonyságnövekedés és a ráfordított költség nem áll egymással összhangban. Ha 10%-al jobb skálázódást akarsz, akkor az dupla vagy akár még több pénzt igényel (a fejlesztési idõrõl nem is beszélve!). Na, ezen a játékok nem fognak javítani semmit sem. Azon fognak, hogy a desktop/WS programok is eljutnak arra a szintre, ahol jelenleg az ilyen szerver programok vannak. E fölé nem, legalábbis addig nem, amíg ésszerû ráfordítással ennél jobb nem készíthetõ. És még ennek az elõrelépésnek is csoválni fogjuk a farkunkat!

Magyarán a játékoknak a jelenlegi tudás elterjesztésében lesz nagy szerepük, nem pedig új tudás kialakulásában. A szerverprogramokra a hatásuk elhanyagolható lesz, a hatásuk abban fog megmutatkozni, hogy a programozók széles köre fogja ezeket a technikákat elsajátítani.

Még egy dolog. Ugyanúgy, ahogy egy általános alkalmazás az órajellel sem skálázódik lineárisan (noha megtehetné általában), ugyanígy a processzorok számával sem teszi. Ez már csak így van a számítástechnikában, nem tökéletes programokat akarunk létrehozni, hanem megfelelõen jó programokat. A tökéletes programok túl drágák lennének és túl hosszú ideig tartana a fejlesztésük. Az evolúció sem ezt az elvet követi és az ésszerûség sem ezt diktálja. A megfelelõen jó program alatt persze nem a Windows 3.1-et vagy egy mai bugos játékprogramot értek.

Szerkesztette: hvuk 2006. 01. 29. 00:42 -kor

[Michell]

Idézet: hvuk - Dátum: 2006. jan. 28., szombat - 23:38

1. ezek a rendszerek meg (DB2, SAP, Oracle, ...) néhány száz megabájtosak. Alsó hangon.  Innentõl gondolom nem kel tovább ragoznom a dolgot.

2. A másik, hogy ezek azok amik a tipikusak. Ezek azok, ameddig érdemes elmenni - ... - innentõl a hatékonyságnövekedés és a ráfordított költség nem áll egymással összhangban. Ha 10%-al jobb skálázódást akarsz, akkor az dupla vagy akár még több pénzt igényel (a fejlesztési idõrõl nem is beszélve!). Na, ezen a játékok nem fognak javítani semmit sem. Azon fognak, hogy a desktop/WS programok is eljutnak arra a szintre, ahol jelenleg az ilyen szerver programok vannak.

3. Magyarán a játékoknak a jelenlegi tudás elterjesztésében lesz nagy szerepük, nem pedig új tudás kialakulásában. A szerverprogramokra a hatásuk elhanyagolható lesz, a hatásuk abban fog megmutatkozni, hogy a programozók széles köre fogja ezeket a technikákat elsajátítani.

1. Ebben a kérdéskõrben SFIJ-jel értek egyet, majdnem teljesen (kivéve a multiplatform ... következményeit). Persze sokszáz megabájt, de abból mennyi a csilivili, a "nélkülözhetetlen új ficsör" - kedvenc DB-mhez átlagosan évente készül új GUI - egyik jobb mint a másik. A teljesitményváltozás pedig nemhogy lineáris, hanem lassan a 15%-ot sem éri el. Aztán sírnak, hogy a DB üzletág nem hoz elég bevételnövekedést.

Bug-ok : Még ma is a múlt héten végigrágott buglisták hosszától látok csillagokat. Hogy azokat a csodajavaslatokat pl. "hogy nem indul el automatikusan : Closed, No bug - indítsd kézzel" már ne is szedjem elõ.

2. Egyszerûen a fentiek kapnak erõforrást, a többit majd a Mega HW megoldja.

3. Ebben sem teljesen értek egyet. Persze nem új tudást hoznak majd létre a Gámák (hacsak nagyon spec. területen nem), de így a jómunkásembereket jóval szélesebb körbõl, illetve gyakorlati - és válaszidõ érzékeny területen szerzett - alapismeretekkel lehet majd találni.
Ez szvsz - ha nem is rövid idõ alatt - egyáltalán nem elhanyagolható hatású lesz.

[hvuk]

Idézet: Michell - Dátum: 2006. jan. 29., vasárnap - 11:32

1. Ebben a kérdéskõrben SFIJ-jel értek egyet, majdnem teljesen (kivéve a multiplatform ... következményeit). Persze sokszáz megabájt, de abból mennyi a csilivili, a "nélkülözhetetlen új ficsör" - kedvenc DB-mhez átlagosan évente készül új GUI - egyik jobb mint a másik. A teljesitményváltozás pedig nemhogy lineáris, hanem lassan a 15%-ot sem éri el. Aztán sírnak, hogy a DB üzletág nem hoz elég bevételnövekedést.
...
2. Egyszerûen a fentiek kapnak erõforrást, a többit majd a Mega HW megoldja.

Ez egyszerûen nem igaz. Lásd például ezt az Anandtech tesztet, ahol a DB2 70-80%-al skálázódott a 2->4 magra növelésnél. Nem szabad elfelejteni, hogy itt kõkeményén van háttéttárhoz fordulás, míg a routerek esetén ilyen nincs. Nyilván komolyabb tesztet kellene találni, de egyelõre ez van. Én legalább hoztam bizonyítékot.

A másik ok, hogy ez miért nem igaz az, hogy több évtizede fejlesztenek többprocesszoros gépekre adatbáziskezelõket. Hülyeség azt állítani, hogy nem koncentráltak a jobb multitaszkúságra, amikor is a konkurenciánál lényegesen jobb skálázódás hatalmas piaci elõnyt jelent (jelentene). Ami nagyon gyorsan átfordítódna hatalmas mennyiségû pénzre. Tehát, ha meg lehetne csinálni normális mennyiségû erõforrással a jelenleginél lényegesen jobb skálázódást, már régen megcsinálták volna. Persze ott van még az a verzió, hogy hatalmas összeesküvés van az adatbázisgyártók, meg a hardvercégek között és direkt nem gyárt (nem gyárthat) senki jobban skálázódó adatbáziskezelõt. De ennek elfogadásától már egyenes út vezet oda, hogy az Intel az 1950 körül lezuhant UFO-k elektronikájának visszafejtésébõl készíti a processzorait.

Idézet

3. Ebben sem teljesen értek egyet. Persze nem új tudást hoznak majd létre a Gámák (hacsak nagyon spec. területen nem), de így a jómunkásembereket jóval szélesebb körbõl, illetve gyakorlati - és válaszidõ érzékeny területen szerzett - alapismeretekkel lehet majd találni.
Ez szvsz - ha nem is rövid idõ alatt - egyáltalán nem elhanyagolható hatású lesz.

Persze, ez is biztos hatással lesz rá. Csak azt akartam mondani, hogy nehogy már azt higgyük, hogy a játékprogramozás fogja a passzát szelet fingani! A legnagyobb hatása továbbra is a párhuzamos programozás gyakorlati elterjesztésében látom, amivel persze triviálisan fejlõdés is a velejárója lesz, hiszen ha hirtelen 5x annyi ember ért valamihez, ott nem csak mennyiségi, hanem minõségi fejlõdés is be fog következni.

[SFIJ]

Idézet: hvuk - Dátum: 2006. jan. 29., vasárnap - 13:16

Ez egyszerûen nem igaz. Lásd például ezt az Anandtech tesztet, ahol a DB2 70-80%-al skálázódott a a) 2->4 magra növelésnél. Nem szabad elfelejteni, hogy itt kõkeményén van háttéttárhoz fordulás, míg a routerek esetén ilyen nincs. Nyilván komolyabb tesztet kellene találni, de egyelõre ez van. Én legalább hoztam bizonyítékot.

b) A másik ok, hogy ez miért nem igaz az, hogy több évtizede fejlesztenek többprocesszoros gépekre adatbáziskezelõket. Hülyeség azt állítani, hogy nem koncentráltak a jobb multitaszkúságra, amikor is a konkurenciánál lényegesen jobb skálázódás hatalmas piaci elõnyt jelent (jelentene). Ami nagyon gyorsan átfordítódna hatalmas mennyiségû pénzre. Tehát, ha meg lehetne csinálni normális mennyiségû erõforrással a jelenleginél lényegesen jobb skálázódást, már régen megcsinálták volna. Persze ott van még az a verzió, hogy hatalmas összeesküvés van az adatbázisgyártók, meg a hardvercégek között és direkt nem gyárt (nem gyárthat) senki jobban skálázódó adatbáziskezelõt. De ennek elfogadásától már egyenes út vezet oda, hogy az Intel az 1950 körül lezuhant UFO-k elektronikájának visszafejtésébõl készíti a processzorait.


c)Persze, ez is biztos hatással lesz rá. Csak azt akartam mondani, hogy nehogy már azt higgyük, hogy a játékprogramozás fogja a passzát szelet fingani! A legnagyobb hatása továbbra is a párhuzamos programozás gyakorlati elterjesztésében látom, amivel persze triviálisan fejlõdés is a velejárója lesz, hiszen ha hirtelen 5x annyi ember ért valamihez, ott nem csak mennyiségi, hanem minõségi fejlõdés is be fog következni.

a) ennek az az oka, hogy kódszinten büzmölték meg a "4magos" mûködést. rúternél ninncsenek sweet spotok. berakod az új kártyát és megvan a garantált kapacbövés. DB2 esetben éredmes megnézni a hárommagos eredményeket, meg a 6 és 8 magosakat nem skálázódik oly gyönyörûen mint a 2-4 esetben

b) adatbáziskezelõknél az evictor pattern-t használják, vagyis connection poolokat. ez elsõ ránézésre gyönyörû, ellenben a nagyocska kódméret és segédadatkupac miatt- ac cpuszám növése elöbb utóbb cache trashingre vezet.

c) technológiai szempontbol a gaming fujja a passzátszelet, mertha a nempc ágat nézzük, keményen motiváltak a gaming szektorban az utolsó kis flopsot is kicsavarni a rendszerbõl. üzleti szoft esetében ezmég nem számottevõ, ott a ficsorlisten van a hangsúly.

[Zollka]

Idézet: SFIJ - Dátum: 2006. jan. 29., vasárnap - 15:19

a) ennek az az oka, hogy kódszinten büzmölték meg a "4magos" mûködést. rúternél ninncsenek sweet spotok. berakod az új kártyát és megvan a garantált kapacbövés. DB2 esetben éredmes megnézni a hárommagos eredményeket, meg a 6 és 8 magosakat nem skálázódik oly gyönyörûen mint a 2-4 esetben

b) adatbáziskezelõknél az evictor pattern-t használják, vagyis connection poolokat. ez elsõ ránézésre gyönyörû, ellenben a nagyocska kódméret és segédadatkupac miatt- ac cpuszám növése elöbb utóbb cache trashingre vezet.

c) technológiai szempontbol a gaming fujja a passzátszelet, mertha a nempc ágat nézzük, keményen motiváltak a gaming szektorban az utolsó kis flopsot is kicsavarni a rendszerbõl. üzleti szoft esetében ezmég nem számottevõ, ott a ficsorlisten van a hangsúly.

Ez eleve meddõ vita...Van program ami kamatozik belõle van ami nem igazán...
Szerintem a render farmok biztosan meg fogják venni a 4 magos procikat...
Arról nem is beszélve ,hogy ha nem lenne most sem teljesítméy növekedés bizonyos területeken akkor az AMD-nek sem mennének úgy az opteronok...

Egyébként meg aki otthon WS-ön tervezget annak sem jön rosszúl 4 mag...
Szal a területe meglesz a 4 magos prociknak is ne mi akarjuk megkeresni

[SFIJ]

Idézet: Zollka - Dátum: 2006. jan. 29., vasárnap - 15:33

Ez eleve meddõ vita...Van program ami kamatozik belõle van ami nem igazán...

a baj csak az, hogy több az olyan program, ami nem kamatozik belõle. és ezek között a CPU intenzív programok is elég sokan vannak. a DC QC procikkal az lészen majd a bibi, hogy az emberek többsége azt fogja tapasztalni, hogy semmi érezhetõ nyeresége nincs a DC, QC procik miatt, azt az egyet leszámítva, hogy egy CPU intenzív proggi kevésbé fogja le a "desktop"-ot...

[bogdan]

Idézet: special - Dátum: 2006. jan. 28., szombat - 20:17

Az Intel a jövõben a következõ taktikát fogja követni: [...]

kétmagos chip@65nm ---> négy mag MCP@65nm --> négymagos chip@65nm-->négymagos chip@45nm--->nyolc mag MCP@45nm--->nyolcmagos chip@45nm

szepen nez ki. a kerdes viszont az, hogy tudja-e tartani ertelmesen! es most nem kotozkodesbol mondom, de azert meg kene nezni egy-ket dolgot. az AMD (mint lattuk a SC->DC atallasbol) szepen megtervezte a processzorat jol bovithetove. az execution layer kozos hasznalataval szep huszarvagassal megoldotta azt a problemat, amit az Intel tancol mostanaban korul. az egychippes Intel processzor nagyon durva megoldas, es nagyon fugg az FSB-tol (bar ketsegkivul nagyon jo aron gyarthato, ezert pirospont jar az Intelnek!) a 4 core egychippes vajon hogy fog a kozos FSB-re reagalni? hat nem fogadnek ra a lovin.. Te igen?

a kozos cache megoldas termeszetesen nagyon szep eredmeny! SOKKAL fejlettebb technologia, mint az AMD-e. ugy tunik gyakorlatilag mindenben jobb. tenyleg. de mi lesz, ha 4 core-t rakunk egy cache-re? remlik a Niagara cache kesleltetese? reszben a 8 core miatt?? nos itt erhetik meglepetesek a varakozokat!! (szemben az AMD jelenlegi megoldasaval, ahol ebbol sokkal kevesebb gond lehet.)

vegul: a _fejletlenebb_ gyartastechnologia miatt (nincs SOI) a 65 nano-n a 4 core nem nagyon foghat menni. persze ez csak tipp, de ezt is figyelembe kene venni. (olyan Paxwilles lenne a dolog: inkabb ne is lett volna.) ha ez igy lenne, akkor a 4 core chip 45 nanon varhato legkorabban.

mindezeket elgondolkodtatonak irtam, es csak otleteles, velemeny. lehet maskepp is. de gondolkodni talan erdemes rajta.

[bogdan]

arrol, hogy kell-e a 4 core: persze, mindenki minel tobbet akar egyszerre. akar van hozza soft, akar nincs.

de komolyra forditva: termeszetesen a jatekok igen eros meghatarozo ero. viszont aki nem jatszik (azert ezekbol is van egypar..) azokank a ws oldal szamit sokat, es az ottani programok. es valo igaz, hogy ott is meg eros az elmaradas (bar folyamatos a fejlodes), de mire ezek jonnek szerintem mar elegge egyeduralkodo lehet a tobbszalu ws programok hada. annak meg jol fog jonni a 4 core, meg ha nem is skalazodik olyan szepen.

d n.r-el beszeltunk regebben arrol, hogy tulajdonkeppen az emberek gepenek a sebesseget 1, max 2 program hatarozza meg: amit gyakran hasznal, es nagyon sokaig fut. ha ezek csak egy kisse is skalazodnak, akor a tobbi mar alig erdekes. ez viszont mar igen kozel van!

(a szerver kerdesben hvuk-al kell egyetertsek: ha olcsobb es jobban skalazodik a tobbmagos processzor mint ha sok socket rendszert epitenek, akkor nem az a kerdes, hogy mennyire skalazodik. venni fogjak, oszt kesz. persze szomoru a jelenlegi hozzaallas, de ez van, ez egy masik problema.)

[special]

Idézet: bogdan - Dátum: 2006. jan. 29., vasárnap - 23:36

vegul: a _fejletlenebb_ gyartastechnologia miatt (nincs SOI)

 

Figy, én simán elhiszem neked, hogy fejlettebb az AMD 65 nanos processe az Intel P1266-nál, csak készíts már egyszer egy összehasonlítást, valós paraméterekkel, légyszi. Kezdésnek nem lenne rossz a tranzisztortípusok aktív és inaktív, szivárgási paramétereinek az összehasonlítása. De nem kell, csak ne tegyél ilyen kijelentéseket. Ráadásul kihangsúlyozva.

A multi-chip megoldásnak több elõnye is van:

-- rövidebb time-to-market idõ adott erõforrásokból, ugyanis "mindössze" a tokozó csapatnak kell megalkotnia a megoldást.
-- gyártási rugalmasság: a magokat tetszés szerint kombinálhatja az Intel a waferek közötti process varianciát kiegyensúlyozva, valamint az esetleg hibás lapkák sem jelentik még másik két mag elpazarlását. ez rendkívül megdobhatja az effektív yieldet, nem beszélve a rugalmas kínálatról. nehéz megbecsülni, de százmilliós, ha nem milliárdos nagyságrendû megtakarítás ez a kék saroknak.
-- ez idõ alatt egy csapat nyugodtan megtervezheti az egy lapkára integrálást, majd az implementáció egy kiismert, érett processre történik. alacsonyabb kockázat. ezt követõen egy jól kezelt, finomított chip kerül nextgen processre késõbb.

A hátrány nyilvánvalóan az, hogy a két lapka a busz sebességével kommunikál egymással, és két loadként jelenik meg a buszon.

Az MCP megoldással lényegesen kevesebb izzadsággal lesznek képesek 4 magos processzorokat kihozni, ugyanis lehetõségük nyílik majd arra, hogy a legenergiahatékonyabb darabokat egy tokba rakva jó órajelen a TDP-n belül maradjanak.

Szerkesztette: special 2006. 01. 30. 00:15 -kor

[bogdan]

bocsanat, nem hangsuly akart lenni, csak kiemeles. nem en talaltam ki, hogy fejlettebb, nem ertek hozza annyira, hogy magam tudjak utanajarni. egyszeruen elhiszem masoknak. Te is a masok kozott vagy, de masok is. ilyenkor az ember valamilyen metodus szerint dont, hogy kinek higgyen. itt nem neked hiszek. ennyi. vedd egyszeruen "ha igaz, hogy" formulanak, es ertelmezd ugy.

a MCP kerdeskorben semmi, de semmi vita nincs kozottunk. pontosan ezek az elonyei, erre kivantam utalni a nagy pirosponttal! a kerdes az, hogy az FSB problematika nem no-e a nyakara egy ilyen lepesnek. en csakis ezt boncolgattam. termeszetesen allast is foglaltam, de mint irtam nem elvszeruen, csak velemenykent.

[hvuk]

A SPEC honlapján megjelentek az elsõ Core Duo int/fp eredmények. A gép egy Lenovo Thinkpad volt T2600-as processzorral (2.167 GHz) és az Intel végezte a tesztelést. A SPECintrate result 34.9, a SPECfprate result 27.3 lett. Elõbbi az Opteron 275 eredményével kb. azonos, azaz clock-to-clock kb. ugyanazt tudják, utóbbi azonban még a 2.8 GHz-es Paxville-nál is gyengébb, a 275-nél pedig nagyon, mert az 36.3-at teljesít, azaz FP-ben kerek 50%-al jobb az Opteron.

Látszik, hogy a Sossamant nem a lebegõpontos egységet intenzíven használó gépekbe szánják. Tényleg, megjelent már a Sossaman? Semmit sem hallani róla.

[bogdan]

ezen most csodalkozol ezutan az eredmeny utan? (bocs a vaskos trefaert..) (persze 64 bit nelkul nem tudom mire jo az egesz..)

egyebkent tudunk arrol valamit, hogy a Conroe es tarsai hova varhatoak lebegopontos teljesitmenyben? (tudom, tudom, meg azt sem tudjuk, milyen orajelen lehetnek, de megis!)

[hvuk]

Az SGI szánalmas pénzügyi adatokról számolt be. Mert sajnos azt, hogy egy negyedév alatt 170-rõl 144 millióra csökkentek a bevételeknek, mindezt úgy, hogy a szezonális hatás miatt nõni kellett volna, máshogy nem lehet nevezni. Okát nem tudom, de van egy olyan érzésem, hogy a Montecito halasztása hozzájárult a bevételcsökkenéshez. Persze ha náluk ekkora csökkenés volt, akkor vélhetõleg máshol sem lesznek túl rózsásak az eladások alakulása (bár a HP Itanium üzletága azért biztos jobban teljesít). Érdekes a dologban, hogy az SGI épp õsszel mutatott be egy új szervercsaládot és még ez sem volt képes növelni a bevételt. Kár a cégért, mert az már látszik, hogy ez már a vég.

Idézet

Silicon Graphics (OTC: SGID) today announced results for its second fiscal quarter which ended December 30, 2005.

Revenue for the second quarter fiscal year 2006 was $144 million, gross margin was 41.7% and the operating loss was $28 million. For comparison, in the first quarter FY06, revenue was $170 million, gross margin was 37.8% and the operating loss was $26 million. The second quarter fiscal year 2006 net loss was $30 million or $0.11 per share, compared with a net loss of $32 million or $0.12 per share in the previous quarter.

Szerkesztette: hvuk 2006. 02. 03. 11:25 -kor

[Asker]

Idézet: bogdan - Dátum: 2006. Feb. 3., Friday - 10:09

ezen most csodalkozol ezutan az eredmeny utan? (bocs a vaskos trefaert..) (persze 64 bit nelkul nem tudom mire jo az egesz..)

egyebkent tudunk arrol valamit, hogy a Conroe es tarsai hova varhatoak lebegopontos teljesitmenyben? (tudom, tudom, meg azt sem tudjuk, milyen orajelen lehetnek, de megis!)

Nesztek

Szerkesztette: Asker 2006. 02. 03. 11:55 -kor

[hvuk]

Összehasonlításképpen tavaly ugyenebben a negyedévben az SGI forgalma 229 millió volt, ami 175 millióról nõtt egy negyedév alatt ennyire. Jól látszik, hogy a tavalyi - vélhetõleg a Madison 9M-nek is köszönhetõ - Itanium eladások megugrása milyen jól látszott az SGI forgalmán. Tavaly 30%-os növekedés az elõzõ negyedévrõl, idén 15%-os csökkenés.

Tényleg érdekes lesz az Itanium forgalmának alakulásáról a jelentés, vajon csak az SGI volt ilyen gyenge és máshol egészségesen nõttek a bevételek vagy pedig mindenkire jellemzõ volt a megtorpanás.