Intel går igenom nyheterna i Haswell

Du jämför definitivt äpplen och päron här. Oracle referens till SPARCs prestandaförbättring refererar till aggregerad prestanda, d.v.s. summan av den prestanda du teoretiskt kan få om alla kärnor och trådar jobbar samtidigt. Med det sättet att räkna så har prestandaförbättringen på Xeon var betydligt mer än så under de senaste 5-7 åren då man gått från single core P4/PentiumM baserade Xeons på ~2GHz till 10 kärniga Sandy Bridge baserade Xeons på upp till 3.8 GHz.

För en server är I/O hastigheten väldigt viktigt, jämför då SPARC T5:s 2x8 PCIe 3.0 banor per sockel mot de värsta Xeon med 40 PCIe 3.0 banor per sockel. Just I/O hastigheten ökade med nära nog 80% från Westmere till Sandy Bridge då Sandy Bridge kan köra DMA från/till L3-cache (känt som DDIO) medan andra CPUer och tidigare Xeons måste flusha ut data till RAM då DMA endast kan utföras därifrån.

Tittar du på IPC förbättringarna mellan SPARC T4 och T5 så är det definitivt ingen fördubbling, det är mer de 10% du såg mellan Sandy till Ivy.

Fast så fasligt dyr är inte Xeon. Skiljer någon 100-lapp mellan Core i7-3930K och motsvarande Xeon. Därför jag inte riktigt begriper varför folk skriker om Ivy Bridge E och Haswell E, det är ju bara köpa Xeon då det ändå handlar om samma sockel.

160%-180% är nog i VÄLDIGT ideala fall. Hittade denna site http://www.softlab.ntua.gr/release/bencherl/results.html som visar hur Erlang beter sig på en lite olika system, bl.a. en Bulldozer med 32 moduler (64 trådar). Kolla hur mycket mindre effekt det är efter 32 trådar och i vissa fall MINSKAR prestanda när man passerar 32-trådar.

Edit: känner att jag inte ger den cred till AMD som de ändå förtjänar. Det man kan notera är att modul-konceptet ändå ger klart mer effekt på den andra tråden jämfört med Intels HT, å andra sidan så kostar HT betydligt mycket mindre räknat i transistorer än den andra tråden i en modul.

Virtual Void #62

Det må vara korrekt.
Men om man istället kollar på 4 moduler /8 trådar stämmer ju Aleshis påstående.

Fråga:
Menar du att en Intel 32 core med HT inte skulle tappa effektivitet per kärna i motsvarande grad?
Är inte detta fenomen i själva verket beskrivet här:
http://en.wikipedia.org/wiki/Amdahl's_law

Gjorde precis ett tillägg just om AMD ovan. Är mycket medveten om vad Amdahl's lag säger och förstår man hur Erlang är implementerat så inser man också varför Ahmdahl's lag är ett mycket litet problem i de flesta Erlang-system. Erlang kör med modellen: processer delar inget och därför behövs inga lås som serialiserar saker. Naturligtvis kan Erlang-program som kör färre processen är det finns CPU-kärnor inte skala på något magiskt sätt, men det är inte fallet i de flesta av de benchmarks som listas på sidan.

Erlang kör idag på system med 100-tals CPU-kärnor och man siktar på att köra på system med tusentals och kanske även tiotusentals CPU-kärnor relativt snart. Ahmdal borde då inte ställa till med några större problem när man kör med 64 CPU-trådar.

Virtual Void #65
Ok. Då är vi överens.
Frågan kvarstår dock. AMD verkar gå all in på flertrådat + HSA.
Det känns som gambling. Och andra sidan, vad skulle man själv ha gjort när din konkurrent är 10 ggr större med lika mycket mer resurser?

Intel kör ett mer klassiskt upplägg med cpu/fpu + gpu inbed.
Jag vet inte, men nog känns det som att AMD är tvunget att lyckas få programutvecklarna att koda HSA för att dom ska lyckas med sin gambling, sett ett par år framåt dvs.

Nä är väl sant, slår man ut det på ett helt system i den klassen dessutom så är skillnaden i pris inte så jättestor.

Jag pratar mer om 4-8 trådar. Det högsta jag sett i något program är runt 7,5 gånger prestandan vid 8 trådar mot en. Men jag är fullt medveten om att det är ett undantag. Cinebench ligger väl runt 6 gånger prestandan vid flertrådat.

Finns även sådana fall där HT är extremt effektivt t.ex. detta program som använder en SSE optimerad mandelbrot: http://shootout.alioth.debian.org/u32/program.php?test=mandel...

På en Core i7 2600 körandes 64-bit Linux skapas en 16000x16000 pixels mandelbrot på 10.94s om man använder en CPU-kärna. Det tar 5.63s resp 6.09s med två fysiska kärnor resp två HT, d.v.s skalning på 1.94 med "riktigt" kärna och 1.80 med HT. Rent generellt har jag noterat att HT är mest effektiv just på saker där båda trådarna använder sig av flyttal. Att det inte skalar helt linjär på "riktiga" kärnor i detta fall beror nog mest på att det tar en del tid (relativt sett) att skriva ut 32MB (storleken på bilden) till disk, något som gör av en CPU-tråd.

Kör man med 4 fysiska kärnor (utan HT) och 4 kärnor med HT så tar det 2.96s (x3.7) resp 1.64s (x6.7).

Men i det allmänna fallet känns HT rätt meningslöst på desktop. Nackdelen är ju att om t.ex. min webbläsare kör på CPU tråd #0 och något får för sig att börja köra på CPU tråd #4 (samma fysiska kärna, men andra tråden) så blir ju webbläsaren långsammare. Kanske inte så stort problem just på en webbläsare, men tänk om man kör något som är relativt tungt och låg latens är viktigt. Detta har väl visat sig i vissa spel som kan bli något långsammare om HT är på, vet inte om samma sak kan hända med AMDs moduler men ser inte varför det inte skulle kunna ske.

Virtual Void #69

Visst sker detta även med Bulldozern, och dessutom i högre grad än med HT. Boten på detta enligt AMD:s sätt att se på det, är att istället öka frekvensen på de aktiva kärnorna och försätta de inaktiva kärnorna i vila.

Dessa test är ju gjorda i win 7 och inte Linux men värd att kika på:
http://www.xtremesystems.org/forums/showthread.php?275873-AMD....

Fast det där testet är ju näst intill syntetiskt. Inte direkt något användningsområde med det. Sådana saker kan man ju alltid komma nära teoretiska siffror med. Det är i ren praktik som skillnaden mellan modul-design och HT är stor. För att ta Cinebench exemplet igen så brukar HT ge runt 20% där. Och jag tror inte AMD förlorar något på sin moduldesign i spel, det verkar inte finnas några scenarion där det är positivt att stänga av så att det blir 4 klassiska kärnor.
http://www.xtremesystems.org/forums/showthread.php?275873-AMD...
Där är en intressant tråd med benches. Notera hur väldigt nära 2CU/4C kommer 4CU/4C på vissa tester. Och detta i lite mer realistiska sammanhang.

EDIT: Kul att Jacozz länkar till samma test medan jag skriver mitt inlägg.
EDIT 2: Fast vi kommer inte fram till samma slutsats. 4CU/8C är alltid snabbare än 4CU/4C. Så jag tycker inte det ser ut som att moduldesignen skulle innebära prestandanackdelar på samma sätt som HT kan göra.
EDIT 3: Tar tillbaka det sista, verkar som att det kan bli en liten prestandaförlust i spel. Men det är främst för att den väljer att klra två trådar på en modul istället för på var sin modul.
http://www.xtremesystems.org/forums/showthread.php?275873-AMD...

Hehe vi är ju simultana?
Jag tänkte just skriva:
Förutom i fåtrådade spel så har du rätt

Man är lite för snabb ibland.

Tror vi faktiskt är rätt överens här ändå. I normalfallet så ger HT en liten ökning på 20-30% på totala prestanda och moduldesignen ger 160-170% (AMD själva säger att den ger upp till 80% effektivitet, vilket ger .8*.8=164% på två kärnor). Finns även "riktiga" program där HT kan ge upp mot 60-70%, vissa typer av server-laster som begränsas helt och hållet av latens hamnar här. Även "riktiga" program som har en hög andel SSE instruktioner ger väldigt bra utdelning på HT, kanske inte lika mycket som mandelbrot programmet men det kan definitivt hamna runt 50%.

Men på desktop är ofta prestanda per tråd viktigare än total aggregerad prestanda och prestanda per tråd sjunker både med HT och med moduldesignen när båda trådarna används.

Om en tråd utför 100 arbete så utför två HT 120 arbete och två moduler 160 arbete. Men om nu det jag bryr mig mest om, min applikation i förgrunden, bara kör på en tråd så utförde den 100 arbete från början men bara 60 arbete om andra tråden används i HT fallet och 80 arbete i modulfallet. Vad jag menar är att vi är överens om att totala mängden utfört arbete ökar. Sen pekade jag på ovan att det existerar verkliga fall där användandet HT/moduler också kan leda till totalt sett försämrad prestanda, men det hör till undantagen.

Så även i det läget när HT/moduler ger positivt tillskott så kan upplevd prestanda för mig som användare av systemet minska. Men tanke på hur extremt få saker som kör på desktop som har nytta av mer än 4 CPU-trådar, så är vare sig HT eller "moduler" något jag skulle betala extra för på ett desktop-system. Om datorn råkar ha en CPU med den finessen så skulle jag nog lämna det på och hoppas att OS:et är tillräckligt intelligent att låta bli att använda den andra tråden så ofta det bara går, men för HT kan det finnas användarfall där det nog vore bäst att stänga av det.

Men det är det där med att den stora massan har mer nytta av starkare kärnor än flera. Hade prestandan skalat linjärt med kärnor i alla applikationer så hade det varit ett race efter kärnor nu som det en gång var med frekvens. Nu är det förunnat workstations och servermarknaden. Eftersom det inte behövs till konsumentmaskiner så är det något de kan ta betalt för till workstations. De vill ju ha något extra att erbjuda i en dyr workstation jämfört med en halvbillig spel-PC.

Ja det var ju enkelt. Har du räknat med yields här? Och hur det påverkar priset på 4-kärniga? De måste ju ha markant lägre pris på 4-kärniga. och eftersom de räcker mer än väl för det mesta så kommer resultatet vara att 90%+ fortsätter köpa samma processorer som innan, fast till lägre pris. Bra strategi tror du?

Kolla upp konceptet med binning så ser du snart varför det är 8-kärniga processorer med två kärnor låsta. Det handlar om att ta hand om defekta processorer. På samma sätt är alla i3, i5 och i7 egentligen en 3770K men olika stympade. De billigaste har fått offra kärnor och frekvenserna varierar. Detta för att kvalitén på varje enskild CPU varierar.

Sen är det fortfarande så att det är ytterst få som faktiskt har nytta av många kärnor och de få exempel som tas upp, ofta rendrering av olika slag, film som 3D, generellt skulle göras väldigt mycket snabbare på ett grafikkort. Så i takt med att GPGU blir vardagsmat minskar behovet av flerkärniga processorer ytterligare. Du kan ju till exempel ta och titta på hur stor skillnad det är att konvertera h.264 med CPU, GPU med CUDA, GPU med OpenGL och slutligen med Intels integrerade grafik. Intressant nog vinner Intels integrerade grafik stort över ett GTX 580 som i sin tur vinner stort över en processor. Så vad ska man då med massa extra kärnor till? Ber du snällt kan nog Virtual Void ge dig en liten föreläsning i hur svårt det är att faktiskt tråda upp mycket av det som en normal dator gör.

http://www.dustinhome.se/product/5010628495/intel-xeon-e5-262...
Varsågod, 6 kärnor för typ 3500 kr. Att jämföra med 3770K som kostar typ 3000 kr. Går att hitta serverbrädor som inte är alltför dyra heller för man betalar ju rätt mycket för licenspengar, design och pistolformade kylflänsar när man köper X79. Annars går det att bygga ihop 8 kärnor rätt billigt om man kör med dubbla 4-kärniga.

Så då är den stora frågan för mig, som pysslar med lite saker som faktiskt pressar en processor lite så som bildredigering, filmredigering och så vidare, när kommer vi få se mjukvaruimplimentationer av det här? Jag skulle behöva byta ut min dator då den är rätt ledsen men frågan är om jag ska stå ut till Haswell om det faktiskt innebär en stor förbättring. Eller är det som vilken annan processor nod som helst fram till om tre år när mjukvaran hunnit i kapp? För i så fall orkar jag inte vänta utan då får jag ta det vid nästa uppgradering.

Jag tänker att du har noll koll. Nehalem erbjöd ofta 40-50% högre prestanda. De fall där den erbjöd mindre prestandaökning var oftast begränsade av grafikkort eller rent syntetiska.
http://www.anandtech.com/show/2542/6

Angående Sandy Bridge så skulle jag säga runt 20%
http://www.bit-tech.net/hardware/cpus/2011/11/14/intel-sandy-...

Notera att en oklockad SB-E ofta är i samma klass som en 990X i 4.6GHz.

Sedan har vi IB:
http://www.bit-tech.net/hardware/2012/04/23/intel-core-i7-377...
Notera att de har både klockat och oklockat. På så vis kan man få en uppfattning av hur många Hz extra en SB behöver för att matcha en IB. Speltesten är extra intressanta där en 5GHz SB lyckas få stryk av en oklockad IB.

Läsförståelse? Jag vet att de är snabba, men de är snabba på många trådar. De är inte bra på den typ av prestanda som använd vid desktop. Apples övergång till x86 visade ju detta rätt tydligt.

Hade du läst så hade du sett att jag även pratade om totalprestanda. Men jag kan väl haka på kroken och prata lite IPC, även fast det är uppenbart att du kommer låtsas att jag bara pratar IPC. Men IPC ökningar per kärna är relevant, då frekvenser är väldigt svåra att öka över nuvarande nivåer utan att satsa på arkitekturer med låg IPC specialiserade på att bara skyffla data, och därmed inte särskillt bra på konsumentprestanda. Att offra IPC för frekvens brukar inte gå så bra för den fåtrådade prestandan. Men det tillåter enklare processorer med fler kärnor.

Du pratar flertrådad prestanda. Att få hög prestanda på 50 trådar är en sak, att få det på 4 är en helt annan sak, inget klår intel på den biten. Du gör förbannat irrelevanta och orättvisa jämförelser. Du ska inte passa på att visa att Intel är dåliga eftersom en vanlig GPU får högre GFLOPs också? Och nej, det tar inte hundratals cykler för intels HT att byta tråd. Det är rent hitte på från din sida och visar hur lite du egentligen vet.

Multitrådad prestanda ja. Hur lätt är det för dem att leverera fåtrådad prestanda?

Klart allt med modern chiptillverkning är avancerat. Men det är bra mycket enklare att slänga på massa kärnor än att utveckla starka arkitekturer som kan leverera bra prestanda per tråd.

Precis! Är det då rättvist att klaga på att intel inte kan öka konsumentprestandan mer än de gör då de med god marginal är världsledande? POWER användes rätt länge till Apples maskiner, men de var hopplöst efter.

Ja ett test där POWER 7 vinner, men det är ett flertrådat test med POWER 7 som klarar dubbelt så många trådar som Xeonen. Hur var det nu? Skyffla GFLOPS är GPUer också bra på. Är det rättvist att klaga på att CPU-utvecklingen går långsamt med den löjligt parallella GPU-prestandan?

Är du ett troll? Du anklagar mig för att hitta på när DU påstår att Nehalem, SB och IB bara gett runt 5% prestandavinst över tidigare generation? Varje tock Intel gör har gett i genomsnitt minst 20%, och i kombination med tick på 10% så ger det betydligt mycket mer än 20% vartannat år. För att jämföra lite Tocks, jämför C2Q med Pentium D, minst dubbla prestandan bara där. Titta på benchmarken jag gav innan med Nehalem över C2Q, och SB över Nehalem! Jag har betydligt mycket mer grund för min gissning än vad du har. Sedan är det bara att titta på presentationen av Intel. Det är rätt kraftiga förbättringar de stoppar in.

Nu ljuger du, du påstod att AMDs moduluppbyggnad var en avancerad variant av HT. Det är bara fel.

Men BD for stordäng även på bara en tråd, problemet är alltså inte skalningen per tråd, utan främst att de satsat på låg IPC och hög frekvens, utan att få upp frekvensen.

Verkligen? Du kan ju punktera något jag haft fel på då? Eller tänker du fortsätta flamsa runt och prata runt ämnet i ett försök att rädda dina dumma uttalanden?
Jag kan ju nämna några saker du har fel om så länge:
Prestandaökningar per Tock
Moduluppbyggnad = HT
Att parallella prestandavinster går att jämföra rakt av med prestandavinster per tråd
Att man kan jämföra prestandavinster per "tock" mellan företag som "tockar" olika ofta.
Att man kan glömma antalet kärnor när man räknar på Intels prestandavinster historiskt, men samtidigt bara räkna parallella ökningar hos andra.

Du kan ju låtsas att Intel gör 5% per tock. Men då vill jag att du förklarar hur Nehalem EX med 10 kärnor och minst 2-3 gånger så hög IPC bara är dryga 10% snabbare än Pentium D i din värld, skiljer bara två tock.

Både Linux har redan stöd för det TSX finess som kallas "HW lock elision" och Windows kommer med största sannolikhet också stödja detta redan innan Haswell släpps då det är något man kan lägga in i OS:et och sedan mer eller mindre automatiskt få stöd för det i applikationer. Rent teoretiskt skulle applikationer kunna börja lägga in stöd för detta redan nu då op-koderna som används för detta är bakåtkompatibla i den bemärkelsen att CPU:er innan Haswell kommer göra på "det gamla sättet" och ta låset på det dyra sättet.

På Linux borde i princip alla applikationer stödja detta omedelbart då källkoden finns tillgänglig till det mesta och man kan få in stöd för detta genom att kompilera om. Men om finessen visar sig ha stor effekt så lär de flesta prestandakritiska applikationer på Windows få patchar rätt snabbt.

"Restricted transactional memory" kommer ta lite mer tid innan vi ser stöd för. Dels är det inte bakåtkompatibelt med äldre CPUer, dels kräver det ändringar i konstruktionen av programmen.

Det här är humor på hög nivå, du anklagar mig och Aleshi för att bara prata om IPC och sedan säger du att Intel inte gör några framsteg och du drar den slutsatsen genom att ENDAST jämför IPC mellan versioner. Som jag skrev ovan, titta på Xeon som på 7 år gått från enkelkärnig CPU på ~2GHz (PentiumM Xeon och kallad "Core" arkitekturen, inte att förväxla med Core2, låg på runt 2GHz som mest) till 10-kärniga Sandy Bridge på upp till 3.8GHz. Och efter som du vill prata tyngre UNIX-servers (som jag tydligen har noll koll på) så har Intel på den tiden också gått från maximal 2 socket till 8 socket system. Det är alltså en förändringa, bara i kärnor per system, från 2 st till 80 st på 7 år. Ovanpå detta har även IPC ökat en hel del. Spöar Oracles x2 vartannat år rätt bra...

POWER7 är snabbast i världen på hyfsat mycket. Men kolla prislappen (en nolla till mot Xeon EX räcker inte) och kolla strömförbrukningen på 250W per CPU mot Xeon EX 130W. Ändå är POWER i genomsnitt bara runt 30% snabbare än den snabbaste Xeon EX CPUn.
SPARC, antar du refererar till T4, är bara snabbast på en väldigt specifik sak: laster där heltalsprestanda och flyttalsprestanda är helt irrelevant och där lasten består av extremt många oberoende samtida anrop där latens är av väldigt låg vikt. Detta är också det enda man har ett "världsrekord" i (ett TPC-C benchmark där dubbelt så många CPU:er krävdes jämfört med POWER för att slå "världsrekord"). Vem leder TPC-H och TPC-E, jo x86 system, vad kör Oracle på sina EXA-servers, jo x86.

Men du som vet så mycket om alla arkitekturer: hur vettigt var det nu att skapa en RISC där själva funktionen i en (32-bitars) instruktion är kodad bara med 5 bitar (vilket leder till att vektor instruktioner måste kodas med en prefix instruktion), hur vettigt är det att ha en arkitektur som saknar alla former av vettiga primitiver för atomära instruktioner, hur vettigt är det att ha 100-tals register som bara kan nås 32 åt gången och hur påverkar det kontext-switch latens att ha så många register. Vet du ens vilken arkitektur som har dessa egenskaper? Hint, det är inte POWER eller x86.

Hög IPC betyder att CPUs prestanda skalar väldigt kraftigt med klockfrekvens, så jo, hög IPC betyder snabb CPU. Däremot finns det vissa arbetslaster där en CPU kan vara väldigt ineffektiv och då få en låg IPC. Så hög IPC är alltid bra.

Min himmel, kan nog också hitta något som är 10 år gammalt som visar att SPARC och POWER suger. Testa att läs den studie du refererar så kaxigt till här, det var för Pentium4. Vad var problemet med Pentium4 nu igen? Usel IPC. Och varför får man usel IPC? T.ex. p.g.a cachemissar, hög latens mot RAM och alldeles för hög klockfrekvens i förhållande till hur mycket instruktioner som resten av systemet kan mata exikveringsenheterna med.

Sedan kan du läsa optimeringsguiden för t.ex. Sandy Bridge. Intel anser att du definitivt har ett allvarligt design-fel i din programvara om du har mer än 10% stalls i den CPUn. Jag måste göra något fel på jobbet, när jag läser av "performance counters" (räknare på cache miss/träff, branch predict träff/miss, TLB träff/miss, de flesta moderna CPU:er har dessa räknare) så ligger den komponent jag jobbar på ofta väsentligt under 5% cache miss, inte alls ovanligt att det är under 1% (träff i NÅGON cache, dock vill man helst ha L1 träffar då den cachen är MYCKET snabbare än alla andra).

Lyssnade rätt nyligen på en presentation om SPARC T5 som hölls av en arkitekt bakom denna CPU. Han fick frågan: om du kunde stoppa dubbelt så många transistorer i denna design, vad skulle du då använda dessa till. Vad tror du svaret var? Jo: mer L3 cache för det är något vi just nu ligger efter IBM och Intel på.

Det är naturligtvis inte lätt att skapa en CPU med massor med CPU-kärnor, men det finns INGET som är så utmanande som att skapa en CPU-kärna med hög IPC då det är ett problem som kräver att du hittar parallellism i en seriel instruktionsström som måste köras på ett sådant sätt så att saker som beror av varandra faktisk får resultaten vid rätt tillfälle och framförallt så måste den synliga resultatet hamna i rätt ordning efter man är klar. Det är något SPARC inte är i närhet av vare sig POWER eller x86, SPARC T1-T3 har mer gemensamt med Atom och ARM Cortex A8 vad det gäller uppbyggnaden av CPU-kärnan, d.v.s in-order dual-issue. SPARC T4-T5 har spottat upp sig lite och tagit sig upp på PentiumPro nivå och ARM Cortex A9 med out-of-order dual-issue.

POWER7 är out-of-order 6-issue och Sandy Bridge är out-of-order 4/5-issue.

Nä det är sant, vilket var en annan sak som Niagara arkitekten nämnde: han tvivlade på att det är vettigt att stoppa in mer än dagens 16 CPU-kärnor i en och samma CPU för det finns helt enkelt inget RAM och ingen RAM-bus design i världen som kan förse specielt mycket fler CPU-kärnor med vettigt jobb. Intel har sagt samma sak, att mata 10 Sandy Bridge kärnor (som var och en är starkare än de 16 T5 kärnorna) är i vissa fall omöjligt, så det är bara vissa typer av arbetslaster som blir vettigt att köra.

Jo, men du är det så att för de flesta normala personer så är det rätt mycket smidigare att åka bil än att åka bus. Så för konsumenter så är x86 totalt överlägsen SPARC, vilket jag inte tror någon säger emot.

Tja, jag har läst på t.ex. här www.agner.org/optimize/microarchitecture.pdf där någon faktiskt testat vilka beteenden och flaskhalsar Intels och AMDs CPUer har. Och flaskhalsen i Bulldozer? För lite L1 cache och framförallt så är avkodaren (max 4 instruktioner till EN av modulerna per klockcykel) en extrem flaskhals. Jämför det med Sandy Bridge som kan avkoda 4 (i speciella fall 5) instruktioner och det kan vara en mix till båda trådarna.

Och har aldrig sagt något annat än att HT delar en CPU och jag skrev ovan att en modul har mycket högre effektivitet jämfört med HT. Men det är ju självklart! HT tar runt 5% extra transistorer att implementera, har för mig att en modul tar runt 40% extra transistorer. Sett ur det perspektivet så är ju HT överlägset i effekt per adderad transistor.

Problemet med Bulldozer är att även den delar vissa saker och flaskhalsarna ligger just i dessa delade saker vilket definitivt drar ner effektiviteten och inte gör en modul direkt jämförbar med en "riktigt" dual-core design.

Gissar att den genomsnittliga kunskapen om dessa är VÄLDIGT låg på swec kring high-end UNIX server CPUer, så är lite stolt av att vara den MEST okunnig på detta

Tror att hans kommentarer om okunnighet var riktad till mig. Men visst, jag kan väldigt mycket mindre än t.ex. du. Men jämfört med herr Saddam så känner man sig väldigt påläst.

Så svaret är troligtvis, kanske delvis?

Får nog bli en Ivy inom en snar framtid då för vet inte om jag vill vänta till 2012. Det var väl laptop CPU som skulle komma först eller? Känns som om man kommer få vänta till sommaren och det är lite för lång tid för min smak. Får dra nytta av det sen när Skylake kommer.

Edit: jag kör för övrigt uteslutande Windows.

Alltså, det är så mycket svammel. Jag får bemöta detta imorrn då jag har ont om tid idag.
Kortfattat så är det äpplen och päron kombinerat med okunskap från din sida. Man kan inte öka prestandan på få trådar så som intel gör lika enkelt som man ökar på många trådar som Oracle och Sun gör. Och det är en sak att bara tugga stora flöden med nummer och en annan sak att hantera program. Samtidigt så är generationsskiftena stora för intel. IB är inte en ny generation, bara en krympning, men gav likväl 10% IPC! Sedan P4 har råprestanda ökat med till det tredubbla, och detta per kärna! Lägg till att mängden kärnor ökat en hel del sedan P4. Du har inget fog för att klaga på intels prestandaökningar och dina jämförelser med Oracle och Sun är precis lika orättvisa som att jämföra med GPU. Men den liknelsen förstod du aldrig i förra inlägget. Virtual Void kanske har mer tid att svara, annars ses vi imorrn!