Intel Skylake efterträds av Kaby Lake 2016

Se nedan

Jaså, jag har läst i en teknisk artikel att switcha mellan trådar tar flera hundra cykler på x86. Och att det bara är SPARC T1, T2, etc som kan switcha trådar snabbt och på så sätt dölja latens, genom att arbeta med nåt annat då tråden väntar på data från RAM. Har du länk som stödjer påståendet att x86 kan switcha snabbt? En annan studie visade att SPARC har typ 95% cpu utilization under full load, medan studier från Intel visade att en server x86 cpu, har cpu utiliation på kring 50% eller så, under full load. Om det nu stämmer som du säger, att x86 kan gömma latens, så borde Intelstudien visat att en server x86 cpu har en cpu utilization på kring 90% precis som SPARC. Så något är fishy.

SPARC T1 var ju kanske 10x snabbare än x86 på trådade server laster, trots att den var klockad på typ 1.2GHz med totalt 256KB cpu cache, och Xeon x86 var klockad på 2.5GHz och cpu cache på flera MB. Så därför var det möjligt att SPARC T1 krossade en x86, pga 95% cpu utilization medan x86 hade 50% cpu utilization. Så något är fishy. Hur kan SPARC T1 vara 10x snabbare än x86 om de döljer lika mycket latens genom snabb trådswitchning?

Jag ser minst två sätt hur man kan förklara att SPARC T1 är 10x snabbare än x86 på vissa trådade serverlaster.
1) Du har fel, x86 tar flera hundra cyckler att switcha tråd, precis som jag läst och kan alltså inte dölja latens. Och det är därför SPARC T1 är 10x snabbare än x86.
2) x86 kan switcha snabbt, men eftersom SMT bara har två trådar så kan inte mycket latens döljas och därför är SPARC T1 över 10x snabbare på vissa laster.

I båda dessa fall har du fel. Så har du länkar? Det låter inte troligt att x86 kan dölja latens, för då borde x86 ha cpu utilization på 95% precis som SPARC T1, och då finns inte en chans att SPARC T1 var 10x snabbare, eftersom x86 har mer än dubbelt så bra specar (dubbla GHz, dubbla cache storleken = 4x bättre spec)

Jag har kollat upp UV2000 igen och det verkar vara lite olika bud. Föregångaren till UV2000 hade i alla fall fat tree topology, dvs hierarkier med olika lager av switchar.
http://clusterdesign.org/fat-trees/

Här står att UV2000 består av ett rack som består av flera IRU, dvs 8 compute blades i varje IRU. Dessa 8 blades är kopplade inuti en IRU enhet genom en 3D enhanced hypercube. Och varje sådan IRU enhet är kopplade samman i en cross bar interconnect, dvs en vanlig matris. Så det är alltså en matris med massa IRU enheter.
http://www.theplatform.net/2015/03/05/balancing-scale-and-sim...

Men här står det nåt på sidan 8 längst ned, att UV2000 med 256 sockets har "three level router topology". Jag vet inte vad det betyder, men kan det betyda tre lager av routrar eller nåt sånt, precis som föregångaren hade flera lager av hierarkiska switchar i en fat tree topology?
https://www.coursehero.com/file/p481j0/Figure-3b-256-socket-u...

detsamma står här
https://www.coursehero.com/file/p481j0/Figure-3b-256-socket-u...

I vilket fall som helst så är latensen till noder långt bort mer än 10x sämre än om man rör sig i samma enhet. T.ex. i en liten 64-socket SGI UV2000 är latensen 870 nanosekunder, dvs 10.7x sämre (sidan 4 i länken nedan). Om man skulle skala upp till 256-cpuer så skulle latensen bli mycket värre. Latensen minskar ju inte linjärt, utan värre än så. Det är därför alla stora Unix servrar stannar vid 32-cpuer.
www.adms-conf.org/2014/adms14_kissinger.pdf

Nja, jag vet flera Linux fantaster (t.ex. virt*** v***) som tror på fullaste allvar att ett HPC cluster som SGI UV2000, kan ersätta och köra scale-up enterprise arbetslaster långt bättre än stora Unix servrar. Somliga av fantasterna har sagt att stora Unix servrar är dinosaurier och snart utdöda och att framtiden är hos stora Linux x86 servrar med 100 tals sockets. När jag påpekar att UV2000 är ett kluster eftersom det enda som körs på UV2000 är HPC laster, så idiotförklarar de mig. Jag frågar då varför alla höga SAP benchmarks är med stora Unix servrar, och alla x86 benchmarks är typiskt 8-sockets och med dåliga poäng och definitivt finns inte UV2000 med bland SAP benchmarks - så får jag inget svar. Men de fortsätter trots det hävda att UV2000 skalar bättre och ersätter stora Unix servrar som SPARC och POWER. Utan några bevis eller benchmarks, eftersom det inte existerar några bra x86 affärsbenchmarks att tala om. Det är bara stora Unix servrar med 32 sockets som klarar av bra affärsprestanda, eftersom Unix skalar långt bättre än x86 eller Linux. Nu pratar jag om scale-up (dvs en stor fet server), och inte scale-out (dvs kluster). Så, jo, det finns massor av såna människor som tror att Unix servrar är dinosaurier och snart utdöda, typiskt finns de i Linux lägret.

Visst kanske NUMALink6 ha en låg latens, men när man börjar skala upp så degraderas prestandan raskt. Med så få som 64-sockets blir latensen mer än 10x sämre. Föreställ dig då 256 sockets med kanske 4x sämre latens. Eller, som de gamla föregångarna till UV2000 som SGI hade, som skalade upp till 4096 cpuer - hur dålig tror du latensen var på ett sådant kluster? Det hade antagligen många många lager av switchar i hierarkier och latensen kröp upp mot millisekunder kanske?

Möjligt, men jag pratar om high end servrar. Och SAP säger själva i en studie att ca 10% av alla deras kunder vill ha >4-sockets.

Vad jag kommer ihåg är detta första gången jag hävdar att x86 maxar på 3-400 gflops. Men strunt samma. Här står att POWER8 maxar på 384 gflops. Jag trodde inte att x86 har dubbelt så hög gflops? Har du länk?
http://www.oerc.ox.ac.uk/projects/asearch/hardware/ibm
"...see HotChips presentation above). With the cores running at 4GHz, and each core capable of 4 double precision FMA operations per cycle, the peak performance is 384 GFlops per chip. This is not as high as a top-of-the-line x86 CPU..."

Jag vet inte. Jag är mer intresserad av SPARC M7 som är en server cpu, än denna XIfx som har två starka trådar per core vilket är ju mer desktop laster. M7 fokuserar ju på genomströmning, dvs serva många klienter samtidigt, dvs en riktig server cpu.

Jag har för mig att enligt fysikens lagar så är effektkravet = GHz * GHz * Volt
Så effekten växer alltså i kvadrat om du ökar GHz. Därför går det inte att gå över 5GHz på ett enkelt sätt.

IBM sade ju länge att deras POWER cpuer skulle gå mot 7-8GHz eller ännu snabbare. IBMs dual core POWER6 kördes ju på 5GHz och hade två trådar, dvs fyra trådar totalt. IBM sade explicit att "databaser körs bättre på få starka trådar, än många svaga trådar". Och om man vill ha många trådar, så stoppar man i många cpuer istället. Då får man både snabba och många trådar. Och därför ville IBM att deras cpuer skulle bli högre och högre klockade och siktade på 7-8GHz i nästa generation. IBM hånade SPARC T1 familjen som var "en nitlott och hade ingen framtid". IBM optimerade hela POWER för databaser, dvs hjärtat i alla affärsystem.

Samtidigt fanns den helt nya radikala SPARC T1 familjen och visade en annan väg med lägre klockade men många cores och många trådar. Så t.ex. behövdes tre IBM P470 servrar med 14 st POWER6 på 4.7 GHz för att matcha en enda Sun Niagara T5440 som har fyra st SPARC T2 cpuer på 1.6GHz i SIEBEL v8 benchmarks.

Men efter POWER6 så frångick IBM få men starka cores, och började likna SPARC mer och mer, med många och lägre klockade kärnor. T.ex. IBM POWER8 liknar ju SPARC M6 ganska mycket; både har 12 cores och 8 trådar varje kärna. Om man hade trott IBM så skulle POWER8 varit en eller två cores, med 12 GHz eller så. Men IBM insåg att det inte funkade, pga effektkraven mfl problem. Och nu är POWER ganska lik SPARC med många kärnor och många trådar. Och helt plötsligt anser IBM att det är så man ska bygga cpuer och att IBM är "revolutionerande och unika". När det i själva verket är starkt influerat av SPARC

Vad teorin säger kan man inte räkna med. Har du länkar som visar 700 gflops? Jag googlade förut på x86 och hittade inget vettigt. Jag hittade bara POWER8 siffran.

Jag har för mig att SPARC T1/T2 byter tråd när den vill det, dvs när den får en cache miss. Inte att den byter varje cykel.

Så den tekniska artikeln på djup detaljnivå som jag läste förrut, stämmer inte när den påstod att det tog flera hundra cykler att byta tråd för en x86? Har du länkar? Jag kan försöka hitta artikeln jag läste igen, men det var längesen, men jag ska googla lite. Men om du redan är säker på detta, så kanske du kan visa länk?

Men varför har SPARC T1/T2 ca 95% cpu utilization och x86 har maximalt 50% under full load - om nu x86 är snabbare på att switcha trådar? Kan det bero på att x86 bara har två trådar och när en tråd stallar, och den switchar, så kanske även andra tråden stallar snart, och då är båda trådarna upptagna med att fetcha data från RAM, dvs det tar väldigt lång tid och därför har en x86 endast 50% cpu utilization under server work loads? Självklart har en x86 som kör desktop laster mycket högre cpu utilization. Det är när den kör server workloads och den servar många klienter som data aldrig kan få plats i cpu cachen, så cpun måste ut till RAM hela tiden. Om tusen klienter ska servas, som alla gör olika saker, så går det aldrig att cache all deras data i en cpu cache.

Medan en 8 core och 64 trådars SPARC T1/T2 alltid har en tråd redo för exekvering. Är det därför som en 1.6GHz SPARC cpu kunde vara 10x snabbare än en x86 på 3GHz?

P4? Det kommer jag inte alls ihåg. Det var en studie från Intel som visade att en server x86 cpu idlar 50% av tiden under full load. Men det är ju självklart, hur skulle en cpu kunna cacha 1000 användares data? Det är ju omöjligt. Det går ju bara att cacha en liten arbetslast, t.ex desktop arbetslaster som kan köras i en tight for loop. Alla cpuer har ju detta problem, det är omöjligt att cacha 1000 klienters data i cpu cachen. T.ex. Fujitsu M10-4S SPARC server som har topp SAP benchmarks, kan serva 153.000 samtidiga SAP användare. Och alla dessa användare gör helt olika saker, så det går aldrig att cacha detta. Så man måste ut till RAM hela tiden. Och det gäller även idag, en cpu kan inte cacha allt, utan måste ut till RAM. Så man måste maskera detta på något sätt, t.ex. genom enorma cpu caches, jag har för mig att nån IBM cpu hade 96MB cpu cache. Men ändå, det går inte att få in tusen tals klienters data i 96MB RAM, därför att du även måste få in SAP, databasen, kernel, etc etc. Du måste alltid ut till RAM om du kör server laster. Punkt. Det spelar ingen roll om du kör dagens Xeon E7v3 eller POWER8 eller SPARC M7.

Men visst, även om det nu vore P4, så måste man tänka på att SPARC T1/T2 var inte heller några bra cpuer idag. Du säger att P4 är dålig idag, men T1/T2 är också dåliga idag. Men visst var det så att P4 var bättre på desktop laster, med tunga beräkningar. SPARC T1/T2 var ju bra på hög genomströmning med att serva många klienter med enkla jobb. Där var den 10x snabbare eller så.

Jag hänger inte riktigt med här. Den länken du visar angående att Xeon Haswell når 788 gflops, är ju när han benchar två stycken Xeon Haswell proppar samtidigt.
https://www.pugetsystems.com/labs/articles/Xeon-E5-v3-Haswell...

Kan du posta en annan länk som visar att en enda Xeon når runt 700 gflops? Jag menar, POWER8 som ska vara väldigt snabb, når bara runt 384 gflops. Och IBM påstår att POWER8 är flera gånger snabbare än x86. Så då borde x86 nå mindre gflops än en POWER8?

Ok, så du menar att det kan vara så att när SPARC T1/T2 byter tråd, så går det långsamt om den byter OS-trådar? Det låter rimligt. Så poängen med SPARCs snabbhet är alltså att den kan maskera mycket mer latens genom att ha många fler trådar att switcha mellan. x86 har bara två trådar att switcha mellan och när de stallar, så får x86 vänta ofta. Det låter rimligt.

Den här studien var inte från Sun. Det var några forskare från nåt universitet har jag för mig. Jag borde sparat artikeln när jag läste den förrut. Och artikeln dröjde med att komma ut, SPARC T1/T2 hade funnit något/några år, innan den började få uppmärksamhet.

Men se på det så här, om jag verkligen sväljer allt som Sun/Oracle skriver, så räcker det med att du motbevisar med länkar/benchmarks/etc så ändrar jag mig. Genast. Det är inte svårare än så att få mig att ändra ståndpunkt. Bevisa att jag har fel. Bevisa även att Sun/Oracle har fel, så kommer jag ändra åsikt, även där. Det är det som är skönt att diskutera med matematiker, det spelar ingen roll hur många timmar man diskuterar, men bevisar du med hårda fakta/länkar så ändrar en matematiker omedelbart ståndpunkt. Simple as that. Det tar några sekunder bara, så tycker jag exakt som du.

Däremot vet jag att man kan visa Linux fantaster (och även dig) hur många länkar som helst som de/du omedelbart avfärdar. Jag har t.ex. visat dem flera länkar om hur bloatad Linux kernel är, enligt vad Linus Torvalds säger - och alla Linux fantaster avfärdar genast Linus Torvalds som mindre vetande. Erhm??? Jag menar, finns det någon mer trovärdig källa om Linux än Linus? Nej, och ändå avfärdas han, trots att han gång på gång i flera olika intervjuer säger att Linux kernel är bloatad. O_o

T.ex. anser du ju att Linux TCP IP stack är helt överlägsen allt annat på marknaden. Och ifall jag visar dig såna här länkar (många av dessa kommentarer säger att Linux stack är inte alls vidare bra) så kommer du omedelbart avfärda länken eftersom "Facebook inte kan så mycket om högprestanda nätverkstrafik". Det går liksom inte att få dig att ändra ståndpunkt, oavsett hur många länkar man visar, från Linus Torvalds eller Gud själv. Alla bevis avfärdas utav dig. Men jag sväljer alla bevis.
http://bsd.slashdot.org/story/14/08/06/1731218/facebook-seeks...

Cache är inte _onödigt_, det är mycket bra. Men mindre viktigt på serverlaster än på desktops, eftersom alla data inte får plats i cachen. Det som är viktigt är att minska latensen, det kan göras mindre bra med cache. Det är bättre att dölja latens med många trådar. En vanlig desktop cpu med få starka trådar och stor cache, når 50% cpu utilization på server loads. En SPARC T1 når 95% cpu utilization på server loads med mycket liten cache. Vilket är bäst, cache eller trådar? Det är helt omöjligt att nå 95% cpu utilization med stor cache. Men det går att nå med trådar.

Idag har Oracle många trådar, SPARC M7 kommer att ha 256 trådar. Hur förbättrar man prestanda härnäst? Jo, genom att gå tillbaka till de gamla sätten; öka cachen. Men om man sysslar med servrar, så är många trådar bättre än stor cache. Så bara för att Sun/Oracle börjat addera cache efter att först ha ökat antalet trådar, så betyder det inte att Sun/Oracle tycker det du säger.

Man kan lägga sin Watt budget på två olika sätt:
1) en enda core som skruvar upp GHz tills kärnan ensam slukar 250 Watt. Det kanske blir 8-10 GHz?
2) många cores/många trådar som tillsammans slukar 250 watt.

IBM pratade om att 1) var framtiden och att 2) var dåligt, och hånade Suns SPARC T1. Tycker du att POWER8 är mer lik 1) eller 2)? Tycker du att POWER8 är lik en sådan design som IBM menade var framtiden för cpuer? Eller gick IBM kanske över till många cores/många trådar design, med sin POWER8 som har 8-12 cores och 96 trådar, precis som SPARC M6 också har 8 cores och 96 trådar? Jag fattar inte att du verkligen tycker på riktigt, att POWER8 är mer lik en single core cpu med två trådar på 8-10 GHz?

Tyvärr, jag är inte övertygad. Jag vet flera fall där man extrapolerar på liknande sätt och får radikalt andra resultat i verkligheten. Om vi tänker till lite, kan ditt resonemang vara rimligt? Är det konsistent om vi tittar från annat håll? Reality check.

Antag att en 5930K med 6-cores drar 150 watt. Om du drar ihop 3 stycken såna här cpuer så får du 18 cores och 350 Watt.

Antag att den dära 18 core Xeon E5 2699v3 du pratar om, också drar 150 watt.

Nu påstår du att en 150 Watt Xeon E5 cpu ger lika mycket prestanda som 350 Watt 5930K. Jag tror inte på detta. Om Intel får 350 watt budget att leka med, så blir prestandan enormt mycket större än om Intel får 150 watt budget. Rimligtvis är en av de 18 kärnorna i E5 mycket klenare än en av de sex kärnorna i 5930K. Mao, så kan du inte tro att en Xeon E5 motsvarar tre st 5930K. Visst, watt siffrorna kanske inte stämmer exakt, men jag hoppas du inser att något är fishy i ditt resonemang?

Visst, om Xeon E5 faktiskt drog 350 Watt, och varje 5930K drog 150 Watt, så är din teori konsistent och det låter trovärdigt att det bara är att dra ihop 18 st individuella 5930K kärnor. Men nu är det antagligen en logisk lucka när du benchar två st x86 cpuer och inte en enda x86 cpu.

Teori är en sak, praktik en annan. Det enklaste vore om du visade benchmarks där en enda x86 når runt 700 gflops. Då har du övertygat mig och jag tycker som du. För som det ser ut nu, enligt din länk, så ligger den snabbaste x86 på 394 gflops vilket är mycket bra, men långt ifrån 700 gflops. Jag gissar även att alla cpuer som benchmarkades ligger på kring 150 watt styck. Mao, det är svårt att öka prestandan mera eftersom watt budgeten är maxad, oavsett om du har få starka cores eller många svaga cores. Mao, just nu verkar det som att ifall Intel får 150 Watt att leka med, så kommer Intel upp i endast 394 gflops. Inte mera. Sen tror jag det spelar mindre roll om det är få starka kärnor eller många svaga kärnor - slutresultatet blir detsamma: ~400 gflops från Intel är max. Och det är bättre än POWER8 på 384 gflops, så det är inte fy skam. Jag är imponerad utav x86 faktiskt.

Jag tror fortfarande att SPARC är konkurrenskraftig med Xeon och POWER. Tror inte du det?
-SPARC XIfx når 1100 gflops. POWER8 når 384 gflops. x86 når 400(?).
-SPARC M7 har 32 cores, 256 trådar, adresserar 2 TB RAM, gör SQL queries 120 GB/sek, stoppar heartbleed attacker och andra pekarfel, krypterar och dekomprimerar data i realtid, etc etc.

Den största 32-socket SPARC M7 servern kommer detta år, har 1024 cores, 8192 trådar, 64TB RAM. Den största x86 business scale-up servern hade fram till nyligen 8-sockets.

Jag vet inte riktigt, men... du tycker att SPARC laggar? Speciellt som SPARC dubblar prestanda varje år, medan x86 ökar prestandan typ 10% varje år. Oracle har släppt fem cpuer på fyra år. Servrarna är dubbelt så snabba, varje generation, ibland flera gånger snabbare varje generation. Om man dubblar varje generation, och alla andra ökar 10% så till slut måste man bli snabbast. Eller hur? Sant är att Sun hade stora problem, men Oracle satsar mer pengar på FoU än Sun någonsin gjort. Därför kan SPARC dubbla prestandan varje generation.

Som du vet minskar Unix marknaden och har gjort det flera år. Men Oracles stora affärsservrar ökar kraftigt. Varje år. Oracle gör en Apple; tillverkar hårdvara, cpu, OS, databas, middleware, etc etc. Så dessa system är mycket optimerade att köra affärssystem och databaser. Och gör det mycket snabbare än en ihopplockad x86 eller POWER.

Dessutom är det mycket politik. T.ex. på mitt stora företag sade cheferna helt plötsligt "nu slutar vi köpa Sun prylar, order från högsta chefen". Och senare sade de samma sak om HP. Sun hade väldigt bra OS och hårdvara, t.ex. ZFS, DTrace, etc - men om företag vägrar köpa så blir det svårt.

Det var precis det här jag menade.

Jag visar länk när Facebook säger att Linux stack är inte alls lika bra som FreeBSD, och i kommentarerna skriver massa människor att FreeBSDs stack är helt överlägsen, etc etc - och genast avfärdar du länken som att Facebook inte vet vad de sysslar med. Och att Linux stack är mycket bättre därför att fler kör det OSet. Precis som Windows körs mer än Linux, då måste Windows vara det bästa OSet.

Det spelar ingen roll hur många länkar jag visar, om du har bestämt dig, så har du och det går inte att ändra på dig. Inte ens om Linus Torvalds ringde dig och sade att stacken suger och att han kopierat allt från FreeBSD skulle du ändra dig. Du skulle avfärda honom direkt. Jag vet hur du funkar.

Som tur är, funkar jag inte så. Om Solaris utvecklarna skulle alla säga att Solaris blivit dåligt och att Linux är bättre och att flera OS utvecklare säger så, skulle jag ändra mig. Då skulle jag börja supporta Linux och överge Solaris. Jag gilllar bara den bästa tekniken, jag har bytt läger flera gånger förrut. Plan9 verkar vara det häftigaste OSet, men jag tror inte det skalar vidare bra på affärsservrar.

Jag har inte blivit överbevisad på något forum, du får gärna PMa mig om du vet någon tråd. Jag hittar fel i deras resonemang (som i ditt), eller så postar de inte relevanta länkar. Om jag verkligen skulle bli överbevisad, skulle jag genast ändra åsikt. Det har hänt flera gånger. Jag har påstått något, och någon har visat länkar som säger motsatsen, och då har jag genast slutat säga så och tackat personen. T.ex såg jag en blog med Oracles stora ZFS servrar mot NetApp, och jag citerade bloggen och förklarade att NetApp hade dåliga prestanda i det fallet. Som alltid postar jag även länken, så att man vet att jag inte hittar på. En NetApp människa läste bloggen och förklarade att bloggen var fel. Jag tackade honom och slutade citera bloggen och skrev även på Oracle bloggen att det var fel och att han borde sluta skriva så. Matematiker söker bara sanningen. Så, om du visar trovärdiga länkar, så tycker jag som du. Jag _måste_ tycka som du, annars är jag inte matematiker. Jag har inget annat val om jag bekänner mig till sanningen.

SPARC är chanslösa mot x86 och POWER? Jag tycker specarna säger annorlunda? Och SPARC har flera världsrekord idag. Nu pratar jag affärssystem. När det gäller kluster dominerar Linux och x86 stort.

Poängen är att samtidigt med SPARC T1 sade IBM att en enda stark core är framtiden. Och att SPARC T1 suger, pga den har så många klena cores att en databas inte skulle köras bra på en SPARC T1 (och det är ju sant). Så därför är framtiden en enda stark core på skyhög GHz. Detta var vad IBM sade och hånade SPARC T1. Och som jag ser det, så har IBM övergett denna syn till att göra som Sun gjorde först med commoditycpu: istället för att höja GHz, så höjde Sun antalet cores. Sen följde alla andra efter. Men du håller inte med om detta? Du anser att IBMs cpuer inte alls har många kärnor med många trådar idag? Att IBM fortfarande är inne på ensam-stark-kärna spåret? Att IBM inte alls liknar SPARC mer och mer?

Som du vet, en matematiker vägrar ingenting som det finns bevis för. Om du verkligen kan visa benchmarks på en singel x86 cpu som når 700 GFlops så ändrar jag självklart åsikt. Men som du gör nu, visa två x86 cpuer som tillsammans når 700 Gflops och dra slutsatsen att en enda x86 cpu når samma siffra är ju inte riktigt rätt. Det hoppas jag du inser? Det enklaste är att du visar benchmarks för en enda cpu. Jag har dock aldrig sett siffror högre än några 100 gflops för en ensam x86, och jag är intresserad av cpuer och påläst om ämnet. Jag hade reagerat kraftigt om jag sett x86 gflops närmare 1000, ja tom över 500 gflops hade jag reagerat på och kommit ihåg det. Och under alla åren har jag aldrig sett det. Så därför blir jag fundersam när du påstår att en x86 klarar av 700 gflops. Det bör backas upp med benchmarks, eller ett logiskt resonemang som håller ihop. Och det resonemang du presenterat håller inte ihop.

Ett av skälen att SPARC och POWER är snabbare än x86, är att såna här Enterprise servercpuer har mycket högre TDP att leka med. De kanske rör sig kring... 250 Watt? Jag tror att om x86 också fick 250 Watt skulle x86 prestera mycket bättre, ja, kanske t.om 700 gflops? Fujitsu SPARC XIfx når nu 1100 gflops, men det är en cpu fokuserad på enkeltrådad prestanda, inte genomströmning som Oracle SPARC M7 gör. Men det viktiga är watt budgeten. Unix Enterprise server cpuer som sitter i stora servrar som väger ett ton, har mycket bättre kylning och man bryr sig inte hur mycket watt de slukar. Om även x86 fick samma lösa tyglar skulle x86 göra bättre ifrån sig. Men det är märkligt att tro att en 150 Watt cpu kan hålla jämna steg med 250 Watt cpuer.

Om du inte kan presentera gflops benchmarks runt 700 gflops så föreslår jag du slutar påstå det. När jag inte kan bevisa något påstående (eller kan presentera ett vettigt resonemang), eller om jag blir motbevisad, så slutar jag genast påstå det. Annars skulle folk tro det vara FUD, och det vore inte bra. I min värld når x86 runt 400 gflops, eftersom den siffran finns det faktiskt bevis för. Om man inte kan bevisa något (antingen genom ett vettigt resonemang eller benchmarks) så kanske det inte är sant och det vore vanskligt att påstå det vara sant.

Sen har du rätt i att varken SPARC XIfx eller SPARC M7 finns att köpa än, men i alla fall SPARC M7 kommer detta år. Och dessa cpuer kommer vara flera ggr snabbare än allt annat på marknaden. Inte 50% snabbare eller så, utan flera ggr snabbare.

Angående facebook och Linux. Det är väl känt att Linux presterar bra på små laster, men har problem att skala uppåt. Någon gammal Unix admin sade att när de benchar olika OS så är ofta Linux snabbast men vissa trådar kan ta lång tid på sig. Linux är opålitligt sade han. Dvs, det hackar och klarar inte stor last, men flera trådar trådar är snabbare än andra OS, och somliga trådar tar lång tid på sig. Medan t.ex. Solaris är aningen långsammare, men jämnare, alla trådar är ungefär lika snabba och man kan skala uppåt och köra mycket stora laster och allt går ungefär lika snabbt och körtiden är predikterbar (vilket är mycket viktigt i Enterprise). Typ som att Linux är en racerbil och det går snabbt med liten last, och i jobbiga uppförsbackar storknar Linux. Men Solaris är som en långsammare lastbil med stor last som kör i jämn takt, uppförsbacke eller ej. Solaris är mer designat för genomströmning och stora laster. Om du har en algoritm som är designad för små laster, så kan du ha små konstanter och en O(n^2) kan vara snabbare än en O(n logn) algoritm för små laster. Men när du ökar lasten tillräckligt mycket så drar O(nlogn) algoritmen ifrån. Precis samma sak gäller för Linux och Solaris. Detta var vad han sade. Och han föredrog HP-UX, det var den bästa Unixet sade han.

Och som du vet är det olika design och algoritmer för små eller stora laster. Linux hade fram till något år sedan sedan maximalt 8-socket servrar, vilket är små laster. Det fanns inte behov för stora laster på Linux. Solaris har länge haft 64 socket servrar. För decennier sedan fanns det även 144 socket server. Det blir en helt annan design på operativsystemet när man måste förbereda sig för såna enorma laster. T.ex. Solaris minneshantering skrevs nyss om för att hantera 64 TB RAM på ett effektivt sätt, nu skalar Solaris till flera 100 TB. Den största Linux servern har väl 6 TB RAM? Nu pratar jag en stor fet scale-up server, och inga stora kluster som SGI UV2000. Om det fanns krav på Linux att hantera 64 TB RAM i en enda stor scale-up server, skulle även Linux tvingas skriva om sin minneshantering.

Det är väl först nyligen som Linux hanterade over commitment utav RAM lite bättre? När Linux startar en process så lovar Linux bort allt RAM som processen begär - även om RAM inte räcker till. Och sedan när RAM tar slut, började förrut Linux döda processer på måfå för att frigöra RAM. Jag vet inte om Linux kunde t.om döda init processen, eller databasen eller affärssystemet? Detta är bara ett av skälen att Unix sysadmins säger att Linux är instabilt. (Solaris lovar inte bort mer RAM till en process, än vad som finns i servern).
http://unix.stackexchange.com/questions/153585/how-oom-killer...
http://opsmonkey.blogspot.se/2007/01/linux-memory-overcommit....

Facebook har många små x86 servrar för skale-out kluster laster, så då passar Linux utmärkt. Om facebook istället hade en last som kan bara köras på enda server, dvs scale-up, så måste du gå till 32 eller 64-socket servrar. Och då funkar inte Linux längre.

Men i Facebook artikeln jag länkade till är det flera kommentarer som säger att FreeBSD stacken är överlägsen Linux, och tydligen sker mycket nätverksforskning på FreeBSD just av detta skäl. Speciellt som artikeln handlar om att facebook vill öka Linux prestandan till samma nivå som FreeBSD. Har för mig att några kommentarer säger att Solaris stack är snabbast när det gäller massiv genomströmning. Här verkar det vara folk som kör Solaris på nätverksswitchar, apropås att folk använder Linux till olika nätverkssaker.
http://www.tomsitpro.com/articles/server-switch-pluribus-hype...

Inte jag heller har sett någon sådan cpu. Så vad är det jag ska bevisa? Att jag inte känner till några sådana cpuer? Eller att IBM övergav vägen med en enda högt klockad cpu, trots att IBM länge pratade om att det enda rätta är "en enda stark högt klockad kärna är bättre för databaser än flera svagare kärnor"? Att IBM ändrade från att skruva upp GHz till att följa i SPARCs fotspår och skruva upp antalet kärnor istället? Jag tror du inte riktigt hänger med i diskussionen.

Men jag har ju precis förklarat varför du tänker fel? Det handlar om wattantalet sade jag ju. Du kan inte ta en kärna som presterar på nivå X och drar 50 Watt, och sen säga att 60 kärnor måste då prestera 60 X och helt negligera att en sådan cpu skulle dra 3000 watt. Du bör hålla dig inom 150 Watt för en Xeon, vilket verkar vara vad alla Intels Xeon cpuer drar eftersom de sitter i småservrar. SPARC och POWER bör hålla sig inom... 250(?) watt eftersom de sitter i stora affärsservrar som kostar miljoner, med helt annan uppbyggnad, vattenkylning och gud vet vad.

Så återigen, du kan inte resonera så som du gör, det är logiskt fel.
-En 5930K med 6-cores drar 150 watt. Om du drar ihop 3 stycken såna här cpuer så får du 18 cores och 350 Watt.
-En 18 core Xeon E5 2699v3 du pratar om, drar också 150 watt.

Wattantalet stämmer inte. Rimligtvis är kärnorna i E5 2699v3 en tredjedel så klena som kärnorna i 5930K, eftersom de har en tredjedel så mycket kräm som kan driva kärnorna.

Som sagt, det enklaste är att du visar en benchmark på en single x86 cpu som presterar 700 gflops. Det är en väldigt hög siffra, och om det vore sant, så skulle nog Intel skryta om det och visa den siffran på alla slides som finns. Men Intel säger inget om det. Den höga siffran har jag bara hört från dig, när du slår samman två cpuer och drar slutsatsen att en ensam cpu är så snabb.

Så du hittar ingen Xeon general purpose cpu som kommer över 400 gflops i benchmarks? Jag hade en lång diskussion med en snubbe som trodde på fullaste allvar att en GPU kunde ersätta en CPU. En Xeon Phi är inte en general purpose cpu som kan driva en affärsserver, det tror jag även du inser.

Jag föreslår fortfarande att du slutar påstå att x86 når över 400 gflops, eftersom du inte kan visa benchmarks på det.

Jag håller med om att varken Oracle SPARC M7 eller Fujitsu SPARC XIfx är lanserade än, och därför är det orättvist att jämföra befintliga cpuer med kommande. Du har helt rätt där. Det kan mycket väl vara så att x86 är bland de snabbare cpuerna idag.

Min poäng är dock att när du säger att x86 är den snabbaste och bästa arkitekturen ("ingen som kommer i närheten av x86 IPC", etc) så kanske det inte stämmer? Intels nya cpuer är typ 10% snabbare för varje generation trots överlägsen IPC. SPARC är 100% snabbare för varje generation trots en dålig IPC. Fortsätter det så här så är SPARC klart snabbast snart. Men vänta nu, snart kommer M7 och XIfx, och då blir SPARC flera ggr snabbare än allt annat. Och sen kommer M8 året efter och Fujitsus nästa cpuer. Intel har inte mycket att komma med. Vilket är märkligt. Med en överlägsen IPC borde ju x86 vara överlägsen än allt annat på marknaden? Eller, kan det vara så att IPC inte är det viktigaste för prestandan, det kanske krävs massa annat också? SPARC har saker som den är bra på, annars skulle de cpuerna inte vara så snabba.

Däremot ser AMDs nya Zen cpu att vara ett monster som kanske kan matcha SPARC. När den har en inbyggd beräkningsdel APU som ger 4000 gflops, och med 100 GB/sek, så är den inte att leka med. Då ligger SPARC XIfx i lä, och Xeon Phi. Det är intressant att XIfx ligger på 1100 gflops utan en inbyggd beräkningsdel. Jag tror inbyggda APUer är framtiden. AMD har en guldsits där. Nvidia kan inte tillverka x86 cpuer. Det är bara Intel och AMD som kan det. Och AMD har överlägset kunnande i grafikkretsar, så framtida AMD cpuer med inbyggd APU kommer vara överlägsna Intels cpuer eftersom Intel inte kan så mycket om grafikkretsar. Framtida AMD cpuer kommer vara homogena, både CPU och APU kan köra data lite varstans ifrån i minnet. Idag kan CPUn bara köra data från visst RAM, och GPUn från annat RAM. Men i framtiden kan du mixa, och APUn kan obehindrat komma åt och köra datat från vilket RAM som helst.
http://www.fudzilla.com/news/processors/38402-amd-s-coherent-...

Något jag reagerade väldigt starkt på, är dock följande om Skylake. NSA har fått en gräddfil in till våra datorer, som inte går att undvika. Man måste köra open source cpuer, som MIPS eller nåt annat som Richard Stallman gör. När RMS surfar, så skriver han in en websida som ett program laddar ned som text, och websidan mailas till RMS konto. Alla tyckte han är extremt nojig, men kanske är han inte helt korkad?

Hmm... Jag tror inte min poäng var tillräckligt tydlig. Jag försöker förklara igen, så ska vi se om jag fortfarande är otydlig.

IBM har länge påstått att enda sättet att göra hög presterande cpuer är att använda 1-2 starka kärnor på hög klockfrekvens. Och att Sun/Oracles sätt med många klenare kärnor är helt fel väg att gå, eftesrom databaser körs bäst på starka kärnor/cpuer med hög klockfrekvens. IBM menar alltså att det är bättre att använda få starka cpuer än många klenare - pga databaser. Därför gjorde IBM sina dual core POWER6 cpuer på 5GHz och däromkring, och hånade SPARC Niagara med många klenare kärnor. På den tiden var det helt galet att ha 8 cores i en cpu, vilket SPARC hade. Idag har alla det.

IBM: 1-2 uberstarka cores är bäst, SPARCs många svagare cores är skit.
SPARC: många klenare cores är bäst.

Om nu IBM hade rätt, dvs att single-dual core starka cpuer är enda sättet att göra bra cpuer istället för många klenare cores vilket är helt värdelöst - varför är då POWER8 mer lik en SPARC M6 med 12-cores? POWER8 har också 12-cores. POWER8 borde väl rimligen ha 1-2 cores kring 8-10 GHz, eftersom IBM påstod att sådan design är överlägsen SPARCs design (dvs många klenare cores än en enda stark core).

När man tittar på IBMs nya cpuer, så har de faktiskt många klenare cores. Precis den vägen som SPARC slog in på för decennier sedan. Så min poäng är att IBM trash talkar sina konkurrenter, och sen när IBM gör exakt samma sak långt senare - så är IBMs design helt plötsligt det bästa som finns. Så, mao, man kan inte lita på vad IBM säger. IBM var ju faktiskt först med att FUDa i systematisk skala, utav alla företag:
https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Def...

Förrut pratade IBM mycket om hur snabba deras cpuer var, POWER7 var så snabb och IBM postade benchmarks över hela internet och skröt om hur viktigt det är med höga prestanda. Nu när Oracle köpte upp Sun och storsatsar på SPARC och är snabbast i världen, så vad säger IBM då när Oracle posta benchmarks överallt? "Prestanda är inte så viktigt, vi förstår inte varför Oracle pratar om höga prestanda, eftesrom ingen kund bryr sig om höga prestanda. Prata om höga prestanda är så 2000-tal och helt omodernt idag". Så höga prestanda är viktigt när IBM har rekordet, och när någon annan tar kronan så är prestanda helt oviktigt? Eh? Låt mig gissa, om IBM skulle få tillbaka prestandakronan (svårt när Oracle ökar 100% varje generation och IBM och Intel ökar 20% varje generation) så skulle prestanda helt plötsligt bli det viktigaste igen.

http://blogs.wsj.com/digits/2013/03/27/ibm-fires-back-at-orac...
"[Oracle SPARC high performance] was a frozen-in-time discussion,” Parris said in an interview Wednesday. “It was like 2002–not at all in tune with the market today." Companies today, Parris argued, have different priorities than the raw speed of chips."