"Als je code kunt optimaliseren zodat het sneller op de atlon64 loopt, is de athlon64 dus de snellere processor."
je zegt nogsteeds helemaal niks hiermee dus
Jawel, ik zeg dat geoptimaliseerde software ook meetelt (ongeacht de processor).
en het gaat je wel aan waarom de cpu sneller is want jij wilde beweren dat de encodeers test onomstotenlijk aan zou geven dat de p4 de meeste bandbreedte had.
die bewering heb ik dus al lang en breed uit het water geschoten.
Nee hoor, je hebt gewoon een oude benchmark opgevist waar een oude P4 nog DDR400 gebruikte en dus ook een bandbreedte-limiet had...
Bewijst alleen dat je niet weet waar ik het over heb.
ummm hij krijgt met ddr2 dus in theorie 2 keer zo veel bandbreedte als voorheen, en heeft daardoor een geheugenbandbreedte te kort opgelopen.... natuurlijk.
het enige dat er gebeurt kan zijn is dat de bottlenek zich heeft verplaast (naar de verwerkings units), niet dat er voor de k8 een probleem bij is gekomen.
Dat is natuurlijk onzin.
Het probleem is dat er nu veel sneller geheugen is, maar dat de Athlon er geen gebruik van kan maken, en dus niet sneller kan worden, terwijl de Intel-CPUs wel sneller zijn geworden.
Bottlenecks zijn nooit goed, zeker niet als ze hetgene zijn waardoor je de concurrent niet meer bij kunt houden.
behalven dan dat de L1 2 keer meer bandbreedte heeft als de L2 waardoor jouw fabel dat AMD een bandbreedte te kort heeft aardig op de tocht komt te staan.
Wat is dit voor onzin? Communicatie wordt bepaald door de zwakste schakel. L1 kan dus nooit sneller met L2 communiceren dan L2 toelaat. Net zoals L1 (danwel L2, afhankelijk van de implementatie) nooit sneller can communiceren dan het geheugen toelaat.
Jij noemt de bandbreedte van execution pipeline tot L1-cache, die is voldoende ja, maar dat is eigenlijk per definitie zo, je kopieert gewoon een variabele van of naar een register in 1 operatie. Vandaar dat ik aangeef dat je bij dergelijke kleine operaties vooral op de latency moet letten. En die is niet zo best.
Ook het lezen en schrijven van cachelines van en naar geheugen gaat niet zo best (en of dat nou door L1 of L2 komt, is niet relevant).
Daarom heb je dus snel geheugen en een onboard memorycontroller, maar kun je eigenlijk nergens heen met al die data. Als jij dat geen probleem vindt, wil je zeker geen snellere processor?
je hele basis aannamen is verkeerd hoe kan je dan ingaan op de kern van het verhaal!
Niks basisaanname, betekenisloos detail. Basisaanname is dat de cache te langzaam is. Of je dat nou L1 of L2 noemt maakt voor het verhaal niet uit.
de CPU weet al wat er wel en niet in de cache zit, die hoevt de L2 cache zelf niet aan te spreken om dat bij te houden.
Het is gebruikelijk om ook de boekhouding tot de cache te rekenen (er komt meer bij kijken dan alleen een stukje geheugen, een cache is een functioneel blok). Sowieso wordt de cache als onderdeel van de CPU te zien, dus inderdaad, alles wat de cache weet, weet de CPU ook, maar dat is zo nietszeggend. Als de cache het niet weet, weet de CPU het ook niet, en dat is het verhaal.
je denkt nog veel te veel op de intel manier.
de fetchers spreken alleen het L2 aan als daar iets zit wat ze ook daarwerkelijk nodig hebben, zit het niet in de L2 dan word die bandbreedte helemaal niet aangesproken, in tegenstelling tot wat er bij intel gebeurt.
Alsof Intel de cache heeft uitgevonden...
Wat een onzin. Je haalt opslag en boekhouding door elkaar.
Je weet pas of iets in de cache zit, als je in de bijbehorende tabellen hebt gekeken.
Iedere cache weet alleen wat ie zelf bevat. Als ie ook een niveau lager zou moeten bijhouden, zou de complexiteit veel te groot worden, evenals de opslag voor de tabellen, en zou de verwerkingssnelheid inzakken, waardoor je L1 in feite devalueert tot een L2 met een beperkte eigen opslag.
L1 doet dus alleen een check op zichzelf. Is er een hit, dan meteen teruggeven, zo niet, dan doorgeven naar L2-cache. Die doet hetzelfde, etc... totdat het ergens uit het geheugen wordt gehaald.
Anders zou cache nooit snel kunnen zijn, en heb je er niks aan.
sinds waneer is 2x64bit op 2 tot 3 ghz traag?
op 2 ghz is dat 32GB/s op 3 ghz is dat zelfs 48GB/s
Nogmaals, je verwart de bandbreedtes.
2x64 bit is van L1-cachehit naar execution pipeline, ik heb het hier over cache naar geheugen.
L1 kan echt niet met 48 GB/s uit geheugen lezen, dat snap je toch zelf ook wel?
alsof de exection pipeline moet wachten tot de die cache evict is gebeurt. daar heeft AMD gespecializeerde units voor die dat bij houden en dat gebeurt geheel buiten de normale data verwerking om en heeft er daarom dus ook weinig of geen effect op.
Voor zover ik weet gaat dat gewoon over dezelfde bus tussen L1 en L2-cache, dus heeft de core er indirect last van, omdat er bandbreedte verloren gaat.
Een evict van L1-cache kan ook weer een evict van L2-cache tot gevolg hebben... en dat gaat dan weer via geheugen, en dat is ook 1 bus.
Sowieso zit er een bepaalde verwerkingstijd aan die operatie, dus ben je minder efficient bezig. De data is pas beschikbaar als de operatie verwerkt is.
Je kunt er lang en breed over zeuren, maar feit is wel dat de caches van Intel lagere latency hebben, en betere associativiteit.
Ik vind dit een plausibele verklaring voor de problemen van de Athlon-cache.
Als je het er niet mee eens bent, waar ligt het volgens jou dan wel aan?
wat jij "normale" cache noemt is cache op de intel manier. dat is niet normaal of abnormaal, maar gewoon anders.
Intel en alle andere fabrikanten ja. Is dus de de-facto standaard, wat je wel normaal kunt noemen.
je bent nu gewoon alleen maar aan het speculeren, en je vastgeroeste ideenen over hoe cache beheerd moet worden op de intel manier aan het projecteren op AMD's manier van aanpak.
Zo zou ik het niet willen formuleren. Ik zou eerder zeggen: de winnede fabrikant heeft altijd gelijk.
Een andere aanpak kan verfrissend zijn, maar als het niet de gewenste resultaten brengt, moet je ook reeel zijn, en die aanpak loslaten.
Verder vind ik dat Intel-Intel gezeur van je wel grappig, want ik ben eigenlijk Motorola/IBM-fan, en ik vind die hele x86-bende eigenlijk helemaal niks.
Ik heb niks met Intel, en ook niet met AMD, misschien dat ik daarom zo'n heldere visie erop heb.
o ik weet niet hoor, maar misschien dat de verbreede SSE unites er iet mee te maken hebben, en smart caching en smart memory access bijvoorbeeld.
daar ligt de kracht van de core2, en het is niet het te kort aan interne bandbreedte in de k8.
Hebben bredere SSE-units, smart caching en smart memory access niet toevallig alles met interne bandbreedte te maken? Lijkt mij wel. Wat toevallig zeg!
Zou ik dan toch gelijk hebben?
intel heeft marktaandeel verloren. vraag naar intel cpu's is dus verlaagt.
Niet sinds april, voor zover ik weet.
intel raakt echt niet several million aan overschot kwijt in 2 maanden
Hoeft ook niet, als ze maar inlopen.
kijk eens naar het geheel. intel had een overschot, de vraag is niet toe genomen en ze hebben de productie niet verlaagt.
sorry hoor maar elke econoom kan je vertellen wat er dan gebeurt met de inventaris.
Elke econoom zal mij gelijk geven dat je voor twee verschillende producten ook twee verschillende markten hebt, en dat je dus de vraag per markt moet bekijken.
En dat gegeven ontbreekt in jouw informatie.
enige conclusie mogenlijk : intels voorraad netburst is sindsdien alleen maar gestegen.
Je snapt het echt niet, he?
Je hebt geen idee hoe de vraag tussen Core2 en Netburst zich verhoudt, dus kun je helemaal NIKS concluderen.
Er zijn drie mogelijke conclusies... Core2 < Netburst, Core2 == Netburst en Core2 > Netburst.
Afgezien daarvan komt de vraag naar Core2 NIET per definitie uit het marktaandeel van Intel. Ik denk dat die voor een deel ook uit het marktaandeel van AMD komt.
Kortom, je kunt de vraag en het aanbod absoluut niet zo simpel gelijkstellen als dat jij dat hier wil doen. Dat zal iedere econoom je kunnen vertellen.
zelfs als de overshotten aan netburst nu aan het dalen zijn is dat pas iets van de laatste 2 maanden en is intel dus nog lang niet door zijn gigantische voorraden heen.
Je hamert nu al dagen op dit punt, en ik heb het al eerder gevraagd... Maar: waar wil je nou naartoe hiermee?
Het boeit toch niet dat ze nog voorraden hebben zolang er vraag is? Ze gaan over op een nieuwe productlijn, dus het probleem lost zich vanzelf op.
Dan maken ze maar even verlies op wat Netbursts, boeiend... Intel kan wel een stootje hebben, zoals ik al zei.
AMD heeft jaren verlies gedraaid op hun processordivisie omdat ze hun CPUs aan de straatstenen niet kwijt konden. Die zijn er toch ook aardig bovenop gekomen toen ze eenmaal een goed product hadden?
Intel heeft dat goede product nu ook.
Kortom, ten eerste heb je geen idee over wat voor voorraden je praat, je raadt maar wat met verouderde informatie... Ten tweede heb je geen idee van wat de gevolgen zijn... dus het heeft er alle schijn van dat je maar wat zoekt om tegen Intel aan te kunnen trappen... Nou, leuk voor je. Ik zou me meer zorgen maken om AMD op dit moment.