Intel och AMD dröjer med nya processorer till januari 2017

Det jag tror många egentligen undrar över är vad det är för information som pekar på lansering av zen i januari. Den frågan är väl inte riktigt besvarad.

@Yoshman:

AMD var väl rätt snabba med lansering av Carrizo? Jag minns den där reklamfilmen med Skotten som sa chippen validerades medan han gjorde reklamfilmen och sedan dröjde det väl bara några par månader (<6 mån?) innan det släpptes.

Men visst AMD skyndar sig kanske mer med Laptopchip än med desktop måhända.

Mycket snack om Zen men det är ju egentligen AM4 som är första milstolpen i detta. Förhoppningsvis stämmer det du säger att tillverkare har får tag i AM4 brädor nu i sommar om inte tidigare.

Bristol Ridge för desktop borde ju börja kunna tillverkas rätt så snart. Har svårt att tro att det kommer vara några tillverkningsproblem i och med att det är 28nm. Men visst hela plattformen måste kanske valideras med Zen innan det kan säljas så det kan ju vara Zen som stannar upp lanseringen av AM4 om de har mycket kvar att validera.

Det kan jag hålla med till 100 % om.

Av alla som publicerade detta rykte var det någon som spekulerade i att AMD nog vill ha en större händelse som arena för sin Zen-lansering för att maximera genomslaget. Många kanske tycker det verkar galet att missa julhandeln, men realistiskt sett kommer det knappast finnas några kretsar att köpa under första tiden ändå. Intel har ju inte heller kunnat möta efterfrågan på kretsar som i7-6700K under rätt lång tid efter lansering och där har man ändå långt mer kontroll över prioritering i tillverkningsprocessen.

Det som ska vara med i julhandel måste i praktiken lanseras i Q3. Så kanske samma sak med Kaby Lake, man väljer CES som för lansering av efterföljaren till i7-6700K av PR-hänsyn. Gissar att man ändå lanserar Core M och eventuellt U-serien (15 W TDP dual core) modeller i Q3.

Är ju faktiskt så att den enda ökning som nu sker av x86 CPUer för konsumentbruk är de mest högpresterande modellerna som är lämpliga i t.ex. spelmaskiner. Av allt att döma så har den nischen fått väldigt mycket högre prioritet hos Intel, två indikationer på detta är utökningen av E-serien i antal modeller samt att man initialt endast lanserade i5-6600K och i7-6700K för desktop Skylake.

Validering är ju bara en sak som ska göras från att man har kretsar som trots allt kan boota ett system och köra program. Och är ju många saker som ska valideras, själv tänkte jag främst på själva CPUn här men du pekar ju på en annan kritiskt punkt där t.ex. moderkortstillverkare måste validera sina produkter med en CPU som är tillräckligt färdig för att man kan utesluta den som felkälla.

Validering är också väldigt svårt på en modern CPU, något vi fått bevittna flera gånger. Ett exempel är problemet med Skylake i Super Pi (var det va?), det gick ändå att patcha med mikrokod utan noterbar negativ effekt. Är man med i program där man kör på pre-produktions-versioner av kretsar händer det absolut att man stöter på problem, i vissa fall så grava att tillverkaren skickar ut en ny batch men oftast går det att göra tillfälliga work-arounds.

AMD har aldrig specificerat någon tidsperiod, men de har varit ganska tydliga ända sedan Financial Analyst Day förra året att det är 2016 som gäller.
http://www.sweclockers.com/nyhet/20451-amd-presenterar-fx-ser...

Jag hittar inte nyheten nu, men jag är ganska säker på att jag läst vid samma tid då att AMD omprioriterat sina resurser och skjutit på sin ARM-design K12 för att istället lansera Zen tidigare, och då innan 2016 slutar istället för början-mitten av 2017 som ursprungligen tänkt.

@Yoshman:

Ja frågan för mig personligen är när AM4 släpps. Zen är kul och så men då det bara bli CPU i början så kör jag på Bristol Ridge.

AMD har väl gjort liknande innan. Släppt ny plattform då CPUn egentligen var väldigt snarlik. Jag tänker på AM2 specifikt som egentiligen bara skillde i minneskontroller och annat smått och gott om jag minns rätt.

Men det kan hända att de kanske måste testa klart Zen innan de kan släppa AM4.

OS- och applikations-leverantörerna kan i väldigt många fall inte heller ordna så att fler kärnor används på ett vettigt sätt. Många problem som man stöter på i skrivbordsapplikationer är vad man kallar "inherently sequential" och sådana problem kan inte utnyttja flera kärnor på något vettig sätt oavsett hur hårt man försöker.

Analyserar man algoritmer i detalj kan det ändå finnas delar som rent teoretiskt kan köras parallellt. Problemet är att det finns en visst kostnad, viss kommunikationslatens, i att fördela ett problem över flera CPU-kärnor. Det som ofta är fallet i lägen när problemet som helhet har en slutgiltig utdata men det finns delar som internt kan köras parallellt är att tiden att slutföra varje separat del hamnar allt för nära tiden motsvarande kommunikationslatensen. I det läget kommer det inte gå fortare att använda flera kärnor, i vissa fall blir det faktiskt rejält mycket långsammare och ovanpå använder man nu CPU-resurser som en oberoende uppgift faktiskt skulle kunna använda på ett bra sätt.

I princip kan man säga att alla saker där totala tiden från start till leverans av resultat börjar krypa ner mot enskilda millisekunder (ändå rätt lång tid för en CPU, vid 4 GHz har man 4 miljoner klockcykler per millisekund och Skylake kan köra upp till fem instruktioner per cykel) så ska man hålla saker på en CPU-kärna.

I servermaskinvara där man vill hantera hundratusentals anrop per CPU-kärna och sekund fungerar det inte att ha en CPU-kärna som fördelar jobbet, en sådan lösning blir långsammare än att köra enkeltrådat. Vad man i praktiken gör är att klassificera inkommande anrop redan i den I/O-enhet som tar emot anropet och resultatet av klassificeringen avgör sedan vilken CPU-kärna man skickar avbrottet till (interrupt) och den tar också hand om all hantering. Motsvarande är i praktiken omöjligt att få till på skrivbordet då man ytterst sällan har tusentals, sinsemellan oberoende, anrop att jobba med.

Intel använder inte AMD64, de kör med Intel64 som för applikationer i praktiken är helt kompatibel med AMD64 men OS-kärnor måste i några fall hantera AMD64 och Intel64 lite olika.

Sedan var inte Intel för sen med sin egen 64-bitars teknik, IA64, den kom faktiskt flera år innan AMD64. Problemet var i stället att IA64 helt enkelt var baserad på en dålig teknik. Grunddesignen i IA64 är väldigt lik VLIW-tekniken som AMD använde fram till 6000-serien.

Fördelen med VLIW är att man kan göra kretsen lite enklare för en viss teoretisk beräkningsprestanda då man kan göra viss parallellisering av instruktioner redan vid kompileringstillfället (något som görs en gång när man skapar programmet). En modern skalär CPU/GPU-design får lägga rätt mycket transistorer på att dynamiskt hitta instruktioner som är oberoende av varandra och därför kan köras parallellt.

Nackdelen med VLIW är att tekniken i praktiken bara fungerar väl inom vissa områden. IA64 används fortfarande en del i superdatorer för tekniken passar långa beräkningar som har relativt liten andel villkorad körning. Av samma anledning passar VLIW väldigt bra till rena grafikberäkningar.

Problemet i en CPU är att det område där VLIW fungerar bra är ett undantagsfall, det normala är väldigt hög andel villkorad körning och som lök på laxen tenderar man ha stor varians i latens för minnesoperationer och med VLIW blir latensen alltid latensen för den operation som tar längst tid. I GPUer såg man problem med VLIW för GPGPU då hela tanken med detta var att göra mer generella uppgifter på GPUn.

Grundtanken är just att kompilatorn kan göra mer av jobbet, den kan även hitta instruktioner som är oberoende och lägga dessa i samma instruktionsord (IA64 hade tre instruktioner per ord, VLIW5 och VLIW4 hade 5 respektive 4 instruktioner per ord). Så långt är allt frid och fröjd, detta är en fördel!

Problemen hopar sig när frekvensen av hopp är högre än antal instruktioner per instruktionsord, då minskar effektiviteten. T.ex. en kompilator är exempel på kod som tenderar ha extremt hög andel villkorade hopp så passar denna modell illa.

Det andra problemet är som sagt när man har flera instruktioner vars data kanske måste laddas från RAM eller högre nivå cache. Instruktionsordet kan inte köra klar innan alla instruktioner har fått sitt data, load-to-use latensen blir därmed den högsta av de ingående instruktioner. En väldigt stor del av varför Intels CPU-designer presterar så bra är att man under lång tid haft väsentligt lägre load-to-use latens än konkurrenterna, så detta är kritiskt. Också för Apples CPU-designer verkar just cache med väldigt låg latens vara den stora magiska ingrediensen, överlag har ARM-designerna haft rätt dåliga cache designer.

VLIW är som en amerikans sportbil, den är väldigt kraftfull och snabb. I alla fall så länge du bara tänker åka rakt fram

Det du frågar efter finns faktiskt i Windows 10 förutsatt att du har en Broadwell baserad E-serie. Tekniken kallas Intel® Turbo Boost Max Technology 3.0 (förbehåller mig rätten att förkorta detta som TBM).

I korthet är ju E-serien modeller med relativt många kärnor, fast med lite lägre prestanda per kärna än de snabbaste två och fyrkärniga Skylake modellerna. Tricket med TBM är att notera lägen där övriga kärnor inte behövs men man har någon applikation, extra prioritet ges till den med input-focus, som behöver all enkeltrådprestanda man kan kräma ur. i det läget kommer TBM "överklocka" en enda kärna.

Specifikt för i7-6950X som normalt har max turbo på 3,5 GHz kan man nå 4,0 GHz med TBM på en kärna och drivaren för TBM ser till att den prioriterade applikation får ensamrätt till den högt klockade kärnan.

Ska bli intressant att se hur pass väl detta fungerar i praktiken.

Fast de nämner att det bara är ett rykte, för de som orkar läsa mer än rubriken.
För övrigt håller jag med, känns väldigt otroligt.

Sablans, jag såg fram emot att bygga en passivt kyld Kaby Lake HTPC runt jul ju, just GPU-biten i Kaby Lake gör den perfekt för HTPC :/

Visst finns det ett par situationer en FX-prolle skulle vara en fördel mot I5 k-modell men de är extremt få och skillnaden minimal vad jag kan se. Visst du kanske lite mer prestanda per krona i de få situationerna men vi pratar om några hundralappar.I alla andra situationer blir det plus minus noll, mer mot minus i spel.
För i princip alla som har en "speldator" är en i5 k-modell bättre än en Fx8350.

Hoppas Zen lyckas men jag har inga höga förhoppningar.

AMD borde ta sig i kragen och släppa sin Zen... bättre att släppa innan Intel släpper nytt.
Antar att det strular med tillverkningen annars har AMD inte riktigt tänkt över hur mycket efter dom ligger.

Läs vad jag skrev och läs sedan din egen länk

"There are Intel- and AMD specific extensions to the instruction set, but as long as you're writing programs in user space, you don't generally need to know the difference."

Vanliga applikationer behöver inte tänka på skillnaden mellan AMD64 och Intel64. De som skriver OS-kärnor, d.v.s. kod som kör i kernel-space i stället för user-space, har några enstaka fall där dessa två skiljer sig åt.