<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom">
	<channel>
		<title>ARM Cortex-A15 prestandatestad - slår Intel Atom på fingrarna</title>
		<description>Diskutera ARM Cortex-A15 prestandatestad - slår Intel Atom på fingrarna</description>
		<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html</link>
		<lastBuildDate>Wed, 19 Jun 2013 17:38:58 +0200</lastBuildDate>
		<generator>JComments</generator>
		<atom:link href="http://www.nordichardware.se/feed/com_content/46792/Page-1.html" rel="self" type="application/rss+xml" />
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20815</link>
			<description><![CDATA[ Sorry att jag inte svarat tidigare, trodde tråden var "död" tills jag nu såg att antalet inlägg hade ökat. Är det mejladressen som du undrar efter? Den finns att hitta på anandtechs hemsida under terms.]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sat, 10 Nov 2012 02:48:47 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20815</guid>
		</item>
		<item>
			<title>fackamato säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20807</link>
			<description><![CDATA[ Vart att maila Anand?]]></description>
			<dc:creator>fackamato</dc:creator>
			<pubDate>Fri, 09 Nov 2012 11:45:13 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20807</guid>
		</item>
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20662</link>
			<description><![CDATA[Försökte göra en edit men fick inte det på grund av att meddelandet blev för långt :( Edit: Mailade även Samsung angående förbrukningen som anandtech visade på och fick svar inom någon minut (bra med kontakter ibland :)). När man stänger av skärmen på Chromebook så stängs endast bakgrundsbelysningen av inte själva LCD panelen. Så anandtech redovisning av förbrukningen är helt fel på båda systemen.]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sun, 04 Nov 2012 13:41:09 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20662</guid>
		</item>
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20661</link>
			<description><![CDATA[ Inte speciellt! Det tar alltid några månader innan kompilatorerna har anpassat sig till nya CPU/GPU/SoC, detta gäller alla plattformar även x86. Bra exempel för detta på x86 plattformen är till exempel när Bulldozer kom, då tog det också ett tag för så väl OS som kompilatorer att optimeras. När man sitter som assemblerprogrammerare kan man alltid sitta och bolla med koden för vad som ger bäst resultat något som aldrig går att förutspå innan du har den fysiska produkten. Grunden är förstås den samma men i och med nya instruktioner och förändringar hur minnet hanteras så tar det liten stund innan man kommer kommer fram till den bästa lösningen. Detta tar någon månad innan det kommer till kompilatorerna, oavsett plattform. Vad gäller assemblerprogrammering på medelstora eller stora projekt så är det inget problem. Vi har ett x86 program här som är antal hundratusen rader kod som är till 80% assembler, det går helt enkelt inte att lösa på något annat sätt. Det kanske skulle varit något snabbare att utveckla det i C med det gick helt enkelt inte att klara kravspecifikationen. Assemblerprogrammering har ofta ett dåligt ryckte ibland många andra programmerare, bland annat att det ska ta så lång tid eller är så svårt att debugga. Men inget utav detta stämmer, alla tycks tro att vi skulle använda samma assemblerverktyg nu som vi gjorde för 20 år sedan. Utvecklingen går framåt även i assemblerranchen! Sedan är det så att ska du göra ett snabbat och effektivt program så finns det inget som slår assembler, även en halvkass assemblerprogrammerare gör bättre program än vad någon kompilator klarar av att göra.]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sun, 04 Nov 2012 13:27:23 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20661</guid>
		</item>
		<item>
			<title>Uridium säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20660</link>
			<description><![CDATA[ Siffrorna jag hela tiden använt är utan skärm Från artikeln "Given that we're dealing with somewhat different panels here, I wanted to see what power consumption looked like if we removed the panels from the equations. I re-ran all of the power data with the display turned off:" Och oavsett så tycker jag det är svårt att begripa varför Cortex A15 plattformen avviker så mycket mer från sitt TDP värde jämfört med Atom-plattformen, framförallt då Exynos 5250 är ett SoC så en rad komponenter som ingår i dess TDP tillkommer till det TDP som N570 har. Du nämner även RAM, Atom kör ju med vanligt DDR2 RAM medan Cortex A15 plattformen kör med DDR3L, så även den komponenten är ju till nackdel för Atom. Så om det inte är SoC:et som drar ström, vad är det då och varför drar motsvarande mycket mindre på Atom-plattformen? Det du skriver om kompilatorer låter ju som om ARM blir en VÄLDIGT dyr plattform att jobba med. Visst kan man i vissa specifika fall även få program på x86 att gå snabbare genom att peta i assembler, men skriver man programvara på ett par 100k rader kod (vilket är rätt normalt för ett medelstor projekt) så fungerar det ju inte att hacka i assembler. Och tittar man på kod som GCC genererar för x86_64 så är den väldigt bra. Undantaget är flyttalsintensiv kod där ICC gör ett mycket bättre jobb, framförallt om man använder sig av deras "vector extensions (Fortran idéer översatta till C) då kompilator då kan använda SSE/AVX väldigt effektivt. Man kan då skriva saker som double v1[N] = { elements }; double v2[N] = { elements }; double v3[N]; v3[:] = v1[:] + v2[:]; vilket utför '+' elementvits m.h.a SSE/AVX (om man vill). Och med multicore så kommer ju nära nog 100% av alla prestandaproblem från interaktion mellan CPU-kärnorna och sådan kod optimerar man inte genom assembler utan genom en bra arkitektur + möjligt optimerade lås med det kan man uppnå med t.ex. GGC atomic built-ins så fungerar koden fortfarande på alla arkitekturer som GCC stödjer.]]></description>
			<dc:creator>Uridium</dc:creator>
			<pubDate>Sun, 04 Nov 2012 12:47:13 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20660</guid>
		</item>
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20658</link>
			<description><![CDATA[ Att använda C++, Speciellt MS C++ 11 ger mig rysningar i hela kroppen. Även på X86 plattformen gör jag normalt mellan 30-70% bättre prestanda med Assembler jämfört med C++. Du har helt enkelt ingen kontroll på koden alls som C++ programmerare. Bara en sådan sak att när vi jämförde GCC i C med MS C++11 så hamnade MS C++11 ganska långe efter. Antagligen beror detta till viss del på optimeringar som behöver göras innan det blir riktigt bra men det kommer aldrig komma i närheten av assembler. Men att MS skulle puscha för att man använder deras produkter är väl inte helt oväntat :). Vad gäller förbrukningen är det enda jag i dagsläget får säga att den ligger på 4,4W vilket med lite googlande du också kan läsa lite här och var. Du hänvisade sedan till AnandTech som fortfarande är inklusive skärm och det spelar ingen roll om du är i idle eller full load, det är minimal skillnad i förbrukning för skärmen. AnandTech siffror; Idle:4,07W så är det 99,9% skärmen. Peak:9,27W I peak får du således 5,2W, räkna med att komponenter runt SoC ökar men 0,8W under belastning så har du de 4,4W som jag talar om. Lite väl enkelt räknat men stämmer på ett ungefär. 4,4W är som sagt var det enda siffran i detta som jag är 100% säker på. Vårat devboard drar som sagt 4,6W med minnet inräknat. Om du kollar in Samsungs hemsida så kan du se att de snart kommer med en ny version av Exynos 5250 och då kommer det med största sannolikhet komma mer officiell information om TDP och så vidare :)]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sat, 03 Nov 2012 20:55:58 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20658</guid>
		</item>
		<item>
			<title>Uridium säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20657</link>
			<description><![CDATA[ Låter lite skumt att Cortex A15 skulle kräva assembleroptimeringar. En av de fördelar som ARM tryckt på med Cortex A9 var att den inte alls är lika "kräsen" med hur instruktionerna ligger (tack vare OoO och jämfört med Cortex A8 där assembleroptimeringar ibland gav en hel del). Med Cortex A15 har ju ARM prata/skrutit om vad bra den passar nya C++11 standarden och även Microsoft pushar ju för att man ska använda C++ för Windows RT enheter. Och angående vad jag fått siffrorna för strömförbrukningen. Jag använder siffrorna från AnandTech. Vad utöver det som ingår i SoC:et är det som drar ström när skärmen är borträknad? SoC är ju en dator på ett chip och saker som SSD kan inte tillföra något i en JS-benchmark. Om TDP är 4.4W så verkar det ju skumt att man mäter upp en genomsnittsförbrukning på över 8W (över 10W med skärm). Så vad utöver SoC:t drar så pass mycket som 4W i en JS-benchmark? Jämför med N570 som har en TDP på 8.5W + sydbryggan, WiFi, NIC och liknande är externa kretsar där. Trots det drog den "bara" 11.4W, d.v.s 2.9W utöver vad som CPUn drar.]]></description>
			<dc:creator>Uridium</dc:creator>
			<pubDate>Sat, 03 Nov 2012 19:22:49 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20657</guid>
		</item>
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20656</link>
			<description><![CDATA[ För att ta företaget generellt: Positiva, som assemblerprogrammerare. Negativa som C programmerare. C kompilatorerna behöver göra en hel del optimeringar innan man kan vara nöjd med resultatet. Själv är jag ju assembler programmerare och tycker det är ett stort steg framåt när det gäller prestandan, detta utan att nämnvärt höja strömförbrukningen. Ser fram mot de företag som gör egna varianter av ARM SoC, Qualcomm framför allt. Krait är ju ingen A15 utan en A9 bas som har viss A15 funktionalitet. Ska bli riktigt roligt och se deras nästa SoC som kommer vara helt baserad på A15 men som vanligt med deras egen touch med bland annat integrerad 4G/lte men även ska de ändra något på minnet, exakt vad vill de dock inte prata så mycket om.]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sat, 03 Nov 2012 16:02:08 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20656</guid>
		</item>
		<item>
			<title>Morkul säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20654</link>
			<description><![CDATA[ Vet inte vart du får dina uppgifter ifrån men skillnaden mellan Exynos 4210 (Dual A9) och Exynos 5250 (Dual A15) är inte speciellt stor, 5250 har trots allt en maxförbrukning på endast 4,4W. Vad Qualcomm kommer med står i stjärnorna då deras A15 inte finns på marknaden ännu. Dock kommer det nog bli lite högre än 4,4W men då har de även inkluderar 4G/TLE i kretsen. Men som sagt innan vi får marknads exemplar att testa med så är så väl Qualcomm som Intels siffror endast avancerade chansningar. Oavsett företag så litar jag inte en sekund på olika tester som är gjord utan tillverkarna själva.]]></description>
			<dc:creator>Morkul</dc:creator>
			<pubDate>Sat, 03 Nov 2012 15:51:16 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20654</guid>
		</item>
		<item>
			<title>Uridium säger:</title>
			<link>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20652</link>
			<description><![CDATA[Jämförelsen mellan Haswell och Cortex A15 är ändå rätt meningslös mer än att visa just att det inte finns något som magiskt får ARM CPU:er att dra mindre ström. De ligger i helt olika prestandasegment och också i helt olika prissegment. Att ett chip med brutal prestanda och nära 1 miljard transistorer ändå kan dra så pass lite ström är ändå något som jag personligen är rätt imponerad av. Rätt jämförelse är mot Atom, som fram till Cortex A15 har varit snabbare än allt ARM kunnat visa upp. Cortex A9 har högre IPC än Atom, men Atoms längre pipe-line har gjort det möjligt att skala upp klockfrekvensen mer så absolut prestanda har ändå varit högre. Detta har man gjort på 32nm och i nya Motorola Razr I kör man Medfield på 2GHz och har ändå bättre batteritid i den luren än Razr M som kör med Snapdragon S4 (på 28nm). Man får inte glömma hur gammal Atoms CPU-kärna är och hur extremt simpel den är även jämfört med Cortex A9. Atom har mindre L1D$ (24kB mot 32kB), den har mindre TBL 16L1/64L2 mot 32/128, den kan avkoda 2 instruktioner (som A9, medan A15 kan avkoda 3), den har 2 exekveringsportar (mot 4 i A9 och 8 i A15), har absolut ingen register renaming (vilket ÄR ett problem i 32-bitars x86 kod) medan A9 har detta för heltalsregister och A15 både för heltal och flyttalsregister. Atom kan bara utföra en "load" ELLER en "store" per cykel, precis som A9 medan A15 kan utföra en "load" OCH en "store" per cykel. Väldigt lite är känt kring nästa Atom utöver att den kommer tillverkas på 22nm, ha en HD4000 GPU och vara "out-of-order". Men ett är säkert: den kommer vara väsentligt mycket snabbare än dagens Atom och den kommer drar betydligt mycket mindre ström än Haswell. Sett ur den vinkeln så borde nog ARM vara lite nervösa, finns nog ingen som tvivlar på att nya Atom kommer vara snabbare än A15. Jämför man Pentium MMX 200 (dual-decode/issue in-order precis som dagens Atom) mot Pentium Pro 200 (dual-decode/issue out-of-order) så gick prestanda upp runt 70% mellan dessa. Problemet för Intel är att nya Atom inte ser ut att dyka upp förrän i slutet av 2013. Deras lycka verkar vara att A15 än så länge verkar dra väl mycket ström jämfört med A9 och Krait som Atom ändå är konkurrenskraftig mot.]]></description>
			<dc:creator>Uridium</dc:creator>
			<pubDate>Sat, 03 Nov 2012 11:57:02 +0200</pubDate>
			<guid>http://www.nordichardware.se/CPU/Styrkrets/arm-cortex-a15-prestandatestad-slar-intel-atom-pa-fingrarna.html#comment-20652</guid>
		</item>
	</channel>
</rss>
