Intel i5 eller Phenom II X4 965

Vad menar du med "utöver" själva trådbytet? Processorn/kärnan i sig har egentligen ingen aning om vad en tråd ens är. Tiden det tar för ett trådbyte är per vanlig definition tiden mellan att en tråd pausas och att nästa tråd körs.

Ja, den tiden varierar mellan operativsystem till operativsystem, men är ändå i samma storleksordning som den på pappret jag presenterade (vilket var för en Linux 2.6.17 kärna). Faktum är att jag nu märkte att jag gjorde ett litet räknefel och att de snarare hittade en genomsnittstid på runt 7500 cykler (tyckte att den förra tiden var aningen i underkant när man jämförde med mutex-tiden).

ps. Och jag tror nog att vi ska hålla oss till alla mainstream operativsystem här. D.v.s. Windows, Linux och de kända BSD versionerna. Om du är intresserad av exakt vilka komponenter som är involverade i varje operativsystem så är du mer än välkommen att läsa den fria källkoden för de två sistnämnda, eller att söka på internet efter mer information om den förstnämnda.

Alright, men var ligger logiken för att påbörja trådbytet? Processorn vet inte själv att "aha! nu är det dags att spara ner registren"! Hur ska nästa tråd väljas?

Allt försvåras ytterliggare om nästa tråd inte ligger i samma process som den första. Har de olika privilegium? Olika minnes-mappningar?

Linux's schemaläggare och FreeBSD's ULE betraktas i allmänhet som bland de snabbaste pre-emptiva schemaläggare när det gäller byte från en tråd till en annan (på x86 arkitekturen).

Jag måste tyvärr upprepa att jag känner att du inte riktigt ha någon koll alls på dessa delar och att siffrorna du ger ut är rena guesstimates.

Ja, även om skillnaden inte alltid är tydlig på alla system.

Kan du själv t.ex. karaktärisera vad "processer" har som inte "trådar" har och i förbifarten nämna några grundläggande punkter som en "tråd" har?

En kärna byter inte från en tråd till en annan. Kärnan vet inte om vad trådar är för något. Kärnan räknar mer eller mindre endast på. Vilka "nästa" instruktioner är beror på vilka de "tidigare" instruktionerna är.

För att då ställa den lätta frågan, hur kan kärnan veta att den ska köra instruktionerna för...

* Spara ner alla register vilket innebär att även stackpekare, instruktionspekare mm sparas.
* Ladda register, stackpekare, instruktionspekare mm från annat ställe

... när den förra instruktionen är "multiplicera register EBX och ECX och spara i register ECX"?

Heh... right... Jag antar att du själv inte är en programmerare?

Trådbyte är en av de mest tidskrävande och komplicerade operationerna i ett modernt operativsystem.

Cooperative multitrådning (d.v.s. att programmen själva bestämmer när de ska släppa CPU-n) är något som inte längre används för mainstream x86-opreativsystem efter Windows 3.x tiden (nåja, Windows 9x/ME hade vissa undantag).

Det är en smak sak också... Jag är super nöjd med min amd pII 940 och vill inte gå över till Intel.. Amd har alltid funkat ypperligt till allt, och ibland kanske han inte packar upp en rarfil lika snabbt som en i7. Men där emot har jag inte direkt brottom så jag är ute efter att tjäna nån sekund här och där..

Och framför allt i spel så går pII 940 lika bra som i7...

Fanboys är alltid lika underhållande att lyssna på...

i7 = Jävligt dyr miniräknare
pII 940 = billig miniräknare

skulle vara roligt att se hur mycket snabbarew core i7 och core i5 är klock per klock än core 2.

Alltså hur mycket snabbare dom nya cpu'erna är vid samma mhz!

Jag skulle nog tippa på att jag har långt mer kunskaper än dig i detta område då det är något jag mer eller mindre dagligen kommer i kontakt med.

Dock så var min formulering av frågan lite för "lös" då med rätt abstraktion (läs: på låg nivå) så kan mer eller mindre allt betraktas som "en minnesarea" (även trådarna).

En process anses i vanliga fall vara något mycket mera abstrakt och "äger" ett antal "minnesareor" (och äkerhetestokens, "handles", trådar, m.m.) men är själv i den vanliga bemärkelsen inte det. En tråd innehåller också inte enbart en stack-pekare, ett par små utrymmen för registren (och eventuella flaggor), ett par små extra variabler som används av systemet utan även sin egen lilla privata "minnesarea" (TLS som är vitalt för att t.ex. skapa en multitrådssäker itoa).

För övrigt är det rätt komiskt att du ignonerar (heh, selektiv citation) kärnfrågorna:

- Något som helst uppbackande med fakta på att tråd-byten endast tar runt 50 cykler i ett modernt mainstream operativsystem på x86 (eftersom det påståendet rent av är falskt). Inga "hemmabyggda" definitioner på tråd-byte tack.

- Uppbackande med fakta att det finns någon form av A.I. på kärnorna som vet om när de ska "veta vart de ska hoppa näst i data-flödet, dumpa registren, ladda de nya registren och fortsätta" (eftersom det inte finns).

- (sist men inte minst) Uppbackande om varför Phenom IIs cachar skulle vara uppbyggt bättre än i7-ornas. Högre vägars associativ cache minskar risken för cache-missar men ökar istället latencyn och i Phenom IIs fall är det nödvändigt p.g.a. avsaknaden av inklusiva cachar (vilket i sig inte nödvändigtvis är "dåligt" eller "bra" utan endast "offrar latencyn för större användbar cache" - d.v.s. annan design idé)). Att slänga på "extra associativitet (skapade just det ordet?)" måste dessutom vägas mot huvudmålet med CPU cacharna: att sänka minneslatencyn.

Det går inte att ge några generella siffror där. I vissa fall (t.ex. vissa spel på mycket höga upplösningar/inställningar) är det mer eller mindre "inget alls" medan i andra fall är det "jättemycket". I extrema fall kan till och med en Core 2 vinna över en Core i7.

Men i genomsnitt så visar de flesta recensioner på en 13-17% prestandavinst clock-för-clock för en Core i7 jämfört med en Core 2 när HyperThreading inte är involverad. När HT är på och många trådar finns så brukar man kunna räkna med en runt 50% vinst.

Eller så är det just för att diskussionen har rört sig in i områden som få vettiga personer någonsin ens har sett en skymt av.

Och själva bytet i sig är dyrt. Intelligensen runt omkring kostar självklart cykler också men det absolut minsta som krävs för ett trådbyte, d.v.s. "interrupt + hopp till kernel-läge + (mappa om minne) + spara register + ladda register + hopp tillbaka till user-läge" är relativt dyrt.

För att mäta tiden det tar för ett trådbyte finns det två vanliga metoder (som inte involverar ändringar i kernel koden):

1. Ha en loop som hela tiden läser av en hög-precisions klocka (RDTSC t.ex.) i båda trådarna. Efter ett antal sekunder (och många trådbyten), dumpa tiderna till disk och jämför/räkna.

2. Ha en loop som hela tiden självmant avslutar sin egen tidskvanta och räknar hur många gånger per sekund som trådbytet skedde. Tiden då en tråd verkligen "körs" är då minimal. Resten är tiden för trådbytena. (metoden de använde sig av)

Ja, och Linux 2.6.x har historiskt sett alltid varit en av de snabbaste när det gäller trådbyten på x86 (eller rättare sagt O(1) schemläggaren - dock så har den vissa andra väldokumenterade problem).

Faktiskt är svaret "ingen". Den körs snarare "mellan" två trådar (d.v.s. extra overheaden för trådbyte).

Därav orsaken att schemläggarens "intelligens" oftast är minimal. Något i stil med "stoppa tillbaka den förra tråden längst bak i kön med dess prioritet och plocka fram tråden som befinner sig längst fram i kön med högst prioritet".

Du har nog rätt i att det skulle vara mycket tveksamt för mig att lyssna på din fakta om den inte är uppbackad av någon neutral tredje-part eftersom jag inte tycker att du är tillräckligt kunnig inom just detta ämne för att lära ut (inget illa menat, jag själv kan endast tillräckligt för att inse vad som är felaktigt och inte tillräckligt för att lära någon annan).

Den biten är nödvändig men inte tillräcklig för själva bytet då det måste finnas någonting som triggar själva anropet av den (eller egentligen funktioner längre upp, men för enkelhetens skull kan man anta optimala förhållanden med båda trådarna i samma process, utan behov av om-mappningar av minne eller annat).

Minimalt så finns det ett interrupt, ett hopp till kernel-läge och ett hopp till user-läge som inte nödvändigtvis syns i själva koden just där (interruptet och hoppet in och ut är någonting som är oerhört dyrt, se t.ex. bara på hur lång tid ett anrop till något trivialt som getpid() tar). Men om vi bortser från de delarna som tar många hundra cykler och endast betraktar switch_to: har du sett vad __switch_to som anropas gör?

Speciellt flyttals-registren tar lång tid (relativt sett) att dumpa. Lite google sa åt en att man kan förvänta sig 250 - 350 cykler för endast switch_to.

Jag förväntade mig att någon skulle säga det. Tänkte skriva det själv tidigare men kom aldrig på den exakta frasen...

Det finns en viss skillnad med att diskutera någonting som i grund och botten är baserad på spekulationer eller eget tycke (AMD vs Intel, SSD vs HDD, etc) och en diskussion om någonting är rätt eller fel enligt både teoretiska värden och empiriska sådana.

Om "uppgraderingsbarhet" för processorn är det man är ute efter så tycker jag att man bör gå med AMD. AM3 är en relativt ny plattform och AMD har (de senaste åren) haft en lång historia av att man har kunnat stoppa in en ny processor även i dem äldre moderkorten.

Moderkorten med Intels kommande P55 (hm... finns det ens planer på X55?) chipset bör kunna hänga med fram tills nästa "tock" (Sandy Bridge) vilket gör en plattform för i5/Lynnfield (eller i7/Bloomfield för den delen) uppgraderingsbar i ungefär 2 år.

MEN... det finns som sagt inga riktiga garantier på att Bulldozer skulle fungera på AM3, utan all "info" är endast mer eller mindre baserat på "past experience".

Så, vad skall man välja då? Jag undrar nämligen själv

En anledning kan ju vara att man behöver en dator till studiestarten mitten av augusti. Är september fortfarande senaste om release-datum? Vill ha en i5 men vettefan hur en månad på universitet kommer gå utan en dator. Kanske blir en Eeeeeeeepc så man klarar första tiden?

Nu är det förvisso oklart vad du skall läsa, men att vara utan dator behöver inte alls vara så farligt. Tvärt om får man väldigt mycket mer tid över som man till exempel kan använda för att läsa sina böcker. När man väl behöver programmera, skriva eller liknande finns det också datorer på universitetet.

Civilingengör medieteknik...