Skrivet av tellus82:
Den som inbillar sig att Intels plattform skulle vara mer stabil är verkligen ute och cyklar, har ni redan glömt sata buggen i P67? eller varför inte Skylake buggen som orsakade krascher under hård belastning (senare fixad med bios uppdatering/mikrokod). Att AMD skulle vara bättre eller sämre på denna punkt är bara löjligt, bägge parter har haft och kommer ha sin beskärda del av hårdvarubuggar.
Vad det gäller specifika moderkortsproblem så finns dom definitivt i bägge läger men då har det med tillverkaren av just det moderkortet att göra, inte plattformen/AMD/Intel.
Man kan inte titta på en population på < 10 system och dra några slutsatser. Där jag jobbade hade vi inte heller jättemånga maskiner, strax under 100 st. För oss var då generellt sett färre HW-fel på Intel-plattformen men AMD var ändå värt det då den presterade bättre (priset var egentligen inte en faktor).
Och jämför vad respektive företag tar för ansvar när det väl skiter sig. AMDs TLB bugg i Phenom 9000-serien gick i.o.f.s. att fixa, men fixen gav en signifikant prestandaförsämring under Windows (även under Linux minskade prestanda med fix, men där var effekten långt mindre så inget jätteproblem för oss på den tiden). Enda anledningen att AMD kom undan med att inte återkalla dessa måste ha varit att inte så många exemplar hann ut på marknaden, för problemet gick inte att lösa på ett vettigt sett i programvara.
Intel gjorde återkallande på kretsar som hade SATA-problemet, även där var problemet "bara" försämrad prestanda, men återkallande var det enda rimliga då det inte gick att lösa med programvara.
Skylake problemet fixade man på ett sätt som inte resulterade i någon mätbar skillnad i prestanda. FPU-problemet i Pentium hanterades med återkallande (för det gick inte att lösa i programvara).
TSX-problemet i Haswell gick inte att lösa med programvara, "fixen" stängde helt enkelt av TSX. Enda orsaken att Intel kom undan med det var för att Windows varken då eller nu använder TSX. Däremot använder allt som använder pthreads under Linux TSX, vilket i praktiken är nästan alla multitrådade applikationer. Xeon E5/E7 hade aldrig detta fel (där hade man absolut blivit tvungen att återkalla annars) och från Skylake fungerar även TSX i konsumentmodellerna.
Antal problem på Xeon-plattformen är extremt få, den plattformen (vilket som sidoeffekt även inkluderar E-serien) genomgår långt mer validering än konsumentmodellerna. Och sedan tillkommer det faktum att ju fler som använder en plattform, ju sannolikare blir det att man hittar eventuella buggar. Något som t.ex. näms kring den bugg för virtualisering som nyligen upptäckts både i Intels och AMDs modeller (ett fel som Intel fixade betydligt snabbare)
"Due to Intel's dominance in the data center and virtualization world, this AMD-specific bug is not going to cause widespread chaos. However, it may give some people grief. For one thing, the code gremlin managed to nip the OpenSUSE Linux project, which is cosponsored by AMD."
Denna bug var rätt allvarlig, den gjorde det möjligt för något som kör virtualiserat att ta över hela systemet!
Svårt att säga speciellt mycket konkret om Zen än, men om de läckta resultaten är något att gå efter tycker i alla fall jag att Zen mer ser ut som en riktigt bra server CPU än en riktigt bra desktop CPU.
Ska man in i datacenter är prestanda och prestanda/W viktigt, men man kommer också behöva visa att man riktigt gör hemläxan kring validering samt att när det skiter sig (för det kommer skita sig i något läge, som i fallet ovan t.ex.) måste man visa att det inte är kunden som blir sittande med svarte petter.
Skrivet av Knightmare:
Det blir en 8C/16T Ryzen för mig oavsett enkeltrådsprestandan.
Så här ser min Xeon 6C/12T ut i 90 min när jag kör make:
http://forumbilder.se/FC0E5/kompilera-android.png
Jag är helt säker på att den kommer funka utmärkt i spel med mina krav (RX 480).
/Knight
Har inte jobbat med Android som OS utan bara med app-utveckling. Men du menar alltså att Android har ett så fundamentalt trasig byggsystem att det är en fördel med ett system som kan bygga om allt så fort som möjligt? Det borde i alla fall inte vara Linux-kärnan som ställer till det, där finns korrekta beroenden för att bara bygga om det som måste byggas om.
Jobbar själv med OS-utveckling (realtids/inbyggda-system) och visst går det absolut snabbare att bygga om allt med dual Xeon E5 maskinen, men i 99 % av fallen är det ju en eller en handfull filer som behöver byggas om. En av grundpelarna med make är just att erbjuda ett system som gör det som måste göras, men inte mer (något som tyvärr allt för många misslyckas med...).
För mig är största flaskhals unit-tester. Använder Bost.Test och alla som använt boost vet att det kryllar av templates, något som gör kompileringstiderna lååånga. Grejen är att normfallet är ju att man ändrat i en fil och vill köra om testerna, då är det typiskt en eller ett par test-filer som byggs om så flaskhalsen blir som väldigt många andra fall: enkeltrådprestanda då det inte går att sprida ut kompilering av en enskild fil över CPU-kärnor på ett vettigt sätt.
Tar ~7-8 s att bygga om en fil på en normalsnabb laptop, tillräckligt kort för att man inte ska hinna göra något annat, absolut tillräckligt långt för att det ska bli irriterande! Bygger man om alla tester skalar det däremot helt linjärt med CPU-kärnor.
