AMD till rätten för falsk marknadsföring av arkitekturen Bulldozers kärnor

Alltså, du fattar inte alls vad jag menar. Problemet är inte rebeandingen i sig utan att man tagit en budgetmodell och rebrandat den till en nyare generation i top klassen R9.

@Djhg2000: Dels så hade inte någon modell utav 386 någon FPU, utan den kom socklad på moderkortet bredvid.

Det jag menade var att på en 386 så visste man att man inte fick någon FPU, utan fick därför köpa till en FPU (som heter 80387) och sätta i sockeln som fanns för detta ändamål på moderkortet.
Inte att man kan köpa en FPU till en gammal intel processor att sätta dit i efterhand på en FX8150, det vore givetvis lite småroligt om så var fallet.

Däremot så tycker jag inte att jämförelsen är sådär jättebra, då man som sagt visste att 386 inte hade någon FPU, men om man missade detta så gick det att fixa i efterhand genom att sätta dit FPU:n på moderkortet.

Däremot med fallet FX8150 så får man vad man köpt.

Att försöka stämma AMD för detta är dock lite löjeväckande, då det borde på sin höjd räcka med pengarna tillbaka (inom skälig tid) men att 4 år senare försöka få igen pengarna för en processor som kostade typ 2500kr ny, är bara slöseri med advokater och domstolar.

Lite som att köpa ett par för små skor, och 5 år senare stämma Puma för att deras storlek 41 inte är samma som Adidas storlek 41, istället bara för att gå tillbaka till butiken och lämna tillbaka skorna och få pengarna tillbaka.

Det kommer inte endast handla om de tekniska aspekterna i domstolen. Även om detta såklart talar till AMD's nackdel finns det andra frågor, som exempelvis konsumentens egna ansvar och vilken skada de faktiskt lidit.

Om det nu slås fast att det varit vilseledande att kalla 4 kärnor för 8, då blir följdfrågan: So what? Vad sägs om att AMD kontrar med: "Visst, det blev lite tokigt i vår marknadsföring. Däremot har vi levererat den prestanda vi utlovat, vilket även bekräftas av oberoende tester. Ingen konsument har blivit lidande av detta".

Observera att jag inte uttalar mig om vad som är rätt eller fel i frågan, utan det jag vill belysa är att det finns många olika sätt att argumentera fram och tillbaka i frågan.

Här är utskriften från "lscpu -e" på min laptop med i7-3840QM (Ivy Bridge):

$ lscpu -e
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
0   0    0      0    0:0:0:0       yes    3800.0000 1200.0000
1   0    0      0    0:0:0:0       yes    3800.0000 1200.0000
2   0    0      1    1:1:1:0       yes    3800.0000 1200.0000
3   0    0      1    1:1:1:0       yes    3800.0000 1200.0000
4   0    0      2    2:2:2:0       yes    3800.0000 1200.0000
5   0    0      2    2:2:2:0       yes    3800.0000 1200.0000
6   0    0      3    3:3:3:0       yes    3800.0000 1200.0000
7   0    0      3    3:3:3:0       yes    3800.0000 1200.0000

Tycker definitivt att HT-tråderna ser ut att dyka upp parvis här, vilket också stämmer med vad jag kommer ihåg från min i7-2600.

CPUID vad jag vet dumpar bara en intern blob och har ingen aning vad informationen den dumpar faktiskt betyder, men ser inte hur varken implementationen eller prestandan av CPUID har någon betydelse här?

Lite av ett sidospår, men behövde faktiskt kolla upp hur det ligger till med soft float numera, och i alla fall GCC har mycket riktigt inte ett inbyggt bibliotek för det längre. Poängen var dock att NT-kerneln antar att x87-instruktionerna finns implementerade på traditionellt sätt (som i Intel 80386-kompatibel) och det du säger här stödjer ju mitt påstående.

Givet vad CPUID returnerade på Bulldozer ser jag det mer som en bugg i schemaläggaren. Antar att AMD testade sig fram till vad de skulle mata in i CPUID för att får bästa prestandan vid lanseringen och löste problemen i efterhand tillsammans med Microsoft. Resultatet är röran vi har idag. Linux kunde de ju fixa på egen hand i förtid utan att någon reagerade eftersom det är öppen källkod och om patchen är tillräckligt väl skriven ser det ut som vilken liten buggfix som helst.

Zen har en väldigt intressant implementation av SMT som skiljer sig markant från hur Core gör och ger bara liknande resultat i genomsnitt. Lite mer information om skillnaderna i denna video:
https://www.youtube.com/watch?v=3K02zTu_baY

Givet att Bulldozer har separata heltalsenheter för varje kärna ser jag inte hur den skulle bete sig nära Core när du inte räknar flyttal, och siffrorna i artikeln du länkade visar i stort sätt bara att den delade flyttalsenheten är en begränsande faktor när du räknar just flyttal. picCOLOR (och bilbehandlingsalgoritmer i allmänhet) är ju tämligen flyttalstunga och räknar dessutom väldigt ofta med transformationsmatriser för att utnyttja SIMD så gott det går. Ska du ha en rättvis jämförelse ska du också ha med heltalstunga program.

Den definitionen är dock lite missvisande om man inte tydliggör att ganska många instruktioner i x86 inte exekverar på en klockcykel. Anledningen till att du kan dela "fetch" och "decode" och ändå få god prestanda är ju att du kan hålla din pipeline fylld medan efterföljande steg fortsätter exekvera instruktioner. Nu spelar jag ju lite djävulens advokat här, men jag hoppas att du ser förbi den löjliga nivån och förstår poängen ändå.

Svårt ja, omöjligt nej. På något sätt klarade vi oss genom att hantera flyttal på separat processor tidigare. Vi skulle utan tvekan behöva någon workaround för existerande kod (troligen emulering) och kompilatorer skulle sannolikt behöva processorspecifika implementationer för flyttal.

Men det är ju bara ytterligare ett argument för AMD att implementera det som SMT istället för att separera ut flyttal, så åter igen stärker du bara mitt argument om att AMD kanske fixade mjukvara med hårdvara.

Om vi bortser från flyttalens existens helt och hållet skulle jag inte kalla Bulldozer FX-8xxx för något annat än 8 kärnor med parvis optimerad pipeline och cache. 8 instruktioner av godtycklig typ kan då exekveras samtidigt (med en offset i latens per par eftersom de inte kan starta exakt samtidigt). Som en konsekvens av den delade cachen kan dock samma data behandlas av två trådar samtidigt och leder därför till en extra väg att optimera prestanda.

Jag tycker tvärt om att AMD inte har gjort något direkt fel här. Om kunderna förväntade sig lika många beräkningsenheter för flyttal som för heltal har de dels inte läst specifikationerna tillräckligt noga och dels känner inte till historien om x86 innan Intel 80386 där flyttal inte ens var en del av CPUn.

Är det en ovanlig konfiguration av beräkningsenheter? Ja.
Är det en missledande konfiguration av beräkningsenheter? Inte enligt mig.

Det stämmer, jag har slarvigt blandat ihop 386 med 486. Den stora nyheten i funktionalitet för 386 var ju MMU, inte FPU. Pinsamt misstag. Låter 386 stå kvar i mina tidigare inlägg för att inte mangla innebörden i dina inlägg.

Hur trådarna dyker upp är ju totalt irrelevant för det som diskuteras här då det inte något praktisk implikation utöver att man måste ha koll på ordningen om man vill köra saker specifikt på två CPU-trådar i samma kärna eller på separata kärnor. Jag har samma ordning på Sandy Bridge som den personen som postade detta, även Nehalem (i7-960 i detta fall) verkar ha samma ordning för denna person.

Om man i linux sätter cpu affinity till 1,3,5 och 7 för en 8 kärnig bulldozer presterar den som väntat, vilket också görs automatiskt.
Sätter man 1,2,3,4 är den dålig men endå snabbare än endast 1 och 3.

På fyrkärnig intel sätter man 1,2,3 och 4. 5,6,7 och 8 är ht.
Av kompatibilitetsskäl hade det varit vettigare att se den som 4 kärnig med ht. Jag gissar att windows gör så.

Skickades från m.sweclockers.com

Påpekandet kring CPUID var enbart att belysa att instruktionen kan patchas och i detta fall skulle en sådan patch inte ens orsaka några potentiella prestandaproblem då CPUID inte används i prestandakritiska lägen.

Vad det gäller OS-kärnor så finns bara en enda sak de i praktiken bryr sig om när det kommer till flyttal: har minst en instruktion körts som använder flyttal sedan senaste kontext-switch? Om ja behövs lite extra hantering av sparande/återställning av flyttalsregister vid nästa kontext-swich. Men bl.a. Linux skippar numera att ens försöka reda ut detta, finns en overhead och är både enklare samt i praktiken lika snabbt att alltid spara/återställa alla register, inklusive de för flyttal. En stor orsak är att x86_64 använder ju SSE-register för flyttal, men SSE register används ju även för heltal (bl.a. för minneskopiering) så i praktiken används nästan alltid dessa register oavsett om programmet jobbar med flyttal eller ej.

Om datorn har en i387, om två (eller åtta som i fallet SPARC T1) CPU-kärnor delar FPU är totalt irrelevant för OS:et. Det är bara en implementationsdetalj, enda OS:et bryr sig om är att alla CPU-trådar har ett separat arkitekturtillstånd för både heltal och flyttal (d.v.s. en egen uppsättning av alla ISA synliga register). Så för detta fall är FPU-delens implementation i Bulldozer irrelevant för det som fallet handlar om.

Vad fallet handlar om är huruvida det kan tänkas vara felaktigt att kalla logiska processorer för "kärnor" i marknadsmaterial. För är vi är väl ändå överens om att

• Bulldozer presterar sig som en 4C/8T

• Optimala sättet att schemalägga både heltalsuppgifter (se @FattarNiInte post om 7z) och flyttal (som TechReport primärt testade) är att schemalägga saker exakt som man gör på Core/Zen med SMT. Ja, det är en mindre skillnad mellan att lägga jobb på två separata kärnor jämfört med att lägga det på två CPU-trådar i samma kärna (framförallt för heltalslaster) för Bulldozer, men det är samma optimala val ett OS ska göra (vilket visar att definitionen som används för SMT har en verkligen positivt poäng)

Vad det gäller videon du postade passar jag och kommentera den mer än att säga: WTF håller han på med där?

Blev nog fortfarande inte helt rätt. MMU introducerades faktiskt med 286, nyheten i 386 var 32-bitars register (EAX, EBX etc).

Känsloargumentet? Vet inte vad du pratar om. Nej det är inte köpar som "får för sig" att R9 betyder topsegment, det är AMD som valt att kalla sina kort i topsegmentet för R9, att då rebranda ett gammalt budgetkort till samma namn är vilseledande, det borde hetat R7 elelr R5. Ett R9 255 motsvars inte av ett GTX 750 Ti. Tom ett 7770 får stryk av ett GTX 460, och ett 7750 ligger en bit under det.

EDIT: Så här beskriver AMD vad R9 serien är:
Leading-edge performance ​and innovative technologies for extreme 4K and VR gaming. For Gamers that demand the best.
Källa: https://www.amd.com/en-us/products/graphics/desktop/r9

Eller... så är denna stämning ett skämt och folk stipulerar bara detta?

Jag håller med om att stämningen till en början ter sig rätt banal men i förlängningen så handlar det väl om vad som får kallas en kärna (core) eller inte. Jag tycker också att Nvidia borde ha blivit utsatt för en stämning i 4GB härvan med 970 kort av samma anledning att man vilseleder konsumenter till att tro att dom får en produkt med fullpresterande 4GB minne.

Som jag förstår detta fall så är det just frågan kring om fallen ens kvalificerar sig för att vara ett potentiellt problem. Verkar vara det man spendera ett par år på. T.ex. har man slagit fast att det är möjligt att beräkna värdet på "skadan".

Är först nu man ska utreda de tekniska bitar kring om marknadsföringen kan anses ha varit missledande.