Vad det gäller HT verkar det som Lion Cove finns i ett par varianter. Den som används i Lunar Lake har verkligen inte transistorerna för att köra HT, det är inte bara avstängt. Möjligen gäller samma sak för Arrow Lake. Men allt pekar på att Lion Cove för Xeon kommer ha HT, d.v.s. det är i så fall nu ett "byggblock" som man läggas med där det är vettigt.
Ska bli spännande att följa utvecklingen här. Thread-director schema-lägger i följande ordning för att optimera prestanda (enligt Intels presenation från CES):
1. P-Core (single threaded)
2. E-Core
3. P-Core (HT)
Verkar alltså som thread-director kan slå av HT per kärna, under körning! Någon estimerade att ytan som krävs för att stödja HT är ca 10-20% av en P-Core. Frågan är om inte det i framtiden är bättre att använda det kislet på E-Cores om nu thread-director ändå föredrar dessa över HT?
Å andra sidan, för Lion Cove baserade Xeon ger det mening att ha kvar HT eftersom den inte kommer ha E-Cores.
Louqe Ghost S1 MK3 | Asus ROG Strix B660-I Gaming WiFi | Intel Core i7 12700K | nVidia RTX 2070 Super FE | Corsair 64GB (2x32GB) DDR5 5600MHz CL40 Vengeance | Samsung 980 PRO M.2 NVMe SSD 2TB | Corsair SF750 750W 80+ Platinum | Noctua NH-L12 Ghost S1 edition | Kablar från pslate customs | 2 stk Dell Ultrasharp 3014 | Logitech MX Keys | Logitech MX Anywhere
Inget är ju satt i sten än, men P-kärnorna verkar klocka marginellt lägre och E-kärnorna kan man väl anta klockar ungefär som idag (de maxar på ~4 GHz och det är ungefär vad ARM64 modeller också ligger på nu).
För single-thread blir ju prestandalyftet en direkt funktion av IPC-ökning hos Lion Cove, vilket enligt Intel är ca 16 %.
För multi-thread beror det på fördelningen P-kärnor vs E-kärnor, för toppmodellen blir det (om Intel IPC siffror stämmer i verkligheten) ca 30 % för heltal och ca 50 % för flyttal.
Det sjunker till 28 % samt 46 % för 8/12 P/E-kärnor (i7), blir även samma för 6/8 P/E-kärnor (i5).
Vad det gäller HT verkar det som Lion Cove finns i ett par varianter. Den som används i Lunar Lake har verkligen inte transistorerna för att köra HT, det är inte bara avstängt. Möjligen gäller samma sak för Arrow Lake. Men allt pekar på att Lion Cove för Xeon kommer ha HT, d.v.s. det är i så fall nu ett "byggblock" som man läggas med där det är vettigt.
Sen är det ju så att en stor andel av de som hänger på SweC undrar egentligen: vad blir ökningen i spel? Det som talar för en OK ökning för Lion Cove i spel är att man dragit upp storlek på cache rätt mycket, frågetecknet är att man ökat L2$ och L1I$, inte L3$ (7800X3D har en väldigt stor L3$). Så oklart exakt hur mycket det gör i spel...
För egen del ser de läckta resultat rätt trista ut. Bryr mig primärt om kompileringsprestanda, där ser både Lion Cove och Zen 5 ut att få rätt medioker ökning på ~10 %
Ok. Vi får se då. Låter lovande i alla fall.
Själv bryr jag mig inte alls om spelprestandan när det gäller CPU då det egentligen bara spelar roll om man kör competitive FPS spel i 1080p med extrema framerates. För en annan som kör i 4k och bara bryr mig om så höga kvalitetsinställningar som möjligt så spelar CPU:n minimal roll förutom vissa edge cases.
Nej för mig är det främst till DAW för musikskapande. Flyttalsprestanda för att driva mjukvarustudio med mjukvarusyntar, mjukvarueffektenheter mm. Nästan enbart CPU-beroende (i vissa edgefall också minnesbandbreddsberoende) och då flyttalsprestanda i realtid där CPU-spikes måste undvikas till varje pris. Man vill ha en väldigt liten buffert för att få så låg latency som möjligt. Kan utnyttja flertrådat väldigt bra. Och även e-cores riktigt bra i Win 11 och Cubase.
Så om det är som du säger med mkt högre flyttalsprestanda på e-cores så knänns det som gjort för mitt use-case.
Antar att kompileringsprestanda är en helt annan sak då det inte är realtidsberoende av låga latencies och inte extremt flyttalsinriktat?
Har själv till och från sysslat med en del hobbykodning, mestadels olika projekt i C++, C# och Python. Men gör det till o från och nu är det ett tag sen.
Och, ja, kompileringstid blir irriterande moment då projekten växer. (En fördel för Python som inte kompileras)
Rent genomjävligt då jag prövade på att utveckla androidappar men fick lägga ned det då emulatorn som kördes i Windowsmiljö var tokslö. Iofs inte direkt kompileringsberodende enbart. Varje gång man skulle köra något fick man vänta evigheter. Var helt enkelt obegripligt slött. Antar att det är en helt annan sak i Linuxmiljö? Var iofs en del år sen med en inte allt för snabb burk...
Copyright © 1999–2024 Geeks AB. Allt innehåll tillhör Geeks AB.
Citering är tillåten om källan anges.
