ps heren laat hardware.info en vooral die linustechtips links liggen als het om cpu hardware gaat..
Er is maar 1 site waarvan de eigenaar zo slim is geweest om de studies te doen om te snappen hoe het nu wel werkt.
Nu is het zo dat je blij mag zijn dat je ongeveer 20% op school kunt leren, de rest moet je leren bij de asic fabrikanten zelf. De flow van software en hardware die benodigd is om een chip te designen is zo duur dat de uni's etc ook daar niet het geld voor hebben. (minimaal benodigde studie is HTS electronica, HTS technische computerkunde of hogere (uni) natuurkunde,
en psychologie voor hulp om de motivatie weer op gang te helpen als het team de design-win niet heeft behaald).
Kleine uitleg waarom deze sites niets snappen van IC ontwikkeling is. Het leek voor een auteur van hardware.info slim om een test te doen waarbij twee verschillende cpus, die voor verschillen frequentie waren ontwikkeld op de zelfde frequentie te laten lopen om zo de IPC en het stroom verbruik te vergelijken... KAN NOOIT!!! Elke chip wordt bij aanvang ontwikkeld met een target klok frequentie in gedachte. Of die behaald wordt is dan nog maar de vraag ivm temps. Een intel chip op 2.4Ghz of dezelfde voor 3.5Ghz zijn niet te vergelijken op dezelfde frequentie.
Kleine verkorte uitleg waarom niet.
Elke digitale chip bestaat uit twee delen. Het blok met combinatorische logica (and, or, nand, nor, xor, inverter, etc) en daarom heen de flipfloppen (8 flipfloppen maken een byte register). Tweede blok is daaraan nauw verbonden en heet de clock-tree. Voorbeeldje.. ik heb een blok met 2 input registers en een output register. Wat de functie is, is in dit voorbeeld niet belangrijk maar stel je telt de twee waarden met een logische and op. Als je nu per bit van de input register naar het output register de tijd die nodig is om door de combinatorische logica te komen (rippelen) bekijkt, zul je een bit vinden die het kortste duurt en een bit die het langste duurt. Uit deze twee tijden kun je de maximale clock waarop dit blok kan lopen berekenen. Stel het blok haalt 1.5GHz. Nu is de target 4.5Ghz. Wat nu.. dan kun je (als een van de mogelijkheden) 3 blokken er in stoppen en deze interleaved gebruiken, waardoor het lijkt of je een blok hebt dat op 4.5Ghz loopt. Als de target 3Ghz zou zijn geweest, had ze er waarschijnlijk maar twee ingebouwd.
Maar nu over stromen. Je kunt de stromen in pakweg 2 soorten verdelen. Schakelstromen die door de clock geiniteerd worden en de wel bekende lekstromen die niet afhankelijk zijn van de frequentie. Nu hebben we een cpu die 3 blokken bevat en een cpu die 2 blokken bevat. Welke zal nu het minste verbruiken bij 3Ghz.
De schakelpiekstromen die er zijn wanneer er een klok komt zijn niet geheel linear met de frequentie. Dit komt door afvlakking van de signalen door capaciteiten die steeds meer effect hebben bij hogere frequenties. Dus een schakelpiek stroom van een blok op 1Ghz zal iets lager zijn dan die van hetzelfde blok op 1.5GHz. Nu wordt dit verschil pas echt veel als je in de buurt komt van de maximale klok waarop de FET gespecificeerd is. 1Ghz en 1.5Ghz liggen nog zo ver van het maximale af dat een schakelpiek bij een frequentie van 1GHz nog nagenoeg gelijk zal zijn als die van 1.5Ghz.
Als we nu kijken naar 2 blokken op 1.5GHz dan heb je dus 3 Ghz aan schakelpiek stromen. Kijken we naar de 3 blokken dan zie je dat deze nog maar op 1GHz lopen en dus ook 3 Ghz aan schakelpiekstromen genereerd. Dus wordt het grootste verschil gemaakt door de lekstromen. En wat zal dus nu de uitkomst zijn. De cpu met 2 of die met 3 blokken? rara, tuurlijk die met 3 blokken gebruikt meer.
Nu een ander fabeltje wat ik veel hoor is mijn cpu crashed op temperatuur.. KAN NIET als hij werkelijk crashed op temperatuur, wordt de smelt temperatuur van het silicium bereikt en dan start de cpu nooit meer op. Alle crashes gebeuren door TIMING!!!!
Eerste timing probleem wat je kunt krijgen is niet afhankelijk van de temperatuur, nl. hoogst mogelijk klok is behaald van een combinatorisch pad.
De twee andere reden zijn afhankelijk van temperatuur.
- De 2de reden is door Clock-skew tussen clock-tree en het combinatorische deel. Als je door temperatuur een verschil in vertraging krijgt in de clock tree t.o.v. de floppen dan zal op een gegeven moment deze zover uit elkaar lopen dat de setup-en-hold tijden niet meer behaald worden.
- De 3de reden is door de flanktijden van de digitale signalen. Een digital signaal zal een steeds lange tijd nodig hebben om van de "0" naar de "1" stijgen als een geleider heter wordt (weerstand wordt hoger). Als je te ver gaat haal je de "1" niet meer op tijd voordat de klok komt (de bekende oogpatronen) dan zegt hij ook crash. (geld ook voor "1" naar "0" natuurlijk)
Als je naar de AMD kijkt loopt deze vast door, of een combinatorisch pad of clock-skew. Aangezien beter koelen geen resultaat verbetering opleverd. De Intel lopen vast door, of wederom clock-skew of door het niet behalen van de oogpatronen. Aangezien deze tot wel 5.8Ghz geklokt kan worden m.b.v. stikstof koeling. Dit betekent NIET dat intel het wel goed gedaan heeft aangezien met normale koeling dit nooit mogelijk is. De padden zijn onzinnig kort.
AMD kan dus het gelukt hebben dat de niet hogere clock door clock-skew komt. Dit is in vergelijking tot het andere probleem vrij (eenvoudig) op te lossen door het beter routen van de twee blokken (combinatorisch en de clock-tree) zodat deze evenveel vertragen oplopen bij hogere temperaturen en beide weer gelijk lopen. Mocht het komen door een combinatorisch pad dan zullen ze de VHDL moeten aanpassen om het langste pad wat korter te maken, wat veel meer tijd kost.
Intel daarin tegen heeft ook een fout gemaakt (zoals bijna alle asic bedrijven, ook AMD (zie buldozer cores op 6.2Ghz op youtube). Bij aanvang van een design wordt geschat wat de specs zijn van de FET (transistors) die over tig jaar gebruikt gaan worden om het design te produceren. Voor mijn pensioen was de vuist regel dat 1/6 a 1/5 van het totalen stroom verbruik van een gate (zie wiki) ongeveer de lekstromen waren. Dat is niet beter geworden maar veel slechter, waarbij intel en andere dachten deze wel beter zouden zijn. Hierdoor genereerd de asic veel meer warmte dan toen gepland was en waardoor de frequentie niet op de target frequentie kan lopen. Intel had verwacht de huidige asics op +/- 5.5GHz te kunnen klokken vandaar de korte combinatorische padden. Alleen, als je korte combinatorische paden maakt zul je meer floppen nodig hebben dan wanneer je het design had gemaakt met combinatorische padden die wat langer waren. Minder floppen, minder ruimte, en minder stroom verbruik.
Nu lees ik ook dat mensen tegenwoordig de volgende beste man als referentie gebruiken LINUSTECHTIPS... nauw ff kijken.. toen ik hem hoorde kletsen vroeg ik me echt af wat voor een diploma die gup heeft, skateboarden?..., hij lult leuk maar weet niks.
Vraag die gup maar eens over VHDL, verilog, setup en hold tijden, clock skew, langste combinatorische pad, antenne effecten, pad limited design, etc... denk dat hij nog nooit een stepper machine van dichtbij heeft gezien laat staan met cadence, synopsys of mentor graphics hun tools heeft gewerkt. Dus als je pro amd bent vooral naar hem luisteren hij wordt door amd betaald.
LINUS vroeg zich af waarmee intel nou bezig is, die zijn de weg kwijt.. uhm dubbele lus ombouwen naar matrix misschien?, en dat is heel veel werk voor een 18 core cpu. Het meest knappe daarin is dat alle latencies vanuit welke core dan ook gelijk zijn. Dat is erg veel werk om goed te krijgen bij het routen van de netlist. Vandaar dat deze 18 cores cpu al bijna volledig klaar was anders kunnen ze deze nooit zo snel op de markt brengen.
Ik was zwaar, zwaar teleur geteld door AMD... een 4 cores CPU en infinityfabric (verbeterde hyperbus en dat is dan weer een bus die gebaseerd is op de EV6 bus van digital). is dat alles? Een clustered CPU? ow nee ook de stempel is uitgevonden. Alle nadelen van een multi socket mainboard komen hiermee ook te voorschijn. Als AMD een uniform memory blok had gemaakt dan hadden ze pas echt een troef in handen, dan hadden ze hetzelfde kunnen doen wat een z mainframe ook kan, nl nagenoeg realtime tread verplaatsen. Iets wat intel eigenlijk niet nodig heeft maar wel doet om warmte te spreiden. Vandaar dat je in je taskmanager de cpu load ziet wandelen van core naar core. AMD kan het ook maar dan binnen 1 CCX.
Voorbeeldje problematiek van gepartitioneerd geheugen. Ik heb 128GB memory en ik laad een 100GB database in het geheugen.. dat wordt partitioneren dus. Nu, ik ben een device dat data genereerd voor de database. Er wordt een tread gedispatched op een van de CCXen. Kan ik van te voren weten welke records deze tread gaat updaten/vullen? nee, afhankelijk door het externe device. Dus op het ene moment gaat het snel (record bevindt zich binnen het geheugen blok van de CCX waar de tread draait) en dan weer langzaam als het record zich bevindt in het geheugen van de andere CCX. Indien tread verplaatsing mogelijk was kon je eenvoudig de tread verplaatsen, maar dat gaat nu niet door, of gaan we de opcodes halen via infinityfabric of gaan we het programma verplaatsen naar de juiste CCX?
Dan over PCIe. AMD heeft geen 64 lanes PCIe nee wat ze hebben is 4 x 16 PCIe dat is NIET hetzelfde. De achtergrond van PCIe is hetzelfde als ethernet nl point to point met een switch topologie. Vraag je netwerk deskundige maar eens wat hij liever heeft, 4 switches met 12 porten non blocking waarbij de up/down link ook nog voor andere zaken gebruikt worden dan interconnect tussen de 4 switchen, of een 48 ports non blocking switch. Voorbeeldje fileserver 4 dikke hba's erin flink wat array's eraan en dan krijg je te horen, tja merk A wil dat alle ssd's in array x en y geupdate worden met nieuwe firmware alleen moet je wel de disken leeg voordat je de update doet ivm corruptie kans van de data. Dus de systeem beheerder brengt de array's offline. Hierdoor wordt alle info van deze arrays naar de overige arrays verplaatst. Dus alle data weer over infinityfabric. Das met PCIe 3.0 x16 nog niet zo'n probleeem maar met 4.0 x16 zitten we al behoorlijk dicht bij de huidige infinityfabric snelheid. Dus zal amd weer aan infinityfabric moeten sleutelen. Wat nou niet echt eenvoudig is vandaar dat de cpu makers liever niet te veel veranderen aan die externe bussen. Kijk maar eerns naar het verleden. Intel laat QPI ook liever met rust en hoelang hebben de fsb niet gehad. Vandaar dat het voor mij niet zo raar is dat ze met crossfire support stoppen, zet er maar eens 4 in crossfire en kijk wat er gebeurd.
AMD cpu's zijn in alles goed dat ook via een distributed netwerk afgehandeld kan worden, zoals VM's die binnen een CCX vallen (hiervoor hebben wij ze in bestelling, office VM's), render programma's (cinebench, blender) waaronder ook vele filters voor foto en video bewerking vallen, en compressie tools. Eigenlijk alle programmas waarbij een grote bewerking opgesplitst kan worden in meerde delen waarbij de kleine delen onderling weinig of geen communicatie nodig hebben. Voor de mensen die graag renderen, als je modeler programma de scene kan uitschrijven naar povray maak dan gebruik van distributed povray op school of je werk want dan staan alle machines parallel en lijk je een 100% schaling te krijgen. 1400 dual core PC's (op de uni) zijn sneller dan wat je ooit thuis kunt aanschaffen.
Dan voor de game specialisten onder ons.. Ik heb voor de grap tombraider op een 40 cores 80 treads dual socket e5-2679 gestart. en daarbij zie je wat ik al verwachte, ook deze game heeft 1 tread die vele malen groter is dan de rest van de treads. Alle overige treads verdelen zich tot semi ruis op de rest van de treads. Nu snappen mensen dus misschien waarom het slim is om 1 core veel harder te laten lopen dan de overige cores. Nu hebben de meeste programma's behalve de hierboven beschreven programma's een langst lopende tread die de totale performance van het programma bepaald. Het is dus handig dat je 1 snellere core hebt om zo deze bottleneck zo lang mogelijk te vermijden. Nu moet het natuurlijk wel zo zijn dat je genoeg cores hebt dat de overige treads niet zo veel cpu gebruik veroorzaken dat deze treads de bottleneck gaan vormen. (alle cores lopen dan tegen 100% load)
Dan prijzen, in de server markt wordt veelal een licentie per core gevraagd. Al was de 10 cores intel 5000 euro duurder zijn wij nog steeds goedkoper uit met de 10 cores van intel voor onze database dan met de 16 core TR van AMD. Aangezien de licentie 1100 euro per core per jaar is. En de performance tussen deze twee cpu's nagenoeg gelijk is.
Vraag me af hoe lang het duurt voordat rendering software hetzelfde licentie systeem zullen overnemen.
Nu hoor ik ook veel mensen zeggen, dan moeten ze maar beter multi treaded software schrijven. Niet alle zaken zijn te verdelen over meerdere treads. Het kan zo zijn dat een calculatie pas kan starten als de vorige calculatie klaar is aangezien het antwoord nodig is voor die opvolgende calculatie. Wat als nu dit altijd zo is zoals bij de modelers van dassault solidworks of autodesk inventer. (ps kom niet aan met verschillende views, dat die wel op meerdere treads kunnen dat is logisch). Die jongens worden pas echt blij met een 1 core CPU op 50GHz.
De huidige benchmark cijfers zeggen alleen iets over de ruwe core snelheid maar nog niets over de rest. Dus voor de juiste info zie anand als hij de benches klaar heeft. Hij heeft technische computerkunde gestudeerd en aangezien die dat nog leuker vond dan zijn website onderhouden, heeft hij een baan bij apple op de apple arm afdeling. Ps de domme commentaren die je vindt over hij is pro intel kan nooit kloppen. Aangezien apple een arm gebruikt en ook intel arm's mag ontwerpen en produceren. Wat denk je dat apple doet als zij er achter komen dat hij onderwater met intel aan het praten is. Intel heeft goud over voor info over de A10. Denk dat hij dat wel uit zijn hoofd laat aangezien de juridische afdeling van apple gehakt van anand zal maken.
Dus anand en biased nee niet naar intel wel naar apple.
my2cents (asic designer)