AMD biedt eerste quadcore-cpu voor minder dan 100 dollar

Chipgigant AMD heeft de Athlon II X4 620 uitgebracht, met een adviesprijs van minder dan 100 dollar. In Nederland is het de eerste quadcore die bij introductie minder dan 100 euro kost. Het ontbreken van L3-cache zorgt voor de geringe prijs.

De Athlon II X4 620 is de eerste van vier processors in de 600-serie die AMD uitbrengt. De cpu heeft een kloksnelheid van 2,6GHz en beschikt per core over 512kB L2-cache. De tdp ligt door het ontbreken van L3-cache op 95W, wat een stuk lager is dan de thermal design power van de Phenom II-cpu's, die op 125W ligt. Later zal AMD ook nog de Athlon II X4 600E, 605E en de 630 uitbrengen; deze hebben een kloksnelheid van respectievelijk 2,2GHz, 2,3GHz en 2,8GHZ. De E-uitvoeringen hebben een tdp van 45W, terwijl de X4 630 een tdp van 95W heeft.

De Athlon II X4-cpu's zijn gestoeld op dezelfde Deneb-architectuur als de Phenom II-cpu's, zij het dat elke vorm van L3-cache ontbreekt. De codenaam voor de quadcore-cpu's zonder L3-cache is Propus en het zou om een nieuwe productielijn gaan, waarbij de L3-cache niet zozeer is uitgeschakeld, maar ook fysiek niet op de die aanwezig is. Het cache-geheugen is bij cpu's goed voor het overgrote deel van het aantal transistors en het achterwege laten van 6MB L3-cache drukt de productiekosten dan ook.

Op dit ogenblik is de X4 620 voor ruwweg 85 euro in de Pricewatch te vinden, waarmee het meteen de goedkoopste quadcore is. De cpu is geschikt voor het AM2+- en het AM3-platform, waardoor de cpu volgens AMD de ultieme budget-processor is.

Reacties (102)

[himlims_]

Ik ben misschien niet volledig geinformeerd (eigen vout) maar wat betekend dat nu wezelijk het ontbreken van die L3 cache? Wil namelijk me pc gaan vervangen voor een nieuw modelletje ik photoshop voornamelijk, ga ik dat merken?

ik dacht ''L3 zal wel iets nieuws zijn'' [..] niets is minder waar. wordt als tijden gebruikt [picture]:

As more and more processors begin to include L2 cache into their architectures, Level 3 cache is now the name for the extra cache built into motherboards between the microprocessor and the main memory. Quite simply, what was once L2 cache on motherboards now becomes L3 cache when used with microprocessors containing built-in L2 caches. [bron]

Level 3 or L3 cache is specialized memory that works hand-in-hand with L1 and L2 cache to improve computer performance. L1, L2 and L3 cache are computer processing unit (CPU) caches, verses other types of caches in the system such as hard disk cache. CPU cache caters to the needs of the microprocessor by anticipating data requests so that processing instructions are provided without delay. CPU cache is faster than random access memory (RAM), and is designed to prevent bottlenecks in performance.[bron]

Corrigeer mij als ik het verkeerd heb; indien de microprocessortjes druk bezig zijn in L1 & L2 en deze loopt over wordt het overgenomen door L3 cache. Dus het ontbreken van L3 kan je systeem vertragen wanneer dat op maximum gebruikt wordt [...] dus voor mijn photoshop verhaal is het niet zo slim op een proc te nemen die geen L3 heeft ... correct? [bron]

[Reactie gewijzigd door himlims_ op 31 juli 2024 17:56]

[robvanwijk]

Er zijn al een boel goede en duidelijke antwoorden gegeven; dat zal ik hier niet herhalen. Wel wil ik nog even toevoegen dat ik nog nooit gehoord heb van caches op het moederbord, zoals in jouw eerste quote wordt beweerd:

As more and more processors begin to include L2 cache into their architectures, Level 3 cache is now the name for the extra cache built into motherboards between the microprocessor and the main memory.

Verder is het zo dat je twee L1 caches hebt: eentje voor instructies, eentje voor data. In L2 en L3 (en L4 als dat ooit bedacht wordt) staan zowel instructies als data. Dit is trouwens geen keiharde regel, da's alleen hoe het op dit moment gedaan wordt; in de toekomst zou dit kunnen veranderen.
Het punt is dat (even er vanuit gaande dat Photoshop op de CPU draait; als die op de GPU draait dan valt dit hele punt weg) code voor filters en dergelijke vaak relatief klein is, Ik heb geen idee of het in de L1 instructie-cache past, maar in L2 zeker, dus daar schiet je niks op met L3 cache. En de data waarop je bewerkingen uitvoert is zo groot, dat gaat nooit allemaal in je L3 passen. (Lokale bewerkingen, zoals een scherpte-filtertje hebben prima locality of reference, maar ook daar geldt weer dat L2 voldoende groot zou moeten zijn voor het gebiedje waarop bewerkingen plaatsvinden.)

Tot slot nog even dit: in principe zou je kunnen zeggen dat de registers min of meer vergelijkbaar zijn met een L0 cache, je RAM geheugen L4, swapfile L5, etc. (wat mij betreft noem je het Internet L7 of L8 ofzo ). Niet bepaald de gebruikelijke benamingen, maar op die manier is het wat makkelijker uit te leggen:
- Hoe hoger het nummer, hoe sneller de data opvraagbaar is
- Hoe hoger het nummer, hoe groter de opslagcapaciteit is
- Hoe hoger het nummer, hoe verder verwijderd (fysiek!) van je processor (of, tot en met L3: hoe verder van je ALU (=het stukje CPU dat echt rekent))
Die fysieke afstand is belangrijk omdat electrische signalen zich voortbewegen met de helft of een derde ofzo van de lichtsnelheid, en zoals we allemaal weten is licht nou eenmaal gruwelijk traag. Reken maar na: 3 GHz betekent een kloktik elke 0,33 nanoseconde. Uitgaande van een derde van de lichtsnelheid leggen signalen in die tijd slechts 3.331 cm af. Dus als je RAM-modules met 3 cm lange paden verbonden zijn met je CPU dan duurt het een hele klokslag voordat ze zelfs maar te horen krijgen dat ze aan de slag moeten. Zodra ze de data gevonden hebben duurt het dan nog een hele klokslag voordat de CPU dat te horen krijgt. Behalve dat het onbetaalbaar zou zijn om 4 GB aan L1 cache te hebben is het ook technisch gezien onmogelijk.

[Madrox]

Cache op het moederbord stamt uit de Pentium 1 (socket 7) tijd. Er waren ook AMD moederborden waarop je cache kon prikken.

http://articles.techrepub...100-10878_11-5033567.html

[BeosBeing]

Maar met de komst van SD-ram was het snelheidverschil verschil tussen cache op het moederbord en het gewone geheugen te klein geworden. Met hogere multipliers (P133=2, PII 300=4½, Athlon 500=5, PIII 600=6, PIV4 1.3=13, PIV 2.0=20, Athlon XP 2400+ (2Ghz) =15 enz.) werd het verschil tussen on-die cache en overige geheugen alleen maar groter.

[Verwijderd]

De snelheid van systeem geheugen, en daarbij dus tevens L1/L2/L3 cache geheugen bijgenomen komt vaak alleen naar voren in synthetische benchmarks.

Tuurlijk kan het een groot verschil uitmaken, de 3 trappen van cache geheugen zijn namelijk bedoeld om er voor te zorgen dat elke core nooit zonder data komt te zitten. Supersnelle toegang is mogelijk tot L1, wat vaak klein van omvang is. Als de data daar niet in te vinden is, wordt het grotere L2 cache aangeroepen, en uiteindelijk het L3 cache geheugen, en als laatste het systeem geheugen.

Het ontbreken van L3 zorgt er dus voor dat er vaker naar het systeem geheugen moet worden gegaan, echter dat moet toch gebeuren als het om nieuwe data gaat. Het is daarom vooral in synthetische benchmarks dat je L1/L2/L3 snelheden goed kan testen, en de invloed op het feitelijk gebruik valt soms reuze mee (met uitzondering van situaties waarin dezelfde data zeer vaak herbruikt wordt en eventueel volledig in het L3 cache geheugen zou passen, maar de gemiddelde dataset in Photoshop is vaak veel groter).

Een X4 met L3 cache geheugen en DDR3-1066 CAS7 is namelijk in gebruik veel langzamer dan een X4 zonder L3 cache geheugen en DDR3-1600 CAS5, maar in een synthetische benchmark komt de X4 met L3 cache geheugen er eventueel beter uit. Ik heb zelf daarom een hekel aan een hoop benchmarks die niet een juist beeld geven van de "gevoels" snelheid.

Photoshop kan zeer dankbaar gebruik maken van multithread, dus als jij maar 85 euro in je budget hebt voor de CPU, dan is een 2.6Ghz Quad-Core een betere keuze dan zeg een 3.2Ghz Dual-Core voor hetzelfde geld. Echter is je hoofdtaak meer applicaties die weinig multi-thread optimalisatie bevatten, dan is de hogere single-core snelheid van de 3.2Ghz dual-core veel beter. Het principe van Intel's Turbo is daarom ook zo mooi, een quad-core schakelt dan bijvoorbeeld 3 cores uit en overklokt de éné core dan automatisch, zodat de CPU als het ware een veel snellere single-core wordt, of iets snellere dual-core. AMD komt ook met een soortgelijk hardware oplossing, maar pas in de volgende generatie, tot die tijd kan je het via de Fusion software benaderen.

Als je dus professioneel met Photoshop bezig bent, dan doe je er in mijn ervaring dus beter aan om met een 85 euro CPU budget, voor de Quad-Core te gaan, en zoveel mogelijk geheugen te bemachtigen. Ik stop zelf minimaal 16GB in een Photoshop bak, en erg duur is dat niet meer tegenwoordig.

[.oisyn]

Een X4 met L3 cache geheugen en DDR3-1066 CAS7 is namelijk in gebruik veel langzamer dan een X4 zonder L3 cache geheugen en DDR3-1600 CAS5

Zoals je zelf al in je reactie heel correct aangeeft hangt dat dus wel van het gebruik af. Je spreekt jezelf dus een beetje tegen dat de ene setup "veel langzamer is in gebruik" dan de andere, zonder het erover te hebben wat dat gebruik dan daadwerkelijk is. Idd, photoshop zal weinig baat hebben bij cache. Een gemiddelde game daarentegen juist veel meer.

[Verwijderd]

Nou je moet bedenken wat het cache doet. Er kunnen dus grotere stukken code in de cache waardoor je het relatief langzamere geheugen dus minder hoeft te benaderen. Dat scheelt. Het probleem is wanneer de active loop te groot is voor de cache dat je veel performance verschil gaat merken doordat er geen gebruik van de snelle cache gemaakt word omdat er constant geswapt moet worden met het geheugen. Dan is meer cache, is meer snelheid.

Dan komt nog het volgende de L3 cache draait op een lagere snelheid dan de core. Ik meen dat het bij PH2 op 2Ghz draaide. Bij de oudere intel core 2 serie draait de grote L2 Cache op core snelheid. Hierdoor was/is de Core 2 ook zo goed met games. De hele active loop paste in de cache, die ook nog eens razend snel was. Jammer genoeg kan ik de link niet weer vinden van iemand die dit heel mooi liet zien . Daarom kan de Athlon II X2 met de iets grotere L2 cache het soms winnen van de Phenom X2, met de kleinere L2 cache, gezien die L2 cache op core snelheid draait. Past de active loop in het L2 cache dan wint de Athlon II, past ie er niet in, dan wint de Phenom omdat ie dan in het L3 past, wat sneller is dan het geheugen.

[Reactie gewijzigd door Verwijderd op 31 juli 2024 17:56]

[DinoBe]

Heel kort door de bocht: L3 en L2 cache geheugen is geheugen dat in de CPU zit en dient als buffer tussen het RAM en de CPU.

Een cpu heeft een aantal registers (iets zoals geheugenplaatsen) die werken op CPU snelheid. Deze zijn zeer snel, heel duur en dus heel beperkt aanwezig. Als een cpu een instructie uitvoert moet hij die gaan halen in het RAM geheugen (heel groot, goedkoop, maar ook heel traag) bijgevolg zit een cpu meer te wachten op het ram geheugen die per clocktik 1 regel uit het geheugen aan de cpu geeft (DDR kan zowel in de up als down cycle data in en uit het geheugen lezen/schrijven).

Om dit euvel op te lossen worden tussen de register van cpu en het ramgeheugen een aantal cache geheugens geplaatst. Deze zijn sneller dan het ramgeheugen, maar kleiner en ook duurder.

Als een cpu een instructie nu wil uitvoeren dan vraagt die aan het cache geheugen die juiste data, als die het niet heeft dan vraagt die het op zijn beurt aan L2, en als die het niet heeft vraagt die het aan L3 en als die het niet heeft dan gaat die het gaan zoeken in het ram geheugen. Nu de systemen zijn wel zo slim (prediction) dat in de buurt van instructie X ook de bijhorende data staat en zal die per tik meegenomen worden uit het ram geheugen. De kans dat de cpu nu in het RAM geheugen moet gaan zoeken is een stuk kleiner en dat maakt de cpu ook sneller.

De P4 had heel veel voordeel aan een groot cache geheugen omwille van zijn lange pipeline. Als een instructie in de pipeline zit en die is al een aantal stappen ver en plots blijkt gegeven X er niet te zijn dat moeten we die eerst in het geheugen gaan zoeken, in de cache steken en dan de pipeline herbeginnnen wat dus vertragend werkt. Hoe groter de cache, hoe minder wachten.

Voor een AMD Athlon64 maakte de hoeveelheid cache niet zo zot veel uit omdat de cpu een rechtstreekse bus naar RAM had en dus niet via de chipset rond moest.
Hoe dat nu zit met die nieuwe Phenom reeksen weet ik niet.

Hopelijk vertel ik nu niet teveel onzin

[Edit]
doh! ik zie nu pas dat ik net hetzelfde verteld heb als legofanaten hier onder

[Reactie gewijzigd door DinoBe op 31 juli 2024 17:56]

[DjVe]

ik vraag me dat ook af...welke invloed heeft het weglaten van L3 op de performance van de CPU?

[Zoijar]

Moeilijk te zeggen. Cache is in feite sneller geheugen dan je normale systeem geheugen (je zou kunnen zeggen dat systeem geheugen op zijn beurt weer "cache geheugen" is voor de data die op je harddisk staat). Als je een waarde uit systeem geheugen ophaalt, dan wordt die in cache geheugen geplaatst. De volgende operatie op dat geheugen gebeurt dan vanuit het snellere cache geheugen (cache hit) (simpel gezegd, het is natuurlijk iets ingewikkelder) en levert dus performance winst op. Systeem geheugen is relatief heel erg traag, dus cache kan een grote performance winst opleveren. Aangezien je maar een bepertke hoeveelheid cache geheugen hebt, kan je daar niet alles in laten staan en moet je dus waardes verwijderen. Probeer je geheugen aan te spreken dat niet langer in de cache aanwezig is, dan moet het opnieuw uit het trage systeem geheugen gehaald worden (cache miss). Hoe meer cache geheugen, hoe meer kans dat het geheugen waar je op werkt nog in de cache aanwezig is, en hoe sneller alles gaat. L1 t/m L3 zijn verschillende lagen van dat cache geheugen, van snel naar trager.

Als je steeds hele andere stukken geheugen slechts een keer aanspreekt, dan zit er vrijwel nooit iets in de cache en zijn bijna alle operaties cache misses. In dat geval maakt het ontbreken van de L3 niets uit. Voor andere software die heel goed met kleine stukjes data omgaat zal de meeste data in de L2 cache aanwezig zijn en maakt het ontbreken van L3 wederom niet uit. Echter, als een programma normaal gesproken veel L3 cache hits heeft, dan kan het ontbreken ervan een aanzienlijke impact op performance hebben. Daarom is het erg lastig hier iets zinnigs over performance te zeggen. Real-life benchmarks zullen moeten volgen.

[Reactie gewijzigd door Zoijar op 31 juli 2024 17:56]

[ocdaan]

De impact van cache geheugen was toch voornamelijk afhankelijk van de lengte van de pipeline? (pipeline, de hoeveelheid instructies in de wacht?) Kan me zoiets herinneren. De P4's hadden een hele lange pipeline en hadden goed voordeel aan extra cashe. De AMD's maar ook de nieuwe Intels hebben er minder baad bij in vergelijking door de relatief kortere pipeline. Of praat ik nu poep?

//.oisyn... muchas gracias senor!

[Reactie gewijzigd door ocdaan op 31 juli 2024 17:56]

[.oisyn]

Of praat ik nu poep?

No offense, maar ja

De lengte van de pipeline heeft invloed op de kosten van een branch misprediction. De pipeline is niet zozeer het aantal instructies 'in de wacht', want dan zou je het moeten zien als in de rij staan bij de supermarkt. Je moet een pipeline meer zien als een productieproces. Er zijn verschillende stappen nodig om een instructie uit te voeren. In grote lijnen moet een instructie eerst uit het geheugen worden gefetched, dan moet hij gedecodeerd worden, dan moet het nodige geheugen opgehaald worden, dan wordt de instructie daadwerkelijk uitgevoerd en vervolgens wordt er weer het nodige data weggeschreven. Net zoals producten in een fabriek niet in een keer volledig worden afgewerkt voordat er aan het volgende product begonnen wordt, is de instruction pipeline ook een soort lopende band waarin de specifieke stappen voor een instructie achter elkaar staan en de instructies voorbij komen.

Echter, sommige van die instructies zijn commando's om te springen naar een ander adres in het programma, zodat er feitelijk een nieuwe toevoer van instructies ontstaat. Normale branch instructies naar een vast adres worden vroeg in de pipeline al uitgevogeld, waardoor er vrij direct achter die instructie meteen al de juiste volgende instructies op de lopende band geladen kunnen worden. Echter, bij instructies waarvan het resultaat afhangt van een vorige instructie, weet je pas aan het eind van de pipeline óf of waarhéén er gesprongen moet worden. Op dat moment staan er dus een hele zooi nutteloze instructies op de lopende band die na de branch komen, die allemaal niet moeten worden uitgevoerd omdat je immers naar een nieuw adres moet springen. De hele lopende band wordt dan weer schoongeveegd, en moet de hele pipeline opnieuw gevuld worden met instructies van het juiste adres. Dit zorgt voor zogenaamde stalls, die bij CPU's met een lange pipeline, zoals de P4, veel performance kosten.

Om dit enigszins te voorkomen heeft een CPU een branch predictor, die op basis van resultaten uit het verleden bepaald of hij gaat springen of niet. Bij een juiste voorspelling zijn de juiste instructies dus al geladen op de lopende band, en kan er direct worden doorgegaan. Maar perfect zal het nooit werken, en dus zijn branch misprediction stalls aan het orde van de dag in een gemiddelde applicatie .

De hoeveelheid cachegeheugen heeft met dit hele verhaal in feite maar weinig te maken

[brompot758]

De hoeveelheid cachegeheugen heeft met dit hele verhaal in feite maar weinig te maken

De hoeveelheid cache heeft wel invloed op de snelheid waarmee de pipeline (weer) gevuld kan worden. Bij een branch misprediction duurt de reload korter als de nieuwe instriucties al in de cache staan omdat ze kortgeleden nog uitgevoerd zijn. Hoe groter de cache, hoe groter de kans dat ze er nog in staan. Overigens geldt dat uiteraard ook voor een correcte branch prediction.

Daarmee is het nogal van belang hoe groot het stuk code is dat een applicatie regelmatig raakt in relatie tot het formaat van de cache.

[poepkop]

@ocdaan: Voor zover ik weet was het grote cachegeheugen nodig om het ontbreken van een onboard geheugencontroller te compenseren. Bij AMD had/heeft cache nauwelijks impact, omdat deze het geheugen veel sneller kan aanspreken. Zo zag je bijvoorbeeld in de a64 tijd, dat de 1mb versie uiteindelijk weer snel verdween van de markt omdat het niks uitmaakte (0,1ghz meer presteerde beter dan een verdubbeling van het cache-geheugen).

De celerons van toen waren niet voor niks langzaam als slakken.

[fevenhuis]

Inmiddels is intel dus veel sneller in het aanspreken van geheugen (in elk geval met triple channel).

De invloed van de cache ga je merken met een hoop verschillende instructies zoals bij complexe software of gewoon veel taken. Over het algemeen is het zo dat je met de originele cache van een processor ontwerp de maximale snelheid eruit haalt (sweetspot) en zonder die cache haalt je dus niet het maximale eruit.
Als je niet veel of geavanceerde software draait (denk aan photoshop,3d rendering,video bewerking) zul je wel kunnen leven met het ontbreken van de cache.

[Caelestis]

Hum dit klopt niet helemaal. Om het zo kort en krachtig mogelijk neer te zetten. Het cache van een processor wordt gebruikt voor "Prediction Data" wat het systeem denkt als volgende nodig te hebben. (hier kan je nog wel erg lang op door gaan maar voor de "leek" hoop ik dat het volgende duidelijk genoeg is)

Wat je IRL merkt als verschil is voornamelijk het vlotte feedback gevoel. Om het duidelijk te maken Intel gebruikt over het algemeen grotere caches dan Amd waardoor mensen vaak op een Intel bak het gevoel krijgen dat het algemene prestatie vlotter en soepeler reageert terwijl er kwa rauwe power geen verschil in zit.

[.oisyn]

Hum dit klopt niet helemaal. Om het zo kort en krachtig mogelijk neer te zetten. Het cache van een processor wordt gebruikt voor "Prediction Data" wat het systeem denkt als volgende nodig te hebben. (hier kan je nog wel erg lang op door gaan maar voor de "leek" hoop ik dat het volgende duidelijk genoeg is)

Wat jij zegt is toch echt hetgeen dat niet klopt. Er staat wel wat prediction data in de cache (en dan voornamelijk in de L1 instruction cache, die doorgaans maar een paar kB groot is), maar dat is maar een fractie van waar het cachegeheugen voornamelijk voor gebruikt wordt, namelijk het weerspiegelen van de data dat een niveau verder staat. Bij een read uit het geheugen zal eerst de cache geraadpleegd worden, en als de waarde er niet in staat dan pas uit het echte geheugen. Een write zal eerst naar de cache schrijven, en later pas naar het geheugen bij een flush actie (geforceerd of als die geheugenplek moet plaatsmaken voor iets anders). Het is wel mogelijk voor applicaties om een leesactie te 'simuleren' zonder nog iets met het resultaat te doen. Hierdoor wordt het geheugen alvast naar de cache getransporteerd, zodat een stukje verderop, als dat geheugen daadwerkelijk nodig is, direct uit de cache gevist kan worden.

[Reactie gewijzigd door .oisyn op 31 juli 2024 17:56]

[Caelestis]

Het vraag was "Wat merk je in verschil met of zonder L3 cache?"

Uit beide ZEER informative posts van je is dit totaal niet duidelijk voor de gewone mens.

Ik heb zijn vraag beantwoord van wat het merkbare uitwerking is voor een consument niet een hele technische uitleg over hoe cache werkt.

[edit]
Oh en zonder prediction data in het L1 cache weet je processor totaal niet wat hij moet doen met de rest van het cache dus om te zeggen het is maar een klein deel is wel waar maar het is en blijft het grond principe waar het hele cache om draait.

Alle data gaat altijd via het RAM geheugen (geen uitzonderingen) dus is dat je bandbreedte en respons direct gekoppeld aan het geheugen en niet aan je cache.
Cache zorgt er alleen voor dat het data zo efficiënt mogelijk geordend en verwerkt wordt door het processor om beter met prioriteiten om te gaan.
Je cache zal onder geen enkel omstandigheid ervoor zorgen dat je geheugen meer bandbreedte krijgt of dat het sneller reageert.

Om het kort te zeggen je PC kan makkelijk zonder cache werken maar nooit zonder RAM.

[Reactie gewijzigd door Caelestis op 31 juli 2024 17:56]

[.oisyn]

Het vraag was "Wat merk je in verschil met of zonder L3 cache?"

Dat was de vraag van Jordy van e ja, wat Zoijar volledig correct uiteenzet. Vervolgens reageer jij met "dit klopt niet helemaal". Je kunt best een versimpelde weergave willen geven, maar dan moet je er niet bijzeggen dat de post van Zoijar niet helemaal klopt, want die klopt weldegelijk 100%

Oh en zonder prediction data in het L1 cache weet je processor totaal niet wat hij moet doen met de rest van het cache dus

Die "prediction data" is gerelateerd aan instructies. Met name resultaten van branch predictions. Zie mijn vorige post over de instruction pipeline. Dat heeft niets te maken met de geheugencaches. Die wourden louter gebruikt om data uit het geheugen te cachen. En het is absoluut onwaar dat hij zonder de prediction data niet weet wat hij moet doen. Net als bij de cache zoals je in je laatste regel van je post schrijft, kan hij ook best werken zonder ook maar iets te predicten. Het is dan alleen iets langzamer.

Alle data gaat altijd via het RAM geheugen (geen uitzonderingen) dus is dat je bandbreedte en respons direct gekoppeld aan het geheugen en niet aan je cache.

Nonsense. Data die in caches gemirrored wordt hoeft niet via je RAM. En de bandbreedte naar de caches is vele malen groter dan die naar het geheugen. Oftewel, als jij opeenvolgende reads doet die allemaal in de caches staan dan behaal je een veel grotere bandbreedte dan als die reads uit het RAM moeten komen. Ook met het wegschrijven van data hoeft het niet direct naar het RAM toe. Dat hoeft in principe pas als de cache vol zit en als dirty gemarkeerde cache locaties plaats moeten maken voor ander geheugen.

Wellicht heb je weleens gehoord van "write combined" geheugen, dit is hier een mooi voorbeeld van. Memory mapped IO, zoals de buffers van je videokaart, moeten over de PCI bus. Maar omdat korte writes teveel overhead geven, wil je die liever in grote chunks transporteren. Door een stuk geheugen als 'write combined' te markeren, worden alle writes geaccumuleerd in de cache. Pas als je een hele cacheline hebt volgeschreven, of als je een write doet naar een adres wat er niet op volgt, wordt de data pas verstuurd over de PCI bus in een enkele packet.

[Reactie gewijzigd door .oisyn op 31 juli 2024 17:56]

[Caelestis]

Hoe kan cache data van de hardeschijf ophalen zonder gebruik te maken van het RAM? Want dat is wat je feitelijk zegt dat gebeurt met cache.

Nonsense. Data die in caches gemirrored wordt hoeft niet via je RAM. En de bandbreedte naar de caches is vele malen groter dan die naar het geheugen.

Waar komt die data dan vandaan? zomaar uit de lucht gegrepen?
Je zegt het zelf het is gemirrored data dus 1 op 1 met het originele data. Waar komt dat originele data vandaan?

Juist uit het RAM. Ook al heeft het processor het data zelf aangemaakt is het nog steeds een mirror van het originele data en wordt uitgevoerd aan de hand van de prediction data technieken. En als je processor het gemirrored data heeft aangemaakt wil dat niet zeggen dat je geheugen bandbreedte groter is geworden. Je processor heeft het namelijk verwerkt niet het geheugen zelf.

Je processor gaat niet zomaar bedenken wat hij moet doen zonder prediction data calculaties uit te voeren.

Er is echter 1 uitzondering en dat is uitwisselbaar Data tussen meerdere cores dit kan wel enigszins gezien worden als zelf aangemaakte data maar zelfs dan nog is dat data als eerst via die andere cores opgehaald uit het geheugen dus is het hele riddeltje rond.

[.oisyn]

Waar komt die data dan vandaan? zomaar uit de lucht gegrepen?
Je zegt het zelf het is gemirrored data dus 1 op 1 met het originele data. Waar komt dat originele data vandaan?

Je interpreteert mijn opmerking verkeerd. Ik zeg dat als je een read doet [van een geheugenadres dus, alle reads en writes gaan over geheugenadressen], en dat stuk geheugen staat gemirrored in de cache, dan hoeft het RAM dus verder niet aangesproken te worden. Het gaat dus niet via je RAM (juist andersom, je RAM gaat via de cache). Dat het origineel wel uit het RAM komt is natuurlijk waar, maar dat is niet wat je zei. En daaruit volgt dat bandbreedte weldegelijk afhangt van of iets in de cache staat of niet, door het simpele feit dat de bandbreedte naar de cache veel hoger is.

(Overigens mapt niet alleen RAM op geheugenadressen. Ook peripheral data (zoals bijv. de framebuffer van je videokaart) is gemapt op een geheugenadres. Nou is dat meestal niet gecached, maar het kán wel. En het is zelfs mogelijk om bepaalde geheugenadressen cache-only te maken - dan is het dus niet eens een mirror. Dit is handig voor communicatie met andere cores of andere hardware. De Xbox360 is een mooi voorbeeld, gezien het feit dat de GPU tussen de CPU en de L2 cache in zit is het mogelijk om te communiceren met de GPU via de L2 cache zonder dat je ooit geheugen ervoor aan hoeft te spreken, wat natuurlijk veel sneller is)

en wordt uitgevoerd aan de hand van de prediction data technieken.

Misschien moet je maar eens gaan uitleggen wat je nou exact met predictiondata bedoelt. Want je visie op het onderwerp is nogal, hoe zullen we het zeggen, controversieel. Ik denk dat deze discussie vooral misloopt door gebrek aan terminologie aan jouw kant. Je bedoelt het wellicht wel goed, maar het komt totaal niet over.

Er is echter 1 uitzondering en dat is uitwisselbaar Data tussen meerdere cores dit kan wel enigszins gezien worden als zelf aangemaakte data

Je kunt als applicatie niet direct communiceren met andere cores, dat gaat via het geheugen danwel via de cache. De memory controller zelf zorgt er natuurlijk wel voor dat als iemand een write doet naar een bepaald adres, dat de caches die andere cores eventueel hebben van dat geheugen als invalid gemarkeerd worden, of dat als je een read doet wat bij iemand anders nog in de cache is aangepast, dat je dan die waarde pakt. Dit heet cache coherency.

[Reactie gewijzigd door .oisyn op 31 juli 2024 17:56]

[Verwijderd]

Lijkt mij dat een L(evel) 3 cache toch een aanslag (je) is op de (overall) snelheid/performance van het systeem is als je die weglaat.Die caches zijn er toch om snel(ler) toegang tot de data te verschaffen zonder eerst de hdd te moeten raadplegen en dus te belasten met het zoeken ernaar op zo'n mechanische schijf.Het zoeken in een zo'n stukje geheugen (de cache) is sneller, veel sneller.
Maarja. Inderdaad. Daarentegen staat een lagere prijs.Een compromie moet er zijn.

[fevenhuis]

Nee de cache levels op een processor hebben helemaal niets te maken met de cache van een HD. De cache op een processor is voor het cachen van instructies niet voor her cachen van data op de harde schijf.

[.oisyn]

De cache op een CPU is voor zowel instructies als algemene data dat doorgaans uit mem komt. En memory wordt door het OS dan weer vaak ingezet als cache voor de hdd. Dus in een CPU cache kan weldegelijk hdd data gecached staan

[ericcgg]

Je bedoelt waarschjinlijk werkgeheugen. Nog steeds veel trager dan cache, mits er goed voorspelt is

[ipazza]

In hoeverre je Wiki kan vertrouwen:

http://en.wikipedia.org/wiki/CPU_cache

[Astennu]

De Performance zal in de meeste gevallen gelijk zijn aan gelijk geclockte Phenom 1 cpu's. Soms zijn ze iets sneller soms iets trager. Maar meestal ongeveer even snel. Alleen dan met een veel lager verbruik. En een betere overclockbaarheid.

[siepeltjuh]

Het degradeerd de performace in veel gevallen. Sommige applicaties hebben er meer last van dan anderen, maar je kan stellen dat over het algemeen de processor een dikke 10% minder presteerd dan dezelfde cpu met L3 cache.

Of het voor photoshop relevant is weet ik eigenlijk niet, daarvoor zou je een benchmark moeten opzoeken.

[Verwijderd]

10% is erg veel en het aantal gebruiksscenarios waarin dat voorkomt is erg gering.
Zoek maar naar reviews van de Phenom II X2 550 / Athlon II X2 250.

[PegOpDeWeg]

sinds CS4 GPU power gebruikt is het totaal irrelevant geworden hoe goed de processor presteert, zelfde voor videobewerkingen.

Wordt wel een hele goedkope upgrade zo, voor 260 euro incl verzenden heb je een quadcore, Gigabyte mobo en 4gb ocz geheugen bij elkaar gesprokkeld.

Dat is gewoon spotprijsje!

[Reactie gewijzigd door PegOpDeWeg op 31 juli 2024 17:56]

[Verwijderd]

Helaas, dat GPU gebruik van CS4 is een pure marketing. In de praktijk wordt het nauwelijks gebruikt. Maar een paar filter, en zelfs dan is het nut gering. Dat hele GPU verhaal mag je voorlopig vergeten.
CS4 kan echter wel prima multi-threaden. Een quadcore heeft dus absoluut nut.

[Stefanovic45]

Vooral games hebben baat bij L3 cache. Kijk ook maar eens naar deze review op hardware.info

[Ventieldopje]

Valt nog wel mee, hij loopt in games ongeveer gelijk met de AMD Phenom II X4 920 die toch weer 40 euro duurder is. Ik zit er sterk over te denken naar deze te upgraden!

[quazar]

Volgens de test op hardware.info is de CPU erg snel
Tenminste, zolang de 4 cores ook echt gebruikt worden door de software. Worden de cores niet gebruikt dan is een dual core van de zelfde prijsklasse veel neller.

edit: ik moet toch sneller typen

[Reactie gewijzigd door quazar op 31 juli 2024 17:56]

[brompot758]

In het artikel wordt aangegeven dat alle Phenom II's 125W zouden verstoken, maar dan wordt de E serie vergeten, zoals de 905E. Dat is een quad core, met level 3 cache die 65W verstookt. Die zijn wel een stuk duurder dan de 620, maar je hebt dan een nog lager energie verbruik en toch je L3 cache.

30 watt verschil, 2 euro per jaar per watt is 60 euro verschil in een jaar voor een 24/7 machine. In anderhalf jaar heb je dan het prijsverschil eruit. En natuurlijk scheelt het idle minder, maar het loont de moeite om e.e.a. even met elkaar te vergelijken.

[poepkop]

Nu ga je uit van het maximum verbruik. Ik denk dat het verbruik niet zo ver uit elkaar zal liggen, zeker bij een 24/7 idle machine. En een beetje ondervolten kan ook werken.

[7th]

http://www.hardware.info/...D_Athlon_II_X4_620_test/7
en
http://www.hardware.info/...D_Athlon_II_X4_620_test/8

AMD Phenom II X4 810 2.60 GHz, L2: 4x 512Kb , L3: 4 MB
vs
AMD Athlon II X4 620 2.60 GHz, L2: 4x 512Kb , L3: niet aanwezig.

Bij test 7 scheelt het maar 7 fps
en bij test 8 scheelt het maar 5 fps

Zo veel effect heeft die 4mb L3 cache niet he.

[DCK]

Volgens Anandtech haalt de Athlon II X4 630 vergeleken met de Phenom II 920 (allebei 2.8 GHz en 95W TDP) in 5 benchmarks gemiddeld 91% van de prestatie.

In videocreatie was hij zelfs beter. Dat is waarschijnlijk omdat videodata sowieso uit geheugen moet komen (L3 cache is daar veel te klein voor), en dat de Athlon niet in zijn L3-cache hoeft te zoeken om erachter te komen dat ie de data uit het geheugen moet lezen.

[Ghostface9000]

Ben ook benieuwd wat dat eigenlijk juist betekent l3 cache ... Graag wat info van iemand

[legofanaten]

Correct me if i'm wrong maar kort door de bocht:

Een processor leest instructies uit het geheugen voor hij ze kan uitvoeren. Geheugen (RAM) is relatief groot (aantal GB) maar relatief langzaam. Omdat een processor een groot deel van de tijd uit zijn neus staat te eten zijn er zogenaamde caches geintroduceerd: Snelle kleine geheugens waar een deel van de geheugeninhoud in staat.

De L1 cache bevind zich fysiek het dichtst bij de processorkern en is het snelste en kleinste geheugen dat beschikbaar is. L2 is groter en langzamer, L3 is weer iets groter en iets langzamer.

Als een processor een nieuwe instructie wil, vraagt hij deze op uit het L1 cache. Zit het daar niet in, dan wordt de data in de L2 cache opgevraagd. Staat het ook niet in de L2 cache, dan wordt de L3 cache geraadpleegd. De volgende in lijn is het hoofdgeheugen (ook bekend als RAM). Als het ook daar niet in staat moet het van de harddisk komen. Omdat de instructies vaak op eenvolgende geheugenadressen staan is de kans dat de benodigde data niet in de caches staat relatief klein, doordat bij het laden van informatie in de caches meerdere opeenvolgende adressen tegelijk worden geladen.

Als er geen L3 cache aanwezig is, moet dus eerder het langzamere hoofdgeheugen worden aangesproken en is de kans dat de volgende instructie/data snel beschikbaar is voor de processor kleiner.

[Stefanovic45]

Ik vind het TDP nog fors. De X4 945 heeft ook een TDP van 95 watt, is geclockt op 3 Ghz en heeft ook nog eens L3 cache. Ik denk dat het gewone deneb cores zijn, gebaseerd op yields die superslecht zijn, en dus in verhouding een hoge spanning nodig hebben...

[Verwijderd]

TDP != verbruik, zal waarschijnlijk niet ver boven de 65w zitten.

Edit:

Later zal AMD ook nog de Athlon II X4 600E, 605E en de 630 uitbrengen

AAAAAH! Wanneer komen er nou die 45w quadcores!

[Reactie gewijzigd door Verwijderd op 31 juli 2024 17:56]

[Stefanovic45]

En meer spanning is ook een hoger verbruik

De standaard Vcore schijnt behoorlijk te liggen, dat is ergens te lezen in het AMD discussie topic

[mieJas]

Inderdaad. Dat voltage kan relatief gemakkelijk naar beneden gehaald worden, zonder in te boeten aan stabiliteit. Zo draait mijn X4 9650 op 1.1 V ipv 1.35. Loopt koeler en verbruikt minder.

Het zou me dus niet verwonderen moest die 620 onder de 65 Watt te krijgen zijn. Vooral omdat je je niet moet afvragen of het L3 cache wel stabiel draait; het is er niet.

[Dark_man]

Tuurlijk ga je denken dat het Deneb cores zijn als je het artikel niet leest waarin staat dat het Propus cores zijn die zijn geproduceerd juist zonder L3 cache om de kosten te drukken...

[Stefanovic45]

Tuurlijk ga je alles geloven wat er wordt geschreven.

Als je je meer verdiept in de processor lijn van AMD weet je dat er bepaalde processor te unlocken en terwijl het toch 'echte' dual cores ware...

[Sinester]

alleen hebben die allemaal de zelfde code naam, en deze is anders.
Plus het was al langer bekend dat AMD een aparte lijn zou opzetten zonder L3

[MatthiasDS]

Ik vind het TDP nog fors.

Ik ook. Ik wil upgraden naar een budget-quadcore systeem, maar de hoge TDP houdt me eigenlijk tegen om deze te nemen.

Denk dat ik maar voor de Ph II X4 810 ga. Lijkt me voor de prijs (€125) ook wel een zeer leuke CPU. Met 4MB L3 cache.

[poepkop]

De TDP bij AMD is het maximum verbruik (voor mobo-fabrikanten eigenlijk) en de TDP bij Intel onder 80% load. Ik ga er vanuit dat deze proc niet meer dan 65 zal verbruiken. Op kantoor hebben wij x2's die ook 95watt zouden verbruiken, echter verbruikt het totale systeem maar 105 watt onder full load (hd, 2x2gb ram, dvd speler en 8400 of 3450).

[MatthiasDS]

De TDP bij AMD is het maximum verbruik (voor mobo-fabrikanten eigenlijk) en de TDP bij Intel onder 80% load.

Klopt niet. De TDP bij Intel is het "gemiddelde maximum" dat kan gehaald worden gedurende korte tijdsperiodes. Je kan er enkel met een zeer kortstondige piek van een paar ms boven. Het gaat dus wel degelijk over het maximumverbruik. Tweakers heeft hier een interessant artikel over, maar ik heb weinig zin om dat te zoeken

Als de 620 niet meer dan 65 kan verbruiken, dan hadden ze hem wel in die klasse gestoken lijkt me? Of springt AMD ineens van 45 naar 95?

[Verwijderd]

Zie het nut niet echt van deze cpu's. Als je een quadcore nodig hebt voor taken, dan zijn het programma's die veel nut hebben aan gedeelde cache. Je kan dan wel zeggen dat je een goedkope quadcore hebt, maar voor dat beetje meer geld zou ik een nuttige config maken en een x4 nemen waar de cache wel opzit.

[Verwijderd]

De Core 2 Quad's presteren ook behoorlijk goed, ondanks dat ze bestaan uit twee chips verbonden met de FSB, en dus zonder L3 cache.

Het klopt dat Core i7 beter presteert doordat de communicatie tussen de cores sneller is, maar echt desastreus is het niet om geen L3 cache te hebben. De meeste multi-threaded programma's minimaliseren de traffiek tussen de cores en doen zo veel mogelijk hun werk onafhankelijk.

Dit is dus een erg mooie chip voor z'n prijs, lijkt mij.

[.oisyn]

De Core 2 Quad's presteren ook behoorlijk goed, ondanks dat ze bestaan uit twee chips verbonden met de FSB, en dus zonder L3 cache.

Dat kan best, maar die hebben alsnog een vrij grote L2 cache (8 - 12 MB in totaal). De L2 cache van deze CPU is praktisch niets (512kB per core, 2 MB in totaal).

[Countess]

die 8mb is ook al aardig excessief, en de prestatie winst is meestal aardig gering.

zeker als je geheugen redelijk snel is zullen in heel veel taken het verschil tussen deze cpu en de phenom 2 klein zijn op gelijke frequentie.

http://www.hardware.info/..._Athlon_II_X4_620_test/19

"on workloads als videocompressie of 3D-rendering kan de budget CPU zich meten met processors die minstens twee keer zo duur zijn. De vrijwel even dure Phenom II X2 550 en Core 2 Duo E6500 steken er een beetje schraal bij af."

voor de prijs maakt hij dus gehakt van alles als het programma multithreaded is.
als je programmas dat niet zijn kan je zowiso beter een dual-core kopen als je de beste prijs/prestatie verhouding wilt, met of zonder L3.

in games scheelt het nog geen 10% meestal met een gelijk geklokte phenom2, maar wel voor 50% minder geld.

edit : heb je mijn laatste zin niet gelezen ofzo?
ze hebben ook games getest en in vergelijking met de x810 (gelijk geclockte phenom II) scheel het bij crysis 3 FPS van de 40. ~7% dus ongeveer.
bij UT was het 7 FPS verschil maar wel op 119 FPS, dus iets meer als 8%
bij 3dmark en zeker bij world in conflict is het verschil zo klein dat het helemaal verwaarloosbaar is.
ik weet niet wat voor games je maakt, maar als het intensive 3d games zijn zal het in de meeste gevallen beter zijn om die ~50 euro die je bespaard op een athlon II in je videokaart te stoppen dan uit te geven aan een phenom II

[Reactie gewijzigd door Countess op 31 juli 2024 17:56]

[.oisyn]

"on workloads als videocompressie of 3D-rendering kan de budget CPU zich meten met processors die minstens twee keer zo duur zijn. De vrijwel even dure Phenom II X2 550 en Core 2 Duo E6500 steken er een beetje schraal bij af."

Ja duh, je hebt het dan over usecases waarbij je sowieso altijd cachemisses gaat hebben. Ga je kijken naar andere toepassingen, zoals games, dan is het resultaat ineens heel anders. Ik ben het ook totaal niet eens met het stukje wat ze even verderop plaatsen:

Zodoende valt de processor in onze game tests een beetje door de mand. Toegegeven: in de toekomst wordt meer en meer software multi-threaded - ook games! - maar op dit moment is dat zeker nog niet altijd het geval.

Nou maken wij zelf multithreaded games, en ik kan je verzekeren dat uit regelmatige benchmarks van de code die we schrijven blijkt dat cache weldegelijk een heel erg belangrijke factor is. Als je je code zo schrijft dat je van tevoren rekening gaat houden met wat je gaat lezen, en er dus ook voor gaat zorgen dat je expliciet dat geheugen al in de cache gaat laden, dan kunnen bepaalde delen zo een factor x sneller performen. Ik heb zelfs cases gezien waarbij een stuk code ineens 2x zo snel draait nadat in een stuk ongerelateerde code wat ervoor komt veel minder geheugen getouched wordt (waardoor de contents die het volgende stuk code nodig heeft dus in de cache blijven staan ipv eruit geknikkerd worden)

.edit:

edit : heb je mijn laatste zin niet gelezen ofzo?

Euh nee, eerlijk gezegd niet. Stond ie er eerst ook al? In dat geval, excuses. Anyway, daar ben ik het verder helemaal mee eens. Maar ik had het dan ook niet over een kosten/baten analyse, ik had het puur over het nut van cache. Maar ik snap nu dat dat juist wel de focus van je post was. Dat je met deze CPU meer waar voor je geld krijgt is helemaal waar.

Overigens reken je verkeerd. De eenheid FPS is namelijk de inversie van wat je eigenlijk wilt weten, namelijk de tijd per frame (en dus niet frames per tijd). Als iets eerst 20FPS was, maar daarna 30FPS, dan is het niet 50% sneller, maar 33% sneller. Of anders gezegd, het kost maar 67% van de tijd om hetzelfde te doen (want de frametijd gaat terug van 50ms naar 33ms). Maar bij kleine percentages komt dat wel ongeveer overeen. Daarnaast zegt dat niets over de snelheid van de CPU zelf, aangezien er nog veel meer factoren aanwezig zijn. Voor games die CPU bound zijn (wat het geval is als je een hele snelle GPU in je bak hebt zitten), dan zullen de verschillen veel hoger zijn. Wat dat betreft is het jammer dat ze geen game als Supreme Commander hebben getest, die juist heel veel baat heeft bij CPU kracht.

k weet niet wat voor games je maakt

Momenteel zijn we met Tomb Raider: Ascension en Deus Ex 3 bezig. Had je trouwens ook gewoon in m'n profiel kunnen lezen

[Reactie gewijzigd door .oisyn op 31 juli 2024 17:56]

[Countess]

okee het was even zoeken maar ik heb wel een benchmark gevonden waar je een apples vs apples vergelijk kan maken van het verschil in cache bij supreme commander
niet van de athlon II jammer genoeg (is er gewoon niet denk ik), maar met de atlon64.

http://www.tomshardware.c...upreme-Commander,397.html

als je naar de athlon 64 x2 4800+ en de x2 4600+ kijkt zijn ze verder gelijk, maar de 4600 heeft maar 512kb cache en de 4800 1MB.
het verschil is 30.28 en 30.8 FPS.
als cache bij dit spel echt zo veel uit maakt zou je toch een iets groter verschil verwachten bij de verdubbeling van de cache.
CPU kracht is zeker belangrijk bij dit spel, wat goed te zijn is bij het verschil tussen single en dual cores maar de Cache lijkt me daarbij duidelijk van secondair belang. (wat best kan kloppen want het is wel reken intensief, maar weinig geheugen intensief)

Voor games die CPU bound zijn (wat het geval is als je een hele snelle GPU in je bak hebt zitten), dan zullen de verschillen veel hoger zijn.

dat klopt... maar mijn theorie is dan dat je eigenlijk een te dikke videokaart voor je scherm (resolutie) hebt gekocht, dat je de AA en AF hoger moet zetten of dat je FPS toch al hoog genoeg zijn dat het niet meer uit maakt.
dat zal vast niet altijd kloppen, maar meestal komt het aardig in de beurt.

[Reactie gewijzigd door Countess op 31 juli 2024 17:56]

[.oisyn]

Sorry, maar ik heb zo mijn twijfels over de validiteit van de benchmark. Ze zeggen:

Performance of 60 seconds of game play is measured in this DirectX 9.0c title based on the Moho engine

Als ze gewoon de game hebben gestart dan heeft ie helemaal nog niet zoveel CPU nodig. Ze moeten een skirmish spelen tegen een stuk of wat AI's, en dan kijken hoe de game zich na 3 oid uur gedraagt.

[Malantur]

Als je een quadcore nodig hebt voor taken, dan zijn het programma's die veel nut hebben aan gedeelde cache.

Dat mag je toch wel even verder onderbouwen.
Volgens mij is er weinig verband tussen een quadcore nodig hebben en L3 cache.
Er zijn vast wel programma's die multithreaded zijn en veel instructies nodig hebben, maar er zijn toch ook mensen die gewoon 4 verschillende programma's tegelijk willen draaien? De kans is ook groot dat er programma's zijn waarbij de instructies helemaal in de L2 cache geraken, en er zijn waarschijnlijk ook programma's die niet erg afhankelijk zijn van geheugen.
Ik moet toegeven dat ik zelf geen expert ben, maar jou reactie een beetje kort door de bocht...

[Verwijderd]

En bijna alle mensen die met 4 programma's alle 4 de cores volkrijgen zullen dus nut hebben aan L3. Zo'n gebruik krijg je bij en/decoderen, renderen, meerdere games tegelijk draaien, folding, ... Allemaal taken waar L3 een verschil maakt. Bij VM's weet ek niet meteen of L3 een verschil maakt maar daar ben je eerder beperkt met het geheugen dan de processorkracht.

Imo ben je voor die prijs beter af met een zware dualcore/tricore met cache, dan een trage quadcore zonder.

[Malantur]

Quote uit de review van hardware.info:

In workloads als videocompressie of 3D-rendering kan de budget CPU zich meten met processors die minstens twee keer zo duur zijn.

Voila, voor renderen gaat de vlieger al niet op

Ik denk dat vooral pc's van bijvoorbeeld Aldi dit zullen gebruiken als marketting. Een goedkope pc met een quadcore en wat kan het de gemiddelde consument schelen of er nu wel of geen L3-cache op zit? Als ze het al weten...

[DjVe]

jah daar zat ik dus ook aan te denken...leuk zo'n cpu, maar als de communicatie met je overige HW niet snel genoeg is, doordat je geen L3 hebt...wat heb je dan aan je quadcore?


edit: typo

[Reactie gewijzigd door DjVe op 31 juli 2024 17:56]

[Sinester]

Dus een quadcore zonder l3 cache is niet nuttig.

L3 cache is geen heilige graal, en word hier volgens mij ook zwaar overschat
Plus goedkoper en meer opties is altijd nuttig

[Madrox]

Lvl 3 cache zorgt bij bepaalde programma's voor performance winst, in andere gevallen maakt het niet/vrijwel niks uit. Meer cores kan echter in bepaalde gevallen voor extra performance zorgen.

Zover ik weet helpt lvl3 cache bijv. weinig tot niets bij games. Dit zou dus een perfecte budget game processor kunnen zijn. en het het is natuurlijk kolder om te zeggen dat zonder lvl3 cache je pc ineens niet meer snel genoeg communiceert. Natuurlijk, het zal in sommige situaties niet zo snel gaan als de cpu's met lvl3 cache. Voor de meeste thuisgebruikers zal het echter nog steeds snel genoeg zijn.

De Intel Celeron vroeger, werd ook erg sceptisch over gedaan. Die miste ook alle/veel cache en zou volgens velen een brakke processor zijn. Maar hoe anders ging het; de Celeron was een van de best verkochte Intel cpu's! Ze klokten ook nog eens over als een speer!

Ps: Deze chip valt ook lekker te océn:
http://www.tweaktown.com/...or_mainstream/index9.html
(zie gelijk ook hoe sterk de core2duo E8500 het doet tegenover de Phenom II x4 855 ;-))

Op de vraag of er een markt is voor dit soort chips durf ik dan volmondig te zeggen: JA!

[Reactie gewijzigd door Madrox op 31 juli 2024 17:56]

[pilo2710]

Even Googlen en een berg resultaten:

http://www.wisegeek.com/what-is-l3-cache.htm

De definitie op een andere site:

As more and more processors begin to include L2 cache into their architectures, Level 3 cache is now the name for the extra cache built into motherboards between the microprocessor and the main memory.
Quite simply, what was once L2 cache on motherboards now becomes L3 cache when used with microprocessors containing built-in L2 caches.

[DjVe]

maar wat is dan ineens de technologische stap vooruit, waardoor er geen L3 meer nodig is?

[Amazigh_N_Ariff]

de L3 cache beslaat bijna 50% van een phenom die.
wanneer je een procs kan produceren die 10-15% procent minder krachtig is voor de helft van de prijs dat tikt het aardig

[freaq]

je zou bijna zeggen maak een octocore, zonder l3.
en dan heb je dezelfde diespace in gebruik,
neem aan dat dat toch flink beter presteerd dan een quadcore met L3

[DjVe]

waarom dan...je cache communiceert toch met je RAM. Dus als dat niet snel genoeg is, dan heb je toch ook niets aan die cores of sla ik nou 5 meter naast een plank?

[YopY]

'niets' is misschien sterk, maar ze zitten dan in verhouding wel langer te wachten op nieuwe gegevens en instructues.

[Rob Krauts]

Dat zou jammer zijn.
Dat betekent dat de processor duurder wordt, warmer wordt en meer verbruikt. En dat terwijl zoveel cores niet gebruikt als consument.

[Mr D]

Als je alle 8 cores van voldoende data kan voorzien, zodat ze niet uit hun neus zitten te vreten, en er voldoende threads zijn om alle cores bezig te houden, zou dit beter kunnen presteren. Misschien als je dan ook het aantal DDR3 kanalen verdubbeld. (quad channel DDR3 ) Maar dan moet er ook een nieuw processorvoetje komen.

Laten we nou geen core-race beginnen, net nu de MHz race is afgelopen, en zeker geen RAM-channel race.

[Reactie gewijzigd door Mr D op 31 juli 2024 17:56]

[Verwijderd]

Denk niet dat die er is maar dat het juist de reden is waarom dit een Buget quadcore is. Voor 85 euro op de eerste rang zitten dat is er nog nooit bij geweest.

Ben wel benieuwt waar die nou tussen gaat vallen/Mee te vergelijken is.

[Reactie gewijzigd door Verwijderd op 31 juli 2024 17:56]

[Stefanovic45]

Geen

Dit is gewoon een beperking van deze CPU, daar is de prijs ook naar.

[NL-RaVeR]

Voor die mensen die wel rekenintensief werk (willen) doen, maar toch een klein budget hebben is dit een perfecte optie. Je hebt toch meer "ruwe" rekenkracht als een dualcore van ongeveer hetzelfde prijs segment. Natuurlijk moet je zo'n cpu niet gaan gebruiken in een Game Rig, want games hebben nou eenmaal veel baat bij meer cache.

Ik denk dat veel fabrikanten van complete systemen dit als een mooie kans zien om goedkope quadcore desktops te maken voor bedrijven/consumenten. De normale consument neemt nou eenmaal eerder de keuze voor een Quadcore pc van 400 euro, dan voor een Dualcore pc van 380 euro, ook al zou de dualcore in werkelijke prestaties beter presteren.

[Verwijderd]

Natuurlijk moet je zo'n cpu niet gaan gebruiken in een Game Rig, want games hebben nou eenmaal veel baat bij meer cache.

Toch wel. Geen enkele dual-core, ongeacht de hoeveelheid cache, blijkt te kunnen tippen aan deze quad-core:

http://www.hardware.info/...D_Athlon_II_X4_620_test/5

[Malantur]

In de syntetische benchmarks..
In de echte games wordt hij voorbijgestreefd door de E7xxx serie van Intel, en de Phenom II X2 5xx serie van AMD.
Maar nog steeds wel mooie prestaties voor de prijs!

[Verwijderd]

3DMark is een representatie van toekomstige games, geen synthetische benchmark.

Er komt steeds meer software die goed gebruik maakt van vier threads of zelfs meer. Dus een quad-core kopen is erg interessant en je kan er meteen enkele jaren mee verder. Een dual-core aanschaffen is stom, die kan binnenkort niet meer mee.

[Sinlath]

Yes! én op AM2+ én goedkoop én quadcore, een ware must have voor de onwetende die een quadcore wil hebben.

vermoedelijk gaat deze ongeveer hetzelfde presteren als een "normale" dualcore maar deze proc zal in het budget segment langer meegaan.

[TIGER79]

nou bij multi-core applicaties zal die wel degelijk beter presteren, dus kan nog niet echt aangegeven worden dat ie hetzelfde presteert als een dual-core...

[Toontje_78]

Onwetende?

Daar was de Q8200 al voor. Bij deze weet je dat het mainstream cve genaamd is.