Opteron 252 nabij: duikt op in prijslijsten en aankondigingen

De lancering van de Opteron x52-serie van AMD, met name de Opteron 252, is zeer nabij, als we de voortekenen mogen geloven. Bij een aantal internetwinkels, waaronder deze, is de Opteron 252 al in de prijslijst verschenen, al is de processor natuurlijk nog niet voorradig. Bij deze webshop bedraagt de prijs 894,73 dollar. Hier zal de prijs waarschijnlijk tussen 830 en 900 euro schommelen. Eerdere berichten vermelden 14 februari als introductiedatum voor de nieuwe Opterons. Nog volgens de berichten zou de Opteron 250 meteen ook in prijs verlaagd worden en zou de Opteron 252 op het huidige prijsniveau van de Opteron 250 komen.

Meer aanwijzingen voor een aankomende introductie van de Opteron x52 zijn te vinden bij Linux World. Deze beurs gaat van start op 14 februari in Boston. Bij de genomineerden voor de productawards in de categorie 'innovatiefste hardware' vinden we de Opteron x52. Ook bieden sommige systeembouwers al servers en workstations aan op basis van de Opteron 252. Hier vinden we een systeem met de Opteron 252 als mogelijke cpu.

Reacties (28)

[Verwijderd]

Waar doen ze zo moeilijk over, weer 200Mhz erbij..

Ben benieuwd hoe ze die dual core versies gaan noemen, 252, 452 en 1652 ofzo...

[Olaf van der Spek]

Waar doen ze zo moeilijk over, weer 200Mhz erbij..

Tegen salarisverhoging van 8 % zeg jij ook nee?

[Verwijderd]

Moet je er meer dan 8% harder voor werken ?

[Verwijderd]

gevonden, de enige wekende ambtenaar op tweakers.net

[sweetdude]

Het eerste cijfer bij de cpu benaming van AMD is met hoeveel broertjes hij tegelijk wil spelen. De 1xx serie is voor single optron systeempjes (enigs kind) 2xx is een tweeling dus die mag met met een broertje op 1 bordje spelen. 8xx serie is voor de quad bordjes en hoger (de gezellige jongens).

[Verwijderd]

252 gaat moelijk he, aangezien er al eentje is die zo heet

[SleutelMan]

De dual-core processors krijgen waarschijnlijk een benaming met x60 t/m x80. Er zullen wel verschillende versies komen van de x75 (een normale en een low-power). Zie ook hier

[Verwijderd]

Als iedereen er zo over dacht zaten we nog steeds op 33Mhz te klote....ah joh die 33Mhz meer waar zeure ze over

[memphis]

Ja en ?
Toen deden we ook retesnel onze dingen op de PC en waren we blij om niet meer op de 4.77mHz XT te werken.....

Naar mijn weten kan het nog steeds want de huidige software wordt al lang niet meer optimaal geschreven.

[familyman]

Vind dit een interessant gegeven. Ik was laatst even bezig met MP3 encoding en zocht op lame.

Vond ik een site waarin de standaard lame werd omgebouwd naar HT-gebruikend en naar multiprocessor-gebruikend. En dan ook nog eens naar verschillende compilers.

De HT-gebruikende versie, gecompileerd met, ik meen de MS-compiler, was 70% sneller dan de standaard Lame, EN bit-voor-bit hetzelfde resultaat.

Ik meen dat de intel-compiler ook sneller was, maar door afrondingsfouten niet 1-1 gelijk.

70%, ik begon me af te vragen of wanneer men beter nadacht over programmeren en multi-threading dit in mijn andere software tot vergelijkbare resultaten zou leiden.

Zo vond ik PhotoShop maar bar langzaam opstarten en te gebruiken....

[SG]

@familyman

Niet elke taak eigend zich om makkelijk op te splitsen in Thread's.

Laad tijd kan alleen versneld worden door het hoofd proscess te ontlasten door apparte load thread te gebruiken maar dat is meer onder runtime van belang.

Bij app laden moet er veel data ingeladen worden die tijd is vooral afhankelijk van de HD.
1 of twee load threads maken geen ruk uit wel Raid0

Lame en dus verwante apps met het zelfde software probleem kunnen dus goed schalen op SMP software design. Volgens jouw melding

Niet elk software probleem kan op die manier ook zo rendable op gelost worden. per app ligt dat ergens tussen de 0% tot 95%

Daarnaast zegt 70% mij niks.
Met welke compiler was die oude app gemaakt de standaard MS VC++ 5.0 compiler? Of ene nieuwere maar dan non SMP.

Maakt heel wat uit of het PII of P4 single thread optimised was vs P4 HT optimised.

PII/PIII code loopt lekker op niet netburst dus oude intels en de hele AMD lijn. Netburst verhapt zich in PII/III code tov andere.

Die performance winst zit mogelijk ook in die 70%.
Dus een link van de bron is wel handig, lijkt mij namelijk erg interresant.

[RetepV]

@familyman

Niet elke taak eigend zich om makkelijk op te splitsen in Thread's.

Dat is zeker waar. Maar de hoofdreden om het niet te doen is dat de risico's op bugs ontzettend veel hoger komt te liggen. Hoe meer threads met elkaar samen moeten werken, des te meer er deadlock situaties op kunnen treden. En deadlock situaties worden ERG moeilijk te debuggen wanneer je meer dan 2 onafhankelijke threads hebt.

Als alle threads gewoon simpele worker threads zijn die allemaal hetzelfde doen is er weinig aan de hand. Maar als alle threads verschillende dingen doen en toch met elkaar gesynchroniseerd moeten zijn (daisy chains van threads die elkaar opstarten b.v.), dan wordt het echt zwaar. Dan kun je weken naar een simpele bug zoeken als je niet de juiste tools hebt.

Het zou al schelen als het OS tools zou leveren waarmee je de executievolgorde van threads kunt volgen. Dan kun je echt pseudoparallel gaan debuggen. De huidige OSsen zijn in feite serieele OSsen met multithreaded mogelijkheden er aan vast geplakt. Het OS is zich er amper bewust van dat er meerdere threads tegelijkertijd draaien. Als je meer gebruik gaat maken van multithreading, zal dat moeten veranderen.

Dat zal helaas kostbare processortijd gaan kosten, maar je hoeft het voorlopig alleen te doen tijdens het debuggen. Een probleem is dan nog wel dat je dan nog geen real-time applicaties kunt debuggen. Maar later kun je de debugging mogelijkheden misschien in hardware uitvoeren en kost het geen processortijd meer. Uiteindelijk is hyperthreading ook het in hardware uitvoeren van multithreading.

Het belangrijkste is dat het OS fatsoenlijke debugging mogelijkheden gaat krijgen. Helaas hebben ze dat bij Microsoft nog steeds niet gesnapt, want ze hebben het er nooit over als ze het over Longhorn hebben. Duizenden nieuwe features voor gebruikers, maar het de programmeur makkelijker maken zodat er minder bugs geprogrammeerd zullen worden: ho maar.

Let maar op, als multiprocessing en multithreading gemeengoed wordt, zal Linux daar bijvoorbeeld snel op inspringen. Ook Solaris zal dat kunnen. Ik verwacht eerlijk gezegd dat Mac OS X er ook snel op in kan springen. Die operating systems hebben de hardware allemaal verregaand losgekoppeld van het OS. Bij Windows is dat veel minder. Windows gaat het moeilijk krijgen in het multiprocessor tijdperk.

Ach ja, misschien vindt Intel er weer wat op zodat ze samen met Microsoft het 'Wintel' tijdperk nog wat langer kunnen rekken. Zo is het tot noch toe steeds gegaan.

[H!GHGuY]

70%, ik begon me af te vragen of wanneer men beter nadacht over programmeren en multi-threading dit in mijn andere software tot vergelijkbare resultaten zou leiden.

dat wordt voor software die dit nodig heeft ook gedaan.

meestal wordt eerst de volledige code in bvb c/c++ geschreven. waarna men de kritieke codepaden gaat zoeken. (wetende dat bij veel programma's grof gezegd en erg overdreven 90% van de tijd in 10% van de functies/code doorgebracht wordt) Dit doet men door te timen hoeveel processortijd elke functie in beslag neem (profiling).
Dan gaat men proberen om deze stukken te optimaliseren in een lager generatie taal (bvb Assembly) waardoor men soms serieuze versnellingen kan aanbrengen.

aan de andere kant heb je op dit moment ook het voordeel dat de compilers ook telkens slimmer en slimmer worden om de programma's zoveel mogelijk sneller te maken.

[Mars Warrior]

Het belangrijkste is dat het OS fatsoenlijke debugging mogelijkheden gaat krijgen. Helaas hebben ze dat bij Microsoft nog steeds niet gesnapt, want ze hebben het er nooit over als ze het over Longhorn hebben. Duizenden nieuwe features voor gebruikers, maar het de programmeur makkelijker maken zodat er minder bugs geprogrammeerd zullen worden: ho maar.
Huh?? Ik zit nu op een 4 processor machine te debuggen in VS.NET en kan elke processor aan en uit zetten en elke thread die ik maar wil debuggen in de volgorde dat ik wil. Dus wat bedoel je nu??

Let maar op, als multiprocessing en multithreading gemeengoed wordt, zal Linux daar bijvoorbeeld snel op inspringen. Ook Solaris zal dat kunnen. Ik verwacht eerlijk gezegd dat Mac OS X er ook snel op in kan springen. Die operating systems hebben de hardware allemaal verregaand losgekoppeld van het OS. Bij Windows is dat veel minder. Windows gaat het moeilijk krijgen in het multiprocessor tijdperk
Wederom, Huh? Windows gebruikt de HAL voor de hardware loskoppeling en ondersteund toch nu al multiprocessors, dus waar heb je het nu over??

[familyman]

De link eindelijk gevonden: http://softlab.technion.ac.il/project/LAME/doc/Multithreading%20LAME%2 0up%20to%203.97%20alpha.doc

[familyman]

@retepv

Ben met je eens dat als een OS eea makkelijker zou maken, het ook meer gemeengoed zou worden om software zo te ontwikkelen.

Maar dat vind ik nog geen argument om het dan nu maar niet te doen. Inderdaad zijn in mijn lame-voorbeeld kritische paden bestudeerd en geoptimaliseerd. Echter, volgens mij, is de hele optimalisatie gebaseerd op goed nadenken over wat de de verschillende threads wilt laten doen.

Dit lijkt me onafhankelijk van de manier van debuggen, maar meer van het logisch initieren van threads.

Debugging blijft dan alleen maar het controleren dat de verschillende threads de gewenste resultaten opleveren, hetgeen onafhankelijk lijkt van de mogelijkheden die het OS hiervoor biedt.

[Karimpje]

Waar gaat dit over. Ik hoor niemand zeuren dat ze nu ineens niet meer een dag of twee bezig zijn met het decoderen van een dvd of het coderen/decoderen van een divX, zou leuk zijn als je dat zou doen met een 4.75mhz.
Of programma's optimaal of niet optimaal worden geschreven, daar gaat het even niet om, maar over de processen die gewoon wel effe volle processor kracht vergen.
Trouwens hoe had je in gedachte dat je dvd brander het zou doen als je processor maar 4.75mhz zou zijn?

[RetepV]

Je kunt het zonder meer doen op een 4.75MHz processor. Maar dan zul je er wel specialistische hardware omheen moeten bouwen .

Iedereen kijkt maar naar die MHZ-en, maar daar draait het helemaal niet om. Die MHZ hype is precies dat: een hype. De MHZ is zo belangrijk geworden omdat de architectuur van een PC eigenlijk nogal ouderwets is (de basis is in 1982 gelegd). Over de jaren zijn alle onderdelen versneld en veranderd, maar niet beter toegespitst gemaakt op hun taak.

Kijk eens naar de VIA C3 processor. Een 533MHz heeft geen coprocessor, maar kan wel op zijn sloffen een DVD decoden en hoeft niet actief gekoeld te worden. Je kunt ook een DVD decoden met een Duron 700. Maar die moet je met een straaljager koelen. Hoe komt dat? Omdat de Duron 700 simpelweg een brute-force aanpak heeft, terwijl er bij de VIA C3 slim nagedacht is over de instructieset. De VIA C3 is meer toegespitst op het decoderen van media.

Je merkt het ook als je DiVX gaat decoderen. Dan komt de VIA C3 533MHz ineens absoluut te kort. Terwijl de Duron 700 het wel kan. En dat komt omdat de VIA C3 geen instructies heeft die helpen bij het decoderen van DiVX.

Je kan dus prima een 4.75MHz processor maken die een DVD kan decoderen. Maar het grootste deel van de processor moet dan speciaal toegespitst worden op het decoderen van die DVD. Misschien moet je de processor 2048 bits breed maken om genoeg data te kunnen transporteren. Maar at the end of the day loopt die processor nog steeds op 4.75MHz.

Je printplaat wordt overigens wel een beetje groot met een databus van 2048 bits .

[erikdeperik]

ja ga doom 3 of farcry spelen op je4.77 xt
zelfs al is het goed geschreven.
word oid zou nog lukken maar dat houd het toch echt op.

ontopic hoeveel mhz loopt die 252 eigenlijk

[SleutelMan]

op 2.6 Ghz, net zoals de Athlon FX-55. (het vorige model, de Opteron 250 draait op 2.4 Ghz, net zoals de FX-53 en de Athlon 64 4000+)

[Database freak]

Waar doen ze zo moeilijk over, weer 200Mhz erbij..


Als je niet kiest voor die 200mhz extra kan je de 250 nu fors goedkoper krijgen, dus hoe je er ook tegenaan kijkt, voor de consument/koper is deze introductie alleen maar voordeling. Het gat met Intel wordt nu ook groter, een 3,6 xeon kon de 2,4 opteron soms nog overtreffen maar tegen 2,6 kan zelfs een 3,8ghz Xeon niet tegenop.

[n4m3l355]

geheel afhankelijk van welke tests je er tegenover zet en ook wie het test.
alle tests moet je met een korreltje zout nemen en uiteindelijk zijn naar mijn idee ook vaak de verschillen zo minimaal dat het helemaal niet boeit. tevens is het verschil qua prijs tussen de highend xeon/opteron zo minimaal dat het ook daar niet meer boeit. als amd daadwerkelijk marktleider wilt worden of eens serieus een omzet wilt draaien moeten ze niet steeds de prijs drukken want dat is iets wat intel toch langer uithoud maar moeten ze een product afleveren wat daadwerkelijk verschilt met intel. en dat is tot nu toe (helaas) nog niet het geval. tevens ben ik wel benieuwd wat intel doet als amd ertoe zou neigen, iedere keer als amd met iets nieuws kwam haalde intel snel weer wat uit de kast wat vergelijkbaar is om zodoende zeker ervan te zijn dat amd geen klantjes weg snoept

[s463042]

Nu nog hopen dat de 252 ook nog een beetje leverbaar is... (itt sommige andere Opterons)

[Verwijderd]

Ik bedoelde meer iets in de richting van, dat hadden ze 3 maanden geleden vast ook al kunnen doen, nu kunnen ze weer net zo goed een 2,8GHz uitbrengen....Ze houden ons gewoon aan het lijntje tot ze met dual core komen....

Salaris verhoging?

Edit, dat over die 252 dat dei voor dual cpu systemen bedoelt was begrijp ik ook wel, echter, met dual core wordt alles effectief verdubbeld (helaas geld dat niet helemaal voor performance) dus 152 wordt 252, 252 wordt 452 en 852 wordt 1652....maar ze doen het met x, mooie marketingnames afdeling hebben ze daar:

XP, FX, X.

Erg orgineel.

[X-G]

Nou, ik vind het toch vet om te zeggen dat ik 'twee Opteron's X246's ' in mijn bakkie heb hangen...

[Puppetmaster]

je bedoelt met die X de x52 modellen opteron uit het nieuws bericht?

das geen marketingnaam oid, dat is gewoon door de nieuwsposter gedaan omdat er meerdere 52-rated opterons zijn.
nl de 152, 252 en 852

hangt samen met de max van multicpu-configs die de processors glueless aan kunnen.

[Verwijderd]

wat bedoel je precies met Glueless? kan me er wel een beetje een voorstelling van maken, maar ik ben niet zeker van mijn gedachten

[Verwijderd]

@puppetmaster, neen daar had ik het niet over