Visa signatur
Star Citizen ❤
Världens snabbaste cpu:
Skrivet av MichaelJackson:
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.
Nu pratar du om saker du uppenbarligen har väldigt dålig koll på. Algoritmers tidskomplexitet och systems skalbarhet över CPU-kärnor är i teorin totalt ortogonala. Skalbarheten över kärnor kommer långt mer från hur man representerar sin data, något som i praktiken ställer en del krav på de algoritmer man rent praktiskt kan använda.
Linux använder självbalanserande träd för att hålla reda på "memory-pages", det d.v.s O(log(N)). Linux använder Patricia trees för FIB (forward information base, det folk felaktigt kallar "route tabel"), det är O(log(N)). Den vanligaste datastrukturen i Linux är nog hash-tabeller med "closed-addressing" där listorna i varje hink använder sig av RCU (read-copy-update, IBM äger patentet på detta men de har explicit givit sin tillåtelse att använda RCU i Linux-kärnan).
Finns idag ingen känd teknik som skalar bättre över CPU-kärnor än RCU (men kanske ändras inom kort, det här är ett område jag har rätt bra koll på ), du får gärna peka på vad Solaris skulle ha som kan matcha skalbarheten hos RCU. Väldigt mycket av det arbete man gjort i Linux-kärnan de senaste 10 åren (RCU användes första gången 2002 i Linux) är att designa om delar så de i bästa fall kan använda RCU och om det inte är möjligt kör man en mer traditionell variant med självbalanserade träd i ihop med RW-semaphorer eller RW-spinlocks, det senare vill man undvika men är ett krav för alla saker som eventuellt måste läsas/skrivas i interrupt-kontext, inte specifikt för Linux utan alla SMP OS använder spinlocks där man förut slog av interrupt temporärt (det fungerar bara på uni-processor-system).
TCP/IP-stacken i Linux har under ganska lång tid kunnat skalas till väldigt många CPU-kärnor, en anledning till varför Linux i praktiken slagit ut alla andra OS från telecom (SPARC/Solaris var en gång i tiden stort här, idag existerar det inte längre). 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), är I/O-operationer mot filsystem. De riktigt stora förbättringarna är ett par år bort nu, med en någorlunda modern Linux-kärna på sin server har man idag en skalbarhet som inte alls går att jämföra med tidigare resultat.
Skrivet av MichaelJackson:
@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.
Vad min kodsnutt visar är att man i praktiken kan skriva ett program som når extremt nära den teoretiska kapacitet som Intels kretsar har. Är inte alls säkert att så är fallet, är faktiskt ovanligt att man kan nå så nära 100% av teoretiskt max.
Om du har invändningar mot mitt program är du extremt inkonsekvent alt. bara rent ignorant. Du pekar på resultatet i "STREAM" benchmarken. Vad du vad det benchmarket gör? Har du sett källkoden (hittar inte en länk nu, kanske var ett misstag men källkoden för STREAM copy/scale/add/triad gick ett tag att hitta via Google)?
I princip mäter man detta
bench (wide_int_t * dst, wide_int_t * src, size_t sz)
{
for (ett gäng gånger)
for (size_t i = 0; i < p_sz; i++) {
dst[i] = src[i]; // Copy
dst[i] = src[i] * S; // S är en konstant "skalningsfaktor"
dst[i] = src[i] + T; // T är ett konstant tal som adderas
??? ; // kommer inte ihåg hur triad såg ut men var inget komplicerad
}
}
Hur är detta benchmark relevant för något mer än att mäta ungefär samma sak som min benchmark mäter, d.v.s. någon form av praktisk maximal kapacitet av en väldigt specifik egenskap. I mitt fall är det flyttalskapacitet, här handlar det om bandbredd som CPUn kan nå?
Ljuger då IBM om sin bandbredd? Vet inte hur nära 100% POWER8 kan nå, men denna benchmark visar bara en egenskap för systemet. För en server borde rimligen bandbredd mot kringkretsar vara rätt viktig, de drar sin bandbredd ur samma pool som CPUn. Är absolut inget konstigt att man designar system som att CPUn bara kan använda en del av tillgänglig bandbredd, så är t.ex. AMDs APU designade inklusive PS4/XBO. I dessa system kan CPU-delen bara använda en fraktion av tillgänglig bandbredd, GPUn kan däremot använda 100%.
Så att IBM får ett lägre resultat än Oracle bevisar absolut inte att SPARC M7 har högre bandbredd än POWER8, det visar bara att bandbredd mot CPU antagligen är högre men det säger inget om bandbredd när man också blandar in I/O (vilket torde vara rätt viktigt för servers).
Skrivet av MichaelJackson:
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.
Fast varför litar du på benchmarks?
Min erfarenhet av benchmarks är samma som AnandTech: de är intressanta för att mäta specifika egenskaper på system, men de är värdelösa om målet är att avgöra hur ett system presterar i ett givet "verkligt" fall. Ta Geekbench, enligt det testet är både Snapdragon 810 och Samsung Exynos 7420 snabbare än Apple A8. I 100% av alla verkliga program är Apple A8 snabbare, i vissa fall betydligt snabbare, än de första två.
Det är tyvärr flera benchmarks som ger de två första orimligt höga resultat mot A8 jämfört med hur det ser ut i verkliga program.
Så håller med dig till 100%, det är att jämföra äpplen och päron där äpplen är benchmarks och päron är verkliga program.
Skrivet av MichaelJackson:
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?
Intels första "riktiga" x86-server CPU var Nehalem, jag tror man insåg rätt snabbt att ett område man inte kunde konkurrera med POWER/SPARC var bandbredd mot RAM. Däremot vet "alla" att Intel är bäst av alla på att designa cache-hierarkier (har bl.a. pratat med ingenjörer som jobbade på SPARC T4, även de "erkände" att Intel ligger rejält före andra på denna punkt). Vad Intel gjorde med Xeon E5/E7 i Sandy Bridge var att utnyttja sin styrka, IBM verkar dedikerad en del av den massiva bandbredd man har mot RAM (fungerar men ger inte så bra perf/W), Intel har i stället gjort det möjliga att köra DMA till/från LLC (last-level-cache, L3 i praktiken).
Vad man får med detta är två stora fördelar
trycket på RAM lättas, bandbredd mot L3-cache är massiv
tiden, latensen, det tar för att läsa/skriva data från/till I/O-enheter minskas radikalt. Detta öppnar upp för en del nya användningsområden!
Att köra DMA till/från LLC är inte ny, vissa linjekort för back-bone routers har möjlighet att markera minne som används för DMA att överhuvudtaget inte mappas i RAM. Ta IP-paket som ska routas, man vill komma åt det data så snabbt som möjligt men är extremt osannolikt att man någonsin behöver data i paketet igen när det hanterats -> packet payload mappas aldrig i RAM, det läggs i CPU-cache av DMA och slängs bort när utgående enhet är färdig med sin DMA.
Har du laster av den typen så kan Xeons hantera massiva mängder data, det handlar nog om samma datamängder som SPARC M7 och POWER8, men Xeons läser/skriver detta data med betydligt lägre latens vilket då kompenserar för att det bara finns två trådar per CPU, ALU-enheter kan hållas matade från två trådar tack vare låg latens mot "working-set".
Skrivet av MichaelJackson:
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.
Det finns lögn, förbannad lögn och sedan finns benchmarks Så nej, här är vi inte överens. AnandTech är långt ifrån ensam om att anse att de de benchmark resultat som SPECint2006 och TPC-X inte är speciellt relevant för verklig prestanda. Vad man kan använda dessa program till är att jämföra två väldigt snarlika system där man vet att benchmarken tester något som var en flaskhals i tidigare modeller. Till och med benchmarks som Geekbench och STREAM går att använda bara man förstår vad de mäter.
Att AnandTech konstaterar att 2699v3 kan hålla 2,8 GHz när alla kärnor jobbar är väldigt relevant t.ex. när de kopplas till att denna CPU i praktiken kan nå 16 DP per cykel och kärna.
Du tittar heller inte på SPECint2006 och SPECfp2006, du tittar på SPECint2006_rate och SPECfp2006_rate. De senare lider av precis samma problem som Geekbench, de ger designer med många svagare CPU-kärnor orimligt högt resultat jämfört med hur majoriteten av alla verkliga program är skapta. Skulle ändå säga att det inte är fullt lika illa för servers, här finns garanterat några enstaka fall där man verkligen gör helt oberoende saker på alla CPU-trådar
Har hört CPU-designers totalt döma ut SPECint2006 som ett relevant test, är alldeles för lätt att göra saker som ökar resultatet i detta test utan att ge någon relevant effekt i majoriteten av verkliga program. Finns ett undantag, ett deltest använder sig av GCC och det verkar som många (har sett folk på på ARM och x86 sidan överens här, inte vanligt att de är överens) anser att GCC är så pass en så "elak" sekvens av instruktioner (massiva mängder villkorade hopp) att alla saker som presterar bra här tenderar att prestera bra på en lång rad program.
Har inte läst lika mycket om SPECfp2006, tror det mest på att flyttalskapacitet är mycket mer en specialiserad sak och därför inte lika viktigt. Men i fallet SSE/AVX: det testas överhuvudtaget inte här då testerna i denna suite designades innan SIMD blev populärt så den mäter skalära flyttalsprestanda. För t.ex. HPC är detta irrelevant, de för det första att anamma SIMD då det dels höger flyttalskapacitet men också då det är en extremt bra match för matrisberäkningar.
En modern x86 använder mellan 1/4 till 1/8 av sin flyttalskapacitet om man kör med skalära instruktioner...
Skrivet av MichaelJackson:
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.
Nej, nej, nej. Om du sak utföra en väldigt specifik sak så kan en specialdesignad krets, i de fall en sådan är vettig, utföra långt mer arbete per cykel än en CPU. Ta systemkretsar, skillnaden mellan en "bra" och en "dålig" systemkrets är enbart hur man designat sina specialkretsar då dessa har endera långt högre kapacitet (typiskt en tiopotens, så en ASIC på 1 GHz matchar då en CPU på 10 GHz) eller långt högre perf/W med ungefär samma kapacitet.
Skrivet av MichaelJackson:
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.
Är ingen HPC-expert, men vad jag läst är deras störta flaskhals inte priset utan strömförbrukning. Xeons har väsentligt mycket bättre perf/W än t.ex. POWER8 och SPARC M7. När IBM finns representerade i superdatorsammanhang har man typiskt använt IBM PowerPC 4xx som bas då den har riktigt bra perf/W, den är dock inte i närheten av POWERs absoluta prestanda per CPU-kärna, vilket är precis vad du säger ovan. Har för mig att Blue Gene hade >200,000 st 4xx kärnor.
Så här är vi helt överens tror jag
Skrivet av MichaelJackson:
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.
Hur skulle SPARC M7 kunna var mer lämpad för tekniska beräkningar? Om så är fallet, varför är SPARCs marknadsandel här 0% med väldigt många signifikanta siffror?
Du skriver "stor grid", det är i praktiken en stor matris. När storleken på matrisen går mot oändligheten så går effektiviteten på FMA-instruktioner mot 100% för matris-multiplikation. Vidare går effektiviteten för SIMD på alla matrisoperationer mot 100% när storleken växer.
Vad betyder det? Jo, att en CPU som Haswell med AVX+FMA kommer nå väldigt nära sin teoretiska flyttalskapacitet inom dessa områden. Det förutsatt att det finns matrisbibliotek som använder AVX+FMA. Finns en rad sådana + Intel ger bort sådana bibliotek då de vet hur viktigt det är för att de ska sälja fler Xeons.
Skrivet av MichaelJackson:
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.
100% utan tvekan! Jag förväntar mig att många missförstår multitaskning, men du borde veta bättre. Amiga kunde multitaska väldigt väl trots en enda 68000 på 7,14 MHz. Windows har vissa problem med svarstider om man kör ett gäng trådar på varje CPU-tråd, Linux har sedan "wonder patch" inga problem att köra 100 trådar per CPU-tråd utan att GUI blir segt.
Just x86 har också väldigt låg kostnad för att byta OS-tråd på en CPU-tråd, är extremt snabbt / effektivt att spara / återställa OS-tråd tillstånd. Och det är alltid så att en CPU-kärna med prestanda P är alltid minst lika snabb som en CPU med två kärnor med prestanda med P/2.
På jobbet hade en laptop med 4-kärnig Sandy Bridge, valde aktivt bort 4-kärnig CPU när jag bytte, kör nu en Broadwell 5600U. Den har något högre enkeltrådprestanda än gamla maskinen, har 15W TDP i stället för ~40W TDP. I praktiken har jag lika bra prestanda på 95% av allt man gör på dagar och för de övriga 5% är den nya maskinen alltid en bra bit snabbare än 50% av den gamla (inget verklig program jag kör skalar linjärt med kärnor). Den nya maskinen väger ungefär hälften och har 5 gånger bättre batteritid.
Skrivet av MichaelJackson:
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.
Så vad du säger är att Google, Facebook, Microsoft (azure), Amazon m.fl, kör "små" servers i deras datacenter?
Vilka företag kör då dessa mytologiska "stora" servers och vad gör dessa (har lite hum vad mainframes gör och förstår poängen med dessa, men övriga)?
Skrivet av MichaelJackson:
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?
Det finns inga för ingen (statistisk sett, eventuellt även i absolut tal just nu) har en M7. Oracle lär ju knappast presentera resultat på områden där SPARC M7 inte "vinner". Så kontentan är: vi har ingen aning hur M7 presterar på den stora massan av alla program som finns där ute.
Skrivet av MichaelJackson:
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.
I så fall missförstår du vad jag skriver, är övertygad om att SPARC M7 presterar bäst per socket på "rätt" typ av problem. Vill bara peka på att majoriteten av alla program som finns där ute är inte av "rätt" typ, d.v.s. enkelt parallelliserbar och med extremt låg data-lokalitet både i tid och rum. Skriver också att det mycket väl kan vara så att t.ex. stora databaser är av den typ SPARC M7 är designad för, är så fallet lär den prestera bäst per socket.
Skrivet av MichaelJackson:
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.
Och det är precis detta Xeon E7 stödjer, medan Xeon E5 typisk bara har "hot-plug" för diskar och liknande.
Skrivet av MichaelJackson:
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.
?
Det går att skala E5 till 8 sockets med extra "glue-logic" om det vore flaskhalsen, det är fortfarande billigare än att använda Xeon E7. Den stora skillnaden mellan E5 och E7 är RAS samt att E7 har mer kapacitet i det Intel kallar "un-core", d.v.s. kretsar som är del av CPU-kretsen men inte är del av själva CPU-kärnorna. T.ex. så får E7 högre I/O-kapacitet via DDIO ("tricket" att köra DMA till/från L3-cache jag nämnde ovan). Så kapaciteten i verkliga program är större i E7 jämfört med E5 om I/O-kapacitet är flaskhals. För rena beräkningar har dessa modeller exakt samma kapacitet vid samma antal kärnor och frekvens, så HPC bygger superdatorer med E5 då den drar mindre ström för samma prestanda, så bättre perf/W.
Skrivet av MichaelJackson:
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.
Tja, marknaden för stora UNIX-servers är krympande. Att den existerade tidigare är ju rätt enkelt att förklara: innan Nehalem fanns överhuvudtaget inga billiga system med "riktiga" server CPUer. Tidigare Xeon CPUer var desktop CPUer med lite större cache.
Idag är det samma CPU-kärna i alla Intel CPUer, men "uncore" är radikalt annorlunda mellan konsumentmodeller och Xeons.
Skrivet av MichaelJackson:
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?
Mitt program beräknar
R = A * B + C
Hur ser matrisberäkningar ut? Jo
Rij = A * B + (C * D + (E * F) .... )
Det är alltså samma sak, mitt program är bara en benchmark som visar vilken flyttalskapacitet man kan få i praktiken och det vi diskuterade var huruvida en 2699v3 kan nå sin teoretiska kapacitet.
Du länkar som sagt till STREAM och det är en minst lika syntetiska benchmark för bandbredd!!!
Skrivet av MichaelJackson:
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?
Jag skrev en benchmark, får se vad den ger på 2699v3.
Den tekniska diskussion du läste måste ha involverat folk som inte riktigt kan sin numme. AVX och SSE sedan SSE4x är väldigt fullständig i att den hanterar operationer på "båda ledder", d.v.s. om man har YMM0=|A1|A2|A3|A4|, YMM1=|B1|B2|B3|B4| så finns instruktioner som gör t.ex. |A1+B1|A2+B2... samt även de som gör |A1+A2|A3+A4|B1+B2|B3+B4|. Med dessa primitiver är det möjligt att använda SIMD för de flesta större numeriska problem som jobbar med vektorer och/eller matriser.
Skrivet av MichaelJackson:
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?
Jag försöker vara väldigt noga med terminologin, så här har du i så fall missförstått mig.
Det finns väldigt stora system från SGI som är cc-NUMA, dessa är fortfarande inte "scale-up" då man i detta fall har "cc-" delen för att ge en väldigt snabb data-path mellan beräkningsnoder. Har pekat på dessa system någon gång för att visa att Linux-kärna kan skala sin hantering av RAM-pages och andra system som behövs här, men har aldrig hävdat att man kan göra effektiv disk-I/O på den här typen av system.
Har också pekat på att det är tekniskt inkorrekt att kalla något cc-NUMA system för kluster, det SGI designat med de system som har >1000 kärnor är fortfarande en väldigt stor server och inte ett kluster, möjligen kan man kalla det cc-NUMA då den är mer asymmetrisk i sin kostnad för att nå alla delar av RAM. Det är dock en server som inte är lämplig för I/O-intesiva laster.
Skrivet av MichaelJackson:
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.
Ändå visar SGIs ekonomiska rapporter att rätt många väljer att köpa dessa system, varför köpa av SGI om man inte behöver skala förbi 8 sockets?
UV300RL verkar reda idag finnas upp till 32-sockets (och man kör Xeon E7, inte E5), den ska ju köra "Oracle 12c with the Oracle Database In-Memory option". Varför köper folk sådant om det inte tillför affärsnytta? Och det borde bara tillföra affärsnytta om dagens x86 och Linux (den kör Oracle unbreakable Linux) faktiskt kan skala till denna storlek. Om så är fallet, hur mycket större är de "stora UNIX-systemen"?
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(2)
@Tomika: hela programmet ligger i spoiler i detta inlägg.
Klipp ut innehållet, lägg det i en fil med namnet flops.cpp, kör
$ g++ -std=c++11 -O3 -march=native -mfma -pthread flops.cpp -o dpflops
$ g++ -DUSE_SP -std=c++11 -O3 -march=native -mfma -pthread flops.cpp -o spflops
så får du binärerna dpflops och spflops.
Säkrare för dig än att köra en binär från Internet
Säg till om du vill ha en färdig binär så kan jag fixa en. Men tror vår dual 2699v3 är på ingång nu, så kan köra själv inom kort.
Edit: här är resultatet på dual 2699v3
$ ./dpflops 72
Measuring DP...
Thread #0 GFLOPS 21.6
Thread #1 GFLOPS 21.1
Thread #2 GFLOPS 21.2
Thread #3 GFLOPS 21.4
Thread #4 GFLOPS 21.4
Thread #5 GFLOPS 21.5
Thread #6 GFLOPS 20.2
Thread #7 GFLOPS 21.5
Thread #8 GFLOPS 20.7
Thread #9 GFLOPS 21.1
Thread #10 GFLOPS 21.0
Thread #11 GFLOPS 21.0
Thread #12 GFLOPS 20.2
Thread #13 GFLOPS 21.4
Thread #14 GFLOPS 17.9
Thread #15 GFLOPS 21.4
Thread #16 GFLOPS 20.5
Thread #17 GFLOPS 21.3
Thread #18 GFLOPS 20.6
Thread #19 GFLOPS 21.4
Thread #20 GFLOPS 20.6
Thread #21 GFLOPS 21.2
Thread #22 GFLOPS 20.0
Thread #23 GFLOPS 20.5
Thread #24 GFLOPS 21.4
Thread #25 GFLOPS 21.6
Thread #26 GFLOPS 20.8
Thread #27 GFLOPS 21.4
Thread #28 GFLOPS 20.8
Thread #29 GFLOPS 20.3
Thread #30 GFLOPS 21.0
Thread #31 GFLOPS 20.1
Thread #32 GFLOPS 21.4
Thread #33 GFLOPS 20.6
Thread #34 GFLOPS 21.0
Thread #35 GFLOPS 20.9
Thread #36 GFLOPS 21.3
Thread #37 GFLOPS 21.1
Thread #38 GFLOPS 21.3
Thread #39 GFLOPS 19.8
Thread #40 GFLOPS 21.3
Thread #41 GFLOPS 20.5
Thread #42 GFLOPS 21.6
Thread #43 GFLOPS 20.5
Thread #44 GFLOPS 20.7
Thread #45 GFLOPS 21.4
Thread #46 GFLOPS 20.5
Thread #47 GFLOPS 21.2
Thread #48 GFLOPS 20.8
Thread #49 GFLOPS 21.2
Thread #50 GFLOPS 20.8
Thread #51 GFLOPS 21.3
Thread #52 GFLOPS 19.6
Thread #53 GFLOPS 21.4
Thread #54 GFLOPS 19.3
Thread #55 GFLOPS 18.7
Thread #56 GFLOPS 19.5
Thread #57 GFLOPS 19.2
Thread #58 GFLOPS 20.5
Thread #59 GFLOPS 20.5
Thread #60 GFLOPS 20.5
Thread #61 GFLOPS 21.1
Thread #62 GFLOPS 20.5
Thread #63 GFLOPS 19.4
Thread #64 GFLOPS 17.3
Thread #65 GFLOPS 18.9
Thread #66 GFLOPS 21.3
Thread #67 GFLOPS 21.1
Thread #68 GFLOPS 20.2
Thread #69 GFLOPS 21.5
Thread #70 GFLOPS 21.0
Thread #71 GFLOPS 20.8
Aggregated GFLOPS: 1489.7
Dold text
1489,7 GFLOPS på två CPU-socklar, d.v.s 744,9 GFLOPS per CPU-sockel. Var lite fundersam varför det inte blev 800 GFLOPS, svaret är att Xeon E5 v3 har något lägre "turbo frequence" för kod som använder AVX än övrig kod då man skulle passera TDP annars. Så frekvensen när när alla 18 kärnor utför AVX är 2,6 GHz (referens) medan den är 2,8 GHz i övriga fall när alla 18 kärnor jobbar.
Teoretisk max blir då: 16 (DP per cykel och kärna) * 18 (kärnor) * 2,6 = 748,8 GFLOPS, så programmet är fortfarande inom 99% av teoretisk max.
Samma körning där man använder endast en CPU-sockel och endast en CPU-tråd per kärna
$ taskset 0x3ffff ./dpflops 18 && taskset 0x3ffff ./dpflops 18
Measuring DP...
Thread #0 GFLOPS 41.3
Thread #1 GFLOPS 41.3
Thread #2 GFLOPS 41.3
Thread #3 GFLOPS 41.3
Thread #4 GFLOPS 41.3
Thread #5 GFLOPS 41.3
Thread #6 GFLOPS 41.3
Thread #7 GFLOPS 41.3
Thread #8 GFLOPS 41.3
Thread #9 GFLOPS 41.3
Thread #10 GFLOPS 41.3
Thread #11 GFLOPS 41.3
Thread #12 GFLOPS 41.3
Thread #13 GFLOPS 41.3
Thread #14 GFLOPS 41.3
Thread #15 GFLOPS 41.3
Thread #16 GFLOPS 41.2
Thread #17 GFLOPS 41.3
Aggregated GFLOPS: 743.2
Dold text
Senast redigerat
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
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.
Skrivet av Yoshman:
Nu pratar du om saker du uppenbarligen har väldigt dålig koll på. Algoritmers tidskomplexitet och systems skalbarhet över CPU-kärnor är i teorin totalt ortogonala.
Ö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å.
Citat:
Linux använder självbalanserande träd för att hålla reda på "memory-pages", det d.v.s O(log(N)). Linux använder Patricia trees för FIB (forward information base, det folk felaktigt kallar "route tabel"), det är O(log(N)). Den vanligaste datastrukturen i Linux är nog hash-tabeller med "closed-addressing" där listorna i varje hink använder sig av RCU (read-copy-update, IBM äger patentet på detta men de har explicit givit sin tillåtelse att använda RCU i Linux-kärnan).
Finns idag ingen känd teknik som skalar bättre över CPU-kärnor än RCU (men kanske ändras inom kort, det här är ett område jag har rätt bra koll på ), du får gärna peka på vad Solaris skulle ha som kan matcha skalbarheten hos RCU.
Å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.
Citat:
Väldigt mycket av det arbete man gjort i Linux-kärnan de senaste 10 åren (RCU användes första gången 2002 i Linux) är att designa om delar så de i bästa fall kan använda RCU och om det inte är möjligt kör man en mer traditionell variant...
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?
Citat:
TCP/IP-stacken i Linux har under ganska lång tid kunnat skalas till väldigt många CPU-kärnor, en anledning till varför Linux i praktiken slagit ut alla andra OS från telecom (SPARC/Solaris var en gång i tiden stort här, idag existerar det inte längre).
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?
Citat:
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), är I/O-operationer mot filsystem. De riktigt stora förbättringarna är ett par år bort nu, med en någorlunda modern Linux-kärna på sin server har man idag en skalbarhet som inte alls går att jämföra med tidigare resultat.
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.
Citat:
Vad min kodsnutt visar är att man i praktiken kan skriva ett program som når extremt nära den teoretiska kapacitet som Intels kretsar har.
Om du har invändningar mot mitt program är du extremt inkonsekvent alt. bara rent ignorant.
Å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.
Citat:
Du pekar på resultatet i "STREAM" benchmarken. Vad du vad det benchmarket gör? Har du sett källkoden (hittar inte en länk nu, kanske var ett misstag men källkoden för STREAM copy/scale/add/triad gick ett tag att hitta via Google)?
...
Hur är detta benchmark relevant för något mer än att mäta ungefär samma sak som min benchmark mäter, d.v.s. någon form av praktisk maximal kapacitet av en väldigt specifik egenskap. I mitt fall är det flyttalskapacitet, här handlar det om bandbredd som CPUn kan nå?
Å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.
Citat:
Ljuger då IBM om sin bandbredd?
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...
Citat:
Så att IBM får ett lägre resultat än Oracle bevisar absolut inte att SPARC M7 har högre bandbredd än POWER8, det visar bara att bandbredd mot CPU antagligen är högre men det säger inget om bandbredd när man också blandar in I/O (vilket torde vara rätt viktigt för servers).
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.
Citat:
Fast varför litar du på benchmarks?
...
Det är tyvärr flera benchmarks som ger de två första orimligt höga resultat mot A8 jämfört med hur det ser ut i verkliga program.
Så håller med dig till 100%, det är att jämföra äpplen och päron där äpplen är benchmarks och päron är verkliga program.
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?
Citat:
Intels första "riktiga" x86-server CPU var Nehalem, jag tror man insåg rätt snabbt att ett område man inte kunde konkurrera med POWER/SPARC var bandbredd mot RAM. Däremot vet "alla" att Intel är bäst av alla på att designa cache-hierarkier (har bl.a. pratat med ingenjörer som jobbade på SPARC T4, även de "erkände" att Intel ligger rejält före andra på denna punkt). Vad Intel gjorde med Xeon E5/E7 i Sandy Bridge var att utnyttja sin styrka, IBM verkar dedikerad en del av den massiva bandbredd man har mot RAM (fungerar men ger inte så bra perf/W), Intel har i stället gjort det möjliga att köra DMA till/från LLC (last-level-cache, L3 i praktiken).
Vad man får med detta är två stora fördelar
trycket på RAM lättas, bandbredd mot L3-cache är massiv
tiden, latensen, det tar för att läsa/skriva data från/till I/O-enheter minskas radikalt. Detta öppnar upp för en del nya användningsområden!
Att köra DMA till/från LLC är inte ny, vissa linjekort för back-bone routers har möjlighet att markera minne som används för DMA att överhuvudtaget inte mappas i RAM. Ta IP-paket som ska routas, man vill komma åt det data så snabbt som möjligt men är extremt osannolikt att man någonsin behöver data i paketet igen när det hanterats -> packet payload mappas aldrig i RAM, det läggs i CPU-cache av DMA och slängs bort när utgående enhet är färdig med sin DMA.
Har du laster av den typen så kan Xeons hantera massiva mängder data, det handlar nog om samma datamängder som SPARC M7 och POWER8, men Xeons läser/skriver detta data med betydligt lägre latens vilket då kompenserar för att det bara finns två trådar per CPU, ALU-enheter kan hållas matade från två trådar tack vare låg latens mot "working-set".
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.
Citat:
Det finns lögn, förbannad lögn och sedan finns benchmarks Så nej, här är vi inte överens. AnandTech är långt ifrån ensam om att anse att de de benchmark resultat som SPECint2006 och TPC-X inte är speciellt relevant för verklig prestanda.
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?
Citat:
Att AnandTech konstaterar att 2699v3 kan hålla 2,8 GHz när alla kärnor jobbar är väldigt relevant t.ex. när de kopplas till att denna CPU i praktiken kan nå 16 DP per cykel och kärna.
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å?
Citat:
Du tittar heller inte på SPECint2006 och SPECfp2006, du tittar på SPECint2006_rate och SPECfp2006_rate. De senare lider av precis samma problem som Geekbench, de ger designer med många svagare CPU-kärnor orimligt högt resultat jämfört med hur majoriteten av alla verkliga program är skapta.
Å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.
Citat:
Nej, nej, nej. Om du sak utföra en väldigt specifik sak så kan en specialdesignad krets, i de fall en sådan är vettig, utföra långt mer arbete per cykel än en CPU. Ta systemkretsar, skillnaden mellan en "bra" och en "dålig" systemkrets är enbart hur man designat sina specialkretsar då dessa har endera långt högre kapacitet (typiskt en tiopotens, så en ASIC på 1 GHz matchar då en CPU på 10 GHz) eller långt högre perf/W med ungefär samma kapacitet.
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.
Citat:
Är ingen HPC-expert, men vad jag läst är deras störta flaskhals inte priset utan strömförbrukning.
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.
Citat:
Hur skulle SPARC M7 kunna var mer lämpad för tekniska beräkningar? Om så är fallet, varför är SPARCs marknadsandel här 0% med väldigt många signifikanta siffror?
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
Citat:
Du skriver "stor grid", det är i praktiken en stor matris. När storleken på matrisen går mot oändligheten så går effektiviteten på FMA-instruktioner mot 100% för matris-multiplikation. Vidare går effektiviteten för SIMD på alla matrisoperationer mot 100% när storleken växer.
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).
Citat:
100% utan tvekan! Jag förväntar mig att många missförstår multitaskning, men du borde veta bättre. Amiga kunde multitaska väldigt väl trots en enda 68000 på 7,14 MHz. Windows har vissa problem med svarstider om man kör ett gäng trådar på varje CPU-tråd, Linux har sedan "wonder patch" inga problem att köra 100 trådar per CPU-tråd utan att GUI blir segt.
Just x86 har också väldigt låg kostnad för att byta OS-tråd på en CPU-tråd, är extremt snabbt / effektivt att spara / återställa OS-tråd tillstånd. Och det är alltid så att en CPU-kärna med prestanda P är alltid minst lika snabb som en CPU med två kärnor med prestanda med P/2.
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.
Citat:
Så vad du säger är att Google, Facebook, Microsoft (azure), Amazon m.fl, kör "små" servers i deras datacenter?
Vilka företag kör då dessa mytologiska "stora" servers och vad gör dessa (har lite hum vad mainframes gör och förstår poängen med dessa, men övriga)?
Ö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.
Citat:
Det finns inga för ingen (statistisk sett, eventuellt även i absolut tal just nu) har en M7. Oracle lär ju knappast presentera resultat på områden där SPARC M7 inte "vinner". Så kontentan är: vi har ingen aning hur M7 presterar på den stora massan av alla program som finns där ute.
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?
Citat:
I så fall missförstår du vad jag skriver, är övertygad om att SPARC M7 presterar bäst per socket på "rätt" typ av problem. Vill bara peka på att majoriteten av alla program som finns där ute är inte av "rätt" typ, d.v.s. enkelt parallelliserbar och med extremt låg data-lokalitet både i tid och rum. Skriver också att det mycket väl kan vara så att t.ex. stora databaser är av den typ SPARC M7 är designad för, är så fallet lär den prestera bäst per socket.
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.
Citat:
?
Det går att skala E5 till 8 sockets med extra "glue-logic" om det vore flaskhalsen, det är fortfarande billigare än att använda Xeon E7. Den stora skillnaden mellan E5 och E7 är RAS samt att E7 har mer kapacitet i det Intel kallar "un-core"
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.
Citat:
Tja, marknaden för stora UNIX-servers är krympande. Att den existerade tidigare är ju rätt enkelt att förklara: innan Nehalem fanns överhuvudtaget inga billiga system med "riktiga" server CPUer. Tidigare Xeon CPUer var desktop CPUer med lite större cache.
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.
Citat:
Mitt program beräknar
...
Det är alltså samma sak, mitt program är bara en benchmark som visar vilken flyttalskapacitet man kan få i praktiken och det vi diskuterade var huruvida en 2699v3 kan nå sin teoretiska kapacitet.
Du länkar som sagt till STREAM och det är en minst lika syntetiska benchmark för bandbredd!!!
Å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.
Citat:
Den tekniska diskussion du läste måste ha involverat folk som inte riktigt kan sin numme. AVX och SSE sedan SSE4x är väldigt fullständig i att den hanterar operationer på "båda ledder", d.v.s. om man har YMM0=|A1|A2|A3|A4|, YMM1=|B1|B2|B3|B4| så finns instruktioner som gör t.ex. |A1+B1|A2+B2... samt även de som gör |A1+A2|A3+A4|B1+B2|B3+B4|. Med dessa primitiver är det möjligt att använda SIMD för de flesta större numeriska problem som jobbar med vektorer och/eller matriser.
Ö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?
Citat:
Jag försöker vara väldigt noga med terminologin, så här har du i så fall missförstått mig.
Det finns väldigt stora system från SGI som är cc-NUMA, dessa är fortfarande inte "scale-up" då man i detta fall har "cc-" delen för att ge en väldigt snabb data-path mellan beräkningsnoder. Har pekat på dessa system någon gång för att visa att Linux-kärna kan skala sin hantering av RAM-pages och andra system som behövs här, men har aldrig hävdat att man kan göra effektiv disk-I/O på den här typen av system.
Har också pekat på att det är tekniskt inkorrekt att kalla något cc-NUMA system för kluster, det SGI designat med de system som har >1000 kärnor är fortfarande en väldigt stor server och inte ett kluster, möjligen kan man kalla det cc-NUMA då den är mer asymmetrisk i sin kostnad för att nå alla delar av RAM. Det är dock en server som inte är lämplig för I/O-intesiva laster.
Å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?
Citat:
Ändå visar SGIs ekonomiska rapporter att rätt många väljer att köpa dessa system, varför köpa av SGI om man inte behöver skala förbi 8 sockets?
UV300RL verkar reda idag finnas upp till 32-sockets (och man kör Xeon E7, inte E5), den ska ju köra "Oracle 12c with the Oracle Database In-Memory option". Varför köper folk sådant om det inte tillför affärsnytta? Och det borde bara tillföra affärsnytta om dagens x86 och Linux (den kör Oracle unbreakable Linux) faktiskt kan skala till denna storlek. Om så är fallet, hur mycket större är de "stora UNIX-systemen"?
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?)
Citera flera
Citera
Skrivet av MichaelJackson:
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.
Mitt test ovan är den direkta parallellen för flyttal till vad STREAM är för CPU-bandbredd, båda är extremt syntetiska benchmarks som testar en enda aspekt.
Skrivet av MichaelJackson:
Ö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å.
Har lite koll på grunderna i alla fall efter att ha jobbat med utveckling av OS-kärnor och algoritmer för parallella system i ca 10 år. Så tar detta på "arbetarnivå" i stället för "akademikernivå", har ju ingen doktorshatt utan är en simpel civing (i.o.f.s topp 5% betyg på KTH det året jag gick ut).
Det jag menar med att de är ortogonala är att typ av algoritm bestämmer algoritmisk komplexitet, här måste du ändå hålla med om att du var totalt ute i de blå när du hävdade att "Linux använder simpla O(n^2) algoritmer som funkar bra på 1-2 sockets"
Till att börja med så var det fel att Linux använder simpla O(N^2) algoritmer, möjligt fanns det lite sådant under 1.x tiden. Vidare är det fullt möjligt att använda sig av O(N^2) algoritmer på ett sätt så att tiden det tar att beräkna något minskar linjärt med antal CPU-kärnor. D.v.s. den algoritmiska komplexiteten har överhuvudtaget ingenting att göra med skalbarheten över CPU-kärnor.
För att ta ett konkreta exempel:
Algoritm: sökning i balanserade träd, för enkelhets skulle antar vi att det är binärträd så sökning är O(log(N))
Skalning: typiskt vill man låta flera CPU-trådar söka / modifiera trädet potentiellt samtidigt, gör man det med t.ex. RW-semaphore kommer det skala väldigt illa förbi 3-4 CPU-kärnor, representerar man sitt träd som en s.k. persistent datastructure så kommer det skala i princip till obegränsat antal kärnor.
D.v.s. valet av algoritm och abstrakt datatyp (binärträd) är helt frikopplat från hur jag väljer att representera denna data i minnet vilket är det som avgör hur det skalar över CPU-kärnor.
Vad du refererar till när du nämner "Turans sats" är algoritmer där beräkningen av ett enskilt problem kan spridas ut över flera CPU-kärnor via någon form av fork-join. Definitivt ett intressant område, men det är något som är totalt oanvändbart inuti en OS-kärna då fork-join i sig själv kräver ett OS för hantering av OS-trådar vilket blir en sekvens med otrevlig rekursion, OS-kärnan behöver ett OS för att utföra OS-tjänster...
För att fork-join ska fungera väl måste man typisk ha ett problem som kan uttryckas i form av en förenklad och splittad variant, typisk divide and conquer. Rekursion är absolut ajabaja i OS-kärnor då man har extremt liten stack för att minimera kostnaden OSet lägger på för varje OS-tråd.
Så hur väl OS-kärnor skalar i bemärkelsen: "hur många av något kan man rimligen ha" (hur stor FIB, hur många samtida socket, hur många öppna filen, hur mycket RAM) bestäms av vilka algoritmer man väljer och deras algoritmiska komplexitet. Hur väl OSet skalar i bemärkelsen: "vad får jag för effekt av att addera flera CPU-kärnor" beror på hur man valt att representera och synkronisera data (dessa två hänger väldigt mycket ihop).
Skrivet av MichaelJackson:
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?
Har aldrig skrivit att Linux skulle skala bättre än Solaris/AIX till 32-sockets, enda jag skrivit är att det idag säljs system med upp till 32-sockets om är avsedda för databaslaster. Nu säger inte SGI hur många maskiner de säljer av respektive storleken, men man kan utgå från att det är minst 16-sockets då 8-socket Xeon E7 system behöver ingen extra "glue-logic".
Hela poängen här är att visa att det finns en kunder som tydligen är beredda att betala väldigt mycket får att köpa dessa system så rimligen borde inte Linux vara en total kalkon, gissningsvis är perf/W och perf/$ bättre än ett Solaris/AIX system med motsvarande kapacitet. Om inte AIX och Solaris har bättre total kapacitet skulle de vara totalt meningslösa så utgår från att så är fallet och har aldrig hävdat motsatsen.
Det man kanske missar i denna diskussion är att vi nu pratar om en marknad som är en fraktion av en procent, frågan är om 8 socket system ens når 1% av servermarknaden.
Sedan måste man vara väldigt noga med att påpeka att detta just refererar till I/O-intensiva serverlaster, i superdatorlaster finns det ccNUMA-system som kör en enskild Linux-kärna med 100,000-tals CPU-trådar där det definitiv finns skalbarhetsproblem men dessa är absolut inte disk-I/O och liknande.
Skrivet av MichaelJackson:
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.
Nu har jag inte tillgång till större Linux-system än 4x 8-kärnor alt 2x 18-kärnor, men har du NICs med klassificering i HW (typ alla vettig 1 Gbit/s och alla 10/40/100 Gbit/s NICs) så finns det överhuvudtaget ingen anledning att det inte går att skala över CPU-kärnor förutsatt att du hanterar varje enskild session på en specifik CPU-tråd, varje CPU-tråd kan däremot ta hand om massor med session. D.v.s. typisk serverlast men väldigt många klienter.
Skrivet av MichaelJackson:
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”
Hur var det med det "kritiska" tänkandet här?
Anta att FreeBSD är överlägsen Linux för TCP/IP, varför kör inte FaceBook, Google, Huawei, Ericsson, Nokia, Cisco, Juniper m.fl. FreeBSD, varför envisas de med Linux? Och snälla säg inte "driver" för alla dessa är mer än stora noga att kunna beställa drivers till vilken HW som helst till FreeBSD. Om bara grävt lite till i detta så hade du hittat att FB pratade specifikt om IPv6, där har *BSD en fördel då de som utvecklar det största conformance test paketet för IPv6, IPv6 Ready, är BSD-frälsta och utvecklar typisk nya finesser och nya tester för dessa parallellt.
Skrivet av MichaelJackson:
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.
Vilken Solaris-version är OpenIndiana? Den TCP/IP-stacken har jag hyfsad koll på, ser inte hur den skulle skala bättre än Linux TCP/IP-stack på samma HW.
Skrivet av MichaelJackson:
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?
Ja? Den bistra sanningen är att Windows är bättre för de flesta person på skrivbordet, inte kanske p.g.a. Windows i sig (även om Windows länge var rätt ensam om helheten i de funktioner active directory erbjuder) utan därför att de program de flesta behöver finns bara på Windows.
Varför växer Linux på så många områden om det inte är bästa valet? Linux växer typisk på nya marknaden, så orsaken är inte legacy. Och min erfarenhet är också att ingen väljer Linux p.g.a GPL, det är snarare en rejäl minuspunkt för många företag, men ändå väljer de Linux över t.ex. FreeBSD som inte alls har dessa licensproblem...
Skrivet av MichaelJackson:
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.
Om du gräver fram någon av dessa diskussioner och läser vad jag skriver så kommer du se att för ett par år sedan skrev jag att Linux skalade inom vissa områden men hade definitivt problem inom andra, just fil I/O är ett område jag pekade ut där Linux var efter "riktiga" UNIX-ar.
Var också det jag skrev i förra posten, skalning kring fil I/O är de områden man relativt nyligen fortfarande kunde göra förbättringar som gav 50-60 högre prestanda på 8 socket system.
Skrivet av MichaelJackson:
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.
Mmm, det är jag som köper allt vem skriver och du som extremt kritisk granska allt som Oracle häver ut sig. Den här tråden innehåller i alla fall humor
Refererar inte till Intels eller IBMs marknadsmaterial, det jag skriver är mest från den erfarenhet jag fått under åren jag jobbade med att skriva specialdesignad "middleware" som körde på Linux-baserade Xeon-system. De få referenser jag gjort till Intel har ju varit teoretisk prestanda, maximala frekvenser och liknande. Du måste ju ändå ha lite särskiljning på marknadsmaterial (som kan säga vad som helst) och teknisk dokumentation (som är värdelös om den inte har som mål att vara korrekt).
Är tyvärr lite ringrostig på just Xeon v3 (Haswell), var främst Sandy/Ivy Bridge jag jobbade med. Numera är det som sagt mest ARM.
Skrivet av MichaelJackson:
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.
Humor igen. Har ju precis bevisat att E5-2699v3 når 744 GFLOPS på samma sätt som att SPARC M7 har en minnesbandbredd på 131-144 GB/s. Med din gedigna teoretiska bakgrund måste det ju vara uppenbart varför t.ex. Linpack aldrig kommer nå det teoretisk värdet, Linpack är inte "embarrassing parallel".
Ja, går ner på detaljer. Är exakt dessa kunskaper om detaljer som gjorde det möjligt att t.ex. kunna hantera 5 miljoner HTTP transaktioner över tiotusentals samtida session på en off-the-shelf Sandy Bridge Xeon per CPU-kärna. Inget traditionellt OS, inte ens Solaris, kommer inom en tiondel av detta. Här vet jag att många av "tricken" är möjliga p.g.a. av saker som t.ex. DDIO. Vet inte om jag missar helheten, för mig var det enda viktiga att denna programvara var vid det tillfället det snabbaste som existerade i världen körandes på standard server HW.
Skrivet av MichaelJackson:
Å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.
Fast läs vad t.ex. AnandTech skriver här (och håller med). Benchmarks som TPC-x, STREAM och även benchmarks för andra områden som Geekbench är inte bara lite off-the-mark, de är i flera fall överhuvudtaget inte representativa för hur olika system presterar relativt varandra i "riktiga" program.
Det finns definitivt ett värde i benchmarks, men det är inte att användas som underlag för om man ska köpa system X med OS Y eller system A med OS B, utan mest för att jämföra olika generationer av system X med OS Y.
Skrivet av MichaelJackson:
Å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.
Jag säger att M7 är snabbare i vissa fall, jag har aldrig sagt det andra du skriver. Ja min kodsnutt är ett specialfall, precis som t.ex. STEAMS eller andra syntetiska bechmarks är ett specialfall. Den mäter exakt en aspekt av systemet, var är maximal kapacitet för att beräkna R = A * B + C
Skrivet av MichaelJackson:
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.
STREAM är inte speciellt representativ för verkliga "access-pattern", t.ex. så presterar ARM Cortex A15 klart bättre än Intel Silvermont i STREAM, man i alla praktiska fall där "access-pattern" inte är lika regelbundet så presterar Silvermont konsekvent bättre, har sett fall där den presterar upp mot en tiopotens bättre.
Värdet på STREAM visar en väldigt specifik aspekt av systemet, vilken bandbredd ser man om man gör en totalt seriell access mot RAM? Min benchmark visar att det i praktiken går att uppnå teoretisk flyttalsprestanda m.h.a. FMA+AVX, precis som STREAM visar att Xeon v3 kan nå väldigt nära 100% av sin teoretiska RAM-bandbredd. Ingen av dessa benchmarks säger däremot speciellt mycket om vilken kapacitet man kommer få i ett viss specifikt program, enda man vet är att det inte är högre än dessa siffror.
Skrivet av MichaelJackson:
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.
Fast varken Oracle eller IBM anger CPU-bandbredd, båda anger teoretisk bandbredd mot RAM vilket inte är samma sak. CPU och alla enheter som använder DMA går via samma RAM-buss så de delar på samma totala bandbredd mot RAM.
Skrivet av MichaelJackson:
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?
Som jag redan skrivit, jobbar främst med ARM för tillfället så ser inte varför jag ska flaggvifta för x86. Tycker jag avfärdat benchmarks rätt konsekvent, ville jag visa saker via benchmarks är det ju bara välja drivor av benchmarks som mäter enkeltrådprestanda så skulle Intel vinna var enda benchmark. Men vad vore poängen?
Skrivet av MichaelJackson:
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?
Tror du inte alls förstår för DDIO, denna kommentar verkar rätt skum annars. DDIO gör att I/O-enheter kan läsa/skriva direkt från LLC, I/O kostar alltså inte RAM-bandbredd på samma sätt som för POWER/SPARC. Inte helt tekniskt korrekt, men se det som att CPU och I/O-enheter delar på L3-bandbredd i stället för att dela på den lägre RAM-bandbredden.
Skrivet av MichaelJackson:
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?
Håller med, men du har fortfarande inte greppat att cache har två dimensioner, tid och rum. Även serverlaster har mer eller mindre tidsmässig lokalitet på "working-set" så CPU-cache är allt annat än irrelevant.
Skrivet av MichaelJackson:
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.
SPARC T1 var en allt för snäv design för att någonsin ha något praktisk värde. Den var snabb på ett extremt snävt användarfall. Finns ARM-designer med 100 ARM-kärnor (som kör Linux BTW), i teorin har dessa system brutal perf/W, i praktiken är det hopplöst att använda en sådan design på något verkligt fall.
Skrivet av MichaelJackson:
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.
En FPGA är mer flexibel än ASIC, men en ASIC presterar normalt sett ett par gånger bättre på sin specifika uppgift.
Skrivet av MichaelJackson:
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.
Och den logiska slutsatsen att nästa 100% av alla superdatorer är byggda på x86 är då vad? Superdatorer byggs av idioter som inte begriper att x86 är det sämsta valet?
Skrivet av MichaelJackson:
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).
Vad har MPI med FMA att göra? Poängen är att när dimensionen på matrisen växer så går beräkningen i varje cell mot att exakt innehålla en multiplikation och en addition per rad/kolumn, d.v.s. perfekt match för FMA. I en 2x2 matris är det två multiplikationer och en addition, d.v.s en FMA plus en MUL som då inte kan ge teoretisk FLOPS kapacitet.
Skrivet av MichaelJackson:
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?
Skicka det! Ska bli intressant att se vem du förväxlat mig med
Vad jag själv kan ha skrivit är att det är möjligt att med affärsmässig vettig effektivitet köra SAP på UV2000, d.v.s. man kan uppnå bättre perf/$ med SGIs system för det problem man faktiskt har. Om det sedan skulle vara möjligt att lös ett mycket större problem på SPARC/POWER är ju i det läget irrelevant om det ger en sämre lösning på det problem jag faktisk vill lösa.
Skrivet av MichaelJackson:
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?)
Fast nu var det UV300RL jag pekade på då den var designad för Oracle 12c
Senast redigerat
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
Skrivet av Yoshman:
Mitt test ovan är den direkta parallellen för flyttal till vad STREAM är för CPU-bandbredd, båda är extremt syntetiska benchmarks som testar en enda aspekt.
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.
Citat:
Har lite koll på grunderna i alla fall efter att ha jobbat med utveckling av OS-kärnor och algoritmer för parallella system i ca 10 år. Så tar detta på "arbetarnivå" i stället för "akademikernivå", har ju ingen doktorshatt utan är en simpel civing (i.o.f.s topp 5% betyg på KTH det året jag gick ut).
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å...."
Citat:
Det jag menar med att de är ortogonala är att typ av algoritm bestämmer algoritmisk komplexitet, här måste du ändå hålla med om att du var totalt ute i de blå när du hävdade att "Linux använder simpla O(n^2) algoritmer som funkar bra på 1-2 sockets"
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?
Citat:
Vidare är det fullt möjligt att använda sig av O(N^2) algoritmer på ett sätt så att tiden det tar att beräkna något minskar linjärt med antal CPU-kärnor. D.v.s. den algoritmiska komplexiteten har överhuvudtaget ingenting att göra med skalbarheten över CPU-kärnor.
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
Citat:
För att ta ett konkreta exempel:
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å?
Citat:
Har aldrig skrivit att Linux skulle skala bättre än Solaris/AIX till 32-sockets,
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
Citat:
enda jag skrivit är att det idag säljs system med upp till 32-sockets om är avsedda för databaslaster. ...det finns en kunder som tydligen är beredda att betala väldigt mycket får att köpa dessa [Linux] system så rimligen borde inte Linux vara en total kalkon
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?
Citat:
Nu har jag inte tillgång till större Linux-system än 4x 8-kärnor alt 2x 18-kärnor,
Inte många linux utvecklare har det.
Citat:
men har du NICs med klassificering i HW (typ alla vettig 1 Gbit/s och alla 10/40/100 Gbit/s NICs) så finns det överhuvudtaget ingen anledning att det inte går att skala över CPU-kärnor förutsatt att du hanterar varje enskild session på en specifik CPU-tråd, varje CPU-tråd kan däremot ta hand om massor med session. D.v.s. typisk serverlast men väldigt många klienter.
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.
Citat:
Hur var det med det "kritiska" tänkandet här?
Anta att FreeBSD är överlägsen Linux för TCP/IP, varför kör inte FaceBook, Google, Huawei, Ericsson, Nokia, Cisco, Juniper m.fl. FreeBSD, varför envisas de med Linux? Och snälla säg inte "driver" för alla dessa är mer än stora noga att kunna beställa drivers till vilken HW som helst till FreeBSD.
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.
Citat:
Om bara grävt lite till i detta så hade du hittat att FB pratade specifikt om IPv6, där har *BSD en fördel då de som utvecklar det största conformance test paketet för IPv6, IPv6 Ready, är BSD-frälsta och utvecklar typisk nya finesser och nya tester för dessa parallellt.
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.
Citat:
Vilken Solaris-version är OpenIndiana? Den TCP/IP-stacken har jag hyfsad koll på, ser inte hur den skulle skala bättre än Linux TCP/IP-stack på samma HW.
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.
Citat:
Ja? Den bistra sanningen är att Windows är bättre för de flesta person på skrivbordet, inte kanske p.g.a. Windows i sig (även om Windows länge var rätt ensam om helheten i de funktioner active directory erbjuder) utan därför att de program de flesta behöver finns bara på Windows.
Varför växer Linux på så många områden om det inte är bästa valet? Linux växer typisk på nya marknaden, så orsaken är inte legacy. Och min erfarenhet är också att ingen väljer Linux p.g.a GPL, det är snarare en rejäl minuspunkt för många företag, men ändå väljer de Linux över t.ex. FreeBSD som inte alls har dessa licensproblem..
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.
Citat:
Om du gräver fram någon av dessa diskussioner och läser vad jag skriver så kommer du se att för ett par år sedan skrev jag att Linux skalade inom vissa områden men hade definitivt problem inom andra, just fil I/O är ett område jag pekade ut där Linux var efter "riktiga" UNIX-ar.
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.
Citat:
Mmm, det är jag som köper allt vem skriver och du som extremt kritisk granska allt som Oracle häver ut sig. Den här tråden innehåller i alla fall humor
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?
Citat:
Humor igen. Har ju precis bevisat att E5-2699v3 når 744 GFLOPS på samma sätt som att SPARC M7 har en minnesbandbredd på 131-144 GB/s.
Å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å"
Citat:
Ja, går ner på detaljer. Är exakt dessa kunskaper om detaljer som gjorde det möjligt att t.ex. kunna hantera 5 miljoner HTTP transaktioner över tiotusentals samtida session på en off-the-shelf Sandy Bridge Xeon per CPU-kärna. Inget traditionellt OS, inte ens Solaris, kommer inom en tiondel av detta. Här vet jag att många av "tricken" är möjliga p.g.a. av saker som t.ex. DDIO. Vet inte om jag missar helheten, för mig var det enda viktiga att denna programvara var vid det tillfället det snabbaste som existerade i världen körandes på standard server HW.
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.
Citat:
Fast läs vad t.ex. AnandTech skriver här (och håller med). Benchmarks som TPC-x, STREAM och även benchmarks för andra områden som Geekbench är inte bara lite off-the-mark, de är i flera fall överhuvudtaget inte representativa för hur olika system presterar relativt varandra i "riktiga" program.
Det finns definitivt ett värde i benchmarks, men det är inte att användas som underlag för om man ska köpa system X med OS Y eller system A med OS B, utan mest för att jämföra olika generationer av system X med OS Y.
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...."
Citat:
Jag säger att M7 är snabbare i vissa fall, jag har aldrig sagt det andra du skriver.
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?
Citat:
Ja min kodsnutt är ett specialfall, precis som t.ex. STEAMS eller andra syntetiska bechmarks är ett specialfall. Den mäter exakt en aspekt av systemet, var är maximal kapacitet för att beräkna R = A * B + C
Å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?
Citat:
STREAM är inte speciellt representativ för verkliga "access-pattern", t.ex. så presterar ARM Cortex A15 klart bättre än Intel Silvermont i STREAM, man i alla praktiska fall där "access-pattern" inte är lika regelbundet så presterar Silvermont konsekvent bättre, har sett fall där den presterar upp mot en tiopotens bättre.
Värdet på STREAM visar en väldigt specifik aspekt av systemet, vilken bandbredd ser man om man gör en totalt seriell access mot RAM? Min benchmark visar att det i praktiken går att uppnå teoretisk flyttalsprestanda m.h.a. FMA+AVX, precis som STREAM visar att Xeon v3 kan nå väldigt nära 100% av sin teoretiska RAM-bandbredd. Ingen av dessa benchmarks säger däremot speciellt mycket om vilken kapacitet man kommer få i ett viss specifikt program, enda man vet är att det inte är högre än dessa siffror.
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?
Citat:
Fast varken Oracle eller IBM anger CPU-bandbredd, båda anger teoretisk bandbredd mot RAM vilket inte är samma sak. CPU och alla enheter som använder DMA går via samma RAM-buss så de delar på samma totala bandbredd mot RAM.
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.
Citat:
Som jag redan skrivit, jobbar främst med ARM för tillfället så ser inte varför jag ska flaggvifta för x86. Tycker jag avfärdat benchmarks rätt konsekvent, ville jag visa saker via benchmarks är det ju bara välja drivor av benchmarks som mäter enkeltrådprestanda så skulle Intel vinna var enda benchmark. Men vad vore poängen?
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.
Citat:
Tror du inte alls förstår för DDIO, denna kommentar verkar rätt skum annars. DDIO gör att I/O-enheter kan läsa/skriva direkt från LLC, I/O kostar alltså inte RAM-bandbredd på samma sätt som för POWER/SPARC. Inte helt tekniskt korrekt, men se det som att CPU och I/O-enheter delar på L3-bandbredd i stället för att dela på den lägre RAM-bandbredden.
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?
Citat:
Håller med, men du har fortfarande inte greppat att cache har två dimensioner, tid och rum. Även serverlaster har mer eller mindre tidsmässig lokalitet på "working-set" så CPU-cache är allt annat än irrelevant.
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.
Citat:
SPARC T1 var en allt för snäv design för att någonsin ha något praktisk värde. Den var snabb på ett extremt snävt användarfall. Finns ARM-designer med 100 ARM-kärnor (som kör Linux BTW), i teorin har dessa system brutal perf/W, i praktiken är det hopplöst att använda en sådan design på något verkligt fall.
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.)
Citat:
En FPGA är mer flexibel än ASIC, men en ASIC presterar normalt sett ett par gånger bättre på sin specifika uppgift.
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.
Citat:
Och den logiska slutsatsen att nästa 100% av alla superdatorer är byggda på x86 är då vad? Superdatorer byggs av idioter som inte begriper att x86 är det sämsta valet?
Å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...
Citat:
Vad har MPI med FMA att göra? Poängen är att när dimensionen på matrisen växer så går beräkningen i varje cell mot att exakt innehålla en multiplikation och en addition per rad/kolumn, d.v.s. perfekt match för FMA. I en 2x2 matris är det två multiplikationer och en addition, d.v.s en FMA plus en MUL som då inte kan ge teoretisk FLOPS kapacitet.
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)
Citat:
Skicka det! Ska bli intressant att se vem du förväxlat mig med
Vad jag själv kan ha skrivit är att det är möjligt att med affärsmässig vettig effektivitet köra SAP på UV2000, d.v.s. man kan uppnå bättre perf/$ med SGIs system för det problem man faktiskt har. Om det sedan skulle vara möjligt att lös ett mycket större problem på SPARC/POWER är ju i det läget irrelevant om det ger en sämre lösning på det problem jag faktisk vill lösa.
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?
Citat:
Fast nu var det UV300RL jag pekade på då den var designad för Oracle 12c
Ä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...."
Citera flera
Citera
@MichaelJackson: Här var det högt i tak! Fast du borde kanske använt termen fanboy troll med Aspergers ett par gånger till för att riktigt få fram poängen
Vi tar det lite långsamt, nu är detta text så får ha lite fantasi att t.ex. Arne Weise läser detta med långsam trygg stämma.
Teoretisk flyttalskapacitet för Haswell är 16 DP per kärna och klockcykel, för att nå detta måste man använda FMA vilket i t.ex. Linpack aldrig går med 100% effektivitet då man gör mer än bara matrismultiplikation. SIMD-enheterna är 256-bitar breda, finns två SIMD-enheter per kärna så 8 DP per kärna och cykel när man inte använder FMA.
Teoretisk flyttalskapacitet för POWER8 (och även för POWER7) är 8 DP per kärna och klockcykel , för att nå detta måste man använda FMA. Ser du en likhet? SIMD-enheterna är 128-bitar breda, funns två SIMD-enheter per kärna så 4 DP per kärna och cykel när man inte använder FMA.
Vad mitt program bevisar är att man i praktiken kan nå 98-99% av teoretisk flyttalskapacitet, FLOPS är enbart flyttalsoperationer per sekund och för att visa peak FLOPS så kvittar det totalt vilken typ av beräkning man utför. Det är inte alls säkert att det går att nå nära 100% i peak, när man jobbar med t.ex. ARM så är det snarare normalfallet att man överhuvudtaget inte kommer i närheten av teoretisk kapacitet med något program.
Men eftersom du är så väldigt på just Linpack. Teoretisk max för POWER8 (vilket då förutsätter 100% effektivitet med FMA) är 384 GFLOPS vid 4,0 GHz
"With the cores running at 4GHz, and each core capable of 4 double precision FMA operations per cycle, the peak performance is 384 GFlops per chip. This is not as high as a top-of-the-line x86 CPU, or a GPU, but with the huge cache and memory bandwidth it should achieve a higher percentage of peak on many real world applications. - See more at: http://webcache.googleusercontent.com/search?q=cache:eCZxiLBPWM4J:www.oerc.ox.ac.uk/projects/asearch/hardware/ibm+&cd=3&hl=sv&ct=clnk&gl=se#sthash.9EAx3ihJ.dpuf"
Intel har kört Linpack med AVX2 (AVX+FMA) och postat resultatet här, två sockets får 985 GFLOPS, vilket betyder att en CPU får minst (Linpack skalar inte helt linjärt med kärnor) 985 / 2 = 492 GFLOPS. Redan där är den snabbare än POWER8.
Testade att köra Intels Linpack på en 2699v3 CPU, resultatet blev 524 GFLOPS som mest.
IBM verkar inte postat några POWER8 resultat för Linpack, gissningsvis för man inte vinner några "världsrekord" i denna benchmark... POWER7+ verkar nå runt 85% teoretisk max, men även om vi antar att POWER8 når 100% av teoretisk max (vilket då är omöjligt då FMA inte har 100% effektivitet i Linpack) så är den långsammare. Vad TDP har med detta att göra vet jag inte, men verkar som du ser något väldigt starkt samband där...
Så två fel av två möjliga från din sida, dels når inte POWER8 ens i teorin än mindre i praktiken. Sedan kan E5 2966v3 nå över 400 GFLOPS i praktiken. Din extrapolering vad runt "rimlig" x86 kapacitet ser jag överhuvudtaget hur den skulle vara relevant. Det har varit 3 "Diracpulser" i flyttalskapacitet för x86. Först Core2 som dubblade kapaciteten till 4 DP per cykel och kärna (två SSE4_2 enheter per kärna), sedan Sandy Bridge som dubblade per cykel och kärna till 8 DP (AVX som ökade bredden från 128 till 256 bitar, från 2 DP till 4 DP per instruktion) och senast Haswell som lade till FMA (AVX2).
Då lägger väldigt mycket ord i min mun jag aldrig skrivit. Jag skrev inte att du hade dålig koll på algoritmer, jag skrev att du har väldigt dålig koll på flaskhalsarna som operativsystemutvecklare brottas med när det kommer till skalbarhet. För operativsystem så styr den algoritmiska komplexiteten hur stort tillstånd man kan hantera, d.v.s. hur många samtida filer, hur många samtida sockets, hur komplicerad FIB, hur mycket RAM (d.v.s. hur många page:ar) man kan hantera etc.
Skalbarhet över kärnor uppnår inte OS genom att använda någon typ av fork-join för att sprida ut enskilda sessioner på flera CPU-kärnor, man uppnår skalbarhet från ett sätt som är helt ortogonalt till ovan. Beroende på hur man väljer att representera sin data och beroende på vilken policy som behövs för att korrekt läsa/skriva denna data (vilket alltså inte har någon direkt korrelation till valda algoritmer och deras tidskomplexitet) så får man olika bra/dålig skalning vid hantering av många samtida session över CPU-kärnor. Man sprider alltså de sessioner man jobbar med för tillfället över tillgängliga CPU-trådar.
Varken OS eller "serverlaster" innehåller normalt sett problem som är P-fullständiga, så vet inte varför du ens blandar in detta. Om man nu har P-fullständiga problem så är de inte parallellserbara via fork-join så den typ av problem löser man bäst på CPU-designer med maximal enkeltrådprestanda, d.v.s. POWER8 eller om det är väldigt "coars-grained" Haswell (POWER8 har högre prestanda per CPU-kärna när alla CPU-trådar används men Haswell har högre enkeltrådprestanda).
Vidare så Solaris (om nu OpenIndiana är representativt för dagens Solaris) bygger sin skalbarhet främst på att ha mycket logik kring att identifiera OS-trådar och data från I/O-enheter som verkar höra ihop med en viss session. Anledningen till detta är för att i möjligaste mån undvika en effekt som kallas "cache line bouncing"
"The lock variable is set by the test_and_set operation on every spinning cycle. While CPU 1 is in the critical section, CPU 2 and 3 constantly read and write to the cache line containing the lock variable. The line is constantly transferred from one cache to the other, because both CPUs must acquire an exclusive copy of the line when they test-and-set the lock variable again. This is called "cache line bouncing", and it imposes a big load on the memory bus. The impact on performance would be even worse if the data protected by the lock was also lying in the same cache line. "
En hel del av det arbete som gjorts i Linux på senare år har samma syfte, att en cache-line frekvent tvingas hoppa mellan olika CPU-kärnor är en rejäl flaskhals för skalning över CPU-kärnor (notera att CPU-trådar på samma CPU-kärna inte orsakar cache-line bouncing så är mycket enklare att hantera dessa). Men RCU gör det möjligt, i de fall man kan använda RCU vilket är långt ifrån överallt, att totalt undvika detta problem helt och hållet då normalfallet för RCU aldrig resulterar i en skrivning till en cache-line som måste delas mellan kärnor som delar data. Bästa optimeringen man kan göra är att se till att en beräkning/uppgift överhuvudtaget inte behöver göras. Så RCU har större potential för att skala över CPU-kärnor för den läger i stort sett noll restriktion på vilken CPU-kärna som ska hantera en viss session.
Vad vi diskuterade kring SGI UV2000 var huruvida det var ett kluster eller ej, inte huruvida det är "scale-up" eller "scale-out". Det senare är överhuvudtaget inte väldefinierade tekniska termer och vill helst undvika sådant i sådana här diskussioner då det alltid blir en påfågeldans av nördar med väldigt stora teknikegon, bäst då att hålla sig till en väldigt väldefinierad syntax. UV2000 är ett ccNUMA system, d.v.s. det är inte ett kluster. Att man sedan nästan uteslutande väljer att partitionera dessa system i zoner om 4 CPU-sockets med shared memory som extremt snabb MPI-kommunikationskanal gör inte systemet till ett kluster.
Kluster: ett system bestående av mer än en adressrymd och därmed mer än en OS-instans, dessa är ihopkopplade med någon form av inter-node kanal.
ccNUMA SMP-system: ett system bestående av en OS-instans och en adressrymd som hyser alla CPU-kärnor.
Sedan får jag göra en ödmjuk uppmaning att kanske läsa dina egna länkar lite bättre:
Du skriver "Det verkar som att Linux hade skalningsproblem när man går till 16/32 sockets"
Man får ändå kanske gratulera till att du lyckas få in två fel i en mening
Artikeln att man får problem med att "NUMA-avståndet" (kostnaden att läsa/skriva RAM på en annan CPUs RAM) när man kliver upp till 64 CPU-sockets inte längre är samma mot alla andra CPU-sockets.
"SGI has dropped the latency on the links between Xeon server nodes to new lows with its NUMALink 7 interconnect and has also made the latencies consistent so this NUMA box behaves, for all intents and purposes, as an SMP machine that doesn’t have to worry about data placement issues. In effect, a UV-300 machine looks like a giant workstation, albeit one that has up to 32 sockets and up to 24 TB of main memory."
"For customers who are willing to shift from all-to-all topology and pay a little latency penalty for their workloads (and have to possibly do a little NUMA tuning with their applications and databases), SGI will allow the UV 300 machines to scale up to 64 Xeon E7 sockets and up to 64 TB of total memory."
Så skalbarhetsproblemet ligger i maskinvara, inte i OS samt problemet uppstår först när man går över 32-sockets.
Angående cache. DDIO gör så att I/O-enheter direkt kan läsa/skriva data till L3-cache. Även i serverlaster så måste ju data hanteras av CPUn och i alla moderna designer går dessa minnesaccesser via CPU-cache. Med DDIO ligger data som kommer in från I/O-enheter direkt i L3 och CPUn kan då direkt läsa/skriva data med bandbredd och latens motsvarande L3-kapacitet. Gissar att man har patenterat detta upp till öronen för enbart denna ändring gav runt 80% högre prestanda mellan Westmere (32nm Nehalem) och Sandy Bridge (första Xeon att få DDIO), POWER och SPARC har långt mer bandbredd mot RAM men där kommer också all DMA just hamna i RAM och inte i L3-cache (eventuellt hamnar det i POWER8 L4-cache för den sitter på "RAM-sidan"). Effektiv bandbredd är därför begränsad av L3-bandbredd och inte RAM-bandbredd för Sandy Bridge Xeon och senare (DDIO är del av "uncore" och finns inte i Xeon E3 och konsumentmodeller).
Har sedan aldrig sagt att det skulle vara något fel på de benchmarks Oracle presenterat för SPARC M7, är övertygad om att de är korrekta och att SPARC M7 verkligen är snabbast på dessa arbetslaster. Hängt upp mig lite på Hadoop mest för att det var ett så totalt irrelevant mått man presenterade, ungefär som en biltillverkare började mäta hur fort vindrutetorkarna går, vem bryr sig? Hadoop är utvecklat från grunden att skala extremt väl över kluster, kluster som inte ens har speciellt snabb inter-node länkar. Så hur är den prestanda man får på en CPU-socket överhuvudtaget relevant i kontext av Hadoop???
Vidare så har även "serverlaster" en varierande grad av parallellism, du nämnde själv Ahmdals lag och även vid extremt låga grader av seriell del så är det bättre med färre starka CPU-trådar än väldigt många CPU-trådar med något högre aggregerad kapacitet. För att ta ett konkret exempel, om man har fem procent av jobbet som är seriell går det inte att få högre speed-up med 32 * 8 (antal trådar mer M7 kärna) än 18,6 (det förutsätter att det finns noll flaskhalsar i form av minne, kommunikation med I/O-enheter och liknande annars blir den ännu lägre). Med motsvarande seriella del är maximal "speed-up" för en E5 2699v3 13,1. I praktiken betyder det den senare är rejält mycket snabbare då prestanda per CPU-tråd är många gånger högre i 2699v3 än M7 om båda använder alla CPU-trådar. Notera att Ahmdals inte säger att man inte kan använda alla CPU-trådar, den säger bara att den aggregerade effekten inte blir högre än den speed-up lagen ger (speed-up är hur många gånger snabbare än enkeltrådfallet det blir).
För att ta en liten referens, ett enda cache-line bounce om man hanterar en transaktion mer mikrosekund är flera procentenheters "seriell" del. Den seriella delen är absolut, kanske inte helt normalt att en enskild transaktion tar en mikrosekund men man får samma utslag i den seriella delen om aggregerad kapaciteten är en miljon transaktioner per sekund. Det är en genomströmning som inte är det minsta extrem för många typer av serverlaster, typ alla former av "deep-packet inspection" i detta område.
SPARC M7 är världens snabbaste CPU på laster som fungerar bra med extrem "fine-grained threading", det är långtifrån alla "serverlaster" och det är ganska exakt noll laster som "vanliga" användare kör.
För att använda mig av din retorik, den måste ju vara rumsren eller hur? Jag är övertygad om att 99,87% av alla program körs snabbare på POWER8 och Haswell än på SPARC M7, jag ändrar naturligtvis åsikt om du kan visa länkar/tester som visar motsatsen.
Tror inte jag är x86 fan-boy, ser inte värdet att "heja" på ett "lag" då inget företag är min vän utan som mest kan de ha en produkt som råkar passa mig bäst för tillfället. Skriver mycket om x86 här för att jag har väldigt mycket erfarenhet av att skriva enormt optimerad kod för dessa CPUer och har extrem detaljkunskap kring vad som fungerar och vad som inte fungerar när man vill få ut maximalt. Har inte den erfarenheten av POWER (har relativt mycket PowerPC erfarenhet men det är bara samma ISA, är lite som att jämföra Atom och "Core") inte heller av SPARC (även här har jag ändå erfarenhet av att handoptimera saker i assembler, men det är många år sedan nu).
Men främsta orsak kring att det blir så mycket x86 är för att jag känner det som ett kall att hjälpa dig på rätt väg när du fått så mycket om bakfoten gällande x86, se det som ren välgörenhet.
Vidare är Intel (och även AMD) väldigt öppna med mikroarkitektur och personer som Agner Fog gjort det möjligt att förstå moderna x86or på en nivå som överhuvudtaget inte är möjligt med någon annan CPU-mikroarkitektur. Har sedan VIC-20 tiden älskat att lära mig hur CPUer fungerar ner på absoluta detaljnivå. Men skulle väldigt gärna vilja ha tillgång till maskiner som POWER8 och SPARC M7. Och angående tillgång, alla som jobbar med Linux-kärnan har tillgång till de största servers Intel och HP bygger då båda dessa företag har labb där Linux-utvecklare enkelt får gratis tillgång till. Så även om jag inte har fysisk tillgång till mer än 2/4 socket system så har jag "virtuell" access till de största x86-system som dessa företag bygger idag. Vet inte om andra företag har liknande policy, t.ex. SGI.
Edit: IBM har en liknande setup för POWER8 kring OpenPOWER och Linux.
Senast redigerat
Visa signatur
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer
Citera flera
Citera
(6)
Känns som trådtiteln kanske är något missvisande beroende på vad man tittar på samt att den känns något spekulativ än så länge.
Jag menar att det där beror väl mycket på vad man är ute efter, mest med tanke på att Sparcar på senare år varit väldigt specifika för uppgifterna de oftast kör. I min bransch så har jag aldrig uppfattat dem som snabbast, inte ens under de åren de slogs som mest mot DIGITAL och/eller Mips designer och man satt med Silicon Graphics IRIX system.
Fast jag har inte haft någon koll på deras utveckling de senaste 10 åren heller iofs. Så jag framstår som arrogant förmodligen. Men helt klart oavsett utfall så är ju perf/watt/pris extremt viktigt idag, även om det kanske inte spelar så stor roll om man jämför absolut prestanda, så klart.
Men vet inga i branschen som skulle överväga Sparc idag, fast ytterst beror det ju på kostnaden, så klart. x86 dominerar, och sedan "Nehalem" så beror det inte enbart pga priset heller, så att säga.
Sen när man tittade på Specint och framförallt Specfp så vet jag att det många gånger inte hade mycket med verklig prestanda att göra heller, speciellt inte när man renderade, eller verkligen belastar systemen i verkligheten. Det enda de fungerade till var om man jämförde system inom samma arkitektur och man eventuellt baserade uppgraderingar utifrån det. Men återigen, har inte använt mig av det där på väldigt många år heller.
Vore kul om det fanns ett sätt att jämföra prestanda över olika arkitekturer rättvist som speglade faktiska användarupplevelser som man kan relatera till, beroende på vad man är intresserad av. Även om det är mest av akademisk betydelse, inte så att man som liten firma/frilansare bygger/köper server från SUN att rendera på som exempel, även om det nu vore relevant till uppgiften (flyttalsprestanda).
Finns det fler ställen med relevant data för prestanda mellan top-CPUerna från de olika tillverkarna som inte kommer från spec.org och/eller tillverkarna?
Hur som helt, kul läsning, och intressant att se att ni trots meningsskiljaktigheter/gamla begravda yxor ändå lyckas hålla nivån någorlunda vuxen och intressant.
Visa signatur
Ride more, Work less!
Citera flera
Citera
Gött när telefon går ner på knä över mängden text i tråden. :')
Visa signatur
Star Citizen ❤
Citera flera
Citera
Hårdvara
- Igår Intel skyller Raptor Lake-krascher på moderkortstillverkare 27
- Igår TSMC utvecklar enorma kretsar med effekt mätt i kilowatt 11
- Igår Så mycket långsammare blir Intels värstingkretsar med ”Intel Baseline” i BIOS 52
- 26 / 4 Corsair Platform 6: För dig som inte nöjer dig med Ikea-skrivbord 11
- 26 / 4 Rykte: Switch 2 släpps i höst – OLED-variant dröjer 51
Mjukvara
- 27 / 4 Stöd för komprimering i fler format på gång till Windows 19
- 27 / 4 Krönika: "Early access" är utstuderad girighet 47
- 27 / 4 Microsoft släpper källkoden till MS‑DOS 4.00 20
- 26 / 4 Ny caps lock-symbol i Windows förbryllar HP-användare 21
- 26 / 4 Därför blockerar Windows 11 24H2 Start‑menyhack 43
Övrigt
- Igår Google nöjda med annonsexperiment: Youtube kan få pausreklam 28
- 27 / 4 Övergivet skadeprogram infekterar miljontals maskiner 17
- 27 / 4 Helgsnack: Är all reklam till ondo? 85
- 26 / 4 NetonNet varnar om läckta kunduppgifter 23
- 26 / 4 Premiär på SweClockers! Månadens drop med gamingskärm hos Elgiganten 74
Datorkomponenter
Ljud, bild och kommunikation
- Google nöjda med annonsexperiment: Youtube kan få pausreklam28
- Visa dina spelvideor1
- Samsung Galaxy Watch 35
- Veckans fråga: Hur mycket lagringsutrymme har din dator?115
- ECC Minnen till Fujitsu primergy tx1320 m346
- Gå ner i vikt - tråden3337
- PUBG: Playerunknown's Battlegrounds4980
- Vilken film såg du senast?13386
- Ubuntu 24.04 LTS39
- Airtec Pro Type1 – batteridrivet alternativ till tryckluft på burk108
- Säljes ASUS ROG Strix 3080 10GB White
- Säljes CoD MW3 ps5 inkl lockpick, Noctua NH-U12S AM4, DAC och HDD
- Säljes Elgato Wave 3 mikrofon
- Säljes TC-Helicon GoXLR Mini
- Säljes Komplett dator, 2700x, GTX 1070
- Säljes Vårstädning - i5-6600, GA-H170N-WIFI, 2x8GB DDR4, GTX 760, Noctua NH-U12S, FD Tesla 650W
- Köpes Uppgraderingspaket am4/am5/lga1700, ssd, gpu
- Säljes Flertal sata SSD'er 480GB-2TB
- Säljes Playstation 5 Digital 825gb
- Köpes Billig / gratis moderkort & cpu sökes till behövande pojk!
- Google nöjda med annonsexperiment: Youtube kan få pausreklam28
- Intel skyller Raptor Lake-krascher på moderkortstillverkare27
- TSMC utvecklar enorma kretsar med effekt mätt i kilowatt11
- Så mycket långsammare blir Intels värstingkretsar med ”Intel Baseline” i BIOS52
- Stöd för komprimering i fler format på gång till Windows19
- Krönika: "Early access" är utstuderad girighet47
- Övergivet skadeprogram infekterar miljontals maskiner17
- Helgsnack: Är all reklam till ondo?85
- Microsoft släpper källkoden till MS‑DOS 4.0020
- Ny caps lock-symbol i Windows förbryllar HP-användare21
Externa nyheter
Spelnyheter från FZ
- Dragon’s Dogma 2 har sålt så bra att Capcom betalar ut mer pengar till aktieägarna igår
- Silent Hill 2 – Snart avslöjas släppdatum och till vilka plattformar det släpps igår
- River City Girls 2 gästas av Double Dragon i sommar igår
- Sand Land delar en sista hälsning från Akira Toriyama 27/04
- Alien: Rogue Incursion släpps till VR senare i år 27/04
