Rykte: Intel Ocean Cove är namnet på nästa generations processorarkitektur

Trädvy Permalänk
Inhibitor
Registrerad
Dec 1999

Rykte: Intel Ocean Cove är namnet på nästa generations processorarkitektur

En ny jobbannons på Intels webbplats avslöjar vad som tros vara namnet på nästa generations Core-arkitektur, vilken ska ligga till grund för produkter under en lång tid framöver.

Läs hela artikeln här

Observera att samma trivselregler gäller i kommentarstrådarna som i övriga forumet och att brott mot dessa leder till avstängning. Kontakta redaktionen om du vill uppmärksamma fel i artikeln eller framföra andra synpunkter.

Trädvy Permalänk
Medlem
Plats
gbg
Registrerad
Nov 2007

Trodde först att det var detta jobb de ämnade ha Jim Keller för... men det kanske var GPU eller styrkrets som blev hans lott?

Tower: ace Battle IV | CPU AMD Phenom II X2 BE unlocked 4cores@3,2GHz | RAM 8GB DDR2@800MHz | MB ASUS M4A785-M | GFK AMD Radeon HD 6850 1GB | HDD Kingston SSD Now 60GB (/) Seagate 2TB(/home) | OS Ubuntu 16.04 LTS

Trädvy Permalänk
Medlem
Plats
Jönköping
Registrerad
Feb 2011

Spännande Core har ju snarare evolutionerats än revolutionerats på sistonne så det är väl dags för något helt nytt kanske.

Första inlägget i en tråd är sällan relevant när tid har förflutit. Vänligen svara på mitt senaste inlägg i tråden, inte det första, annars blir det kass. http://ozzed.net Min egenkomponerade 8-bit musik. Gillar du musiken från gamla klassiska NES eller Gameboy och liknande är det värt ett besök. :) Jag finns också på Spotify, Bandcamp, Jamendo, Youtube, och du kan även följa mig på Twitter och Facebook.

Trädvy Permalänk
Medlem
Plats
Linköping
Registrerad
Okt 2011

Intel Cove i5?

Jag hittar ut själv...

Trädvy Permalänk
Medlem
Plats
Tullinge
Registrerad
Jun 2005

Intel kan inte mjölka gamla produkter längre om de ska hänga med AMD's aggressiva frammarsh. Intel har på en del plan ett försprång men inser att de måste kavla upp ärmarna då deras gamla rival är tillbaka på banan.

Saknat när teknik rivaler slåss om oss konsumenter istället för att mjölka oss 😊

Får hoppas amd släpper nått så nvidia får lite eld i baken dom med.

Skickades från m.sweclockers.com

Ryzen 1700 @ 3.86ghz, Palit GTX 1080 GR Premium

Trädvy Permalänk
Medlem
Registrerad
Nov 2011

När jag läste att Jim Keller skulle över till Intel så tänkte jag direkt att de skulle börja med en ersättare till P6-derivaten. Hans specialitet är ju lite att bygga saker från grunden. Och Intels P6 och dess derivat har ju funnits på marknaden i 23 år nu.
Ser det inte som ett sammanträffande att denna nyheten kommer nu.

Trädvy Permalänk
Medlem
Plats
Arvika/Thn/localhost
Registrerad
Jul 2001

Gillar inte när SweC postar ut Rykte artiklar där det framförallt är svammel. Lite väl rörig artikel.

Trädvy Permalänk
Medlem
Plats
Karlstad
Registrerad
Nov 2010

Det känns som att det börjar bli dags att byta ut namnen i3,i5,i7 etc. Detta av flera anledningar, men främst att de första är från 2008. Och det känns bra med ett nytt namn som särskiljer de nya från de gamla, så att man direkt kan skilja agnet från vetet.

Gått över till enbart Google Chromebook på klientsidan.

Trädvy Permalänk
Medlem
Plats
Huddinge/Stockholm
Registrerad
Jan 2015
Skrivet av Johan86c:

Det känns som att det börjar bli dags att byta ut namnen i3,i5,i7 etc. Detta av flera anledningar, men främst att de första är från 2008. Och det känns bra med ett nytt namn som särskiljer de nya från de gamla, så att man direkt kan skilja agnet från vetet.

Tycker de kan byta namn när något revolutionerande händer. Inte så mycket som hänt de senaste tio åren. Mellan varje generation alltså.

OnT: Detta låter spännande

Skickades från m.sweclockers.com

Dator 1: | i7 7700k | MSI GTX 1080 Gaming X | MSI Z270 Gaming pro carbon | Corsair LPX DDR4 16 GB | FD define S | Samsung 850 EVO 1TB | Noctua NH-U12S | Corsair RM750x 750W | Windows 10
Skärm 1: ASUS 27" ROG SWIFT PG279Q 1440p @ 165Hz/IPS/G-Sync

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Aleshi:

När jag läste att Jim Keller skulle över till Intel så tänkte jag direkt att de skulle börja med en ersättare till P6-derivaten. Hans specialitet är ju lite att bygga saker från grunden. Och Intels P6 och dess derivat har ju funnits på marknaden i 23 år nu.
Ser det inte som ett sammanträffande att denna nyheten kommer nu.

Dagens Core må ha en blodslinje (fast kanske är kisellinje för kretsar?) tillbaka till PentiumPro, men de en PPro och Skylake har väldigt lite gemensamt...

Och varför behöver denna design ersättas? Så vitt jag känner till är det fortfarande bara Apple som har en design med bättre IPC, men den kan än så länge inte klockas i närheten lika högt.

Går det att göra en bättre x86 design än vad vi har i dag? Självklart!
Är dock rätt övertygad om att vad man än gör kommer det inte bli någon större skillnad, att Apple kunna gå förbi är väldigt mycket en konsekvens av att man kan utgå från en ISA som är långt bättre lämpad för dagens krav jämfört med x86.

Men man ska inte överdriva vikten av ISA heller, en rimlig ansats är att en "perfekt ISA" (vilket Aarch64 och även RISC-V kommer väldigt nära att var) kanske ger upp mot 20-30 % bättre IPC allt annat lika.

Vad vi så här långt utnyttjat extremt dåligt i mainstream-programvara är SIMD. Inte speciellt förvånande med tanke på att inget av de stora programmeringsspråket haft något inbyggt stöd för detta tidigare, C++17 blev först med detta. Här finns en latent potential på 2-16 gånger högre prestanda inom de områden där SIMD är användbart, det i existerande CPUer!

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

Trädvy Permalänk
Medlem
Plats
Gislaved
Registrerad
Jan 2003

Gäller att vara ute i tid.

Vad kan det ta fram till första produkt till konsument om de börjar fila på nått nytt nu? 5 år? Mer?

En del av mina bildlänkar hostas på egen maskin, är bildlänkarna trasiga, ha tålamod.

Trädvy Permalänk
Medlem
Plats
Gävle
Registrerad
Feb 2004
Skrivet av Karaff:

Gäller att vara ute i tid.

Vad kan det ta fram till första produkt till konsument om de börjar fila på nått nytt nu? 5 år? Mer?

Dom har nog filat på det ett bra tag redan. Vilken tid det tar från start till färdig produkt är omöjligt att säga då så mycket bygger på gammal teknik.

Spectre fixen i Ice lake är nog ett bra mått på hur lång tid det tar att få ut en ny ide till en färdig produkt.

Trädvy Permalänk
Medlem
Registrerad
Nov 2011
Skrivet av Yoshman:

Dagens Core må ha en blodslinje (fast kanske är kisellinje för kretsar?) tillbaka till PentiumPro, men de en PPro och Skylake har väldigt lite gemensamt...

Och varför behöver denna design ersättas? Så vitt jag känner till är det fortfarande bara Apple som har en design med bättre IPC, men den kan än så länge inte klockas i närheten lika högt.

Går det att göra en bättre x86 design än vad vi har i dag? Självklart!
Är dock rätt övertygad om att vad man än gör kommer det inte bli någon större skillnad, att Apple kunna gå förbi är väldigt mycket en konsekvens av att man kan utgå från en ISA som är långt bättre lämpad för dagens krav jämfört med x86.

Men man ska inte överdriva vikten av ISA heller, en rimlig ansats är att en "perfekt ISA" (vilket Aarch64 och även RISC-V kommer väldigt nära att var) kanske ger upp mot 20-30 % bättre IPC allt annat lika.

Vad vi så här långt utnyttjat extremt dåligt i mainstream-programvara är SIMD. Inte speciellt förvånande med tanke på att inget av de stora programmeringsspråket haft något inbyggt stöd för detta tidigare, C++17 blev först med detta. Här finns en latent potential på 2-16 gånger högre prestanda inom de områden där SIMD är användbart, det i existerande CPUer!

Du argumenterar en massa som om jag förespråkar en ny arkitektur. Jag bara konstaterar att dessa två saker sammanfaller. Och jag vet att de är väldigt olika idag. De har ju trots allt gjort förbättringar rätt många gånger och vid ett par tillfällen rätt ordentliga sådana. Men det betyder inte att de inte kan se fördelar med att börja om från grunden någon gång.

Trädvy Permalänk
Medlem
Plats
Huddinge
Registrerad
Mar 2012

Intel "Ocean Cove"... Intel "OC"...

how creative...

Trädvy Permalänk
Medlem
Plats
Hudiksvall
Registrerad
Maj 2002
Skrivet av krigelkorren:

Trodde först att det var detta jobb de ämnade ha Jim Keller för... men det kanske var GPU eller styrkrets som blev hans lott?

Gissningsvis har dom anställt Keller för en ny satsning på SoC/Ultra low-power segmentet (rip atom), om jag minns rätt så anställde AMD Keller främst för att jobba på K12 (ARM baserad server processor) och inte Zen, K12 kom dock aldrig till marknaden. Keller har trots allt jobbat med ARM projekt hos Apple.

Trädvy Permalänk
Avstängd
Registrerad
Sep 2017
Skrivet av krigelkorren:

Trodde först att det var detta jobb de ämnade ha Jim Keller för... men det kanske var GPU eller styrkrets som blev hans lott?

Trodde jag med! Kanske nöp de honom innan annonsen gick i tryck?

Skickades från m.sweclockers.com

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Aleshi:

Du argumenterar en massa som om jag förespråkar en ny arkitektur. Jag bara konstaterar att dessa två saker sammanfaller. Och jag vet att de är väldigt olika idag. De har ju trots allt gjort förbättringar rätt många gånger och vid ett par tillfällen rätt ordentliga sådana. Men det betyder inte att de inte kan se fördelar med att börja om från grunden någon gång.

Fast vad skulle vinsten att starta om från början vara?

Var lite det jag försökte belysa, Zen var till stor del en "clean sheet design". Den matchar Intel i flyttal men faller efter i heltalsberäkningar (vilket är vad spel, webbläsare, de flesta server program, MS Office, kompilering, m.m. nästan uteslutande använder) och är långt efter i SIMD.

Intel hävdar att de övervägt en omstart, men när de tittar närmare på det finns det inget som pekar på att man skulle få en speciellt mycket bättre design av det.

Pekade på ARM då det trots allt finns någon där som passerat Intel i IPC (i heltal, det är överlägset viktigast då det används i alla program, flyttal är en nisch och SIMD är en något mindre nisch än flyttal men ändå en nisch). Helt övertygad att enda anledningen att Apple har ett litet övertag i flera heltalsfall långt mer kommer från att ha en mycket bättre ISA än något annat.

D.v.s Core må vara en gammal design, men den verkar vara väldigt nära perfektion för x86!

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

Trädvy Permalänk
Medlem
Registrerad
Aug 2017

På tiden

Moores lag säger att man ökar antalet transistorer med 100% vartannat år. Det är vanligt att man likställer det med att prestandan fördubblas vartannat år, eftersom man fördubblar antalet transistorer vartannat år. Per år blir det 40% fler transistorer varje år. Det skulle motsvara 40% bättre prestanda per år. Det är väl nästan den takt som GPUerna förbättrar sin prestanda?

Då kan vi jämföra 40% bättre prestanda per år, mot Intels resultat. I genomsnitt har Intel ökat prestandan ca 3% per år. Det är... inte så bra. Det blir förvånande när folk anser att Intel gör bra cpuer. Somliga anser faktiskt att Intel gör _världens_ snabbaste och bästa cpuer. Ja, det finns sådana människor på riktigt, som anser att 3% bättre prestanda per år är bäst i världen. Att Intels cpuer är snabbast i världen (de struntar i alla benchmarks som bevisar motsatsen).

Detta bevisar att Intel torde ha världens sämsta cpu arkitektur, eftersom trots att Intel får 40% fler transistorer per år, så får Intel endast ut 3% bättre prestanda. 40% kommer in och 3% kommer ut.

När folk säger att Intel är bäst i världen på cpuer, så menar de faktiskt att Intel har världens bästa processnoder. Där är det inget snack, Intel är världsledande. De är snart nere på 7nm, före alla andra. Så Intel får alla sina cpu förbättringar genom krympningar, dvs Intels processingenjörer är världsbäst. Intels cpu arkitekter är sämst i världen. Eftersom processnoden är så bra, och cpu arkitekterna dåliga, så blir Intels cpuer ändå hyfsade. Slutresultatet blir ca 5% bättre prestanda per generation. Det är ju hyfsat. Eller? Nja. Kolla på andra cpu familjer, de får mycket bättre än 5% per generation, upp till 100%.

Många av de prestanda förbättringar som Intel gör, kommer från deras överlägsna processnod förbättringar. Det är därför Intel är så lätta att överklocka, och AMD är svåra. Intel släpper alltså en ny cpu som är 5% snabbare än den föregående. Men denna "enorma" prestandavinst beror endast på att Intel höjt med 200MHz, och inte på egentliga arktiekturförbättringar. Så Intel är beroende av att de kan höja med 200 MHz varje generation för att visa snabbare prestanda. Intel skulle kunna höja 1-2 GHz direkt och då slå i taket, men då skulle Intels nya kommande cpu inte kunna höjas 200MHz, så den skulle inte vara snabbare. AMDs cpuer har ju slagit i taket när de kommer ut från fabrik och kan knappt höjas 200MHz. Intel vet att de börjar närmar sig taket, och att det är hög tid att Intel börjar om på ny kula med ny arktitektur. Intel kan inte alltid höja 200MHz mycket oftare. De måste börja på nytt nu. Då skulle Intel kunna sänka till 2-3GHz med bibehållen hög prestanda, och sen höja 200MHz för varje ny cpu. Nu får Intel alla sina prestandaförbättringar genom att höja GHz. Det håller inte. Intel är i en återvändsgränd.

Problemet som Intels processingenjörer har, är att det tar längre och längre tid att krympa. Förrut kunde Intel alltid vara ett steg snabbare, men idag tar det så lång tid. Intel kommer att ligga på 7nm under flera år, under tiden hinner konkurrenterna ikapp. De har flera år på sig att gå ned till 7nm och Intel är fortfarande kvar där. Förrut krympte Intel snabbt, och konkurrenterna hann inte med. Idag hinner alla med. Intel måste byta strategi, de kan inte längre vinna genom att krympa hela tiden. I framtiden kanske man ligger kvar på 3nm under tio år - då ligger alla på 3nm och Intel har tappat sitt process försprång. Då måste Intel försöka förbättra sin arktiketkur istället.

Det är alltså hög tid att Intel skrotar sin antika Core arkitektur och designar något helt nytt. Precis som AMD gjort. När man kört fast i en återvändsgränd, så går det inte att förbättra kraftigt, man är fast med små inkrementella förbättringar. Det är de symptom vi ser hos Intel; 5% bättre per år. Dvs, återvändsgränd. Intel är väl inne på sin 8e generation Core nu? De mjölkar sina kunder på samma gamla skåpmat. Inget nytt och bättre. Det var exakt samma som AMD visade med Bulldozer, det blev bara små förbättringar för varje ny cpu dvs återvändsgränd. När AMD gjorde Ryzen så blev det ett stort skutt i prestanda, eftersom de började på ny kula. Det är exakt det som Intel behöver göra för att återta ledningen. Börja om på ny kula. Det inser t.om. Intel, och det är därför de gör en ny arktitektur. Vem f-n är nöjd med 5% per generation? Jo, bara fanboys. Ingen vettig människa är nöjd med det.

Fast nu har Intel höjt prestanda ordentligt ibland, med typ 20% eller så. Hur gick det till? Jo, Intels nya cpu har 20% fler kärnor. Räkna bort kärnorna, så ser du att det i praktiekn är 3% högre prestanda. Precis samma gamla visa.

Och talet om att "hög IPC är viktigt", är lika begåvat som att prata om att "hög GHz är viktigt". Det är bara någon som inte förstått parallell algoritmteori som kan tro det. En som förstått algoritmteori vet att många arbetslaster inte går att parallellisera, och därför spelar det ingen roll hur många kärnor man använder. Man kan inte köra koden snabbare ändå. Omvänt så betyder det att en viss typ av arbetslast bara har en viss max-IPC, och det går inte att få ut mer IPC än vad som är typiskt för det arbetet. T.ex. många server arbetslaster har en max IPC på 0.8 (därför att koden grenar sig mycket). Så det spelar ingen roll om en x86 har extremt hög IPC, och en annan cpu har låg IPC - x86 kommer inte ha en fördel i praktiken, så benchmarksen kan vara sämre (vilket de är, eftersom x86 inte är designade för servers).
https://www.anandtech.com/show/10435/assessing-ibms-power8-pa...
"ie. If you superficially look at what kind of parallelism can be found in software, it starts to look like a suicidal move. Indeed on average, most modern CPU compute on average 2 instructions per clockcycle when running spam filtering (perlbench), video encoding (h264.ref) and protein sequence analyses (hmmer). Those are the SPEC CPU2006 integer benchmarks with the highest Instruction Per Clockcycle (IPC) rate. Server workloads are much worse: IPC of 0.8 and less are not an exception. It is clear that simply widening a design will not bring good results"

Men det finns väl antagligen folk som än idag tror att en cpu på 4GHz måste vara snabbare än en cpu på 3GHz. AMD hade ju länge mycket lägre klockade cpuer än Intels Prescott cpuer, men AMD var snabbare. Så GHz har inte så mycket med prestandan att göra. På samma sätt har IPC inte så mycket med prestandan att göra. Det är lika smart att tro att max hastighet är viktigt på en bil för att åka snabbt i staden. Men det är dumt att betala dyra pengar för en bil med hög maxhastighet på 400km/h när du ändå inte kan köra snabbare än 100km/h i staden. Då är det klyftigare att köpa en bil med snabb acceleration, och inte hög max hastighet. På samma sätt är vissa typer av programkod begränsade och har en max IPC. Om du t.ex. bara kör serverlaster med 0.8 IPC, varför välja en cpu som har IPC på 3? Vad har gaming laster för IPC? Man kanske inte behöver högre IPC än så.

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2007
Skrivet av Lalle-:

Intel Cove i5?

Jag hittar ut själv...

Intel Covefefe.....Lake?

Spel: Ryzen 7 1800x, R9 270, 16GB DDR4 Flare X
Har haft dessa GPUer: Tseng ET6000, Matrox M3D, 3DFX Voodoo 1-3, nVidia Riva 128, TNT, TNT2, Geforce 256 SDR+DDR, Geforce 2mx, 3, GT 8600m, GTX460 SLI, GTX580, GTX670 SLI, 1080 ti AMD Radeon 9200, 4850 CF, 6950@70, 6870 CF, 7850 CF, R9 390, Vega 64
Lista beg. priser GPUer ESD for dummies

Trädvy Permalänk
Medlem
Plats
Gävle
Registrerad
Jan 2011

@MikaelSwahn
Så mycket text, så många förenklingar, så många fel. Jag vet inte ens vart jag ska börja.. @Yoshman , hjälp mig.

Skickades från m.sweclockers.com

Mobo MSI Z97 Gaming 5 CPU Intel i7 4790k: 4,6 Ghz @ 1,27v RAM Corsair Vengange Pro 16GB @ 2400MHZ
GPU MSI GTX 1080 ti Gaming X Skärm Acer X34A

Trädvy Permalänk
Medlem
Registrerad
Jul 2015

Intel gaping hole?

"Oh glorious cheeseburger… we bow to thee. The secrets of the universe are between the buns..."
"All my farts come straight from hell, you're already dead if you notice a smell"

Trädvy Permalänk
Medlem
Registrerad
Nov 2011
Skrivet av Yoshman:

Fast vad skulle vinsten att starta om från början vara?

Var lite det jag försökte belysa, Zen var till stor del en "clean sheet design". Den matchar Intel i flyttal men faller efter i heltalsberäkningar (vilket är vad spel, webbläsare, de flesta server program, MS Office, kompilering, m.m. nästan uteslutande använder) och är långt efter i SIMD.

Intel hävdar att de övervägt en omstart, men när de tittar närmare på det finns det inget som pekar på att man skulle få en speciellt mycket bättre design av det.

Pekade på ARM då det trots allt finns någon där som passerat Intel i IPC (i heltal, det är överlägset viktigast då det används i alla program, flyttal är en nisch och SIMD är en något mindre nisch än flyttal men ändå en nisch). Helt övertygad att enda anledningen att Apple har ett litet övertag i flera heltalsfall långt mer kommer från att ha en mycket bättre ISA än något annat.

D.v.s Core må vara en gammal design, men den verkar vara väldigt nära perfektion för x86!

Jag finner det inte omöjligt att Intel med sitt team av ingenjörer kan göra något strået vassare än det de har om de börjar om från början. Om jag får gissa lite så finner jag det inte orimligt att de identifierat en del svagheter som kräver rätt ordentlig omkonstruktion även fast jag kan för lite för att peka ut någon. Med tanke på hur begränsade resurser AMD har och att Intel högst troligen fortfarande har en signifikant fördel på tillverkningsprocessen så lyckades AMD rätt bra med Zen.

Men men, vi får se. Jag tycker bara att det verkar som att Intel tänker ta fram något som är nytt lite mer från grunden än det de brukar ta fram.

Trädvy Permalänk
Medlem
Registrerad
Apr 2012

Core2duo kändes jävligt snabb när den kom. Gick ju att överklocka vua fsb som fan med!
Vore kul om cores ersättare blir ett lika stort kliv.

"Whether you think you can or you can't, you're right!"

I7 4790K @ 4,8ghz, Corsair 110i GT, Titan X Maxwell, 32 Gb 1600 Mhz RAM, 2 st 256 SSD i RAID0 för spel, 512 gb SSD systemdisk., Tascam US-2000 ljudkort. Skärm: Philips BDM4065UC 40" 4k.

+ Massa andra datorer i varje hörn av huset.

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av Yoshman:

Dagens Core må ha en blodslinje (fast kanske är kisellinje för kretsar?) tillbaka till PentiumPro, men de en PPro och Skylake har väldigt lite gemensamt...

Och varför behöver denna design ersättas? Så vitt jag känner till är det fortfarande bara Apple som har en design med bättre IPC, men den kan än så länge inte klockas i närheten lika högt.

Går det att göra en bättre x86 design än vad vi har i dag? Självklart!
Är dock rätt övertygad om att vad man än gör kommer det inte bli någon större skillnad, att Apple kunna gå förbi är väldigt mycket en konsekvens av att man kan utgå från en ISA som är långt bättre lämpad för dagens krav jämfört med x86.

Men man ska inte överdriva vikten av ISA heller, en rimlig ansats är att en "perfekt ISA" (vilket Aarch64 och även RISC-V kommer väldigt nära att var) kanske ger upp mot 20-30 % bättre IPC allt annat lika.

Vad vi så här långt utnyttjat extremt dåligt i mainstream-programvara är SIMD. Inte speciellt förvånande med tanke på att inget av de stora programmeringsspråket haft något inbyggt stöd för detta tidigare, C++17 blev först med detta. Här finns en latent potential på 2-16 gånger högre prestanda inom de områden där SIMD är användbart, det i existerande CPUer!

Pratar man verkligen om IPC mellan olika CPUer när de gäller X86 64 vs ARM CPUer när de inte ens är samma typ av instruktioner eller ens samma produkter de används för?

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 5820K @4.2 Motherboard: GA-X99-UD4 GPU: ASUS 1070 Strix
HTPC #3 CPU: R5 1600 @3.6 Motherboard: B350m-A GPU: 1080 Sea Hawk X

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Dec 2008
Skrivet av Xyborg:

@MikaelSwahn
Så mycket text, så många förenklingar, så många fel. Jag vet inte ens vart jag ska börja.. @Yoshman , hjälp mig.

Skickades från m.sweclockers.com

Din post var smidigare att quota

@MikaelSwahn
Det må vara 3% prestanda per år, men nu har ju antalet cores äntligen gått upp på konsumentsidan.
På workstation/server sidan så har väl antalet cores ökat hela tiden? (har inte så bra koll) Så det kanske är den sidan man ska titta på istället om man vill se utvecklingen.

Eller så kanske man ska strunta i att jämföra bolag, och istället se Alla tillverkare som en gemensam grupp.
Moore's lag är ju egentligen inte begränsad till vad en specifik tillverkare kan göra, utan används överlag som riktlinje. Så det verkar bättre att se vad tillverkarna presterar överlag. Sen är det ju lite si och så med vem som egentligen är tillverkaren. Det är väl egentligen bara Intel och Samsung som tillverkar kisel själva.

"Dustybridge" 2500K - 32GB RAM - Tac2 - GTX770 - 120hz - vattenkylning - vad mer behöver man veta? ;)

Trädvy Permalänk
Medlem
Plats
Stockholm
Registrerad
Aug 2010
Skrivet av Yoshman:

Vad vi så här långt utnyttjat extremt dåligt i mainstream-programvara är SIMD. Inte speciellt förvånande med tanke på att inget av de stora programmeringsspråket haft något inbyggt stöd för detta tidigare, C++17 blev först med detta.

Hmm? Jag hittar inget explicit stöd för SIMD i C++17. Vad är det du pratar om?
Det jag hittar i C++17 som har med SIMD att göra är att det är lättare att lägga data på jämnare adresser så att de blir lättare för kompilatorer att auto-vektorisera ordinär C++ - kod — om de nu gör det.

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Aleshi:

Jag finner det inte omöjligt att Intel med sitt team av ingenjörer kan göra något strået vassare än det de har om de börjar om från början. Om jag får gissa lite så finner jag det inte orimligt att de identifierat en del svagheter som kräver rätt ordentlig omkonstruktion även fast jag kan för lite för att peka ut någon. Med tanke på hur begränsade resurser AMD har och att Intel högst troligen fortfarande har en signifikant fördel på tillverkningsprocessen så lyckades AMD rätt bra med Zen.

Men men, vi får se. Jag tycker bara att det verkar som att Intel tänker ta fram något som är nytt lite mer från grunden än det de brukar ta fram.

Åter igen, titta på Apple! Där har du ett företag med i praktiken obegränsade resurser, de startade från scratch med en CPU-design som på alla sätt är en "big-core" design.

För att förstå hur mycket "big-core" Apples ARM CPU är kan man titta på en av de grundläggande aspekterna: hur många instruktioner är det teoretiskt möjligt att köra per cykel (issue width). Apples CPU är är 6-wide, jämför det med AMD/Intel som "bara" är 4-wide (Intels CPUer kan "issue" 5 instruktioner per cykel om det är "rätt" mix, inte allt för osannolikt i praktiken att det händer).

Att göra en 6-wide x86 är knappast värt det i praktiken. Är få tillfällen där man kan utnyttja det och det kostar massor med transistorer i front-end att göra detta för x86, är däremot rätt enkelt på Aarch64 då alla instruktioner är lika stora (trivialt att hitta instruktionsgränserna) + avkodning av RISC är långt simplare jämfört med avkodning av x86 (finns brutalt med instruktioner och längden varierar från 1 till 15(!) bytes, det är hjärndöd design 2018).

Resultatet är ändå att Apples design är bättre sett till vissa aspekter och sämre i andra jämfört med Intels. Där Apple är snabbare är primärt de områden där man kan förvänta sig att Aarch64 ger en fördel över x86_64. D.v.s. Core-designen är en fantastiskt bra design givet förutsättningarna (hopplös ISA, minneskonsistensmodell som är allt annat än optimalt för multicore etc).

Skrivet av Bloodstainer:

Pratar man verkligen om IPC mellan olika CPUer när de gäller X86 64 vs ARM CPUer när de inte ens är samma typ av instruktioner eller ens samma produkter de används för?

I de diskussioner som förs i forum likt detta så används "IPC" inte i sin tekniskt korrekta definition (antal maskinvaruinstruktioner som i genomsnitt körs per cykel), i stället använda "IPC" att som ett mått på hur snabbt ett givet problem kan lösas av en CPU-tråd vid en specifik CPU-frekvens.

Med den definitionen går det hur bra som helst att göra jämförelser mellan olika ISA. Skulle man verkligen titta på antalet instruktioner tiltar det hela i favör för load/store ISAs (som ARM, MIPS, etc) då det krävs fler instruktioner i genomsnitt för att lösa en viss uppgift.

Grejen är att x86 CPUer sedan många många år tillbaka delar upp x86 instruktionerna som "front-end" tuggar i sig till något som i praktiken är interna RISC (d.v.s. minnesoperationer är separerade från aritmetiska operationer). Tittar man på Zens back-end så ser den faktiskt mer ut som en modern "big-core" ARM/PPC design än en traditionell x86 back-end (gissningsvis delvis en effekt av att initiala idén var att Zen och K12 skulle dela samma back-end men ha olika front-ends, Zen för x86_64 och K12 för Aarch64).

TL;DR går hur bra som helst att jämföra om man jämför det enda som i praktiken spelar roll: hur effektiv är CPUn att lösa ett specifikt problem (är egentligen irrelevant hur många instruktioner det tar).

Skrivet av Findecanor:

Hmm? Jag hittar inget explicit stöd för SIMD i C++17. Vad är det du pratar om?
Det jag hittar i C++17 som har med SIMD att göra är att det är lättare att lägga data på jämnare adresser så att de blir lättare för kompilatorer att auto-vektorisera ordinär C++ - kod — om de nu gör det.

Och det är det fina i kråksången! Saker blir aldrig riktigt välanvända innan det är så naturligt att använda något att många inte ens inser vad som händer på maskinvarunivå.

C++17 införde std::execution::parallel_unsequenced_policy. Om du garanterar för kompilatorn att din kod uppfyller kraven för detta, vilket innefattar detta

"The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized, vectorized, or migrated across threads (such as by a parent-stealing scheduler). The invocations of element access functions in parallel algorithms invoked with this policy are permitted to execute in an unordered fashion in unspecified threads, and unsequenced with respect to one another within each thread."

Så är det möjligt för kompilatorn att ta din helt "vanliga" sekventiella kod och köra den parallellt m.h.a. SIMD!

SIMD är mer restriktivt jämfört med MIMD ("vanligt" multicore programmering), men SIMD har den enorma fördelen i att kostnaden för att synkronisera mellan de parallella beräkningarna är i princip noll.

Som nämns i tråden är det väldigt många algoritmer som inte kan spridas över flera kärnor på ett effektivt sätt. Finns en delmängd av dessa algoritmer som ändå innehåller en hel del parallellism, men den kan i praktiken inte utnyttjas via MIMD då kostnaden för synkronisering är allt för nära vinsten med att använda flera kärnor (skalningen blir extremt låg eller till och med negativ i vissa fall). Kan SIMD används i teorin är det däremot nästan alltid möjlig även i praktiken just då kostnad för synkronisering är väldigt nära noll.

Utanför C++17 har det även de senaste åren dykt upp en annan form av "automatisk" användning av SIMD, det under namnet "auto-vectorization". Finns i både GCC, ICC och LLVM men i min mening är det bara senare versioner av LLVM där man ser någon praktiskt nytta.

Edit: kod som är SIMD kompatibel kan i teorin även köras m.h.a. av GPGPU i de flesta fall!

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

Trädvy Permalänk
Medlem
Plats
Uppsala
Registrerad
Aug 2015
Skrivet av Yoshman:

Åter igen, titta på Apple! Där har du ett företag med i praktiken obegränsade resurser, de startade från scratch med en CPU-design som på alla sätt är en "big-core" design.

För att förstå hur mycket "big-core" Apples ARM CPU är kan man titta på en av de grundläggande aspekterna: hur många instruktioner är det teoretiskt möjligt att köra per cykel (issue width). Apples CPU är är 6-wide, jämför det med AMD/Intel som "bara" är 4-wide (Intels CPUer kan "issue" 5 instruktioner per cykel om det är "rätt" mix, inte allt för osannolikt i praktiken att det händer).

Att göra en 6-wide x86 är knappast värt det i praktiken. Är få tillfällen där man kan utnyttja det och det kostar massor med transistorer i front-end att göra detta för x86, är däremot rätt enkelt på Aarch64 då alla instruktioner är lika stora (trivialt att hitta instruktionsgränserna) + avkodning av RISC är långt simplare jämfört med avkodning av x86 (finns brutalt med instruktioner och längden varierar från 1 till 15(!) bytes, det är hjärndöd design 2018).

Resultatet är ändå att Apples design är bättre sett till vissa aspekter och sämre i andra jämfört med Intels. Där Apple är snabbare är primärt de områden där man kan förvänta sig att Aarch64 ger en fördel över x86_64. D.v.s. Core-designen är en fantastiskt bra design givet förutsättningarna (hopplös ISA, minneskonsistensmodell som är allt annat än optimalt för multicore etc).

I de diskussioner som förs i forum likt detta så används "IPC" inte i sin tekniskt korrekta definition (antal maskinvaruinstruktioner som i genomsnitt körs per cykel), i stället använda "IPC" att som ett mått på hur snabbt ett givet problem kan lösas av en CPU-tråd vid en specifik CPU-frekvens.

Med den definitionen går det hur bra som helst att göra jämförelser mellan olika ISA. Skulle man verkligen titta på antalet instruktioner tiltar det hela i favör för load/store ISAs (som ARM, MIPS, etc) då det krävs fler instruktioner i genomsnitt för att lösa en viss uppgift.

Grejen är att x86 CPUer sedan många många år tillbaka delar upp x86 instruktionerna som "front-end" tuggar i sig till något som i praktiken är interna RISC (d.v.s. minnesoperationer är separerade från aritmetiska operationer). Tittar man på Zens back-end så ser den faktiskt mer ut som en modern "big-core" ARM/PPC design än en traditionell x86 back-end (gissningsvis delvis en effekt av att initiala idén var att Zen och K12 skulle dela samma back-end men ha olika front-ends, Zen för x86_64 och K12 för Aarch64).

TL;DR går hur bra som helst att jämföra om man jämför det enda som i praktiken spelar roll: hur effektiv är CPUn att lösa ett specifikt problem (är egentligen irrelevant hur många instruktioner det tar).

Och det är det fina i kråksången! Saker blir aldrig riktigt välanvända innan det är så naturligt att använda något att många inte ens inser vad som händer på maskinvarunivå.

C++17 införde std::execution::parallel_unsequenced_policy. Om du garanterar för kompilatorn att din kod uppfyller kraven för detta, vilket innefattar detta

"The execution policy type used as a unique type to disambiguate parallel algorithm overloading and indicate that a parallel algorithm's execution may be parallelized, vectorized, or migrated across threads (such as by a parent-stealing scheduler). The invocations of element access functions in parallel algorithms invoked with this policy are permitted to execute in an unordered fashion in unspecified threads, and unsequenced with respect to one another within each thread."

Så är det möjligt för kompilatorn att ta din helt "vanliga" sekventiella kod och köra den parallellt m.h.a. SIMD!

SIMD är mer restriktivt jämfört med MIMD ("vanligt" multicore programmering), men SIMD har den enorma fördelen i att kostnaden för att synkronisera mellan de parallella beräkningarna är i princip noll.

Som nämns i tråden är det väldigt många algoritmer som inte kan spridas över flera kärnor på ett effektivt sätt. Finns en delmängd av dessa algoritmer som ändå innehåller en hel del parallellism, men den kan i praktiken inte utnyttjas via MIMD då kostnaden för synkronisering är allt för nära vinsten med att använda flera kärnor (skalningen blir extremt låg eller till och med negativ i vissa fall). Kan SIMD används i teorin är det däremot nästan alltid möjlig även i praktiken just då kostnad för synkronisering är väldigt nära noll.

Utanför C++17 har det även de senaste åren dykt upp en annan form av "automatisk" användning av SIMD, det under namnet "auto-vectorization". Finns i både GCC, ICC och LLVM men i min mening är det bara senare versioner av LLVM där man ser någon praktiskt nytta.

Edit: kod som är SIMD kompatibel kan i teorin även köras m.h.a. av GPGPU i de flesta fall!

Det är väl bara jag själv som tycker att det är lite konstigt att man gör den jämförelsen av vad som egentligen verkar vara en prestandabaserad mätning, appliceras mellan två produkter där den ena är byggd och används för prestanda (x86 64) och den andra (ARM) optimeras för strömsnålhet. Jag skulle gärna se Apple jobba för att få upp ARM CPUer i både prestanda, storlek och hur de kan användas i mer desktop/workstation lösningar. Just idag sitter de väl bara på Mobiler/laptops/tablets och sedan är det upp till servrar som använder dom, hela konsument desktop samt enterprise workstation delen är det bara X86 maskiner på, tyvärr.

PC #1 CPU: R5 1600 @3.8 Motherboard: B350-A PRIME GPU: EVGA 1080 Ti
PC #2 CPU: i7 5820K @4.2 Motherboard: GA-X99-UD4 GPU: ASUS 1070 Strix
HTPC #3 CPU: R5 1600 @3.6 Motherboard: B350m-A GPU: 1080 Sea Hawk X

Trädvy Permalänk
Datavetare
Plats
Stockholm
Registrerad
Jun 2011
Skrivet av Bloodstainer:

Det är väl bara jag själv som tycker att det är lite konstigt att man gör den jämförelsen av vad som egentligen verkar vara en prestandabaserad mätning, appliceras mellan två produkter där den ena är byggd och används för prestanda (x86 64) och den andra (ARM) optimeras för strömsnålhet. Jag skulle gärna se Apple jobba för att få upp ARM CPUer i både prestanda, storlek och hur de kan användas i mer desktop/workstation lösningar. Just idag sitter de väl bara på Mobiler/laptops/tablets och sedan är det upp till servrar som använder dom, hela konsument desktop samt enterprise workstation delen är det bara X86 maskiner på, tyvärr.

ARM är inte nödvändigtvis "low-end".

Ja, det fanns en massa orsaker till varför 32-bitars ARM nästan uteslutande användes för strömsnåla enheter och att alla försök att ta 32-bitars ARM till servermarknaden misslyckades kapitalt. Bl.a. så har 32-bitars ARM, precis som x86, en massa gammal dynga i sin ISA som gör det svårare att designa riktiga high-end kretsar.

Till skillnad från x86->86_64 där man "bara" (inte så bara egentligen, Keller et.al. gjorde ett lysande jobb givet förutsättningarna) utökade existerande ISA med 64-bitars stöd så har egentligen 32-bitars ARM och 64-bitars ARM ISA ingenting med varandra att göra. Aarch64 är en "clean sheet" ISA-design med dagens problemsättningar i fokus (inte de som var aktuella tidigt 80-tal)!

Qualcomms "Falkor" Aarch64 CPU som vi hittar i Centriq 2400 är inte "low-end", den matchar Intels/AMDs serve CPUer sett till mängd arbete som utförs per cykel och per CPU-sockel!!! Dessa CPUer används bl.a. i Solarflare Communications bästa servers för datacenterbruk.

Lite Centriq vs Xeon benchmarks, inte mycket till "low-end" där för ARM, eller hur? De fall där Centriq faller efter här är konsekvent de fall där programspråket Go används och orsaken var att man vid tillfället inte hade stöd för en rad ARM-specifika optimeringar medan x86 hade dessa. Det är numera åtgärdat, med upp till x16 (1500 %) prestandaökning i enstaka fall!

Caviums ThunderX2 Aarch64 CPU må vara lite mer nischad jämfört med Qualcomms, men prestandan borde det inte vara något fel på med tanke på att Cray valt att använda dessa i deras absolut bäst presterande produkt (Skylake SP är här nedpetad till andra plats och Epyc används bara i den enklare CS-serien).

Väldigt mycket tyder på att Apple kommer använda deras ARM CPUer även för MBP. Det är egentligen helt logiskt givet att Ipad Pro slår de flesta x86-baserade bärbara för <10k på fingrarna vad det gäller rå prestanda. Problemet här är mest att iOS är ingen höjdare för att producera innehåll...

64-bitars ARM (precis som RISC-V) är en dröm för kompilatortillverkare att jobba med tack vare att dess två tittat på dagens krav och skapat en ISA utifrån det. För x86 får kompilatortillverkarna slå knut på sig själv för att göra det bästa av situationen (och tack vare att så enormt mycket resurser stoppas in blir resultatet ändå riktigt bra!).

Edit:
Det skrivet: tror ändå Intel kan göra en del saker som på ett relevant sätt förbättrar upplevelsen på skrivbordet.

Ett stort problem Intel hade fram till Skylake var att en enda CPU-design skulle täcka allt från ultrabooks till de mest högpresterande servers. Det fungerar inte givet hur extremt olika optimeringar som behövs för en optimal server krets (där många kärnor/trådar, hög minnesbandbredd etc är kritiskt) och en optimal desktop krets (där relativt få kärnor med maximal prestanda per kärna, låg latens etc är kritiskt).

Intel hade redan nästan 100 % av servermarknaden, hade man hävdat för ett år sedan att deras datacentergrupp skulle se >=20 % vinstökning under Q4 2017 och Q1 2018 hade nog de flesta skrattat åt analysen. Nu har vi facit: Broadwell Xeons hade haft problem mot all konkurrens som dykt upp, men Skylake SP (första "rena" server CPUn från Intel) är ett jättelyft. Det verkar även kunderna anse, Skylake SP ger Intel större vinster på servermarknaden än de någonsin haft tidigare.

Ett problem för konkurrenterna är RAM-priset. Intel har höjt prisnivån rakt över för Xeon, för ett system blir det ändå rätt irrelevant då RAM och även SSD står i väldigt många fall för en bra bit över 50 % av kostnaden för HW (kolla vad 128-1024 GB RDIMM går lös på...). Går då inte att konkurrera med "vår CPU är billigare", enda sättet att konkurrera är bättre absolut prestanda och prestand/W (lite beroende på användarfall).

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

Trädvy Permalänk
Medlem
Registrerad
Nov 2011
Skrivet av Yoshman:

Åter igen, titta på Apple! Där har du ett företag med i praktiken obegränsade resurser, de startade från scratch med en CPU-design som på alla sätt är en "big-core" design.

För att förstå hur mycket "big-core" Apples ARM CPU är kan man titta på en av de grundläggande aspekterna: hur många instruktioner är det teoretiskt möjligt att köra per cykel (issue width). Apples CPU är är 6-wide, jämför det med AMD/Intel som "bara" är 4-wide (Intels CPUer kan "issue" 5 instruktioner per cykel om det är "rätt" mix, inte allt för osannolikt i praktiken att det händer).

Att göra en 6-wide x86 är knappast värt det i praktiken. Är få tillfällen där man kan utnyttja det och det kostar massor med transistorer i front-end att göra detta för x86, är däremot rätt enkelt på Aarch64 då alla instruktioner är lika stora (trivialt att hitta instruktionsgränserna) + avkodning av RISC är långt simplare jämfört med avkodning av x86 (finns brutalt med instruktioner och längden varierar från 1 till 15(!) bytes, det är hjärndöd design 2018).

Resultatet är ändå att Apples design är bättre sett till vissa aspekter och sämre i andra jämfört med Intels. Där Apple är snabbare är primärt de områden där man kan förvänta sig att Aarch64 ger en fördel över x86_64. D.v.s. Core-designen är en fantastiskt bra design givet förutsättningarna (hopplös ISA, minneskonsistensmodell som är allt annat än optimalt för multicore etc).

Återigen. Det är inte mig du ska övertyga. Det är Intel. Jag säger inte att Intel behöver börja om från början eller att de ens har någon stor vinst i att göra det. Det enda jag säger är att det onekligen ser ut som att intel ser skäl att börja om lite mer grundligt. Om det är så eller om de i så fall har rätt i detta vet jag inte.