[CPU] Waarom maakt iets anders dan het aantal GHz uit?

[kramer65]

Hallo,

Gezien ik eigenlijk een tekort aan rekenkracht heb in mijn computer ben ik mij een beetje aan het oriënteren op een nieuwe CPU. Zo lees ik naast het aantal kernen over dingen als het aantal 'nm', de cache, en natuurlijk het aantal GHz.
Om te beginnen met het laatste. Naar mijn weten is iets met één Hertz iets wat zich éénmaal per seconde herhaalt en dus is iets met 3 Gigahertz iets wat zich 3.000.000.000 (drie miljard) keer per second herhaalt. Een kern met een kloksnelheid van 3 GHz kan dus drie miljard berekeningen per seconde uitvoeren.
Verder lees ik op wikipedia dat de klokcycli per instructie invloed heeft, maar dat dit geen probleem is voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken. Verder schijnt de cache een belangrijke rol te spelen. "Doorgaans geldt: hoe groter de cache, hoe sneller de processor.". "Tot slot is er een fenomeen, pipelining, dat de processorsnelheid in bepaalde situaties verhoogt. Vroeger werden commando's altijd ná elkaar uitgevoerd. Nu kan commando B beginnen terwijl commando A nog aan de gang is; dit noemt men pipelining."

Ok, dat begrijp ik allemaal. Wat ik echter niet begrijp, is waarom al die dingen zouden uitmaken. Naar wat ik begrijp kunnen die dingen de processorsnelheid, alias het aantal berekeningen per seconde verhogen. Maar dat komt dan dus toch altijd in uiting in het aantal Hertzen van de CPU?

Ik gebruik mijn computer voor gegevensanalyse met extreem veel floating points in zelfgeschreven Python programma's. Ik zit met mijn huidige quadcore geregeld aan 48 uur (of langer) 100% belasting per core. Het enige wat mij dus interesseert is het aantal berekeningen per seconde per kern. Waarom zou ik dan nog kijken naar iets anders dan het aantal GHz per kern. In die redenatie zou ik dan altijd uitkomen bij AMD die bijvoorbeeld al een 3.1GHz octacore hebben voor onder de €150.

Ik heb echter het idee dat er wat schort aan mijn redenatie. Ik heb wat rond zitten lezen over de werking van processoren, maar kan nergens antwoord op mijn vraag vinden. Heeft iemand hier een verklaring waarom mijn redenatie niet opgaat?

[MaximusTG]

Ja, wat wil je nou? Je geeft zelf het antwoord toch al min of meer? Hoeveel instructies per klokcyclus (oke, je schrijft het andersom) is ook van invloed, dus nee, je kan niet puur op GHz vergelijken. Maar omdat je aangeeft dat je veel floating point berekeningen doet, waarom zoek je geen benchmark die processors vergelijkt op basis van FLOPS (floating point operations per second)?

[kramer65]

MaximusTG schreef op donderdag 30 augustus 2012 @ 09:49:
Ja, wat wil je nou? Je geeft zelf het antwoord toch al min of meer? Hoeveel instructies per klokcyclus (oke, je schrijft het andersom) is ook van invloed

Maar zoals ik ook schrijf; "maar dit is geen probleem voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken"
Dat zou dus niet uit hoeven maken.

Mijn punt is een beetje; waarom gaan mensen voor Intel, als het aantal GHz per Euro veel hoger ligt bij AMD? Ik zie ook vaak dingen staan als AMD is meer 'bang for buck', maar intel is beter (vrij vertaald). Het waarom daarin begrijp ik gewoon niet..

[dutch_warrior]

Ik weet niet meer precies waar de verschillen tussen de AMD FX en Sandy Bridge ontstaan, ten tijde van de introductie van AMD Bulldozer is de architectuur in het AMD nieuwsberichten topic wel uitgebreid besproken.

Het gebruik van de juiste instructiesset is echter ook van groot belang voor de prestaties, zeker wanneer we over de AMD FX cpu's praten. De AMD architectuur is op papier erg efficiënt in de praktijk komen de voor deze architectuur optimale scenario's echter nog niet zo vaak voor.

Deze benchmark behandelt de bulldozer architectuur en het performance verschil tussen de optimale en worst case scenario's.

Als je zelf optimaal multi threaded kan programmeren voor de FX cpu's dan kan je met een AMD systeem inderdaad veel bang for buck krijgen. Zodra je van het optimale scenario afwijkt presteren de bulldozer cpu's een stuk minder.

[ Voor 20% gewijzigd door dutch_warrior op 30-08-2012 10:19 ]

[ramonlambal]

volgens mij gaan floating points nog steeds sneller op een GPU, maar ik weet neit of het mogelijk is om met pyton zelfgeschreven programmas het daar naar toe te krijgen?

[MaximusTG]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:55:
[...]

Maar zoals ik ook schrijf; "maar dit is geen probleem voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken"
Dat zou dus niet uit hoeven maken.

Mijn punt is een beetje; waarom gaan mensen voor Intel, als het aantal GHz per Euro veel hoger ligt bij AMD? Ik zie ook vaak dingen staan als AMD is meer 'bang for buck', maar intel is beter (vrij vertaald). Het waarom daarin begrijp ik gewoon niet..

Ja, maar wat wil je nou horen dan? Jij blijft erbij dat alleen het aantal GHz de snelheid bepaald. Dat is dus niet zo. De praktijk is veel complexer, en heeft met verschillende eigenschappen van een processor te maken. Een processor die beter is in taak 1 dan processor 2 kan bij taak 2 ineens langzamer zijn.
Dat GHz niet alles zegt blijkt wel uit benchmarks.

Dus tenzij je echt op de technische verklaring in wil gaan, zou ik ze voor aankoopdoeleinden gewoon als blackbox beschouwen, en ze vergelijken op basis van budget en benchmarks op het gebied waarin je em zal gebruiken.
Wie weet, misschien heb jij wel meer aan een DIY rekencluster van goedkope pc's?

[Nilsepils]

*Algemeen Advies* Welke CPU moet ik kopen?

is dit misschien geen nuttige informatie?

[jeroen3]

Als je zoveel floating point berekeningen moet maken. Loont het dan niet om de gpu aan het werk te zetten?
Of threads?

Overigens is cache geheugen snel omdat het in de chip zit. RAM kost veel meer tijd, trage clock, looptijden, delays...
Dus als je een berekening wilt maken loont het als je alles in cache kan doen, en niet halverwege weer met het RAM moet spelen.

Jij moet in de processor kijken, en controleren dat elke core een dedicated floating point module heeft.
De bulldozer heeft die volgens mij niet.
Daarbij speelt de instructieset ook een grote rol dus de intelligentie van de compiler.
Als ik dit zie, dan is python 17 keer trager dan C.

[naarden 4ever]

Het is gewoonweg niet aantal cores * kloksnelheid, want de architecturen verschillen teveel. Vroeger kon je kiezen; je had een Pentium van 233MHz en een Athlon van 270MHz, dan was de Athlon beter. Punt.

Dat was echter uit de periode dat AMD net onafhankelijk van Intel was (AMD was vroeger een bedrijf dat Intel hielp aan de grote vraag van chips te voldoen, en produceerde zelf ook dus Pentium processoren), daarna heeft AMD wel de info van de Pentium en de Pentium II gekregen, maar verdere informatie hoefte Intel niet aan AMD te geven. Daardoor zijn beide bedrijven een eigen weg gegaan. Resultaat? AMD heeft minder sterke cores gekregen door de tijd, en dat proberen ze te compenseren door middel van hoge kloksnelheden en veel cores in te bouwen. In de tijd met de dualcores was AMD de eerste. AMD was ook de eerste met een quadcore, en ook met de octocore (Bulldozer) voor de consument, maar de cores zelf zijn van mindere kwaliteit. Daardoor komt het voor, zeker in de hoger geplaatste Intel-processoren, dat een Intel gehakt maakt van een bulldozer.

Dus, tijden veranderen. Tuurlijk, het zijn beide x86-64 CISC processoren, maar de architectuur, d.w.z. de opbouw van de processor, is gewoon heel anders. In ruwe kracht, dus op papier, is AMD veel sneller dan Intel. AMD heeft meer cachegeheugen, wat erg prettig is bij o.a. FLOPs, maar feit blijft; de optimalisatie voor AMD is over het algemeen beroerd. Dat is dan ook uiteindelijk de reden dat mensen een Intel kiezen, want met name met games merk je het verschil in architectuur, waar Intel gewoon een streepje voor heeft.

Voor jouw situatie zou ik gewoon benchmarks opzoeken om te kijken hoeveel FLOPs elke processor maakt en daaruit je keuze maken.

[Reepje]

Opmerkelijke topic.
Al lang, lang geleden werd de mhz mythe doorprikt door AMD, die zijn processoren namen gaf als AMD athlon 64 x2 5000+. Daarmee wilde ze aangeven dat deze processor die op 2,6 Ghz liep, zou presteren als een intel die op 5 Ghz liep (of iets dergelijks, verwarring zal er altijd blijven).

Ondertussen zijn procesoren velen malen complexer geworden. Toch zijn er nog mensen die bijv bij de mediamarkt staan en daar computers vergelijken op prijs/Ghz processor en zo tot hun meest optimale aankoop komen.

Alsof een processor een zwart doosje is waar uitsluitend aan de ene kant nulletjes en eentjes ingaan, en die aan de andere kant weer uitgepoept worden. En hoe meer van die nulletjes en eentjes door dat doosje geperst worden (hoe hoger de Ghz van de processor), hoe sneller de computer is.

Wel lachen.

[Tsurany]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:44:
In die redenatie zou ik dan altijd uitkomen bij AMD die bijvoorbeeld al een 3.1GHz octacore hebben voor onder de €150.

Ik heb nog een leuke 3,6Ghz Pentium IV, wil je die niet kopen voor 140 euro? Meer Mhz'en en goedkoper!

Wikipedia: Megahertz myth
YouTube: The Megahertz Myth

En zo is er nog veel meer te vinden. Volgens mij heb je niet echt goed onderzoek gepleegd.

[ Voor 15% gewijzigd door Tsurany op 30-08-2012 10:44 ]

[Umbrah]

Je kunt de cache-vergelijking zo zien: hoe "lager", hoe sneller. Elke keer als hij een instructie wil uitvoeren, kijkt hij eerst: zit dit in L1? Zo nee, volgende clocktick gaat hij verder kijken, tot hij op den duur bij het RAM uitkomt. Vanuit daar zul je steeds verder moeten zoeken, naar zelfs de OS-laag aan toe die dingen vanaf de harddisk gaat trekken.

Als je gaat kijken naar arithmetic libraries zoals MPIR en GMP, zul je zien dat die vaak grotendeels in *ASM zijn gemaakt, specifiek voor een CPU tak: puur processor taal. Waarom? Op die manier kunnen ze relevante waarden zo dicht mogelijk bij de CPU houden. Zeker bij floats van groot belang. Overigens kun je dit soort libraries gewoon als "blackbox" aanroepen vanuit Python/.Net/wat je maar wilt: dingen gaan er in, dingen gaan er uit. Dat is het idee ook achter frameworks, jij programmeert alleen, de blackboxes maken zich zorgen om de implementatie. Daar kan overhead in komen, en soms is Python dan ook 17x zo traag als C. C is overigens slechts een taal, waar je ook maar weer blackboxes mee aanspreekt. Het verschil is dat je een andere taal spreekt dan python en de output anders verwerkt. Ik weet zeker dat Python sneller KAN zijn dan C, zeker als je dingen die in Python zelf zitten en goed zijn in C mogelijk helemaal zelf moet uitwerken (en dan het risico loopt dat het brak is).

Er zijn foefjes, zoals Hyperthreading en gedeeltelijke core duplicatie, en dat compliceert de boel: hele CPU's delen onderdelen. Daarnaast zit je inderdaad met een instructieset die op papier erg algemeen is, maar in de praktijk anders is. Intern werken AMD en Intel allebei met een RISC-achtig eigen instructieset die op veel dingen zich slechts voordoet als de decennia ouden X86 set. Alleen er zijn vaak meerdere wegen die naar Rome leiden, waardoor bepaalde operators (waarde A, Waarde B, soms Waarde C, en een operator) intern anders gaat en dan net wat langer duurt/korter.

Volg je hem? Een operatie uitvoeren kan dus best wat meer "herzen" kosten, waardoor je assumptie: Hz = berekeningen per seconde van nature al fout is.

Gooi er ook nog eigenschappen bij als voorspellings algoritmes in de CPU (na paar keer hetzelfde sommetje doen rekent hij niet eens meer maar gooit hij gewoon de uitkomst van eerder er uit), en andere trucs, en je kunt stellen: Hz zegt niks over berekeningen per seconde.

In feite kun je MHz alleen vergelijken bij identieke processors (generatie, hoeveelheid cores, hoeveelheid toegewijd cache), en zelfs dan: de software heeft altijd ook inspraak, hoewel je daar zelf controle over hebt.

Floats zijn overigens het meest complexe wat er is, ik zou zeggen: kijk dan naar FLOPS benchmarks. Benchmarken is het enige wat je kunt doen om te vergelijken, want meten is weten.

Floats zijn echter dingen waar je veel mee kunt doen met een videokaart, die zijn van nature gemaakt om te tekenen, en dat is altijd iets van: moet die lijn daar, daar, of ergens halverwege staan? Ga er echter wel even over nadenken, omdat GPU's niet zomaar "het antwoord" zijn. Want vraag jezelf ook af: in welke mate moeten mijn resultaten kloppen? Geloof me, ik heb voor een groot pensioenfonds toen ik nog in NL werkte deze vergelijking ook gemaakt. Als je Double Precision floats wil hebben, dan stort de voordeel vergelijking voor een videokaart al snel in.

Dan heb je het voordeel nog dat er heel erg veel rekenkernen op een videokaart zitten. Maar daar heb je dan eigenlijk alleen voordeel van als je één berekening in zeer veel stukken kunt hakken. Heel veel berekeningen tegelijk is eigenlijk niet haalbaar. Waarom? Ook die videokaart deelt namelijk componenten, en je moet de data ook ergens vandaan halen en naar wegschrijven. Double Precision + ondeelbare taken = ga maar niet aan de videokaart, je performance-per-watt stort in. Het >KAN< wel, maar een ouwe, trouwe X86 CPU, zoals een dikke vette Xeon pompt met zijn vier kernen veel meer sommetjes per watt EN per uur er uit!

[TERW_DAN]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:55:
[...]

Maar zoals ik ook schrijf; "maar dit is geen probleem voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken"
Dat zou dus niet uit hoeven maken.

Zowel intel als AMD maakt dan wel x86 compatible CPU's, maar de architectuur is wel degelijk anders. Dus die vergelijking gaat al niet op.

naarden 4ever schreef op donderdag 30 augustus 2012 @ 10:33:
Het is gewoonweg niet aantal cores * kloksnelheid, want de architecturen verschillen teveel. Vroeger kon je kiezen; je had een Pentium van 233MHz en een Athlon van 270MHz, dan was de Athlon beter. Punt.

En zelfs dat is niet waar. TEn eerste omdat er nooit Athlons van 270MHz zijn geweest, ten tweede omdat toen Intel, AMD en Cyrix nog allemaal CPU's maakte voor dezelfde moederbordjes, er ook al verschil zat tussen verschillende 486 CPU's.

naarden 4ever schreef op donderdag 30 augustus 2012 @ 10:33:
Resultaat? AMD heeft minder sterke cores gekregen door de tijd, en dat proberen ze te compenseren door middel van hoge kloksnelheden en veel cores in te bouwen.

Nouj, laten we de Athlon XPs niet vergeten. Daar liet AMD zien dat ze toch aanzienlijk snellere CPU's konden maken dan Intel, ook al liepen ze op lagere snelheden. Toen zijn ze begonnen met de ratings (die niet lieten zien hoe snel de CPU was ten opzichte van een Intel CPU, maar ten opzichte van de oude Athlons... dat is tenminste de officiele uitleg).

Voor jouw situatie zou ik gewoon benchmarks opzoeken om te kijken hoeveel FLOPs elke processor maakt en daaruit je keuze maken.
[/quote]
En dat is ook de enige manier om je keuze goed te onderbouwen, benchmarks!

[Paul]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:55:
Maar zoals ik ook schrijf; "maar dit is geen probleem voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken"
Dat zou dus niet uit hoeven maken.

Jawel, want de processorarchitectuur (x86-64) legt niet het aantal instructies per seconde op, het legt alleen maar op dat wanneer je opdracht 'Tel 1 bij 1 op' geeft er '2' uit moet komen.

Waarschuwing: Fictieve getallen: Als een Intel 3 instructies per kloktik verwerkt en een AMD doet er 2 dan moet die AMD dus anderhalve keer zoveel GHz hebben om evenveel instructies per seconde te doen.

1 Hz is niet gelijk aan 1 instructie per seconde, 1 Hz is gelijk aan 1 kloktik per seconde. Wat er allemaal in één kloktik gebeurd verschilt heel erg per fabrikant, per familie en per generatie.

[Reepje]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:44:
In die redenatie zou ik dan altijd uitkomen bij AMD die bijvoorbeeld al een 3.1GHz octacore hebben voor onder de €150.

Ja inderdaad. Ik heb eens in een winkel gewerkt (jullie weten welke) en daar had je klanten die zelfs met hun rekenmachientje de kracht van computers uitrekenden. He pap, deze is het snelst 24,8 GHz !!! ( 8X3,1=24,8)

Als verkoper mocht ik dan alleen vertellen dat dat inderdaad een hele goede en snelle computer was. Klanten mag je namelijk niet in verwarring brengen, want verwarde klanten kopen niets.

[bwerg]

Ik heb niet ieder's reactie helemaal gelezen dus misschien dat ik dingen dubbel zeg.

kramer65 schreef op donderdag 30 augustus 2012 @ 09:44:

Om te beginnen met het laatste. Naar mijn weten is iets met één Hertz iets wat zich éénmaal per seconde herhaalt en dus is iets met 3 Gigahertz iets wat zich 3.000.000.000 (drie miljard) keer per second herhaalt. Een kern met een kloksnelheid van 3 GHz kan dus drie miljard berekeningen per seconde uitvoeren.

Incorrect. Een berekening duurt namelijk niet één kloktik, maar meerdere. En het is afhankelijk van de gebruikte architectuur van de CPU hoeveel kloktikken er nodig zijn per berekening. En het verschilt ook dat sommige architecturen meerdere berekeningen tegelijk verwerken, waardoor dat weer wat gecompenseerd wordt. Ter vergelijking: de pentium 4 had een hoge kloksnelheid, maar ook een enorm lange pipeline (het aantal stages dat een instructie moet doorlopen voordat hij klaar is), waardoor de athlon 64 veel sneller was met een lagere kloksnelheid (en een erg korte pipeline). De precieze details liggen erg ingewikkeld, en weet ik zelf ook niet.

Verder lees ik op wikipedia dat de klokcycli per instructie invloed heeft, maar dat dit geen probleem is voor het vergelijken van desktopcomputers aangezien die allemaal dezelfde architectuur gebruiken.

Vroeger misschien, maar nu totaal niet meer van toepassing. De architecturele verschillen tussen pentium 4, core 2, ivy bridge, bulldozer, phenom II, atom en bobcat zijn totaal verschillend. Allemaal desktop-architecturen die x86-zijn (maar dat is de instructieset die bepaalt welke code je erop kan draaien, niet wat de architectuur is of wat de prestaties zijn).

Verder schijnt de cache een belangrijke rol te spelen. "Doorgaans geldt: hoe groter de cache, hoe sneller de processor.".

In de zin van "high-end CPU's hebben vaak meer cache", dan ja. Maar cache is niet doorslaggevend. High-end core 2 quads hadden echt idioot veel cache, maar die verliezen het hard van een core i7 die minder cache heeft.

"Tot slot is er een fenomeen, pipelining, dat de processorsnelheid in bepaalde situaties verhoogt. Vroeger werden commando's altijd ná elkaar uitgevoerd. Nu kan commando B beginnen terwijl commando A nog aan de gang is; dit noemt men pipelining."

Dit soort technische details zit dus erg goed bij de huidige i3/i5/i7, die per kloktik meer werk verzetten dan welke andere architectuur dan ook. Maar er zijn nog veel meer manieren om de prestaties per kloktik te verbeteren.

Ok, dat begrijp ik allemaal. Wat ik echter niet begrijp, is waarom al die dingen zouden uitmaken. Naar wat ik begrijp kunnen die dingen de processorsnelheid, alias het aantal berekeningen per seconde verhogen. Maar dat komt dan dus toch altijd in uiting in het aantal Hertzen van de CPU?

Dat ligt dus aan dat "hertz" het aantal kloktikken per seconden bepaalt, en een kloktik dus nog geen hele berekening is.

Samenvattend: het is tegenwoordig veel te lastig om te bepalen wat de prestaties zijn, aan de hand van specificaties. Kijk dus gewoon naar benchmarks, en dan vooral naar voor jou relevante benchmarks. Ik heb wel een tip (wel architectuur-gebaseerd) voor jouw gebruik: bij AMD bulldozer-CPU's delen elke twee cores één floating-point unit. Een quadcore heeft dus maar 2 floating-point units, terwijl die van andere architecturen (phenom II en alle recente intels) er 4 hebben. Ik zou dus geen bulldozer nemen.

Umbrah schreef op donderdag 30 augustus 2012 @ 10:48:
Je kunt de cache-vergelijking zo zien: hoe "lager", hoe sneller. Elke keer als hij een instructie wil uitvoeren, kijkt hij eerst: zit dit in L1? Zo nee, volgende clocktick gaat hij verder kijken, tot hij op den duur bij het RAM uitkomt. Vanuit daar zul je steeds verder moeten zoeken, naar zelfs de OS-laag aan toe die dingen vanaf de harddisk gaat trekken.

Je bedoelt het feit dat L1 sneller is dan L2? Dat werkt voor het vergelijken van architecturen ook niet helemaal 100% duidelijk, want L2-cache kan per architectuur ook weer verschillende snelheden hebben (als in: bij sommige architecturen is L2 het hoogste level waar het meeste in past, bij sommige is dat L3, dus die L2 en L3 hebben een vergelijkbaardere functie dan de twee L2's van die architecturen).

[ Voor 10% gewijzigd door bwerg op 30-08-2012 10:56 ]

[VyperX]

kramer65 schreef op donderdag 30 augustus 2012 @ 09:44:
[...]
Ok, dat begrijp ik allemaal. Wat ik echter niet begrijp, is waarom al die dingen zouden uitmaken. Naar wat ik begrijp kunnen die dingen de processorsnelheid, alias het aantal berekeningen per seconde verhogen. Maar dat komt dan dus toch altijd in uiting in het aantal Hertzen van de CPU?
[...]
Ik heb echter het idee dat er wat schort aan mijn redenatie. Ik heb wat rond zitten lezen over de werking van processoren, maar kan nergens antwoord op mijn vraag vinden. Heeft iemand hier een verklaring waarom mijn redenatie niet opgaat?

Het uitvoeren van een "berekening" zoals jij die in je programma zet bestaat uit een aantal stappen. Bijvoorbeeld voor een vermenigvuldiging van 2 floating point getallen:

• Laad 1ste waarde in register A
• Laad 2de waarde in register B
• Voer vermenigvuldiging uit
• Schrijf waarde weg naar geheugen X

Dit laat al zien dat voor een "berekening" er meer moet gebeuren, en dat dit vooral van het geheugen afhankelijk is. Hoe sneller de processor toegang heeft tot het geheugen, hoe sneller je complete berekening is uitgevoerd. Vandaar dat caches helpen.
Door caching kan de processor sneller bij de waardes (en instructies!!) die het moet uitvoeren.

Verder zijn de huidige processoren uitgerust met dingen als 'branch prediction'. Dit houdt in dat ze al operaties gaan uitvoeren (waar ze de data voor hebben), die _mogelijk_ nodig zijn.

Hoe meer (en sneller) cache je hebt, en hoe beter je branch prediction, hoe meer effectieve snelheid je uit je processor krijgt.

[GeeBee]

Volgens mij gaat het kortweg gezegd om snelheid vs efficiëntie.
Stel je kunt heel snel lopen. Als je boodschappen wilt doen, is het efficiënter om eerst te bedenken welke boodschappen je wilt hebben en die in één te halen. Als je echter heel snel voor elke boodschap van huis naar de supermarkt loopt, ben je uiteindelijk veel meer tijd kwijt.
Je door efficiëntie veel tijd winnen.

In beide gevallen wordt de klus gedaan: de boodschappen zijn binnen. Toch kan iemand die langzamer loopt, maar eerst nadenkt de totale klus sneller klaarhebben dan een hele snelle loper die alleen maar heel snel heen en weer loopt.

Zoiets?

[MaximusTG]

Nee

Maak dan een vergelijking waarbij iemand die steeds naar de winkel loopt en twee boodschappen meeneemt vs iemand die langzamer loopt maar een hele tas meeneemt.

[ Voor 91% gewijzigd door MaximusTG op 30-08-2012 11:04 ]

[bwerg]

GeeBee schreef op donderdag 30 augustus 2012 @ 11:00:
Toch kan iemand die langzamer loopt, maar eerst nadenkt de totale klus sneller klaarhebben dan een hele snelle loper die alleen maar heel snel heen en weer loopt.

En dan moet je je bij pentium 4 dus een idioot voorstellen. Die als een gek over de weg stuitert en al zijn boodschappen laat vallen, en onderweg roept "kijk mij eens snel zijn", terwijl athlon 64 hem gek aankijkt vanaf zijn fiets met boodschappentassen.

Zo kun je het ook uitleggen, ja. Doet de werkelijkheid geen eer aan maar het idee is duidelijk.

[ Voor 5% gewijzigd door bwerg op 30-08-2012 11:06 ]

[jeroen3]

Ja, maar dan moet je het wel compleet maken.

De grootte van het karretje (cache registers)
Het aantal handen (cores)
De grootte van het product, 6 blikjes of een six-pack. (efficiëntie architectuur en 32/64 bit)

Je snapt dan dat het pakken twee six packs tegelijk in een groot karretje sneller het gewenste aantal six-packs in de auto (ram) oplevert dan het pakken van één blikje per keer in een klein karretje waarmee je 6 keer op en neer moet.

[naarden 4ever]

Tja, en zo kunnen we nog wel even doorgaan... Pipelining, caches met verschillende niveau's, x86-64 of ARM, RISC/CISC, frequentie, FSB, Cores, instructiesets, threads in zowel de CPU als het programma, etc.

Je kunt nu eenmaal geen Intel met AMD vergelijken. Hoewel ze op sommige onderdelen hierboven gelijk zijn, ook in heel veel dingen niet. Zo zijn het beide CISC processoren met de x86-64 architectuur, maar de pipelines zijn verschillend van lengte, verschillende caches, frequentie verschilt... Het zijn gewoonweg niet dezelfde CPU's.

Je moet kijken wat voor jou het beste is. Zo kan ik iemand die een Folding@Home/BOINC/SETI@Home apparaat in elkaar wilt zetten ook alleen maar een AMD-platform aanraden. Waarom? Chipset. AMD loopt heel erg voor met het aantal PCIe lanes op het moederbord, en als iemand 4 topkaarten in zijn PC wilt plaatsen, koop je een 990GX (volgens mij), die kan quad-crossfireX draaien op 16/16/8/8. Intel komt daar niet eens in de buurt van die bandbreedte op de northbridge op PCIe.

Echter, als iemand wilt gamen, blijkt het dat Intel gewoonweg beter is. In elke benchmark komt Intel als beste uit de bus (sinds Core 2/Athlon 64). Het zou dan ook debiel zijn om voor een AMD te gaan als je een Intel kan kopen (en gebruiken, want een i7 met een HD5450 combineren is ook zinloos. Verhoudingen, tellen ook nog mee), want op dat vlak is Intel gewoon beter.

[ Voor 43% gewijzigd door naarden 4ever op 30-08-2012 12:40 ]

[marcop23]

Ik denk dat dit ook leuk is om te lezen:
http://www.lighterra.com/papers/modernmicroprocessors/

Laatst gepost door .oisyn in het Devschuur-topic. Ik vond het in ieder geval heel interessant. Gaat helemaal over CPU's, zo low-level als bijna maar kan. Ik vond het, als relatieve noob, in ieder geval begrijpbaar en duidelijk.

[kramer65]

Okee. Dank jullie allen. Het duurde even gezien ik ineens een heleboel te lezen en bekijken had. Ik ben een stuk wijzer geworden en ben blij dat ik van mijn eigen Megahertzmythe af ben. Ik vond mezelf al klinken als "mijn cameratelefoon heeft wel 16megapixel en is dus beter dan jouw Canon 50D (15MP).."

Het belangrijkste wat ik heb geleerd zijn de volgende zaken:

Een operatie uitvoeren kan dus best wat meer "herzen" kosten, waardoor je assumptie: Hz = berekeningen per seconde van nature al fout is.

1 Hz is niet gelijk aan 1 instructie per seconde, 1 Hz is gelijk aan 1 kloktik per seconde. Wat er allemaal in één kloktik gebeurd verschilt heel erg per fabrikant, per familie en per generatie.

Mijn basisassumptie was dus al fout. Een Hertz is geen volle berekening, maar zoiets als één "actie", en hoeveel acties er nodig zijn per berekening verschilt dus schijnbaar enorm per fabrikant/processor.

Ik denk dat dit ook leuk is om te lezen:
http://www.lighterra.com/papers/modernmicroprocessors/

Dit was een erg goeie tip. Ik heb er helemaal doorheen gelezen en begrijp nu een stuk beter wat er allemaal wel niet bij komt kijken.

Floats zijn overigens het meest complexe wat er is, ik zou zeggen: kijk dan naar FLOPS benchmarks. Benchmarken is het enige wat je kunt doen om te vergelijken, want meten is weten.

De mantra die dus ook terugkomt, benchmarks, benchmarks, en nog eens benchmarks.

jeroen3 schreef op donderdag 30 augustus 2012 @ 10:29:
Jij moet in de processor kijken, en controleren dat elke core een dedicated floating point module heeft.
De bulldozer heeft die volgens mij niet.
Daarbij speelt de instructieset ook een grote rol dus de intelligentie van de compiler.
Als ik dit zie, dan is python 17 keer trager dan C.

Bij de aanschaf van mijn volgende processor zal ik zéker naar de FPU's kijken. En over Python wat trager is dan C. Dat klopt, maar dat wordt weer gecompenseerd door de extreem korte ontwikkeltijd met Python. En ik gebruik natuurlijk wat trucks, zoals PyPy, Cython, etc. Voor geïnteresseerden: YouTube: High Performance Python I

Heel erg bedankt voor alle reacties!

[MaximusTG]

hertz is geen term die alleen met computers te maken heeft, het is de SI-eenheid van frequentie. 1 hertz, of Hz, betekent 1 trilling per seconde. 2 Hz betekent 2 trillingen per second, en dus periodes van 0,5 s.

Wikipedia: Hertz (eenheid)

[kramer65]

MaximusTG schreef op vrijdag 31 augustus 2012 @ 14:32:
hertz is geen term die alleen met computers te maken heeft, het is de SI-eenheid van frequentie. 1 hertz, of Hz, betekent 1 trilling per seconde. 2 Hz betekent 2 trillingen per second, en dus periodes van 0,5 s.

Wikipedia: Hertz (eenheid)

Dat begrijp ik. Ik ken Hertz ook uit de muziek (geluidsfrequenties en LFO's etc). Ik ging er alleen ook vanuit dat een Hertz gelijk stond aan een berekening. Dat dit dus niet zo is, en dat om die reden het aantal hertzen van een processor vrij weinig zegt, begrijp ik nu..

[White Feather]

Het magische woord hierin is: IPC

Wikipedia: Instructions per cycle

Voor verschillen in IPC's:
http://www.tomshardware.c...cture-benchmark,2974.html

16 CPU's op 3 Ghz. Daar kun je mooi zien wat de verschillen zijn.

[bwerg]

MaximusTG schreef op vrijdag 31 augustus 2012 @ 14:32:
1 hertz, of Hz, betekent 1 trilling per seconde.

Zelfs dat "trilling" kun je weg laten. Het betekent gewoon "per seconde".

[Zer0]

White Feather schreef op zaterdag 01 september 2012 @ 09:47:
Het magische woord hierin is: IPC

Wikipedia: Instructions per cycle

Voor verschillen in IPC's:
http://www.tomshardware.c...cture-benchmark,2974.html

16 CPU's op 3 Ghz. Daar kun je mooi zien wat de verschillen zijn.

IPC zegt ook niet alles, het is ook nog eens afhankelijke welke instructies een CPU kan uitvoeren en welke hij op dat moment uit moet voeren. CISC (Complex instruction set computer) vs. RISC (Reduced instruction set computer) speelt ook een rol.
Waar een CISC CPU 4x2 in één instructie kan doen, moet een RISC CPU deze in drie instructies doen (2+2+2+2) bijvoorbeeld. (Dit voorbeeld is niet waarheidsgetrouw en enkel om het verschil aan te geven)

[Anoniem: 251563]

White Feather schreef op zaterdag 01 september 2012 @ 09:47:
Het magische woord hierin is: IPC

Wikipedia: Instructions per cycle

Voor verschillen in IPC's:
http://www.tomshardware.c...cture-benchmark,2974.html

16 CPU's op 3 Ghz. Daar kun je mooi zien wat de verschillen zijn.

Maak IPC echter niet te magisch!! Het is niet zo dat IPC gelijk staat aan performance. Sterker nog, het is even belangrijk als de frequentie, niets meer en niets minder. We leven nu al een paar jaar met algemene gedachte dat IPC alles is; dit is nou de "IPC myth".

[Cheezus]

Daarom dus het magische woord: Benchmarks-die-relevant-zijn-voor-jouw-toepassing.

[Anoniem: 269504]

Het is denk ik ook de beperking van de huidige bouwwijze van een cpu die niet toelaat standaard boven de 4GHZ uit te komen . Als je bv een P4 op 18 GHZ kan laten draaien is die misschien net zo snel als de nieuwste sandy bridge . Nu heeft een moderne cpu de bijbehorende instructiesets om optimaal te functioneren wat hem clock voor clock tijdens een wisseling van cpu socket sneller maakt als zijn voorganger.
Zowiezo is die instructieset een bottleneck omdat gewone computertaal omgezet wordt naar een Machine code die de cpu begrijpt

[Zer0]

Anoniem: 269504 schreef op zaterdag 01 september 2012 @ 13:00:
Zowiezo is die instructieset een bottleneck omdat gewone computertaal omgezet wordt naar een Machine code die de cpu begrijpt

De instructie-set is de "machine code" die de cpu begrijpt. Een cpu vertaalt geen taal naar code, je stuurt hem instructies en die voert hij uit. Stuur hem een computertaal en hij doet niks.

[Anoniem: 269504]

Zer0 schreef op zaterdag 01 september 2012 @ 13:26:
[...]

De instructie-set is de "machine code" die de cpu begrijpt. Een cpu vertaalt geen taal naar code, je stuurt hem instructies en die voert hij uit. Stuur hem een computertaal en hij doet niks.

Oke

Toch is het wel frapant dat een GPU die een andere ontwikkeling heeft doorgemaakt met bepaalde berekeningen veel sneller is dan een normale cpu .

http://wiki.accelereyes.c...oduction_to_GPU_Computing

[Gomez12]

kramer65 schreef op vrijdag 31 augustus 2012 @ 14:28:
Mijn basisassumptie was dus al fout. Een Hertz is geen volle berekening, maar zoiets als één "actie", en hoeveel acties er nodig zijn per berekening verschilt dus schijnbaar enorm per fabrikant/processor.

Ja en nee, een hertz kan een volle berekening zijn, maar dan is het wel een volle berekening in het formaat dat de processor aankan.

300/300 is bijv al een berekening die meerdere cpu-cycles in beslag neemt, want die moet eerst afgebroken worden naar meerdere berekeningen die de processor aankan.
1+1 zou theoretisch wel in 1 cpu-cycle kunnen, maar over het algemeen wil je het antwoord ook weer opslaan zodat je er iets mee kan doen en het bewaren van het antwoord kost ook weer minimaal 1 cpu-cycle.

Het probleem met pure-Ghz mythes is dat het opzich nog wel relevant zou kunnen zijn als de rand-apparatuur de berekeningen maar snel (en slim) genoeg kan afbreken naar wat de cpu aankan.
Momenteel gaat het niet echt meer om het aantal cpu-cycles, maar meer om welke architectuur die berekeningen zo slim kan aanleveren dat ipv 100 cycles het maar 10 cycles kost.

[Dreamvoid]

Anoniem: 269504 schreef op zaterdag 01 september 2012 @ 14:05:
Toch is het wel frapant dat een GPU die een andere ontwikkeling heeft doorgemaakt met bepaalde berekeningen veel sneller is dan een normale cpu .

Daar is het dan ook een specialistische processor voor. Maar dat heeft alleen zin als je zo'n GPU ook vol kan blijven pompen met berekeningen die hij kan doen: simpele instructies die elk onafhankelijk van elkaar zijn uit te voeren zonder veel data heen- en weer te hoeven schuiven.

[dion_b]

kramer65 schreef op vrijdag 31 augustus 2012 @ 14:28:
[...]

Bij de aanschaf van mijn volgende processor zal ik zéker naar de FPU's kijken.

Nou nee, kijk vooral niet naar synthetische indicaties, niet naar aantal MHz, niet naar hoeveelheid cores, niet naar wat dan ook. Die informatie kan verhelderend zijn om te verklaren *waarom* CPU A sneller is dan CPU B in een bepaalde taak, maar niet meer dan dat.

Enige juiste antwoord is al gegeven:

Cheezus schreef op zaterdag 01 september 2012 @ 12:30:
Daarom dus het magische woord: Benchmarks-die-relevant-zijn-voor-jouw-toepassing.

Dat dus.

Gewoon een aantal toepassingen bepalen die jij vaak gaat doen en die uitdagend zijn (webbrowsen is dat niet, 3D gamen of compileren is dat wel), en vervolgens kijken naar scores van CPUs in jouw toepassing. Vaak komen daar resultaten uit die te verwachten zijn op basis van aantal GHz, aantal cores en hoeveelheid cache enzo. Soms krijg je verrassende resultaten (een schijnbaar tragere dualcore die de vloer veegt met een vergelijkbaar ogende quadcore bijv) - maar de waarheid zit hem in de praktijktest. Ook al kun jij (of ik of wie dan ook) het niet verklaren, als CPU A beter is in jouw toepassing dan CPU B, dan kun je beter CPU A nemen,

Nuancering:
Er is ook zoiets als budget. Bijna niemand koopt de snelste CPU die er is voor zijn toepassing, je koopt de snelste CPU voor jouw toepassing binnen budget. Of de CPU die de beste prestatie-prijs verhouding heeft voor jouw toepassing. Ik kies persoonlijk voor dat laatste, omdat ik niet losse budgetten heb voor alle onderdelen maar een totaalbudget. Als ik 40% minder hoef te betalen voor CPU en slechts 10% prestaties verlies kan ik dat geld stoppen in andere onderdelen die weer voordeel hebben. Prijs/prestatie is zo simpel als prestaties in relevante benchmark delen door aanschafprijs. Je krijgt dan per CPU een getal. Hoe hoeger dat getal, des te beter.

[bwerg]

Als je een zeer specifieke taak hebt zijn er niet altijd relevante benchmarks te vinden. Als je weet dat je veel threads met zware FP-berekeningen wil draaien dan is de architectuur op zich al een reden om niet voor bulldozer te gaan, omdat die maar half zoveel FP-units heeft per core als andere CPU's. Natuurlijk moet je wel een beetje kijken wat voor vlees je in de kuip hebt (misschien is een bulldozer wel 3x zo snel als een i7, en in FP-berekeningen dus 1,5x zo snel) maar als je de verhoudingen in prestaties ongeveer weet, kun je dit belangrijke architectuur-verschil wel als goed argument zien.

Maar dit is hierin wel een uitzonderlijk geval. Normaal gewoon benchmarks, ja.

[dion_b]

Zelfs in dat geval kun je prima relevante benchmarks vinden. Zoek een andere toepassing in dezelfde taal met vergelijkbare FP-berekeningen. In wetenschappelijke kringen is het erg gebruikelijk dat mensen hun eigen programmata schrijven, benchmarken en resultaten delen. Daar kijken kan een goede indicatie geven.

Juist het punt wat je zelf geeft over de mogelijkheid dat CPU X 3x zo snel is iha waardoor het zelfs met de halve hoeveelheid cores 1.5x zoveel zou kunnen presteren geeft al een voorbeeld waarom ook hier redeneren vanuit architectuur/specs gevaarlijk is. Ik heb veel vaker gezien dat mensen goedbedoelend onhandige keuzes gemaakt hebben op basis van architectuur dan dat ze het goed deden. Ik heb zelfs de grootste leek nog nooit een verkeerde keuze zien maken op basis van relevante benchmarks (de uitdaging: zorg dat die benchmarks relevant zijn )

[Anoniem: 251563]

dion_b schreef op zondag 02 september 2012 @ 10:54:
[...]

Nou nee, kijk vooral niet naar synthetische indicaties, niet naar aantal MHz, niet naar hoeveelheid cores, niet naar wat dan ook. Die informatie kan verhelderend zijn om te verklaren *waarom* CPU A sneller is dan CPU B in een bepaalde taak, maar niet meer dan dat.

Enige juiste antwoord is al gegeven:

[...]

Dat dus.

Gewoon een aantal toepassingen bepalen die jij vaak gaat doen en die uitdagend zijn (webbrowsen is dat niet, 3D gamen of compileren is dat wel), en vervolgens kijken naar scores van CPUs in jouw toepassing. Vaak komen daar resultaten uit die te verwachten zijn op basis van aantal GHz, aantal cores en hoeveelheid cache enzo. Soms krijg je verrassende resultaten (een schijnbaar tragere dualcore die de vloer veegt met een vergelijkbaar ogende quadcore bijv) - maar de waarheid zit hem in de praktijktest. Ook al kun jij (of ik of wie dan ook) het niet verklaren, als CPU A beter is in jouw toepassing dan CPU B, dan kun je beter CPU A nemen,

Nuancering:
Er is ook zoiets als budget. Bijna niemand koopt de snelste CPU die er is voor zijn toepassing, je koopt de snelste CPU voor jouw toepassing binnen budget. Of de CPU die de beste prestatie-prijs verhouding heeft voor jouw toepassing. Ik kies persoonlijk voor dat laatste, omdat ik niet losse budgetten heb voor alle onderdelen maar een totaalbudget. Als ik 40% minder hoef te betalen voor CPU en slechts 10% prestaties verlies kan ik dat geld stoppen in andere onderdelen die weer voordeel hebben. Prijs/prestatie is zo simpel als prestaties in relevante benchmark delen door aanschafprijs. Je krijgt dan per CPU een getal. Hoe hoeger dat getal, des te beter.

Vergeet daarbij niet dat het niet alleen over de prijs/prestatie van een onderdeel (zoals de CPU) gaat, maar de prijs/prestatie van het gehele systeem. Als je gaat gamen dan is het misschien beter een wat zwakkere CPU te nemen en een wat sterkere GPU, en in andere situaties kan een SSD weer een goede investering zijn. Dit is vaak lastig met benchmarks: veelal kijkt men dan naar slechts één onderdeel, en niet naar het geheel.