---

Hej eksperter

Jeg har noget grafisk software som i dag kører på en HP PC med Dual Xeon 2.1
Ghz processor. Maskine er ca 3 år gammel og kører Win 2000.

Det hele fungere fint, bortset fra at visse beregninger tager meget lang
tid, 1 - 3 timer.

Jeg påtænker at købe en ny maskine HP DL 380 med de nye Intel Dualcore 5160
Woodcrest processorer.

Er der noget jeg skal være opmærksom på ved dette skifte ?

Kan jeg godt gå ud fra at softwaren kan afvikles på denne ny hardware me dde
helt nye Dualcore Processorer ?


På forhånd tak.

Søren

---

Søren wrote:
> Hej eksperter
>
> Jeg har noget grafisk software som i dag kører på en HP PC med Dual Xeon 2.1
> Ghz processor. Maskine er ca 3 år gammel og kører Win 2000.
>
> Det hele fungere fint, bortset fra at visse beregninger tager meget lang
> tid, 1 - 3 timer.
>
> Jeg påtænker at købe en ny maskine HP DL 380 med de nye Intel Dualcore 5160
> Woodcrest processorer.
>
> Er der noget jeg skal være opmærksom på ved dette skifte ?
>
> Kan jeg godt gå ud fra at softwaren kan afvikles på denne ny hardware me dde
> helt nye Dualcore Processorer ?

De woodcrest baserede maskiner der er lækre, der er godt nok blevet
sparket nyt liv i sagerne!

hvis dit programmel udnytter flere kerner som det er, burde du ikke få
nogen problemer med woodcrest'en.

---

Hej

Jeg har hørt meget godt ydelses mæssigt om HP 385 med AMD i stedet, de
skulle være noget hurtigere!

MVH jens
"Claus Albæk" <claude@eugina.dk> skrev i en meddelelse
news:44d2e747$0$15787$14726298@news.sunsite.dk...
> Søren wrote:
>> Hej eksperter
>>
>> Jeg har noget grafisk software som i dag kører på en HP PC med Dual Xeon
>> 2.1 Ghz processor. Maskine er ca 3 år gammel og kører Win 2000.
>>
>> Det hele fungere fint, bortset fra at visse beregninger tager meget lang
>> tid, 1 - 3 timer.
>>
>> Jeg påtænker at købe en ny maskine HP DL 380 med de nye Intel Dualcore
>> 5160 Woodcrest processorer.
>>
>> Er der noget jeg skal være opmærksom på ved dette skifte ?
>>
>> Kan jeg godt gå ud fra at softwaren kan afvikles på denne ny hardware me
>> dde helt nye Dualcore Processorer ?
>
> De woodcrest baserede maskiner der er lækre, der er godt nok blevet
> sparket nyt liv i sagerne!
>
> hvis dit programmel udnytter flere kerner som det er, burde du ikke få
> nogen problemer med woodcrest'en.

---

Jens Willadsen wrote:
> Hej
>
> Jeg har hørt meget godt ydelses mæssigt om HP 385 med AMD i stedet, de
> skulle være noget hurtigere!

Det var i 'gamle dage' AMD'erne får baghjul nu....

---

> De woodcrest baserede maskiner der er lækre, der er godt nok blevet
> sparket nyt liv i sagerne!
>
> hvis dit programmel udnytter flere kerner som det er, burde du ikke få
> nogen problemer med woodcrest'en.

Softwaren understøtter i hvert fald Dual Processor. Tror i så også at det
understøtter Dual Core Processor med flere kerner ?

Hvis det ikke gør, vil softwaren vel stadig kunne afvikles, bare uden at
udnytte Dual Core Processor ?


Har i noget ide om hvor hurtig Woodcrest er i forhold til tidligere Xeon
Processorer ?
Jeg har testet filer på min nuværende maskine (Dual Xeon 2.1 Ghz. ca 3år
gl). Da tog beregningerne ca. 1 time pr fil. Efterfølgende har jeg så testet
de samme filer på en Dual Xeon 3 Ghz der var ca. 9 mdr gammel. Der tog de
samme beregninger ca. 15 min pr fil.

Hvad tror i jeg kan forvente af Woodcrest ?

Jeg regner med at købe denne HP
http://h10010.www1.hp.com/wwpc/dk/da/sm/WF06b/1-3-351805-351805-12083635-12568302-77545383.html

Søren

---

>>>>> "S" == Søren <Fjern_Dette _srl@get2net.dk> writes:

S> Har i noget ide om hvor hurtig Woodcrest er i forhold til tidligere
S> Xeon Processorer ? Jeg har testet filer på min nuværende maskine
S> (Dual Xeon 2.1 Ghz. ca 3Ã¥r gl). Da tog beregningerne ca. 1 time pr
S> fil. Efterfølgende har jeg så testet de samme filer på en Dual Xeon
S> 3 Ghz der var ca. 9 mdr gammel. Der tog de samme beregninger ca. 15
S> min pr fil.

Det lyder da som en overraskende stor forbedring. Jeg vil gætte på at
din begrænsning ikke ligger i CPU-kraft.

S> Hvad tror i jeg kan forvente af Woodcrest ?

Du har alt for lidt styr på, hvad din applikation faktisk bruger tiden
på, til at nogen kan komme med et godt bud. Har maskinen overhovedet
100% CPU-forbrug på alle CPU'er når du kører din applikation?


/Benny

---

"Benny Amorsen" <benny+usenet@amorsen.dk> skrev i en meddelelse
news:m38xm2omi9.fsf@ursa.amorsen.dk...
>>>>>> "S" == Søren <Fjern_Dette _srl@get2net.dk> writes:
>
> S> Har i noget ide om hvor hurtig Woodcrest er i forhold til tidligere
> S> Xeon Processorer ? Jeg har testet filer på min nuværende maskine
> S> (Dual Xeon 2.1 Ghz. ca 3år gl). Da tog beregningerne ca. 1 time pr
> S> fil. Efterfølgende har jeg så testet de samme filer på en Dual Xeon
> S> 3 Ghz der var ca. 9 mdr gammel. Der tog de samme beregninger ca. 15
> S> min pr fil.
>
> Det lyder da som en overraskende stor forbedring. Jeg vil gætte på at
> din begrænsning ikke ligger i CPU-kraft.
>
> S> Hvad tror i jeg kan forvente af Woodcrest ?
>
> Du har alt for lidt styr på, hvad din applikation faktisk bruger tiden
> på, til at nogen kan komme med et godt bud. Har maskinen overhovedet
> 100% CPU-forbrug på alle CPU'er når du kører din applikation?
>
>
> /Benny


CPU kører stort set hele tiden mod 100 % hele tiden.

Jeg glemte også at skrive før at min nuværende konfig er med 1.5 GB ram og
den maskine jeg testede på have 4 GB ram.
Det gør selvfølgelig en del og der ligger nok nogen af forklaring.
Søren

---

>>>>> "S" == Søren <Fjern_Dette _srl@get2net.dk> writes:

S> Jeg glemte også at skrive før at min nuværende konfig er med 1.5 GB
S> ram og den maskine jeg testede på have 4 GB ram. Det gør
S> selvfølgelig en del og der ligger nok nogen af forklaring.

Hvis der ellers køres med 100% CPU hele tiden, så gør mængden af RAM
ingen forskel -- med mindre algoritmen aktivt tilpasser sig til at
benytte mere RAM.


/Benny

---

Benny Amorsen <benny+usenet@amorsen.dk> writes:

> Hvis der ellers køres med 100% CPU hele tiden, så gør mængden af RAM
> ingen forskel -- med mindre algoritmen aktivt tilpasser sig til at
> benytte mere RAM.

Nogle operativsystemer bruger overskydende hukommelse til disk-cache.
Det kan også give ret store forskelle i kørselstid, hvis de data der
arbejdes med lige pludselig kan ligge i RAM i stedet for at de skal
hentes fra disken hver gang.

--
Jacob - www.bunk.cc
I used to have a drinking problem. Now I love the stuff.

---

>>>>> "JBN" == Jacob Bunk Nielsen <spam@bunk.cc> writes:

JBN> Benny Amorsen <benny+usenet@amorsen.dk> writes:
>> Hvis der ellers køres med 100% CPU hele tiden, så gør mængden af
>> RAM ingen forskel -- med mindre algoritmen aktivt tilpasser sig til
>> at benytte mere RAM.

JBN> Nogle operativsystemer bruger overskydende hukommelse til
JBN> disk-cache. Det kan også give ret store forskelle i kørselstid,
JBN> hvis de data der arbejdes med lige pludselig kan ligge i RAM i
JBN> stedet for at de skal hentes fra disken hver gang.

Hvis applikationen ventede på disk, ville den ikke køre med konstant
100% CPU.


/Benny

---

Benny Amorsen <benny+usenet@amorsen.dk> writes:
>>>>>> "JBN" == Jacob Bunk Nielsen <spam@bunk.cc> writes:
>
> JBN> Nogle operativsystemer bruger overskydende hukommelse til
> JBN> disk-cache. Det kan også give ret store forskelle i kørselstid,
> JBN> hvis de data der arbejdes med lige pludselig kan ligge i RAM i
> JBN> stedet for at de skal hentes fra disken hver gang.
>
> Hvis applikationen ventede på disk, ville den ikke køre med konstant
> 100% CPU.

Det kommer an på hvordan man måler. På de Unix-maskiner jeg typisk
kommer i nærheden af hedder det bare 'wait' eller 'system' i stedet
for 'user'. Kigger jeg med top står applikationen stadig og bruger al
den CPU-tid den kan få.

Det kan jo også tænkes at maskinen er nødt til at swappe hvis
applikationen bruger mere hukommelse end der er til rådighed. Så vil
det (på Linux) være kswapd der bruger CPU-tiden, men maskinen vil
fortsat bruge al den CPU den kan få hvis man kigger med top. At meget
af tiden så går med en eller anden kernel-lock mens maskinen venter på
diskene er en anden sag.

--
Jacob - www.bunk.cc
Editing is a rewording activity.

---

>>>>> "JBN" == Jacob Bunk Nielsen <spam@bunk.cc> writes:

JBN> Det kommer an på hvordan man måler. På de Unix-maskiner jeg
JBN> typisk kommer i nærheden af hedder det bare 'wait' eller 'system'
JBN> i stedet for 'user'. Kigger jeg med top står applikationen stadig
JBN> og bruger al den CPU-tid den kan få.

Jeg gad nok vide, hvilken Unix du typisk kommer i nærheden af. Jeg har
i al fald aldrig set det.

JBN> Det kan jo også tænkes at maskinen er nødt til at swappe hvis
JBN> applikationen bruger mere hukommelse end der er til rådighed. Så
JBN> vil det (på Linux) være kswapd der bruger CPU-tiden, men maskinen
JBN> vil fortsat bruge al den CPU den kan få hvis man kigger med top.

kswapd skulle ikke gerne bruge ret med CPU-tid, med mindre du benytter
ATA-diske i PIO-mode.

JBN> At meget af tiden så går med en eller anden kernel-lock mens
JBN> maskinen venter på diskene er en anden sag.

Hvis man venter på en lock skal det ikke så gerne bruge CPU-tid -- kun
hvis det er spinlocks, og de spinner forhåbentligt ikke ret længe.


/Benny

---

Benny Amorsen wrote:
> Jeg gad nok vide, hvilken Unix du typisk kommer i nærheden af. Jeg har
> i al fald aldrig set det.

Cpu(s): 0.5%us, 2.0%sy, 0.0%ni, 49.9%id, 45.8%wa, 0.2%hi, 1.7%si, 0.0%st

Linux gunnar 2.6.14.4 #1 SMP PREEMPT Mon Feb 20 17:16:37 CET 2006 i686 GNU/Linux

fra top(1):
wa -- iowait
Amount of time the CPU has been waiting for I/O to complete.

// Hans
--
Jeg beskyttes IKKE af den gratis SPAMFighter til privatbrugere, der
har spammet usenet i over 6000 indlæg.

---

>>>>> "HJ" == Hans Joergensen <haj@enterprise-server.dk> writes:

HJ> fra top(1): wa -- iowait Amount of time the CPU has been waiting
HJ> for I/O to complete.

Ja, CPU'en er ikke busy på det tidspunkt, den venter netop på at få
noget arbejde.

Jeg håber da ikke top viser det som CPU busy time under den enkelte
applikation. Det ville ikke give mening.


/Benny

---

Benny Amorsen wrote:
> Ja, CPU'en er ikke busy på det tidspunkt, den venter netop på at få
> noget arbejde.

Yeb.

> Jeg håber da ikke top viser det som CPU busy time under den enkelte
> applikation. Det ville ikke give mening.

Det gør den ikke.

// Hans
--
Jeg beskyttes IKKE af den gratis SPAMFighter til privatbrugere, der
har spammet usenet i over 6000 indlæg.