---

Hej med jer allesammen
Jeg har lige installeret redhat 7.2 og er egentlig meget godt tilfreds.
Pludselig skete det at jeg blev forundret. Redhat's rpm'er er alle i i386
format. Hvis jeg ikke tager meget fejl betyder det at de er kompileret så de
kan køre på en i386 hvilket vil efterhånden er en gammel sag. Jeg så så også
at mandrake kan hentes i en i586 udgave som så må være kompileret til en
nyere cpu. Så kommer spørgsmålet :) Er der noget at hente ved at kompilere
det hele om til f,eks i686 Jeg har en pentium 2), og findes der en måde at
gøre det uden at skulle hente alle srpms og installere det hele på engang og
så kompilere og refreshe det hele ?

Og så lige en ting mere. Hvordan kan det være at hvis man henter en srpm, og
kompilerer den, så hedder den stadig i386 selvom den bliver kompileret under
en pentium 2. Er det endnu en redhat "feature" eller overser jeg blot et
eller andet ?

Mvh

Lars

---

"Lars Rasmussen" <nospam@please.dk> wrote in message
news:3bd7d811$0$736$edfadb0f@dspool01.news.tele.dk...
> Hej med jer allesammen
> Jeg har lige installeret redhat 7.2 og er egentlig meget godt tilfreds.
> Pludselig skete det at jeg blev forundret. Redhat's rpm'er er alle i i386
> format. Hvis jeg ikke tager meget fejl betyder det at de er kompileret så
de
> kan køre på en i386 hvilket vil efterhånden er en gammel sag. Jeg så så
også
> at mandrake kan hentes i en i586 udgave som så må være kompileret til en
> nyere cpu. Så kommer spørgsmålet :) Er der noget at hente ved at kompilere
> det hele om til f,eks i686 Jeg har en pentium 2), og findes der en måde at
> gøre det uden at skulle hente alle srpms og installere det hele på engang
og
> så kompilere og refreshe det hele ?
>
> Og så lige en ting mere. Hvordan kan det være at hvis man henter en srpm,
og
> kompilerer den, så hedder den stadig i386 selvom den bliver kompileret
under
> en pentium 2. Er det endnu en redhat "feature" eller overser jeg blot et
> eller andet ?
> Mvh
> Lars

Det er rigtig at de fleste RH rpm er lavet i i386 mode, men de vitale dele
som kernel, glibc og diverse compressing og krypterings sager kommer alle
bygget til i386, i586 og i686.
Der vil altid være lidt gevinst ved at bygge sagerne til den rette cpu, men
jeg tror det er begrænset hvor meget du får ud af at alt er bygget korrekt,
kernel er den vigtigste og det er jo den som laver det meste af arbejdet.
mvh
Torben

---

Lars Rasmussen wrote:

> ............. Så kommer spørgsmålet :) Er der noget at hente ved at
> kompilere det hele om til f,eks i686 Jeg har en pentium 2), og findes der
> en måde at gøre det uden at skulle hente alle srpms og installere det hele
> på engang og så kompilere og refreshe det hele ?

Nej.


> Og så lige en ting mere. Hvordan kan det være at hvis man henter en srpm,
> og kompilerer den, så hedder den stadig i386 selvom den bliver kompileret
> under en pentium 2. Er det endnu en redhat "feature" eller overser jeg
> blot et eller andet ?

i386 bliver brugt i to betydninger: Som navnet på 80386 processoren og som
et generisk navn for alle Intel processorer, der er baseret på 80386.

At source pakkerne hedder noget med i386 betyder blot, at de er beregnet
til at blive kompileret på en Intel platform. Der er altså ingen forskel
på sourcen til en i386, i486, Pentium I, II eller III.

Jeg tvivler også på, at der er meget at hente i performance ved at
kompilere pakkerne om.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Jeg tvivler også på, at der er meget at hente i performance ved at
> kompilere pakkerne om.

Enig. Dog med undtagelser: Fx. kan en del numerisk software kompileres
til at udnytte ATLAS biblioteket ("Automatically Tuned Linear Algebra
Subroutines"), som i sin tur kan vinde ganske voldsomt ved at blive
specialkompileret til en given maskine.

Det er i øvrigt ikke kun CPUen der tæller, mængden af cache o.l.
spiller en ikke ubetydelig rolle. Ved installationen afprøver ATLAS
simpelthen en række muligheder for de centrale algoritmer og vælger
den hurtigste. Det tager gerne adskillige timer at løbe det hele
igennem...

Det er selvfølgelig mest interessant hvis der sidder en stor grim
matrixinversion eller lignende centralt placeret i ens kode. Ellers
bliver man let skuffet.

--
O__ ---- Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk) FAX: (+45) 35327907

---

Peter Dalgaard BSA wrote:

[...]

> Det er i øvrigt ikke kun CPUen der tæller, mængden af cache o.l.
> spiller en ikke ubetydelig rolle. Ved installationen afprøver ATLAS
> simpelthen en række muligheder for de centrale algoritmer og vælger
> den hurtigste. Det tager gerne adskillige timer at løbe det hele
> igennem...

Sejt.

Mht. Cache kender jeg et par dataloger, der sad og optimerede nogle
algoritmer. De fandt, at performance af algoritmerne afhang i langt
større grad af deres evne til at udnytte cachen maksimalt end af
algoritmernes teoretisk tids-kompleksitet !

(dermed ikke sagt at vi nu skal til at bruge bubble-sort

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Peter Dalgaard BSA wrote:
>
> [...]
>
> > Det er i øvrigt ikke kun CPUen der tæller, mængden af cache o.l.
> > spiller en ikke ubetydelig rolle. Ved installationen afprøver ATLAS
> > simpelthen en række muligheder for de centrale algoritmer og vælger
> > den hurtigste. Det tager gerne adskillige timer at løbe det hele
> > igennem...
>
> Sejt.
>
> Mht. Cache kender jeg et par dataloger, der sad og optimerede nogle
> algoritmer. De fandt, at performance af algoritmerne afhang i langt
> større grad af deres evne til at udnytte cachen maksimalt end af
> algoritmernes teoretisk tids-kompleksitet !

Virkelig? Jeg har altid troet at en algoritme der kører O(N**N) er
meget langsommere end en der kører O(N**2)

Algoritmers tidskomplexitet bruges til at vurdere hvor meget tid der
skal bruges for STORE inddata. Ikke hvor meget tid der skal bruges for
et specifikt inddata... Hvis man derimod har et bestemt inddata eller
kan med god tro sige at inddata i langt de fleste tilfælde ligner
noget specielt kan man jo bruge algoritmer der enten kører meget
langsomt i worst-case. F.eks. quicksort, der er en O(N**2) algoritme
for at sortere sorterede data. Men det er sjældent man gør det, så man
bruger quicksort fordi den kører bedre for normale inddata (faktisk
O(N lg N) ) end de fleste andre sorterings algoritmer...

> (dermed ikke sagt at vi nu skal til at bruge bubble-sort
>
> -Claus
>

--
Dennis

Mother said that there would be days like this,
but she never said there would be so many!

---

Dennis Haney wrote:

> Algoritmers tidskomplexitet bruges til at vurdere hvor meget tid der
> skal bruges for STORE inddata. Ikke hvor meget tid der skal bruges for
> et specifikt inddata... Hvis man derimod har et bestemt inddata eller
> kan med god tro sige at inddata i langt de fleste tilfælde ligner
> noget specielt kan man jo bruge algoritmer der enten kører meget
> langsomt i worst-case. F.eks. quicksort, der er en O(N**2) algoritme
> for at sortere sorterede data. Men det er sjældent man gør det, så man
> bruger quicksort fordi den kører bedre for normale inddata (faktisk
> O(N lg N) ) end de fleste andre sorterings algoritmer...

Det ved jeg godt. Det, jeg skrev, forudsætter naturligvis at data er
begrænset i størrelsen (til noget der svarer til cachen).

Men hvis problemet f.eks er, at man skal bearbejde 60.000 tal en masse
gange, og man så finder at en N^2 algoritme er langsommere end en N^3
algoritme, skal man altså bruge lidt tid på at få løftet underkæben
på plads igen.

Du kan selvfølgelig bare komme med 60 mill. tal i stedet, så cachen
bliver trashet, men pointen er, at med den cache størrelse som moderne
CPUer har, er der mange af de problemer vi møder i det virkelige liv,
som kan være i cachen. Navnlig hvis det er beregningsintensive opgaver.

Jeg vil tro, at de optimeringer, som Peter beskrev ATLAS laver, netop
tager sigte på, at opdele arbejdet i dele som hver i sær passer med
cache størrelsen.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Men hvis problemet f.eks er, at man skal bearbejde 60.000 tal en masse
> gange, og man så finder at en N^2 algoritme er langsommere end en N^3
> algoritme, skal man altså bruge lidt tid på at få løftet underkæben
> på plads igen.

Hvad man glemmer med O() notationen, er at der er en konstant ganget
på (som går ud når man kører forholdsmæssigt mellem to værdier af N).

Denne konstant kan være endog meget stor for komplicerede algoritmer.
--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Dennis Haney <davh@diku.dk> writes:

> langsomt i worst-case. F.eks. quicksort, der er en O(N**2) algoritme
> for at sortere sorterede data. Men det er sjældent man gør det, så man

Det vigtige her er sorteringspunktet som bruges til at dele "bunken"
midt over. Quicksort går i N*N når punktet konsekvent deler i en tom
og en fuld bunke. Ved at tage medianen af tre punkter undgås dette
som regel.

--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Thorbjørn Ravn Andersen wrote:

> Det vigtige her er sorteringspunktet som bruges til at dele "bunken"
> midt over. Quicksort går i N*N når punktet konsekvent deler i en tom
> og en fuld bunke. Ved at tage medianen af tre punkter undgås dette
> som regel.

Deler den ikke mængden på pseudo-tilfældige stedet ? Jeg mener, at jeg
så en beregning, hvor sandsynligheden for worst-case scenariet faldt
voldsomt med størrelsen af data.

Det er SVJH det, der gør quicksort smart: Ved små datamængder har du
en (relativt) stor sandsynlighed for at havne i worst-case men det er
ikke noget problem pga. størrelsen. Ved store datamængder har du en
meget-meget lille risiko for at havne i worst-case.

-Claus

---

Claus Rasmussen wrote:

> Deler den ikke mængden på pseudo-tilfældige stedet ? Jeg mener, at jeg
> så en beregning, hvor sandsynligheden for worst-case scenariet faldt
> voldsomt med størrelsen af data.

Afhænger fuldstændig af hvilken implementation du bruger. Udvælgelsen
af "skilleelementet" er en af de ting der er meget vigtigt i en god
quicksort.

>
> Det er SVJH det, der gør quicksort smart: Ved små datamængder har du
> en (relativt) stor sandsynlighed for at havne i worst-case men det er
> ikke noget problem pga. størrelsen. Ved store datamængder har du en
> meget-meget lille risiko for at havne i worst-case.

Du vil få kortest køretid hvis dit skilleelement deler i to lige store
bunker.

Derfor vil en smule intelligens (hvilket udvælgelse af et tilfældigt
element emm ikke er) være særdeles relevant, især ved store datamængder.
--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Claus Rasmussen <clr@cc-consult.dk> skrev:

> Mht. Cache kender jeg et par dataloger, der sad og optimerede nogle
> algoritmer. De fandt, at performance af algoritmerne afhang i langt
> større grad af deres evne til at udnytte cachen maksimalt end af
> algoritmernes teoretisk tids-kompleksitet !

Ja, nogle gør mere ud af end andre. Her er et citat fra bzip2's
hjemmeside:

Other stuff I did: cacheprof

Memory effects have a big effect on the performance of programs --
especially bzip2. I tried and failed to find a decent, open-source
tool which would tell me exactly which lines of code produce cache
misses, and in the end I wrote my own. It's a useful performance
analysis tool, and I think it totally Kicks Ass. Your opinion may
differ. In any case, you can get it from http://www.cacheprof.org.

"I" er bzip2's forfatter, Julian Seward. Cacheprof er i øvrigt skrevet
i haskell.

---

Byrial Jensen wrote:

> "I" er bzip2's forfatter, Julian Seward. Cacheprof er i øvrigt skrevet
> i haskell.

Haskell ?! Det var nok ikke lige det, jeg ville vælge til et low-level
analyse værktøj. Jeg har en bog om Haskell, men har indtil videre kun
fået kigget overfladisk i den. Det kunne være, at jeg skulle kigge lidt
mere. Det ser faktisk ud til at være et spændende sprog.

-Claus

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Haskell ?! Det var nok ikke lige det, jeg ville vælge til et low-level
> analyse værktøj. Jeg har en bog om Haskell, men har indtil videre kun
> fået kigget overfladisk i den. Det kunne være, at jeg skulle kigge lidt
> mere. Det ser faktisk ud til at være et spændende sprog.

Der står også "in conjuction with the gcc toolchain". Så cacheprof
masserer formentlig uddata fra gprof eller lignende.

--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Claus Rasmussen <clr@cc-consult.dk> writes:

> Mht. Cache kender jeg et par dataloger, der sad og optimerede nogle
> algoritmer. De fandt, at performance af algoritmerne afhang i langt
> større grad af deres evne til at udnytte cachen maksimalt end af
> algoritmernes teoretisk tids-kompleksitet !

Tjah, tidsforskellen er svjv den samme mellem cache og ram som mellem
ram og disk (hurtig disk, dog), og den kender vi jo godt.

> (dermed ikke sagt at vi nu skal til at bruge bubble-sort

Nej, for den er ikke lokal på den måde som beskrevet ovenfor

--
Thorbjørn Ravn Andersen "...plus...Tubular Bells!"
http://bigfoot.com/~thunderbear

---

Lars Rasmussen wrote:

> Og så lige en ting mere. Hvordan kan det være at hvis man henter en srpm, og
> kompilerer den, så hedder den stadig i386 selvom den bliver kompileret under
> en pentium 2. Er det endnu en redhat "feature" eller overser jeg blot et
> eller andet ?

Ligger det ikke i spec-filen, hvad den binære rpm skal hedde ?

---

"Lars Rasmussen" <nospam@please.dk> wrote:

>Og så lige en ting mere. Hvordan kan det være at hvis man henter en srpm, og
>kompilerer den, så hedder den stadig i386 selvom den bliver kompileret under
>en pentium 2. Er det endnu en redhat "feature" eller overser jeg blot et
>eller andet ?

Jeg har aldrig boret i det, men jeg er ret overbevist om, at du
specifikt skal bede om at få en pakke kompileret til maskinens
processor.

Hvis en pakke automatisk blev kompileret til maskinens processor,
ville man jo ikke kunne distribuere pakken til andre bagefter -
medmindre man foretog kompileringen på en 80386...


--
Allan Olesen, Lunderskov

"UNIX er overflødigt." - Lars P. Fischer