Skrivet av Petterk:
Det är skillnad på ett single-image system och ett kluster med höghastighetsnätverk – det förstnämnda kan köra ett OS på de där 256 socklarna.
Det är inte så stor skillnad mellan dem. T.ex. ScaleMP som blir slagen utav SGI UV1000 på SPECjbb i din länk, är ju ett kluster. ScaleMP kör vSMP, dvs virtuell SMP, dvs det är en hypervisor som körs ovanpå ett kluster. Hypervisorn lurar Linux kernel till att ScaleMP är en enda stor scale-up maskin, men i själva verket är det ett kluster med massa små noder. Och då kan man köra en single image Linux kernel på ScaleMP beräkningsklustret. ScaleMP är ju "leader within High Performance Computing" som de själva säger. Dvs, HPC är ju beräkningskluster. Och ingen kan köra monolitisk mjukvara på HPC kluster. Det skulle bli urdåliga prestanda, pga monolitisk affärssystem branchar koden jättemycket, och latensen mellan noderna långt ifrån varandra i ett kluster skulle ställa till det. Det enda som kan köras på ScaleMP, är embarassingly parallel mjukvara, dvs kod där det är endast lite kommunikation mellan noderna, typ som SETI@home, eller SPECjbb, etc - dvs beräkningar där man portionerar ut lite beräkningar mellan varje nod, och sen när man är klar med beräkningarna så sammanställer man alla data. Så kommunikationen minimeras. Men i ett stort affärssystem som SAP (inte Hana) så kommuniceras det mycket, och det går inte att göra på ett distribuerat system med noder utspridda långt bort, med dålig topologi.
Idealt ska varje CPU ha minst en direktkanal till varje annan CPU. Så om du har 2, 4 eller 8 st cpuer, så kan det se ut så här:
http://regmedia.co.uk/2012/09/03/oracle_sparc_t5_coherency.jp...
Vi ser att med 2 cpuer, så är det 4 direktkanaler mellan cpuerna. Och med 8 cpuer så är det 28 direktkanaler mellan cpuerna. Föreställ dig ormboet av direktkanaler ifall du har 16 eller 32 cpuer! Det blir mycket komplicerat och rörigt att få ordning på det. Enligt kombinatorik så behöver du n! / 2*(n-2)! direktkanaler med n cpuer. Så med 32 cpuer skulle du ha 496 direktkanaler mellan varje cpu. Men helst ska du ha flera direktkanaler så du får upp bandbredden ordentligt. Det är inte lätt att bygga en stor scale-up server med så många kanaler som 496 stycket. Det man gör istället i praktiken, är att man grupperar ihop cpuerna, så att man kanske har 8 st grupper om 4 cpuer i varje. Också har man en fet kanal mellan varje 4-grupp cpuer. Som den här IBM POWER8 servern med fyra cpuer.
http://2eof2j3oc7is20vt9q3g7tlo5xe.wpengine.netdna-cdn.com/wp...
Men idealt är att varje cpu ska vara kopplad till varandra. Så det borde gå många fler pilar ut från denna 4-grupp av POWER8 cpuer, totalt borde det vara 120 pilar (eftersom POWER8 skalar upp till 16 cpuer maximalt, och då blir det 120 direktkanaler mellan varje cpu). Så vi ser att POWER8 kommer ha problem med scale-up. Den skalar inte så väl, ju fler cpuer vi lägger till, desto sämre blir kommunikationen mellan varje cpu. Och 16 cpuer är maxgränsen för IBMs största POWER8 server som heter E880.
Om du då har 256 cpuer som alla är kopplade till varandra, så behöver du nästan 35,000 direktkanaler mellan alla cpuer. Och det inser man att det funkar inte. Så SGI och ScaleMP tar ordentliga genvägar. De har stora grupper, inte om 4 cpuer i varje, utan mycket större grupper, och hierarkier av cpu grupper. Och då blir bandbredden mellan varje cpu blir mycket dålig, t.ex. om cpu nr 67 ska kommunicera massivt med cpu nr 239, så finns inte tillräckligt många kanaler, speciellt som alla andra cpuer ska samsas. Kommunikationen mellan 67 och 239 får ta massa omvägar, ut på de stora breda motorvägarna. Och till slut kan kommunikationen ta in på smågator för att nå fram till nr 239. Så de stora motorvägarna har gott om bandbredd, men latensen får även stryka på foten, och det är ju latensen som är viktig när det gäller monolitisk mjukvara. Du kan få god bandbredd eller dålig latens, eller tvärtom. Du kan inte få båda samtidigt.
Så man inser varför det blir stora problem att köra monolitisk mjukvara på något som har fler cpuer än 16 (som IBM också anser i E880). När du har stora motorvägar mellan grupper av cpuer, så blir det många omvägar. Om istället varje cpu är kopplade till varandra så blir det mycket snabbare, och du kan köra monolitisk mjukvara upp till typ 16 cpuer (som IBM tycker). Men inte mycket större scale-up servrar än så kan du bygga effektivt. Det är helt uteslutet att du skulle kunna bygga en effektiv scale-up server med 64 cpuer eller 96 cpuer eller större. Allt som är större än så, är någon form av fusk inblandat, så det blir stora grupper av cpuer och latensen mellan noder långt ifrån varandra blir dålig. Dvs, vi har ett kluster i praktiken. Och det märker man på att dessa stora SGI och ScaleMP servrar, aldrig kör scale-up benchmarks. Tex. finns det inga SAP, TPC, etc benchmarks på dem. Och nu när vi förstår mer om problematiken om kopplingarna mellan cpuerna, så inser vi varför de aldrig kan köra scale-up monolitisk mjukvara. Sen kan man förstås skriva distribuerad mjukvara till den, såsom t.ex. SAP Hana klustrade databaser. Men de kan aldrig konkurrera med en scale-up maskin. Om du har en 32 cpu scale-out server vs en 32 cpu scale-up server så kommer alltid scale-up servern vinna.
Dessutom, om man läser lite om SGIs servrar, dvs Altix, UV1000, UV2000, etc - så har de alla en MPI enhet. MPI används endast inom klustrade beräkningar. Scale-out saker. T.ex. IBM E880 har ju ingenting för att underlätta MPI trafik därför att E880 är inte någon scale-out server. MPI används endast inom klustrade vetenskapliga beräkningar. Det finns ingen databas eller monolitisk mjukvara som använder sig av MPI. Ska du börja använda MPI så måste du skriva om affärssystemen så de blir klustrade, och genast börjar du få problem med lås, synkronisering, rollback, etc.
Citat:
Hana kan köras på både kluster och single-image system och det finnas andra IMDB som tar nytta av single-image system också. In-memory databaser är ju bara en tillämpning. Det är såklart fortfarande ett scale-upsystem även om du kör flera instanser av en applikation.
Om du inte kör Hana som ett kluster, så får du stanna vid 8 cpuer. Det går inte större konfigurationer med single node. Vill du gå över 8 cpuer, så måste du köra kluster. Och då blir prestandan relativt sämre, än en stor single node konfiguration.
Från PetterKs länk:
Hana SAP-certified and available today as a 4- or 8-socket single-node system with up to 6 terabytes (TB) of in-memory computing,
SGI UV for SAP HANA utilizes a unique scale-up, single-node architecture designed to deliver performance at unprecedented platform capacities. The simplicity of a single-node will allow enterprises to run applications free from the overhead of clustered appliances and reduce installation time—there are no cluster nodes, cluster network, or SAN to configure and administer. And there will not be a need for database partitioning or re-balancing I/O when increasing the size of the SGI appliance.
Citat:
Att Zen skulle vara mycket snabbare än Intel är inte ett rimligt antagande. Det är ju inget de behöver vara. Däremot är det inget mindre generationsskifte det handlar om på samma grundarkitektur – Intel bygger fortfarande vidare på Nehalem.
Jomen Zen kommer vara mycket snabbare än AMDs föregångare tror jag. Jag tror inte det är möjligt att överklocka Zens föregångare, och nå upp till Zen prestanda. Men det kan du göra med Intels Q66600. Vad säger det dig om Intels cpuer? När en gammal generation cpu är lika snabb som de senaste? Då är det inte vidare lyckat? Men hur ska man t.ex. matcha Zens beräkningsdel, med föregångscpun? Jag tror Zen kommer att vara mycket snabbare än allt Intel har, speciellt om man börjar använda grafikdelen. Intel kan inte matcha det.
Skrivet av Yoshman:
Är inte expert på databaser, jobbar med OS-kärnor och middleware, men huvudpoängen var bara:
SGI-UV är inte ett kluster, det är ett ccNUMA-system precis som multisocket-system byggt på QPI, Bixby, HyperTransport etc. Jämför man NUMALink 6 med Bixby v1 så ger det förra ett system mer likt en massivt multicore krets då det absolut kritiska är kommunikationslatensen vilken är 50% högre i Bixby. Latensmässigt så ligger NUMALink 6 på ungefär samma nivå som QPI när detta används i 2/4-socket system (är något högre latens vid 8 sockets).
Visst, det låter bra det du säger. Men kan du presentera någon ickle klustrad benchmark som kör monolitisk mjukvara (inte klustrad databas SAP Hana, för klustrade databaser har massa andra problem som jag inte vill gå in på)? Nej, såna existerar inte. Om du läser runt lite, så ser du att alla kunder kör någon form av klustrad mjukvara. Och om du läst det ovan om cpuer som vill ha många datakanaler, så inser du varför ingen kör monolitisk mjukvara som branchar mycket på kluster. Kluster kan köra mjukvara som inte branchar mycket, som inte kommunicerar mycket mellan cpuer - typ Hana. Ingen kör typ TPC eller SAP eller nåt sånt, på dessa nischade beräkningsservrar. Jag läste om några andra som försökt spara pengar och slippa köpa en stor Unix server med 16cpuer, så de började utveckla egen transaktionsintensiv mjukvara över ett tight kluster. Förhoppningen var att de skulle skala upp och få grymma prestanda och sälja det med stor förtjänst, eftersom det inte fanns något sådan mjukvara på marknaden. De spenderade mycket tid och pengar, men det blev väldigt knöligt till slut med alla lås, rollback vid ej commit, dataintegritet, etc etc. Det slutade med att de köpte en stor Unix server istället. Det var mycket svårare än de trodde när de började grotta ned sig i detaljer. Översiktligt verkade det enkelt och straightforward, men detaljerna dödade hela projektet. Det finns en anledning att det fortfarande inte finns någon bra klustrad mjukvara inom just det transaktionsintensiva segmentet, än idag. Om det vore enkelt skulle alla göra det, och det skulle inte finnas någon marknad för stora dyra Unix servrar.
Citat:
Frågan är om någon annan ens slår Core2 i enkeltrådprestanda (Apples Cyclon har högre IPC än Core2, men inte tillräckligt mycket högre för att matcha Core2 vid 2.5-3GHz), att man ändå lyckats öka enkeltrådprestanda rätt mycket fram till Sandy Bridge är imponerande.
Har du kollat IBMs POWER8? Just POWER skryter med att ha bäst trådad prestanda av alla.
Skrivet av Petterk:
Vad det gäller JVM så är ju detta vad vi vet. (Altix 4700 är en annan maskin än just den Yoshman länkade)
SGI Altix är föregångaren till UV1000 och UV2000. Det är samma server, med vissa förbättringar.
Citat:
Tittar man på deras press-releaser så ser man att Skoda exempelvis kör både ICE X kluster och UV 2000 och båda främst används för CFD, men anledningen att köpa ett UV-system är såklart cache-koherent minne eller att du har väldigt mycket minne i samma system. I fall där kluster är bättre erbjuder de ju detta. Bland annat med Infiniband.
Det finns en anledning till att både SGI och ScaleMP används främst för CFD och andra beräkningar - de är beräkningsservrar. De kör främst mjukvara som påminner om SETI@home. Ingen kör ERP affärssystem på SGI eller ScaleMP beräkningservrar, latensen skulle bli för dålig.
