---

hvad fordele er der ved dual fremfor en hurtigere cpu alene ?
f.eks. 2* socket 370 PentiumIII 800Mhz vs. 1*1,6Ghz Pentium4 socket 478...
hvad er bedst/hurtigst?
og til hvilken opgaver er hvilken bedst?

---

On Wed, 19 Dec 2001 21:07:15 +0100, Scar wrote:

>hvad fordele er der ved dual fremfor en hurtigere cpu alene ?
>f.eks. 2* socket 370 PentiumIII 800Mhz vs. 1*1,6Ghz Pentium4 socket 478....
>hvad er bedst/hurtigst?
>og til hvilken opgaver er hvilken bedst?

Fordi du har to processorer istedetfor en, har noget mere kraft
at rutte med....hvor meget afhænger af styresystemet, da det er
dette der skal administrere processer, tråde, allokering og alt
det der. Det betyder så ikke at maskinen bliver dobbelt så
hurtig, den bliver lidt hurtigere - til gengæld kan du have
flere processer kørende end på en uniprocessor maskine.

Er styresystemet ordentligt forberedt for SMP startes
program-trådene på den processor der nu trækker det mindste læs
- ellers er det nødvendigt med programmer der understøtter SMP,
da programmerne ellers bliver plantet et sted og alle nye tråde
bliver startet op her istedetfor på naboprocessoren der står
helt uopdækket.

SMP er godt til beregningstunge opgaver, fx rendering,
animationer og sådan noget stads!

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
Fact: fourteen out of every ten people like chocolate.

---

Peter Jespersen says in dk.edb.hardware:
> [...] Det betyder så ikke at maskinen bliver dobbelt så
> hurtig, den bliver lidt hurtigere - til gengæld kan du have
> flere processer kørende end på en uniprocessor maskine.

Med moderne hardware og som almindelig dødelig bruger ramler man
nu næppe ind i noget loft mht. antallet af processer. Hvis
valget står mellem 2 stk x MHz processorer eller et stk 2*x MHz
processor vil de fleste nok enkeltprocessorløsningen: Det giver
mere i spil (minus Quake 3, der understøtter multiprocessor) og
i de fleste andre programmer.

Det eneste sted hvor multiprocessor rigtig giver noget (igen
under antagelse af 2 stk x MHz vs et stk 2*x MHz) er mht.
responstid overfor brugeren: Selvom maskinen arbejder for fuld
tryk på den ene processor kan den anden fint tage sig af
opdatering af vinduer og håndtering af museklik o.l.

> SMP er godt til beregningstunge opgaver, fx rendering,
> animationer og sådan noget stads!

Ja, under antagelse af at samlet MHz for de to processorer
overstiger MHz for den enkelte processor de holdes op imod.
--
Toke Eskildsen <URL:http://www.daimi.au.dk/~darkwing/>

---

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev:

> Det eneste sted hvor multiprocessor rigtig giver noget (igen
> under antagelse af 2 stk x MHz vs et stk 2*x MHz) er mht.
> responstid overfor brugeren: Selvom maskinen arbejder for fuld
> tryk på den ene processor kan den anden fint tage sig af
> opdatering af vinduer og håndtering af museklik o.l.

Det er også klart her jeg kan mærke fordelen ved 2 CPU'er.
Det er næsten umuligt at tvinge systemet i knæ.

> > SMP er godt til beregningstunge opgaver, fx rendering,
> > animationer og sådan noget stads!

I det hele taget til grafiske opgaver er det suverænt.
Jeg arbejder meget med dtp og her er jeg virkelig glad for at
jeg valgte et dualsystem. Photoshop f.eks. understøtter flere
processorer, men det skal styresystemet jo så selvfølgelig
også gøre. Det er ikke meget ved at køre Win9x. :)

--
Med venlig hilsen
Madsen.

---

NEMLIG! Svartid er nøgleordet i dual-processor-systemer. Jeg havde en Celly
600@1008 og en dual Celly 366@550. Til spil og den slags brugte jeg
single-maskinen, men til workstation er dual bare sagen - med masser af ram.
Det bliver et rigtig "transparent" system at arbejde med... Thumbs up til
Abit BP6!

/Henrik!

"Toke Eskildsen" <darkwing@daimi.au.dk> skrev i en meddelelse
news:MPG.168b19cc600d0bad9896bd@news.skjoldhoej.dk...
> Peter Jespersen says in dk.edb.hardware:
> > [...] Det betyder så ikke at maskinen bliver dobbelt så
> > hurtig, den bliver lidt hurtigere - til gengæld kan du have
> > flere processer kørende end på en uniprocessor maskine.
>
> Med moderne hardware og som almindelig dødelig bruger ramler man
> nu næppe ind i noget loft mht. antallet af processer. Hvis
> valget står mellem 2 stk x MHz processorer eller et stk 2*x MHz
> processor vil de fleste nok enkeltprocessorløsningen: Det giver
> mere i spil (minus Quake 3, der understøtter multiprocessor) og
> i de fleste andre programmer.
>
> Det eneste sted hvor multiprocessor rigtig giver noget (igen
> under antagelse af 2 stk x MHz vs et stk 2*x MHz) er mht.
> responstid overfor brugeren: Selvom maskinen arbejder for fuld
> tryk på den ene processor kan den anden fint tage sig af
> opdatering af vinduer og håndtering af museklik o.l.
>
> > SMP er godt til beregningstunge opgaver, fx rendering,
> > animationer og sådan noget stads!
>
> Ja, under antagelse af at samlet MHz for de to processorer
> overstiger MHz for den enkelte processor de holdes op imod.
> --
> Toke Eskildsen <URL:http://www.daimi.au.dk/~darkwing/>

---

mange tak for dine svar peter =)
"Scar" <jantran81@mail.dk> wrote in message
news:3c20f38b$0$35631$edfadb0f@dspool01.news.tele.dk...
> hvad fordele er der ved dual fremfor en hurtigere cpu alene ?
> f.eks. 2* socket 370 PentiumIII 800Mhz vs. 1*1,6Ghz Pentium4 socket 478...
> hvad er bedst/hurtigst?
> og til hvilken opgaver er hvilken bedst?
>
>
>
>

---

"Scar" <jantran81@mail.dk> writes:

> hvad fordele er der ved dual fremfor en hurtigere cpu alene ?

At man får dobbelt så meget regnekraft.

Jeg nyder fx meget at jeg kan starte programmer, oversætte en ny kerne
og en masse andet uden at maskinen bliver sløv at arbejde med (OK,
afhængig af hvor offensiv jeg er med make og "-j"-flaget :).

> f.eks. 2* socket 370 PentiumIII 800Mhz vs. 1*1,6Ghz Pentium4 socket 478...
> hvad er bedst/hurtigst?

Hvis vi lige ser bort fra at CPU'erne er af forskellige generationer
og sådan noget, og så bare siger at vi har 2 * CPU X på 1 MHz og en
CPU X på 2 MHz.

Så vil jeg nok foretrække en 2 MHz CPU frem for to 1 MHz CPU'er da de
færreste programmer alligevel kan udnytte SMP effektivt, og selv om de
kan vil der stadig være problemer med mange ting i OS'et er ligger
neden under.

Det kan blandt andet være at holde styr på hvad der sker når en af CPU
cacher et eller andet uden at skrive det tilbage til hukommelsen. Så
kan du selv forestille dig hvordan det kan gå galt når den anden CPU
prøver at læse det hukommelse.

I Linux 2.2 kørte kernen således kun på en CPU (så at sige). I Linux
2.4 er det lidt smartere, men der er stadig nogle ting, som gør at en
CPU er er at foretrække.

Men dit spørgsmål er måske nok lidt forkert, for ofte står valget jo
ikke mellem 2 * 1 MHz eller 1 * 2 MHz, men mellem 1 * 2 MHz eller 2 *
2 MHz.

> og til hvilken opgaver er hvilken bedst?

Hvis du spiller, så vil du oftest ingen glæde have af at have mere end
en CPU. Hvis du oversætter store programmer, laver 3D grafik (i et
program der har understøttelse for den slags), deler din computer med
mange andre, så der kører mange programmer, så vil du ofte have glæde
af flere CPU'er.

Her er fx toppen af hvad 'top' spytter ud på en maskine med 24 CPU'er
jeg har adgang til hvor jeg læser:

load averages: 8.24, 7.85, 7.74 21:57:34
445 processes: 426 sleeping, 7 zombie, 2 stopped, 10 on cpu
CPU states: 64.8% idle, 33.0% user, 2.2% kernel, 0.0% iowait, 0.0% swap
Memory: 24G real, 19G free, 3511M swap in use, 44G swap free

Nu er den ikke så travl, men ofte har alle CPU'er noget at lave. Så
vidt jeg husker er det 400 MHz (UltraSPARC) CPU'er der sidder i den,
den ville nok næppe virke ret godt med en enkelt CPU

--
Jacob (som kun har dual-maskiner ;) - www.bunk.cc
Laugh when you can; cry when you must.

---

In article <3c20f38b$0$35631$edfadb0f@dspool01.news.tele.dk>, jantran81@mail.dk
says...
> hvad fordele er der ved dual fremfor en hurtigere cpu alene ?
> f.eks. 2* socket 370 PentiumIII 800Mhz vs. 1*1,6Ghz Pentium4 socket 478...
> hvad er bedst/hurtigst?

Man kan desværre ikke sige at 2x500MHz == 1x1000MHz. Hovedreglen siger at man
kun udnytter 70% af den samlede regnekraft. Du må ikke hænge mig op på det
præcise tal, men noget i den retning.

Til almindelige mennesker vil det være bedre at have al regnekraften samlet i
en enkelt CPU. Den ekstra pris kan ikke rigtigt retfærdiggøres.

> og til hvilken opgaver er hvilken bedst?

Det er bedst til store tunge regneopgaver eller servere.

--
/Søren

Husk, Google er din ven :)

---

Søren 'Mufoxe' Lund Jensen <mufoxe@hotmail.com> writes:

> [ ... ] Hovedreglen siger at man kun udnytter 70% af den samlede
> regnekraft. Du må ikke hænge mig op på det præcise tal, men noget i
> den retning.

Øhhh, hvilken hovedregel?

Hvad mener du i det hele taget?

- At man generelt kun bruger 70% af al den CPU-tid ens computer har? I
så fald tror jeg tallet er markant lavere, sikkert under 10%
(forudsat at man ikke kører dnetc eller andre lignende ting).

- At man kun får 70% ekstra ydelse ved at sætte en CPU mere i en
maskine, som allerede har en CPU? I så fald er det godt nok et
generalisering af format du her kommer med.

Jeg har en fornemmelse af at det er nr. to du mener. I så fald kan du
måske også fortælle hvordan man måler den slags? Det kommer jo helt an
på hvilke(t) program(mer) man tester med.

Min dual-maskine svarer meget hurtigere når jeg laver tunge ting på
den, og så kører min dnetc også dobbelt så hurtigt - det må da kaldes
dobbelt ydelse, ikke ?-)

> Til almindelige mennesker vil det være bedre at have al regnekraften samlet i
> en enkelt CPU. Den ekstra pris kan ikke rigtigt retfærdiggøres.

Det kommer vel an på hvad disse "almindelige mennesker" bruger deres
computer til, men generelt tror jeg du har ret.

--
Jacob - www.bunk.cc
Is knowledge knowable? If not, how do we know that?

---

On 21 Dec 2001 01:12:49 +0100, Jacob Bunk Nielsen wrote:

<snip>

>Jeg har en fornemmelse af at det er nr. to du mener. I så fald kan du
>måske også fortælle hvordan man måler den slags? Det kommer jo helt an
>på hvilke(t) program(mer) man tester med.

Når det kommer til stykket kommer det an på styresystemet og
hvor godt SMP håndteringen er implementeret i dette.

>Min dual-maskine svarer meget hurtigere når jeg laver tunge ting på
>den, og så kører min dnetc også dobbelt så hurtigt - det må da kaldes
>dobbelt ydelse, ikke ?-)
>
>> Til almindelige mennesker vil det være bedre at have al regnekraften samlet i
>> en enkelt CPU. Den ekstra pris kan ikke rigtigt retfærdiggøres.
>
>Det kommer vel an på hvad disse "almindelige mennesker" bruger deres
>computer til, men generelt tror jeg du har ret.



Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
Any given program, when running correctly, is obsolete.

---

"Peter Jespersen" <flywheel@illogical.dk> writes:

> Når det kommer til stykket kommer det an på styresystemet og
> hvor godt SMP håndteringen er implementeret i dette.

Blandt andet, men ikke kun.

Linux er et glimrende eksempel på hvordan SMP-understøttelsen er
blevet meget forbedret for hver ny generation. I 2.0 var den elendig,
i 2.2 var den OK uden at være god, og i 2.4 er den ganske god.

Men visse programmer der kører i userspace uden kald til kernen har
faktisk kunnet opnå dobbelt ydelse selv under de ringeste
SMP-understøttelser i kernen.

Tag nu fx min dnetc - der får du stadig dobbelt så meget fart på en
dual-maskine selv om du kører Linux 2.0, hvor understøttelsen for SMP
var meget middelmådig. Så vidt jeg husker er det noget med at alle
kerne-processer kun kører på den ene CPU, hvilket selvfølgelig er
kæmpe nedtur i et system med mange CPU'er.

--
Jacob - www.bunk.cc
Overdrawn? But I still have checks left!

---

On 21 Dec 2001 11:10:00 +0100, Jacob Bunk Nielsen wrote:

>"Peter Jespersen" <flywheel@illogical.dk> writes:

<snip>

>Linux er et glimrende eksempel på hvordan SMP-understøttelsen er
>blevet meget forbedret for hver ny generation. I 2.0 var den elendig,
>i 2.2 var den OK uden at være god, og i 2.4 er den ganske god.
>
>Men visse programmer der kører i userspace uden kald til kernen har
>faktisk kunnet opnå dobbelt ydelse selv under de ringeste
>SMP-understøttelser i kernen.

Men du kan vel ikke komme udenom schedular'en, deployment og adm
af tråde og timeslices er vel stadig en ring0 opgave.
Hvis kernen har problemer med håndtering/administration af tråde
til flere processorer, vil det vel stadig trække ned.

>Tag nu fx min dnetc - der får du stadig dobbelt så meget fart på en
>dual-maskine selv om du kører Linux 2.0, hvor understøttelsen for SMP
>var meget middelmådig. Så vidt jeg husker er det noget med at alle
>kerne-processer kun kører på den ene CPU, hvilket selvfølgelig er
>kæmpe nedtur i et system med mange CPU'er.

De fleste SMP implementationer er en blanding af synkon og
asynkron SMP, dvs at styresystemet gerne holder sig til den ene
(oftest den første) processor. WinXP er lidt en klampet
undtagelse, da GUI'en er så tung at man har set sig nødsaget til
at lade denne køre på en anden processor.

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
Microsoft Education, the first step to "Planet of the Apes."

---

"Peter Jespersen" <flywheel@illogical.dk> writes:

> >Men visse programmer der kører i userspace uden kald til kernen har
> >faktisk kunnet opnå dobbelt ydelse selv under de ringeste
> >SMP-understøttelser i kernen.
>
> Men du kan vel ikke komme udenom schedular'en, deployment og adm
> af tråde og timeslices er vel stadig en ring0 opgave.

Ja, og det kører i Linux 2.0 på den ene af CPU'erne, det optager i
praksis bare så lidt CPU-tid i forhold til de userspace-programmer man
kører at det ikke reelt giver problemer.

> Hvis kernen har problemer med håndtering/administration af tråde
> til flere processorer, vil det vel stadig trække ned.

Ja, men det er der vel heller ikke nogen der snakkede om. Vi snakker
blot om at denne administration kun varetages af den ene af de to
(eller flere) CPU'er. Såfremt den kan følge med er der jo ikke nogen
problemer. Det kan man dog godt forestille sig er en noget anden sag,
hvis vi snakker om systemer med mange CPU'er.

> De fleste SMP implementationer er en blanding af synkon og
> asynkron SMP, dvs at styresystemet gerne holder sig til den ene
> (oftest den første) processor.

Ja, det er blandet andet det der skete i Linux 2.0. I 2.4 er det vist
lidt anderledes, men jeg skal ærligt indrømme at jeg ikke har læst op
på det for nyligt.

> WinXP er lidt en klampet undtagelse, da GUI'en er så tung at man har
> set sig nødsaget til at lade denne køre på en anden processor.

GUI'en er vel næppe en del af kernen? I så fald er der da noget helt
galt med designet af Windows!
At man vælger at fordele de forskellige processer på de CPU'er der nu
er til rådighed virker da på mig som et fornuftigt design. Det ville
da være direkte dumt ikke at udnytte den regnekraft der er tilstede.

--
Jacob - www.bunk.cc
You may be recognized soon. Hide.

---

On 21 Dec 2001 13:32:38 +0100, Jacob Bunk Nielsen wrote:

>"Peter Jespersen" <flywheel@illogical.dk> writes:
>
>> >Men visse programmer der kører i userspace uden kald til kernen har
>> >faktisk kunnet opnå dobbelt ydelse selv under de ringeste
>> >SMP-understøttelser i kernen.
>>
>> Men du kan vel ikke komme udenom schedular'en, deployment og adm
>> af tråde og timeslices er vel stadig en ring0 opgave.
>
>Ja, og det kører i Linux 2.0 på den ene af CPU'erne, det optager i
>praksis bare så lidt CPU-tid i forhold til de userspace-programmer man
>kører at det ikke reelt giver problemer.
>
>> Hvis kernen har problemer med håndtering/administration af tråde
>> til flere processorer, vil det vel stadig trække ned.
>
>Ja, men det er der vel heller ikke nogen der snakkede om. Vi snakker
>blot om at denne administration kun varetages af den ene af de to
>(eller flere) CPU'er. Såfremt den kan følge med er der jo ikke nogen
>problemer. Det kan man dog godt forestille sig er en noget anden sag,
>hvis vi snakker om systemer med mange CPU'er.

Vel, nogle styresystemer trækker 10-20% fra, blandt andet på
denne regning!
Styresystemer som Linux, *BSD, OS/2 og BeOS derimod er noget
mere beskedne!

>> De fleste SMP implementationer er en blanding af synkon og
>> asynkron SMP, dvs at styresystemet gerne holder sig til den ene
>> (oftest den første) processor.
>
>Ja, det er blandet andet det der skete i Linux 2.0. I 2.4 er det vist
>lidt anderledes, men jeg skal ærligt indrømme at jeg ikke har læst op
>på det for nyligt.
>
>> WinXP er lidt en klampet undtagelse, da GUI'en er så tung at man har
>> set sig nødsaget til at lade denne køre på en anden processor.
>
>GUI'en er vel næppe en del af kernen? I så fald er der da noget helt
>galt med designet af Windows!

Godt nok er det eneste de endnu ikke har proppet ind i ring0
endnu da lige netop køkkenvasken.
Men det er endnu ikke en del af kernen, men man plejer ikke kun
at holde kernen eller basis systemet til en enkelt processor,
men også UI.

>At man vælger at fordele de forskellige processer på de CPU'er der nu
>er til rådighed virker da på mig som et fornuftigt design. Det ville
>da være direkte dumt ikke at udnytte den regnekraft der er tilstede.

Vel de har benyttet det som argument for ikke at optimere UI'en,
ligesom da de i slutningen af 80'erne begyndte at spekulere i at
smide alle drivere ind i ring0.

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
I started out with nothing & still have most of it left.

---

"Peter Jespersen" <flywheel@illogical.dk> writes:

> >Ja, men det er der vel heller ikke nogen der snakkede om. Vi snakker
> >blot om at denne administration kun varetages af den ene af de to
> >(eller flere) CPU'er. [ ... ]
>
> Vel, nogle styresystemer trækker 10-20% fra, blandt andet på
> denne regning!

Det lyder vildt, så længe vi snakker om et moderat antal processer på
et dual-system.

> Styresystemer som Linux, *BSD, OS/2 og BeOS derimod er noget
> mere beskedne!

Jeg kender stort set kun til SMP under Linux.

> Men det er endnu ikke en del af kernen, men man plejer ikke kun
> at holde kernen eller basis systemet til en enkelt processor,
> men også UI.

Det kan jeg ikke se nogen grund til, og sådan fungerer det da også
langt fra på min Linux-boks. Her kører X da gladeligt på den CPU der
nu har tid. Det er jo heller ikke en del af kernen. BASH kører da også
bare på den CPU der har tid, når jeg bruger en TTY.

--
Jacob - www.bunk.cc
I'm sorry if the correct way of doing things offends you.

---

On 21 Dec 2001 14:34:33 +0100, Jacob Bunk Nielsen wrote:

>"Peter Jespersen" <flywheel@illogical.dk> writes:
>
>> >Ja, men det er der vel heller ikke nogen der snakkede om. Vi snakker
>> >blot om at denne administration kun varetages af den ene af de to
>> >(eller flere) CPU'er. [ ... ]
>>
>> Vel, nogle styresystemer trækker 10-20% fra, blandt andet på
>> denne regning!
>
>Det lyder vildt, så længe vi snakker om et moderat antal processer på
>et dual-system.

Vel Linux/*BSD er en flok nørde systemer, hvor det ikke gør så
meget at det hele bliver holdt tilbage en ekstra uge for lidt
optimering af sådanne ting. Kommercielle systemer er ikke altid
det bedste på den front, med mindre det er et designkriterie....

BeOS snupper en 1-5%, OS/2 nok 4-8%

<snip>

>Jeg kender stort set kun til SMP under Linux.

Det skal du ikke være ked af, det er ikke det værste man kan
komme ud for

>> Men det er endnu ikke en del af kernen, men man plejer ikke kun
>> at holde kernen eller basis systemet til en enkelt processor,
>> men også UI.
>
>Det kan jeg ikke se nogen grund til, og sådan fungerer det da også
>langt fra på min Linux-boks. Her kører X da gladeligt på den CPU der
>nu har tid. Det er jo heller ikke en del af kernen. BASH kører da også
>bare på den CPU der har tid, når jeg bruger en TTY.

Med fx Windy skal programmet være forberedt for SMP før det kan
deles ud på flere processorer, ellers bliver alle tråde smidt på
den samme. Vil tro at det skyldes manglen på tråd-kultur, ikke
bare hos udviklerne af programmerne (måske udviklerne af
udviklingsværktøjerne) men også Redmond selv! Ret besynderligt
da NT er en udløber af OS/2, der har en lang tradition for
flertrådethed og er en applikation threadsafe under OS/2 bliver
trådene spredt med gavmild hånd på optil 64 processorer.

Jeg kender så ret meget til Linux på SMP konfigurationer, men
kunne godt forestille mig at udover basis-systemet er den
komplet ligeglad med hvor de enkelte processer bliver smidt,
bare der er plads!

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
Knowledge without wisdom is useless.

---

"Peter Jespersen" <flywheel@illogical.dk> writes:

> Vel Linux/*BSD er en flok nørde systemer, hvor det ikke gør så
> meget at det hele bliver holdt tilbage en ekstra uge for lidt
> optimering af sådanne ting. Kommercielle systemer er ikke altid
> det bedste på den front, med mindre det er et designkriterie....

Tja ... jeg så et interview med en eller anden fra FreeBSD-projektet,
som sagde at de med deres 5.0 current var ca. et år bagefter Linux med
hensyn til SMP. Så det er nok ikke bare altid en uge

Men ud over det, så er det også mit indtryk at FreeBSD håndterer SMP
ganske godt.

> Med fx Windy skal programmet være forberedt for SMP før det kan
> deles ud på flere processorer, ellers bliver alle tråde smidt på
> den samme. Vil tro at det skyldes manglen på tråd-kultur, ikke
> bare hos udviklerne af programmerne (måske udviklerne af
> udviklingsværktøjerne) men også Redmond selv!

Det lyder altså meget mærkeligt. Det vil sige at du mener at alle
programmer som udgangspunkt startes og køres på CPU0, hvis programmet
ikke specifikt er lavet til at checke om der er en ekstra CPU det lige
kan smide sig selv på?

Det lyder jo totalt håbløst.

> Jeg kender så ret meget til Linux på SMP konfigurationer, men
> kunne godt forestille mig at udover basis-systemet er den
> komplet ligeglad med hvor de enkelte processer bliver smidt,
> bare der er plads!

Mangler der et "ikke" eller ved du en masse men "forestiller" dig
alligevel noget ?-)

Næste gang du kommer i nærheden af en *nix-boks, så prøv at starte top
og se hvor meget CPU-tid programmerne bruger, og hvor meget af det der
bliver brugt af kernen. Desværre kan man ikke lige se hvilken CPU
processerne kører på.

I øvrigt kan jeg fortælle at jeg kører dnetc på mine to Linux-kasser,
som begge er SMP-maskiner. Der bruger kernen ikke ret meget tid
(0,1-0,3%) når den bare hygger sig med dnetc og ellers ikke lave noget
hårdt ved siden af.

--
Jacob - www.bunk.cc
He who laughs last usually had to have joke explained.

---

On 21 Dec 2001 18:36:15 +0100, Jacob Bunk Nielsen wrote:

>"Peter Jespersen" <flywheel@illogical.dk> writes:
>
>Tja ... jeg så et interview med en eller anden fra FreeBSD-projektet,
>som sagde at de med deres 5.0 current var ca. et år bagefter Linux med
>hensyn til SMP. Så det er nok ikke bare altid en uge
>
>Men ud over det, så er det også mit indtryk at FreeBSD håndterer SMP
>ganske godt.
>
>> Med fx Windy skal programmet være forberedt for SMP før det kan
>> deles ud på flere processorer, ellers bliver alle tråde smidt på
>> den samme. Vil tro at det skyldes manglen på tråd-kultur, ikke
>> bare hos udviklerne af programmerne (måske udviklerne af
>> udviklingsværktøjerne) men også Redmond selv!
>
>Det lyder altså meget mærkeligt. Det vil sige at du mener at alle
>programmer som udgangspunkt startes og køres på CPU0, hvis programmet
>ikke specifikt er lavet til at checke om der er en ekstra CPU det lige
>kan smide sig selv på?

OK, forkert formuleret!
Systemet kan godt finde ud af at smide programmet på den mest
egnede CPU, dvs den der trækker mindst, men den kan ikke fordele
et enkelt program's tråde på flere processorer....med mindre
programmet er forberedt for det.

>> Jeg kender så ret meget til Linux på SMP konfigurationer, men
>> kunne godt forestille mig at udover basis-systemet er den
>> komplet ligeglad med hvor de enkelte processer bliver smidt,
>> bare der er plads!
>
>Mangler der et "ikke" eller ved du en masse men "forestiller" dig
>alligevel noget ?-)

D'oh! Hader når det sker!

>Næste gang du kommer i nærheden af en *nix-boks, så prøv at starte top
>og se hvor meget CPU-tid programmerne bruger, og hvor meget af det der
>bliver brugt af kernen. Desværre kan man ikke lige se hvilken CPU
>processerne kører på.
>
>I øvrigt kan jeg fortælle at jeg kører dnetc på mine to Linux-kasser,
>som begge er SMP-maskiner. Der bruger kernen ikke ret meget tid
>(0,1-0,3%) når den bare hygger sig med dnetc og ellers ikke lave noget
>hårdt ved siden af.

Det må man sige er ret godt!

Har godt nok en K6 drevet SuSE kværn i skabet men har ikke følt
trang til at snuse i dens affærer, hmmm 0.1% system (den hygger
sig med en SET@Home det meste af tiden) 55 ud af 60 processer
sover, 3 kørende og 2 zombier.

Live long and prosper...
_________________________________________________________________
Peter Jespersen, member of Team OS/2 Denmark
flywheel@illogical.dk
http://www.illogical.dk
I drank a beer once but I didn't swallow any of it.

---

"Peter Jespersen" <flywheel@illogical.dk> writes:

> OK, forkert formuleret!

Heh, så er det godt jeg er kritisk

> Systemet kan godt finde ud af at smide programmet på den mest
> egnede CPU, dvs den der trækker mindst, men den kan ikke fordele
> et enkelt program's tråde på flere processorer....med mindre
> programmet er forberedt for det.

OK, så er jeg med.

> >I øvrigt kan jeg fortælle at jeg kører dnetc på mine to Linux-kasser,
> >som begge er SMP-maskiner. Der bruger kernen ikke ret meget tid
> >(0,1-0,3%) når den bare hygger sig med dnetc og ellers ikke lave noget
> >hårdt ved siden af.
>
> Det må man sige er ret godt!

Tja, jeg kom lige til at undersøge det lidt nærmere. Den dual celeron
466 jeg har til at køre som hjemmeserver (det vil sige web, mail, DNS,
NFS, NTP, SMB og hvad man nu ellers lige kan finde på) kører med de
der 0,1-0,3% system CPU-tid.

Min workstation, som er en dual Pentium Pro 200, som kører X og alt
dertil hørende (Emacs (selvfølgelig!), Licq, KDE, Opera osv.) bruger
lidt mere 1-3% CPU-tid til system. Den kører selvfølgelig også dnetc

--
Jacob - www.bunk.cc
Insanity is hereditary. You get it from your kids.

---

It seems Jacob Bunk Nielsen wrote:
> Næste gang du kommer i nærheden af en *nix-boks, så prøv at starte top
> og se hvor meget CPU-tid programmerne bruger, og hvor meget af det der
> bliver brugt af kernen. Desværre kan man ikke lige se hvilken CPU
> processerne kører på.

Hvis *nix maskinen er en FreeBSD står der hvilken CPU der kører en given
process på SMP maskiner når man kører "top"

--
Kasper Mejlgaard, TCC Frascati

---

Kasper Mejlgaard <nntpspam1@in-addr.dk> writes:

> Hvis *nix maskinen er en FreeBSD står der hvilken CPU der kører en given
> process på SMP maskiner når man kører "top"

Jeg har desværre ikke lige adgang til en FreeBSD-ting :-\

Men jeg kan se at noget lignende gør sig gældende under Solaris. Både
Solaris 7 og Solaris 8.

--
Jacob - www.bunk.cc
People who push both buttons should get their wish.

---

Jacob Bunk Nielsen wrote:
>
> Min dual-maskine svarer meget hurtigere når jeg laver tunge ting på
> den, og så kører min dnetc også dobbelt så hurtigt - det må da kaldes
> dobbelt ydelse, ikke ?-)
>

hvad er dnetc? :)

mvh
Jakob

---

Jakob Bækgaard Sandholm <jbs@stibo.dk> writes:

> hvad er dnetc? :)

Det er et lille program der bruger overskydende CPU-tid til at forsøge
at lave et angreb (ved udtømmende søgning (bruteforce på engelsk)) på
en RC5-64 krypteringsalgoritme i forbindelse med en konkurrence
udskrevet af RSA-labs. Det kan også bruges til at lave søgning
"Optimal Golomb Ruler" (det tør jeg ikke lige oversætte :). Jeg (og
dem jeg er på hold med) søger udelukkende på RC5-tingen.

Programmet fylder under en megabyte og bruger også under en megabyte
hukommelse, så man mærker stort set ikke noget til at det kører i
baggrunden. Der er SETI@home lidt anderledes, da det bruger markant
mere RAM og derfor kan virke ganske grumt på maskiner der ikke har
meget RAM.

Du kan læse mere på:

<http://www.distributed.net/> - hjemmesiden for det hele.
<http://stats.distributed.net/> - statistiksiden.
<http://www.rc5.dk/> - Mit holds (lidt kedelige) hjemmeside med
statistik for hvordan det kører. Mine tre dual-maskiner hedder
{paven, munken, abbeden}.bunk.cc i statistikken. Du (og alle andre der
har lyst) skal være meget velkommen til at hoppe med på holdet og
benytte proxy.rc5.dk som proxy og dermed dukke op i statistikken

--
Jacob - www.bunk.cc
You are so boring that when I see you my feet go to sleep.