[Algemeen] AMD Nieuwsdiscussietopic - deel 33

[Hyperz]

Mensen lijken keer op keer te vergeten dat multi-threading gewoonweg niet (efficiënt) haalbaar is voor vele taken. Zeggen dat je met Bulldozer beter afbent in de (nabije?) toekomst puur omdat de nadruk op multi-threading ligt vindt ik dan ook persoonlijk onzin.

Bekijk het eens zo:
SB - 100% performance per core, 4 cores
BD - 50% performance per core, 8 cores

8 threads = beiden +- even snel
1 thread = SB 2x sneller dan BD

Conclusie: SB is een beter alround design en presteert goed in beide situaties terwijl BD enkel goed zal presteren in de heavy multi-threaded situaties, welke veel minder vaak voorkomen. Dit zal in de nabije toekomst niet veel veranderen. En voor taken die goed scalen kan je sowieso beter gaan afloaden naar de GPU in de toekomst.

[dcm360]

Je plukt de 100% en 50% echter zo uit de lucht, zelfde geldt voor de getallen eronder. Een core van een BD processor weet echt wel meer werk te verzetten dat de helft van wat een SB kan.

madmaxnl schreef op zondag 16 oktober 2011 @ 22:47:
[...]


<Plaatje>

offtopic:
Mn antivirus weigert dingen van dat domein door te laten, is er misschien ergens een mirror van dat plaatje?

[ Voor 40% gewijzigd door dcm360 op 16-10-2011 22:54 ]

[Hyperz]

madmaxnl schreef op zondag 16 oktober 2011 @ 22:47:
[...]


[afbeelding]

Wss Metro, en duidelijk GPU-limited. In Metro had ik een vergelijkbare framerate, en was ik niet CPU limited.

[ Voor 15% gewijzigd door Hyperz op 16-10-2011 23:02 ]

[Hyperz]

dcm360 schreef op zondag 16 oktober 2011 @ 22:52:
Je plukt de 100% en 50% echter zo uit de lucht, zelfde geldt voor de getallen eronder. Een core van een BD processor weet echt wel meer werk te verzetten dat de helft van wat een SB kan.

Die nummers zijn idd fictief. Dat verandert echter mijn conclusie niet.

[Hero of Time]

GENETX schreef op zondag 16 oktober 2011 @ 22:44:
Hero Of Time,

Vergis je in 1 ding niet. Het Bulldozer ontwerp op zichzelf lijkt meer futureproof te zijn. Het is het vehikel waar AMD nu aan kan sleutelen om verder te gaan. Dat wil echter niet zeggen dat de huidige "Zambezi"-processors ook echt futureproof zijn. Het moet vooral van toekomstige processoren gebaseerd op deze architectuur komen die de minpuntjes van de eerste lichting BD kunnen verhelpen en tegelijk kunnen rekenen op betere support van de compilers en dergelijke.

Ik zeg ook niet dat de BD nu perfect is, ik zeg alleen dat met de juiste optimalisaties het een veel degelijkere concurrent is voor Intel dan mensen nu inzien. Ik heb de laatste tig pagina's ook gevolgd en weet goed wat er gezegd is. Daarom zeg ik ook dat de toekomst meer weet en de opvolger van BD ook veel beter zal zijn door optimalisaties in de CPU zelf (en wellicht de architectuur iets).

[Hero of Time]

Hyperz schreef op zondag 16 oktober 2011 @ 22:58:
[...]


Die nummer zijn idd fictief. Dat verandert echter mijn conclusie niet.

Dat verandert het wel, want je schets nu het idee dat BD maar half zo efficiënt is vergeleken met SB, en dat is het echt niet. Het is veel efficiënter. Hoeveel durf ik niet te zeggen, daar heb ik niet genoeg verstand van deze dingen (en de review nummers niet vergeleken).

[Erwin1967]

GENETX schreef op zondag 16 oktober 2011 @ 22:31:
[...]

Zie het vetgedrukte onderstreepte woordje

Wat jij zegt is namelijk net zo goed onzin. Niemand heeft een glazenbol dus dit iets dat niemand kan beweren als feit zijnde. Wel ga ik met je mee dat we niet te hoge verwachtingen moeten hebben inderdaad. Toch is het zo dat het BD ontwerp zeker wel potentie heeft door oa 4 cores meer (ook al zijn de cores op zichzelf zwakker) en de gedeelde L2 cache tussen cores.

Ik ga uit van de situatie nu en het enige zinnige wat je kunt zeggen is dat de huidige BD in de toekomst ook niet sneller zal zijn. De rest is puur speculatie. Ik merk in de discussies hier heel veel gehoopt wordt en dat de praktijk vervolgens tegenvalt. De introductie van de BD is daar een voorbeeld van. Er wordt gehoopt dat de software in de nabije toekomst veel meer threads tegelijkertijd gaat gebruiken en op basis daarvan wordt de BD als beter naar voren geschoven. Op welke termijn verwacht men dit? Toch wel binnen de levensduur van de BD anders is het zinloos om hier rekening mee te houden. Tegelijkertijd wordt de single-thread performance gebagatelliseerd. Je noemt de core zwakker. Hij is niet zwakker maar enorm veel zwakker waardoor de BD de 8 cores nodig heeft om de SB bij te houden. Hyperthreading bij Intel en het modules concept bij AMD klinken aardig maar feitelijk wil je altijd, bij een beperkt aantal cores, volledig functionele cores hebben omdat je anders altijd bij bepaalde toepassingen weer tegen (onverwachtte) bottlenecks aan zult lopen.

[Hyperz]

Nee, het idee dat ik wil schetsen is dat je veel vaker nood zal hebben aan single threaded performance en dat je in de toekomst beter naar de GP-GPU performance van je grafische kaart kan gaan kijken dan naar die van je CPU. Die 50/100% was niet bedoelt om BD te laten overkomen als troep maar om mijn punt duidelijk te maken. Natuurlijk is dit ook zwaar afhankelijk van wat je vooral met je CPU wil gaan doen.

[GENETX]

Hyperz schreef op zondag 16 oktober 2011 @ 22:49:
Mensen lijken keer op keer te vergeten dat multi-threading gewoonweg niet (efficiënt) haalbaar is voor vele taken. Zeggen dat je met Bulldozer beter afbent in de (nabije?) toekomst puur omdat de nadruk op multi-threading ligt vindt ik dan ook persoonlijk onzin.

Mensen lijken keer op keer te vergeten dat we behoorlijk tegen de limiet zitten met wat mogelijk is voor single threaded performance.

Zoals ik onlangs al zei:
Wij zitten nog te kijken naar single thread performance op multicore processors, dat terwijl de ingenieurs al bezig zijn met heterogene processoren om meer performance te kunnen leveren.

Ik ben benieuwd wanneer Intel tegen de muur aanloopt waarop verbetering op thread niveau echt niet meer haalbaar is. Je kan heel leuk blijven wijzen naar single threaded performance en alle complicaties van multithreaded applicaties. Feit is gewoon dat we tegen een limiet aanlopen waar we eigenlijk niet verder kunnen. We moeten wel opschalen voor meer performance. Er zijn slechts 2 andere gavellen. In de eerste kan het niet en ben je hopeloos de sjaak met je applicatie. In het andere geval is het de moeite niet waard omdat de processors nu al meer dan snel genoeg zijn op 1 thread voor acceptabele performance.

En om in je laatste post in te haken. GP-GPU is ook heel leuk, maar ook lang niet overal inzetbaar. Net zoals multithreaded niet overal goed inzetbaar is. De rek is er uit voor "general purpose processors" zoals we er jaren mee hebben gewerkt. Je ziet heel duidelijk dat AMD de strategie heeft om hier van af te stappen.

[ Voor 32% gewijzigd door GENETX op 16-10-2011 23:26 ]

[dcm360]

Mja, wat noem je nood aan single threaded performance? Ik kan me eerlijk gezegd geen voorbeeld bedenken van software die ik gebruik die en veel werk moet verzetten en die dat werk niet over meerdere cores kan verdelen. Singlethreaded software is harder aan het uitsterven dan je misschien denkt.

[Erwin1967]

Hero Of Time schreef op zondag 16 oktober 2011 @ 22:40:
@Erwin1967:
Weet je dat zeker? Als er meer software optimalisatie komt voor BD, kan het nog slecht uit komen te zien voor SB. Leuk voor de mensen die op single thread performance geilen, maar bij echte multithread moet je toegeven dat SB wat tekort schiet vergeleken met BD. Als het ontwerp volgend jaar meer gefinetuned is in de hardware zal dat nog duidelijker zijn. Intel zal gegarandeerd zelf er een antwoord op hebben, maar dat zal echt niet met SB wezen. Dat moet IB doen, hopen de Intel mensen hier.
Zie ook GENETX, we hebben geen glazen bol, we kunnen niet in de toekomst kijken, dus is het afwachten.

Het gaat om het nu, niet over volgend jaar want dan zijn SB en als het goed is ook BD alweer vervangen door hun opvolgers. Single-thread performance wordt steeds meer onderschat omdat men graag een hexa of octa core in hun computer wil hebben. Gisteravond heb ik toevallig een programma gebruikt dat mijn systeem behoorlijk belastte. Het programma registax, voor het stacken van astrofoto's, gaf regelmatig 100% cpu belasting op mijn q9300 met 96% geheugen gebruik, dus best een zwaar programma. Ook hier was minstens de helft van de tijd de single-thread performance van groot belang. Ik moest dus van de 3 minuten ongeveer 1,5 minuut wachten op een berekening die kennelijk niet multi-threaded uitgevoerd kan worden. Ik dacht toen wordt het niet eens tijd voor een cpu met snellere cores

[Erwin1967]

GENETX schreef op zondag 16 oktober 2011 @ 23:19:
[...]

Mensen lijken keer op keer te vergeten dat we behoorlijk tegen de limiet zitten met wat mogelijk is voor single threaded performance.

Wij zitten nog te kijken naar single thread performance op multicore processors, dat terwijl de ingenieurs al bezig zijn met heterogene processoren om meer performance te kunnen leveren.

Ik ben benieuwd wanneer Intel tegen de muur aanloopt waarop verbetering op thread niveau echt niet meer haalbaar is.

We lopen inderdaad al tegen limieten aan. Versnellingen van factor 2 kunnen we op korte termijn wel vergeten. Maar goed, alles wat wel mogelijk is, is welkom. Er zijn ook andere bottlenecks die een rol spelen. De harde schijf is daar een van. De oplossing daarvan is de SSD. Verder is geheugentoegang ook zeer vertragend. Geheugenintensieve programma's hebben daar ook veel last van. Op die vlakken zullen AMD en Intel ook aan de slag zijn.
Doel van een heterogene processor, althans op de korte termijn, is niet om meer absolute performance maar om schaalverkleining te verkrijgen (alles op een chip) en daarmee kosten te drukken. Dus primair gericht op OEM's.

[Zer0]

Hero Of Time schreef op zondag 16 oktober 2011 @ 22:40:
@Zer0:
Ik bedoel dat je, zoals ik eerder al in dit topic meldde, dat je beperkt bent in het aantal VMs dat je kan draaien met SB voordat je systeem er onder lijdt. BD heeft een hoger limiet omdat het 8 fysieke cores heeft, vergeleken met de HT techniek van Intel, wat zoals eerder is gemeld hier, zwakke threads zijn. Er zijn nog steeds 4 fysieke cores die het werkt uitvoeren, dat is de beperking die je krijgt.
Ga maar eens een compile bak maken waarbij je 8 projecten tegelijk wilt compileren in VMs. Dat zal veel langer duren met een SB dan met een BD. Daar is BD veel meer toekomstgericht en gaat dus langer mee. Ik denk ook zo dat de opvolger van BD op een gelijke socket zal draaien, maar IB zal zeer waarschijnlijk een andere krijgen.

Dat zijn nogal wat aannames. De 8 cores in de BD zijn geen volledige cores, en zullen dus niet de volledige winst van 8 "echte" cores benaderen. Hoe het zich verhoud met de winst die bijvoorbeeld VMware ESXi uit Hyperthreading kan halen heb ik nog nergens gezien in benchmarks.
Je voorbeeld van 8 compiles in net zo veel VM's is ook een leuke.. dat gaat een zooitje worden, aangezien er ook nog CPU tijd nodig is voor scheduling, en moderne compilers multi-threading zijn.
Daarnaast is voor virtualisatie CPU vrijwel nooit een bottleneck, IOPS en memory zijn veel belangrijker.

[The Source]

We zullen binnenkort zien wat Intel op 32nm binnen een TDP van 130W kan doen tov AMD op 32nm op 125W. Natuurlijk is het oppervlakte van de CPU die ook van belang en Sandy Bridge-E is ook niet bepaald klein.

[Hyperz]

GENETX schreef op zondag 16 oktober 2011 @ 23:19:
[...]

Mensen lijken keer op keer te vergeten dat we behoorlijk tegen de limiet zitten met wat mogelijk is voor single threaded performance.

Zoals ik onlangs al zei:
Wij zitten nog te kijken naar single thread performance op multicore processors, dat terwijl de ingenieurs al bezig zijn met heterogene processoren om meer performance te kunnen leveren.

Ik ben benieuwd wanneer Intel tegen de muur aanloopt waarop verbetering op thread niveau echt niet meer haalbaar is. Je kan heel leuk blijven wijzen naar single threaded performance en alle complicaties van multithreaded applicaties. Feit is gewoon dat we tegen een limiet aanlopen waar we eigenlijk niet verder kunnen. We moeten wel opschalen voor meer performance. Er zijn slechts 2 andere gavellen. In de eerste kan het niet en ben je hopeloos de sjaak met je applicatie. In het andere geval is het de moeite niet waard omdat de processors nu al meer dan snel genoeg zijn op 1 thread voor acceptabele performance.

En om in je laatste post in te haken. GP-GPU is ook heel leuk, maar ook lang niet overal inzetbaar. Net zoals multithreaded niet overal goed inzetbaar is. De rek is er uit voor "general purpose processors" zoals we er jaren mee hebben gewerkt. Je ziet heel duidelijk dat AMD de strategie heeft om hier van af te stappen.

We zitten dicht bij het limiet, daar twijfel ik ook niet aan. Maar het is niet omdat per-thread performance zo'n een beetje aan zijn einde zit dat het probleem van het paralleliseren van algoritmes zichzelf oplost. En moest dat wel het geval zijn zou Intel ongetwijfeld met een CPU komen met dezelfde core count als AMD. Wat zou het voordeel van AMD zijn in zo'n situatie? Want dan gaat de CPU met de beste performance per core winnen in dat geval. Vergeet ook niet de die size en verbruik van Bulldozer, welke in beide gevallen +- 2x zo veel is als SB.

Ik ben wel eens benieuwd wat er in de verre toekomst gaat gebeuren in CPU land: single thread performance = dead end, GHz race = dead end, multi-core race = zelfde situatie als de GHz race uiteindelijk, kleiner productieprocess = dead end uiteindelijk. Wat blijft er dan nog over? Lijkt me wel alsof we de CPU opnieuw zullen moeten uitvinden. Lopen we tegen een muur aan waar vooruitging in perfomance zo laag wordt dat het kopen van nieuwe hardware maar om de 10 jaar nodig zal zijn en dus fabrikanten bijna geen winst meer maken? Dit idee spookt al een tijdje door mijn hoofd .

[Toettoetdaan]

@Hierboven:
Kwantum CPU en grafiet in plaats van silicium

[Hyperz]

Was een kwantum CPU niet enkel goed in zéér specifieke taken? Grafiet was ik vergeten.

[Toettoetdaan]

Hyperz schreef op maandag 17 oktober 2011 @ 00:41:
Was een kwantum CPU niet enkel goed in zéér specifieke taken? Grafiet was ik vergeten.

Klopt, maar de techniek staat nog in de kinderschoenen, er kan vast veel meer uitgehaald worden.
Naast Grafiet is er ook synthetische diamant een interessant materiaal.
Maar ook alternatieve instructie set's zullen steeds meer overwogen gaan worden, zie ARM vs x86 maar ook de telkens betere/nieuwere versies van SSE.

Waarschijnlijk komen we eerder bij het punt dat consumenten software geen zichtbaar profijt uit snellere hardware kan halen dan dat de hardware niet sneller kan.
Nu merk je dat al, die normale huis tuin en keuken PC is beperkt door de snelheid van internet.

Het is logisch dat fabrikanten steeds meer naar een system-on-chip design proberen te werken, hier zal het grootste gedeelte van de mee markt bedient kunnen worden. Immers hebben veel mensen eigenlijk al genoeg aan een iPad.

Straks hebben we in de 400 euro pc's een quad-core en HD5770 prestatie's zitten, alleen gamer's en professional hebben meer 'nodig'.

[GerardReintke]

Toettoetdaan schreef op maandag 17 oktober 2011 @ 02:01:
[...]
En wat dacht je van synthetisch diamant,super gelijdend voor zowel stroom als warmte.
En dat zelfs op zeer kleine oppervlakte

Klopt, maar de techniek staat nog in de kinderschoenen, er kan vast veel meer uitgehaald worden.
Naast Grafiet is er ook synthetische diamant een interessant materiaal.

Maar ook alternatieve instructie set's zullen steeds meer overwogen gaan worden, zie ARM vs x86 maar ook de telkens betere/nieuwere versies van SSE.

Waarschijnlijk komen we eerder bij het punt dat consumenten software geen zichtbaar profijt uit snellere hardware kan halen dan dat de hardware niet sneller kan.
Nu merk je dat al, die normale huis tuin en keuken PC is beperkt door de snelheid van internet.

Het is logisch dat fabrikanten steeds meer naar een system-on-chip design proberen te werken, hier zal het grootste gedeelte van de mee markt bedient kunnen worden. Immers hebben veel mensen eigenlijk al genoeg aan een iPad.

Straks hebben we in de 400 euro pc's een quad-core en HD5770 prestatie's zitten, alleen gamer's en professional hebben meer 'nodig'.

[RuddyMysterious]

Hyperz schreef op zondag 16 oktober 2011 @ 22:49:
Mensen lijken keer op keer te vergeten dat multi-threading gewoonweg niet (efficiënt) haalbaar is voor vele taken. Zeggen dat je met Bulldozer beter afbent in de (nabije?) toekomst puur omdat de nadruk op multi-threading ligt vindt ik dan ook persoonlijk onzin.

Wat? Ik heb al meermaals een video-encode batch moeten stilleggen om wat te gamen op mijn triplecore, wat helemaal niet zou hoeven als ik meer cores had. Er is dus wel degelijk vraag naar, en jij maakt de fout door te denken dat mensen maar één ding tegelijk doen op hun computer. Neen, niet echt, waarom zou anders iedereen ten tijde van de Athlon64 X2 en de eerste Core 2 Duo's zo zijn overgestapt naar dualcore, terwijl er toch zo goed als niks baat bij had omdat zo goed als niemand multicore cpu's bezat? Er is multithreaded geprogrammeerde software langs de ene kant, en er is een shitload aan willekeurige software die je tegelijk kan draaien. Beide gebruikersprofielen zijn gebaat met een multicore cpu.

[Devpartner]

The Source schreef op zondag 16 oktober 2011 @ 23:58:
We zullen binnenkort zien wat Intel op 32nm binnen een TDP van 130W kan doen tov AMD op 32nm op 125W. Natuurlijk is het oppervlakte van de CPU die ook van belang en Sandy Bridge-E is ook niet bepaald klein.

Wat is gulftown dan? volgens mij is dat al een goede indicatie wat intel kan op 32nm met 130W TDP... namelijk een 6core monster.

Er is natuurlijk wel een gigantisch verschil dat intels 32nm echt goed is en GLOFO op dit moment echt slecht is. Mss dat we nog een jaar of langer mogen wachten vooralleer je de vergelijking kunt maken gebaseerd op architectuur en niet op process maturiteit.

[ Voor 8% gewijzigd door Devpartner op 17-10-2011 08:12 ]

[Hyperz]

DevilsProphet schreef op maandag 17 oktober 2011 @ 08:05:
[...]

Wat? Ik heb al meermaals een video-encode batch moeten stilleggen om wat te gamen op mijn triplecore, wat helemaal niet zou hoeven als ik meer cores had.

Video encoding/decoding is dan ook één van die dingen die relatief makkelijk in parallel uitgevoerd kan worden... Als je je CPU voornamelijk gebruikt voor zulke taken dan ben je idd beter af met zoveel mogelijk cores. Al zou ik persoonlijk nooit CPU-heavy multi-threaded apps draaien tijdens gaming want het zal altijd een grote impact hebben op game performance, of je nu een dual-core of een 16 core hebt. Beide apps zullen vechten om alle system resources.

[Astennu]

The Source schreef op zondag 16 oktober 2011 @ 23:58:
We zullen binnenkort zien wat Intel op 32nm binnen een TDP van 130W kan doen tov AMD op 32nm op 125W. Natuurlijk is het oppervlakte van de CPU die ook van belang en Sandy Bridge-E is ook niet bepaald klein.

Ik verwacht dat het aardig wat meer zal zijn. Performance van SB 1155 tm 4 threads maar zodra die 6 core zijn werk kan gaan doen zul je het verschil zien. En ook veel winst in apps die zwaar leuken op grote cache en geheugen bandbreedte.

Waar BD het al goed doet zal SB-E het denk ik helemaal goed gaan toen tov SB. Maar voor de meeste apps zal het denk ik niet al te veel verschil maken.

Een beetje hetzelfde als wat je eerst zag met S1156 vs S1366 Quad vs Hexa.

[ Voor 17% gewijzigd door Astennu op 17-10-2011 09:18 ]

[RuddyMysterious]

Hyperz schreef op maandag 17 oktober 2011 @ 08:30:
[...]


Video encoding/decoding is dan ook één van die dingen die relatief makkelijk in parallel uitgevoerd kan worden... Als je je CPU voornamelijk gebruikt voor zulke taken dan ben je idd beter af met zoveel mogelijk cores. Al zou ik persoonlijk nooit CPU-heavy multi-threaded apps draaien tijdens gaming want het zal altijd een grote impact hebben op game performance, of je nu een dual-core of een 16 core hebt. Beide apps zullen vechten om alle system resources.

Je kan natuurlijk prullen met de prioriteiten of het aantal threads dat die batch mag gebruiken limiteren, etc. Er zijn genoeg manieren om dat samen te laten doen met een minimum aan invloed op de beleving van de game. En daarmee bedoel ik TF2, dus niet zomaar eender welke game.

[Verwijderd]

Hyperz schreef op zondag 16 oktober 2011 @ 22:49:
Conclusie: SB is een beter alround design en presteert goed in beide situaties terwijl BD enkel goed zal presteren in de heavy multi-threaded situaties, welke veel minder vaak voorkomen. Dit zal in de nabije toekomst niet veel veranderen. En voor taken die goed scalen kan je sowieso beter gaan afloaden naar de GPU in de toekomst.

En dit klopt dan weer niet wat het veronderstelt dat er geen vooruitgang zit op het gebied van programmeren, het is dus alleen zo als niemand meer multithreading code meer aanmaakt, terwijl het toch meer dan duidelijk is dat het andersom is. Kijk naar BF3 en de frostbyte 2 engine (wordt ook gebruikt in NFS the run).

Je conclussie dat er juist weinig meer multthreading op de loopband staat is dus iets waar je je in vergist. Ook het gene wat gebruik kan maken van DX11 en GPU->CPU threads kan pushen zie je ook in een keer over het hoofd.

[Hyperz]

Verwijderd schreef op maandag 17 oktober 2011 @ 10:15:
[...]


En dit klopt dan weer niet wat het veronderstelt dat er geen vooruitgang zit op het gebied van programmeren, het is dus alleen zo als niemand meer multithreading code meer aanmaakt, terwijl het toch meer dan duidelijk is dat het andersom is.

Dat heeft niets met vooruitgang in programmeren te maken maar met het feit dat de meeste taken gewoonweg niet efficiënt op te splitsen zijn in meerdere threads. Ikzelf ben maar een hobbyist C++/C# programmeur maar ik heb genoeg ervaring met threading om dit met zekerheid te kunnen zeggen. Jij verwart de moeilijkheidsgraad van taken in parallel uitvoeren met de mogelijkheid van iets in parallel uit te voeren.

DX11 is ook geen goed voorbeeld want dat is een API. Je moet kijken naar effectief dingen bereken (algoritmes). Extreem simpel voorbeel, verdeel de werklast van dit eens over 2 threads:

code:

int sum = 5 * 5;

[ Voor 12% gewijzigd door Hyperz op 17-10-2011 11:14 ]

[Devpartner]

Hoeveel programmas ken jij die weinig threads gebruiken? en die je compleet afzonderlijk draait van eender welke andere applicatie?

Browsen met flash
browsen met javascript die om de x tijd gaat pollen bij host
mediaplayer/winamp/ of andere muziekspelers.
communicatie software: skype, msn, ventrillo, icq, ...
games?
youtube/vlc/mediaplayer... of andere video content.
Anti-spyware/anti-virus/anti cheat scanners.

Je kan het draaien hoe je wil, maar op een ongebruikte pc draaien 100en threads en bij de minste multitasking die je doet krijg je een negatief effect op single threads. Single thread is zogoed als irrelevant als je het bekijkt als 1 metingpunt. Wat belangrijk is hoeveel je haalt bij 2-4 threads die belast zijn.. Daaruit kun je een nuttige waarde halen.
Over dit en 2jaar gaat dit meetpunt zich bevinden bij 4-8threads.

[Hyperz]

Zucht, ieder modern programma gebruikt meerdere threads. Die zijn er niet om CPU intensieve werklast te verdelen maar puur om 2 dingen tegelijk te doen, bvb de GUI niet laten bevriezen terwijl het programma op een http response wacht

[Phyxion]

Hyperz schreef op maandag 17 oktober 2011 @ 11:17:
Zucht, ieder modern programma gebruikt meerdere threads. Die zijn er niet om CPU intensieve werklast te verdelen maar puur om 2 dingen tegelijk te doen, bvb de GUI niet laten bevriezen terwijl het programma op een http response wacht

Klopt, er zit een groot verschil tussen het gebruik van threads en multithreading. De meeste tasks zijn gewoon niet multithreaded te doen, maar bijvoorbeeld video decoding/encoding wel. Zoals je ook al zei, 5 * 5 heeft geen zin om te multithreaden en de meeste applicaties hebben niks aan multithreading.

[Devpartner]

Hyperz schreef op maandag 17 oktober 2011 @ 11:09:
[...]


Dat heeft niets met vooruitgang in programmeren te maken maar met het feit dat de meeste taken gewoonweg niet efficiënt op te splitsen zijn in meerdere threads. Ikzelf ben maar een hobbyist C++/C# programmeur maar ik heb genoeg ervaring met threading om dit met zekerheid te kunnen zeggen. Jij verwart de moeilijkheidsgraad van taken in parallel uitvoeren met de mogelijkheid van iets in parallel uit te voeren.

DX11 is ook geen goed voorbeeld want dat is een API. Je moet kijken naar effectief dingen bereken (algoritmes). Extreem simpel voorbeel, verdeel de werklast van dit eens over 2 threads:

code:

int sum = 5 * 5;

Ps: ik programeer niet vanuit een hobby oogpunt. En ik programmeer met programmas tussen de 60-200 threads waarbij er meerdere threads intensief zijn.


Op je vraag:
Dat is 1 complexe CISC instructie. Zelfs een single threaded cpu kan die instructie niet verdelen over meerdere pipelines.....


Wil je een voorbeeld:
Doom, is single threaded. er is maar 1 thread die berekend hoeveel dmg je doet bij een schietactie de geluiden en de gevolgen berekent en weergeeft.

Je kan dit veranderen naar multithreaded door elke unit op de map een thread te geven, die dan elk kunnen berekenen wat de dmg is voor zijn beheerde unit.
Dit is ook toepasbaar op de intelligentie van de units.

Je gaat in multithreading zogoed als nooit 100 winst maken bij het verdubbelen van threads. Daarvoor zijn er gewoon teveel limieten. (eg: programma code 80% van de tijd, HD 20% -> multithreading kan je enkel die 80% proberen aan te pakken... -> zelfs met oneindig veel threads en perfecte scalability kun je niet onder de 20% gaan..).

In bovenstaande probleem geval zou je een andere thread de data kunnen laten ophalen wanneer je denkt dat je ze gaat nodig hebben. Hierdoor zou je je bottleneck acties (HD in dit voorbeeld) kunnen minimaliseren door vooraf data te laden.

[ Voor 31% gewijzigd door Devpartner op 17-10-2011 11:33 ]

[Hyperz]

Dat jij programma's met x-aantal threads maakt zegt meer over het type programma dan over het probleem: de meeste dingen kan je niet opsplitsen in meerdere taken. Je geeft dat trouwens zelf aan door te zeggen dat sommige threads CPU intensief zijn. Als het zo simpel is, waarom is de werklast niet gelijk verdeelt over alle threads? Juist ja. Beter voorbeeld dan, bereken één md5 hash met meerdere threads op een manier die sneller is dan met een single thread. Success .

[dirkjesdirk]

De FX 8120 is nu beperkt voorradig bij Afuture. https://www.afuture.nl/pr...1/FD8120FRGUBOX_AMD_.html
Helaas wel vrij duur...


NB: is het niet handig om een "levertijden topic" aan te maken voor de FX processors?

[Devpartner]

Hyperz schreef op maandag 17 oktober 2011 @ 11:32:
Dat jij programma's met x-aantal threads maakt zegt meer over het type programma dan over het probleem: de meeste dingen kan je niet opsplitsen in meerdere taken. Je geeft dat trouwens zelf aan door te zeggen dat sommige threads CPU intensief zijn. Als het zo simpel is, waarom is de werklast niet gelijk verdeelt over alle threads? Juist ja. Beter voorbeeld dan, bereken één md5 hash met meerdere threads op een manier die sneller is dan met een single thread. Success .

Als je een programma draait dat 1 md5 hash moet maken en dat is alles... Dan is dat geen intensief programma. Dan kan je evengoed een 286 gebruiken want je gaat niets bottlenecken. Als je wil multithreaden moet je op grote schaal kijken hoe je meer intensieve threads tegelijkertijd kan doen...

Als je md5 hashing continue moet doen voor verschillende waarden dan kan je perfect een threadpool maken die elk een hash berekening doet en dan wegschrijft..

Je gaat voor 1 md5 verlies hebben... voor 2 win je al tijd en voor meer begint het verschil drastisch te zijn... deze oplossing blijft schaling zolang het locken en unlocken van je map met to-md5-hashed waarden niet de bottleneck begint te vormen.
Je kan dit verbeteren door ipv de threadpool de data zelf te laten halen uit 1 gemeenschappelijke map, de data te assignen aan elke thread apart of aan een map/kleinere threadpool. Hierdoor ga je minder lock contention hebben en dus een betere schaling bij meer requests.

Met andere woorden: Thread parallelism is iets dat je doet op algoritme en workflow niveau en niet op instructie niveau. De cpu core (hardware) doen dit op instructie en instructie flow niveau.

[ Voor 9% gewijzigd door Devpartner op 17-10-2011 11:52 ]

[Verwijderd]

dirkjesdirk schreef op maandag 17 oktober 2011 @ 11:38:
De FX 8120 is nu beperkt voorradig bij Afuture. https://www.afuture.nl/pr...1/FD8120FRGUBOX_AMD_.html
Helaas wel vrij duur...

Dat gaat sneller dan ik dacht. Het ziet er naar uit dat ik binnen aan maand echt tot actie over kan gaan

[Hyperz]

Devpartner schreef op maandag 17 oktober 2011 @ 11:40:
[...]


Als je een programma draait dat 1 md5 hash moet maken en dat is alles... Dan is dat geen intensief programma. Dan kan je evengoed een 286 gebruiken want je gaat niets bottlenecken. Als je wil multithreaden moet je op grote schaal kijken hoe je meer intensieve threads tegelijkertijd kan doen...

Als je md5 hashing continue moet doen voor verschillende waarden dan kan je perfect een threadpool maken die elk een hash berekening doet en dan wegschrijft..

Je gaat voor 1 md5 verlies hebben... voor 2 win je al tijd en voor meer begint het verschil drastisch te zijn... deze oplossing blijft schaling zolang het locken en unlocken van je map met to-md5-hashed waarden niet de bottleneck begint te vormen.
Je kan dit verbeteren door ipv de threadpool de data zelf te laten halen uit 1 gemeenschappelijke map, de data te assignen aan elke thread apart of aan een map/kleinere threadpool. Hierdoor ga je minder lock contention hebben en dus een betere schaling bij meer requests.

Met andere woorden: Thread parallelism is iets dat je doet op algoritme en workflow niveau en niet op instructie niveau. De cpu core (hardware) doen dit op instructie en instructie flow niveau.

Precies. Je gaat verlies hebben. Als je er een heleboel wilt ga je winst hebben, maar enkel en alleen omdat je ze los van elkaar kan berekenen, net zoals shaders op een grafishe kaart en video encoding etc. En daar zit het hem. Als je een md5 hash wil maken van 1GB aan data zal het WEL CPU intensief zijn en er is niets dat je kunt doen om dat op een zinvolle manier te gaan verdelen over meerdere cores omdat alles in het algoritme van elkaar afhankelijk is. En zo gaat dat met de meeste zaken. Je kunt logische en herhaalbare taken makkelijk verdelen over threads. De rest is een ander verhaal.

Nuja, dit gaat wel een beetje offtopic denk ik dus laten we gewoon kijken wat de toekomst brengt .

[Edmin]

dirkjesdirk schreef op maandag 17 oktober 2011 @ 11:38:

NB: is het niet handig om een "levertijden topic" aan te maken voor de FX processors?

Be my guest. Als er vraag naar is...

[Verwijderd]

Edmin schreef op maandag 17 oktober 2011 @ 12:23:
[...]

Be my guest. Als er vraag naar is...

Goed idee!

[dirkjesdirk]

Edmin schreef op maandag 17 oktober 2011 @ 12:23:
[...]

Be my guest. Als er vraag naar is...

Is dit een beetje conform de bedoeling? AMD FX processors levertijden topic
Zo nee, dan graag advies

[Devpartner]

Hyperz schreef op maandag 17 oktober 2011 @ 12:08:
[...]
En zo gaat dat met de meeste zaken. Je kunt logische en herhaalbare taken makkelijk verdelen over threads. De rest is een ander verhaal.

Fout, De meesten zaken bestaan uit meerdere van die zaken die perfect in parallel gedaan kunnen worden. Dat is dan ook de workflow die men threaded maakt in die situaties.

[Joepi]

Hadden we deze al, anders:
AMD's FX-8150 "Zambezi" - Bulldozer in Action
http://www.lostcircuits.c...task=view&id=102&Itemid=1
Intersssant, wat MS over L1 en L2 Cache stelt...

[karstnl]

Joepi schreef op maandag 17 oktober 2011 @ 16:46:
Hadden we deze al, anders:
AMD's FX-8150 "Zambezi" - Bulldozer in Action
http://www.lostcircuits.c...task=view&id=102&Itemid=1
Intersssant, wat MS over L1 en L2 Cache stelt...

Aardig interessant, nu hopen dat de opvolger in 2012 verbetering biedt op dat vlak

L1D cache size – too small and too slow. Especially at 16 kB size there should not be a reason to need 4 cycles access latency.
L2 cache latency: 27 cycles. This is almost twice the access latency of the L2 cache in Phenom II and while the L2 cache here is substantially larger, the combination of the insufficient L1 size with the extremely slow L2 cache is a recipe for disaster. I dare say that by reducing the L2 latency to 12-15 cycles, Zambezi would most likely see a 20-30% performance increase. Of course, this is pure speculation because I have not run any simulations.

[Verwijderd]

En zelfs simulaties zijn eerder onvertegenwoordigbaar voor de werkelijkheid dan vertegenwoordigbaar. Ze hebben een goed punt, daar waren meerdere al achter, dat die combinatie het moeilijker maakte. Het ligt toch nog steeds erg aan de programma structure.
Voor desktop programma's iets minder interessant, voor HPC en servers veel interessanter, aangezien veel op elkaar lijkende opdrachten simultaan kunnen worden verwerkt zonder veel latencie verlies.

Voor servers is BD het snelste, beste multithreaded integer performance.
Voor supercomputing, relatief minder FP performance wordt gecompenseerd door efficiente instructies van AMD, FMAC, 4 operands instructies en XOP + Xsave.

[Verwijderd]

Hyperz schreef op maandag 17 oktober 2011 @ 11:32:
Dat jij programma's met x-aantal threads maakt zegt meer over het type programma dan over het probleem: de meeste dingen kan je niet opsplitsen in meerdere taken. Je geeft dat trouwens zelf aan door te zeggen dat sommige threads CPU intensief zijn. Als het zo simpel is, waarom is de werklast niet gelijk verdeelt over alle threads? Juist ja. Beter voorbeeld dan, bereken één md5 hash met meerdere threads op een manier die sneller is dan met een single thread. Success .

Wat een aperte onzin. Verreweg de meeste programma's hebben niet eens de performance van één core nodig, en dus is het niet eens nodig om taken op te splitsen, ongeacht of dat nou makkelijk of moeilijk is.

Voor de programma's waar dat wel zinvol is, is het meestal prima mogelijk parellelisatie in het ciritical path toe te passen. Dingen offloaden naar een threadpool kan zonder ingrijpende veranderingen in de architectuur, en is vaak al erg effectief. Je hele app ontwerpen voor multithreading is ingrijpender, maar kan vaak tot flinke winsten leiden.

Je moet ook niet vergeten dat er meerdere manieren zijn om taken te parallelliseren. Je kunt dezelfde taak meerdere keren naast elkaar uitvoeren, je kunt een taak opsplitsen in subtaken en zo dingen deels parallelliseren, je kunt een nieuwe taak alvast starten voor de vorige helemaal afgelopen is, enfin er zijn legio mogelijkheden. Het is vooral een kwestie van architectuur en dat maakt het lastig om het achteraf nog in te bouwen, maar onmogelijk is het zelden.

Tuurlijk zijn er uitzonderingen te bedenken en gebieden waar het lastig is, een inherente lineaire taak als MD5 kun je moeilijk parallelliseren en ik heb zelf in dit topic al eens betoogd dat het bij games ook lastig is door de grote hoeveelheid afhankelijkheden tussen de verschillende taken. Maar om nou te doen alsof het in verreweg de meeste gevallen schier onmogelijk is, is echt totaal onzinnig. Parallellisatie is de toekomst en programmeurs en software architecten zullen meer en betere oplossingen bedenken om dat voor elkaar te krijgen.

[Nox]

In bovenstaande probleem geval zou je een andere thread de data kunnen laten ophalen wanneer je denkt dat je ze gaat nodig hebben. Hierdoor zou je je bottleneck acties (HD in dit voorbeeld) kunnen minimaliseren door vooraf data te laden.

Gezien de modules een gedeelde L2 cache hebben zou de een de data in de cache kunnen stoppen en de andere de data gebruiken zonder zelf requests uit te voeren om data te vragen?

[The Source]

Ivy Bridge to have 77W max TDP, backwards and forwards compatibility explained
http://vr-zone.com/articl...lity-explained/13754.html

Ik vertelde eerst al over de lage TDP van Ivy Bridge en nu blijkt uit gelekte Intel documenten dat die wellicht rond de 77W TDP zit voor een quadcore (ik bevestig niets ). Dat is aardig lager vergeleken met Sandy Bridge (95W) maar een gigantische gap met Bulldozer (125W). Ik denk dat het veilig is om te stellen dat de performance van Ivy Bridge hoger zal zijn ivm Sandy Bridge. Tuurlijk is dat op 22nm en duurt het nog tot 2012 voordat deze CPU op de markt komt maar het zal wel een competitor zijn voor AMD BD.

[Verwijderd]

The Source schreef op dinsdag 18 oktober 2011 @ 00:42:
Ivy Bridge to have 77W max TDP, backwards and forwards compatibility explained
http://vr-zone.com/articl...lity-explained/13754.html

Ik vertelde eerst al over de lage TDP van Ivy Bridge en nu blijkt uit gelekte Intel documenten dat die wellicht rond de 77W TDP zit voor een quadcore (ik bevestig niets ). Dat is aardig lager vergeleken met Sandy Bridge (95W) maar een gigantische gap met Bulldozer (125W). Ik denk dat het veilig is om te stellen dat de performance van Ivy Bridge hoger zal zijn ivm Sandy Bridge. Tuurlijk is dat op 22nm en duurt het nog tot 2012 voordat deze CPU op de markt komt maar het zal wel een competitor zijn voor AMD BD.

Je hebt je link gesloopt

Maar daar was ik al even naar op zoek geweest, dat is inderdaad een flink verschil. De performance schijnt niet erg omhoog te gaan, maar ik kan me voorstellen dat het overclockpotentieel dat wel doet. Nu komt, als ik de berichten mag geloven, tegen die tijd ook BD 1.1 uit, dus het is te hopen dat ze dan een flinke slag wat betreft verbruik hebben kunnen maken. Als ze dan rond de 95 watt kunnen uitkomen en de performance die beoogde 10-15% kunnen opschroeven lopen ze een klein beetje in, gezien de vooruitgang in performance die ik heb gezien gehoord van de Ivy's maar zo'n 3-8% zou zijn.

Het wordt in ieder geval een interessante tijd Ik heb een klein beetje hoop voor AMD, aangezien er aan een net nieuwe architectuur die nog niet helemaal af is nog veel meer te verbeteren valt dan iets dat al flink doorontwikkeld is. Aan de andere kant is het dan weer weinig voordelig dat Intel al op 22nm zit, terwijl AMD daar nog op moet wachten tot 2014.

[Joepi]

MSI: BD compatible
http://event.msi.com/mb/am3+/

[bwerg]

The Source schreef op dinsdag 18 oktober 2011 @ 00:42:
Ik vertelde eerst al over de lage TDP van Ivy Bridge en nu blijkt uit gelekte Intel documenten dat die wellicht rond de 77W TDP zit voor een quadcore (ik bevestig niets ).

Ivy bridge komt toch ook gewoon ok LGA2011, dus high-end? Dan ben ik benieuwd waarom er voor zo'n laag TDP wordt gekozen. Genoeg marge voor hogere kloksnelheden zou je zeggen. Ik had eigenlijk ook verwacht dat sandy bridge op LGA2011 een 125W TDP zou krijgen met standaardsnelheden van ~3,8GHz of zo.

Dat bij hogere kloksnelheden het verbruik per kloktik minder goed wordt kan er natuurlijk wel voor zorgen dat 125W niet meer de sweet spot is natuurlijk. Maar 77W is wel heel laag.

[chim0]

High-end wil toch niet per se zeggen hoge kloksnelheden? Gaat om de functionaliteit van de processor.

De high-end i7 920 was ook "maar" 2,66GHz maar was wel razend populair en kon ziekelijk hoog overgeklokt worden.

[Devpartner]

Mooi dat TDP omlaag gaat terwijl cpu performance gelijk blijft (gezien de model lijkt het mij te presteren zoals een hypotethische 2700 met een paar %).
Hopelijk heeft AMD tegen dan een deftig 32nm process zodat ze op zijn minst de huidige 8150 binnen de 95W krijgen... wat dan toch de verschillen tussen die cpu's acceptabel houdt. (50W TDP of 66% meer zoals het nu zou lijken is dat niet meer.)

[DCG909]

Wat ik heb gehoord (hier) over pilldriver, doet mij vermoeden dat BD niet "echt" af is.... die L1 & L2 latency's zorgen ook voor langere wacht tijden (dus meer acties en daardoor meer stroom).....
Ik denk dat ik nog effen op pilldriver wacht

[Help!!!!]

bwerg schreef op dinsdag 18 oktober 2011 @ 07:39:
[...]

Ivy bridge komt toch ook gewoon ok LGA2011, dus high-end? Dan ben ik benieuwd waarom er voor zo'n laag TDP wordt gekozen. Genoeg marge voor hogere kloksnelheden zou je zeggen. Ik had eigenlijk ook verwacht dat sandy bridge op LGA2011 een 125W TDP zou krijgen met standaardsnelheden van ~3,8GHz of zo.

Dat bij hogere kloksnelheden het verbruik per kloktik minder goed wordt kan er natuurlijk wel voor zorgen dat 125W niet meer de sweet spot is natuurlijk. Maar 77W is wel heel laag.

Sandy Bridge = S1155 TDP=95w
Sandy Bridge E = S2011 TDP= 125w
Ivy Bridge = S1155 TDP=77w

[dutch_warrior]

Het ligt natuurlijk aan je definitie van af, ik denk dat we wel kunnen zeggen dat Zambezi niet is wat AMD had verwacht en gehoopt. AMD heeft enkele problemen in het ontwerp ontdekt en moest gewoon de keuze maken of uitstel tot 2012 of gewoon nu het maximaal haalbare uitbrengen.

Met het oog op de problemen rond het 32nm proces bij Global Foundries heeft AMD er denk ik slim aan gedaan om Zambezi toch nu te lanceren, dan is het proces voor Piledriver misschien op orde.
Als ik kijk hoelang de productie van Llano nu loopt baart het mij wel zorgen wanneer ik zie dat de vcore standaard nog steeds vrij hoog is. Hopelijk heeft AMD dit gedaan omdat ze alle productie capaciteit nodig hebben voor Bulldozer based cpu's.

Een stukje goed nieuws voor AMD is dan weer dat Intel problemen heeft met de graphics drivers van de nieuwe Atoms. De eerste benchmarks van cedar trail zijn niet bijzonder overtuigend, tuurlijk de intel apu lijkt overal een stuk sneller maar als de drivers nog steeds niet op orde zijn wat heb je dan aan die apu?
Het feit dat in de hierboven geplaatste benchmarks een Asus netbook met Intel Atom en AMD gpu getest is wijst er voor mij wel op dat Intel voor Cedar Trail nog niet alles op orde heeft.

Ook nog even een update over het uitschakelen van een cluster (core) in een Bulldozer module (Compute Unit).
Het lijkt erop dat 4cu4t in de praktijk geen performance winst biedt ten opzichte van 2cu4t.
Stroomverbruik bij 4cu4t is hoger en de maximale turbo snelheid is 300Mhz lager.
Wanneer een game 80% belasting maakt op vier cores dan wint 4cu4t ruim van 2cu2t, wanneer een game echter maar 60% load maakt op 4threads dan wint 2cu4t vanwege de hogere clocks.

[Verwijderd]

Hyperz schreef op maandag 17 oktober 2011 @ 11:09:
[...]


Dat heeft niets met vooruitgang in programmeren te maken maar met het feit dat de meeste taken gewoonweg niet efficiënt op te splitsen zijn in meerdere threads. Ikzelf ben maar een hobbyist C++/C# programmeur maar ik heb genoeg ervaring met threading om dit met zekerheid te kunnen zeggen. Jij verwart de moeilijkheidsgraad van taken in parallel uitvoeren met de mogelijkheid van iets in parallel uit te voeren.

DX11 is ook geen goed voorbeeld want dat is een API. Je moet kijken naar effectief dingen bereken (algoritmes). Extreem simpel voorbeel, verdeel de werklast van dit eens over 2 threads:

code:

int sum = 5 * 5;

Ik verwar niets , ik geef je een goed voorbeeld van een engine waar spelen gebruik van maken die multithreaden.

Ik zit ook niet te wachten op notepad die 8 (of meer) threads bestrijkt, DX11 is wel een goed voorbeeld want het laat zien hoe de API zelf threads naar een CPU kan sturen waar anders deze alleen door de GPU worden behandelt.

Jij heb het over een ander niveau van programma's waar ik het duidelijk heb over spelletjes. Als jij geen optie ziet in multithreading voor de applicaties waar jij aan werkt is dat niet jou probleem meer dan de mijne ?

[Dreamvoid]

dutch_warrior schreef op dinsdag 18 oktober 2011 @ 11:10:
Een stukje goed nieuws voor AMD is dan weer dat Intel problemen heeft met de graphics drivers van de nieuwe Atoms. De eerste benchmarks van cedar trail zijn niet bijzonder overtuigend, tuurlijk de intel apu lijkt overal een stuk sneller maar als de drivers nog steeds niet op orde zijn wat heb je dan aan die apu?
Het feit dat in de hierboven geplaatste benchmarks een Asus netbook met Intel Atom en AMD gpu getest is wijst er voor mij wel op dat Intel voor Cedar Trail nog niet alles op orde heeft.

Intel draait als geheel uitstekend, maar het Atom programma ziet er slecht uit op het moment. De netbook markt zit in het slop, en als extra klap is AMD daar wel competitief en succesvol. Het is zelfs zo beroerd gesteld dat op het moment een omlaag geklokte Sandy Bridge het beter doet qua performance-per-watt dan een dedicated low-power cpu ontwerp. In theorie zijn de productiekosten van SB veel hoger, maar die vlieger gaat niet meer op als je 'kapotte' SB's-met-maar-1-core uit de vuilnisbak pakt.

En aan de tablet/smartphone kant (Z-serie Atoms) zit Intel nog steeds met het probleem dat de OEMs en software boeren onder het motto "never change a winning team" totaal geen zin hebben om hun OS/apps naar x86 te porten, niet nu hun huidige modellen als warme broodjes de deur uit lopen. En zelf dan maar het OS maken, tsja...wat een succes is dat geworden.

[ Voor 9% gewijzigd door Dreamvoid op 18-10-2011 14:41 ]

[bwerg]

chim0 schreef op dinsdag 18 oktober 2011 @ 07:49:
High-end wil toch niet per se zeggen hoge kloksnelheden? Gaat om de functionaliteit van de processor.

De high-end i7 920 was ook "maar" 2,66GHz maar was wel razend populair en kon ziekelijk hoog overgeklokt worden.

High-end betekent dat het maximale eruit gehaald wordt. De i7 920 had een 130W TDP en kon dus niet hoger geclockt. Als je topmodel een TDP van 77W heeft, betekent dat je een sneller model kan maken met hogere clocks.

Help!!!! schreef op dinsdag 18 oktober 2011 @ 11:05:
[...]

Sandy Bridge = S1155 TDP=95w
Sandy Bridge E = S2011 TDP= 125w
Ivy Bridge = S1155 TDP=77w

Dat is nieuw voor mij, maar alsnog zullen er wel 22nm-CPU's op S2011 komen (extreme-varianten), net zoals dat er 32nm-CPU's op S1366 kwamen. Al met al lijkt me bulldozer en ook piledriver dan redelijk kansloos...

[dahakon]

Ivy op 2011 is nog minstens een jaar weg, als we er van uit gaan dat ze niet te dicht op SB-E launch willen zitten. Of Piledriver bij voorbaat kansloos is, is een nattevinger drol van een gok. Het is duidelijk dat er scherpe kantjes zitten aan het ontwerp van Bulldozer, maar er zijn al (ver voor de launch voor wat het waard is) geruchten dat een nieuwe stepping van Bulldozer een aantal zaken aan zal pakken waarmee een betere performance te krijgen is. Piledriver zou een 10-15% performance increase moeten krijgen over Bulldozer. De vraag is alleen, is dat Bulldozer in zijn huidige vorm? Of is het ten opzichte van een eventuele nieuwere stepping, die beter voldoet aan wat Bulldozer zou moeten zijn? Klokt Piledriver wel zoals AMD het wil, binnen een acceptabel TDP?

[Verwijderd]

Wanneer zou de nieuwe stepping dan moeten uitkomen? Dan waarschijnlijk ook de 8120 op 95W en de 8170 mag ik hopen?

Dus intel gaat de nehalem structuur nu veranderen naar sandy bridge achtige structuur, SB-E voor servers en ivy bridge voor desktops en light servers mss.

[Devpartner]

Aanrader: semiaccurate charlie artikels. Heeft er 2 geschreven over waarom BD faalde en faalt...
De vraag is kunnen ze die problemen rechttrekken?

Dingen die ik eruit haal: Cache is gewoon traag (wisten we al)
hij ziet front end en executie als een issue (ik niet)
waarschijnlijk is GLOFO niet de volledige cullprit in de vermogens
Projected BD frequency bij launch was 10% hoger.


Persoonlijk vind ik de cache performance het belangrijkste om bij te tweaken. Ik hoop dat ze dit doorhadden vanaf het begin en ze dus dit heuvel met piledriver al stuk zouden rechttrekken.

[Verwijderd]

Als de frequentie 10% hoger had gelegen was het volgens mij goed geweest. Bijna 400MHz erbij, dus mogelijk was de target 4,0GHz. Ik dacht zelf eerst 3,8GHz.
Hopelijk komen ze daar snel op bij de volgende stepping.

[dahakon]

Verwijderd schreef op dinsdag 18 oktober 2011 @ 18:13:
Wanneer zou de nieuwe stepping dan moeten uitkomen? Dan waarschijnlijk ook de 8120 op 95W en de 8170 mag ik hopen?

Die stepping zou ergens vanaf halverwege Q1 tot eind Q1 2012 moeten verschijnen, volgens Charlie. Met die stepping zou een redelijke performance boost voor de integer cores moeten komen. Over clocks en TDP ging het verder niet, maar het lijkt mij vooral logisch dat dit moet verbeteren met het verbeteren van het 32nm proces.

[Verwijderd]

Dat is dus ruim drie maanden. Dan bestaat er een goede kans dat de 2 eerder genoemde CPU's nog voor de nieuwe stepping gereleased worden.
Hopelijk een FX8170 op 4GHz, hoewel op 3,8 of 3,9GHz mij aannemelijker lijkt.

Eerst maar eens de huidige FX reeks tweakers.net gebruikers benchmarks zien.

Apart om te zien dat Intel cores naast elkaar plaatst, terwijl AMD ze in een vier hoeken duwt. Daarom kan ik de Komodo CPU ook totaal niet plaatsen, 1 module erbij, ergens in het midden naast de ander 4? 2 modules erbij lijkt mij logischer, beetje thuban achtig concept.

[Dreamvoid]

dahakon schreef op dinsdag 18 oktober 2011 @ 18:01:
Ivy op 2011 is nog minstens een jaar weg, als we er van uit gaan dat ze niet te dicht op SB-E launch willen zitten.

Idd, waarom zou Intel in vredesnaam in de high/mid end aggressief versneld gaan introduceren? Ze hebben wel belangrijker dingen aan hun hoofd: de netbook markt terugwinnen en zich de tablet markt invechten.

[Verwijderd]

Devpartner schreef op dinsdag 18 oktober 2011 @ 18:14:

Dingen die ik eruit haal: Cache is gewoon traag (wisten we al)

Cache valt best mee, zie ook Dresdenboy's comment op dat artikel. Het programma dat werd gebruikt geeft foute latencies neer, met AIDA worden de correcte latencies weergegeven en die zijn wel ok.

[Verwijderd]

Devpartner schreef op dinsdag 18 oktober 2011 @ 18:14:
Aanrader: semiaccurate charlie artikels. Heeft er 2 geschreven over waarom BD faalde en faalt...
De vraag is kunnen ze die problemen rechttrekken?

Dingen die ik eruit haal: Cache is gewoon traag (wisten we al)
hij ziet front end en executie als een issue (ik niet)
waarschijnlijk is GLOFO niet de volledige cullprit in de vermogens
Projected BD frequency bij launch was 10% hoger.


Persoonlijk vind ik de cache performance het belangrijkste om bij te tweaken. Ik hoop dat ze dit doorhadden vanaf het begin en ze dus dit heuvel met piledriver al stuk zouden rechttrekken.

Het probleem wat ik heb is dat Bulldozer wel degelijk redelijke prestaties haalt maar men verwacht gewoon iets wat niet bestaat op de Bulldozer , single thread performance.

Haal je dat uit het verwachtings patroon is het niet zo erg. Wat mij wel stoort is dat het gewoon weg niet op de meeste programma's die wel multithreaden op een hoog niveau presteert (soms wel soms niet enz.). De prijs is natuurlijk ook, iets van andere merk is goedkoper en haalt wel de prestaties.

Enige wat ik hoop is dat de volgende ronde dat AMD het wel voor elkaar krijgt om het stabiel te krijgen, want mijn broek zakt af van http://blogs.amd.com/play/2011/10/13/our-take-on-amd-fx/

[- J.W. -]

Verwijderd schreef op woensdag 19 oktober 2011 @ 10:29:
[...]


Enige wat ik hoop is dat de volgende ronde dat AMD het wel voor elkaar krijgt om het stabiel te krijgen, want mijn broek zakt af van http://blogs.amd.com/play/2011/10/13/our-take-on-amd-fx/

Dat heet marketing

Toch zijn zijn reacties op de reacties wel interessant. Tuurlijk, neem alles met een grote korrel zout, maar hij beweert/insinueert dat een 68xx serie videokaart beter paired met BD dan een 58xx kaart en er wordt opgemerkt dat er veel variatie in de benchmarks zit. Ihb dat het veelgebruikte Asus Crosshair V moederbord minder goed lijkt te presteren.

Niet dat het nu ineens een top-processor is/wordt, maar het geeft wel aan dat er nog een hoop te tunen / verbeteren valt qua firmware etc, wat op zich ook niet verwonderlijk is met een compleet nieuwe architectuur

[ Voor 5% gewijzigd door - J.W. - op 19-10-2011 12:48 ]

[N97]

Zeg... heeft iemand hier iets gehoord over leverproblemen van de A8-3850?

Er is dus geen enkele winkel (pricewatch) die hem meer heeft en leveranciers van de webwinkels hebben hem ook niet meer.

Altijd leuk als je na wekenlang uitzoeken eindelijk het (voor mij) ultieme systeem heb gevonden, is alles op voorraad behalve de CPU.

Hebben mede-tweakers ervaringen met het bestellen van een CPU in Belgie of Duitsland?
Ook in die landen is de CPU niet meer op voorraad.

[ Voor 6% gewijzigd door N97 op 20-10-2011 11:12 . Reden: Update buitenland ]

[Naluh!]

Verwijderd schreef op woensdag 19 oktober 2011 @ 10:29:
[...]

Enige wat ik hoop is dat de volgende ronde dat AMD het wel voor elkaar krijgt om het stabiel te krijgen, want mijn broek zakt af van http://blogs.amd.com/play/2011/10/13/our-take-on-amd-fx/

offtopic:
Dit zinnetje onderaan het artikel vind ik nog wel het mooist: Adam Kozak is a product marketing manager at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions.

Je geeft er een officiële 'feel' aan door het om een website van AMD te publiceren door een hoge AMD-pief maar tegelijkertijd houd je vast een slag om de arm mocht er ooit iets gezegd worden wat AMD niet zo uit komt.

En we vinden het allemaal nog normaal ook dat bedrijven zo met ons omgaan .

[dahakon]

N97 schreef op woensdag 19 oktober 2011 @ 13:20:
Zeg... heeft iemand hier iets gehoord over leverproblemen van de A8-3850?

Er is dus geen enkele winkel (pricewatch) die hem meer heeft en leveranciers van de webwinkels hebben hem ook niet meer.

De hardware.info pricewatch claimt dat er 11 aanbieders met voorraad zijn

Naluh! schreef op woensdag 19 oktober 2011 @ 14:14:
Je geeft er een officiële 'feel' aan door het om een website van AMD te publiceren door een hoge AMD-pief maar tegelijkertijd houd je vast een slag om de arm mocht er ooit iets gezegd worden wat AMD niet zo uit komt.

En we vinden het allemaal nog normaal ook dat bedrijven zo met ons omgaan .
[/offtopic]

Dat zinnetje staat onder elke blog van elke AMD-medewerker die zijn eigen visie in zijn blog geeft. Het heeft ook een reden, namelijk om de advocaten happy te houden. Dat is dan weer nodig omdat wij het normaal vinden hoe wij met bedrijven om gaan

[Naluh!]

dahakon schreef op woensdag 19 oktober 2011 @ 16:27:
[...]


De hardware.info pricewatch claimt dat er 11 aanbieders met voorraad zijn


[...]


Dat zinnetje staat onder elke blog van elke AMD-medewerker die zijn eigen visie in zijn blog geeft. Het heeft ook een reden, namelijk om de advocaten happy te houden. Dat is dan weer nodig omdat wij het normaal vinden hoe wij met bedrijven om gaan

Daar is een heel makkelijke oplossing voor: gewoon niet op de blog-site van AMD posten maar op je eigen persoonlijke blog. Maar ja, dan ben je dat voordeel van de officiële 'feel' weer kwijt. Dus lossen ze het zo op, lekker van 2 walletjes eten.

Inhoudelijk is het natuurlijk dezelfde lijst aan 'smoesjes' die we hier de afgelopen tig pagina's voorbij hebben zien komen .

De man noemt het overigens schaamteloos een 8-core cpu: "Those users running time intensive tasks are going to want an AMD FX processor for applications like x264, HandBrake, Cinema4D where an eight-core processor will rip right along.".

[Redblader]

Naluh! schreef op woensdag 19 oktober 2011 @ 17:36:
[...]

De man noemt het overigens schaamteloos een 8-core cpu: "Those users running time intensive tasks are going to want an AMD FX processor for applications like x264, HandBrake, Cinema4D where an eight-core processor will rip right along.".

Het is toch ook een 8-core..?

[dahakon]

Naluh! schreef op woensdag 19 oktober 2011 @ 17:36:
[...]
Daar is een heel makkelijke oplossing voor: gewoon niet op de blog-site van AMD posten maar op je eigen persoonlijke blog. Maar ja, dan ben je dat voordeel van de officiële 'feel' weer kwijt. Dus lossen ze het zo op, lekker van 2 walletjes eten.

De beste man werkt voor AMD en praat over technieken waar ze bij AMD mee bezig zijn. Op zich niet zo vreemd om dat op een specifiek deel van een AMD-site te doen. Disclaimers zijn er altijd, puur voor de juridische kant. Als je goed op gaat letten, dan zul je zien dat je het veel meer tegen komt. Het is echt niet iets specifiek AMD's.

Inhoudelijk is het natuurlijk dezelfde lijst aan 'smoesjes' die we hier de afgelopen tig pagina's voorbij hebben zien komen .

De man noemt het overigens schaamteloos een 8-core cpu: "Those users running time intensive tasks are going to want an AMD FX processor for applications like x264, HandBrake, Cinema4D where an eight-core processor will rip right along.".

Het is ook schaamteloos een 8-core. Dat deze cores niet 1 op 1 vergelijkbaar zijn met een Intel core, of een oudere AMD core, doet daar helemaal niets aan af.

[madmaxnl]

Naluh! schreef op woensdag 19 oktober 2011 @ 14:14:
[...]

offtopic:
Dit zinnetje onderaan het artikel vind ik nog wel het mooist: Adam Kozak is a product marketing manager at AMD. His postings are his own opinions and may not represent AMD’s positions, strategies or opinions.

Je geeft er een officiële 'feel' aan door het om een website van AMD te publiceren door een hoge AMD-pief maar tegelijkertijd houd je vast een slag om de arm mocht er ooit iets gezegd worden wat AMD niet zo uit komt.

En we vinden het allemaal nog normaal ook dat bedrijven zo met ons omgaan .

Dat doen ze omdat ze anders aangeklaagd kunnen worden -in Amerika-(daar kun je voor elke habbekrats iemand aanklagen). Als het aan jou lag zou AMD dus kapot geprocedeerd worden als de verwachtingen en of visies van medewerkers niet uitkomen.

[ Voor 7% gewijzigd door madmaxnl op 19-10-2011 17:43 ]

[Naluh!]

dahakon schreef op woensdag 19 oktober 2011 @ 17:41:
[...]


De beste man werkt voor AMD en praat over technieken waar ze bij AMD mee bezig zijn. Op zich niet zo vreemd om dat op een specifiek deel van een AMD-site te doen. Disclaimers zijn er altijd, puur voor de juridische kant. Als je goed op gaat letten, dan zul je zien dat je het veel meer tegen komt. Het is echt niet iets specifiek AMD's.

Je komt het heel veel tegen ja, en zoals ik al zei: je kan het makkelijk voorkomen door op je persoonlijke blog zoiets te verkondigen. Nu is het gewoon half-half.

[...]

Het is ook schaamteloos een 8-core.

Mooi, dan zijn we het eens

[- J.W. -]

Nee, hij post dat als werknemer van AMD, niet als Pietje uit Purmerend..

Anyway, lekker belangrijk allemaal

[Verwijderd]

Naluh! schreef op woensdag 19 oktober 2011 @ 18:02:
Je komt het heel veel tegen ja, en zoals ik al zei: je kan het makkelijk voorkomen door op je persoonlijke blog zoiets te verkondigen. Nu is het gewoon half-half.

En precies zoals het eigenlijk overal gebeurt. Ben je nu spijkers op laag water aan het zoeken of wil je er nog iets inhoudelijks mee zeggen?

[Naluh!]

Verwijderd schreef op woensdag 19 oktober 2011 @ 18:35:
[...]

En precies zoals het eigenlijk overal gebeurt. Ben je nu spijkers op laag water aan het zoeken of wil je er nog iets inhoudelijks mee zeggen?

Het was een offtopic-opmerking over AMD in het bijzonder en bedrijven in het algemeen, dat had je op kunnen maken uit de "off topic"- tags.

[Verwijderd]

ik kan ook google geen driver voor mijn amd sempron 145 2.80 GHz vinden.
weet iemand heir een driver?

[ Voor 16% gewijzigd door Verwijderd op 19-10-2011 20:24 ]

[mitsumark]

Dat is geen nieuws.

Een CPU heeft geen driver nodig.

Open even een eigen topic en omschrijf duidelijk het probleem.

Edit: je eigen topic was dus al gesloten, volg het advies dat daar gegeven is eens op.

[ Voor 27% gewijzigd door mitsumark op 19-10-2011 20:29 ]

[Zer0]

dahakon schreef op woensdag 19 oktober 2011 @ 17:41:
Het is ook schaamteloos een 8-core. Dat deze cores niet 1 op 1 vergelijkbaar zijn met een Intel core, of een oudere AMD core, doet daar helemaal niets aan af.

Dat ligt helemaal aan wat je als core definieert. In mijn ogen is een core een onafhankelijke rekeneenheid, en dat zijn de "cores" in een BD module niet, ze delen onderdelen die noodzakelijk zijn voor het functioneren. Theoretisch zou je cores met een zaag moeten kunnen scheiden zonder het functioneren te belemmeren.

[Devpartner]

Dat kun je ook tussen de cores... de front-end ea zitten niet meer in de cores.. Net zoals vroeger toen de fpu niet in de core zat, net zoals het cache (of toch bepaalde stukken) niet meer in de core zit.

verschillende cache levels en datacomuncatie kanalen worden al geshared sinds jaren... ook dit kun je niet in 2 kappen hoor.

[Verwijderd]

Zer0 schreef op woensdag 19 oktober 2011 @ 22:38:
Dat ligt helemaal aan wat je als core definieert. In mijn ogen is een core een onafhankelijke rekeneenheid, en dat zijn de "cores" in een BD module niet, ze delen onderdelen die noodzakelijk zijn voor het functioneren. Theoretisch zou je cores met een zaag moeten kunnen scheiden zonder het functioneren te belemmeren.

Volgens mij kon dat al bij de eerste Athlons niet. Misschien bij die Pentium D's die twee P4's aan elkaar geplakt waren, maar of dat nu als voorbeeld van volwaardige chips wilt hebben weet ik nou ook weer niet.

[ Voor 7% gewijzigd door Verwijderd op 19-10-2011 23:26 ]

[Zer0]

Verwijderd schreef op woensdag 19 oktober 2011 @ 23:25:
[...]

Volgens mij kon dat al bij de eerste Athlons niet. Misschien bij die Pentium D's die twee P4's aan elkaar geplakt waren.

Het enige wat die cores delen is cache, en dat is niet noodzakelijk om te functioneren.
BD "cores" op een module delen oa de instructie fetch en decode, en die zijn echt nodig om te functioneren. Daar zit mogelijk ook de reden voor tegenvallende prestaties en de reden dat AMD hamert op software optimalisatie. Het is vergelijkbaar met de "problemen" die Intel had met HT voor er software voor geoptimaliseerd werd. Software moet de cores na elkaar vullen met instructies omdat er per twee cores maar een pipeline is om instructies te sturen. De hudige software ziet gewoon x cores en wil x instructies tegelijk sturen.

[Verwijderd]

Goed, volgens mij hebben we deze discussie nu al een aantal maal gehad en was ook al lang voor iedereen duidelijk dat de AMD Bulldozercores tussen volwaardige cores en HT in liggen. Waarom dit nu weer uit de sloot getrokken moet worden weet ik niet.

Tenzij iemand nieuwe input heeft natuurlijk, maar steeds dezelfde herhaling van zetten maakt het er ook niet boeiender op. Dat sommige mensen moeite hebben met het label dat gebruikt is is duidelijk, maar volgens mij ook totaal irrelevant aangezien het maar een label is.

[ Voor 17% gewijzigd door Verwijderd op 19-10-2011 23:39 ]

[Playa del C.]

Verwijderd schreef op woensdag 19 oktober 2011 @ 23:38:
Goed, volgens mij hebben we deze discussie nu al een aantal maal gehad en was ook al lang voor iedereen duidelijk dat de AMD Bulldozercores tussen volwaardige cores en HT in liggen. Waarom dit nu weer uit de sloot getrokken moet worden weet ik niet.

Tenzij iemand nieuwe input heeft natuurlijk, maar steeds dezelfde herhaling van zetten maakt het er ook niet boeiender op. Dat sommige mensen moeite hebben met het label dat gebruikt is is duidelijk, maar volgens mij ook totaal irrelevant aangezien het maar een label is.

Jij bent zelf anders drie keer aan het posten in de laatste negen posts. In de eerste ben je iemand anders aan het bekritiseren op zijn gedrag, in de tweede doe je mee aan een discussie die je in de derde post alweer als herhalend en niet nuttig bestempeld. Ik hoop dat alle irrelevante posts in dit topic nu weggemod worden, inclusief deze van mij.

[Naluh!]

Verwijderd schreef op woensdag 19 oktober 2011 @ 23:38:
Goed, volgens mij hebben we deze discussie nu al een aantal maal gehad en was ook al lang voor iedereen duidelijk dat de AMD Bulldozercores tussen volwaardige cores en HT in liggen. Waarom dit nu weer uit de sloot getrokken moet worden weet ik niet.

Ik vermoed omdat de marketingmanager van AMD het schaamteloos een 8-core cpu noemt en dat even aangestipt werd .

[GENETX]

Zer0 schreef op woensdag 19 oktober 2011 @ 23:32:
[...]

Het enige wat die cores delen is cache, en dat is niet noodzakelijk om te functioneren.
BD "cores" op een module delen oa de instructie fetch en decode, en die zijn echt nodig om te functioneren. Daar zit mogelijk ook de reden voor tegenvallende prestaties en de reden dat AMD hamert op software optimalisatie. Het is vergelijkbaar met de "problemen" die Intel had met HT voor er software voor geoptimaliseerd werd. Software moet de cores na elkaar vullen met instructies omdat er per twee cores maar een pipeline is om instructies te sturen. De hudige software ziet gewoon x cores en wil x instructies tegelijk sturen.

En waar haal je al die wijsheid vandaan?

De cores hebben gewoon een buffer met instructies klaarstaan. Dat is nodig voor out-of-order execution. Het is dus ook niet zo dat de fetch/decode altijd een continue stroom van instructies moet leveren aan een core. Zolang er nog instructies in de buffer zijn geeft dit geen problemen, de processor heeft namelijk nog werk voorhanden. En guess what, een fetch-decode kan meerdere (tot 4) instructies oppikken in 1 keer.

Ja, de capaciteit is op dit vlak verminderd inderdaad. Dat wil echter niet zeggen dat daar ook de bottleneck in zit. En dat is het enige dat van belang is.

[ Voor 6% gewijzigd door GENETX op 20-10-2011 08:06 ]

[RuddyMysterious]

Naluh! schreef op donderdag 20 oktober 2011 @ 06:17:
[...]

Ik vermoed omdat de marketingmanager van AMD het schaamteloos een 8-core cpu noemt en dat even aangestipt werd .

En wat denk je daarmee te bereiken? Een beetje een stok in het hoenderhok gooien? Emotionele reacties uitlokken? Het is niet alsof de BD een kind is van iemand hier, dus dat zal je niet lukken. Hoop ik althans.

@zero: waarom moeten ze opgesplitst kunnen worden als dat realistisch gezien toch nooit zal gebeuren? Het staat de cpu-ontwerpers vrij om met een architectuur te komen waarbij "het overtollige vet" is weggehaald om zo tot een betere efficiëntie per oppervlak of per verbruik te komen.

Nu kan je zeggen dat dat niet echt op gaat bij de BD, vergeleken met SB, maar je moet om juist te zijn vergelijken met een BD waarbij er maar één core per module wordt gebruikt. Prestaties zijn significant hoger, ja, maar zo ook het energieverbruik. De franstalige hardwaresite die is aangehaald en waar de 4M/4C setup vs de 2M/4C is getest, laat ook zien dat ondanks de lagere prestaties de efficiëntie met betrekking tot energieverbruik nog steeds op peil blijft, en soms zelfs iets beter is.

[The Flying Dutchman]

Eens kijken of er een wat interessanter discussiepunt mogelijk is: één van mijn grootste vraagtekens is hoe het kan dat die bulldozer 2 miljard transistors gebruikt tegenover slechts 900 miljoen voor Thuban en zo'n 1.2 miljard voor de snelste Intel cpu? Waar zijn al die transistors gebleven, wat zijn ze aan het doen? Met zo'n gigantisch transistor budget tov andere processors moet je toch een flinke performance stap kunnen maken.

Wat dat betreft lijkt het een beetje op een Fermi, maar die had dan tenminste nog het excuus dat het vrijwel een cpu was qua programmeermogelijkheden tov andere GPU's.

Zijn hier toevallig nog wat interessante artikeltjes over verschenen waarin dit uitgebreid besproken wordt?

[pino85]

Goede vraag en voer voor een discussie, als leek in die materie zou ook ik hier wel graag wat meer over willen weten.

[N97]

dahakon schreef op woensdag 19 oktober 2011 @ 16:27:

De hardware.info pricewatch claimt dat er 11 aanbieders met voorraad zijn

Dat is er inmiddels 1 aanbieder geworden en deze heeft er nog precies 1 op voorraad (€134.95/€144.90).
Ik heb een mailtje gestuurd of dat klopt. Geen zin in een betaling te doen om vervolgens te horen te krijgen dat hij niet meer op voorraad is en dat ik geduld moet hebben.

Maar toch heel raar dat hij in Nederland, Belgie en Duitsland uitverkocht is. Blijkbaar is de A8-3850 een hele populaire CPU of AMD heeft weer eens lever/productie problemen.

Productieproblemen dus...
http://www.fudzilla.com/p...l-suffers-from-bad-yields

[ Voor 8% gewijzigd door N97 op 20-10-2011 11:30 ]

[RuddyMysterious]

The Flying Dutchman schreef op donderdag 20 oktober 2011 @ 10:27:
Eens kijken of er een wat interessanter discussiepunt mogelijk is: één van mijn grootste vraagtekens is hoe het kan dat die bulldozer 2 miljard transistors gebruikt tegenover slechts 900 miljoen voor Thuban en zo'n 1.2 miljard voor de snelste Intel cpu? Waar zijn al die transistors gebleven, wat zijn ze aan het doen? Met zo'n gigantisch transistor budget tov andere processors moet je toch een flinke performance stap kunnen maken.

Wat dat betreft lijkt het een beetje op een Fermi, maar die had dan tenminste nog het excuus dat het vrijwel een cpu was qua programmeermogelijkheden tov andere GPU's.

Zijn hier toevallig nog wat interessante artikeltjes over verschenen waarin dit uitgebreid besproken wordt?

Het is algemeen geweten dat cache veel transistors opslokt, en cache is iets waar de BD veel van heeft. Disclaimer: ik doe maar een gok, ik ben er niet zeker over.

[ Voor 3% gewijzigd door RuddyMysterious op 20-10-2011 12:41 ]

[The Flying Dutchman]

DevilsProphet schreef op donderdag 20 oktober 2011 @ 12:40:
[...]

Het is algemeen geweten dat cache veel transistors opslokt, en cache is iets waar de BD veel van heeft. Disclaimer: ik doe maar een gok, ik ben er niet zeker over.

Dat klopt, maar hoe verhoudt zich dat tot de Intel processoren en Thuban? Rechtvaardigt het verschil in cache tussen die processoren 800 respectivelijk 1100 miljoen transistoren?

[spNk]

De 4 extra cores?

Edit:
http://www.fudzilla.com/h...le-ibm-exec-names-amd-cto

[ Voor 71% gewijzigd door spNk op 20-10-2011 14:28 ]

[Naluh!]

DevilsProphet schreef op donderdag 20 oktober 2011 @ 08:49:
[...]

En wat denk je daarmee te bereiken? Een beetje een stok in het hoenderhok gooien? Emotionele reacties uitlokken? Het is niet alsof de BD een kind is van iemand hier, dus dat zal je niet lukken. Hoop ik althans.

offtopic:
Als dat mijn bedoeling zou zijn geweest is het aardig gelukt iig...

Ik vond het gewoon lichtelijk ironisch dat AMD er steeds op hamert dat het om een 8-core gaat en sommige mensen hier juist alles doen om juist een beeld te bewerkstelligen dat daar min of meer recht tegenover staat. Wie de schoen past trekke hem aan wat dat betreft overigens...

The Flying Dutchman schreef op donderdag 20 oktober 2011 @ 10:27:
Eens kijken of er een wat interessanter discussiepunt mogelijk is: één van mijn grootste vraagtekens is hoe het kan dat die bulldozer 2 miljard transistors gebruikt tegenover slechts 900 miljoen voor Thuban en zo'n 1.2 miljard voor de snelste Intel cpu? Waar zijn al die transistors gebleven, wat zijn ze aan het doen? Met zo'n gigantisch transistor budget tov andere processors moet je toch een flinke performance stap kunnen maken.

Een groot stuk gaat al naar de extra cores tov Thuban lijkt me. Al houd je nog genoeg over, zal idd wel een groot gedeelte in de cache zijn gaan zitten.

[ Voor 33% gewijzigd door Naluh! op 20-10-2011 15:02 ]

[Devpartner]

Bulldozer Module heeft 213M transistors.

Dus 4Modules tesamen is goed voor ~850M transistors.

4Modules+het level3 cache = 1250M transistors.

dan is er nog een stuk voor uncore (HT, northbridge, ...).

En dan nog een groot ingebeeld stuk voor aan de ~ (onnauwkeurigheid) van dat statement te komen.

[ Voor 19% gewijzigd door Devpartner op 20-10-2011 15:56 ]

[A87]

YouTube: AMD bulldozer = EPIC FAIL

[Verwijderd]

Vind hem erg slecht, geen britney kwaliteit, iemand die alleen over hondenpoep praat.
Gooi het valluik maar open.

[Sp3ci3s8472]

Lias schreef op donderdag 20 oktober 2011 @ 16:46:
YouTube: AMD bulldozer = EPIC FAIL

Zo zo iemand is gefrustreerd. Voor de rest niet echt de moeite waard om te kijken.

[ Voor 57% gewijzigd door Sp3ci3s8472 op 20-10-2011 16:52 ]

[Verwijderd]

N97 schreef op donderdag 20 oktober 2011 @ 11:24:
Productieproblemen dus...
http://www.fudzilla.com/p...l-suffers-from-bad-yields

Ik zie dit als een grotere bedreiging dan de zogenaamde slechte performance van Bulldozer.