Inlägg

Microsoft tog Java, och ändrade lite grand på det så att det bara kunde köras på Windows. Detta språk kallades J#. Sun gillade inte detta utan stämde MS, eftersom tanken med Java är att det ska vara plattformsoberoende. MS drog tillbaka sitt J# språk. Något år senare släppte MS sitt nya språk som hette C#. När man tittade på tidig C# och Java kod kunde man knappt se skillnad, de var så otroligt lika. Det var tydligt att C# var en Java kopia. T.ex. kunde man fråga sig, varför körde C# en virtuell maskin i botten precis som Java, när C# var tydligt låst till Windows då? På den tiden var ju den virtuella maskinen kass och hade många problem, bla. prestandaproblem. Det enklaste hade ju varit att skapa en Windows exe fil, istället för att köra på en långsam .NET virtuell maskin. Några år senare divergerade C# och blev mer och mer olikt Java.

Jag borde vara tydlig med att jag pratade stora affärsservrar, inte stora kluster. På stora affärsservrar som väger ett ton med 16 eller t.om 32 cpuer, så var det uteslutande Unix där såsom SPARC/POWER risc cpuer. x86 fanns inte där. Först nu, för några månader sen har de första stora affärsservrarna baserade på x86 släppts, men de är fortfarande förhållandesvis små i jämförelse mot Unix servrar. Dessutom kör dessa x86 affärsservrar, klustrade arbetslaster, såsom SAP Hana och andra in memory databaser gjorda för analyser och inte persistent lagring. Så man kan säga att de inte är riktiga affärsservrar, utan används för klustrade arbeten, precis som ett kluster.

-Stora kluster har 100.000 tals cpuer. Oftast används Xeon här, finns lite SPARC och POWER.
-Affärsservers är en enda stor server som väger ett ton och har 16 eller 32 cpuer och i denna domän är det uteslutande Unix och IBM stordatorer som används. Och dessa affärsservrar är svindyra, mycket mycket dyrare än ett stort kluster. T.ex. en 32-cpu IBM POWER6 server som hette P595 kostade $35 miljoner listpris. Du kunde fått ett mycket stort x86 kluster för en kvarts miljard SEK.

Jag håller inte med. Din lilla kod behöver inte alls vara representativ för riktiga beräkningar, vilket du påstår. Det finns andra tecken på att en E5-2699v3 inte alls når 800 gflops i praktiken:

1) Din kod får väldigt höga värden, runt 800 gflops på en E5-2699v3. Men i verkliga beräkningsbenchmarks såsom SPEC2006 får en E5-2699v3 inte vidare högt, den ligger ungefär som en POWER8. Och vi vet att en POWER8 har 400 gflops.

2) Det finns flera sajter där de pratar om E5-2699v3 beräkningskapacitet och det är inte alls högt, t.ex. sajten där det pratas om att i verkligheten kommer Amdahls lag in, så en E5-2699v3 ligger på 241 gflops i bästa fall i teoretin när vi säger att 95% av koden kan parallelliseras (din kodsnutt tar inte hänsyn till Amdahls lag). På en annan sajt diskuterade några ingenjörer som jobbade med tekniska beräkningar , och de sade att alla vektorinstruktioner inte kan användas i varje steg utan de används bara i något enstaka steg, så i praktiken blir det ganska låga gflops värden för en E5-2699v3 när man tittar på helheten.

3) Det finns inga benchmarks på 800 gflops ute. Alla benchmarks som finns ute på nätet ligger kring 400 gflops.

4) En professor i vetenskapliga beräkningar, Torben Larsen vid Aalborgs universitet, visade en graf över x86 beräkningsförmåga ökar över tiden, och den slutade år 2010(?). När man extrapolerar och drar ut linjen i samma riktning de senaste 20 åren, så slutar linjen år 2015 på... gissa. Just det, 400 gflops. Linjen är nästan spikrak hela tiden, över 20 år. Varför skulle linjen ta stora skutt år 2015?

5) Jag finner det svårt att tro att en 150 watt Xeon är dubbelt så snabb som en POWER8 på 250 watt som ligger på 400 gflops.

6) Eftersom du inte vet något om vetenskapliga beräkningar, så är chansen stor att du missar något viktigt. Det skulle inte förvåna mig att ifall någon som jobbar med sånt här tittade på din kod och skulle säga "Men jisses så här kan du inte göra, i verkligheten måste du tänka på X och Y, och då blir koden så här istället:"

Mao, det finns INGENTING där ute som säger att du har rätt. På hela stora vida internet finns inga som helst stöd för dina påståenden om E5-2699v3s beräkningsförmåga. Däremot finns det flera tecken som säger att det ligger kring 400 gflops. Det enda på nätet som säger att E5-2699v3 når 800 gflops, är du. Återigen, eftersom du nu hävdar det så tvärsäkert, kanske du borde backa upp det påståendet med en enda länk? Om du hade rätt, så kanske det borde krylla med den informationen på nätet? Men det gör det inte. Varför? Du kanske har fel? Eller är det alla andra som har fel?

När jag däremot postat länkar som stödjer mig och mitt påstående om 400 gflops, så avfärdar du samtliga länkar som mindre vetande, och du vet tydligen mera än dessa som jobbar med tekniska beräkningar, är detta inte lite märklig debatteknik?
Yoshman: "...Du har Googlat, bra men beräkningen du hittade är gjord av någon som inte alls förstår vad "base-clock" är och hur "turbo boost" fungerar...."
Yoshman: "...Den tekniska diskussion du läste måste ha involverat folk som inte riktigt kan sin numme..."

Det här låter precis som vår tidigare diskussion om när jag gång på gång, frågade hur du kunde tro att en SGI UV2000 är en scale-up server, och jag spaltade upp flera frågor enligt ovan, och bad dig posta en enda länk som stödde ditt påstående - vilket du aldrig någonsin gjorde, och ändå framhärdade du gång på gång på gång på gång att UV2000 är en scale-up server. Precis som ovan. Jag förstår inte hur du gång på gång, kan vara så envis om något du inte har en susning om. Du hittar på något som inte stämmer, och håller fast vid det benhårt. Och när jag ber om länkar, så postar du aldrig något. När jag däremot postar länkar som visar varför du har fel, avfärdar du alla dem som mindre vetande. Ja, exakt samma debatteknik som du uppvisar här ovan. Gång på gång under alla dessa åren om alla olika saker. Det känns inte vidare seriöst om du frågar mig. Känns nästan som ett Troll skulle kunna göra så här. Det vore seriöst om du ifrågasatte ditt påstående och beaktade alla benchmarks och länkar:
-Ja, jag kan tyvärr inte hitta några länkar som stödjer mitt påstående, och jag har läst alla dina benchmarks och länkar som säger motsatsen. Enligt den vetenskapliga metoden måste jag nu börja tvivla på mitt påstående, jag ska sluta säga så tills jag vet mera om saken. Och om jag har fel, så ändrar jag ståndpunkt. Men om jag har rätt, så kommer jag posta länkar som visar att jag har rätt, och då måste de andra ändra ståndpunkt!

Yoshmans debatteknik sedan många år:
-Jag kan inte posta några som helst länkar som stödjer mitt påstående, du måste tro mig på mitt ord. Du vägrar tro mig, trots att jag förklarat med alla tekniska detaljer varför jag har rätt. Och alla dina länkar är ju helt värdelösa, de kan ju tydligen ingenting om ämnet, jag kan mera om detta ämne som jag inte har en susning om. Och jag förstår att detta kan uppfattas som Trollande, men det är inget Trollande. Jag är en seriös debattör, det är bara det att jag inte håller mig till den vetenskapliga metoden där jag avfärdar alla benchmarks och länkar, jag är istället subjektiv för att jag inte behärskar ämnet, men jag har ändå väldigt starka åsikter och vet att jag har rätt. Trots att ingenting på nätet stödjer mitt påstående.

Det glädjer mig att du har i alla fall koll på grunderna, det är inte alla som har det. Det är väl därför du kan säga till mig om parallell algoritmteori: "...Nu pratar du om saker du uppenbarligen har väldigt dålig koll på...."

Jag läste artiklar som sade att eftersom Linux inte skalar vidare högt (alla linux utvecklare sitter på sina desktops med 1-2 cpuer) så behöver inte Linux använda komplicerade metoder som skalar till 32 sockets, 512 tals kärnor och 4096 trådar som M7-16 har. Det vore helt onödigt att lägga in komplicerad kod för sånt när inga såna Linux servrar finns. Därför används simpla metoder i t.ex. Linux schemaläggare som har bra konstanter för få cpuer. Och vem skulle lägga in sådan kod, alla kernel utvecklare sitter på 1-2 sockets. Det räcker fint med simpla metoder som är snabbare på småservrar. Låter detta resonemang helt orimligt tycker du? Att det är helt ute i det blå? Du påstår att linux är optimerat för stora 32-socket servrar?

Här påstår du att det är fullt möjligt att parallellisera kod, men det är fel generellt. Du har inte läst så mycket teori säger du och det förstår jag, men det finns något som heter P-fullständiga problem, och de kan inte parallelliseras så det hjälper inte att ta in flera cpu-kärnor. De kan bara köras på en enda cpu-kärna oavsett hur mycket du försöker.
http://pages.cs.wisc.edu/~tvrdik/4/html/Section4.html

Jag tror det är bättre att du först håller dig till hela bilden, än att gå ner på detaljnivå. Om du inte fått rätt på helhetsperspektivet i första hand, så varför gå vidare ned till detaljnivå?

Jo det har du. Vi har många gånger haft just den diskussionen under flera års tid. Du har hårdnackat avfärdat alla mina länkar som visat att Linux har seriösa skalningsproblem och du har avfärdat alla mina listor med frågor, och du har påstått att SGI UV2000 är en scale-up maskin, och att Linux kan göra allt som Unix kan. Du har refererat till top500 och att Linux skalar bra där. Och när jag bett dig visa länkar om att UV2000 kan ersätta stora Unix servrar har du aldrig gjort det. Det här låter som när du nekade till att blandat in Xeon Phi, vilket du gjorde.
Yoshman: "...Har inte blandat in GPUer eller Xeon Phi, men är ju samma princip där...."
#15772862

Dessa SGI linux "scale up" servrar UV300H med upp till 32-sockets som är certifierade för SAP HANA databasen, är certifierade för att köra analyser på HANA read only minnesdatabasen. HANA är en klustrad databas, så UV300H är alltså certifierad för att köra klustrade scale-out dataanalyser. Och till klustrade arbetslaster funkar Linux mycket bra för. Däremot är inte dessa SGI "scale-up" servrar certifierade att köra riktiga scale-up datalaster, som t.ex. stora databaser eller SAP. Det kommer väl, men undrar hur bra de är. Idag kallas de "scale-up" servrar, återstår att se om de är det i praktiken också. Kan de t.ex. köra SAP väl? Den största 8-socket E7v3 servern får 320.000 saps. HP Kraken Superdome 16-socket E7 server får 460.000 saps. Så vad får då en 32-socket SGI UV300H? 560.000? Ju högre upp man går, desto sämre skalar SAP, därför att det är en scale-up last, och scale-up laster skalar dåligt per definition. Fujitsus 32-socket M10-4S SPARC får 844.000 saps. Det ser ut som att 32-socket Unix skalar hyfsat i alla fall.

Däremot undrar jag varför inte SGI försöker certifiera UV2000 för SAP Hana? UV2000 är ju i praktiken ett kluster, så SAP Hana borde funka hyfsat?

Inte många linux utvecklare har det.

Jag ser helst benchmarks, visst låter det bra det du säger. Men vi vet att teori är en sak och praktik en annan. T.ex om vi pratar serverlaster, så vet vi att x86 inte är vidare bra på serverlaster, eftersom x86 är designad att jobba främst ifrån cache och inte mot RAM som SPARC/POWER är (därför de har stor RAM bandbredd). Så hur bra är då Linux som kör ovanpå x86 på just detta? Vet inte. Men jag blir inte förvånad om man stöter på problem när man går till stora servrar, och går förbi 4-8 sockets. Det är sällan en design funkar lika bra för stora servrar, skalningsproblem du vet.

Varför kör majoriteten av alla datorer Windows? För att Windows är bäst? Varför kör majoriteten av alla servrar Linux och Windows, när vi vet att Solaris/AIX är bättre server OS? Varför vann VHS när Betamax var bättre? Bara för att en miljon flugor äter bajs, så betyder det inte att bajs är gott. Att många kör Linux eller Windows bevisar inte att det är bäst.

Ok, så du menar att för IPv6 så är BSD bättre än Linux? Ja, med tanke på att IPv4 adresserna är slut så är det kanske viktigt att FB fokuserar på IPv6 som är framtiden. När man läser lite på nätet säger folk att BSD har bättre stack än Linux. Mycket av forskningen sker på BSD, etc etc. Men då verkar vi överens om att BSD har en bättre IPv6 stack än Linux.

OpenIndiana är en alfa version av Solaris 11. Antagligen är det samma stack som i Solaris 11. Jag har inte koll på koden, men det är ett faktum att Solaris 11 har en stack som körs på stora servrar. Skalbarhet betyder att något går att lasta på mer och mer, om det tar stopp i förtid så skalar den inte. Mao, Solaris 11 stacken går upp till 32-sockets och förbi. Vi vet inte om Linux stack skalar så högt, eftersom det inte funnits så stora Linux servrar tidigare. Mao, det är rimligt att tro att Linux stacken råkar på problem när man provar det på stora servrar. Jag tror du är medveten om att när man provar någon arbetslast med 10x så mycket arbete så ser man nya problem man inte sett tidigare - det är aldrig problemfritt att prova 10x större last. Så vi vet att Solaris 11 skalar väl till 32 sockets och förbi (faktum är att Solaris ser varje tråd som en cpu, dvs 4096 cpuer ser Solaris) men vi vet inte om Linux skalar väl till 32-sockets. Min välgrundade gissning är: nej eftersom det är svårt att skala.

Varför vann VHS över betamax? Ibland kommer företagen överens om att stödja en produkt över en annan. T.ex. på mitt stora företag jag jobbade på förrut, fick en order från högsta ort att sluta köpa Sun hårdvara. Och det här var flera år innan Sun fick problem. Jag pratade med andra företag, samma sak där. Sen fick vi order att även sluta köpa HP hårdvara. Samma på andra företag. Jag vet inte hur styrelsen fattar sina beslut, men de gör det inte alltid på tekniska grunder, utan på affärsmässiga grunder. Återigen, bara för att något växer så betyder det inte att det är TEKNISKT bäst. Det kanske är bäst på andra grunder, mest lättanvänt, lättast kod, etc. Men vad styrelserna beslutar sig för och vad som är tekniskt bäst - korrelerar inte alltid.

Om du hade sagt detta, så hade vi varit överens. Jag skrev för flera år sen, att Linux skalade väl i kluster, men inte alls som scale-up smp servrar. Och jag postade länkar som visade att Linux hade skalningsproblem på bl.a. I/O, det var antagligen genom mina länkar du förstod att Linux hade I/O skalningsproblem. Men ändå skrev du inlägg efter inlägg efter inlägg med invändningar och avfärdade alla mina länkar om att Linux hade skalningsproblem på stora SMP scale-up servrar. Jag har googlat lite efter våra diskussioner och hittar inga längre, eftersom den sajten raderat alla diskussionsforum. Men jag kommer ihåg att just du, och jag hade ändlösa debatter, precis som här, om Linux skalbarhet. Du envisades och envisades och envisades och visade aldrig länkar själv. Jag postade massor av länkar, som du genast avfärdade. Din debatteknik har inte ändrats något idag. Det enda som ändrats idag, är att du säger "nehej, så där sade jag aldrig om Linux skalbarhet" - vilket du visst gjorde. Jag tycker det är väldigt fult gjort av dig. Du verkar ha lite problem att ändra ståndpunkt, oavsett hur många benchmarks eller länkar man postar. Jag önskar du kunde säga "ja, jag hade fel och du hade rätt. Jag har ändrat ståndpunkt i denna fråga som vi debatterade i tråd efter tråd under alla åren". Jag har inte så taskigt minne att jag hittat på alla dessa diskussioner, jag ägnade timmar och timmar åt att googla och skriva inlägg efter inlägg för att bevisa för dig att Linux hade skalningsproblem. T.ex. frågade jag dig, "om nu Linux skalar så bra som du påstår, varför har inte Solaris/AIX dött ut? SPARC/POWER är svindyra, varför finns den marknaden kvar, om nu billiga Linuxservrar kan ersätta SPARC/POWERs arbete?" etc etc. Jag spaltade upp listor med frågor 1) 2) etc och postade jättemånga länkar. Jag tycker det är riktigt fult av dig att neka. Be för att alla gamla diskussioner inte kommer tillbaka på nätet så jag kan bevisa att du ljuger i denna fråga. Riktiga Trollfasoner du visar just nu.

Nu förstår jag inte riktigt vad du menar. Jag menar att man ska vara kritisk mot företags marknadsföring och istället kräva bevis såsom t.ex. benchmarks o dyl. Du gör inte detta, du följer inte den vetenskapliga metoden att kräva trovärdiga bevis, vilket du visat under alla åren. T.ex. har du krävt att jag ska tro dig om 800 gflops, trots att jag postat flera länkar och benchmarks som alla ligger på 400 gflops. Så jag vet inte alls vad du baserar din tro om 800 gflops på.

När jag läser Oracles och IBMs påståenden så struntar jag fullständigt i dem. Däremot tittar jag på benchmarks och andra länkar, gärna forskningsartiklar. Om nu Oracle påstår ZFS ger ett gott skydd, då läser jag de oberoende forskningsartiklarna innan jag tror Oracle. Faktum är att jag ibland har kritiserat Sun och Oracle för att de kommit med ett dåligt underbyggt påstående, på deras sajter.

Du har bevisligen avfärdat alla mina benchmarks och länkar i många många många trådar, och du har bevisligen kommit med starka och felaktiga påståenden som du erkänt att du inte är så insatt i många trådar. Så du följer bevisligen inte den vetenskapliga metoden, som går ut på att granska allt kritiskt. Så jag förstår inte alls vad du menar, insinuerar du att jag köper Oracles och Suns benchmarks rakt av och avfärdar IBM och Intels benchmarks? På samma sätt som när IBM postade massor med POWER7 benchmarks och jag gratulerade dem till att ha världens snabbaste cpu då? Jag avfärdade inte IBMs benchmarks, jag accepterade dem. Det verkar som att du menar att det är du som följer den vetenskapliga metoden, och inte jag?

Återigen, din lilla kodsnutt bevisar inte att E5-2699v3 når 800 gflops i verkliga laster. Det är ett tillrättalagt stycke kod med t.ex. 100% parallellisering vilket inte riktiga laster kan göra. Jag vill alltså återigen, be dig posta några riktiga benchmarks som uppnår ca 800 gflops, t.ex. SPEC2006, Linpack, Lapack, etc. När vi pratar riktiga benchmarks som massa branschmänniskor skrivit ihop tillsammans, så är de mer trovärdiga än lite kod som du skrivit. Chansen är stor att du missat en viktig aspekt. Om nu 800 gflops är sant, så borde det krylla av benchmarks ute på nätet? Om det är sant att Nvidia 980 GTX når 200 fps i Battlefield4 ultra inställningar 4K upplösning, så borde det finnas flera benchmarks på nätet och flera borde prata om det på forumen. Om å andra sidan man bara ser 30 fps benchmarks, och alla pratar i forumen att de bara når 30 fps - så kanske siffran 200 fps är fel? Det är som att du skrivit lite kod som ritar en triangel och når 200 fps och ber mig tro din slutsats att Battlefield 4 når 200 fps, eftersom din triangel gör det. Ett riktigt spel har AI att ta hänsyn till, Fysikmotor, tesselering, etc etc etc. Återigen, lite tillrättalagd kod betyder ingenting. Ritkiga benchmarks är mer trovärdiga. Vad litar du mest på, en triangel som snurrar på skärmen, som jag skrivit - eller 3DMARK benchmarks?

På samma sätt är ett officiellt granskat STREAM benchmark mer trovärdigt än lite minneskod som jag själv skriver ihop - det ska man inte lita på. Vet inte hur många gånger jag sagt det, men du kan inte bencha äpplen och dra slutsatser om päron.

"Humor igen, har ju precis bevisat att min triangel snurrar 200 fps, alltså når man 200 fps i BF4 också"

När man går ned på detaljer som du och och min aspberger kompis gör, så är det lätt hänt att missa helheten. Och allt måste stämma för att det ska vara trovärdigt. Det duger inte att maniskt upprepa siffran 800 gflops när allting på nätet säger 400 gflops. Då är det något som inte stämmer - och då är det läge att omvärdera sin ståndpunkt som varje god tränad vetenskapsman gör, man kräver in nya bevis som man inte sett tidigare, och granskar dem och fattar ett beslut efter moget övervägande. Att hålla fast vid sin ståndpunkt trots att allting pekar på motsatsen - vad är det? Ja då har man en dogmatisk världsbild som man hade på medeltiden. "Det är sant för att jag säger så, jag skiter i allting som säger motsatsen".

På samma sätt, om du faktiskt kunde presentera benchmarks om 800 gflops, och presentera benchmarks att E5-2699v3 är dubbelt så snabb som POWER8 (som når 400 gflops) i alla andra beräkningsbenchmarks - så kommer självklart JAG att ändra ståndpunkt och gratulera Intel. Men fram till dess vill jag ha bevis på ditt orimliga påstående, ditt ord räcker inte oavsett hur mycket du tjatar.

Ja, efter att du invänt på flera olika sätt mot Hadoop benchmarken så är det ju rimligt att ditt nästa steg att invalidera ALLA benchmarks i ett enda grandiost slag. Jag förstår att du desperat inte vill acceptera något SPARC M7 benchmark alls, för då rubbas din världsbild om att x86 är snabbast i världen. BTW, Oracle har släppt ytterligare ett nytt M7 benchmark idag, och det är också 2-3x snabbare än POWER8 och x86 - det är att köra många virtuella maskiner, SPECvirt_sc2013. Så vi ser att det är ett ganska brett spektra som SPARC M7 är snabb på, inte en "liten nisch".

Det lustiga är att om Intel verkligen skulle släppa en x86 cpu som var snabbare än SPARC M7 och Oracle, skulle du propsa på att jag måste acceptera Intels alla benchmarks, och hur viktiga benchmarks är. Skulle inte förvåna mig alls, om du i andra trådar postar mängder med benchmarks och berättar hur viktigt det är att använda granskade benchmarks gjorda av branschmänniskor. Bara inte i denna tråd, eftersom fel cpu är snabbare.

Jag förstår inte riktigt vad problemet är? Varför kan du inte acceptera att M7 som har dubbelt av allting: dubbelt så många transistorer, dubbelt så hög Hz, dubbelt så många cores, tio gånger så många trådar, etc etc och dessutom postat över 20 dubbelt så snabba benchmarks i vitt skilda områden, faktiskt kanske är snabbare än en x86 cpu? Det är nästan något maniskt över beteendet du uppvisar? Du vägrar och kämpar och kämpar och envisas och envisas. Och detta beteende har du uppvisat i tråd efter tråd i år efter år - mot mig. Alltid avfärdat alla mina benchmarks och länkar och aldrig postat några benchmarks själv (men du postar alltid en detaljerad förklaring till varför alla mina länkar är felaktiga). Varför kan du inte bara säga "Grattis, M7 är snabbast just nu. Nu går vi vidare till nästa generation Intel cpuer och kollar vad resultatet blir då". Vad är problemet med detta? Om Intel släpper sin nya cpu som är dubbelt så snabb som M7 kommer jag självklart gratulera Intel och säga till folk som tror SPARC/POWER är snabbast "nja, du har fel, faktum är att Intel är faktiskt snabbast just nu, nästa generation kanske det är annorlunda men nu vinner Intel. Kolla dessa benchmarks så kan du själv se". Rätt ska vara rätt. Jag vill inte sprida felaktig information - det vore ju att sprida FUD och att Trolla.

MichaelJackson: "....Du säger att SPARC M7 är snabbare på vissa specialfall, och därför är den inte snabbare än x86...."

Men du hävdar ju att M7 är snabbare endast på vissa nischade saker. I alla andra fall är x86 snabbare, mao M7 är inte snabbare än x86 rent generellt, därför borde rubriken bytas. Så du hävdar väl att M7 inte är snabbare än x86 - rent generellt? Eller har jag missuppfattat dig? Så du har sagt det andra jag skriver?

Återigen, ett officiellt benchmark gjort av branschfolk mäter mycket mera än en liten del, och är mer representativt för riktigt arbete - än en kodsnutt som du skrivit. Du hävdar att din lilla kodsnutt är representativ för riktiga beräkningslaster "vad är skillnaden mellan min kod och en riktig beräkninsbenchmark - jag ser ingen skillnad". Om du nu hade rätt, så borde alla beräkningsbenchmarks såsom gflops visa samma siffra som din kod: dvs 800 gflops. Men tvärtom visar de alla 400 gflops. Så det kanske är viss skillnad i din kod mot en större beräkningsbenchmark? Du säger ju att du inte ser någon skillnad, men det blir ju olika gflops resultat. Vad kan skillnaden bero på? Antingen har du fel, eller så har alla andra fel. Men du är fortfarande övertygad om att din kodsnutt är representativ för riktiga beräkningslaster, så 800 gflops är realistiskt att uppnå i verkligheten?

Saken är den, att ifall du hade rätt om 800 gflops, så borde det finnas såna resultat ute på nätet. Men det gör det inte. Så något är fel om 800 gflops.

Å andra sidan vet vi att SPARC M7 har enorm minnesbandbredd, så då borde det märkas i benchmarks där man hela tiden går ut mot RAM (och inte jobbar mot cachen) - dvs på alla serverlaster borde M7 få bra resultat. Vilket är sant. Så något är inte fel. Detta stämmer.

Den officiella STREAM benchmarken säger att M7 har bra bandbredd, så den borde få bra server last resultat - sant. Din kodsnutt säger att E5-2699v3 borde få ~800 gflops - ingenting på nätet stödjer detta. Så antagligen är det falskt. Det ser ut som att en officiell benchmark är korrektare proxy för det benchmarken mäter, än en benchmark du gjort. Håller du med om att din egen gflops benchmark långt ifrån överenstämmer med verkligheten, medan STREAM benchmarken indikerar något som faktiskt överensstämmer med verkligheten - att M7 är bra på serverlaster?

Jag förstår inte hur du riktigt vill få det till att din egen ihopsnickrade benchmark bevisar att E5-2699v3 når 800 gflops i verkliga beräkningslaster?

Försöker du hävda att IBM gör rätt när de adderar all bandbredd i chippet? Att det är en rättvisande siffra? Då borde väl IBMs POWER8 på 230GB/sek få ett bättre STREAM resultat än SPARC M7 på 160 GB/sek? Men det är tvärtom, M7 är dubbelt så snabb på STREAM bandbreddsbenchmark. Mao, det kanske är helt käpprakt fel att addera all bandbredd i chippet, därför att i praktiken så är POWER8 bandbredd hälften så snabb som M7? Mao, du kanske inte kan göra som IBM gör, därför att om IBM verkligen hade rätt, borde POWER8 vara snabbast. Mao, facit visar att IBM har fel. Så IBM har fel, och du har fel.

Så du ser inte varför du skulle flaggvifta för x86? Du ser dig inte själv som en manisk x86 fanboy som avfärdar alla benchmarks som visar att x86 är långsammare än konkurrenterna på något sätt? Nehepp. "Jovisst är SPARC T1 runt 50x snabbare men det betyder ingenting med tanke på att ..[detaljerad teknisk förklaring].. alltså är x86 snabbare!". Att du jobbar med ARM säger ingenting när ditt hjärta är hos x86. Det är ju inte så att du vill sprida korrekt information om x86 "grabbar, det ni säger stämmer inte, kolla på dessa benchmarks så får ni själva se varför ni har fel". Nej, det finns benchmarks som stödjer mig, men du lyssnar inte på dem. Så du är inte intresserad av att sprida korrekt information, nej, du vill bara tjafsa i all oändlighet med invändning efter invädning, i tråd efter tråd. År efter år. Och du har heller inga vettiga invändingar "ja, det är rättvist att plocka in diskreta extera kort när man benchar mot SPARC M7 eftersom M7 har DAX" - hur vettigt är det? Efter långt om länge har du slutat tjata om att plocka in diskreta externa kort - kanske för att du inte orkar mer, eller inser att det var inte vettigt det du sade. Eller så är det så att du bara väntar på att börja igen med detta.

Angående att hitta Intel benchmarks som visar enkeltrådsprestanda - varför skulle du göra det? Det vore ju menlöst - vi alla är överens om att Intel (antagligen) har bättre enkeltrådsprestanda. Det är inte där, vi är oense. Däremot skulle du nog bli fundersam om jag avfärdade alla enkeltrådsprestanda som att "men det betyder ingenting att Intel är 2x snabbare på enkeltrådsprestanda med tanke på att... jag avfärdar dina benchmarks". Nej, istället säger jag; "jag ser benchmarks att Intel är snabbare på enkeltråd och accepterar resultaten - grattis till det". Så jag accepterar Intel enkeltrådsprestanda benchmarks, men du vill inte acceptera några benchmarks alls om M7, ser det ut som. Du invänder mot M7 benchmarksen, ett efter ett, och när jag vederlägger alla dina felaktiga argument, så vill du slutligen invalidera alla benchmarks som företeelse. Men självklart, ifall x86 vore snabbare, så måste jag acceptera dina benchmarks för annars vore jag orättvis. Typ.

Jag försöker bemöta ditt tidigare argument:
"...Även i fall 2) [dvs där det handlar om att betjäna många klienter så att arbetsdatat inte får plats i cachen] finns det fall där Xeon vinner över de andra då den kretsen har mer cache-bandbredd samt mer flyttalskapacitet än även POWER8...."

Så jag ställer frågan igen: menar du det du skriver här ovan, att ifall x86 får jobba uteslutande mot cachen så kan x86 hålla jämna steg när det gäller att betjäna många klienter? Och vilka fall är det? Har du sett benchmarks eller nåt liknande, eller har du hittat på det?

Så du håller med om att SPARC/POWER kan betjäna fler klienter än x86 när working set inte får plats i cachen. Bra. Framsteg! Det tog bara typ sjuttio-elva inlägg innan jag fick dig hit.

Angående cachens två dimensioner såsom tidslokalitet, vad har det med saken att göra? När du betjänar många tusen olika klienter, så kommer cachen tömmas och fyllas gång på gång innan den kommer tillbaka till samma data någon gång i framtiden långt borta - men vad spelar det för roll? Så jag ser inte poängen med tidslokalitet. Men du får gärna förklara varför tidslokalitet är viktigt för en server, när den betjänar många tusen klienter och tömmer och fyller cachen många många gånger innan den kommer tillbaka till samma klient? Jag är alltid villig att lära och omvärdera mina tidigare ståndpunkter.

Det var många kunder som köpte SPARC T1, så den hade ett praktiskt värde inom sin nisch. Om den inte sålt bra, så hade Sun lagt ned SPARC coolthreads cpuerna och återgått till 2 starka cores med hög klockfrekvens som SPARC64 cpuerna Fujitsu gjorde.

(När vi pratar Xeon Phi, ARM med 100 kärnor, etc - så låter det ganska troligt att de bara kör klustrade laster och inga scale-up laster. Så jag förstår att man kör Linux på dessa cpuer, Linux skalar väl på klustrade laster.)

Tack för informationen, men du har inte förklarat hur jag har fel: "nej, nej, nej". En HFT algoritm kanske använder 20 beräkningssteg, så därför är det inte självklart att använda en 1 GHz ASIC eller FPGA jfrt mot en 4 GHz cpu - för cpun blir klar snabbare med 20 beräkningar än en ASIC eller FPGA.

Återigen, SPARC M7 är snabbare på tekniska beräkningar än x86, men x86 har bättre perf/watt än M7. T.ex. IBMs Blu Gene hade 750 MHz PowerPC cpuer, och de var klena men bra perf/watt. Och dessutom är x86 billigare, och det är viktigt när du köper in en kvarts miljon cpuer. Därför hittar vi x86 i superdatorerna, inte för att de är snabbast på beräkningar. Detta har vi diskuterat tidigare.

Här är det Fujitsus kommande superdator med 1000 Petaflop (som antagligen är uppbyggd på SPARC XIfx cpuer, eftersom deras K-superdator är uppbyggd på SPARC Venus). Om man skulle köpt 200.000 Geforce GTX 980 istället, så skulle de kostat 1 miljard kronor. Det är för dyrt, man måste hålla nere kostnaderna. Och strömmen.
http://www.nordichardware.se/Apple/flagship-2020-kan-bli-vaer...

MPI, jag försöker bara säga att jag gjort nummekurser med t.ex. MPI.

Jag förstår inte riktigt vad du försöker säga. Menar du att rent generellt, i alla vetenskapliga beräkningar som görs på stora grids, så är det exakt en enda multiplikation och en addition i varje cell och därför blir FMA så gott som 100% effektivt? Och därför når x86 uppemot 800 gflops? Öh? Jag förstår inte vad du försöker säga här. När man gör vetenskapliga beräkningar så behöver det inte vara en enda multiplikation och en enda addition i varje cell - det kan vara olika operationer i olika celler. Vissa komplexa operationer, vissa simpla.

(Och glesa matriser representeras oftast som en länkad lista, inte som en array om jag inte kommer ihåg fel nu)

Jag har googlat lite nu efter våra ändlösa debatter där du och andra påstod att SGI UV2000 kan användas för att ersätta stora Unix servrar - och alla kommentarer är borta eftersom siten raderat allt. Det har du antgaligen också gjort och sett att allt är borta, som tur för dig. Men jag vet, att jag ägnat många timmar år att googla efter länkar och benchmarks, och ställt upp listor med frågor 1) 2) etc åt dig, där jag ifrågasatt varför du tror att SGI UV2000 är en scale-up server. Och nu har jag inga bevis längre för dina scale-up påståenden. Men å andra sidan, jag tror inte någon skulle blivit förvånad om du verkligen gjort det; dvs envist framhärdat att UV2000 kan ersätta stora Unixservrar på alla laster, avfärdat mina länkar, etc etc - och aldrig ändrat ståndpunkt. Speciellt kommer jag ihåg en kommentar du skrev, som gjorde mig irriterad - och den kommer jag ihåg, du skrev nåt i stil med "Linux kan göra allt som Unix kan göra, därför är stora Unix servrar döda" - jag kommer inte ihåg exakta formuleringen. Jag kommer ihåg detta, bland alla andra av dina invändningar och avfärdanden.

Men det vore inte alls förvånande om det hela utspelade sig exakt som jag beskriver det. Däremot att du, skulle gått med på att x86 inte skalar bättre än SPARC/POWER utan några invändningar vore ju inte alls likt dig. Även här pratar du ju om hur Linux TCP/IP stack skalar bättre än Solaris stack, etc etc. Det vore inte konstigt om du kommit med invändning efter invändning och att du avfärdat alla mina länkar och benchmarks hur Solaris skalar bättre än Linux. Speciellt kommer jag ihåg när jag postade en länk från SGI där SGI skrev att SGI Altix inte kan användas för scale-up benchmarks:
http://www.realworldtech.com/sgi-interview/6/
"...The success of Altix systems in the high performance computing market are a very positive sign for both Linux and Itanium. Clearly, the popularity of large processor count Altix systems dispels any notions of whether Linux is a scalable OS for scientific applications. Linux is quite popular for HPC and will continue to remain so in the future,
...
However, scientific applications (HPC) have very different operating characteristics from commercial applications (SMP). Typically, much of the work in scientific code is done inside loops, whereas commercial applications, such as database or ERP software are far more branch intensive. This makes the memory hierarchy more important, particularly the latency to main memory. Whether Linux can scale well with a SMP workload is an open question. However, there is no doubt that with each passing month, the scalability in such environments will improve. Unfortunately, SGI has no plans to move into this SMP market, at this point in time..."

och på denna länk svarade du (jag kommer ihåg ditt argument) att den dära länken var gammal och för den gamla servern Altix, men att den nya Linux SGI UV2000 är helt annorlunda och skalar mycket bättre och kan följaktligen ersätta stora Unix servrar nu - så därför avfärdade du den dära SGI länken. På det svarade jag att UV2000 bygger vidare på Altix, så det är i grunden exakt samma maskin, bara en snabbare NUMAlink - men det kunde jag inte bevisa med länkar (vilka du antagligen även avfärdat också). Du skulle antagligen även avfärdat min nya länk. Denna konversation kommer jag ihåg. Både du och jag vet, att vi hade ändlösa debatter om just detta som du idag nekar till. Varför blir jag inte förvånad att du nekar idag. Inte riktigt shysst tycker jag. Det vore intressant om jag kunde få fram de gamla konversationerna och citera dig, så man släpar fram Trollet i solen och det spricker. Är det så farligt att säga att man har fel, och säga "ok, idag vet jag bättre, du hade rätt hela tiden"? Du har ju även insinuerat om annat forum där jag blivit motbevisad om att UV2000 inte alls är en scale-out server - att jag haft fel hela tiden om UV2000, att man visst kan använda UV2000 för scale-up. Men idag verkar du ju tro att UV2000 inte är en scale-up server - så jag hade rätt även på den andra websajten. De hade fel, och jag hade rätt hela tiden. UV2000 är inte en scale-up server. Kul att du ändrat uppfattning om SGI UV2000, det tog bara X antal år. Och hela tiden sa du att jag hade fel i post efter post. Lite märkligt beteende?

Även den servern används som UV300H, dvs för read only in memory analyser. Inte för att lagra data som en vanlig databas server för persistent lagring. Det verkar som att Linux hade skalningsproblem när man går till 16/32 sockets:
http://www.nextplatform.com/2015/10/26/sgi-targets-oracle-in-...
"...The trick with the UV 300-RL machines to run Oracle 12c as an in-memory database, as it turns out, is getting the underlying operating system to scale...."

Fint med din benchmark. Kan du nu köra en officiell benchmark typ linpack eller lapack eller SPEC2006? Som sagt, riktiga laster har andra problem än små kodsnuttar.

Öh.... Min specialisering på KTH var just algoritmer, du kanske hört talas om teoretisk datalogi? Din "åsikt" att algoritmers tidskomplexitet och systems skalbarhet över CPU kärnor i teorin är ortogonala var det... märkligaste jag hört på länge. Jag har läst en doktorandkurs i parallella algoritmer, och det var en av de svåraste matematikkurserna jag läst t.ex. skulle professorn bevisa Turans sats som han använde två st dubbeltimmar till. Vi var 30 studenter i början och på slutet var det jag och en till kvar, och fem stycken doktorander i matematik, resten hade hoppat av. Jag hittade en del svar till uppgifterna i hemtentorna, i forskningsartiklar utav en av världens bästa matematiker (ja, det är sant, han är antagligen bland de bästa i världen eftersom han har fått de tyngsta priserna, typ motsvarande Nobelpriset, fast i matematik). Jag lärde mig en hel del om parallell algoritmteori, som är mycket knepigare än vanlig algoritmteori men det finns mycket kvar att lära på forskarnivå. Det är kanske därför du säger att jag har väldigt dålig koll på just parallelll algoritmteori? Eller är det bara en del av din debatteknik att använda härskartekniker "det här kan du ingenting om lilla vän" i syfte att trycka ned den andre?

Det här påståendet får du gärna förklara mera. Hur skulle de vara ortogonala i teorin? På vilken teori baserar du den "åsikten"? Vilka satser? Var inte rädd för att vara för teoretisk, jag klarar av teori om just detta upp till forskarnivå.

Återigen, jag bryr mig inte direkt om vad alla säger har för häftiga tekniker i sin produkt. Problemet med det, är att ifall man lyssnar på dem och tror på dem, så glömmer man att de inte berättar vad som är dåligt med deras produkt. De kanske säger "ja, vår bilmotor går upp till 300km/h" men de berättar inte att bilens hjulupphängning klarar max 200km/h, så bilens maxhastighet blir 200km/h - oavsett vad motorn klarar av i teorin.

Om du skulle diskutera med IBM folk skulle de säkert komma med en lång teknisk förklaring till varför POWER8 är 50x snabbare än x86, ända upp till 1000x snabbare "ja, den har en inbyggd fluxkondensator som klarar av 1.21 gigawatt" etc etc etc.

På allt detta svarar jag som man bör: so what? Visa mig resultaten istället. AMD pratade om sitt HBM minne som är 9x snabbare än GDDR5 i Fiji XT R9 390X, men är grafikkortet 5x snabbare än Nvidias kort? Nej, Nvidia är snabbare. Men om du pratar med AMD folk skulle de säkert förklara hur mycket bättre HBM är och komma med långa tekniska förklaringar, men glömma berätta om alla dåliga saker i AMD kortet.

Det enda som är viktigt är praktiska resultat. I fallande ordning där 1) är mest trovärdigt.
1) Riktiga tester på IRL last
2) Benchmarks
3) Egen kod
4) Gissningar

När du pratar om hur bra teknik det finns i Linux, så bryr jag mig inte riktigt. Jag är van vid att prata med IBM folk om hur bra deras cpu är, när jag lyssnar på dem så är POWER8 det bästa sedan skivat bröd och 50x snabbare än x86. Men... är det sant? Nej. Du borde inte lita på marknadsföringssnack.

Så när du pratar om att Linux skalar bättre än Solaris därför att Linux har si eller så i sin kärna (detta har vi diskuterat många många gånger förr i många olika trådar), så får du gärna visa några som helst bevis för detta. Benchmarks eller länkar eller vad som helst. Det har du aldrig kunnat visa förrut, och jag väntar mig inte att du kan göra det nu heller.

Däremot finns det flera tecken som pekar på att Linux ligger långt efter Unix i skalbarhet i praktiken. Jag kan dra några av tecknen igen:

1) De största Linux servrarna som funnits fram till nu, har 8-sockets. Mao, Linux är omoget när det gäller skalbarhet, det är osannolikt att Linux skalar förbi 8-sockets. Det kräver mycket utveckling, kanske decennier precis som Unix. Linux utvecklarna idag sitter på sina 2 socket PC, hur ska de optimera Linux skalbarhet för 32 socket servrar när såna aldrig existerat, jag är inte säker på att SGI släppt såna än, jag vet inte om det finns såna ute på marknaden att testa mot.

2) SAP benchmarks på små 8-socket servrar visar att Linux är långsammare än Solaris på nästan exakt samma hårdvara. Linux hade 2.8 GHz cpuer, Solaris hade 2.6GHz cpuer - av exakt samma modell. Och Linux cpu utilization var ~88% medan Solaris låg på ~99%. Det finns andra benchmarks, som visar att Linux är långsammare på nästan identisk hårdvara.

3) När HP testade Linux på sin Big Tux 64-socket server så fick de en cpu utilization på ~40% under max load. Mao, mer än varannan cpu idlade, under full load. Det slutade med att HP inte sålde Big Tux Linux servern. Prestanda var för dåliga.

4) När HP nyligen byggde om sin 64-socket Superdome server till att innehålla x86 cpuer istället, så stannade HP vid 16-sockets. Skälet till att de inte gick upp till 64-sockets som med Unix, måste vara skalbarhetsproblem.

5) När man pratar med Unix sysadmins, så säger alla att Linux skalar långt sämre och har sämre stabilitet. Det finns _ingen_ som säger tvärtom, dvs att "linux skalar bättre på 32-socket system än gamla Unix os som gjort det i decennier". T.ex. denna sysadmin säger att Linux har skalningsproblem för filsystem. Det finns många såna här liknande länkar, det finns inga länkar som säger tvärtom, att Linux skalar bättre på stora servrar - hur skulle det gå till, stora Linux servrar har ju aldrig funnits.
http://www.enterprisestorageforum.com/technology/features/art...

6) Marknaden för stora servrar är uteslutande Unix och Mainframes, Linux existerar inte, det är 0% Linux och 0% Windows likaså. Hur går det ihop när Linux skalar bättre än alla andra OS, eftersom Linux har RCU?

etc etc etc

Mot alla dessa tecken, vilka tecken finns det att Linux skalar bättre än gamla Unix som i decennier skalat förbi 32-sockets? Inga alls, förutom att Linux har RCU. Då måste RCU betyda att Linux skalar bättre, eller hur? Det spelar liksom ingen roll om det finns andra begränsningar i Linux som sätter stopp för skalbarhet? Jag menar, Linux har gjort stora ökningar i skalbarhet nyligen "Det senaste områdena som fått rejäla lyft, har ibland varit 50-60 gånger högre prestanda på system med 8-sockets av Intels topp-modeller (vilket visar att det fanns en del att jobba med)" - hur kan Linux öka prestandan på små 8-socket servrar så mycket som 50x när Linux ändå använder RCU? Det borde inte gå?

Du låter som BTRFS användare som säger att BTRFS är bättre än ZFS, eftersom BTRFS använder B+ träd som är bättre rent teoretiskt än det ZFS använder, Merkle träd. Alltså måste BTRFS vara ett bättre filsystem, eller hur? Visst. Läs lite på forum så får du se hur mycket BTRFS kraschar och hur instabilt och långsamt det är i jämförelse med ZFS. Eftersom BTRFS använder B+ träd som är bättre, hur är det möjligt att BTRFS är sämre än ZFS? Mao, jag bryr mig inte om RCU eller vad nu fancy teknik POWER8 har för att göra det 50x snabbare än x86 - hur bra presterar det i verkligheten? Inte alls. Visa några länkar som stödjer ditt påstående att Linux skalar bättre än Solaris. Bloggartiklar, benchmarks, forumtrådar, etc - vad som helst. Du har aldrig kunnat posta såna förrut dock.

Så bara för att RCU används i vissa ställen, så betyder det inte att RCU automatiskt gjort att hela Linux skalar superbt över alla områden? Det kanske finns områden där RCU inte används, eller inte funkar bra ihop med befintlig Linux design?

Så TCP/IP stacken i Linux har under lång tid kunnat skalas till väldigt många cpu kärnor? Och det är därför Linux slagit andra OS? Det visste jag inte. Hur många kärnor har TCP/IP stacken kunnat skalats till i Linux? Tja, med tanke på att den största Linux servern har 8 sockets, så blir det väl inte så många cpu kärnor? Det låter som ganska lite, 8-sockets bevisar ingenting om Linux skalbarhet.

https://en.wikipedia.org/wiki/Scalability
"An...networking protocol...is said to scale if it is suitably efficient... when applied to large situations....If... fails when a quantity increases, it does not scale...."

Wikipedias kursivering. Linux TCP/IP stack skalar till 8-sockets. Sen tar det stopp. Det är inte vidare skalbart om du frågar wikipedia? Wikipedia skulle säga "Linux TCP/IP stack does not scale"? Jag har svårt att tro att Linux TCP/IP stack som funkar bra för 2 sockets, helt plötsligt skulle köra lika bra på 32 sockets. Jag tror det skulle kräva massiv omskrivning. Bara för att något funkar på 2-sockets, betyder inte att den funkar bra på 32-sockets.

Pratar vi TCP/IP stackar, så verkar FreeBSD vara ganska mycket bättre än Linux, trots att Linux har "RCU, fluxkondensatorer och dubbla överliggande kamaxlar med oljeinsprutning etc etc etc" och FreeBSD inte har just alla dessa saker. Men FreeBSD har annan teknik än de som nämns utav Linux folket, som gör FreeBSD bättre. Facebook vill förbättra Linux TCP/IP stack så den blir lika bra som FreeBSD:
http://www.theregister.co.uk/2014/08/07/facebook_wants_linux_...
“Our goal over the next few years is for the Linux kernel network stack to rival or exceed that of FreeBSD”

Solaris hade en kass TCP/IP stack förrut pre Solaris 10, det är därför det kallades Slowlaris, men stacken har skrivits om iom Solaris 11 och är nu bäst på throughput säger sysadmins, den skalar sjukt högt säger de. Det är samma människor som skapade ZFS, DTrace, SMF, Zones, Crossbow, etc - tekniker som alla har plagierats utav Linux. När de skapar en TCP/IP stack blir den antagligen bra, den skalar i alla fall upp till 32-sockets och vidare om man behöver det.

Bara för att Linux används inom vissa områden, betyder det inte att Linux är bättre. Windows har stor dominans, det måste betyda att Windows är bättre än Linux, eller hur?

Självklart förbättras Linux skalbarhet. Men det lustiga är att du hade exakt samma argument för flera år sen. Jag visade länkar som visade att Linux hade problem med skalning, som du invände emot, bl.a. genom att säga "jamen det är annorlunda nu, den dära problemlänken är ju ett år gammal så den räknas inte, idag ett år senare skalar Linux super eftersom de arbetat om Linux". Och exakt samma argument drar du idag, och kommer dra om 10 år. Jag är inte övertygad om att en kärna som används främst på 2-sockets, skalar bättre än Solaris och AIX som länge använts på 32-sockets. Varken idag, igår eller imorgon. När jag visar en skalningslänk kommer du avfärda den med massa invändningar och säga "jamen idag är det annorlunda, så din länk gäller inte längre". Så här kommer det vara år efter år. Och om jag mot förmodan postar en aktuell länk idag, kommer du hitta andra invändningar. Men å andra sidan har du aldrig visat en länk där Linux skalar bättre än Unix. Det är alltid jag som visat länkar som stödjer mig, som du alltid avfärdat.

Mönstret går igen år efter år, så här ser det ut: Jag nämner ett problem som Linux har. Genast säger du "jamen du har fel, eftersom Linux har finess XYZ och eftersom Unix saknar XYZ så är Linux mycket bättre än Unix". T.ex. har Linux RCU och därför skalar Linux bättre än Solaris som inte har RCU. Om vi pratar x86 vs SPARC, så har x86 finess ZYX, som inte SPARC har, därför är x86 snabbare. etc etc. Vad vi än pratar om, så drar du upp en finess som just Linux eller x86 har, som de andra inte har.

Mitt standardsvar på dina invändningar, är "jamen visa benchmarks då som bevisar din ståndpunkt!". Vilket du aldrig gör. Du visar aldrig några bevis för att Linux skalar bättre än Solaris, eller att x86 är snabbare än SPARC M7, eller något annat av dina påståenden. Du bara säger "jamen dina benchmarks stämmer inte, därför att..." och så kommer det en lång teknisk förklaring till varför x86/Linux faktiskt är bättre - men inga benchmarks eller bevis som stödjer dig. Bara en teknisk förklaring som taget direkt ifrån Intels hemsida.

Jag vet inte hur många gånger jag skrivit detta till dig genom åren: bara för att Linux/x86 har XYZ, och de andra inte har XYZ - så betyder det ingenting. Implementationen kanske suger, det kanske finns andra begränsningar, etc etc etc. SPARC och Unix har ju faktiskt funktion ABC som Linux inte har, och tack vare ABC så är SPARC/Unix bättre i praktiska benchmarks. Jag säger aldrig "jamen Linux saknar ABC - alltså måste Linux skala sämre", jag visar ofta länkar/benchmarks/etc.

Du måste lära dig tänka mer kritiskt, och inte bara köpa marknadsföringssnacket rakt av. Om IBM påstår något, och kommer med en lång teknisk förklaring - så ska du inte acceptera deras påståenden om hur prestandan förbättras 50x upp till 1.000x nej, kräv bevis. Säg "jaså, så POWER8 är 1000x snabbare, har du benchmarks?" om IBM inte kan presentera bevis så var det bara ordbajseri, eller FUD. Jag själv är allergisk mot ordbajseri.

Jag köper inget av Oracle, jag kräver bevis. Alltid alltid alltid. Om Oracle påstår att ZFS är säkrare, så vill jag se underlag för det. Om SPARC M7 är snabbare så vill jag se underlag för det. Jag skiter fullständigt i alla tekniska detaljer, därför att i verkligheten räknas inte teorin. Praktiska tester är det enda viktiga. Och har man inte praktiska tester, får man nöja sig med benchmarks. Egenskrivna små kodsnuttar bör undvikas, för de är inte representativa för riktigt arbete.

Jag har ett helhetsperspektiv - om man tar bort ordbajseriet - hur blev i slutändan? Resultatet? Du går ned på detaljnivå direkt, utan att titta på helhetsbilden, så du bryr dig inte om att saker kan vara motsägande när man tittar på hela bilden. "x86 når 800 gflops enligt Intels tekniksnack, men varför visar inga praktiska benchmarks den siffran?" det bryr du dig inte om, istället framhärdar du i inlägg efter inlägg att E5-2699v3 når 800 gflops, och jag måste tro dig på ditt ord, eftersom du läst det utav Intel. Och du postar aldrig bevis.

Nästan exakt det min kompis gör, han har Asperger - han går direkt ned på detaljnivå men ser inte hela bilden. Han kan säga emot sig själv ibland därför att när man går ned på detaljnivå så är varje påstående rätt, det är bara när man pusslar ihop allt man ser att det är fel, att något måste vara felaktigt.

Återigen, små tillrättalagda kodsnuttar är inte representativa för riktigt arbete, där massa saker spelar in, man måste gå ut mot diskar, cpu cachen blir thrashad, etc etc etc. Om jag skriver en liten for loop med massa NOPar säger ju inget om hur en cpu presterar i riktigt arbete. Jag vill se riktiga benchmarks, det bästa vore ju att få se riktiga arbetslaster, men vi får nöja oss med stora benchmarks.

Återigen, när du arbetar på riktiga data så blir det helt andra problem. cachen thrashas, etc. Det kryllar av numme benhcmarks, jag tycker de är mer representativa för beräkningsprestandan för en cpu än din kodsnutt. Om jag skriver en liten kodsnutt för SPARC M7 som visar fantastiska prestanda (vissa saker är 83x snabbare på SPARC M7 - men det är ju inte representativt för riktigt arbete så denna siffra på 83x snabbare har jag struntat i för det är ju bara ett drömscenario) så betyder det inget i verkligheten. Du säger att SPARC M7 är snabbare på vissa specialfall, och därför är den inte snabbare än x86. Din lilla kodsnutt är ju bara ett specialfall, så den säger inte så mycket.

Angående varför jag accepterar STREAM benchmarks, men inte din kodsnutt - det är pga STREAM är en benchmark som flera använder. Det den mäter, är hur snabbt man skyfflar data, dvs minnesbandbredd. Och det är exakt det som STREAM handlar om: minnesbandbredd. Det låter väl som en relevant benchmark när man pratar om bandbredd? Istället för att tjata om din kodsnutt, så tycker jag vi går över till mer representativa benchmarks, såsom SPEC2006 eller Linpack, lapack, etc.

Om IBM adderar all bandbredd i systemet så är det lögn. En av bandbredderna kommer att vara långsammast, så du kan inte få högre bandbredd än den flaskhalsen. Det är omöjligt att nå högre, det är en matematisk sanning. Bevis: det finns en sats som kallas för MAX FLOW = MIN CUT:
https://en.wikipedia.org/wiki/Max-flow_min-cut_theorem#Defini...

Oracle påstår att SPARC M7 cpn har högst minnesbandbredd. Oracle har inte pratat om IO eller nåt annat. Benchmarken visar bara att M7 har högre cpu minnesbandbredd, exakt det som Oracle påstår. Inget annat.

Absolut, du har rätt att benchmarks är äpplen och verkliga program är päron. Men, eftersom vi inte har riktiga laster att jämföra, så får vi nöja oss med det näst bästa: benchmarks.

Benchmarks är hyfsat genomlysta, flera kör dem, och det bästa med benchmarks: de är inte tillrättalagda små kodsnuttar som är specialskrivna för att utnyttja en enda specifik funktion i en cpu för att nå höga värden. Nej, istället är benchmarks stora och relevant arbete utförs, som i vissa fall kommer ganska nära riktiga arbetslaster. Mao, eftersom det är så mycket kod, spelar det inte roll om den lilla specialfunktionen utnyttjas eller inte i steg nr 57, man mäter ju ändå hela resultatet steg 1-100. Och då spelar inte snabba små steg någon roll på det hela taget. Dvs, jag har helhetsperspektiv, och inte tittar nere på detaljnivå, igen. Om vi ska kolla hur snabb en cpu är, är det bättre att titta på hela cpun, och inte på hur bra en special funktion presteras. Bara för att SPARC M7 är 83x snabbare på en viss liten småsak, säger ju ingenting på det hela taget. En enda accelerad grej är inte intressant, det är ju hur hela cpun presterar på det hela som är intressant.

Eller vad säger du om benchmarks? Om x86 vore snabbare skulle du tycka att benchmarks var det viktigaste, precis som IBM? Du skulle inte gilla om jag avfärdade benchmarks där x86 är snabbare? Helt plötsligt skulle benchmarks vara jätteviktiga?

Försöker du säga att ifall Xeons bara kan arbeta mot cachen och slipper gå ut mot RAM, så håller Xeon jämna steg med POWER/SPARC när det gäller genomströmning?

Om det är detta du menar, så vet jag inte om du har rätt. Det jag menar däremot, är att för serverlaster där du betjänar tusentals användare där working set aldrig får plats i cache, så är POWER/SPARC snabbare. Håller du med?

Sen att x86 har bättre cachedesign, vet jag inte. Det kan vara så, jag säger inte att det är omöjligt. Men x86 är ju en desktopdesign och i bästa fall kan du få plats med datalasten i cachen eftersom det är bara en användare, så det låter rimligt att just desktops har bra cache. Med servrar spelar det inte lika stor roll, t.ex. SPARC T1 hade en total cache på 3,1 MB och sket fullständigt i cachen, därför att working set för en server aldrig ändå får plats i cachen. Istället hade T1 en barrel cpu, så den dolde latency i varje tråd. Mao, T1 hade jättedålig cachedesign, men var ändå 50x snabbare än x86 på just den var designad för; betjäna många klienter. Cache är inte allt, annars skulle T1 inte kunnat vara så enormt mycket snabbare.

Absolut är det så att officiella benchmarks inte är representativt för verklig prestanda, men officiella benchmarks är det bästa vi har i brist på verkliga laster.

Jag finner det otroligt att x86 som är långt sämre på officiella beräkningsbenchmarks än SPARC M7, skulle helt plötsligt vara snabbare på beräkningar i verkligheten. Det jag tror är att ifall M7 är snabbare än x86 på benchmarks, så gäller samma förhållande även i verkliga laster. Men du verkar mena att det kan vara tvärtom? Att x86 är sämre i benchmarks, men i verkligheten är den snabbare?

Först hade du massor av invändningar mot benchmarksen, typ "vi ser att ett kluster med 32st x86 servrar med dubbla Xeons tar 1000 sekunder på Hadoop, mot SPARC M7-4 som tar 4000 sekunder, alltså är x86 snabbare" och jag vet inte vad du kom med. Jag vederlade alla dina invändningar, ett efter ett. Så sa du att, mäta Hadoop per socket, är något som Oracle hittade på och helt menlöst mått. Efter lite diskussion kring det, sade du slutligen att "Hadoop benchmarken är helt menlös och inte relevant alls". Och nu vill du få det till att alla SPARC M7 benchmarks är helt menlösa? Du backade steg för steg efter ditt försök att invalidera Hadoop benchmarken, och nu vill du i ett slag invalidera alla M7 benchmarks. På så sätt kan du hävda att x86 är ändå snabbare än M7 eftersom alla benchmarks är helt menlösa? Är detta korrekt?

När jag såg alla POWER7 benchmarks över hela internet, så accepterade jag dem och sade "grattis IBM, POWER7 är den bästa cpun just nu". Det var inte så att jag kom med massor av invändningar och i ett slag idiotförklarade alla benchmarks. Exakt samma benchmarks, som jag i nästa steg tyckte var jätterelevanta, när SPARC T5 kom. Vore inte detta en märklig debatteknik?

Ska vi titta på helhetsbilden igen? Om nu detta är sant, så kanske du kan posta länkar där den når 800 gflops? Inte det? Ok, då är det något påstående som är fel. Vilket då?

Återigen (vet inte hur många gånger jag skrivit detta till dig) men när det gäller beräkningar, som t.ex. superdatorer gör så vill man ha många cores och trådar för att göra många beräkningar samtidigt. Därför är GPUer intressanta, de har klena trådar men kan köra många beräkningar samtidigt. T.ex. IBMs Blue Gene superdator som länge hade nr 5 i top500, hade en PowerPC på 750 MHz. Och hur klen cpu tror du den har? Vet inte hur många gånger jag måste skriva det, men när det gäller numme beräkningar som t.ex. MCMC vill man göra massivt parallella beräkningar. Därför är det viktigare med stor genomströmning för goda beräkningsprestanda, än låg latency. Det är precis detta som SPARC M7 har. Och därför har SPARC M7 bättre beräkningsprestanda än x86.

Jaså. Inom High Frequency Trading använder man typiskt FPGA, inte ASICs. FPGA kan man programmera om och uppdatera sin algoritm med jämna mellanrum. ASICs kan man inte ändra på, så det används inte så ofta inom HFT, om någon ens gör det?

En FPGA är typiskt låg klockad, kring 1GHz kanske. Om vi jämför detta mot en 4GHz cpu, så kan lite grovt, CPUn göra 4 operationer när FPGAn gjort en enda operation. Och det är därför inte helt trivialt att använda FPGA inom HFT världen när du vill ha så låg latency som möjligt. Antag att en HFT algoritm använder 20 steg innan den avgjort om den ska köpa aktien, då tar en 4GHz cpu kortare tid än en 1GHz FPGA.

Detta torde även gälla en ASIC som är klockad på 1GHz.

Strömförbrukningen är en av flaskhalsarna. Den andra är att det är svårt att fördela arbetet effektivt på superdatorn, och administrera allt arbete. T.ex. Blue Gene hade ett specialskrivet OS som bara kunde göra beräkningar, inget annat. På varje nod kördes alltså detta OS. Så användes Linux för at distribuera ut arbetslasten till varje nod. Och ändå benämdes Blue Gene som en Linux dator. Jag håller inte med det.

SPARC M7 är snabbare på tekniska beräkningar än x86, enligt min förklaring om SPEC2006 ovan: superdatorer behöver många cores och trådar. SPARC M7 har många cores, det har inte x86.

Sun hade problem med pengar och kunde inte satsa pengar på FoU, så SPARC halkade efter. Sen kom Oracle och öste pengar över SPARC teamet, och idag ser vi resultatet: SPARC M7. M7 finns inte i någon superdator. Och det kommer nog inte hända, efersom den drar så mycket ström. Något måste man ju få utav all strömförbrukning.

Oracle är absolut inte intresserade av HPC marknaden, man tjänar för lite pengar där. Det är typ, 2 st kunder för en superdator som tar åratal av FoU. Oracle har sagt att de fokuserar på high end Enterprise marknaden, där finns de stora pengarna att tjäna. Detsamma sade faktiskt Sun förrut, de drog sig ur HPC marknaden.

Fujitsu är däremot intresserade av HPC. De har ju sin "K" superdator på plats nr 4(?) med föregångaren till den strömsnåla SPARC XIfx cpun. Fujitsu kommer bygga en 100 pflops superdator med sin SPARC XIfx, just den som uppnår 1.100 gflops. Ska bli intressant att se vad den uppnår i praktiken också. Så nej, SPARC är inte ute ur superdator världen. Oracles SPARC är däremot det, de drar för mycket ström. HPC cpuer måste vara strömsnåla.
https://en.wikipedia.org/wiki/K_computer

Det här kan du få utveckla lite om du vill. Ja, jag har läst doktorandkurser i numme på KTH också, programmerat MPI på Cray superdator och sånt. Hur kan effektiviteten gå mot 100%? (Det är i praktiken oftast en gles matris).

Det händer att en tråd strular och låser/saktar ned kärnan. Om man har två kärnor, så kan den andra kärnan köra på utan avbrott. Om man bara hade en kärna skulle hela datorn strula. Jag själv föredrar flera kärnor utan tvekan, framför en enda stark kärna. Jag kommer ihåg när man hade en single core dator, och fick dual core - multitaskingen blev bättre. När man har 4 kärnor, kunde man spela spel samtidigt som man tankade filer och sånt. Det skulle inte gått i praktiken på en enda kärna även om den var lika snabb. (Amigan körde en 68000 på 7.1590 MHz om jag inte missminner mig). Men visst, jag förstår att du vill hellre ha en stark kärna med en enda tråd om du får välja. Jag väljer flera kärnor, så blir systemet mer responsivt när det strular.

Jag har dessutom läst folk som klagat på att Linux har urusel multitasking apropås wonder patch, typ att Linux laggar när de spelar MP3 och... scrollar websida(?). Därför har de kört Con Kolivas scheduler som fixade till det, därför blev den omtalad. Om Linux inte haft de problemen hade inte Con behövt skriva sin scheduler.

Öh? Seriöst, känner du inte till att Googles, Facebook, etc kör sina stora datacenters på små servrar? Nu blir jag förvånad. T.ex. Google har 1 miljon servrar i sina datacenters, och när en server kraschar kopplar de in en ny. FB gör egna standardiserade servrar, de specialdesignar egna modeller och beställer från... Dell? HP? Kommer inte ihåg.

Men ja, när du kör enorma kluster, så vill du ha billiga småservrar som du kan byta ut utan problem. Man vill undvika single-point-of-failure å det längsta. Kluster är alltid bättre, se bara hur sällan FB och Google har sina sajter nere. Och jämför mot stora Unix eller Mainframes, som sällan går ned. OpenVMS kluster verkar vara det stabilaste som finns med upptider på 17 år eller mer, där de uppgraderar OS, byter ut servrar, kör Alpha cpuer och Itanium cpuer på olika maskiner i samma kluster. Helt magiskt. OpenVMS och Unix skapades ungefär samtidigt, men OpenVMS har en annan design än Unix, och mycket stabilare säger OpenVMS admins jag talat med. De säger t.ex. att Solaris är lite instabilt. Jag frågade om Linux och Windows, och då fnissar de.

Vem som kör dessa mytologiska stora Unix/Mainframe servers? Det är t.ex. stora fortune 500 företag som banker, etc - som kör stora affärsystem som SAP, databaser, etc. När Oracle demonstrerade sin M5-32 server blev Morgan Stanley cheferna glada, därför att den kunde faktiskt slutföra vissa databasqueries som aldrig genomfördes tidigare. Det gick att få fram ett svar på en fullt bestyckad M5 med 32 sockets och 32TB RAM. Att köra det på en 8-socket server fanns inte på kartan.

Jag tycker det är lite lustigt att du har så starka åsikter om High End Enterprise marknaden när du inte känner till den jättebra? Höll inte du på att tjata i alla år tillsammans med de andra linux killarna om hur bra Linux skalar även på high end scale-up servrar? Jag har bestämt för mig det.

Precis min poäng. Då är det lite vanskligt att påstå att "finns dock väldigt många serverlaster [SPARC M7] inte är snabbast på"? Jag håller med om att den antagligen inte är snabbast på alla serverlaster, så "världens snabbaste servercpu" kanske är fel titel. Men om nu M7 är typiskt 2-3x snabbare än de snabbaste massmarknad cpuerna som finns, så kanske den bara är 20% snabbare i värsta fallet. Det kanske t.om finns chans att den är snabbast på de flesta, om inte alla serverlaster? Om M7 var 50% snabbare så är inte marginalen god, den kan vara rejält långsammare i somliga fall. Men nu finns det god marginal, t.ex. 11x snabbare på några databasbenchmarks - då kanske den är snabbare på ALLA databaslaster? I sämsta databasfallet kanske den bara är 2x snabbare?

Jag tror inte att majoriteten av program handlar om att betjäna så många klienter som möjligt. Men för just den kategorin, så tror jag SPARC M7 är snabbast per socket.

Jag har läst att den stora skillnaden mellan E5 och E7, är att E7 är byggd för att skala upp till 8-sockets, glueless. E5 är byggd för att skala upp till 4-sockets glueless. Detta innebär att E7 måste ha mera RAS och är mera enterprise, eftersom den går till större servrar. Därför laggar den efter E5 i utvecklingen, mindre buggar och stabilare. Jag tror att om man tittar på alla 8-sockets servrar, så är det uteslutande E7? E5 är mer för desktops, beräkningar etc.

Unix krymper. Vanliga x86 cpuer börjar bli ganska bra nu faktiskt, jämfört med förrut. Förrut var ju x86 ett skämt, och dög inte till någonting. Men idag är det annorlunda, x86 kan ersätta små Unix servrar. Och den största marknaden är små servrar. Det är sällan man behöver 16- eller 32-socket servrar.

Personligen tror jag att Intel slog sig i slang med HP för att lära sig RAS och enterprise cpuer från HP iom Itanium, sen när Intel lärt sig allt som HP hade att lära ut, struntade Intel i att utveckla Itanium och satsade på att utveckla Xeon istället.

Dock säljer Oracle sina engineered systems, dvs en server specialiserad för t.ex. databaser. Då blir den snabbare än andra konkurrenter, därför att Oracle äger hela stacken: cpu, operativsystem, java, affärsystemet. Så hela stacken är optimerad för affärssystem. T.ex. kan då Oracle bygga in acceleratorer rätt in i cpun för att boosta affärsystemet. Detta är unikt säger analytiker, det normala är att det är separata server och mjukvarutillverkare som inte samspelar så tight. Detta leder till Oracle är motsvarigheten till Apple inom Enterprise: ett system som är tight, alla delar från Oracle. Och dessa system är mycket snabbare än andra konkurrenter eftersom hela stacken är optimerad. Så Engieneered systems växer mycket starkt hos Oracle. Men vanliga Unix servrar krymper.

Återigen, jag vill se laster som är mer representativa verkligheten, som utför riktiga beräkningar. Om jag skriver några rader kod som utnyttjar SPARC M7s funktion så det blir 83x snabbare än x86, så är det helt menlöst. Ett riktigt system gör många saker, och ifall ett enda steg går snabbt så påverkar det inte hela bilden. Det är väl hela bilden vi är intresserade av, eller bara en viss liten grej? Typ, hur snabbt ett graffe kan flippa en pixel av och på, eller hur många fps man får i ett helt spel? Vad är intressantast? Antag att en graffe är super på nån liten smågrej, det påverkar inte hela FPSen i stort. Och det är ju ändå FPSen vi är intresserade av, inte nån liten smågrej.

STREAM skyfflar data i minnet, och det är relevant för en bandbreddsbenchmark? Kör istället ett officiellt gflops benchmark istället för din kod. Ska jag köra en 83x snabbare benchmark på SPARC M7 tycker du? Nej.

Öh, de kunde uppenbarligen mycket mera än mig, som ändå läst forskarkurser i numme. Jag vet inte, du kanske är professor i numme, men nånting säger mig att du inte är det. Dessa snubbar sade att dessa specialinstruktioner inte var till så stor hjälp i praktiken, vilket var ett av skälen att man inte får ut 800 gflops ur en E5-2699v3. Men om du nu vet mycket mera än dem, så kan du få visa länkar där man faktiskt får ut 800 gflops? Det låter ju lite otroligt, med tanke på att en POWER8 på 250 watt, får ut 400 gflops.

Missuppfattar jag dig, men visar du en tendens att nedvärdera andras kunskaper, även om saker du inte har en aning om?

Återigen, jag struntar vad som står i marknadsföringen, jag vill se resultaten. SGI kallar sitt stora 10.000 core SGI UV2000 server för SMP. Och SMP servrar är scale-up. Men ändå går det inte att köra scale-up laster på en UV2000 som SAP. Det enda som körs på dem, är HPC klustrade laster som numme.

Detsamma med ScaleMP som också har en server med 10.000 tals cores, det består av ett kluster av x86 servrar som kör en hypervisor som lurar Linux att tro att det är en scale-up SMP server. Men ScaleMP kör också bara numme klustrade HPC beräkningar.

Så i praktiken så används SGI UV2000 uteslutande som ett beräkningskluster. Och i marknadsföringsbladen står det att det är en SMP server. Vad ska man tro på, det som står i marknadsföringen, eller hur man använder den i praktiken? Mao, UV2000 är i praktikten ett kluster.

Så du hävdar att du inte tillsammans med de andra linux killarna under flera års tid, hävdat att SGI UV2000 är en scale-up server som kan ersätta stora Unix servrar för t.ex. SAP och stora databaslaster? Du skrev inte nåt i stil med meningen att "stora Unix servrar är snart utdöda, Linux kan göra allt som Unix kan" kommer inte exakt ihåg formuleringen? Ska jag googla lite och se om jag kan citera dig? Jag kan skicka PM med citatet?

SGIs stora scale-up server UV300H, används just nu i första hand för SAP HANA och andra in-memory databaser. Såna in memory databaser, är read-only, och därför går bra att klustra, och används uteslutande för analyser. Som ett datawarehouse. T.ex. amerikanska posten använder ett SGI UV2000 med en Oracle in memory TimesTen database för att detektera bedrägeri i realtid. Men dessa databaser används inte som en traditionell databas, dvs inte som en transaktionsintensiv miljö där man lagrar saker på disk. In memory databaser; säger sig självt att man inte lagrar något viktigt på dem.

Absolut finns affärsnytta att köra större analyser i realtid på in memory databaser, och det kan man betala mycket för. SAP är en stor marknad, och har många viktiga kunder. En stor SAP installation kan kosta en halv miljard SEK. Om man kan köpa en stor SGI server för någon mille så är det småpengar. Jag har för mig att SGI UV300H är certifierat för SAP Hana?

Om man läser lite om SAP Hana, så finns det två olika databasservrar i systemet. En stor scale-up för att lagra alla data på disk, och en klustrad för att göra analyserna. Lagringsdatabasen måste göras på en scale-up server. Jag vet inte om UV300H är certifierad för båda lagringsdatabasen eller bara analysdelen? Det borde stå nånstans om man googlar lite. (Om UV300H bara används för analysdelen, så används den bara som ett kluster, inte som en scale-up server. Och då kan man fråga sig varför UV300H inte används som scale-up server - är det för att x86 har problem att skala till 16-sockets?)

Det låter vettigt. Och ifall M7 är designad för hög genomströmning, så borde den vara snabbare än x86 på det?

Jag tror det är helt onödigt att köpa in en M7, man borde kunna få prova dem tycker man ju, speciellt som att det låter som att ni är ganska stora.

När det gäller Solaris så kan det vara långsammare än Linux. På små laster. Solaris är byggd främst för att skala uppåt till 32-sockets och över. Solaris sweetspot är 32-64 sockets. För decennier sedan fanns det 144-sockets Solaris servrar. Linux är designad för upp till 8-sockets, och sweetspot för Linux är 2-4 sockets. Skälet till det är att det aldrig har funnits större Linux servrar än 8-sockets fram till för några månader sen typ. Linux kernel hackarna utvecklar ju mot de servrar de har tillgång till: sina egna desktops. De har inte tillgång till 8-socket servrar att optimera koden för, än mindre 16-socket eller 32-socket x86 servrar som knappt kommit ut på marknaden.

Eftersom det i decennier existerat stora Solaris servrar leder till att Solaris använder mer komplexa algoritmer i själva operativsystemet, tidskomplexiteten typsikt är O(n logn). Jag läste en blogg om detta, där Oracle fått skriva om stora delar av Solaris för att skala uppåt till 1000 tals trådar. Solaris ser varje tråd som en cpu. Linux använder simpla O(n^2) algoritmer som funkar bra på 1-2 sockets, eftersom Linux utvecklarna har såna hemma. Och typiskt har komplicerade algoritmer som t.ex. O(n logn) större konstanter än simpla algoritmer, detta leder till att Solaris kan ha lägre prestanda på småservrar, men när man börjar öka lasten så drar Solaris ifrån enkelt - eftesrom det är just det som Solaris är byggd för. Flera benchmarks visar att Solaris är snabbare än Linux på exakt samma hårdvara (eller liknande hårdvara) när vi pratar hårdare körning, typ full load på 8-sockets. Och inte typ, en enda tråd som körs under 10 sekunder - där kan Linux vara snabbare. Men det spelar ingen roll vad teorin säger, det enda viktiga är praktiken, så det borde vara enkelt att kompilera om er Linuxmjukvara till Solaris och bencha själv på exakt era laster. Men det beror ju på vad ni har för laster. Rätt vertyg till rätt arbete. Kör ni t.ex. bara Windows grejer så ska man man ju köra x86. Kör ni bara affärssystem som SAP och stora databaser så är valet givet. Men det vore intressant att se om du kunde köra era laster på en SPARC M7, och höra en åsikt från en person som testat såna i verkligheten. Speciellt om ni tycker komprimering och kryptering är viktigt.

Nja, för High Frequency Trading är vi inte intresserade utav hög genomströmning som SPARC M7 är byggd för, M7 är anpassad för stora serverlaster som betjänar många tusen klienter samtidigt. Vi i HFT branschen är intresserade utav låg latency, inte att betjäna många klienter. Därför passar x86 bättre än en servercpu.

"Hur nära Wall Street får man bygga en datahall?" Jag förstår inte frågan. Datahallarna ligger allihopa en bit ifrån Wall Street. Och alla HFT klienter ligger i samma datahall som själva aktiebörsens server, dvs colocation. Det blev gnäll från tradingfirmorna, eftersom vissa HFT klienter ligger nära aktiebörsens server, andra ligger långt bort i samma rum. De HFT klienter som ligger 10m närmre aktiebörsens server, får informationen aningen snabbare, och då kan de fatta ett beslut snabbare och ta aktieaffären som kom in före alla andra. Så börsen fick då ge alla exakt lika långa kablar, typ 100m. Så en HFT klient som ligger nära börsens server, har ändå 100m lina. Då blev det gnäll från somliga HFT klienter, eftersom linan är ihoptvinnad när de ligger nära servern, och när linan är ihoprullad så blir det interferens så signalen störs och deras signal blir aningen försenad på väg till servern. Somliga har alltså sin lina rak, och andra ihoptvinnad. Och rak lina är snabbare. Så börsen började sträcka ut alla linor runt väggarna så de blev raka. etc etc. Vi är inte intresserade av throughput, eftersom en vanlig x86 räcker till. T.ex. all trafik från HFT klienterna och alla andra, till NASDAQs aktieserver, får lätt plats i en 1Gbit lina.

@Yoshman, angående ditt gflops program du skrev ihop. Jag förstår inte riktigt vad du försöker bevisa med det. Jag har sagt att jag inte är intresserad av marknadsföring eller egentillverkade tillrättalagda benchmarks där Intel t.ex. benchar 50 GB direkt från RAM och kallar det Big Data. Det enda som räknas är i praktiken med tester som liknar verkligheten. T.ex. om vi pratar gflops så gäller SPECint2006, Linpack, etc. Ditt program som inte gör något vettig beräkning är alltså inte intressant. T.ex. IBM påstår att deras POWER8 har 230GB/sek bandbredd, och SPARC M7 har 160GB/sek - så ifall du tittar på vad firmorna påstår så ska du köpa POWER8. Men om du istället tittar på riktiga bandbredd benchmarks, så är SPARC M7 dubbelt så snabb än POWER8.

Det är så mycket FUD och aggressiv marknadsföring så man kan inte lita på någon. Det enda man kan lita på, är officiella benchmarks och helst ska man testa själv på exakt sin last. Det är först då man kan dra några vettiga slutsatser. Skit i vad tillverkarna säger. T.ex. IBM påstod att deras gamla POWER6 hade 240GB/sek bandbredd. Det lät som en helt fantastisk siffra och ifall man blint trodde på vad IBM sade, var valet enkelt: köp POWER6. Men jag rotade lite, och det visade sig att IBM kommit fram till den siffran genom att addera bandbredden för L1 cpu cache + L2 cpu cache + L3 cpu cache + RAM bandbredd + etc. Så kan man ju inte göra, det är helt fel om man tänker efter lite. Antag att L1 cpu cache har 1GB/sek bandbredd - då är det en flaskhals och det går inte att vara snabbare än en flaskhals. Om jag ska leverera massa paket genom hela världen, och ifall en av alla kurirer, kan bara hantera ett enda paket per timme eftersom just den kuriren måste passera djungeln, så spelar det ingen roll hur många 1000 kurirer jag har i andra länder. Djungeln är ändå flaskhalsen. Det går inte snabbare än ett paket per timme. Det är flaskhalsen som bestämmer genomströmningshastigheten. Det är en matematisk sanning och går inte att komma runt. Så kort sagt, IBM ljög om den gamla POWER6 minnesbandbredd. Och det är inte första gången IBM ljugit. POWER8s max bandbredd är också en siffra som antagligen bara uppnås i ideala sammanhang med små specialskrivna kodsnuttar, precis som ditt program. Helt ointressant alltså.

Jag är van vid Enterprise världen (där främst IBM ljuger) och jag har lärt mig att det spelar ingen roll vad marknadsföringen och alla specarna säger. För företag ljuger. Och det FUDas friskt. Lita inte på vad någon säger, titta istället på benchmarks och gör egna tester. Om du inte kan göra egna tester, titta på benchmarks. Det är därför jag inte bryr mig om hur många gflops som E5-2699v3 uppnår enligt Intel, och det är därför jag inte kan acceptera dina siffror (som du citerat utav Intel). Det är därför jag vill se riktiga benchmarks. Där har vi facit. Där avslöjas lögnerna. Där ser vi vem som har rätt och vem som är naket klädd. Inget annat kan få mig att ändra uppfattning, oavsett vad företag eller specar säger. Jag är så van vid alla lögner och FUD. Det blir man om man är van vid enterprise marknaden. Det är bara hårda fakta och siffror som gäller. Inget annat. Istället för att debattera inlägg efter inlägg vad Xeon eller SPARC uppnår i teorin, så låt oss posta vettiga benchmarks istället. Siffrorna talar för sig själva. Vi behöver inte göra det. Det spelar ingen roll hur mycket Intel eller du, påstår att E5-2699v3 når 800 gflops, om den i praktiska tester uppnår 400 Gflops, eller om den når dess teoretiska maximum på 281 Gflops pga Amdahls lag, som i den dära länken jag postade.

Det är ungefär som om jag skrev en kodsnutt för AMDs nya GPU som visar att jag kan tända och släcka en pixel säg 25% snabbare än Intel, och drar slutsatsen att AMD är 25% snabbare på FPS också. Ett riktigt FPS spel handlar om så mycket mer än att tända och släcka en pixel, man har fysikmotor, AI, etc etc. Det är helt fel att skriva en liten kodsnutt och extrapolera slutsatser från det, till riktiga FPS spel eller riktiga gflops. Det är som att jämföra äpplen, och sen drar slutsatser om något helt annat, t.ex. päron.

Jag skulle vilja se Tomika köra SPEC2006 benchmarks, eller Lapack, Linpack, etc. Inte några specialskrivna benchmarks som inte gör något vettigt.

I fall 2), när jag säger hög genomströmning, och när jag pratar om serverlaster, så pratar jag om att betjäna tusentals klienter samtidigt. Det går inte att rymma så stora laster i cachen. Mao, det du pratar om: när lasten rymms i cachen, är fall 1), dvs desktop laster. Du verkar påstå att x86 både har lägre latency och högre genomströmning än SPARC M7?

Sen påstår du att Xeon har mer flyttalskapacitet än SPARC M7, hur når du den slutsatsen? SPARC M7 är ju snabbare än både Xeon och POWER8 i officiella SPECint2006 och SPECfp2006? Det ser ut som att SPARC M7 har mer flyttalskapacitet om vi tittar på benchmarks. Fast det förstås, om vi tittar på vad varje tillverkare påstår och säger - så blir det helt andra resultat. Fast det ska vi inte fästa oss vid, ofta är det överdrivet eller rena lögner. Benchmarks är närmre sanningen än tillverkarnas uppgifter. Det hoppas jag du håller med mig om?

Jag vill se riktiga benchmarks, och litar inte på att specialskrivna program eller tillverkarnas uppgifter låter en dra slutsatser om hur cpun funkar i verkligheten. Att AnandTech konstaterat att 2699c3 håller 2.8 GHz när alla kärnor jobbar känns irrelevant. Det viktiga är väl ändå hur snabb cpun är, vad den presterar på benchmarks och praktsika tester, inte hur många kärnor den har igång.

När du har stora affärsservrar som betjänar 1000 tals klienter samtidigt, så är förstås svarstiden viktig. Men om det redan är tillräckligt låg svarstid så spelar det ingen roll om det klienten blir betjänad på 10 millisekunder eller 20 millisekunder. Mao, svarstiden är inte så viktig om den är tillräckligt låg för att inte upplevas störande för klienten. För affärsservrar gäller normalt andra spelregler än de du är van vid: en x86 server som betjänar 100 klienter på 10 millisekunder var, är en sämre server än en SPARC server som betjänar 5.000 klienter på 20 millisekunder. 50x fler klienter är att föredra, du sparar ganska mycket pengar och ström.

Jag har hört att ASICs inom HFT inte är jättetrivialt att använda på ett bra sätt, därför att många kör på 1GHz eller så. Och en 4GHz cpu har lägre latency än en 1GHz krets.

Visst är det Hadoop fallet tungt på komprimering, komprimering brukar vara det. Men när du säger att "Oracle valt ett sånt specialfall med komprimering som Intel inte har inbyggd så det är orättvist" - så har du fel igen. Oracle redovisar i samma benchmark siffror utan komprimering, och det blir ungefär samma resultat. Vilket är rimligt, Oracle säger ju att komprimering är i stort sett gratis, så då borde det bli samma resultat oavsett om Oracle slår på komprimering eller inte. Och det är precis det Oracle redovisar i benchmarken. Mao, även om SPARC M7 kör icke komprimerat så förändras inte siffrorna, M7 är 5x snabbare även okrypterat. Det vore jobbigt om SPARC M7 slog på kryptering och komprimering, båda ska ju nästan vara gratis så M7 kör nära full hastighet hela tiden oavsett. Men för en x86 kanske prestandan halveras eftersom den komprimerar, och sen halveras en gång till eftersom den krypterar. Då blir en M7 hela 2 x 2 x 5 = 20x snabbare än en x86 cpu. Men visst, börjar du bestycka en x86 cpu med diverse externa kort ändras bilden. Då kanske x86 kan köra i full hastighet eftersom den slipper kryptera och slipper komprimera, så då är SPARC M7 bara 5x snabbare.

SPARC M7 har flera acceleratorer ja: komprimering, kryptering, databas. Förutom dessa fyra, känner jag inte till några andra accelerateror. M7 benchmarksen som Oracle postade använder inte databas acceleratorn i alla benchmarks, bara på några få. Komprimering och kryptering låter M7 kör nära full hastighet, det är inte så att komprimering och kryptering ökar M7s hastighet på Hadoop - de bara låter M7 köra nära full hastighet. Så om du tycker Oracles benchmarks är orättvisa titta istället på okrypterade och okomprimerade resultaten som Oracle alltid(?) postat - då kan du sluta prata om att använda externa kryptokort till x86. Då blandar vi inte in några acceleratorer alls (förutom i databasbenchmarksen).

Hur drar du denna slutsats? SPARC M7 är ju mycket snabbare på SPECint och SPECfp benchmarks? Om Xeon har högre heltal och flyttalsprestanda, så borde väl Xeon även vara snabbare på benchmarks som mäter just det? Eller menar du att Xeon har högre teoretisk prestanda? Men med teori skjuter ingen hare. Har du benchmarks som stödjer ditt påstående?

Du får gärna visa länkar till en rad sådana problem du pratar om så jag kan lära mig något jag missat.

Hur drar du den slutsatsen att Xeons har högre flyttalskapacitet när SPARC M7 är mycket snabbare i riktiga SPEC benchmarks?

Xeons är framförallt billiga, och ifall man skulle bygga en superdator med 100.000tals SPARC M7 cpuer skulle priset bli helt oöverkomligt. Men prestandan skulle skjuta i höjden, eftersom en superdator behöver många cores och trådar, enligt beräkningsexperter. Och det är nåt som M7 har i överflöd.

Dessutom är en superdator optimerad för att dra så lite watt som möjligt, jag läste att en stor superdator kan dra 10 megawatt. T.ex. IBMs Blue Gene som fram till för några år sedan hade nr 5 på top500 listan, hade dubbla 750MHz powerpc cpuer som drog väldigt lite watt. Samtidigt som det fanns ganska rejäla Xeons ute på marknaden. Men en M7 superdator skulle dra alldeles för många watt, så det skulle inte funka med en sån superdator.

Sant. Man drar sig inte för att skriva om dem till GPUer också. Om du kan skriva om och få ut 5% högre prestanda så gör man ofta det.

Alla numeriska HPC beräkningar som t.ex. CFD eller finansmatematik eller väderleksberäkningar på superdatorer som jag känner till, handlar om att lösa samma diffekvation på ett stort grid. Ju fler cores/trådar desto finmaskigare grid. Det är just därför man har superdatorer, så man kan ha 100.000 cpuer och ännu flera cores och trådar. Superdatorer handlar om just det, lösa samma beräkning på många gridpunkter => många cpus.

Om det nu var istället att en superdator typiskt skulle göra en enda beräkning så snabbt som möjligt (och inte biljoner beräkningar), vore det bättre med en enda cpu klockad med flytande kväve till 7-8 GHz. Men superdatorer ser inte ut så, de har 100.000 tals cpuer och GPUer. Allt för att göra så många beräkningar som möjligt, dvs massiv throughput på kortast tid. Dvs scale-out laster. Och SPECint och SPECfp, mäter exakt det. Så ja, SPEC är en relevant benchmark för tekniska beräkningar. Annars skulle den inte se ut på det sättet, att den skalar utåt.

Och jag har sagt att jag är imponerad hur en 150 watt cpu som Xeon presterar så bra. Men ifall vi pratar om vilken cpu som är mest lämpad för tekniska beräkningar, så verkar det som att SPARC M7 cpun är bättre på det än x86.

Men vill du bygga ett kluster för X kronor som är för beräkningar, så är det en annan fråga som x86 antagligen vinner när det gäller pris/prestanda.

Jag tror inte många säger emot att Xeon är bättre på att köra få trådar snabbt, dvs betjäna en enda användare snabbt. Men SPARC och POWER är mer servercpuer dvs tung last 24/7, och då handlar det om att trycka igenom så mycket arbete som möjligt. Så för desktops, dvs en användare som kör några få trådar så är Xeon bäst. För att serva tusentals klienter så är SPARC och POWER bättre. Därför att de är byggda för olika saker.

Så ifall du fick välja mellan en single core cpu med två överlägset starka trådar, eller en 6-core med 12 hyfsade trådar, skulle du välja single core cpun??? Jag har svårt att tro dig. Visst är du en desktopanvändare, men ändå. Vad ska du med två starka trådar till, du kommer aldrig kunna multitaska bra. Om man tittar i task manager, så startar Windows upp många trådar, typ 100 eller så, vill jag minnas. Jag gissar att Linux gör detsamma? Som singleanvändare vill du ha ett responsivt system, det får du aldrig med en enda uberstark tråd.

Helt korrekt att Intel har stor del av servermarknaden idag. Men då pratar vi småservrar, low end. När vi pratar highend, så har Intel ungefär 0%. Fram till nyligen fanns inga 16 socket Intel servrar. Och de som precis har släppts, har väl knappt hunnit någon köpa än. High end servermarknaden ägs till 100% utav Unix och Mainframes. Och när det gäller att betjäna 100.000 tals klienter så är det bara Unix och Mainframes som gäller. Intel går inte, kan inte.

Jovisst, men ingen säljer en Xeon Phi dator där Phi är den enda cpun. På samma sätt säljer ingen en dator där AMD Fury X är den enda cpun. Mao, det är fel att säga att Phi och AMD Fury X är cpuer. De är hjälpcpuer, de driver inte en dator själv, de skulle vara urusla på det.

Du säger att AMD Fury X också är världens snabbaste cpu på sin nisch precis som SPARC M7, men AMD Fury X är ingen cpu. Så tycker inte du kan säga så.

(SPARC M7 är inte så extremt nischad heller, på alla laster där det gäller att betjäna så många klienter som möjligt, är M7 mycket snabbare än allt annat på marknaden)

Snällt! Kommer du komma med invändning efter invändning i långbänk om jag ändrar trådens titel då? Du ser vitt skilda benchmarks här, över 20st, och jag personligen förstår jag inte vad det är att invända emot hårda fakta, men du accepterar inte benchmarksen. Pga titeln. Men om titeln ändras, så slutar du försöka invalidera alla benchmarksen? Då kan du acceptera dem?

Du får gärna visa några serverlaster som SPARC M7 inte är snabbast på. Har svårt att tro att du hittar några, eftersom inte många benchamrks är släppta. Har du blogg inlägg där folk säger att M7 är långsam, då? Foruminlägg? Något som helst bevis att M7 är långsam?

Du har haft flera invändningar emot att SPARC M7 presterar bäst per cpu socket här. Jag tror poängen med benchmarksen är att Oracle vill visa att M7 är snabb på mycket stora laster. Vilket den är byggd för. 10 TB data att hantera för 4 cpuer torde anses som mycket stor last.

Med Unix servrar och Mainframes kan du byta allt under drift. Stoppa och starta cpuer under drift, RAM minnen, moderkort, etc etc. Mycket är dubblerat, ibland tripplat. Databussarna har ECC checksums på allting, etc etc. Nu pratar vi bara RAS.

Om vi pratar prestanda så har en stor Unix server mycket högre prestanda än en Xeon E7. Kolla bara på t.ex. SAP benchmarksen. SPARC 32-sockets ligger på 844.000 saps medan x86 ligger kring 300-400.000. Och SAP skalar dåligt, pga det är en scale-up arbetslast. Det går inte att köra scale-out på SAP. (SAP Hana är en annan sak, det är en klustrad in memory dvs read-only databas som används endast för analyser, inte för att göra riktigt SAP arbete).

Skälet att världens stora datacenter är byggda med E5 och inte E7 är talande. Skillnaden mellan E5 och E7 är att E7 skalar upp till 8 sockets. E5 skalar upp till 4 sockets. Annars är det inte jättestor skillnad mellan dem. Så när datacentren nöjer sig med E5, så betyder det att det är massor med småservrar, 2 sockets eller så. Det är en helt enkelt ekonomifråga. En 8-socket server är mycket dyrare än 4st 2-socket servrar. Och eftersom de kör småservrar, så är det scale-out laster, dvs klustrade laster. Precis som Google, Facebook, etc.

Klustrade laster är mer kostnadseffektivt är scale-up laster. Man vill gå mot klustrat när helst det är möjligt. Det är billigare med många småservrar än en enda stor server. T.ex. IBMs P595 POWER6 server med 32-sockets kostade $35 miljoner, dvs en kvarts miljard listpris. Men du kunde köpt 64st x86 servrar för mycket mindre, och fått mer cpu kapacitet.

Så varför existerar det ens en marknad med 16 eller 32 socket Unix / Mainframes som är svindyra, dvs flera 10 miljoner kr för en enda server, när du kan få ett helt gäng billigare x86 servrar med mer cpu kapacitet för en bråkdel av pengarna? Det finns vissa arbetslaster som inte kan köras klustrat. Det är typiskt affärsystem som SAP och stora databaser. Där har du inget annat val än en enda stor scale-up server med 16- eller 32-sockets. Och ju fler sockets, så ökar priset exponentiellt typ. Och alla vill slippa såna här svindyra scale-up servrar. Vad händer om den kraschar, då stannar hela företaget. Det är bättre med ett billigt kluster och ifall en x86 server kraschar så gör det inget, man byter nod. Precis som Google gör. Jag hörde att de har runt 1 miljon servrar.

Ifall man kan kan, så väljer man billiga scale-out kluster 10 ggr av 10. Man undviker i det längsta scale-up servrar, för de är svindyra och single-point-of-failure. Men alla tillverkare vill in dit, för marginalerna är skyhöga och de kan kräva flera miljoner för en enda server. Många tillverkare vill lämna x86 marknaden för marginalerna är typ 3% eller så, de tjänar ingenting. IBM sålde sin x86 division till Lenovo. HP ville sälja sin x86 division. etc etc. High end är där alla stora pengarna finns.

Men om man nu verkligen kan uppnå den prestanda i verkliga program som Agner Fog och du påstår, så borde det finnas benchmarks. Men det finns inte. Varför? Då har vi minst två förklaringar:
1) Agner Fog och ditt program är inte representativt för verkliga laster.
2) Ni två har rätt, det är bara det alla andra är klåpare som inte lyckas pressa ut 800 gflops i verkligheten.
Vad tror du är mest troligt till varför det inte finns benchmarks som stödjer era påståenden? Det kanske finns någon annan troligare förklaring, isåfall vill jag gärna höra den. Kanske @Tomika kan köra lite SPEC2006 eller lapack eller linpack på sin dator?

Jag har aldrig sagt att jag INTE är imponerad av Xeon. Det är som en 150 watt AMD graffe skulle vara nästan lika snabb som en 250 watt NVidia graffe ur samma generation - vem skulle inte bli imponerad?

Jag läste en lång teknisk diskussion där några snubbar som jobbade med vetenskapliga beräkningar diskuterade detta. Kontentan var att man inte alltid kunde använda Intels specialfunktioner, tvärtom påstod nån att det var ovanligt i riktiga beräkningslaster att man kunde använda specialfunktionerna. Och det var därför man inte fick ut mer än 400 gflops. I vissa enskilda moment kunde du använda specialfunktionerna men det var mycket sällan, och påverkade inte resultatet nämnvärt i slutet. Om detta är sant, så kan det förklara varför det inte finns några riktiga benchmarks (som utför många moment) som får ut mer än 400 gflops (vilket är väldigt bra för en 150 watt cpu) i verkliga laster.

Men det finns inga benchmarks som stödjer 800 gflops. Det enda viktiga måste väl ändå vara benchmarks? Det borde inte spela någon roll hur mycket tillverkarna ljugit ihop? Varken IBM, Intel eller Oracle?

Mainframes har en otrolig inlåsningseffekt. Och de funkar bra för det de är skapta för, dvs batch jobb som körs över natten: "uppdatera detta konto med 2%" och upprepa för miljoner konton. Generellt tror jag att om något är skapt för en specifik grej, så borde den vara bra på det.

Men Mainframes har ingen fokus på t.ex latency, t.ex. det finns ingen aktiebörs som kör Mainframes. Om Mainframes hade lägre latency skulle aktiebörserna switcha till Mainframes omedelbart. Mainframes används inom bankvärlden, inte inom finansvärlden.

Mainframes har otrolig bakåtkomptabilitet, kod från 1970 kan fortfarande köras omodifierat. Det är Enterprise, långa supportcykler på decennier. Enormt bra RAS, de kraschar sällan.

Överlägsen I/O. 296.000 I/O kanaler för en enda Mainframe.

Problemet är att de är svindyra och enorm inlåsningseffekt. Din kod kan inte portas enkelt till andra system. Många Enerprise företag försöker gå ifrån mainframes så fort de kan. IBM säljer Mainframes främst till gamla kunder som uppgraderar. Det är inte många nya Mainframe kunder. Jag själv skulle valt ett kluster med billiga 2-socket x86 servrar om jag skulle gjort något själv idag. Om jag måste köra stora affärssytem med extrema prestanda så är det SPARC M7 som gäller, men det är högst otroligt att jag skulle göra det. Jag tror x86 är bästa valet idag, om man inte har konstiga krav.

Gränsen flyttas fram hela tiden, och beroende på vem du pratar med kan du göra i realtid, med andra användare kan du inte göra det. Pratar vi många PB så blir det svårt med realtid, annat om du inte stoppar in 1 miljon servrar, etc. Så visst går det med realtidsanalys, du har rätt. Det beror helt enkelt på vems definition man använder. Men inte många skulle säga att 50 GB som kan köras från RAM, är Big Data.

Jag vill minnas att du påstått det tidigare? Tillsammans med fultra? Flera personer har sagt att jag har fel, att SGI UV2000 är en scale-up server. När jag bett dem visa scale-up benchmarks som t.ex. SAP, har ingen lyckats. Men de har ändå hävdat att det är en scale-up server, trots att SGI UV2000 inte kan köra scale-up laster som t.ex. SAP. SGI själva har sagt att UV2000 inte kan det, men det vill de inte lyssna på. De länkarna är helt orelevanta säger Linux fanboysen. SGI har fel, säger de. När jag hävdar att det enda riktiga är benchmarks, så har jag fel. Och så börjar de skriva drivor om teori och siffror, och alltså har de rätt och jag har fel. Men var är benchmarksen då? Finns det några kunder som kör UV2000 till SAP, någonstans på internet? Nej. Inga SAP historier någonstans, inga use cases på SGIs hemsida där kunder kör affärsystem, alla SGIs UV2000 kunder kör uteslutande HPC beräkningar. Var inte du en av dem som sade just det här?

Vad jag vet (och jag är ganska påläst om high end Enterprise) så är det bara SGI som i decennier försökt ta sig in på high end marknaden, som ska släppa en 32-socket server. HP har sin Kraken 16-socket server som är baserad på en gammal Unix 64-socket server som byggts om till x86. Bullion har sin 16-socket server, som presterar kasst. Jag tror mest på HP här, de har länge byggt stora 64-socket Unix scale-up servrar och kan detta. SGI har aldrig byggt såna, och antagligen presterar SGIs server kasst på allt som inte är klustrade laster. Detta är första generationen från SGI som håller på att komma ut nu, vi får vänta 3-4 generationer innan SGI börjar lära sig bygga effektiva servrar. Sen måste även Windows och Linux skrivas om, och det kräver mycket jobb. Nyligen fick Solaris och AIX skrivas om för att hantera 10 tals TB RAM, trots att de båda i decennier hanterat stora servrar. Linux och Windows är klient desktop OS, och de måste nu försöka ta steget in till High end, det är inte alls trivialt, det kommer ta decennier innan de är i Unix klass. T.ex. Linux Big Tux fick 40% cpu utilization under max last, enligt HPs tester. Att Linux ska gå upp mer än så, blir svårt. Linux kernel hackare har inte tillgång till stora 32-socket servrar, hur ska de optimera Linux till 32-sockets? De servrarna existerar ju inte ens knappt.
https://www.sgi.com/solutions/sap_hana/

En sådan E7 server vore inte liten alls! Det vore en helt anständig scale-up server. Jag ser två problem:
1) Det vore en bra server, förutsatt att den funkade lika bra som en Unix server som skalat i decennier till 32 sockets. Det går inte i en handvändning att skala upp till 32 sockets. HP som kan sånt här sedan decennier, har börjat med en 16-socket Kraken server för x86, trots att samma server byggd på Itanium gick upp till 64-sockets. Nästa HP generation kanske går upp till 32-sockets?

2) Det finns ingen sån server du beskriver. SGI UV300H med 32-sockets kommer närmast, alla andra x86 servrar stannar på 16-sockets. SGI UV300H går upp till 24 TB RAM.

Jag tror inte att SGIs 32-socket server presterar bra. Jag vill se benchmarks. Antagligen släpper inte SGI några scale-up benchmarks med sin UV300H, pga den presterar dåligt. Om UV300H presterade bra, skulle SGI bomba internet med sina benchmarks, men det lär inte hända. Jag tror att nästa generation UV300H så börjar vi se generella benchmarks med olika scale-up benchmarks. Men inte nu, SGI har fullt upp med att få den att funka och fixa alla flaskhalsar. Optimering kommer nästa generation. Idag släpper väl SGI någon enstaka scale-out klustrad benchmark gissar jag.

Det är som när ryska företaget skulle släppa sin Metro 2033 serie med FPS spel. Deras första grafikmotor var ju kass. Det tog några generationer, och ändå är inte de ikapp Unreal 4 motorn. Och hårdvaruservrar har längre ledtider än mjukvara. Om nu Metro 2033 har haft problem i alla år att komma ikapp Unreal 4 motorn, så hur många år kommer inte SGI ha problem att komma ikapp stora Unix servrar som har flera decennier försprång? Men det spelar ingen roll vad jag tycker, det enda som räknas är praktiska resultat. Om SGIs UV300H presterar benchmarks som utklassar Unix så ändrar jag förstås mig omedelbart. Då säger jag att jag har fel och jag måste omvärdera x86, för då har vi en ny spelare på high end marknaden - men det är högst orimligt idag, med tanke på att det tar lång tid att skala väl.

EDIT: Ny benchmarks släppt. SPECjbb2015, så om man är intresserad av att köra Java på en server, så är M7 ungefär 2.5x - 4.2x snabbare än E5-2699v3

Ett av skälen att vi aldrig blir överens, är att vi pratar om två olika typer av prestanda.
1) Låg latency, dvs att genomföra en enda beräkning på kortast möjliga tid.
2) Hög genomströmning, dvs att genomföra maximalt antal beräkningar på kortast möjliga tid.

Som jag sade, är SPARC cpuerna designade för att lösa 2), för att betjäna många klienter som möjligt. En server är typiskt byggd för att betjäna så många klienter som möjligt - dvs through put är det viktiga. Desktops är typiskt byggda för att betjäna en enda användare så snabbt som möjligt - dvs latency är det viktiga dvs 1) är det viktiga. Du har ett klient desktop perspektiv, så du prioriterar att din PC betjänar dig så fort som möjligt. Jag har ett server perspektiv, så jag prioriterar att betjäna så många kunder som möjligt. Det bästa vore ju förstås att ha låg latency och hög genomströmning, men det går ju inte. Antingen får man låg latency och dålig genomströmning, eller så har man hög latency och hög genomströmning. Latency och genomströmning är två motsatta begrepp och båda kan inte uppfyllas samtidigt. T.ex. om en server skickar ut ett mess så fort något händer så sjunker latency, men genomströmningen minskar - servern börja lagga och hinner inte med att skicka ut alla paket som köas upp. För att öka genomströmningen så brukar servern samla på sig flera mess i ett paket, och sen skicka ut paketet som innehåller flera mess, då ökar latencyn men servern klarar av att skicka ut flera mess än tidigare, dvs genomströmnigen ökar.

Jag har upprepade gånger sagt att Oracle SPARC är byggd för hög genomströmning och latencyn är inte den bästa på O-SPARC. Jag har sagt att x86 har lägre latency än O-SPARC och sämre genomströmning. Är vi överens om detta? Däremot verkar det som att du påstår att x86 även har högre genomströmning än SPARC M7?

Tomika säger ju att han ser sin E5-2699v3 (Intels snabbaste cpu) inte kör alla kärnor under full load, cpun stänger av kärnor när cpun börjar överskrida 150 watt. Det är bara 5-6 kärnor som kör, under full load, säger han. Hur påverkas troughput när man bara har 150 watt att driva cpun på? Intels Xeon kan variera klockfrekvensen uppåt och nedåt, beroende på hur många cores som dras för tillfället. Ju flera cores som aktiveras, ju lägre blir frekvensen - allt för att inte överskrida 150 Watt. Antingen kör Intel få cores med hög hastighet, eller så kör Intel många cores med lägre hastighet - allt för att inte överskrida 150 watt. SPARC och POWER har inte det problemet, de kan sträcka på benen upp till 250(?) watt, de är inte strypta. Så när man ser x86 enkeltrådsprestanda som är bra i teorin, det finns inget som säger att det fortsätter vara bra när man aktiverar alla trådar och cores samtidigt, då sjunker antagligen enkeltrådsprestandan. Enda sättet att se hur det blir i verkligheten är via benchmarks. Det är därför du inte kan visa benchmarks som visar 800 gflops, för de existerar inte. I teorin kanske, men i praktiken blir det annat. Man kanske kan räkna ut hur mycket watt 800 gflops borde dra, och se att det blir typ 300(?) watt, men det finns ju inga 300 watts Xeons, vilket betyder att Xeons inte kan nå upp till 800 gflops. 150 watt kanske bara räcker till 300 gflops? Vilket ändå är väldigt bra, med tanke på att POWER8 når 400 gflops på 250(?) watt.

Jag jobbar med HFT, bygger tradingstrategier för sånt. Och ja, det är en hemlig värld.

Sant. Men det är typiskt en desktop arbetslast du beskriver. En server är intresserad av att betjäna många klienter, t.ex. stora aktiebörs servrar vill ju betjäna alla börsrobotar som är inne och handlar, så genomströmning är mycket viktigt för aktiebörser. En klient, dvs en bank eller en tradingfirma som skickar ordrar in till börsen, vill ha så låg latency som möjligt för att vara snabbast. Det är två olika scenarior, en betjänar så många som möjligt, och en blir betjänad så snabbt som möjligt. Klient vs server.

SPARCs specialgren är alla scenarior där det gäller att göra så mycket arbete som möjligt inom ett tidsintervall. Och där visar alla dessa 20 benchmarks att den hinner med mycket mer arbete än x86. Sen finns det även benchmarks som använder acceleratorer: kryptering, komprimering och databaser. Och SPARC M7 krypterar och komprimerar gratis. Databas acceleratorn är effektiv, upp till 10.8x snabbare. Men det finns flera benchmarks som bara handlar om att trycka igenom stora mängder data - och i alla såna scenarior så är SPARC M7 mycket snabbare än x86. Dvs serverlaster.

Så vadå, menar du att SPARC M7 har högre genomströmning och sämre latency än x86? Och att x86 har sämre genomströmning och bättre latency än M7? Precis det jag påstått hela tiden?

HPC sfären består av Xeons därför att de är billiga. Man kan inte bygga en HPC med svindyra SPARC cpuer. Jag har en slide här utav professor Torben Larsson vid Aalborg Universitet, i beräkningsvetenskap, och han skriver följande, först räknar han upp superdatorer på TOP500 och redovisar hur många 100.000 cores de har. Och flera av dem är CPU och GPU baserade. Professor Torben skriver:
http://blog.accelereyes.com/blog/2011/06/27/jacket-lectures-l...
-"The way to performance is cores - MANY cores... Really MANY cores. ... and POWER"
-"Clear tendency towards using GPUs. GPUs are not more a high core general computation unit. The change happened in 2010"

Skälet att GPUs är så bra inom HPC är för att de har många cores. Precis det SPARC M7 har. x86 har inte många cores eller trådar. Jag har ju förklarat för dig att t.ex. inom Monte Carlo simuleringar så vill du göra så många simuleringar som möjligt inom ett tidsintervall. Och en SPARC M7 hinner göra många flera simuleringar än en x86. Och när man gör CFD eller numme, så vill man beräkna så många gridpunkter som möjligt. Så när man sysslar med HPC så vill man göra så mycket arbete som möjligt under några veckor/månader - och vem tror du har mest genomströmning? SPARC eller x86? Följaktligen har x86 jämförelsevis låga beräkningsprestanda. Om x86 INTE hade låga beräkningsprestanda skulle det inte finnas behov av att komplettera med GPU och Xeon Phi - x86s beräkningsprestanda räcker ju inte till. Jag tror inte Fujitsus kommande 100 Petaflop superdator med SPARC XIfx har några GPUer alls, t.ex.? Jag misstänker att det räcker med uteslutande SPARC XIfx cpuer med sina 1.100 Gflops - i klass med GPUer.

Angående låga beräkningsprestanda för x86, vi såg ju SPECint2006 och SPECfp2006 benchmarksen, där SPARC M7 återigen är snabbare än x86, ja M7 har rekordet. Så hur kan då "Xeons ha långt mer heltalskapacitet och flyttalskapacitet än SPARC M7" när den benchar lägre?

Om man ska vara strikt, så är en server något som kan betjäna klienter. Det spelar ingen roll om det är en klient eller många. Men de servrar jag pratar om, är stora affärservrar som servar tusentals klienter samtidigt, och detta har jag varit tydlig med. Det har x86 stora problem med, det är därför det bara finns Unix och Mainframes i den kategorin som kan betjäna maximalt antal tusen klienter samtidigt. Du kanske pratar om andra servrar, i betydelsen att så fort man betjänar en klient så är man en server. Och då förstår jag att även en enkel PC kan vara en server. Men riktigt stora servrar betjänar typiskt många klienter, och inte en enda klient - även om det antagligen finns såna.

Och när arbetet ökat maximalt, så är SPARC M7 bäst. x86 storknade först. POWER8 hängde med ett tag, men storknade även den. Kvar var SPARC M7.

Om working set får plats i cache, så pratar vi desktop användning. Inte server. Servers som betjänar tusentals användare får aldrig plats med working set i cachen. Men om nu datat får plats i cachen, så tycker jag det låter rimligt att en högt klockad cpu >4 GHz borde vara snabbare än en 2.5 GHz x86. Så jag gissar att POWER8 är snabbast i detta läge?

Jag tycker det är enklare för gemene man att se hur snabb hela cpun är. När man får veta enkeltrådsprestanda så säger det ingenting om hur snabb cpun är sammantaget. Du måste även veta hur många trådar det är. När du köper cpu så tittar du väl aldrig på enkelttrådsprestanda? Nej, du kollar benchmarks cpu mot cpu och sen bestämmer du dig. Du vill ha en så snabb cpu som möjligt, inte så snabb enkeltrådsprestanda som möjligt. Om folk verkligen tyckte enkeltrådsprestanda var ett bra mått, skulle det finnas i alla benchmarks, istället för som nu: cpu mot cpu.

Den smala nischen är alla scenarior där man vill trycka igenom stora mängder arbete på kortast tid, typ betjäna tusentals klienter.

Jag tror inte någon klassar AMD Fury X som en CPU? Vem installerar Windows på en AMD gpu?

Återigen, jag håller med dig om att SPARC M7 inte är världens snabbaste cpu. Det finns saker som x86 är snabbare på, t.ex. små datamängder. Vad tycker du jag ska ändra titeln till? "Världens snabbaste server-cpu" då?

Anser du att x86 är den "rätta" cpun, som egentligen borde vunnit detta Hadoop benchmark? Visst var det så att 32 st Xeon servrar med dubbla cpuer tog 1000 sekunder på sig, medan den ensamma M7-4 servern tog 4000 sekunder på sig - men hur får du det till att SPARC M7 cpun var långsammare på detta benchmark? Menar du att 4st Xeon cpuer skulle prestera mycket bättre än M7-4 på detta benchmark?

Sant. När jag talar med sysadmins så säger de att det är enorm skillnad på vad stora Unix servrar klarar av, och vad x86 klarar av.

Helt sant att E7v3 presterade mycket bra på SAP benchmarks. Men den stora skillnaden mellan E7v3 och POWER8 och SPARC M7, är att Unix servrarna skalar långt uppåt. Det gör inte E7v3. Så på små laster, med få klienter, kan x86 vara mycket bra. Men när du ökar lasten väldigt mycket så hänger inte x86 med. T.ex. SAP rekordet ligger på 844.000 saps (det är en Fujitsu SPARC M10-4S server med 32 st SPARC64 cpuer) medan x86 rekordet ligger typ kring 300-400.000. Nu skalar SAP väldigt dåligt, eftersom det inte går att köra klustrat, så du måste ha en stor scale-up server. Och jag misstänker att om Fujitsu benchade med 64st cpuer, skulle deras resultat bli typ 850.000 saps. Så att öka 100.000 saps på redan höga nivåer - är väldigt mycket.

Återigen, teori och praktik skiljer på sig mycket. Hur mycket Agner Fog säger är en sak, men riktiga benchmarks är en annan. Så visa mig benchmarks och jag byter åsikt direkt.

Angående att Fujitsus kommande SPARC XIfx cpu ska nå 1.100 gflops - jag håller med dig. Jag ska kanske sluta prata om den förrän vi ser riktiga benchmarks på den. För teori är en sak, praktik en annan. Däremot tror jag att om en cpu är snabbare på SPECint2006 och SPECfp2006 så borde den även ha högre praktisk gflops? T.ex. IBM påstår ju att sin POWER8 har 230 GB/sek bandbredd och SPARC M7 har 160 GB/sek enligt Oracle, men i praktiska benchmarks, så har SPARC M7 dubbelt så bra resultat (kolla STREAM benchmarken). Teori är en sak, praktik en annan.

Skälet att jag accepterar det som sanning, är att det låter rimligt och korrekt. En POWER8 ligger på 400 gflops i praktiken. Och x86 bör göra detsamma (vilket är extremt bra eftersom POWER8 har hela 250(?) watt och x86 har 150 watt). Professor Torben Larsen vid Aalborg Universitet, har en slide där han visar gflops utvecklingen genom tiden och han har plottat många olika Xeon cpuer. Nu slutar grafen vid 2010, men om man extrapolerar och fortsätter samma linje bortåt, så hamnar man på 400 gflops år 2015. Man hamnar inte på 800 gflops, det skulle knäcka grafen rejält.

Du verkar tro att den teoretiska siffran på 800 gflops är vad x86 uppnår i praktiken. Det tror inte jag. Jag vill se benchmarks, innan du övertygar mig.

Och det blir en övning åt författaren att visa benchmarks från verkligheten.

Jag känner till att de största Mainframes kan hantera 10 TB RAM. Men jag är skeptisk till att en enda Mainframe cpu kan hantera det? Jag tror det krävs många flera cpuer, full bestyckning.

Jag känner till att Maifnrames har långt bättre I/O än x86 och (antagligen) Unixservrar. Men när IBM påstår att en Mainframe kan ersätta 1.500st x86 servrar - det är lite för mycket. Vad händer om 20 av x86 servrarna börjar göra lite krävande arbete? Mainframen kommer aldrig klara av det. Det är som när IBM påstår att en POWER8 är 50x snabbare än en x86 upp till 1.000x snabbare - då har antagligen IBM jämfört mot en antik Pentium2 som idlar. Påståendena stämmer helt enkelt inte. Du kommer med inlägg efter inlägg om hur SPARC M7 inte är snabbast i alla scenarion, och som det ser ut är Mainframen snabbare endast på scenariot att alla x86 servrar idlar - så du borde inte gilla IBMs påståenden hur snabba Mainframes är.

Du får gärna visa benchmarks eller nåt som visar att de kan göra det realtids på Big Data. Jag har svårt att tro att någon kan göra det på t.ex. Petabyte data.

Nej, det stämmer inte att SGI påstår det finns kunder som kör affärssystem och databaser på deras UV2000. Jag har själv mailat dem och frågat. Du får gärna länka.

Jag känner till detta. Min poäng är att en SGI UV2000 med 10.000 tals kärnor, kan bara köra HPC laster, dvs typiska kluster laster. Det finns ingen som kör scale-up affärssystem på en SGI UV2000. Så i praktiken så beter sig UV2000 som ett kluster, för det är det är den enda den klarar av att köra. Oavsett vad som står i SGIs reklamblad. SGI håller på att släppa sin UV300H som faktiskt klarar av databaser och affärssystem, men den är helt annorlunda konstruerad och stannar på 16 sockets, eller är det 32? Men om man kunde köra scale-up affärsystem på en UV2000 skulle det inte finnas behov av en UV300H. SGI säger också i flera artiklar att det inte går att köra affärssystem på en UV2000, att du måste ha en UV300H.

Jag har inte sagt att SPARC S4 kärnan är snabbare än POWER och x86. Det har väl SPARC aldrig varit efter Coolthreads cpuerna (Fujitsu är en annan sak - de har starka kärnor eftersom de kör SPARC64). Oracle SPARC får inte sin hastighet genom kärnorna, istället satsar SPARC på massiv genomströmning, dvs uträtta så mycket arbete som möjligt på kortast tid.

Om du tänker dig en x86 som en Porsche, snabb som attan, men kan transportera två personer på X sekunder. Då skulle O-SPARC (Oracle SPARC) motsvara en buss, den åker inte alls lika snabbt som Porsche, men transporterar 100 personer på 2X sekunder. SPARC satsar på att hantera stora datamängder, betjäna så många som möjligt på kort tid. Det är alltså en typisk server cpu. x86 är mer en desktop, eftersom den kan betjäna en enda användare snabbt pga x86 klarar bara små laster - men öka arbetet mycket och x86 storknar snabbt. SPARC kommer bara tuffa på, som ett tåg. (När en SPARC T1 var 50x snabbare än x86 på webserver - så var det på stora mängder klienter. På några få klienter var x86 snabbare, men x86 stötte på sin maxgräns snart och bröt ihop medan T1 fortsatte uppåt långt vidare och kunde betjäna 50x fler klienter. T1 hade förstås också sin gräns där den bröt ihop, men den gränsen låg längre bort än 50x). Kör både M7 och x86 t.ex. 4 trådar, så blir x86 klar snabbare. Men ingen kör så små laster i verkligheten på en High End Enterprise server. Där är det tusentals användare och enorma laster utan avbrott 24/7.

Det är lite grand som GPU. Inte många (förutom du) skulle säga att en CPU är snabbare på beräkningar än en GPU. En GPU kan nå >1.000 Gflop, medan en x86 CPU typiskt når 400 Gflops. Ändå (om vi följer din logik) så är CPUn bättre på beräkningar eftersom en GPU har ganska hög latency, en CPU har lägre latency. Det tar lång tid att sparka igång en GPU, och en x86 CPU går det snabbt att få igång. T.ex. skulle man köra 4 trådar samtidigt så blir x86 CPUn klar tidigare. Men en GPU har 2048 trådar eller fler, så därför tycker de flesta att en GPU är bättre på beräkningar eftersom en GPU kan hantera stora mängder beräkningar på kortare tid än en CPU. Men i detta fall skulle du säga "jamen 1000 gflops för Nvidia är inte imponerande om du betänker att CPUn har 50(?)% lägre latency, alltså är det fel att säga att Nvidia är snabbare på beräkningar, egentligen är en x86 snabbare!" - precis som du säger om SPARC M7 vs x86.

Det är också skälet att en x86 cpu har låga beräkningsprestanda, eftersom den har så få cores och trådar. Helst ska man ha 100 tals trådar, eller 1000 tals trådar. Det är därför en HPC superdator har många många cpuer och cores. Ju fler trådar, desto mer arbete klarar en server cpu av på samma tid på en desktopcpu.

Håller du med om att SPARC M7 är byggd för genomströmning och klarar av stora mängder arbete mycket snabbare än x86? Och att x86 klarar av små mängder arbete snabbare än SPARC M7?

Återigen, SPARC som är en serverprocessor, är byggd för att trycka igenom enorma mängder arbete på kortast tid. Det är inte x86. Även om man inte använde acceleratorerna skulle M7 enkelt vinna alla benchmarks där det handlar om att trycka igenom stora mängder arbete på kortast tid, därför att SPARC är byggd för exakt det, den har t.ex. 256 trådar och x86 har 36 trådar. T.ex. Neurala nätverk benchmarksen som mest handlar om Linjär Algebra, tror jag inte använder någon accelerator alls, som t.ex. databas acceleratorn. Det handlar bara om att köra många trådar, precis som GPU.

Jaså du tycker enkeltrådsprestanda måste vara det viktigaste? IBM tycker det viktigaste måste vara core prestanda (därför att IBM inte har en chans när man mäter cpu mot cpu mot SPARC, så IBM har slutat jämföra cpu mot cpu). Intel verkar presentera en hel del benchmarks där de mäter cpu mot andra cpuer. Så vilket mått ska man använda när vi diskuterar vilken cpu som är snabbast?

1) Om du får veta hur mycket arbete en tråd klarar av på en viss tid, vet du då hur stora SAP/databas/Hadoop/etc laster den cpun klarar av, och på vilken tid? Nej, du informationen är ofullständig - hur många trådar har cpun totalt? Har den 2 trådar, eller 2048 trådar?

2) Om du får veta hur mycket arbete en core klarar av på en viss tid, vet du då hur stora SAP/databas/Hadoop/etc laster den cpun klarar av, och på vilken tid? Nej, du behöver mer information - hur många cores har cpun totalt? Har den 2 cores, eller 32 cores?

3) Om du får veta hur mycket arbete en cpu klarar av på en viss tid, vet du då hur stora SAP/databas/Hadoop/etc laster den cpun klarar av, och på vilken tid? Japp, du behöver inte mer information.

Vilket mått tycker du är meningsfullast? En siffra, eller tvingas uppge flera siffror? Varför inte stanna där, varför inte tvingas uppge en hel drös med siffror?

Japp, på alla hörnfall där det gäller att trycka igenom enorma mängder arbete på kortast möjliga tid, dvs serverlaster.

...

Du är helt otrolig. Du blir sur över att jag vägrar acceptera din siffra på att 2699v3 når ~800 GFlops? Återigen, jag accepterar inte det pga siffran låter inte rimlig. Det låter inte vettigt helt enkelt. Tidigare accepterade jag något du påstod utan bevis, därför att just det påståendet lät vettigt. Men detta påstående är inte vettigt, jag är skeptisk, jag vill se en benchmark. Är det för mycket begärt att du backar upp märkliga påståenden?

Det vetenskapliga metoden är att backa upp sina påståenden med bevis, speciellt om påståendena är orimliga. Att bli sur för att någon kräver bevis - är ju ytterst ovetenskapligt. Det är bara människor utan vetenskaplig träning som kräver det, typ fanatiska religiösa människor "Ja, gud existerar, det måste du acceptera för annars blir jag sur". Låter det rimligt att tro på vad folk säger utan bevis? Du har skrivit många märkliga saker genom åren, men detta tar nog priset. Du drar så många förhastade slutsatser eftersom du läser länkar fel, så man vill gärna se bevis för alla märkliga påståenden du lägger upp, t.ex. när du tror att två st E7v3 cpuer är dubbelt så snabb på SAP - men det visade sig vara fyra st E7v3 cpuer, vilket du missade.

Istället för att spekulera och teoretisera, så bör du posta en länk, eller att @Tomika kör en benchmark. @Tomika, ställer du upp?

Eller, wtf, jag googlar lite snabbt istället så du kanske ändrar åsikt om du ser ett bevis. Ok, här är en länk i den grå rutan som säger att teoretiskt så når TVÅ st E5-2699v3 ända upp till 1324.8 GFlops, dvs 662 GFlops per cpu. Men, ifall man kan parallellisera 95% av koden - dvs man har nästan ett idealiskt dröm scenario - så når dessa båda E5-2699v3 teoretiskt 482 Gflops, dvs 241 Gflops per cpu i teorin pga Amdahls lag. I praktiken blir siffran rimligen lägre. Siffran 242 Gflops är en bra bit ifrån de 800 gflops som du kräver att jag ska acceptera för en enda E5-2699v3. Förstår du nu varför jag tycker även detta ditt påstående är orimligt? Siffran 800 gflops för en cpu låter inte rimlig, när t.ex. POWER8 ligger på 400 gflops styck. Och POWER8 är en rejäl server cpu som kanske ligger på 250 watt, dvs har mer resurser än x86. Det är inte rimligt att en 150 watt cpu är dubbelt så snabb som en POWER8.
https://www.pugetsystems.com/labs/articles/Intel-Xeon-E5-v3-H...
"...Just because your program runs almost 4 times faster with 4 cores does not mean it will run 36 times faster with a dual 18-core system...

To evaluate the new E5-2699 v3 processors under the influence of Amdahl’s Law, observe that the speedup is the “effective” core count as far as performance goes. To estimate the relative performance of the new processors we use the theoretical peak double precision floating point performance measured in GFLOPS.

performance = CPU cores * sockets * Clock speed (GHz) * AVX2 vector length and FMA3 (16)

for a dual E5-2699v3 system that would be

performance = 18 * 2 * 2.3 * 16 = 1324.8 GFLOPS

Now at a parallel fraction of .95 Amdahl’s law gives us;

effective number of cores = 1/( 1-.95) + .95/36) = 13.1

this give a performance at P = .95 of

performance(P=.95) = 13.1 * 2.3 * 16 = 482 GFLOPS"

Återigen, du får helt enkelt visa en benchmark innan jag tror dig.

Du vill ha låg latency för att få realtime Big Data analyser? Fel igen. Du kan inte realtidsanalysera Big Data. Det går inte, Big Data är för mycket data, 50 GB räknas inte som Big Data. För att öka hastigheten på analysen, så kan man räkna fram vissa parametrar över natten utifrån Big Data. Mha dessa parametrar så kör man algoritmer som går snabbt att beräkna. Så man aggregerar all Big Data och kokar ned det till vissa parametrar under natten, som du sen använder i andra algoritmer.

Är detta andra eller tredje invändningen du har mot Oracles "tillrättalagda" Hadoop benchmark? Du försöker invalidera Oracles Hadoop benchmark på flera olika sätt. Du har ju inte ens börjat invända mot de andra benchmarken. Varför har du så många invändningar mot Oracles benchmarks? Jag själv, när jag såg alla POWER7 benchmarks, så gratulerade jag, och accepterade att POWER7 var snabbare än Suns cpuer då. Du verkar ha svårt att acceptera att någon cpu kan vara snabbare än x86, och du avfärdar alla Oracle benchmarks. Låter det så orimligt i dina öron att en 10 miljarder, 250 watt, 32 cores och 256 trådar cpu - är snabbare än en x86 cpu som har hälften av allt? Du vill verkligen inte tro det, så du letar och letar efter invändningar för att hitta något som låter dig ogiltigförklara Oracles alla 20 benchmarks. Det värsta är att dina invändningar är inte ens vettiga, det känns nästan som att du är oseriös och trollar? Ok om du hade vettiga invändningar, men det har du ju inte. "DAX sitter på ett separat chip" - långbänk. "Hadoop 32 node klustret med dubbla x86 cpuer är snabbare än en SPARC M7-4 server" - långbänk, "enkeltrådsprestanda är det viktigaste, alltså är x86 snabbare än SPARC M7" - långbänk, etc etc. Det är helt enkelt inte vettiga saker du försöker leda i bevis, och därför kan du inte posta benchmarks - för dina påståenden inte är sanna.

Bara när jag hör något orimligt letar jag efter invändningar för att invalidera benchmarken, men om det låter rimligt så letar jag inte för då är det antagligen sant. I detta fall låter det rimligt att en cpu som har dubbelt av allt, är dubbelt så snabb? Eller?

Om en Mainframe cpu är klenare än en x86, hur kan då en Mainframe med 64 cpuer, ersätta 1.500st x86 servrar? Jo, ifall alla idlar! Tycker du detta är ett korrekt påstående utav IBM: "En Mainframe kan ersätta 1.500 st x86 servrar"? Låter det inte orimligt? Så fort jag hör ett påstående så tänker jag automatiskt "Är det rimligt? Kan det vara sant?". Ofta är det orimliga påståenden. Men du tänker inte så kritiskt?

Jag kan starta upp 5st Mainframes på min laptop mha emulatorn TurboHercules, som alla idlar. Vad tror du IBM tycker om jag påstår att min laptop kan ersätta fem st Mainframes?

En SPARC M7 kan addressera 2TB RAM, vilket jag visat dig länkar på. Oracle har valt 512 MB RAM dock i sina senaste M7 servrar, lite oklart varför. Kanske för att tvinga kunder att köra Oracles egna databas? Om du vill köra databaser med benkrossande hastighet, så måste du använda SPARC M7 servrar, de är upp till 10x snabbare än andra servrar på databaser. Och ifall du vill göra stora Big Data analyser, så måste du använda Oracles egen databas - därför att den kan komprimera gratis, så t.ex. 512 MB RAM kan hantera 5TB databas. IBMs databas DB2 kan inte komprimera data gratis (förrän den skrivs om till att utnyttja M7s nya funktioner) så då är du fast vid 512 MB RAM - vilket är för lite. Så vill du köra stora mängder data med svindlande hastighet, så måste du köra Oracles egen databas, på Oracles egen server M7. Om Oracles servrar hade tillåtit 2TB per CPU, skulle deras M7-16 hanterat 32 TB RAM (precis som Oracles föregångare M7-32) och då hade du kunnat köra IBMs databas DB2 på den. Det går inte nu.

Mainframes styrka är I/O, ja. Inte cpu. Mainframes kan ha 296.000 I/O kanaler. Men vad tror du skulle hända om man hängde på några x86 cpuer lika många I/O kanaler? Jo, x86 servern skulle krosa Mainframen i cpu och I/O. Men en Mainframe har överlägsen RAS, du kan byta allt under drift. T.ex. vissa Mainframes har tre cpuer som gör samma beräkningar, och ifall en cpu beräknar annorlunda, så stängs den av och IBM larmas. Vissa SPARC (och Mainframe cpuer) kan backa tillbaka och spela upp en cpu instruktion igen ifall det blev något fel. Såna här saker kan bara stora Unix servrar och Mainframes, och det är därför de är high end - pålitliga, dvs RAS. Det är inte så konstigt att det pålitliga ZFS kommer från Sun som gör High End servrar med hög RAS. High End = RAS. Ett desktop företag som Microsoft skulle aldrig skapat ZFS.

Angående att en Maifnrame cpu kan addressera 10 TB RAM tycker jag låter lite märkligt, och vill se en länk på. Jag har tänkt lite på detta och kommit fram till följande: föregångaren SPARC M6-32 kan hantera 32 TB RAM, och vi vet att varje M6 cpu kan hantera 1TB RAM var. Så vad händer om du har en enda M6 cpu och stoppar i 32TB RAM? Jag tycker det låter märkligt ifall en enda M6 cpu kan hantera alla 32 TB RAM? Behövs det inte 32 st cpuer för det? T.ex om du har en dual x86 moderkort som kan ta 1 TB, så brukar det vara så att första cpun hanterar 512MB och ifall du stoppar i en till cpu, så kan du stoppa i 512MB RAM igen, så du har totalt 1TB RAM. Och ifall du bara har en cpu, så stannar det vid 512 MB RAM. På samma sätt låter det rimligt att en M6 cpu, kan bara hantera 1TB RAM även om du har 32 TB RAM i servern. Därför tycker jag det låter märkligt ifall en ensam Mainframe cpu kan hantera 10 TB RAM, behövs det inte fler cpuer för det? Jag vet att IBMs största Mainframe går upp till 10 TB RAM, men jag funderade fram att det förutsätter att du stoppat i max antal cpuer, dvs, typ 24 st cpuer. Så du får nog tyvärr visa länk på detta också om du vill övertyga mig

Ett kluster som molnet, består av många billiga low end servrar. Det gör inget om en kraschar, det är bara att koppla in en ny. Typiskt har low end servrar upp till 4 cpuer eller 8 cpuer. Och de har ingen RAS att tala om, t.ex. kan du byta moderkortet under drift? De har väl ECC, men inte checksummor på alla beräkningar som görs, etc. De är inte pålitliga.

High end servrar har upp till 64 cpuer, och kör mjukvara som inte kan parallelliseras. Därför behöver du en enda stor och snabb server, du kan inte köra många småservrar. Typiskt körs stora affärssystem och databaser som betjänar många tusen användare. Om servern kraschar så är det mycket illa för ett företag. Så high end servrar karakterisas av mycket god RAS, dvs pålitlighet. Och det är RAS som är det dyra. Ett enterprise företag kör hellre en långsam server som är pålitlig än en snabb server som räknar fel och kraschbenägen. Vad händer om finansiella beräkningar blir fel, pga inga dubbelkontroller av beräkningar? Katastrof.

Jag tycker det är talande att du tycker Xeon småservrar är high end. Du är helt klart inte vidare bekant med den världen, det är inte så konstigt att du har fått saker om bakfoten.

Jag citerade Tomika som kör en E5-2699v3 privat.

Java kom först, och C# började som en kopia utav Java. I början var de väldigt lika, ibland kunde man nästan inte se skillnad mellan språken om man bara läste koden. Innan C# hade Microsoft sin MFC som var ett riktigt härke. Men vad du än väljer, C# och Java är mycket lika, typ som Svenska och Norska.

På stora system, typ aktiebörser, stora affärsservrar, stora databasservrar, etc - alltså STORA system (servrar som väger 1.000kg) så används uteslutande Java/C/C++. C# existerar inte på stora system eftersom Windows inte körs på stora system. Alla stora system kör RISC cpuer såsom SPARC och POWER, och x86 finns inte på såna stora system. Det har nu senaste månaderna blivit ändring på det, och x86 har nu börjat dyka upp på medelstora system. Men de största systemen kör uteslutande SPARC/POWER - och Windows existerar inte på såna cpuer. Det betyder att stora servrar uteslutande kör Java / C / C++. Java har dessutom högre prestanda än C#, men det är inte så himla viktigt för en hobby programmerare.

C# existerar på klienterna, eftersom de ofta kör Windows. Där är C# vanligt. De stora back end servrarna kör Java, klienterna kör ofta C#. Ibland kör ju klienterna också Java / C / C++, men C# är vanligt på klienterna. Som hobbyprogrammerare kommer du aldrig få komma i närheten av de stora viktiga servrarna (det är bara mycket erfarna proffs som får göra det), så du kommer uteslutande att få jobba med klienterna, dvs C# vore nog lämpligt.

Själva språket Java utvecklas ganska långsamt, och det är en medveten strategi utav Oracle/Sun. Sun ville inte stoppa in allt som var nytt och hett och på mode, därför att några år senare kanske det är helt ute. Sun stoppade bara in saker i Java som man visste var tidlöst och alltid höll sig - dvs Enterprise. Enterprise kännetecknas av mycket lång support, decennier. En stor server ska bara gå och gå i tiotals år, man vill inte omkompilera och ominstallera så fort du uppgraderat Java eller nåt annat. Allt ska vara exakt likadant som det var för 10-20 år sen - dvs Enterprise. Strategin var också att själva Java biblioteken skulle utvecklas mycket snabbt, det var Suns strategi. Lika snabbt som C# utvecklas, lika snabbt utvecklas Java biblioteken.

C# har en annan strategi, det är inte Enterprise. Det körs inte på stora backend servrar som väger ett ton (Windows existerar inte på såna servrar) så C# är främst riktad mot desktop. Det betyder att det gör inget om man tvingas omkompilera och ominstallera och fnula, så fort du uppgraderat .NET eller nåt annat. En desktop ska ju inte ha upptime på decennier, så det gör inget om du hela tiden måste fnula med C# uppgraderingar. Därför stoppar Microsoft in alla möjliga funktioner som finns i C#, det senaste och hetaste. Det leder till att själva språket C# växer snabbt och utvecklas snabbt. Men det är mycket möjligt att om några år så kanske det visar sig att en speciell funktion inte alls var bra att lägga in i C#. C# är mer, utvecklas snabbt med det senaste och hetaste. Java är mer, långsamt och eftertänksamt.

Det är två olika strategier. Desktop eller Enterprise. Och som hobbyprogrammerare kommer du bara jobba på desktop. Men självklart kan du även köra Java program på desktop, utan problem, tex Minecraft är skriven i Java. NASDAQ, aktiebörsen är skriven i Java.

Själv tycker jag det är bra att inte måla in sig i ett hörn. T.ex. Microsoft hade sin teknik Silverlight, som senare lades ned. Jag vill lära mig så generella saker som möjligt, som körs på många plattformar, inte bara på Windows. Sprida mina risker.

Men oavsett vilket språk du väljer, så kan du lätt byta mellan dem. Det som skiljer är biblioteken, det tar ett bra tag att lära sig dem utantill. Själva språken är hyfsat lika, C# är modernare med massor av heta nya funktioner (som LISP har haft sedan 1969 typ)

SUPERMICRO X10SAT funkade med lite strul. UEFI bios var det som gällde, och skriva kommandon från UEFI prompten.

Jag kollar på sidan 6 i länken från SICS. Sidan heter "M7 Processor" och texten lyder "32 SPARC Cores" etc. Och det är exakt samma bild som jag länkade till här:
http://chucksblog.typepad.com/.a/6a00d83451be8f69e201b8d16b81...
fast på din sid 6 ser man texten också.

Låt oss betrakta din bild. Där ser man på ömse sidor två små rektanglar, med text "ACCELERATORS / MEMORY CONTROL". Och det är på dessa små rektanglar där DAX sitter. Så du menar att dessa Rektanglar (kallad DAX-R hädanefter för att förkorta), inte sitter på chippet. Du menar nåt i stil med att Oracle etsat fram dessa små DAX-R chip separat och lagt dem på samma paket en bit ifrån chippet.

På bilden tycker jag det ser ut som att DAX-R är en bit utav chippet. Jag tycker det låter märkligt att Oracle etsar fram DAX-R chippen separat, det är ju inte så många transistorer det är fråga om. Om Oracle klämt in 10 miljarder transistorer så kan de väl klämma in 10.1 miljarder transistorer som DAX-R kanske tar upp. Att accelera t.ex. databaser tycker jag verkar effektivast att göra det rätt i chippet, att MEMORY CONTROLLER tar hand om den biten.

Jag kan förstå att ifall man ska bygga in nåt stort, typ GPU eller APU så kanske man vill etsa fram ett separat chip och sen lägga dem nära varandra på ett paket - eftersom man överskrider sin transistorbudget.

Jag tycker det ser ut som att DAX-R sitter på samma chip, och jag tycker inte det ser ut som att det är tre separata chip som lagts på samma paket, vilket du påstår: vänster DAX-R, cpu och höger DAX-R. Det låter inte vettigt ur ingenjörssynpunkt att etsa fram tre olika chipp när det är så lite yta vi pratar om.

På vad baserar du din åsikt? För det är väl en åsikt, eller har du någon information som du grundar din tro på (att det är tre olika chip)? Och det är pga din tro du tycker du att det är rättvist att börja plocka in externa diskreta komprimeringskort som 89xx och externa beräkningskort som Xeon Phi när man benchar cpu mot cpu, som du säger: "vad är skillnaden??".

Ska jag maila Oracle och fråga om DAX-R transistorerna sitter på samma cpu, eller om det är separata chip som etsats fram, som man lagt på samma paket?

Jag tror inte jag sagt att SPARC M7 är en general purpose cpu? Men däremot har jag sagt att M7 är mer generell än de gamla cool threads SPARC T1 cpuerna på 80 watt, som faktiskt hade många klena trådar. Dessa M7 trådar är starka. Det finns folk som tror att M7 också har samma svaga trådar som SPARC T1, men det stämmer alltså inte. M7 är mer generell än T1, och det har jag alltid hävdat. Från... T4(?) cpun kan en core också dedikera alla resurser till en och samma tråd, istället för att köra flera trådar samtidigt - det gör tråden mycket starkare när den får en hel kärna för sig själv. Detta kunde inte SPARC T1. Så återigen, jag har länge hävdat att de nyare SPARC cpuerna är _generellare_, pga man kan få starka trådar om man vill det.

Visst, du har en poäng. SPARC M7 är ju faktiskt inte snabbaste cpun på precis allting, det finns saker som andra cpuer är snabbare på, typ, högre IPC, kanske snabbare ALU, lägre minnes latency, minneslatch, etc etc.

Vad bör jag ändra titeln till tycker du? Jag vill inte ändra titeln själv, därför att då kommer du komma med massor av invändningar i inlägg efter inlägg efter inlägg. Säg en titel, så slipper du dra det i långbänk.

Har du hört talas om Usain Bolt, världens snabbaste man? Jag fattar inte hur man kan utse honom till världens snabbaste man, enligt wikipedia "fastest person ever". Jag menar, hur snabb är han på maraton eller ultradistans? Det lär ju finnas personer som är snabbare än honom på olika distanser.

Har du hört talas om världens snabbaste bil? Eller MC? Eller flygplan? Eller snabbaste fågel, eller you name it. Jag tror knappast världens snabbaste bil är snabbast hela tiden, kanske finns det en bil som just kring 2.3 sekunder accelerar snabbare. Och det lär ju finnas bilar som har en snabbare pistong i just in motor, vid en viss tidpunkt. Hur kan man kalla en bil "världens snabbaste"??? Det är ju bluff och båg, det måste speciellt du förstå.

Hur kan man kalla någon världens bästa fotbollspelare? Dumt, det måste ju finnas någon som t.ex. skjuter med förbundna ögon bättre. Och en fotbollspelare måste ju vara bättre på exakt allting, annars kan man inte anse honom vara den bästa spelaren, eller hur?

När NVIDIA har snabbare grafikkort än AMD, hur i hela friden vet man det? Tänk om AMD har lägre latency i en speciell upplösning när man spelar just en speciell bana i ett speciellt spel? Eller, jag själv kanske har skrivit ett eget program som AMD är snabbare på i ett visst läge. Då kan man ju knappast säga att NVIDIA är snabbare, när det existerar corner cases där AMD faktiskt är snabbare.

Hur kan PS4 ha snabbare grafik än XBone??? Finns det inte ett enda spel där XBone är snabbare i ett visst läge, t.ex. på en speciell karta i ett spel - ja, då kan ju inte PS4 fanboysen hävda att PS4 har bättre grafik, därför att PS4 inte har bättre grafik i ALLA lägen. Bara i majoriteten av spelen och upplösningarna har PS4 bättre grafik - och det är ju ruffel och båg, eller hur?

Jag väntar mig alltså att du kommer gå in i alla trådar med inlägg efter inlägg efter inlägg och dra ALLTING i långbänk när någon säger t.ex. att SSD diskar är snabbare än SATA diskar: antag att man kopierar in 512 GB data till två diskar, en SSD som är just 512 GB stor, och en 8 TB SATA disk. SATA disken kommer inte bli långsammare eller ha problem, men det kommer SSD disken ha eftersom den blir full och då börjar den thrasha och bli extremt långsam.

Jag håller med om att Xeon klustret på 32 servrar, med totalt 64 cpuer, gör arbetet på 1000 sekunder, och en ensam SPARC M7 server med 4 cpuer gör samma arbete på 4000 sekunder. Jag hade varit glad om jag hade haft en enda av de Xeon servrarna med dubbla Xeon cpuer, med 10 core 20 trådar styck, det är ordentligt med tryck i dem tror jag.

Personligen blir jag väldigt imponerad över hur bra en ensam SPARC M7 server står sig mot ett helt x86 kluster med 32 servrar med dubbla Xeon. Jag förstår att du inte blir imponerad, och det är ok, folk blir imponerade av olika saker.

Du visar en Intel länk där en Xeon E5v3 är 2.5x snabbare än en Xeon E5v2 på TeraSort Hadoop benchmark. Och följaktligen är då SPARC M7 benchmarksen orättvis, därför att Oracle benchade mot ett gammalt kluster med v2 cpuer. Det är ditt resonemang.

Visst, låt mig analysera och bemöta ditt resonemang.
1) Antag att det nya x86 v3 klustret är 2.5x snabbare än det gamla x86 v2 klustret (genom extrapolation argumenterar du för att det nya v3 klustret borde vara 2.5x snabbare) - men isåfall är SPARC M7 ändå snabbare. En E5v2 cpu sorterar 8 GB/min, och du tror att en E5v3 borde sortera 2.5x snabbare, dvs 20 GB/min. En SPARC M7 gör 33 GB/min. Så det spelar ingen roll om E5v3 är 2.5x snabbare, x86 är ändå rejält långsammare.

2) E5v3 benchmarksen du länkar till på intels hemsida benchar 50 GB totalt. Det är ju missvisande. Hadoop använder man för Big Data, som inte lämpar sig att hantera på annat sätt än parallellt. Och Hadoop är parallellt, eftersom det är funktionellt. Funktionella språk har inga sidoeffekter -> i teorin går att parallellisera automatiskt så man slipper trådar och alla dessa race conditions och annat. Intels benchmarks använder servrar med 128 GB RAM, dvs hela datamängden på 50 GB kan köras från RAM och det är inte rättvist, det finns inte en chans att man ser 2.5x snabbare i verkligheten på riktiga big data. Oracle benchar 10 TB data, och det räknas som Big Data. Det är inte rättvist bencha 50 GB på x86, men 10 TB på SPARC M7? x86 är inte bra på att hantera massiv genomströmning, det är däremot SPARC M7 byggd för: stora mängder data och stora mängder många klienter - dvs riktiga serverlaster. Du vill ju gå ut på diskarna som man gör på riktigt, använda så mycket data att det inte får plats i RAM, etc etc för att få veta hur det funkar i produktion på riktigt. I verkligheten blir det mycket långsammare än att köra direkt från RAM. Inte nåt dröm fejkscenario som Intel gör. Samtidigt som du påstår att Oracle gör tillrättalagda benchmark så att "fel system vinner".

3) Intels benchmark som visar att Hadoop Terasort blir 2.5x snabbare med E5v3 än den gamla E5v2, den benchmarksen handlar egentligen om kryptering. I benchmarken kör Intel sin Terasort benchmark med kryptering, och den nya E5v3 sorterar 50 GB data, mer än dubbelt så snabbt när kryptering är påslaget. "As Figure 1 shows, E5-2699 v3 with encryption is more than 2.5X faster than the E5-2697".

Så benchmarken säger egentligen att E5v3 är 2.5x snabbare än E5v2 på kryptering pga nya inbyggda AES instruktioner som avlastar E5v3 cpun, men det betyder inte att E5v3 är 2.5x snabbare generellt på Hadoop. Det betyder bara att E5v3 är snabbare på kryptering.

Mao, så är det fel slutsats att ett nytt E5v3 kluster är 2.5x snabbare än det gamla E5v2 klustret på Hadoop, den korrekta slutsatsen är att krypteringen körs 2.5x snabbare. Så hur mycket snabbare blir då Hadoop på en E5v3 kluster? Vet inte, Hadoop består av mycket mer än bara kryptering, som bara är en liten del. Det är så mycket som spelar in i verkligheten när du har mycket data måste hela systemet vara snabbt, disk, I/O, ram, cpu, etc. Cpu prestanda är bara en del. Allt måste samspela. T.ex. vad händer med prestandan när man inte kan köra från RAM längre, och man måste ut till disk?

Så bara för att E5v3 är... 25%(?) snabbare än E5v2 när man kör okrypterat från RAM - så betyder det inte nödvändigtvis att Hadoop benchmarken blir 25% bättre på 10 TB big data.

Sammantaget från dessa tre punkter så är ditt resonemang felaktigt och logiken haltar igen.

Är det inte vettigt att normalisera tycker du? Så att man kan jämföra äpplen mot äpplen? Om t.ex. Intel benchar ett 32 node kluster med dual cpuer varje, och IBM benchar ett 8-node kluster med 4 cpuer i varje - hur kan man jämföra resultaten? Men om man normaliserar då går det att jämföra resultaten. Det är det som är själva poängen med normalisering. Det är inte vettigt att jämföra en amerikans inkomst i dollar från 1940 mot idag rakt av - man måste räkna om valutorna och normalisera så man får samma måttstock. Så man kan jämföra äpplen mot äpplen. Det Oracle gör, är att räkna ut hur mycket en cpu presterar, då kan man faktiskt jämföra cpu mot cpu. Oracle påstår att deras cpu är mycket snabbare på Hadoop, så Oracle presenterar cpu vs cpu värden. Det är ju fel att jämföra 1000 cpuer mot 70 cpuer - därav kan ingen slutsats dras vilken cpu som är snabbast. Man måste normalisera så det blir samma måttstock, dvs 1 cpu mot 1 cpu. Eller en server mot en server (då måste man normalisera igen så de har samma antal cpuer, etc). Hur gör du dina analyser om du aldrig normaliserar data? Hur kan du tro att du drar korrekta slutsatser? T.om i högstadiet förstår de att man inte kan jämföra äpplen mot päron?

Varför inte per CPU-tråd? Jo, därför att Oracle påstår att deras CPU är snabbast på detta. Oracle påstår inte att deras trådar, utan att deras cpuer är snabbast. Då kanske man ska jämföra cpu mot cpu? Om Oracle påstod att deras trådar var snabbast i världen, så måste de presentera siffror där de jämför tråd mot tråd, men det gör inte Oracle.

När IBM insåg för några år sen att Oracles SPARC cpuer kom ikapp och var snabbare än POWER, så lade IBM sin strategi och skiftade fokus bort från cpu till kärnor. Så IBM resonerade som att "POWER7 kärna är snabbare än SPARC kärna" (SANT på några benchmarks) så måste det betyda att "en POWER7 cpu snabbare än en SPARC cpu" (FALSKT. På alla(?) benchmarks var SPARC snabbare). Så, låter det korrekt när IBM presenterar benchmarks där en POWER7 core är snabbare, och sen presenterar slutsatsen att hela POWER7 cpun måste vara snabbare? Bencha äpplen och sen basunera ut att samma slutsats måste även gälla päron? Det låter exakt som hur du resonerar. Eller?

Så det är bara Oracle som skyltar med dessa rekord? Eh? Du är tydligen inte bekant med high end enterprise världen, men det är jag. Den som skryter mest om sina resultat är väl ändå IBM. T.ex. Sun lade ned TPC-C benchmarks helt därför att Sun inte tyckte det var vettiga real life arbetslaster, men IBM insisterade och fortsatte hela tiden med TPC-C och berättade hur bra IBM var på databaser och hur dåliga SPARC var. Till slut fick IBM till det rejält med ett POWER7 kluster som nådde hela 10 miljoner tmpc. IBMs föregångare P595 en POWER6 server med 32 st 5GHz cpuer och 2TB RAM (bara servern kostade $35 miljoner listpris!!!) hade också en bra siffra på 6 miljoner tmpc.

Så kom Oracle och köpte Sun och Oracle tog upp TPC-C igen och släppte en T5 server med 8 SPARC T5 cpuer och nådde 8.5 miljoner tmpc.
http://www.serverwatch.com/server-news/ibm-strikes-back-again...
Senare släppte Oracle ett TPC-C rekord med SPARC kluster med gamla Sun T3 servrar (från Sun tiden) som nådde 40 miljoner tmpc. Efter det slutade IBM släppa och prata om hur viktiga TPC-C benchmarks är.

När Oracle släppte sina T5 sparc servrar och krossade IBM, så fick IBM ändra strategi igen. Nu började IBM börja prata om att prestanda är inte så viktigt, det var såååå 2002 att prata om cpu prestanda, ingen bryr sig om prestanda längre:
http://blogs.wsj.com/digits/2013/03/27/ibm-fires-back-at-orac...
"...Companies today, Parris argued, have different priorities than the raw speed of chips...."

Under POWER7 tiden, när Sun hade det knackigt fanns det benchmarks över hela internet om hur bäst POWER7 cpun var och basunerade ut hur en POWER7 server kunde ersätta flera 100 x86 servrar. Jag imponerades och grävde lite hur en POWER7 server kunde ersätta flera 100 x86 servrar, hur i hela friden kunde en POWER7 server vara så fantastiskt snabb??? Jag upptäckte att IBM benchade en 4-socket POWER7 mot urgamla Pentium3 med 256 MB RAM och alla P3 idlade och arbetade typ 2-3% var. Då är det inte så konstigt att du kunde lyfta bort alla 100 P3 och ersätta med en enda POWER7 server. Det är IBMs aggressiva marknadsföring i ett nötskal.

Senare släppte IBM sin POWER8 som var snabbast ett tag, och återigen var det benchmarks över hela internet, och hur viktigt det är med prestanda. Så SPARC och POWER har turats om att vara snabbast, men iom Oracle ökar nu SPARC prestandan 100% varje generation. Och det inser IBM att det går inte att konkurrera med, så i fortsättningen blir det SPARC för hela slanten, när vi pratar högst prestanda.

IBM påstår att deras POWER8 är 50x snabbare än Intel Xeon, ända upp till 1.000x snabbare. Inga invändningar från din sida? IBM backar inte upp det med några benchmarks alls, utan bara lite vaga hänvisningar "enligt våra egna tester, som vi inte tänker visa er":
https://esj.com/articles/2014/04/25/softlayer-cloud-service.a...

Här är ett annat exempel. Vi ser att en Mainframe med 64 z10 cpuer kan ersätta 1.500st x86 servrar. Jisses vad snabb en Mainframe måste vara!
http://www-03.ibm.com/press/us/en/pressrelease/23592.wss
"...Single z10 equal to nearly 1,500 x86 servers.."
Men när man betänker att en Mainframe cpu är mycket långsammare än en Intel Xeon, så börjar man ju fundera på hur 64 långsamma cpuer kan ersätta 1.500 st x86 servrar? Jo, det visar sig att alla dessa urgamla P3 idlar allihopa och knappt uträttar något arbete. Somliga skulle säga att IBM försöker lura en att en z10 cpu är snabb som flera hundra st x86 cpuer?
Man kan ju emulera en Maifnrame cpu med "TurboHercules" på en x86 och få ut hyfsade mid sized Mainframe prestanda:
https://en.wikipedia.org/wiki/Hercules_%28emulator%29#Perform...

Här ser vi att IBM påstår att deras z196 Mainframe cpu är världens snabbaste cpu. Inga invändningar från din sida?
https://www-03.ibm.com/press/us/en/pressrelease/32414.wss

Det lustiga är att IBM aldrig släppt några benchmarks på sina Mainframe cpuer. När IBM har en bra cpu så postas benchmarks över hela internet och alla konkurrenter trash talkas, och massor med falska påståenden "en POWER8 är 50x snabbare än x86, upp till 1000x snabbare". Men aldrig ser man benchmarks med IBM Mainframes, finns inte en enda benchmark mot en x86 cpu någonstans, i något benchmark. Har aldrig släppts. Varför? Det här låter lite som vår SGI UV2000 diskssion där jag berättade att SGI aldrig släppt några enterprise business benchmarks såsom SAP någon gång - är det för att UV2000 inte kan köra SAP?

Enligt wikipedia så var IBM det första företaget som började med FUD och falsk marknadsföring på systematisk skala, dvs hela företaget sysslade med det som strategi, på alla nivåer. Tidigare har enstaka individer trash talkat sina konkurrenter, men IBM var först med att hela företaget gjorde det systematiskt:
https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt#Def...
IBM har alltid varit företaget med dåligt rykte, ända tills Microsoft tog över kronan, men MS har mjuknat på senare dagar. Under tiden har IBM aldrig upphört med sina fulspel. Varför kallas IBM "Big Blue"? Jo, det kommer att under en period hade IBM fler advokater (blå kostym) anställda än ingenjörer.

IBM har ju många patent, varför det? IBM drog in $2 miljarder årligen på patent trolling, enligt artikeln där Twitter betalade $36 miljoner till IBM:
http://arstechnica.com/business/2014/03/twitter-paid-36-milli...

En annan gång IBM hotade Sun med menlösa patent, varpå Suns advokater och ingenjörer sade att patenten är invalida att IBMs advokater borde skämmas. IBMs advokater rörde inte en min:
-Ok, ni kanske inte bryter mot dessa patent, men vi har tusentals patent. Ska vi åka hem och hitta några ni bryter emot, eller tänker ni betala $20 miljoner?
Sun betalade och IBMs advokater åkte vidare till nästa företag.
http://www.forbes.com/asap/2002/0624/044.html

Tidigt i Suns historia, så tänkte inte Sun på patent. En dag stämdes de utav IBM som hade ett patent som de inte borde fått, patentet sade att "om något är enklare, så blir det snabbare". Sun förlorade och var mycket nära konkurs. Efter det började Sun patentera allt möjligt som försvar mot IBM, berättar James Gosling, skaparen av Java:
http://nighthacks.com/roller/jag/entry/quite_the_firestorm

Så, nej, IBM har alltid haft ett mycket dåligt rykte och alltid FUDat, trashtalkat och patent trollat sina konkurrenter. Speciellt inom Mainframes, där har IBM mycket mycket dåligt rykte. IBM säljer typ 100 st Mainframes per år och ändå står Mainframes för typ 10% av IBMs enorma vinst. Mainframes är mycket mycket dyra och IBM gör allt för att behålla monopolet inom Mainframes - men alla fula metoder inom stordatorvärdlen hör inte vanliga människor som mest sitter med desktops. FUD sitter i IBMs dna. Jag jobbade med en VD som var f.d. IBM på ett stort företag en gång, som var den första att ta upp "men tänk om våra konkurrenter använder din ide för att FUDa oss då?". Ingen annan hade ens tänkt tanken, varken jag eller nån annan. Men IBM chefen var FUD första han tog upp. Och det var långsökt, kan inte berätta ideen här. FUD sitter i IBMs dna.

Oracle har sålt hårdvara i några få år och har inte hunnit posta så mycket benchmarks. Men visst, jag håller med dig om att Oracle också kör fulspel iom sina licenser. Jag tänker inte förneka det - rätt ska vara rätt. Jag vill bara att rätt infromation ska komma fram.

Här har vi ytterligare ett exempel på low end cpuer. Low end cpuer har en begränsad watt budget, och hela cpun kan inte överskrida den. Det var mycket prat om Apples senaste Mac Pro, den lilla svarta cylindern. Ett av problemen med dess Xeon cpu, som egentligen inte var så snabb, men den var dyr pga den kunde köra full belastning under lång tid. Xeon är byggda att belastas under lång tid. En i7 kunde utklassa Xeon under kortare tidsrymder, men under längre tid så höll Xeon högre belastning. Det var den stora skillnaden mellan i7 och Xeon. Så stod det i en intressant artikel jag läste på... anandtech(?).

En high end server cpu som M7, kan köras full belastning hela tiden, eftersom de har större watt budget och kanske vattenkyld och hela baletten. En 2699 kan inte köras under full belastning, efter ett tag börjar den slå av saker för att inte överskrida 150 watt. SPARC M7 har inte det problemet, de är byggda att köras hårt 24/7. Samma med enterprise SAS diskar, de är byggda att vara på länge, vanliga SATA diskar är inte byggda för det. Så jag undrar om inte prestanda på papperet låter bra för Xeon, men i verkligheten så finns risken att den överskrider 150 watt, och börjar slå av chipdelar - precis som du beskriver ovan (endast 4-6 kärnor används, resten i dvala). Jag har svårt att tro att endast 4-6 kärnor används effektivt på SPARC M7, och resten i dvala.

Men du har en cool setup. Vad använder du den till? Är det för att spela 4 spel samtidigt? Hur gör du det? Hur accessar du alla spelVM? Och varför?

Jag har erfarenhet utav extremt hög presterande kritiska servrar inom finansbranschen som alla känner till. Men idag jobbar jag med analysera finansiell data och bygga aktie tradingstrategier. Har alltid jobbat inom finans, har aldrig jobbat med eller för Sun eller Oracle. Jag är analytiker, som du kanske märker på hur jag dissekerar inlägg här och pekar ut fel. Arbetar med hur man ska göra korrekta analyser och vilka slutsatser man kan dra och vilka slutsatser man inte kan dra. Man får inte vara förhastad så man drar felaktiga slutsatser, för då blir man inte långlivad som analytiker. Jag har mest studerat matematik och matematisk statistik, men har också en civ.ing.examen i teoretisk datalogi.

DAX skiljer sig på sätt att det sitter direkt på chippet:
http://chucksblog.typepad.com/.a/6a00d83451be8f69e201b8d16b81...
Taget från
http://chucksblog.typepad.com/chucks_blog/2015/10/the-amazing...

Återigen, om du blandar in externa diskreta kort för x86, så kan även SPARC göra det. Och det vill inte jag, för det är inte rättvist att jämföra Enterprise kort med extrema resurser och prestanda mot en desktop?

Om du jämför en Volvo mot en Porsche och börjar blanda in propellerplan till Volvons sida, så kan Porsche ta in en rymdskyttel i jämförelsen, eftersom Porsche har mycket mer pengar. Och det vore inte rättvist att blanda in svindyra rymdskyttlar mot små propellerplan. Vad sägs om att vi bara jämför bil mot bil istället, när vi ändå pratar om vilken bil som är snabbast? Pratar vi vilket flygplan som är snabbast, eller pratar vi vilken bil som är snabbast? Du inser väl att man kan inte dra slutsatser om bilar, om du benchar mellan flygplan? Jag förstår inte riktigt vad som är problemet rent logiskt, att när man benchar, så ska man bencha äpplen mot äpplen, och inte äpplen mot päron?

Om du nu verkligen skulle ha ett externt x86 kort som hanterar komprimering och krypto så att Xeon kan köra Hadoop i full hastighet, så räcker det ändå inte till att utprestera M7 som är 4.6x snabbare på Hadoop. M7 är snabbare hur du än gör med externt kort eller ej, men du skriver ändå inlägg efter inlägg med invändningar om att egentligen är x86 snabbare. Jag fattar inte riktigt varför du alltid ska dra saker i långbänk i tråd efter tråd efter tråd efter tråd trots att siffrorna säger emot dig varje gång? Somliga skulle säga att du är lite vinklad, lite biased. Vägrar acceptera hårda fakta. "Jamen att SPARC T1 är 25x snabbare än Itanium är ju inte vidare imponerande om du betänker att..."

Du har blandat in Xeon Phi i en tidigare diskussion om SPARC vs x86. Jag tyckte inte det var rättvist att jämföra ett externt diskret beräkningskort mot en cpu då, och det tycker jag inte nu heller. Om nu det finns en flaskhals så är det naturligt att man köper in ett kort för att hantera problemet, men då tycker jag inte man kan tillskriva prestandaökningen till cpun? Det vore ju falsk marknadsföring: "AMD cpuer är lika snabba som Intel !!!" - förutsatt att du väljer bara den bästa procenten av AMD cpuer som klarar av hög överklockning, använder flytande kväve för kylningen, köper special RAM minne som också tål överklockning, etc. "Men om vi bortser från alla dessa moddar, så är AMD lika snabba som Intel!!!" - låter inte riktigt rätt i mina öron?

Den billigaste SPARC T7-1 kostar 320.000 kr. Det står i en tidigare post här. De är servercpuer och de kör Unix, inte Windows. Så du kan inte köra Windows program på dem. Man kan installera Linux på dem, tror jag - men det kommer antagligen inte funka bra jämfört med Solaris som är optimerat för SPARC. Så det är bara att undvika Linux.

Jag tror att Intel alltid tar det bästa beslutet för Intel - med den informationen man har just då, och med de förutsättningar man hade just då. Med facit i hand är det lätt att säga att Intel tagit fel beslut, men just då visste man inte det. Detta gäller alla, personer, företag, etc etc.

T.ex. var det en läsvärd artikel om hur stora mjukvarusystem kan vara dåligt kodade och bloatade. Och i efterhand med facit i hand, vill man bara slänga all kod och börja om från början. Och somliga gör det, men det är ett misstag. Vad får dig att tro att nästa version blir mycket bättre? Man skrev den bästa koden med de förutsättningar man hade just då. (Nu pratar jag stora mjukvarusystem. Inte några rader kod.)
http://www.joelonsoftware.com/articles/fog0000000069.html
"..."Well," [the new programmer] say, "look at this function. It is two pages long! None of this stuff belongs in there! I don't know what half of these API calls are for."

Before Borland's new spreadsheet for Windows shipped, Philippe Kahn, the colorful founder of Borland, was quoted a lot in the press bragging about how Quattro Pro would be much better than Microsoft Excel, because it was written from scratch. All new source code! As if source code rusted.

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that's kind of gross if it's not made out of all new material?

Back to that two page function. Yes, I know, it's just a simple function to display a window, but it has grown little hairs and stuff on it and nobody knows why. Well, I'll tell you why: those are bug fixes. One of them fixes that bug that Nancy had when she tried to install the thing on a computer that didn't have Internet Explorer. Another one fixes that bug that occurs in low memory conditions. Another one fixes that bug that occurred when the file is on a floppy disk and the user yanks out the disk in the middle. That LoadLibrary call is ugly but it makes the code work on old versions of Windows 95.

Each of these bugs took weeks of real-world usage before they were found. The programmer might have spent a couple of days reproducing the bug in the lab and fixing it. If it's like a lot of bugs, the fix might be one line of code, or it might even be a couple of characters, but a lot of work and time went into those two characters.

When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.

You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.

....

It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time. First of all, you probably don't even have the same programming team that worked on version one, so you don't actually have "more experience". You're just going to make most of the old mistakes again, and introduce some new problems that weren't in the original version.

The old mantra build one to throw away is dangerous when applied to large scale commercial applications. If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That's fine. You may want to refactor a class to make it easier to use. That's fine, too. But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly..."

Du ser inte skillnaden om något sitter på cpun, eller om det finns varianter av moderkortet som har funktionen?

Förrut ville du ju blanda in Xeon Phi beräkningskort också när vi pratade SPARC M7 mot x86 - vill du göra det igen? Varför inte blanda in GPUer också när du ändå håller på? Hur ska man kunna dra en slutsats om vilken cpu som är snabbast, om du börjar blanda in externa kort? Jag vill inte googla fram svindyra Enterprise hjälpkort som kostar miljontals kronor när man benchar cpu mot cpu, det vore inte rättvist mot x86. Hur kan du dra en korrekt slutsats vilken cpu som är snabbast, när du börjar blanda in externa diskreta kort? Man jämför äpplen mot äpplen, inte äpplen mot päron?

Vad tror du folk här på forumet skulle säga om swec benchade grafiken på en AMD A10-7850K med inbyggd grafik, mot en Intel cpu + Geforce GTX 980Ti och sedan deklarerade att Intel har snabbare grafik? Du ser inte problemet att bencha gpu mot cpu, och sen skriva slutsatsen om cpu mot cpu? Jag har försökt förklara det logiska felet du gör många gånger, men du ser fortfarande inte felet?

Fel system vinner? Om du nu får använda ett 89xx komprimeringskort i en x86 server så att den komprimerar och krypterar gratis precis som en M7, tror du att x86 blir så snabb då att den vinner alla benchmarks? T.ex. blir 10.8x snabbare i databaser och kan matcha en M7?

Fine, låt Xeon servern få mer RAM. Vad spelar det för roll. Tror du det ändrar benchmarks resultaten då? T.ex. att x86 blir 10.8x snabbare i databaser?

Visst, det kan finnas benchmarks där SPARC M7 förlorar. M7 är väl inte snabbare på exakt allting, snabbare ALU, snabbare register, snabbare minne, snabbare trådar, etc. Det finns saker som M7 inte är snabbare på. Så vad ska jag ändra titeln till, tycker du? Säg nåt som du blir nöjd med, så kanske du kan sluta posta inlägg efter inlägg efter inlägg med invändning efter invändning om hur mycket snabbare x86 egentligen är, trots dessa benchmarks där M7 demolerar? "Ja, jag ser att SPARC M7 är 4.6x snabbare än x86 på hadoop men det är ju knappast imponerande om du tänker på att... så egentligen är x86 snabbare!". Post efter post med liknande innehåll: "ja, jag ser att SPARC T1 är 25x gånger snabbare än Itanium, men det är ju knappast imponerande om du betänker att... så egentligen är x86 snabbare!"

Vad vill du att jag ändrar titeln till, så slipper du posta inlägg efter inlägg i tråd efter tråd efter tråd efter tråd efter tråd om hur felaktiga mina benchmarks/länkar är, och hur mycket snabbare x86 egentligen är? Utnötningstaktik?

Fin beräkning. Men kan du visa några real life benchmarks? Alla benchmarks jag har sett har angivit POWER8 till strax under 400 gflops, och Intel Xeon strax däromkring. Du har påstått nån liknande Gflops siffra förrut, och jag bad dig visa benchmarks, men då kunde du inte visa några benchmarks alls som stödde ditt påstående. Det kanske du kan visa nu?

T.ex. IBM påstår POWER8 ha 230 GB/sek minnesbandbredd. Och SPARC M7 har ju 160GB/sek. Men i riktiga benchmarks så har M7 dubbelt så bra bandbredd som POWER8:
https://blogs.oracle.com/BestPerf/entry/20151025_stream_sparc...
Mao, teori säger inte så mycket. Det är praktiska benchmarks som gäller.

Men du har helt rätt i att SPARC XIfx inte är släppt än, och det är inte riktigt rättvist att blanda in den. Jag kanske ska sluta prata om den förrän den släppts? Nåt jag undrar över, är hur många gflops M7 har. Den är ju typ 75% snabbare i SPECint2006 och SPECfp2006 än x86, vilka är beräkningar. Om nu x86 gör 400 gflops, så kanske M7 uppnår 75% extra, dvs 700 gflops?

SPARC tappat sedan Oracle? Möjligt. Sun tappade massa kunder mot slutet när det gick dåligt. Det var därför Sun öppnade all kod och sänkte priserna. Skänka bort och sänka priser gör man bara när man är desperat. Sun hade 30.000 kunder. Oracle har 300.000 enterprise kunder. Om Oracle kan få endast 15% att byta till deras specialdesignade servrar för att köra databaser 10x snabbare än andra, så ligger Oracle bra till. Och om Oracle dessutom sänker priserna för licensen om du kör SPARC, så kommer Oracle sälja ganska mycket servrar. Unix marknaden är vikande, men Oracles engineered systems marknad (dvs databasservrar) ökar i mycket snabb takt, den växer mycket bra.

Angående oberoende benchmarks, så tror jag flera av dem är verifierade utav extern part. T.ex. SPECint2006 borde ha kollats av någon extern för att få det officiellt, gissar jag. Samma med databas benchmarks, SAP, etc. Mao, jag tror att flera benchmarks är opartiska. Om de tvärtom faktiskt är partiska, så borde IBM och x86 också vara partiska, så då borde de jämna ut sig, om alla kör partiska benchmarks?

Bara för att förtydliga, eftersom SPARC M7 är dubbelt så snabb som x86, så betyder det inte att jag säger att SPARC teamet är dubbelt så bra som Intels Xeon team. Nej, jag tror alla teamen är ungefär lika bra, men de har olika förutsättningar och resurser till förfogande. Om Intel också hade Larry Ellison som sade "dubbla prestandan varje generation eller så får ni sparken, och ni får hur mycket pengar ni vill" så skulle det hända saker. Jag tror det kallas för eld-i-baken strategin?

Skälet att M7 har dubbla prestandan, är helt enkelt att M7 har ungefär dubbelt av allting:
-10 miljarder transistorer istället för 5.7 miljarder i Xeon E7v3
-250(?) Watt mot 150 watt för Xeon
-4.13 GHz mot 2.5GHz för Xeon
-32 cores mot 18 cores för Xeon
-256 trådar mot 36 trådar för Xeon
etc etc.

Då är det inte så konstigt att M7 blir dubbelt så snabb. Det vore konstigt om den INTE vore dubbelt så snabb. Å andra sidan, om Intel också började göra high-end Enterprise cpuer som sitter i stora vattenkylda servrar som väger 1,000kg styck, skulle Intel också kunna dubbla allting, dvs lika många transistorer, lika mycket watt, lika många cores, GHz, etc etc - och då är det högst troligt att båda cpuerna blir ungefär lika snabba.

Intel gör främst desktop cpuer och är inne på low-end Enterprise marknaden med upp till 8-sockets och begränsad RAS (tillförlitlighet) - då blir Xeon teamet bakbundna med hälften av alla resurser. Jag tycker Xeon presterar exceptionellt bra med tanke på att deras nisch är desktops och low end servrar.

Om du diskuterar prestanda per krona, så är det inget snack om saken. Du kan köpa flera x86 servrar för priset av den minsta SPARC M7-1 servern som kostar $40.000, dvs 320.000kr. Dessa bör vara snabbare. (Om du inte kör databaser, för då behöver du >10st x86 servrar för att utprestera SPARC M7-1, och så många lär kosta en slant). Så visst, då har du helt rätt i det du säger att ifall man får X antal kronor och ska bygga snabbaste x86 eller SPARC så är x86 lösning rimligtvis snabbare. Jag pratar dock om cpu vs cpu, på gammalt manligt sätt. Det är två olika diskussioner: bäst prestanda, eller prestanda per krona, vi verkar tala förbi varandra. Kanske därför debatten aldrig tar slut?

Jag tror att i majoriteten av dessa 20 benchmarks med M7, så är även POWER8 benchad förutom x86. IBM har inte alltid släppt benchmarks med önskad konfiguration utav POWER8, så Oracle fick väl jämföra mot det som var släppt.

Resonemanget är rimligt, och därför köper jag det. Mer eller mindre. Därför ber jag dig inte posta länkar, utsagan stämmer antagligen hyfsat.

Om du löser P-fullständiga problem så är troligtvis x86 snabbare, ja.

Det här får du gärna visa länkar på, E5 2699 och i7-5960X, med tanke på att jag läst att POWER8 når typ 400gflops. Och POWER8 är ingen dålig cpu.

Tack för korrigeringen, jag vill inte sprida felaktig information. Men tycker inte du också att Vims modell är ganska elegant?

Jag tycker inte det är rättvist av dig att implicera att Intel beslut att satsa på Netburst P4 var en exceptionellt usel ide. Just då, vid den tiden, så tog Intel beslutet att satsa på netburst P4 och det var det bästa beslutet då för Intel, annars hade Intel inte tagit det beslutet. Det är alltid lätt att gå tillbaka i tiden och säga att någon gjorde fel, att de istället borde gjort så här - när du har facit i hand. Men med den informationen man hade då, så var det faktiskt det bästa beslutet - just då.
-Varför sålde en av Apples grundare sina aktier för $1000 till Steve Jobs precis när Apple startades? Det var ju exceptionellt dåligt beslut!
-Ja, men han hade varit med i många startups som alla failat, och just då var det bästa beslutet att sälja sina aktier, det fanns inte en chans att veta att Apple skulle bli stort 40 år senare.

Det folk inte verkar förstå, när man tittar på korkade beslut idag, är att just då, utifrån den informationen man hade då, var det bästa beslutet man tog. Det finns inte en chans att folk förstod att om man röstade på Hitler skulle det gå som det gick då. Utifrån den informationen man hade då, så var det bästa beslutet för Tyskland tyckte folk. Intel hade gjort sin due diligence och tekniska undersökningar och kommit fram till att Netburst var det bästa beslutet då. Intel hade rejält på fötterna för sitt beslut, det fanns mycket som stödde det bestlutet. Kanske hade de lyssnat på IBM som tjatade om att det enda vettiga är 1-2 cores med skyhög GHz, därför att databaser (som är själva hjärtat i ett företag) trivs bäst på starka kärnor, istället för många lägre klockade kärnor, vilket Sun sysslade med. Därför trash-talkade IBM SPARC T1 cpun som hade 8 kärnor och 32 trådar - korkad design att ha många lägre klockade kärnor och trådar, sade IBM. Det enda raka är 7-8GHz cpuer med 1-2 cores, sade IBM. Idag har vi facit, och alla satsar idag på många lägre klockade cores. Det finns ingen cpu idag som har 1-2 cores med 7-8 GHz, vilket IBM sade var framtiden. Så istället för att satsa på höga GHz, satsar man idag istället på många cores som Sun var först med att kommersialisera.

Med det sagt, Itanium hade stora prestandaproblem under många år vilket du kanske missat. Och även de senaste Itanium cpuerna var kassa ur prestanda synpunkt:
https://en.wikipedia.org/wiki/Itanium
"...journalist John C. Dvorak reported "Itanium continues to be one of the great fiascos of the last 50 years" .[5] Tech columnist Ashlee Vance commented that the delays and underperformance "turned Itanium into a joke in the chip industry."[6] In an interview, Donald Knuth said "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write...."

År 2005, om vi tittar på samtida Itanium cpu med SPARC T1 och P4, så släpptes single core McKinley några år innan SPARC T1, och den var ungefär lika snabb som 2200+ Athlon, dvs 1.67 GHz AMD.
http://www.theregister.co.uk/2002/07/09/hp_releases_itanium_2...
Senare, år 2006 släpptes Montecito Itanium, och om man googlar lite så var den ungefär dubbelt så snabb som McKinley, kanske eftersom den hade två kärnor. Så vi kanske kan avrunda och säga att Montecito var ungefär 2x så snabb som en McKinley, som är ungefär lika snabb som Pentium4. Det betyder att en SPARC T1 inte var 50x snabbare än en samtida Itanium, SPARC T1 var bara typ 25x snabbare än Itanium Montecito inom sin nisch, dvs webservrar och liknande saker med många lätta trådar och hög genomströmning. Nu pratar vi inte 25% snabbare än Itanium, vilket är ganska bra när man jämför cpuer/gpuer. Nej, vi pratar 25 gånger snabbare. Och jag vet inte vilken måttstock du har, men jag blir imponerad i alla fall när en cpu är 10x eller 20x snabbare än nån annan.

Siffran långt över 50% känns lite tagen ur luften, men visst, jag ska inte be dig posta länkar. Men vi kanske kan säga att SPARC M7 inte är så dålig på beräkningar om man tittar på SPECint2006 då? Skulle man göra beräkningar på riktigt så är det många parallella trådar som körs samtidigt, typexemplet är Monte Carlo simuleringar som används flitigt inom t.ex. finansmatematik och andra områden när man inte kan lösa ekvationen analytiskt, utan måste använda en dator. Så i verkligheten skulle SPARC M7 vara mycket snabbare än x86 på vetenskapliga beräkningar (vilket ses också i neurala nätverk benchmarks som vanligtvis körs på parallella GPUer i produktion). Och ifall du löser partiella diff ekvationer på ett stort grid som i CFD, så behöver du många många trådar. Det är därför superdatorer har 10.000 tals cpuer, ju fler trådar och cores desto bättre eftersom man kan lösa ett större/finmaskigare grid. Och många trådar och cores är precis vad SPARC M7 har. Så jag tycker det ser ut som att SPARC M7 är långt bättre på beräkningar än x86.

Sen ska vi inte glömma bort Fujitsu SPARC64, som alltid satsat på 2 trådar per kärna, men mycket starka trådar. Fujitsus 1.100 Gflops är ganska imponerande om du frågar mig, speciellt när man jämför med x86 som når 400 gflops. Så bevisligen går det att få starka trådar på SPARC. Fujitsu får ut ganska mycket mer gflops än x86, trots att Fujitsu använder 2 trådar, medan SPARC M7 använder 8 trådar. Och trots att x86 har 30%(?) högre IPC än Oracles SPARC version. Spelar det någon roll hur hög IPC är, när M7 är mycket snabbare i 20 vitt skilda benchmarks?

SPARC är en server cpu, och ska serva tusentals samtidiga användare. Servrar används inte interaktivt. Men visst, om vi pratar om interaktiv användning så har du en poäng.

På Hadoop är SPARC M7 ca 4.6x snabbare än x86, men x86 har lägre latency så därför vinner x86 Hadoop benchen eftersom x86 skalar bättre? Hmmmm?

Om du tittar på Hadoop benchmarken, så kördes ett kluster på 32 st x86 servrar, varje server hade dubbla x86 cpuer. Det var alltså totalt 64 st x86 cpuer. Mot detta, benchades en enda SPARC M7 server på 4 cpuer totalt. Dvs 64st x86 cpuer mot 4st SPARC M7 cpuer. Med samma mängd data på 10TB så är det inte så konstigt att den enda SPARC M7 servern behövde 4000 sekunder på sig, medan de 32 st x86 servrarna behövde 1000 sekunder på sig. Men därifrån kan du inte dra slutsatsen att x86 skalar bättre. Snarare tvärtom.

Två st SPARC M7 servrar som delar på arbetet skulle kanske halvera tiden ned till 2000 sekunder. (Hadoop är funktionellt, och funktionellt går bra att parallellisera vilket är själva poängen med Hadoop). Och fyra SPARC servrar kanske halvera tiden igen ned till 1000 sekunder. Om man använder 32st SPARC servrar, så skulle SPARC M7 klustret göra klart arbetet på 2 minuter. Och du drar slutsatsen att x86 skalar bättre? Låt oss vända på steken, hur lång tid tror du två stycken x86 servrar med 4 cpuer totalt skulle ta på sig att tröska igenom 10TB hadoop? Jag förstår inte vad det finns argumentera emot, SPARC M7 totaldemolerar x86 även på detta benchmark.

Yahoo Cloud så är SPARC M7 servern 1.6x respektive 2.5x snabbare än x86. Visst var latencyn bättre för x86, men jag tycker ändå att eftersom jobben är snabbt avklarade, så hinner M7 betjäna nästan dubbelt så många användare än x86 inom samma tidsrymd. För mig ser det ut som att SPARC M7 är snabbare även på detta benchmark.

Den urgamla SPARC M5-32 och även gamla SPARC M6-32 hade interconnect Bixby1 som skalade upp till 96 sockets. SPARC M7 har en interconnect Bixby2 som skalar upp till 64 sockets. SPARC M5 och M6 såldes upp till 32 sockets och 32 TB RAM. Eftersom M7 har effektiv komprimering av RAM så man kan köra i full speed utan tappad prestanda trots att man komprimerar mycket. T.ex. typiskt i databaser kan du komprimera 10:1 utan prestandaförlust, då motsvarar det 80 TB RAM, det räcker ganska långt även för mycket krävande kunder. SPARC M7 kan hantera 2TB RAM per cpu, så det finns gott om utrymme att skala uppåt. Jag tror det är fel i artikeln nedan, eftersom Bixby2 skalar upp till 64 sockets och 128 TB RAM, inte 32 TB RAM som det står på ett ställe, och 128 TB RAM på ett annat ställe. Den korrekta siffran är 128 TB RAM, tror jag.

Jag antar att du inte påstår att Xeon E7v3 som skalar till 8 cpuer med 12 GB RAM, skalar högre än SPARC M7. SPARC M7-16 servern går upp till 16-sockets och 8 TB RAM. Men skalar lätt långt högre om Oracles kunder kräver det:
http://www.nextplatform.com/2015/10/28/inside-oracles-new-spa...
"....The first generation Bixby interconnect, which debuted with the Sparc M5 machines several years ago, was able to scale up to whopping 96 sockets and 96 TB of main memory in a single system image, although Oracle only shipped Sparc M5 and Sparc M6 machines that topped out at 32 sockets and 32 TB of memory. With the Sparc M7 processors, Oracle has a second generation of Bixby interconnect that tops out at 64 sockets and 32 TB of memory, as John Fowler, executive vice president of systems, told us last year when the M7 chip was unveiled. The Sparc M7 systems that use this chip are currently topping out stretch to 16 sockets and 8 TB of main memory, which is considerably less than the theoretical limits that Oracle could push.
...
But with Oracle doing so many tricks in hardware to compress data and to make this available to its systems and database software, and with Oracle using flash to accelerate storage performance and to augment the main memory capacity, it makes a certain amount of sense for Oracle to stick with slightly lighter memory configurations and leave some headroom with 64 GB sticks should customers need them for larger memory footprints
....
It is not clear what this bandwidth drop does to performance, but it may be largely academic unless someone wants to build a 64 socket machine with 128 TB of memory. Oracle would surely take the order should it come in."

Om du behöver fler sockets än 16, så finns Fujitsu M10-4S med 64-sockets och 32 TB RAM. Det är den enda servern på marknaden som har 64 sockets. Ingen annan har så många.

Jag tvivlar på att 32-socket x86 skalar vidare bra. I alla dessa år fram till nu har x86 skalat upp till 8-sockets, och att skala väl uppåt går inte på en handvändning. SGI har i flera decennier försökt bygga stora 16-socket x86 och större scale-up servrar utan att lyckas. Det finns starka skäl att tro att prestandan på en stor 16-socket x86 server inte är vidare bra. T.ex. när HP kompilerade Linux till sin 64-socket Itanium Superdome2 server, så fick de ut ~40% cpu utilization under full load. Varannan cpu idlade under full load, under Linux. Linux har aldrig körts på större scale-up servrar än 8 sockets. Det kräver ganska mycket omdesign för att skala väl. T.ex. Solaris som i flera decennier skalat upp till 144-sockets och mycket RAM, fick nyligen skriva om sin minneshantering för att skala upp till 100 tals TB RAM. IBM AIX gjorde samma sak iom POWER7 P795 32 sockets som gick upp till 8 TB RAM. AIX och Solaris har skalat till stora servrar i decennier, och ändå fick man skriva operativsystemen för att skala upp till ett tiotal TB. Varken Linux eller Windows har skalat mer än 8-sockets hittills, jag har svårt att tro att en x86 server med Windows eller Linux skulle prestera väl i jämförelse med gamla beprövade Unix servrar. Jag vill se benchmarks för att reda ut frågan. Men personligen tror jag att en färsk scale-up x86 server presterar dåligt. Kanske om 10-20 år så kommer x86 skala väl, när man hunnit bygga några generationer scale-up servrar och lärt sig.

Och börja inte blanda in SGIs UV2000 kluster och påstå att det är en scale-up server. Du vet att jag är påläst om den.

Jag förstår inte riktigt vad du försöker säga. Återigen, om du börjar blanda in externa kort, så kan Oracle också göra det. Och Oracles server kort kanske kan kosta upp emot miljontals kronor. Jag tycker inte det är rättvist att blanda in Enterprise grejor som kan kosta mycket mer än hela x86 servern. Jag tycker inte vi ska blanda in externa hjälpkort eftersom vi pratar om cpu vs cpu. Vi pratar inte GPU vs cpu när det gäller beräkningar.

Om vi pratar om DAX och alla acceleratorer som SPARC M7 har, så sitter de på chippet. De är inga externa co-cpuer i stil med gamla 80287 matematik hjälpprocessorer som sitter på ett externt kort. Jag förstår inte riktigt vad du försöker säga, menar du att alla M7 acceleratorer sitter på ett externt kort, som M7 accessar utifrån? Nej, det stämmer inte. Allt är inbakat i chippet.
http://www.enterprisetech.com/2014/08/13/oracle-cranks-cores-...
"....The S4 core, for instance, has special instructions to ensure application data integrity, which is done in real-time and which safeguards against invalid or stale memory references and buffer overruns... The Sparc M7 also has database query offload engines and accelerators for in-memory compression and decompression algorithms....The on-chip compression leaves the S4 cores leftover capacity to do useful work.
...
The query accelerator for the Oracle 12c database’s in-memory columnar data store does in-memory format conversions, value and range conversions, and set membership lookups. These on-chip database functions were developed in conjunction with the Oracle database team and reside on eight off-core query accelerator engines...."

Aldrig!

Nja, men Vim är ju meckigt, det är lite konstigt om man aldrig sett en modal editor, som har olika lägen. Sen måste man även förstå input modellen. Så det är en hel del nya tankesätt man måste tillägna sig. Själv tycker jag att Vims inputmodell är väldigt elegant, som är mer av ett språk som funkar så här: operator + antal upprepningar + (eventuellt en operand)

T.ex. om jag vill gå nedåt 4 rader så trycker jag "piltangent ned + 4 + ingen operand", iom att "j" är en förkortning för pil ned, så trycker man typiskt "j4". Om jag vill radera 10 ord, så trycker jag "d4w", dvs "delete" + 10 + "word".

Så det finns olika förkortningar för olika operatorerna. radera, kopiera, klistra in, hitta nästa tecken/ord, etc etc etc. Varje förkortning motsvarar en tangent, typ "d" för delete, etc etc etc

Sen finns det olika förkortningar för operander: stega markören ett steg (bakåt framåt upp ned), stega till slutet av ett ord, stega till början av ett ord, stega till början eller slutet av en rad, en mening, början slutet av ett stycke, hitta nästa bokstav som görs så här: "f" och en bokstav t.ex. "fo" placerar markören på nästa "o", hitta bokstaven bakåt med "t" och en bokstav, etc etc etc. Så det finns MASSOR av olika sätt att flytta markören, hundratals sätt: flytta markören till början av en mening eller slutet, etc. Så varje av dessa är ett kommando, och har en tangent som förkortning.

Sen är det bara att kombinera alla förkortningar på olika sätt med en siffra. Typ, "d5w" betyder "radera 5 ord" eller "5fO" betyder "flytta markören till femte O framåt". Tex, "df2" skulle då "Delete" ända fram till siffran "2" i texten. Dvs, radera allting ända fram till siffran 2 i texten. Och "5df2" skulle radera ända fram till siffran 2, och upprepa det fem gånger i rad.

Folk som kan Vim bra, kan utföra magi med endast några få knapptryckningar. Göra jättekomplicerade editeringar med få tryckningar. Vim är verkligen designat för att editera text. Jag använde Emacs för längesen men gick över till Vim.

Möjligt. Men M7 är en serverprocessor som ska serva tusentals användare samtidigt, det är inte en Intel x86 bra på, det ses av att en SPARC T1 på 1.2 GHz med ~80 watt, var 50x snabbare än en dual core Intel Xeon 2.4 GHz på webserver. Så visst, det kan vara så att en x86 är snabbare på desktop laster, som t.ex. Crysis.

Men om vi pratar beräkningar (SPECint2006), och neurala nätverk som ofta körs på x86, och grafer och andra skilda benchmarks så är det bara att titta på M7 benchmarksen. De talar för sig själva. Men visst, jag tror inte M7 är designad för desktoplaster såsom... Winrar? Nej, Winrar kan starta upp många trådar, och det är M7 helt överlägsen på med sina 256 trådar per cpu. MP3 eller videoenkodning eller folding, nej, det vore M7 också bra på eftersom det är många trådar även där.

Hmmm... Många program idag är trådade och drar stor nytta av många trådar i en cpu, men om du har ett behov av att köra 1-2 trådar så snabbt som möjligt, som t.ex. Crysis så är det högst rimligt att x86 är snabbare, ja. Där håller jag med dig. En server som betjänar tusentals användare samtidigt behöver många trådar som arbetar så fort som möjligt, en desktop behöver inte många trådar, det går bra med några få trådar för att betjäna en ensam användare. Det är olika designprinciper och cpuerna är typiskt bra på det de är designade för.

Vim som är gratis borde funka, det läser bara in aktuell del av en stor fil. Men Vim är väldigt svårt att komma igång med, om man aldrig använt det tidigare bör man undvika det.