Intel Core i7-5775C och i5-5675C "Broadwell" kan pressas ned till 37 W TDP

Permalänk
Entusiast
Skrivet av Paddanx:

Nja.. håller inte helt med.

Det med "en siffra" har du helt rätt i. Det måste finnas mer info.
Men att ha en som avgör dens enkeltrådade, en för 4 trådade och en för 8 trådade eller fler kan utgöra en hel del för ett prestanda index.
typ som första siffran är 8 tråd eller mer, nästa är 4 trådar, nästa är enkel trådad, där du kan lägga sista på övriga saker, som turbo, upplåst, osv.

Typ i7-"8-4-1" som du ersätter 8-4-1 med de prestandan de har vid de trådarna. De kraftigaste kommer då få högsta numret först, vilket de ska, men samtidigt man man se skillnad mellan tex 4960x och 4690k rätt snabbt. Du kan om du vill lägga till gen framför hela så du kan skilja mellan gammal och ny, då det mellan gen är svårt att få perfekt bild.
Största problemet jag ser är att du snabbt få slut på siffror...
så du kommer behöver "88-44-11 eller nått sånt.

Läs efterföljande inlägg så får du se att det inte går. Pentium G3258 och 4790K kan prestera identiskt lika eller helt olika vid samma frekvens beroende på vilket benchmark du kör. Enkeltrådad prestanda är inte bara beroende av klockfrekvens. I det här fallet är det två Haswell (resultatet är samma om man byter ut 4790K mot 4770K) så samma arkitektur presterar inte alltid likadant vid samma klockfrekvens. I det fallet jag länkade till beror det på storleken på cache. Yoshman drog ett mer generellt exempel mellan helt olika arkitekturer där det blir ännu tydligare hur meningslös en ensam siffra är.

Det enda vettiga sättet att avgöra hur en processor presterar är att titta på en rad tester som undersöker olika aspekter av designen. Sedan får man göra en bedömning av vad som uppfyller ens egna krav.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Inaktiv

Trimma TDP är intressant, just detta kan man väl inte göra innan? Man kan ändra frekvensen och volten som påverkar TDP, men man kan inte direkt styra TDP.

Angående namngivningen i7, i5 och i3 så borde Intel byta namn på dem till slow, slower and slowest så förstår kunderna bättre vad de köper för produkt. Jag tycker märkningen med processorer tack varje att man har tillgång till internet överallt inte är så stor problem, men visst borde diverse testresultat stå vilken en seriös butik kan ta med.

Permalänk
Datavetare
Skrivet av Uzanar:

Tack för det svaret Yoshman, hoppades på att du skulle komma inhoppandes

Ja då är det väl lite som jag trodde då.
Men finns det verkligen inte något slags sätt att beräkna antalet "instruktioner" per klockcykel som en processor utför i ett specifikt program för IPC står ju trots allt för "Instructions per clock cycle"?
Jag har ingen aning om vad en instruktion är i detta sammanhang men... upplys mig gärna

Ska försöka mig på en lite populärvetenskaplig förklaring, så är en hel del detaljer jag skippar. Få se om det överhuvudtaget lyckas...

IPC står mycket riktigt för "Instructions Per Clock cycle" och "instruktion" i strikt teknisk mening är antal så kallade "maskinkodsinstruktioner" som körs per cykel. Om man tar denna definition av IPC så är ett visst värde här bara något som går att jämföra mellan CPUer som kör samma uppsättning instruktioner. Är här man ser termer som "x86", "ARM", "PowerPC" m.fl, detta är exempel på CPUer som använder olika typer av instruktionsuppsättningar, olika "ISA" (Instruction Set Architecture).

För att förstå varför det inte går att jämföra denna definition av IPC mellan CPUer med olika ISA inte kan jämföras kan man ta ett exempel där det är ganska stor skillnad i hur många maskininstruktioner som behövs. Anta att det finns ett tal i RAM som vi vill addera ett till, på x86 ser detta ut så här om vi antar att positionen talet är lagrat i minnet ligger i CPU-register edi (ett "register" är det snabbaste typ av minne som finns i en CPU, finns ett väldigt begränsat antal register, 8st i 32-bitars x86, 16st i 64-bitars x86 och 32-bitars ARM, 32st på 64-bitars ARM och PowerPC).

Antag också att vi vill göra samma sak på ARM och där säger vi att register r0 innehåller positionen talet är lagrat. Namnen på register är här irrelevant, använder just dessa då det är de register som råkar användas för första argumentet till funktioner på respektive arkitektur. Trots olika namn representerar registren här samma sak, en minnesposition och de är 32-bitar långa.

x86

add DWORD PTR [edi],0x1 ; add one to the number at the location pointed to by edi

ARM

ldr r3, [r0, #0] ; load content pointed to by r0 into r3 adds r3, #1 ; add one to r3 str r3, [r0, #0] ; store content in r3 to the location pointed to by r0

Då ARM är en s.k. RISC-arkitektur kan den bara utföra aritmetik mot register, det som händer här är att man läser upp minnescellen som r0 refererar till till register r3, adderar ett till r3 och sparar sedan ner resultat i minnet igen.

För att göra samma sak på dessa två olika ISA krävs alltså en instruktion i ena fallet men tre i det andra. I genomsnitt är det inte alls så här stor skillnad, ville bara visa hur stor skillnad det kan vara i relativt fundamentala fall.

Som lite extra kuriosa är det så att de flesta moderna CPUer bryter upp maskininstruktionerna i mindre interna instruktioner (även vissa ARM modeller gör detta), så på säg Haswell så blir det väldigt likt ARM varianten internt då man där separerar minnesoperationer och beräkningar. Haswell kan påbörja upp till 4 interna instruktioner för beräkningar och upp till 4 interna instruktioner för minnesoperationer per cykel men den kan maximal köra 5st x86 instruktioner per cykel (är praktiskt möjligt att skriva ett program som faktiskt får IPC på 5 sedan Sandy Bridge, men det gör inget speciellt intressant...).

Så ofta när man säger "IPC" menar man inte den strikt tekniska termen utan mer: ungefär hur mycket kan man förvänta sig att en viss CPU presterar per CPU-tråd och tidsenhet jämfört med andra. D.v.s. man har inget absolutbelopp utan det relaterar mer till antal "instruktioner" i programmeringsspråk som C, Java eller liknade som man kan köra per tidsenhet. Det är ett mycket mer användbart mått, men varierar från program till program och varierar även med storleken, typen och utformningen på data man jobbar med => man kan inte ge ett värde på detta.

Men inte heller den definitionen på ISA är speciellt användbar, de som vill peka på hur bra Apples "Cyclone" CPU gillar denna definition för "IPC" matchar i stort sätt Haswell i t.ex. Geekbench. Dels är Geekbench inte speciellt representativ för prestanda i "vanliga" program, men främst är det riktigt intressanta måttet hur mycket en CPU får uträttat vid sin normala arbetsfrekvens. Haswell går att köra upp till 4.4GHz (i7-4790) medan Cyclone inte alls är designad för höga klockfrekvenser och skulle nog inte kunna passera 2-2.5GHz oavsett hur mycket ström man lät den dra.

Det sagt, den tekniska definitionen av IPC går faktiskt att mäta väldigt exakt på Intels moderna CPUer. CPUn håller reda på massor med statistik, bl.a. hur många cykler den kört, hur många instruktioner som påbörjats, hur många som slutförs (ibland "gissar" CPUn vad som ska hända, när den gissat fel kommer instruktionen påbörjats men aldrig slutförs). Ett värde på genomsnittlig IPC får man då genom att ta

(antal slutförda instruktioner) / (antal köra cykler)

I praktiken ligger detta värde på mellan ~1.0 (vissa tyngre serverlaster med massiva mängder data) till strax över 2.0 (enklare program med "bra" mix av instruktioner och där man kan hålla det mesta i register) i de snabbaste x86-CPUerna. Enklare modeller som Atom, Jaguar och ARM-modeller i telefoner/pekplattor håller sig runt 1.0 och kanske strax över.

Mycket pekar på att den modell som idag används för att designa CPUer inte kan ge en genomsnittlig IPC på mycket högre än 2.0-2.5, finns helt enkelt inte mer saker som är helt oberoende i en enskild instruktionsström. Hyperthreading, eller SMT, är ett sätt att bättre utnyttja den potentiella kraft som finns (Sandy Bridge och senare kan ju köra upp till 5 x86 instruktioner per cykel per kärna).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Datavetare

Konkret exempel på IPC dels på en Sandy Bridge baserad Xeon E5 och dels på en Silvermont baserad Atom maskin. Detta program skapar ett gäng binärträd, jag körde med "20" som argument och då har träden upp till 2^20 = ~1miljon poster. Man gör sedan en enkel beräkning på alla träd man skapat, något som kräver att man springer igenom alla poster vilket är något som sätter rätt mycket stress på cache-systemet i en CPU.

IPC på Sandy Bridge maskinen blev ca 1.4 medan det låg på ca 0.8 för Silvermont. Hastighetsmässigt var därför den förra maskinen (E5-2690) med max turbo 3.8GHz så här mycket snabbare än den senare (C2758)

(1.4 * 3.8) / (0.8 * 2.4) = 2.8 gånger snabbare

Edit: För att ta detta hela vägen. Om man tittar på ett annat exempel, t.ex. detta Python program som en del använder för att benchmarka RPi, RPi2 och Banana Pi. Här blir i stället IPC 1.8 på Sandy Bridge och 1.0 på Silvermont. Blir högre IPC då detta program är "snällare" mot CPU-cachen + saker som använder så kallade "interpreterade språk" eller "skriptspråk" brukar få lite högre IPC då de typiskt kör en rätt tight kärna (interpretatorn) vilket leder till riktigt bra hit-rate i instruktionscachen. För just Sandy Bridge och senare finns en speciell cache (kallas ibland L0-cache) för instruktioner som ligger efter att man brutit upp x86 instruktioner i interna instruktioner. Denna cache är väldigt liten, men små loopar får plats och går då väldigt fort.

Huvudpoängen: olika program har olika IPC även om de körs på samma CPU. Även om IPC-kvoten (relativa prestanda mellan CPU-modeller) i detta fall var ganska lika i de två fallen, så kan den variera rätt kraftigt mellan olika program. En Xeon E5 kommer relativt en Atom/ARM klara tunga serverlaster bättre än den klarar att t.ex. köra enklare spel eller andra lättare uppgifter.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Entusiast
Skrivet av Yoshman:

Ska försöka mig på en lite populärvetenskaplig förklaring, så är en hel del detaljer jag skippar. Få se om det överhuvudtaget lyckas...

IPC står mycket riktigt för "Instructions Per Clock cycle" och "instruktion" i strikt teknisk mening är antal så kallade "maskinkodsinstruktioner" som körs per cykel. Om man tar denna definition av IPC så är ett visst värde här bara något som går att jämföra mellan CPUer som kör samma uppsättning instruktioner. Är här man ser termer som "x86", "ARM", "PowerPC" m.fl, detta är exempel på CPUer som använder olika typer av instruktionsuppsättningar, olika "ISA" (Instruction Set Architecture).

För att förstå varför det inte går att jämföra denna definition av IPC mellan CPUer med olika ISA inte kan jämföras kan man ta ett exempel där det är ganska stor skillnad i hur många maskininstruktioner som behövs. Anta att det finns ett tal i RAM som vi vill addera ett till, på x86 ser detta ut så här om vi antar att positionen talet är lagrat i minnet ligger i CPU-register edi (ett "register" är det snabbaste typ av minne som finns i en CPU, finns ett väldigt begränsat antal register, 8st i 32-bitars x86, 16st i 64-bitars x86 och 32-bitars ARM, 32st på 64-bitars ARM och PowerPC).

Antag också att vi vill göra samma sak på ARM och där säger vi att register r0 innehåller positionen talet är lagrat. Namnen på register är här irrelevant, använder just dessa då det är de register som råkar användas för första argumentet till funktioner på respektive arkitektur. Trots olika namn representerar registren här samma sak, en minnesposition och de är 32-bitar långa.

x86

add DWORD PTR [edi],0x1 ; add one to the number at the location pointed to by edi

ARM

ldr r3, [r0, #0] ; load content pointed to by r0 into r3 adds r3, #1 ; add one to r3 str r3, [r0, #0] ; store content in r3 to the location pointed to by r0

Då ARM är en s.k. RISC-arkitektur kan den bara utföra aritmetik mot register, det som händer här är att man läser upp minnescellen som r0 refererar till till register r3, adderar ett till r3 och sparar sedan ner resultat i minnet igen.

För att göra samma sak på dessa två olika ISA krävs alltså en instruktion i ena fallet men tre i det andra. I genomsnitt är det inte alls så här stor skillnad, ville bara visa hur stor skillnad det kan vara i relativt fundamentala fall.

Som lite extra kuriosa är det så att de flesta moderna CPUer bryter upp maskininstruktionerna i mindre interna instruktioner (även vissa ARM modeller gör detta), så på säg Haswell så blir det väldigt likt ARM varianten internt då man där separerar minnesoperationer och beräkningar. Haswell kan påbörja upp till 4 interna instruktioner för beräkningar och upp till 4 interna instruktioner för minnesoperationer per cykel men den kan maximal köra 5st x86 instruktioner per cykel (är praktiskt möjligt att skriva ett program som faktiskt får IPC på 5 sedan Sandy Bridge, men det gör inget speciellt intressant...).

Så ofta när man säger "IPC" menar man inte den strikt tekniska termen utan mer: ungefär hur mycket kan man förvänta sig att en viss CPU presterar per CPU-tråd och tidsenhet jämfört med andra. D.v.s. man har inget absolutbelopp utan det relaterar mer till antal "instruktioner" i programmeringsspråk som C, Java eller liknade som man kan köra per tidsenhet. Det är ett mycket mer användbart mått, men varierar från program till program och varierar även med storleken, typen och utformningen på data man jobbar med => man kan inte ge ett värde på detta.

Men inte heller den definitionen på ISA är speciellt användbar, de som vill peka på hur bra Apples "Cyclone" CPU gillar denna definition för "IPC" matchar i stort sätt Haswell i t.ex. Geekbench. Dels är Geekbench inte speciellt representativ för prestanda i "vanliga" program, men främst är det riktigt intressanta måttet hur mycket en CPU får uträttat vid sin normala arbetsfrekvens. Haswell går att köra upp till 4.4GHz (i7-4790) medan Cyclone inte alls är designad för höga klockfrekvenser och skulle nog inte kunna passera 2-2.5GHz oavsett hur mycket ström man lät den dra.

Det sagt, den tekniska definitionen av IPC går faktiskt att mäta väldigt exakt på Intels moderna CPUer. CPUn håller reda på massor med statistik, bl.a. hur många cykler den kört, hur många instruktioner som påbörjats, hur många som slutförs (ibland "gissar" CPUn vad som ska hända, när den gissat fel kommer instruktionen påbörjats men aldrig slutförs). Ett värde på genomsnittlig IPC får man då genom att ta

(antal slutförda instruktioner) / (antal köra cykler)

I praktiken ligger detta värde på mellan ~1.0 (vissa tyngre serverlaster med massiva mängder data) till strax över 2.0 (enklare program med "bra" mix av instruktioner och där man kan hålla det mesta i register) i de snabbaste x86-CPUerna. Enklare modeller som Atom, Jaguar och ARM-modeller i telefoner/pekplattor håller sig runt 1.0 och kanske strax över.

Mycket pekar på att den modell som idag används för att designa CPUer inte kan ge en genomsnittlig IPC på mycket högre än 2.0-2.5, finns helt enkelt inte mer saker som är helt oberoende i en enskild instruktionsström. Hyperthreading, eller SMT, är ett sätt att bättre utnyttja den potentiella kraft som finns (Sandy Bridge och senare kan ju köra upp till 5 x86 instruktioner per cykel per kärna).

Dold text

Man tackar så mycket för informationen och att du tog dig tiden till att skriva ner den!
Kanske inte förstod allting men över lag fick jag en mycket bättre bild än innan över hur det står till.

Du borde nästan ha en ruta där det står "Sätt in en 10-krona för kvalitets-info" i signaturen...

Visa signatur

Den digitala högborgen: [Fractal Design Meshify C] ≈ [Corsair RM850x] ≈ [GeForce RTX 3080] ≈ [AMD Ryzen 7 7800X3D ≈ [Noctua NH-U14S] ≈ [G.Skill Flare X5 32GB@6GHz/CL30] ≈ [MSI MAG B650 TOMAHAWK] ≈ [Kingston Fury Renegade 2 TB] ≈

Permalänk
Entusiast
Skrivet av anon159643:

Trimma TDP är intressant, just detta kan man väl inte göra innan? Man kan ändra frekvensen och volten som påverkar TDP, men man kan inte direkt styra TDP.

Angående namngivningen i7, i5 och i3 så borde Intel byta namn på dem till slow, slower and slowest så förstår kunderna bättre vad de köper för produkt. Jag tycker märkningen med processorer tack varje att man har tillgång till internet överallt inte är så stor problem, men visst borde diverse testresultat stå vilken en seriös butik kan ta med.

De har haft ställbart TDP i modeller designade för strömsnåla modeller tidigare. Intel introducerade vad de kallar för cTDP med Ivy Bridge men det var som sagt mest för laptopar och liknande.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Medlem
Skrivet av Helllodar:

4k Blu-Ray är ett måste om DVD försäljning ska fortsätta, har för mig det kommer i sommar.

Gällande playback så har jag alltid föredragit software decoding över hardware acceleration.

i3-4360 ligger vid ca 40% belastning med software (ca 40GB film, inget komprimerat).

Min 4770k klarar inte 4k hevc utan frame drops när man börjar komma upp i hyfsad bitrate. Men iof är kabske inte decodern så optimerad än.

Vad är problemet med hårdvaruavkodning? Finns väl ingen anledning att köra utan det. Vad kör du för mediaspelare förresten? Nu för tiden lär man väl nästan aktivt välja bort hårdvaruavkodning för avc, är ju standard i nästan allt nu. Man kan ju fortfarande köra deinterlace och uppskalning etc med mjukvara om man nu vill ha bättre bild.

Tvivlar starkt på att vi ser 4k Blu-Ray till sommaren, är alldeles för tyst på den fronten för att det ska vara så nära.

Edit. De spikade tydligen standarden i februari, så runt jul 2015 väntas 4k Blu-Ray att komma.

Skickades från m.sweclockers.com