Apple iMac Core Duo vs. iMac G5

Nadat vorige maand de eerste ervaringen met de Apple 17" iMac Core Duo op het web verschenen, heeft nu ook AnandTech een exemplaar onder de loep genomen en de iMac Core Duo vergeleken met een iMac G5. Daarin wordt eerst nog even teruggeblikt op Apples aankondiging van de overstap naar het Intel-platform en de daarmee gepaard gaande problemen en vertragingen. Na deze overpeinzingen begint de reviewer met het voorstellen en beoordelen van de nieuwe iMac.

Het low-end model is uitgerust met een 17"-breedbeeldscherm met een resolutie van 1440x900 pixels. Een 20"-scherm op 1680x1050 behoort echter ook tot de mogelijkheden. De aansturing van dit scherm gebeurt door een ATi X600 bij de iMac G5 en door een Radeon X1600 bij de met een Intel-chip uitgeruste iMacs. Beide configuraties zijn uitgerust met 512MB werkgeheugen, maar daarbij maakt de reviewer meteen de opmerking dat dit ook wel het absolute minimum is voor OS X. Een geheugenupgrade, een van de enige aanpassingen die mogelijk zijn aan deze systemen, is dan ook een van de eerste zaken om te overwegen en kan eenvoudig uitgevoerd worden. Een leuke gadget die deze Intel-iMacs overgenomen hebben van de G5 is overigens de iSight-camera met een resolutie van 640x480 pixels en de microfoon die bovenaan in het scherm geïntegreerd zijn.

Ook op softwaregebied zijn er wijzigingen vast te stellen. Met Front Row klopt Apple namelijk aan bij gebruikers die hun computer vooral als mediacenter willen gebruiken. Front Row kan dan ook bestuurd worden met de afstandsbediening en biedt eenvoudige toegang tot foto's, muziek, video's en dvd's. De reviewer stelt dat het programma nog mijlen verwijderd is van Windows Media Center Edition, maar vraagt zich ook af of Apple wel een dergelijk systeem wilde creëren. Het lijkt er meer op dat het bedrijf gewoon het concept van een dergelijke media-interface wilde introduceren aan zijn gebruikers. De software werkt overigens wel uitstekend, aldus de reviewer, en de integratie van de Quicktime-filmtrailers in het pakket is een leuke extra. Het enige minpunt is dat de interface soms een beetje traag reageert en de 'snappiness' van Windows Media Center Edition mist.

	Tijd nodig voor het encoden van een mp3 met iTunes 6 (s)
	iMac Core Duo 1,83 GHz	42
	iMac G5 1,9 GHz	56
	iMac Core Solo 1,83 GHz	73

Bij de Core Solo werd een van de Intel-cores uitgeschakeld

Bij het uittesten van beide versies, stelde de reviewer overigens vast dat de Intel-editie dan wel fluisterstil is, maar wel meer geheugen lijkt te verbruiken. Met een gemiddeld verschil van 1 tot 2 MB per applicatie, betekent dat de Intel-machine meteen na het opstartproces al 15MB meer geheugen verbruikt dan de PowerPC-versie. Tussen beide iMacs is bij normaal gebruik overigens verder geen verschil te merken, enkel wanneer men specifieke dialoogvensters gaat opzoeken komt men te weten of het een Intel- of PowerPC-iMac betreft. Gezien de compleet andere architectuur is dit volgens de reviewer toch een knappe prestatie. Wat de reviewer wel opviel, was het feit dat de omschakeling van een single-core naar een dual-core chip onder Mac OS X veel minder duidelijk prestatievoordeel oplevert dan in Windows. Daarvoor geeft hij twee mogelijke verklaringen. Ten eerste is het mogelijk dat de scheduler van OS X gewoon beter is, waardoor er minder prestatieproblemen op een single-core processor zijn. Anderzijds acht hij het ook niet ondenkbaar dat de geheugenhoeveelheid van 512MB al een bottleneck vormt, zodat er niet ten volle van de twee cores geprofiteerd wordt. Voor specifieke vergelijkingen wordt overigens een uitgebreid gamma benchmarks gedraaid.

	Keynote 3.0: export naar Quicktime (s)
	iMac G5 1,9 GHz	108
	iMac Core Duo 1,83 GHz	110
	iMac Core Solo 1,83 GHz	183

AnandTech staat overigens uitgebreid stil bij het 'Performance per Watt'-argument dat door Steve Jobs ooit aangehaald werd als een van de redenen om over te stappen van PowerPC- naar Intel-chips. In een presentatie werd geclaimd dat met Intel tot meer dan vier keer betere prestaties haalbaar zouden worden in integerbewerkingen ten opzichte van IBM's PowerPC-chip. De reviewer besloot dan ook het energieverbruik van beide systemen aan een nader onderzoek te onderwerpen. Beide iMacs werden zo identiek mogelijk geconfigureerd, maar toch is de Core Duo-versie enigszins in het voordeel door zijn X1600-gpu op 90nm, in verhouding tot de X600 op 130nm. Doordat de gebruikte tests echter vooral cpu-intensief zijn en niet op de grafische mogelijkheden leunen, wordt het effect hiervan geminimaliseerd. Ook in het geheugen zit een afwijking: terwijl het Intel-systeem voorzien is van DDR2-667-reepjes, blijft de G5 op DDR2-533 steken. Idle zet de Core Duo meteen al een net resultaat neer, met een totaal energieverbruik dat slechts tweederde van dat van de G5 bedraagt. Ook onder belasting blijft de Intel-machine beduidend minder energie verbruiken dan de met een PowerPC-chip uitgeruste configuratie. Het uitschakelen van de tweede core, heeft overigens opvallend weinig invloed op het energieverbruik. Wanneer de prestaties per watt berekend worden, haalt de Core Duo zelfs een score die bijna dubbel zo hoog ligt als die van de G5. Met een core uitgeschakeld doet de Intel het nog steeds beter dan de IBM-chip, maar wordt het verschil veel kleiner.

	Totaal energieverbruik onder belasting (Quicktime H.264) (W)
	iMac Core Solo 1,83 GHz	59
	iMac Core Duo 1,83 GHz	64
	iMac G5 1,9 GHz	97

Tot slot belicht de reviewer ook nog even het principe van 'universal binaries' en Rosetta. Hoewel er heel wat programma's al beschikbaar zijn om op zowel PowerPC- als Intel-Macs gedraaid te worden, ontbreken er nog steeds enkele belangrijke namen waaronder Microsoft Office, de producten van Adobe en zelfs de professionele software van Apple zelf. Voor die programma's heeft Apple Rosetta ontwikkeld, dat de PowerPC-code van niet-universele binaries automatisch vertaalt naar x86-opdrachten voor de Intel-processor. Hoewel de code gecached wordt, brengt dit nog steeds een duidelijk prestatieverlies met zich mee. Bovendien stijgt ook het geheugenverbruik drastisch wanneer Rosetta gebruikt wordt voor een applicatie.

Reacties (33)

[johnbetonschaar]

Ten eerste is het mogelijk dat de scheduler van OS X gewoon beter is, waardoor er minder prestatieproblemen op een single-core processor zijn.

Zou kunnen ja... Wat me echter aannemelijker lijkt is dat de geteste software niet zwaar multithreaded is en ie daarom weinig verschil in prestaties ziet. Dat is bij Windows net zo, en in het algemeen bij desktop-toepassingen.

Anderzijds acht hij het ook niet ondenkbaar dat de geheugenhoeveelheid van 512MB al een bottleneck vormt, zodat er niet ten volle van de twee cores geprofiteerd wordt.

Klinkklare onzin, van een dualcore processor gaan je taken dus echt niet meer geheugen gebruiken ofzoiets. En dat je je 2e core niet kan gebruiken o.i.d. omdat je te weinig geheugen hebt is natuurlijk ook onzin, en zoiets wordt met deze 'conclusie' wel geimpliceerd. Tenzij er zo getest is dat het geheugen ramvol heeft gezeten en de boel continu aan het swappen was, heeft de hoeveelheid geheugen dus echt geen invloed. En als ze wel met te weinig geheugen hebben getest dan is het gewoon een hele slechte test geweest.

[Anoniem: 105188]

Elk programma is tegenwoordig "zwaar multi-threaded", ga maar eens naar de Windows Task Manager -> View - Select Columns en selecteer daar eens "Handle count" en "Thread Count".

Dat 1 staafje 512mb een bottleneck kan vormen is ook waar. Als je 2 cores hebt dan wordt de hoeveelheid en bandbreedte van je geheugen in 2 gedeelt. Dus elke core heeft maar 256mb voor zich en heef maar de helft van de bandbreedte voorzich.

[johnbetonschaar]

Elk programma is tegenwoordig "zwaar multi-threaded", ga maar eens naar de Windows Task Manager -> View - Select Columns en selecteer daar eens "Handle count" en "Thread Count".

Ehh hoe zal ik het zeggen... De task manager gebruiken en naar het aantal handles en threads te kijken is niet echt een goede manier om het al-dan-niet multithreaded zijn van je taken vast te stellen hoor... Wie zegt er dat niet 90% van de threads die jij ziet service threads zijn van Windows die 99.9% van de tijd in een sleep state staan... Ik ben zelf software engineer/programmeur, en geloof mij maar: heel weinig software wordt multithreaded geschreven, ten eerste omdat het veel moeilijker/foutgevoeliger is, en ten tweede omdat de meeste toepassingen gewoon helemaal geen baat hebben bij multithreading....

Dat 1 staafje 512mb een bottleneck kan vormen is ook waar. Als je 2 cores hebt dan wordt de hoeveelheid en bandbreedte van je geheugen in 2 gedeelt. Dus elke core heeft maar 256mb voor zich en heef maar de helft van de bandbreedte voorzich.

Ehh dat heeft niks met de hoeveelheid geheugen te maken he, maar alleen met de geheugen bandbreedte. Nergens staat iets over '1 staafje' in het artikel, en ook niet of het geheugen met 2 staafjes ineens dubbele bandbreedte heeft (dit is overigens een eigenschap van de geheugencontroller, en niet van de geheugenmodules zelf)...

Edit: ohja en dat beide cores slechts de helft (256MB) van het geheugen 'krijgen' is ook niet waar. Elke core kan van het geheugen gebruiken wat de taken die ie uitvoert nodig hebben... En aangezien je niet met 2 cores ineens ook 2x zoveel processen hebt draaien is het geheugen-argument dus redelijke onzin.

[Chatslet]

Scheduler in OS X is inderdaad beter/anders dan in windows. Onder OS X werkt alles veel soepeler met meedere programma's open. Wat hier boven geroepen wordt over dat geheugen geen invloed heeft is grote onzin. Hoe voller het geheugen komt te staan hoe meer pages er gewisseld moeten worden tussen het geheugen en de harde schijf. Het kan dus zijn dat 1 core daar bijna vol op mee bezig is en dat kost dus performance. Ook roept er hier iemand "Intel heeft toch dual channel?!" Uhm ja vast wel maar niet met maar 1 reepje geheugen.....

[Dreamvoid]

Scheduler in OS X is inderdaad beter/anders dan in windows. Onder OS X werkt alles veel soepeler met meedere programma's open

Uh, uit dit artikel: "One other potential reason is that the OS X interface in general isn't particularly responsive, so it may just be that the dual core effect is dulled thanks to a slower UI (slower compared to Windows that is)."

Edit: oh en SizzLor, Linux doet het toch verdomd aardig met een monolitische kernel, dus dat gaat zeker niet altijd op.

[Anoniem: 105188]

Dat tegenwoordig applicaties meerdere threads hebben draaien wil zeggen dat het makkelijker is voor de scheduler deze applicatie over meedere cores te verdelen. Je hebt gelijk als je zegt dat multithreaded applicaties meestal threads hebben draaien die in een blocked status wachten op een vrijgeving maar dit soort service threads zijn meestal zware processen die heelerg veel tijd nodig hebben of de rest van de applicaite blocken als ze in de mainthread worden opgenomen. Vandaar dat het altijd nut heeft als deze over meerdere cores worden vedeelt. Terwijl de mainthread op de ene core gezellig verder gaat wordt de zware bewerking op het ander afgehandeld.

Als elke core de helft geheugen hoeveelheid tot zijn beschikking heeft betekent dit dat er meer terug wordt gegrepen op het paged geheugen wat impact heeft op de performance.

Dat elke core met de intel core duo architectuur de helft van het geheugen krijgt is waar, kijk maar eens in de datasheets. Dit hebben ze gedaan vanwege memmory management perikellen. Als ze zouden doen wat jij zegt (wat overigens wel kan en sommige architecturen doen het ook) dan zou het betekennen dat elke core het geheugen van het andere zomaar kan overschrijven en als men in een onverwachte race conditie terecht komt dan gebeurd dit ook.

Als alle twee de cores daadwerkelijk onafhankelijk van elkaar hun werk willen doen dan moeten ze ook daadwerklijk onafhankelijk van elkaar I/O moeten hebben op het geheugen. Dus ze zullen alle twee op het zelfde momment toegang moeten hebben op het geheugen. Dat je met twee staafjes theoretische 2x zoveel bandbreedte is ook waar. Kijk maar eens naar de Dual-channel moederborden die tegenwoordig op de markt zijn.

Het beste zou natuurlijk zijn als er 2 onafhankelijke memory controller op het moerderbord zouden zitten maar dat is niet altijd mogelijk. Een goede memory controller die goed onderscheid kan maken tussen alle twee de cores en goede prioriteit kan geven aan I/O aanvragen is ook voldoende.

Overigens, iedereen is tegenwoordig software ingeneur daar is niks bijzonders meer aan. Zelfs snotapen van 11 kunnen coden. Dat jij voorkeur geeft aan een monolitische opbouw in je code wil dit niet zeggen dat iedereen dit doet. Persoonlijk geef ik de voorkeur aan precies het omgekeerde. Zoveel mogelijk aparate componenten en processen.

[johnbetonschaar]

Overigens, iedereen is tegenwoordig software ingeneur daar is niks bijzonders meer aan. Zelfs snotapen van 11 kunnen coden. Dat jij voorkeur geeft aan een monolitische opbouw in je code wil dit niet zeggen dat iedereen dit doet. Persoonlijk geef ik de voorkeur aan precies het omgekeerde. Zoveel mogelijk aparate componenten en processen.

Pfft mag ik even lachen zeg... Hebben die 11 jarige snotapen ook een WO-opleiding gevolgd en ervaring met het ontwikkelen van software projecten van > 100,000 regels code? Waaronder een zwaar multithreaded spelserver in Java? En is 'Hello World' in Visual Basic schrijven bij jou ook software engineering?

Ik zal maar niet op de andere argumenten ingaan omdat het anders een flameware op gaat leveren, maar ze staan in ieder geval vol feitelijke fouten (tussen een paar opmerkingen die wel correct maar niet relevant zijn)...

[johnbetonschaar]

@Tha Lord:

Daarom zei ik ook al: als ze getest hebben met taken die zoveel geheugen gebruiken dat de boel moet gaan pagen, dan is het gewoon een hele slechte test, als het doel was om de verschillen tussen de CPU's te meten...

[Anoniem: 38786]

sorry, maar ik heb een mac en het loopt hier super flexibel. probeermaar eens zo een grafische gui te laten werken op een windows bak.

maar om ff door te gaan: het argument ging hier over de scheduler, niet over de gui, dus ik vind je argument nogal offtopic.

[Anoniem: 105188]

Mjah als je een WO opleiding hebt gehad waarom beschouw je jezelf als software ingeneur? Dat is het werk van een MBO of MAVO//HAVO opgeleid iemand.

Bij het WO gaat het er eigenlijk om dat je dingen kunt bedenken en niet dingen kunt maken. IIG dat is hoe ze het mij hebben uitgelegd. Coden is een bijzaak, zolang je maar zelf iets kan bedenken en dit op papier kun vastleggen. Als je het dan in code wilt omzetten vind je een paar HBO/MBO of HAVO/MAVO slaafjes die het voor jou omzetten naar code.

Een spelserver in Java? Wat heb jij daarmee te maken? Daar ben jij als WO opgeleiden veelste duur voor.

[johnbetonschaar]

Mjah als je een WO opleiding hebt gehad waarom beschouw je jezelf als software ingeneur? Dat is het werk van een MBO of MAVO//HAVO opgeleid iemand.

Bij het WO gaat het er eigenlijk om dat je dingen kunt bedenken en niet dingen kunt maken. IIG dat is hoe ze het mij hebben uitgelegd. Coden is een bijzaak, zolang je maar zelf iets kan bedenken en dit op papier kun vastleggen. Als je het dan in code wilt omzetten vind je een paar HBO/MBO of HAVO/MAVO slaafjes die het voor jou omzetten naar code.

Laat een software engineer dan ook precies de gene zijn die de software 'engineered' (ingenieur: WO-titel), en de programmeur degene die het tiep/implementatiewerk voor zijn rekening neemt...

Inderdaad ligt de nadruk voor mij op het ontwerpen en op papier vastleggen van een design, maar dat coden een bijzaak is die alle 'HBO/MBO/MAVO slaafjes' kunnen doen is echt een fabeltje... Snap wel dat je het zegt hoor want zo is het mij ook geleerd, maar ga maar eens in een bedrijfscontext software ontwikkelen en dan merk je snel zat dat dit een utopie is. Sowieso kun je een goed ontwerp ook op een slechte manier implementeren en dat is dus niet de bedoeling....

Een spelserver in Java? Wat heb jij daarmee te maken? Daar ben jij als WO opgeleiden veelste duur voor.

Misschien heb ik die dan ook voor mijn plezier ontwikkeld? Voor een habbekrats? Niet alles hoeft alleen maar commercieel en duur betaald te worden. Komt nog bij dat serversoftware in het algemeen verdomd lastig te ontwikkelen is, en dit dus echt geen werk is voor 'snotapen van 11'. Jaartje of 5 tot 10 aan actieve ontwikkelervaring is minimaal vereist....

[Anoniem: 61096]

Bij het WO gaat het er eigenlijk om dat je dingen kunt bedenken en niet dingen kunt maken. IIG dat is hoe ze het mij hebben uitgelegd. Coden is een bijzaak, zolang je maar zelf iets kan bedenken en dit op papier kun vastleggen. Als je het dan in code wilt omzetten vind je een paar HBO/MBO of HAVO/MAVO slaafjes die het voor jou omzetten naar code.

Wat raar dan dat ik bedrijven kan die voornamelijk software ontwikkelen waar de gemiddelde opleiding van de software ontwikkelaars toch echt WO is (en een redelijk aantal post docs.) (En ja, dit zijn bedrijven met 100+ aan werknemers.)

Een software ontwikkelaar moet wel snappen waar die mee bezig is. Als dat niet zo is krijg je echte bagger software.

[Anoniem: 42145]

Als je het dan in code wilt omzetten vind je een paar HBO/MBO of HAVO/MAVO slaafjes die het voor jou omzetten naar code.

Dit is toch wel een van de meest hardnekkige fabeltjes op tweakers die maar blijven terug komen. Hoevaak is dit argument nu al weerlegt in 1 van de 1000'en threads over dit onderwerp en hoe vaak moet het nog terug komen?

Wat denk je wat voor opleiding Linus had? Wat denk je wat de minimale graad is die je moet hebben om als programmeur bij Microsoft of Apple aan de slag te kunnen?

Ik ben zelf ook WO afgestudeerd en doe veel aan programmeerwerk. Een dikke 70% van de dingen die ik maak zou ik toch echt niet aan een HAVA/MAVO of MBO 'slaafje' willen uitbesteden. HBO is overigens ook gewoon een hogere opleiding, en die zou ik zeker niet zomaar als 'code klopper' of 'slaafje' willen betitelen.

[catfish]

ik dacht dat intel toch al lang aan dual-channel deed, dus lijkt het me raar dat dit een probleem zou zijn

daarbij, als je echt het verschil wilt zien tussen 1 en meerdere cpu's, dan kies je voor een klein testprogramma dat vooral rekenintensief is en weinig geheugen verbruikt, deze test is dan wel niet echt real-life, maar geeft wel een beeld wat er gebeurd in optimale omstandigheden
ook is er zoiets als het synchronisatie van threads, een prog met 2 threads wil dus helemaal niet zeggen dat het sneller loopt op een dual-core

[Saturnus]

Het plaatje:
Het programma vindt dat deze CPU van Intel een Pentium 6 is...nou ik heb nooit een P5 gezien...

[_JGC_]

P6 slaat gewoon op de i686 architectuur. P5 stond voor de klassieke Pentium, De P54C was een van de eerste Pentiums bijvoorbeeld.
Na de i686 architectuur is er niet veel ingrijpend veranderd. Hier een instructiesetje extra, daar eentje erbij, hier wat optimalisaties, daar wat optimalisaties, maar de P6/i686 benaming is er altijd bij gebleven. i786 heb ik nooit zien verschijnen.

[Anoniem: 63780]

De i786 heb je beslist zien verschijnen. Dat is namelijk de Itanium van Intel.

Bron

[[micro]]

en volgens deze URI wordt met Intel 80786 of Intel P7 dan weer de Netburst Microarchitecture oftwel de sputterende motor van de Pentium 4.

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

[masser120]

Dat viel mij ook al direct op! Misschien is dan de Intel Pentium D de Pentium 5 en dus de Core Duo (wat een zaadnaam) de Pentium 6. Tenminste, als 'oude naamstijl'

[TD-er]

Ten eerste is het mogelijk dat de scheduler van OS X gewoon beter is, waardoor er minder prestatieproblemen op een single-core processor zijn. Anderzijds acht hij het ook niet ondenkbaar dat de geheugenhoeveelheid van 512MB al een bottleneck vormt, zodat er niet ten volle van de twee cores geprofiteerd wordt.

Nogal een vreemde conclusie.
Als je duidelijk het verschil wilt testen tussen de processoren, zorg je toch dat je zoveel mogelijk andere mogelijk beperkende factoren uitsluit. Voldoende geheugen erbij prikken lijkt me dan een van de eerste stappen.

Verder lijkt het mij ook niet onwaarschijnlijk dat de process-scheduler gewoon eerst de eerste core alle threads aan toewijst en daarna pas de 2e core gaat gebruiken om op die manier een zo laag mogelijk verbruik te realiseren. Ze adverteren namelijk met een bepaalde prestatie per Watt.
Bij Windows gebruikt de scheduler de core die het minst belast is, waardoor je OS en drivers enzo door de ene core afgehandeld worden, terwijl het rekenintensieve proces op de 2e core draait. Daardoor voelt Windows zoveel sneller aan met 2 cores.

[Anoniem: 144697]

de imac wordt geleverd met 512mb, dus het lijkt mij niet dat je hem moet testen met 1024mb, want niet iedereen gaat zijn laptop uitbreiden. Laat staan, niemand weet haast dat dat kan!

[Dreamvoid]

Ik heb nooit helemaal begrepen waarom Apple zijn consumentensystemen überhaupt standaard met zo weinig geheugen uitlevert, bij de Mac Mini is dit ook al zo schraal. OS X *vreet* RAM en het kan toch niet de bedoeling zijn om je standaard systeem met zo'n bottleneck uit te rusten. Goed, dat betekent wel dat iedereen "moet" upgraden naar Apple's dure extra geheugen, en als tweaker gooi je er gewoon el-cheapo RAM in, maar als niet-tweaker (waar de Macs toch voor bedoeld zijn) voel je je toch een beetje bekocht als er achter komt dat je dat van tevoren had moeten weten, zeker vanwege Apple's betrouwbare "good guy" imago. Bij een prijsvechter als Dell weet je op je klompen dat je donders goed moet opletten bij een aanbieding, van Apple verwacht je toch dat het standaard wel goed zit. Maar misschien ben ik wat naief

[Anoniem: 133254]

1// imac: laptop? -> desktop.
2// ram uitbreiden: iedereen ziet dat het een van de opties is, net als grotere harddisk, die je kan selecteren als je de mac in je virtuele winkelwagen gooit.

[De raad hierbij is het absolute minimum er in laten steken, en bij een geheugenboer het apart te kopen omdat Mac belachelijk veel voor z'n geheugen extra vraagt.]

[Dr. Strangelove]

Wat de reviewer wel opviel, was het feit dat de omschakeling van een single-core naar een dual-core chip onder Mac OS X veel minder duidelijk prestatievoordeel oplevert dan in Windows.

Maar nog steeds zo'n 80% verschil aan de grafieken te zien. Nogal interessant als je nagaat dat de iBook met een Solo wordt uitgerust; het performance verschil tussen de Macbooks en iBook wordt dus fors groter dan tussen de Powerbooks en iBooks.

[mOrPhie]

Ik ben al die vergelijkingen tussen de G5 en de core duo een beetje zat aan het worden. Iedereen die aan een Core Duo iMac heeft gezeten zeggen allemaal hetzelfde: Het voelt veel sneller en soepeler aan. En dat is toch een beetje wat geldt, niet al die cijfertjes.

[Adrianb]

Ik ben echt doodverbaasd over het wattage :x
Ik dacht dat -de mensen die tegen de Intel change waren- constant rond riepen dat de Intel processor veel meerenergie zouden verzuipen, niet dus
Geldt hetzelfde voor de laptop modellen?

[GekkePrutser]

Dit is dan ook een low-power processor, de opvolger van de Pentium M voor laptopgebruik. Vandaar ook de lagere kloksnelheid dan gebruikelijk bij de Pentium 4. De opvolger van de P4 die echt bedoeld wordt voor desktopgebruik, komt over een half jaar pas (Merom heet die, geloof ik). Al zal die naar verwachting ook een lager stroomgebruik hebben.

Maargoed, de mensen die riepen dat Intel veel stroom verbruikt, die zaten dus aan de P4 te denken.

Edit: Jan de Groot was me voor, sorry.

[Whieee]

De Merom zal niet veel meer zijn dan een opvolger van de Core Duo, met EMT64 support en wellicht wat meer L2 cache en een hogere FSB. Al met al zal de Merom stukken minder energie verstoken dan de Pentium-D denk ik zo

Misschien leuk als Apple in september komt met 8-way PowerMac (4-way Merom) Dan heb je 2x zoveel cores als een PowerMac Quad en waarschijnlijk toch nog een lager stroomverbruik

[_JGC_]

Dit is dan ook niet de Pentium IV die ze in die machines stoppen, maa het laptopplatform van Intel in desktops toepassen. Intel staat al jaren bekend om het zuinige Centrino platform. De core solo en core duo oplossingen zijn gewoon het vervolg hierop. Apple heeft gedaan wat tweakers hier al tijden roepen: Intel moet de mobile centrino lijn meer gaan gebruiken op de desktop.

[cc bcc]

Ik dacht dat -de mensen die tegen de Intel change waren- constant rond riepen dat de Intel processor veel meerenergie zouden verzuipen, niet dus

Dat is niet waar, Apple heeft gezegd dat de voornaamste reden om te switchen juist het lage energieverbruik van toekomstige (nu dus huidige) intel chips was. Ik kan me niet voorstellen dat tegenstanders van de switch dit omdraaiden. En onder mac gebruikers waren maar weinig tegenstanders, nadat de shock een beetje bezonken was.

[Anoniem: 115558]

Als mensen interesse hebben kan ik hetzelfde ff op mijn X2 testen Wel grappig dat je nu een G5, Athlon(64/X2) en een P-M in hetzelfde OS kan benchen

[multipasser]

Dat is de 10.4.4 met patch die jij hebt!
Maar de full Native Intel versie die op de MacTels staat nu is nog niet in 'install' vorm. Alleen als recovery op hd!

Dus de resultaten kunnen verschillen.

[Anoniem: 42145]

Ben ik nu eigenlijk de enige die deze cijfers niet super indruk wekkend vind?

De Core Duo is op grofweg dezelfde clock maar met 2 cores ongeveer even snel als een single core G5. Kwa prestatie is het amper een vooruitgang.

En dan die stroom-besparing. Elke watt is meegenomen, zeker in zo'n krap ontwerp als de iMac, Mac Mini of een notebook. Maar 2/3 van het verbruik van de G5... Ik had toch eigenlijk wel minimaal op de helft gehoopt, stiekum nog als ietsjes meer dan dan de helft.

Omdat de prestaties niet zoveel verschillen en de intel Mac hoe dan ook zuiniger is, zal ik bij een keuze tussen die 2 toch zeker wel voor de intel gaan. Toch kan ik me niet helemaal aan het gevoel onttrekken dat de winst van de switch wat marginaal is voor de iMac.