# Gentoo wolno sie uruchamia :( [SOLVED]

## Woocash

Wczoraj sobie skompilowałem gentoo (ponownie)

Dzisiaj odpalam system i tak : jajko bootuje sie ok 15 sek. system natomiast ok 30 sek. Już nie mówie o KDE 3.2.2 (1,37 min. bez prelinku, z prelinkiem ok 1,30).

Na początku stawiałem ze staga 3 i to dosłownie szybko sie uruchamiało (KDE o 10-15 sek). No to pomyślałem że jak skompiluje prawie od zera to będzie jeszcze szyciej, ale sie rozczarowałem  :Sad:  system dłużej sie uruchamia i wogóle jakoś dziwnie chodzi  :Neutral: 

Jaka to moży być przyczyna ? Próbowałem włączyć DMA i system IO, jednak to nie zmienia sprawy.

Ps. Sytem ze stage'a3 jak i ze stage'a 1 kompilowałem na tych samych flagach.

Ps2. Mój sprzęt to : celeron 900, 256 ramu o GF2 32 MBLast edited by Woocash on Thu Jul 08, 2004 2:40 pm; edited 1 time in total

----------

## Volt3r

Z jakimi flagami kompilowales ??

Dma ci sie napewno wlacza dla dysku ??

----------

## thunder

Po pierwsze czy kompilowales oprogramowanie czy jechalez z paczek tbz2

Po 2 jak kompilowales to z jakimi flagami

Po 3 sprawdz

```
ps aux
```

lub 

```
top
```

Zaby zobaczyc czy moze cos ci spowalnia system  :Smile: 

----------

## muchar

Ważny też jest zastosowany system plików. Zwróciłbym na to baczną uwagę.

----------

## rane

 *Quote:*   

> Już nie mówie o KDE 3.2.2

 

może znajdź coś na zastępstwo dla kde (u mnie fluxbox odpala się ok. 3 sekund, a są jeszcze szybsze wm-y...)

 *Quote:*   

> Próbowałem włączyć DMA i system IO, jednak to nie zmienia sprawy.

 

próbowałeś? czyli się nie udało?

----------

## Woocash

To tak : DMA i IO mam włączone, system to xfs, fluxbox tez mi sie szybko uruchamia, ale ja wole KDE(kwestia przyzwyczajenia)

Flagi : 

FLAGS="-O2 -march=pentium3 -mcpu=pentium3 -mmmx -ftracer -falign-loops -ffast-math -frename-registers

-funroll-all-loops -pipe

-fomit-frame-pointer ${LDFLAGS} -DNDEBUG -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -DG_DISABLE_CAST_CHECKS"

CHOST="i686-pc-linux-gnu"

CXXFLAGS="-O2 -march=pentium3 -mcpu=pentium3 -pipe"

LDFLAGS="-s -z comreloc"

Kompilowałem oprogramowanie z w/w flagami (oprócz bootstrapa)

----------

## thunder

 *Quote:*   

> -march=pentium3 -mcpu=pentium3 

 

tych flag nie stosuje sie razem bo -march powoduje kompilacje dla okrelonej architekrury i wylaczenie supporta dla wszystkich innych a -mcpu kompiluje dla okreslonej architektury i ma support dla innych architektor

a co do systemu plikow to xfs nie jest za szybki lepsze jest jest jfs,ext

----------

## Woocash

Czyli mam wywalić -mcpu= czy -march= ?

ehh...

lepiej będzie jak sobie postawie od nowa getnoo z GPR (stage3)

a później najwyżej coś przekompiluje.

A co do fs, to reiser3 też jest szybki ?

----------

## thunder

No jak nie zmieniasz procesora to najlepsze jest -march a jak masz zamiar zmieniac procesor to uzywasz -mcpu

----------

## Volt3r

Co do systemu plikow to nie wiem czemu uwazasz ze xfs nie jest szybki ? Robilem kiedys specjalnie testy na kopiowanie duzych plikow i drzewa portage (ext3, jfs, reiser, xfs) i to wlasnie xfs okazal sie najszybszy do duzych plikow. Co do malych to reiser lub ext. Aktualnie mam wszystko na xfs i jest ok tylko to nieszczesne portage musze przeniesc na reiserka  :Smile: 

----------

## Woocash

Dobra czyli stawiam gentoo ze stage3  :Smile: 

Pożyjemy zobaczymy jak to będzie.

----------

## C1REX

```
CXXFLAGS="-O2 -march=pentium3 -mcpu=pentium3 -pipe"
```

Zmień też na...

```
CXXFLAGS="${CFLAGS}"
```

KDE korzysta właśnie z tych optyalizcji, których prawie nie miałeś.

Oczywiście FLAGS to też nie jest dobry wpis, ale to pewnie błąd i masz CFLAGS.

----------

## cpu

Zapokaz dmesg i otuput z hdparm tez czegos sie dowiemy   :Very Happy: 

----------

## Woocash

 *Quote:*   

> Zapokaz dmesg i otuput z hdparm tez czegos sie dowiemy.

 

Za późno  :Smile:  Już postawiłem gentoo ze stage 3, ale pokaże po kompilacji Xorg'a

----------

## fallow

co do szybkosci systemo plikow , to jakis czas temu , no troche temu , robilem sobie benchmark na bonnie++ i bylo tak jeszcze na starym hdd

```

Version  1.03       ------Sequential Output------ --Sequential Input- --Random- 

                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks-- 

Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP 

ext2           512M  9697  99 35934  17 10591   7 12669  91 30850  11 215.6   0 

ext3           512M  9864  97 35918  35 12186   9 11300  82 32600  12 191.4   0 

jfs              512M  9295  99 34634  16 10894   6 12781  91 30732  10 192.1   0 

xfs             512M 11416  98 36395  17 11585   7 12518  92 30777  12 182.5   0 

reiser3       512M  7605  79 34131  23 12375   9 11674  85 29697  12 177.5   1 

reiser4       512M  8959  95 28129  18 14299  15 10410  95 30204  16 215.8   2 

                    ------Sequential Create------ --------Random Create-------- 

                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- 

              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP 

ext2             32   428  99 +++++ +++ +++++ +++   430  99 +++++ +++  1163  99 

ext3             32   317  99 +++++ +++ 30967  99   320  99 +++++ +++   883   9 

jfs                32  6647  30 +++++ +++  5216  25  1057  15 +++++ +++   226   2 

xfs               32  1453  26 +++++ +++  1490  19  1580  32 +++++ +++   358   5 

reiser3         32 12853  98 +++++ +++  9067  81 10699  87 +++++ +++  7611  80 

reiser4         32 16122  88 +++++ +++  7378  96  7340  94 +++++ +++  7558  96 

```

a w operacjach na malych plikach ,kopiowanie kasaowanie drzewka portage bylo tak 

```

system :     reiser4   .   reiser3    .   jfs     .     xfs 

copy            67s          73s         272s        120s 

del               21s          18s         75s          50s    

```

ja czulem i czuje roznice w szybkosci miedzy jfs a reiser3/4 . Uzywalem jakis czas jfs , faktycznie bardzo malo obciaza cpu , ale w moim odczuciu reiser jest zdecydowanie szybszy . reiser4. byl na wersji snapshota 0.5.0 ; na 0.5.4 wyniki mialem juz troche lepsze.

ktos kiedys mowil na "naszym" forum , ze paczki slacka sa kompilowane z 

```

march=386 

mcpu=686 

```

wiec , kiedy chce sie uzywac intrukcji z zestawu 386 a optymalizowac wynikowe ulozenie instrukcji w kodzie pod katem 686 to chyba jednak mozna tak zrobic 

pozdro  :Smile: 

----------

## mkay

 *thunder wrote:*   

>  *Quote:*   -march=pentium3 -mcpu=pentium3  
> 
> tych flag nie stosuje sie razem bo -march powoduje kompilacje dla okrelonej architekrury i wylaczenie supporta dla wszystkich innych a -mcpu kompiluje dla okreslonej architektury i ma support dla innych architektor
> 
> 

 

nie do konca 'nie stosuje sie razem'. w takim konteksie, jak wyzej rzeczywiscie nie ma to sensu (BTW: -mtune, nie -mcpu), ale czasami mozna zastosowac obydwa switche jednoczenise. np: -march=686 -mtune=athlon-xp

----------

## mkay

wtrace sie jedynie na temat systemu plikow. reiserfs rzeczywiscie wydaje sie byc najszybszy, ale jest tez troche niestabilny. padl u mnie, padl u kilku znajomych, padl m.in. na gentoo.pl. co jak co, ale od fs'a wymagam przede wszystkim stabilnosci i pewnosci, ze nie strace swoich danych. dlatego polecam przetestowanego i nprawde niezlego ext3. z drugiej strony reiser jest naprawde niewiarygodnie szybki, gdy mamy do czynienia z bardzo duza iloscia malenkich plikow, dlatego polecam zastosowanie go dla katalogu /urs/portage (tym bardziej, ze nawet jak padnie, to te dane mozna bardzo latwo odzyskac).

BTW: jezeli kogos interesuja testy szybkosci poszczegolnych fs'ow, to polecam: http://lubuska.zapto.org/~hoppke/yellow_brown/results.html

----------

## fallow

zgadzam sie a aye  , ze szybkosc to nie wszystko , ja tez nie uzywam tylko reisera , po za tym cos za cos , reiser takze bardzo obciaza procesor , ale na duzej ilosci malych plikow jest niezastapiony , ja sie przekonalem do 

```

 / xfs

 /usr /var /tmp reiserfs

```

a i tak co jakis czas robie backup domowego systemu ...  :Smile: 

pozdro  :Smile: 

----------

## sir_skiner

 *fallow wrote:*   

> zgadzam sie a aye  , ze szybkosc to nie wszystko , ja tez nie uzywam tylko reisera , po za tym cos za cos , reiser takze bardzo obciaza procesor , ale na duzej ilosci malych plikow jest niezastapiony , ja sie przekonalem do 
> 
> ```
> 
>  / xfs
> ...

 

nie znam sie, ale w takim razie  po co ci xfs? w usr laduje prawie wszystko...

----------

## fallow

w /home/username trzymam np muzyke , filmy , i tak dalej, sa to duze pliki i  xfs obciaza cpu mniej niz reiser.

pozdro  :Smile: 

----------

## C1REX

Ta stabilność to nie jest problem, skoro i tak robi się kopię bezpieczeństwa.

Używam XFS, bo właśnie na nim wydaje mi się, że system chodzi najszybciej i najszybciej wstaje. Może mi się tylko wydaje, ale tyle mi starczy.

----------

## mkay

 *C1REX wrote:*   

> Ta stabilność to nie jest problem, skoro i tak robi się kopię bezpieczeństwa.
> 
> 

 

masz kopie bezpieczenstwa wszystkiego co masz na dysku?;p

----------

## C1REX

Kopie mam wyłącznie /

o /home się nie martwię, bo jest mała możliwość, że się rozsypie, a i wartość danych na nich jest znacznie mniejsza.

----------

## mkay

 *C1REX wrote:*   

> o /home się nie martwię, bo jest mała możliwość, że się rozsypie 

 

hmm - no taka sama, jak gdzie indziej;p

 *C1REX wrote:*   

> a i wartość danych na nich jest znacznie mniejsza.

 

uhh - to juz zalezy u kogo. / mozna zawsze odzyskac sciagajac z netu, /home z reguly nie

----------

## Woocash

Dzisiaj skompilowalem sobie KDE 3.2.2 z tymi flagami :

```
CFLAGS="-O3 -mcpu=pentium3 -march=pentium3 -mfpmath=sse -fomit-frame-pointer -f$

 -fforce-addr -funroll-loops -mmmx -msse -fprefetch-loop-arrays -ffast-math -pi$

 -DNDEBUG -DG_DISABLE_ASSERT"
```

I az mnie zamurowalo  :Neutral: 

KDE uruchomilo mi sie w... 6,2 sek  :Smile: 

Takie gentoo mi sie podoba  :Smile:   :Smile:   :Smile: 

----------

## Woocash

Nie bede zakładał nowego tematu, tylko tu go umieszcze.

A więc tak:

skompilowałem sobie mc na tych o to flagach :

```
CFLAGS="-O3 -mcpu=pentium3 -march=pentium3 -mfpmath=sse -fomit-frame-pointer -ftracer

 -fforce-addr -funroll-loops -mmmx -msse -fprefetch-loop-arrays -ffast-math -pipe -s

 -DNDEBUG -DG_DISABLE_ASSERT"
```

Mc uruchamia mi sie... w ok. 10-20 sek  :Sad: 

Próbowałem także z innymi flagami, ale skutek był jeszcze gorszy  :Sad: 

Co na to poradzicie ?

----------

## C1REX

To prawdopodobnie wina złej konfiguracji systemu, a nie flag. 

Sprawdź, czy podczas odpalania KDE (w logach) nie wywala Ci komunikatu "unknown host". To może dawać dokładnie takie objawy, jakie wystąpiły u Ciebie.

Sprawdź też, jak szybko odpala Ci się mc na koncie root-a (nie su),  na gołym xorg bez kde i całkowicie bez x-ów.

----------

## Woocash

No wywala mi takie coś przy uruchamianiu sie Xorg'a. A to bardzo źle ? i jak to naprawić ?

----------

## C1REX

Tak, to bardzo źle - zwłaszcza jeśli używa się kde. Coś zostało pominięte w procesie konfiguracji zaraz po zainstalowaniu systemu. Wszystko w handbooku powinno być.

----------

## Woocash

A byłbyś tak miły i mógł mi wkleić tą część z handbook'a ? Bo mi sie strony nie otwierają  :Sad: 

A to jest najśmieszniejsze, że mam jeszcze dwie otwarte i one działają, ale jak chce otworzyć nową to już nie działa  :Sad: 

----------

## mkay

 *Woocash wrote:*   

> A byłbyś tak miły i mógł mi wkleić tą część z handbook'a ? Bo mi sie strony nie otwierają 
> 
> A to jest najśmieszniejsze, że mam jeszcze dwie otwarte i one działają, ale jak chce otworzyć nową to już nie działa 

 

wydaje mi sie, ze chodzi o wpisanie nazwy komputera do /etc/hostname i/lub /etc/hosts (w tym drugim lacznie z ip)

----------

## C1REX

Jakby nie pomogła edycja tych plików, to mozna spróbować tego:

```
chown woocash:users /home/woocash/.ICEauthority
```

woocash to nazwa konta, a /home/woocash to katalog domowy. users to grupa do której należy.

----------

## krzyzakov

-funroll-all-loops

Ta flaga nie jest najszczesliwsza.

Sprawdz sobie jak to rozdmuchuje binarke. Lepiej -funroll-loops, jak juz musisz, chociaz i to nie zawsze  daje przyspieszenie.

Mysle, ze bootstrap najlepiej zrobic z podstawowymi flagami optymalizacji  z czego i tak -march jest najwazniejsza.

----------

## Woocash

bootstrapa to ja mam z najprostrzymi flagami skompilowanego.

-O2 -march=pentium3

----------

## Woocash

 *krzyzakov wrote:*   

> -funroll-all-loops
> 
> Ta flaga nie jest najszczesliwsza.
> 
> Sprawdz sobie jak to rozdmuchuje binarke. Lepiej -funroll-loops, jak juz musisz, chociaz i to nie zawsze  daje przyspieszenie.
> ...

 

hehe, ale ja mam właśnie  -funroll-loops, a nie -funroll-all-loops

----------

## _troll_

 *krzyzakov wrote:*   

> -funroll-all-loops
> 
> Ta flaga nie jest najszczesliwsza.
> 
> Sprawdz sobie jak to rozdmuchuje binarke. Lepiej -funroll-loops, jak juz musisz, chociaz i to nie zawsze  daje przyspieszenie.

 

w manie do gcc mozemy poczytac:

 *Quote:*   

> -funroll-loops
> 
> Unroll loops whose number of iterations can be determined at compile time or upon entry to the loop.  -funroll-loops implies both -fstrength-reduce and -frerun-cse-after-loop.  This option makes code larger, and may or may not make it run faster.
> 
> -funroll-all-loops
> ...

 

Z moich dosawiadczen z assemblerem to jednak mysle, ze rozwiniecie z -funroll-loops jest w porzadku.

Zgodnie z manem - to moze, ale nie musi przyspieszyc program, przy czym napewno nie spowoduje opoznien. To co daje ta flaga, to rozwiniecie blokow N razy w kodzie zamiast wykonujacej sie N razy petli. To nie jest zly ficzer, pod warunkiem ze z gory znana jest liczba iteracji. Minusem jest zajetosc miejsca - jesli petla zaklada wykonanie jakiejs operacji 1000 razy - to zamiast tej petli, ktora by zajela, powiedzmy 100 instrukcji, mamy 100*1000 instrukcji (z dokladnoscia do zmiany wartosci iteratora). Ubytek miejsca _moze_ byc bardzo duzy - ale miejsce jest tanie. Dyski twarde nie kosztuja juz grubych pieniedzy (mowie o zwyklym IDE  :Wink:  ). Ale przy takim tysiecznym sprawdzaniu warunku stopu dla petli zyskujemy troche czasu wlasnie dzieki rozwinieciu petli.

Z all-loops to faktycznie bylbym bardzo ostrozny. Przy nieznanej liczbie iteracji petli to ja bym tego nie rozwijal. (to _moze_. ale _nie musi_, wszystko popsuc....)

No coz... Jak zawsze - temat dyskusyjny. Sa zwolennicy i przeciwnicy. Ja stosuje -funroll-loops, wszystko dziala dobrze, a miejscem sie raczej nie przejmuje. Rozdmuchanie kodu nie jest takie duze, zeby zapelnic dysk, nie spowalnia mi to programow, a _moze_ je przyspieszyc.

Moze komus sie to przyda.

Pozdrawiam,

Przemek

----------

## mkay

 *_troll_ wrote:*   

> To co daje ta flaga, to rozwiniecie blokow N razy w kodzie zamiast wykonujacej sie N razy petli. To nie jest zly ficzer, pod warunkiem ze z gory znana jest liczba iteracji. Minusem jest zajetosc miejsca - jesli petla zaklada wykonanie jakiejs operacji 1000 razy - to zamiast tej petli, ktora by zajela, powiedzmy 100 instrukcji, mamy 100*1000 instrukcji (z dokladnoscia do zmiany wartosci iteratora). Ubytek miejsca _moze_ byc bardzo duzy - ale miejsce jest tanie. Dyski twarde nie kosztuja juz grubych pieniedzy (mowie o zwyklym IDE  ). Ale przy takim tysiecznym sprawdzaniu warunku stopu dla petli zyskujemy troche czasu wlasnie dzieki rozwinieciu petli.

 

nie robilem nigdy testow, ale wydaje mi sie to troszke picem na wode. zauwaz jak malo mozna zyskac przez rozwijanie petli. wierze, ze gcc jest na tyle sprytny, ze uzywa do takich petli licznika cx. mamy wiec:

```

petla:

...

[1000 instrukcji]

...

loop petla
```

dokladamy jedna instrukcje (loop), ktora trwa na moje oko 4-5 cykli zegarowych. wykonujemy wiec 1001, zamiast 1000 instrucji i mamy oszalamiajacy zysk 0,1% ( :Wink: ) przy 100krotnym zwiekszeniu kodu (oczywiscie tylko kodu petli - nie calego programu).

petla moze nie korzystac z cx (mam jednak watliwosci, czy wtedy zostanie rozwiniete - wydaje mi sie, ze w taki wypadku rozwijana bedzie tylko z opcja -funroll-all-lops) - wtedy zamiast loop'a mamy inc/dec + cmp + jakis jump. w sumie 3 insrtuckje, wiec zyskujemy juz 0,3% na szybkosci;]. prawda jest, ze im krotsza petla, tym wiecej zyskujemy, ale jest to IMHO gra nie warta swieczki

 *_troll_ wrote:*   

> 
> 
> Z all-loops to faktycznie bylbym bardzo ostrozny. Przy nieznanej liczbie iteracji petli to ja bym tego nie rozwijal. (to _moze_. ale _nie musi_, wszystko popsuc....)
> 
> 

 

no wlasnie jestem ciekaw na jakiej zasadzie to robia... chyba czegos jutro o tym poszukam

 *_troll_ wrote:*   

> nie spowalnia mi to programow, a _moze_ je przyspieszyc.

 

przyspieszy napewno, ale duze to przyspieszenie nie bedzie (chociaz z drugiej strony faktem jest, ze 1000 instrukcji w petli to raczej sporo - nawet jak na asemblera). wlasciwie ciekawe byloby wybranie kilku przykladowych programow i przejrzenie (oczywiscie nie reczeni:>) ile przecietnie instrukcji znajduje sie w petlach

----------

## _troll_

 *aye wrote:*   

> nie robilem nigdy testow, ale wydaje mi sie to troszke picem na wode. zauwaz jak malo mozna zyskac przez rozwijanie petli. wierze, ze gcc jest na tyle sprytny, ze uzywa do takich petli licznika cx. mamy wiec:
> 
> ```
> petla:
> 
> ...

 

Oprocz tego co dales w kodzie, jescze musi sie znalezc warunek na wyjscie z petli, co oznacza, ze w kazdym cyklu petli dochodzi zmudne sprawdzenie. IMO to jest glowny powod, by to stosowac.

 *aye wrote:*   

>  *_troll_ wrote:*   Z all-loops to faktycznie bylbym bardzo ostrozny. Przy nieznanej liczbie iteracji petli to ja bym tego nie rozwijal. (to _moze_. ale _nie musi_, wszystko popsuc....)
> 
>  no wlasnie jestem ciekaw na jakiej zasadzie to robia... chyba czegos jutro o tym poszukam

 Jak znadziesz info - podziel sie wnioskami  :Smile:  *aye wrote:*   

>  *_troll_ wrote:*   nie spowalnia mi to programow, a _moze_ je przyspieszyc. przyspieszy napewno, ale duze to przyspieszenie nie bedzie

 Z reguly - rzeczywiscie _powinno_ przyspieszyc dla zdecydowanej wiekszosci wykonywanych petli, ale nie musi dla wszystkich. Jesli petla wykonuje sie dwa razy, a iterator zmienia sie w samych instrukcjach to zysk bedzie tak maly, ze w ogole niewidoczny (dwa sprawdzenia) - zwlaszcza tam, gdzie liczba instrukcji w bloku jest naprawde duza. A kod sie rozbucha....

W moim odczuciu - miejsce jest tanie, wiec czemu nie wykorzystac takiej dosc oczywistej sztuczki?

Pozdrawiam,

Przemek

----------

## fallow

dla pentium :

```

loopne/nz    7/8

loope/z       7/8

loop            5/6

jmp             1-4

jcxz             5-6

caly zbior Jcc 1 cykl 

inc/dec reg=1 , mem=3

```

pewnie w najnowszych procesorach ilosc cykli znowu spadla , ale ja i tak zawsze bylem zwolennikiem rozwiajania petli . sam zawsze to robilem recznie w kodzie i zawsze widzialem efekty sczegolnie kiedy liczylo sie cos na obrazkacha petla musiala byc skosntruowana dla x i y ,wtedy dla 320x200 bylo to 64000 iteracji i efekt widac bylo golym okiem,choc z drugiej strony kiedy przez caly czas ilosc cykli spada wraz z pojawianiem sie nowych procesorow , rozwijanie petli chyba kiedys nie bezie mialo sensu  :Smile: 

ja takze stosuje funroll-loops , jednak co do funroll-all-loops wole zachowac ostroznosc

 w ogole to timingi zestawu x86 dla pentium sa tu 

 a tu jest b.dobre how-to jak optymizowac kod w asmie pod pentium 

 i o tym jak wykorzystywac sse 

pozdro:)

----------

## mirekm

 *fallow wrote:*   

> dla pentium :
> 
> ```
> 
> loopne/nz    7/8
> ...

 

To jeszcze do tego dodaj taki feature intela jak wypełnianie kolejki do każdego dekodera potoku przy każdym skoku, a wtedy to już się robi coś.

pozdro

----------

## fallow

 *Quote:*   

>  To jeszcze do tego dodaj taki feature intela jak wypełnianie kolejki do każdego dekodera potoku przy każdym skoku, a wtedy to już się robi coś. 

 

a na takich ficzerach to sie juz nie znam  :Smile:   :Laughing: 

pozdro  :Smile: 

----------

## yemu

 *Woocash wrote:*   

> KDE uruchomilo mi sie w... 6,2 sek 
> 
> Takie gentoo mi sie podoba   

 

mam pare pytań: jaki proc, ile ramu, jaki dysk, jaki kernel? jakie mniej wiecej uslugi masz odpalane przy starcie systemu?czy masz jakies programy w autostarcie KDE.

pytam bo 6,2 s to troche szybko:-)

mi kde uruchamia się: 

45s - pierwsze uruchomienie

9s - drugie uruchomienie

dla porownania podaje parametry:

XP2200+,512MB, dysk seagate 5400obr

kernel 2.6.5-r1, z wlaczonym preemptible i paroma rzeczami, ktore znalazlem na forum (na 2.4.26_pre6 jest podobnie)

system plikow ext2

uruchomione rzeczy typu: hotplug, samba, maskarada, cups

kde 3.2.2 przekompilowane z flagami: 

-O2 -march=athlon-xp -mfpmath=sse -fomit-frame-pointer -fforce-addr -funroll-loops -mmmx -msse -m3dnow -fprefetch-loop-arrays -ffast-math -DNDEBUG -DG_DISABLE_ASSERT

czy to normalne ze tak wolno odpala mi sie to KDE? jak ktos ma podobna konfiguracje i moglby sprawdzic i wrzucic posta ile sie mu uruchamia kde, to bede wdzieczny, bo nie wiem czy to normalne, czy mam dalej kombinowac

pozdro

yemu

----------

## Woocash

900 Mhz Celeron, 256 MB RAM, 80 GB WD 7200 obr./min 8 Mb cache, nie mam żadnych innych programów uruchmionych (typu samba, maskarada i cups)

----------

## Pepek

Dodam od siebie, że samo KDE odpala mi się w 9.8 s. Na kompie w tym czasie, gdy odpalam KDE odpalony już jest klient SETI@HOME, ale myślę, że on niewiele opóźnia. Komp to Athlon XP 2400+, 256 MB RAM, dysk Seagate Barracuda 80 GB 7200 rpm cache 2 MB, system plików ext3, jajo 2.6.3-r1.

Pozdrówki.

----------

## Woocash

 *yemu wrote:*   

> 9s - drugie uruchomienie[...]

 

Sorki, moje drugie uruchomienie trwa 6,2 sek, a pierwsze ok 15 sek, może nawet mniej, nie wiem, musiłbym jeszcze raz przetestować.

----------

## sir_skiner

 *yemu wrote:*   

>  *Woocash wrote:*   KDE uruchomilo mi sie w... 6,2 sek 
> 
> Takie gentoo mi sie podoba    
> 
> mi kde uruchamia się: 
> ...

 

to zdecydowanie nie jest normalne, mi gnome 2.6 startuje w ~10 sek. i to wydaje mi sie troche za wolno a mam athlona-xp 1800+

----------

## argasek

 *Quote:*   

> pewnie w najnowszych procesorach ilosc cykli znowu spadla , ale ja i tak zawsze bylem zwolennikiem rozwiajania petli . sam zawsze to robilem recznie w kodzie i zawsze widzialem efekty sczegolnie kiedy liczylo sie cos na obrazkacha petla musiala byc skosntruowana dla x i y ,wtedy dla 320x200 bylo to 64000 iteracji i efekt widac bylo golym okiem,choc z drugiej strony kiedy przez caly czas ilosc cykli spada wraz z pojawianiem sie nowych procesorow , rozwijanie petli chyba kiedys nie bezie mialo sensu 

 

petla:

...

dec ecx

jnz petla

Jest chyba najszybsze dla ogołu procesorów niż loop, jecxz itd.

----------

## yemu

 *sir_skiner wrote:*   

> to zdecydowanie nie jest normalne, mi gnome 2.6 startuje w ~10 sek. i to wydaje mi sie troche za wolno a mam athlona-xp 1800+

 

no wlasnie tak podejrzewalem  :Sad:  po prelinku troche sie poprawilo i pierwsze uruchomienie KDE trwa ok. 30s. 

jesli ktos ma jakies rady jak to przyspieszyć, to prosze o pomoc  :Smile: 

wrzucam jeszcze output hdparm'a bo mam wrazenie ze to moze cos z dyskiem:

```

hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 65535/16/63, sectors = 156301488, start = 0

```

```

hdparm -tT /dev/hda

/dev/hda:

Timing buffer-cache reads:   968 MB in  2.01 seconds = 481.90 MB/sec

Timing buffered disk reads:   74 MB in  3.02 seconds =  24.50 MB/sec

```

----------

## cichy

 *Woocash wrote:*   

>  *yemu wrote:*   9s - drugie uruchomienie[...] 
> 
> Sorki, moje drugie uruchomienie trwa 6,2 sek, a pierwsze ok 15 sek, może nawet mniej, nie wiem, musiłbym jeszcze raz przetestować.

 

Do yemu:

KDE3.2.0

Pierwsze uruchomienie: 12s

Nastepne 5-6s

Z uslug wlaczone jest cups (hp3650 na usb), nie mam stałki tak wiec nie ma samby, maskarady itp.

Na jajku 2.6.3 gentoo-dev-sources wyniki sa takie same

Sprzet taki jak w sygnaturze

Transfer dysku wedlug hdparm to 44MB/s. Partycja reiserfs3

Jeszcze dla porzadku: W jaki sposob liczysz czas? To co ja podalem to jest czas od zalogowania sie w kdm do calkowitego zaladowania kde.

----------

## cichy

 *yemu wrote:*   

> 
> 
> ```
> 
> hdparm /dev/hda
> ...

 

Wedlug mnie podejrzana jest linijka:

IO_support=0(default 16-bit)

Sprawdz:

```

hdparm -c /dev/hda

```

Powinno pomoc...

U mnie wyglada to tak:

```

bash-2.05b# hdparm /dev/hda

/dev/hda:

 multcount    = 16 (on)

 IO_support   =  1 (32-bit)

 unmaskirq    =  1 (on)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 65535/16/63, sectors = 78165360, start = 0

bash-2.05b# hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   824 MB in  2.00 seconds = 411.65 MB/sec

 Timing buffered disk reads:   90 MB in  3.01 seconds =  29.86 MB/sec

bash-2.05b# hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   1108 MB in  2.00 seconds = 553.53 MB/sec

 Timing buffered disk reads:  134 MB in  3.01 seconds =  44.53 MB/sec

bash-2.05b# hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   1108 MB in  2.01 seconds = 552.15 MB/sec

 Timing buffered disk reads:  134 MB in  3.00 seconds =  44.61 MB/sec

bash-2.05b# hdparm -Tt /dev/hda9

/dev/hda9:

 Timing buffer-cache reads:   1120 MB in  2.00 seconds = 559.53 MB/sec

 Timing buffered disk reads:  136 MB in  3.04 seconds =  44.73 MB/sec

bash-2.05b#

```

Dysk to WD Caviar 40GB/7200obr/8MB cache

----------

## mkay

 *argasek wrote:*   

> 
> 
> petla:
> 
> ...
> ...

 

hmm - czemu tak uwazasz?

----------

## Woocash

 *C1REX wrote:*   

> To prawdopodobnie wina złej konfiguracji systemu, a nie flag. 
> 
> Sprawdź, czy podczas odpalania KDE (w logach) nie wywala Ci komunikatu "unknown host". To może dawać dokładnie takie objawy, jakie wystąpiły u Ciebie.

 

Nadal lipa  :Sad: 

Zrobiłem to i nadal wolno sie to uruchamia ;(

----------

## argasek

 *aye wrote:*   

>  *argasek wrote:*   
> 
> petla:
> 
> ...
> ...

 

1. Ponieważ dla starszych procesorów loop z tego co pamiętam, to 3 cykle

2. dec - 1 cykl, jnz - 1 cykl = 2 cykle

3. Dla procesorów z branch-prediction (MMX i wzwyż), adres skoku warunkowego trafia w swoisty "cache" i nic nie kosztuje.

----------

## yemu

 *cichy wrote:*   

> 
> 
> Jeszcze dla porzadku: W jaki sposob liczysz czas? To co ja podalem to jest czas od zalogowania sie w kdm do calkowitego zaladowania kde.

 

troche zle napisalem bo to co ja podawalem to czas lacznie ze startem X. po zalogowaniu sie bez trybu graficznego dawalem 'startx' i mierzylem czas do znikniecia splash-screenu

----------

## _troll_

 *thunder wrote:*   

>  *Quote:*   -march=pentium3 -mcpu=pentium3  
> 
> tych flag nie stosuje sie razem bo -march powoduje kompilacje dla okrelonej architekrury i wylaczenie supporta dla wszystkich innych a -mcpu kompiluje dla okreslonej architektury i ma support dla innych architektor

 

Dlaczego 'nie stosuje sie ich razem'? Sorry - nie rozumiem czemu... To raz.

Dwa - kazda z tych flag ustawia pewne inne flagi (nazwijcie to metaflagami). Majac je obie ustawiasz sobie po prostu pewien zbior flag wlaczanych do kompilacji. Niczemu to nie przeszkadza. Po szczegoly jakie flagi - man gcc (lektura na nadchodzace wakacje  :Wink:  ).

mcpu mozesz nazwac po prostu 'lagodniejsza' wersja march - ale to tez nie do konca prawda ('nie jest to takie oczywiste', ze march wlaczy wszystko to co mcpu).

Generalnie - decyzja czy uzyc obu czy jednej z nich zalezy od kazdego usera z osobna. Od siebie dam mala rade - jesli nie wymieniacie procka zbyt czesto to walnijcie obie. Macie dokladnie pod swoja maszyne zrobiony system! IMHO - nie ma w tym nic zlego, zeby az mowic ze tak sie nie robi...

PS. Sorry za 'troche odswiezone info'. Po prostu mi nie pasilo  :Wink: 

Pozdrawiam,

Przemek

----------

## free-mind

Fragment man'a z gcc 3.3.2:

 *Quote:*   

> -march=cpu-type
> 
>            Generate instructions for the machine type cpu-type.  The choices
> 
>            for cpu-type are the same as for -mcpu.  Moreover, specifying
> ...

 

O ile się nie mylę, to stąd wynika, że ustawienie np. -march=i686 automatycznie włącza -mcpu=i686 bez konieczności dopisywania tego drugiego...  :Wink:  Peace.

----------

## fallow

o "flashback" , pamietam ze rozwodzilismy sie juz kiedys nad march i mcpu w watku o CFlagach  :Smile:  :Smile: 

----------

## _troll_

 *free-mind outsider wrote:*   

> Fragment man'a z gcc 3.3.2:
> 
>  *Quote:*   -march=cpu-type
> 
>            Generate instructions for the machine type cpu-type.  The choices
> ...

 

Juz 'sie rozpisywalismy', wiec tylko zakoncze - to nie jest takie oczywiste.

Koniec - nie jestem skonczonym trollem!  :Smile: 

Pozdrawiam,

Przemek

----------

## Woocash

Hmm, odpowie ktoś na moje pytanie ?   :Rolling Eyes: 

----------

## Woocash

Nie bede sie prosił  :Razz: 

Znam przyczyne tego "błędu"

Mam dwa dyski, jeden w kieszeni (20 GB) i jeden normalny (80 GB).

Ten w kieszeni sie strasznie 'pocił' i nie nadążał, dlatego sie tak długo gentoo uruchamiało.

Na 80'tce, ruszyło momentalnie w nie całe 30 sek miałem uruchomione gentoo + Xorg + KDE  :Smile: ))

----------

