Wydajny kernel
matiit
najwydajniejszy?
I jeszcze jaki najlepszy I/O sheduler? CFQ?
Chodzi mi o system na Desktop.
Damian 'legion' Szuberski
--
Damian Szuberski
matiit
To wiem. Jądro konfigurowałem wiele razy...
Myślę że mam optymalne (to teraz)...
Ale poszukuje więcej :)
Czyli jakie patche polecasz? I tego planiste... bo tego nigdy nie wiem
i ustawiam CFQ.
Zygmunt M. Zarzecki
Co to znaczy wydajny?
A binarki pod procesor masz?
zyga
--
warning!
http://zarzecki.com
We have nothing to fear but fear itself - Franklin Delano Roosevelt
Damian 'legion' Szuberski
>> Powinieneś przede wszystkim dobrze skonfigurować jądro.
> Myślę że mam optymalne (to teraz)...
> Ale poszukuje więcej :)
> Czyli jakie patche polecasz? I tego planiste... bo tego nigdy nie wiem
> i ustawiam CFQ.
A potem pobaw się flagami sysctl (odpowiedzialnymi za swap etc.).
--
Damian Szuberski
matiit
Który z tych trzech planistów jest sprawiedliwy?
Nadal nikt nie podpowiedział żadnego patcha/patchsetu.
Damian 'legion' Szuberski
> Który z tych trzech planistów jest sprawiedliwy?
> Nadal nikt nie podpowiedział żadnego patcha/patchsetu.
Gdyby istniał jakiś rozsądny patch poprawiający wydajność to pewnie
zostałby zaaplikowany, nieprawdaż?
--
Damian Szuberski
matiit
<leg...@wmid.amu.edu.cutthisjunk.pl> wrote:
> On 2008-02-15, matiit wrote:
> > Który z tych trzech planistów jest sprawiedliwy?
>
> Przeczytaj ich opisy.
>
Ale może ktoś miał jakieś doświadczenia.
> > Nadal nikt nie podpowiedział żadnego patcha/patchsetu.
>
> Gdyby istniał jakiś rozsądny patch poprawiający wydajność to pewnie
> zostałby zaaplikowany, nieprawdaż?
>
standardowy kernel ma być możliwie najlepszy we wszystkim do czego
zostanie zaprzężony.
Jacek Popławski
Kryjcie się! Gentoo user detected.
PS. Podobno jak się trzy razy przekompiluje ten sam kernel to się lepiej
dostosowuje do sprzętu, szczególnie do myszki.
matiit
Matjo, myślałem że jednak będą mądrzejsze wypowiedzi. Przemyślałem
się...
Maciej Piechotka
> Jakie patche na kernel powinienem nałożyć, żeby mieć jak
> najwydajniejszy?
Ja mam zen-sources. Jak chcesz to jest w overlayu custom-kernels.
Jednak nie spodziewaj się wielkiego przyspieszenia.
> I jeszcze jaki najlepszy I/O sheduler? CFQ?
> Chodzi mi o system na Desktop.
RTFM
Pozdrawiam
--
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)
matiit
No są zen-sources... dzieki
sporo maja bajerow do wyboru ( w menuconfig )
lanman
Plyta glowna z procesorem 2 rdzeniowym i przygotowac jajko pod SMP,
uruchomic DMA dla HDD, ReiserFS zamiast ExtFS, dodatkowo tak jak bylo
pisane umiescic w jajku tylko to co jest potrzebne, najlepiej
wkompilowac na stale (nie jako moduly) bo wtedy dziala szybciej.
Przekompilowac caly system pod swoja architekture z bibliotekami
systemowymi glibc wlacznie.
Stachu 'Dozzie' K.
O widzisz, mój drogi wyznawco Gentoo. Właśnie "wyznawco", nie
"użytkowniku", bo tylko osoba głęboko wierząca może uważać, że cały
system skompilowany pod procesor i kernel skonfigurowany dokładnie dla
sprzętu może być wydajniejszy (whatever that means) od dystrybucyjnych
binarek.
--
Secunia non olet.
Stanislaw Klekot
matiit
<doz...@dynamit.im.pwr.wroc.pl.nospam> wrote:
Mogą być... Porób sobie różne testy... nawet na firefoksie.
Skompilowany z różnymi flagami różnie się zachowuje.
Karol Olszewski
> Mogą być... Porób sobie różne testy... nawet na firefoksie.
> Skompilowany z różnymi flagami różnie się zachowuje.
poprzednik w tym watku ma killfile wiec nawet nie chce wiedziec co za
bzdure wypisal, ale moga i sa szybsze tak jak mowisz :) dodatkowo takie
systemy sa stabilniejsze !!! przy oczywiscie rozsadnej kompilacji (tj
flagach), na gentoo byl taki specjalny projekt dla kernel source ktory
wlasnie mial na celu wszelkie przyspieszenie calego jajka ale nie
pamietam nazwy musisz pogooglac (zreszta cos mi swita ze mogl juz upasc
ten projekt)
--
Karol Olszewski (GPG: 0x7196DAB4)
(K)adu: 208440
Jabber: karol.olszewski at jabber.org
[ My PGP Public Key -> http://www.keyserver.net/ ]
Bartosz Feński aka fEnIo
>> Mog=B1 by=E6... Por=F3b sobie r=F3=BFne testy... nawet na firefoksie.
>> Skompilowany z r=F3=BFnymi flagami r=F3=BFnie si=EA zachowuje.
>
> poprzednik w tym watku ma killfile wiec nawet nie chce wiedziec co za
> bzdure wypisal, ale moga i sa szybsze tak jak mowisz :) dodatkowo takie
> systemy sa stabilniejsze !!! przy oczywiscie rozsadnej kompilacji (tj
> flagach), na gentoo byl taki specjalny projekt dla kernel source ktory
> wlasnie mial na celu wszelkie przyspieszenie calego jajka ale nie
> pamietam nazwy musisz pogooglac (zreszta cos mi swita ze mogl juz upasc
> ten projekt)
No paczpan. Takie smerfastyczny projekt, przyspieszający systemy tysięcy
użytkowników i padł.
Się porobiło.
pozdr,
fEnIo
--
,''`. Bartosz Fenski | mailto:fe...@debian.org | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://fenski.pl | xmpp:fe...@jabber.org | rlu:172001
Bartosz Feński aka fEnIo
>> > Jakie patche na kernel powinienem nałożyć, żeby mieć jak
>> > najwydajniejszy?
>> > I jeszcze jaki najlepszy I/O sheduler? CFQ?
>> > Chodzi mi o system na Desktop.
>>
>> Powinieneś przede wszystkim dobrze skonfigurować jądro.
>>
>
> Plyta glowna z procesorem 2 rdzeniowym i przygotowac jajko pod SMP,
> uruchomic DMA dla HDD, ReiserFS zamiast ExtFS, dodatkowo tak jak bylo
> pisane umiescic w jajku tylko to co jest potrzebne, najlepiej
> wkompilowac na stale (nie jako moduly) bo wtedy dziala szybciej.
Teraz zapewne doczekamy się od Ciebie felietonu na temat narzutów
związanych z obsługa modułów, prawda?
> Przekompilowac caly system pod swoja architekture z bibliotekami
> systemowymi glibc wlacznie.
Koniecznie, bo takie KDE czy GNOME lubi sobie coś policzyć z użyciem SSE2.
Maciej Piechotka
To zależy od typu komputera - na często hibernowanym laptopie szybsze są moduły
- nie są za każdym razem ładowane.
Maciej Piechotka
Będzie wydajniejszy - pytanie o ile. Na pewno np. ooo przekompilowane działa znacznie szybciej (ale i kompiluje się sporo).
Łukasz D.
Ta a świstak siedzi i zawija je w te sreberka.
Mówisz jak początkujący użytkownik Ubuntu. Ale jeśli chcesz możesz sam sobie
obalić tę tezę. Postaw sobie ubuntu i przekompiluj jądro dystrybucyjne pod
sprzęt jaki tam jest. Różnica jest odczuwalna gołym okiem.
Co do całego systemu to już inna sprawa tak samo jak brak optymalizacji to
przegięciem w drugą stronę jest przesadzenie z flagami kompilatora. Ale
podam tylko jeden przykład, jakoś nie zdarzyło mi się znaleźć paczki
binarnej mplayer'a która by mnie zadowalała. Zawsze kompilowałem
niezależnie czy to był slackware, fedora, debian czy gentoo.
Łukasz Krotowski
> W artykule lanman napisał(a):
>> Przekompilowac caly system pod swoja architekture z bibliotekami
>> systemowymi glibc wlacznie.
>
> Koniecznie, bo takie KDE czy GNOME lubi sobie coś policzyć z użyciem SSE2.
Zdecydowanie. Z resztą nie tylko KDE czy GNOME, nawet najprostszy
program działający na liczbach zmiennoprzecinkowych:
#v+
float f1(void) {
return 1.5f;
}
float f2(void) {
return 2.3f;
}
int main() {
return f1() / f2();
}
#v-
skompilowany z opcjami -march=i686 -O2 daje kod (tylko main()):
#v+
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $12, %esp
call f1
fstps -16(%ebp)
call f2
fdivrs -16(%ebp)
fnstcw -6(%ebp)
movzwl -6(%ebp), %eax
movb $12, %ah
movw %ax, -8(%ebp)
fldcw -8(%ebp)
fistpl -12(%ebp)
fldcw -6(%ebp)
movl -12(%ebp), %eax
addl $12, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
#v-
zaś z opcjami -march=k8 -mfpmath=sse -O2:
#v+
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $8, %esp
call f1
fstps -12(%ebp)
call f2
fstps -8(%ebp)
movss -12(%ebp), %xmm0
divss -8(%ebp), %xmm0
addl $8, %esp
popl %ecx
leave
leal -4(%ecx), %esp
cvttss2si %xmm0, %eax
ret
#v-
Podpowiadam: operacje SSE to te korzystające z rejestrów MMX.
--
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com
Stachu 'Dozzie' K.
>>>> > Nadal nikt nie podpowiedział żadnego patcha/patchsetu.
>>>>
>>>> Gdyby istniał jakiś rozsądny patch poprawiający wydajność to pewnie
>>>> zostałby zaaplikowany, nieprawdaż?
>>>>
>>> Niekoniecznie. Taki patch mógłby nie nadawać się na serwery itp, a
>>> standardowy kernel ma być możliwie najlepszy we wszystkim do czego
>>> zostanie zaprzężony.
>>
>> O widzisz, mój drogi wyznawco Gentoo. Właśnie "wyznawco", nie
>> "użytkowniku", bo tylko osoba głęboko wierząca może uważać, że cały
>> system skompilowany pod procesor i kernel skonfigurowany dokładnie dla
>> sprzętu może być wydajniejszy (whatever that means) od dystrybucyjnych
>> binarek.
>>
> Ta a świstak siedzi i zawija je w te sreberka.
>
> Mówisz jak początkujący użytkownik Ubuntu. Ale jeśli chcesz możesz sam sobie
> obalić tę tezę. Postaw sobie ubuntu i przekompiluj jądro dystrybucyjne pod
> sprzęt jaki tam jest. Różnica jest odczuwalna gołym okiem.
A czy ta różnica nie wynika czasem z ilości ładowanych modułów
i autowykrywanego sprzętu? Bo wtedy to ty byś mówił jak początkujący
użytkownik Ubuntu.
Łukasz D.
Częściowo na pewno jest to skutek ograniczenia ilości ładowanych modułów.
Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku przejścia
moduł->kernel oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
z uwzględnieniem rejestrów jaki ten procesor posiada.
Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt, jeśli
tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale raczej tylko w
szybkości uruchamiania się systemu.
Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
Stachu 'Dozzie' K.
...które to przejście na ogół jest pomijalnie krótkie...
> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
> z uwzględnieniem rejestrów jaki ten procesor posiada.
...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
się średnio mniej niż przez 5% czasu procesora...
> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt, jeśli
> tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale raczej tylko w
> szybkości uruchamiania się systemu.
I raczej niezauważalny.
> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
Bartosz Feński aka fEnIo
No i super. Całe kilka instrukcji mniej na rzecz jednej, która pewnie
jednocyklowa nie jest.
Zresztą nawet Debian ma jądra/libc6 zoptymalizowane dla różnych wersji
procka.
Łukasz Krotowski
>
>>>> Przekompilowac caly system pod swoja architekture z bibliotekami
>>>> systemowymi glibc wlacznie.
>>>
>>> Koniecznie, bo takie KDE czy GNOME lubi sobie coś policzyć z użyciem SSE2.
>>
>> Zdecydowanie. Z resztą nie tylko KDE czy GNOME, nawet najprostszy
>> program działający na liczbach zmiennoprzecinkowych:
>>
>
> No i super. Całe kilka instrukcji mniej na rzecz jednej, która pewnie
> jednocyklowa nie jest.
Nie jest. Ale to nie ma znaczenia. Ważne jest, że kompilując kod z
włączoną matematyką zmiennoprzecinkową na SSE dostaniesz różny kod od
zwykłego i686. Poza tym kod mojego programiku to 9 linii, KDE czy GNOME
mają tych linii znacznie więcej. I nie wiem (nie czytałem i prawdę
powiedziawszy nie zamierzam) czy nie ma tam również dedykowanych
optymalizacji dla SSE (jak takie działają możesz zobaczyć np. na [1]).
[1] http://wmula.republika.pl/proj/sse2string/index.html
--
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com
Łukasz D.
no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z eth0 na
poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale pomijalne
nie jest
>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>
> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
> się średnio mniej niż przez 5% czasu procesora...
no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2% zwykle w
okolicach 0,3%
>
>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt, jeśli
>> tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale raczej tylko
>> w szybkości uruchamiania się systemu.
>
> I raczej niezauważalny.
to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć. start
desktopa 30 sekund krócej to juz jest warte zachodu
>
>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>
> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>
a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
Stachu 'Dozzie' K.
Wtedy i tak najprawdopodobniej potrzeba czegoś więcej niż oferuje
dystrybucyjne jądro, na przykład KLIPS.
>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>
>> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
>> się średnio mniej niż przez 5% czasu procesora...
>
> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2% zwykle w
> okolicach 0,3%
No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
własnoręcznej kompilacji kernela.
>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt, jeśli
>>> tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale raczej tylko
>>> w szybkości uruchamiania się systemu.
>>
>> I raczej niezauważalny.
> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć. start
> desktopa 30 sekund krócej to juz jest warte zachodu
Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
>>
>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>
>> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>>
> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
MoonWolf
>> kernel source ktory wlasnie mial na celu wszelkie przyspieszenie
>> calego jajka ale nie pamietam nazwy musisz pogooglac (zreszta cos mi
>> swita ze mogl juz upasc ten projekt)
> No paczpan. Takie smerfastyczny projekt, przyspieszający systemy
> tysięcy użytkowników i padł.
To pewnikiem spisek Debianowców do spółki z RedHatowcami.
> Się porobiło.
Czy to aby się już nie kwalifikuje na pcoa?
--
<:> Roger, MoonWolf Out <:>|Ending is near
(::) (::)|
(:) JID:moon...@jabberpl.org(:)| http://karakkhaz.prv.pl
Jacek Popławski
> Będzie wydajniejszy - pytanie o ile. Na pewno np. ooo przekompilowane działa
> znacznie szybciej (ale i kompiluje się sporo).
A dlaczego akurat OO działa szybciej? Bo się dłużej kompiluje i placebo jest
silniejsze?
Jacek Popławski
> poprzednik w tym watku ma killfile wiec nawet nie chce wiedziec co za
> bzdure wypisal, ale moga i sa szybsze tak jak mowisz :) dodatkowo takie
> systemy sa stabilniejsze !!! przy oczywiscie rozsadnej kompilacji (tj
> flagach), na gentoo byl taki specjalny projekt dla kernel source ktory
Muszę przyznać, że nawet jak na użytkownika Gentoo masz ciut za długą
sygnaturkę, czym kompilowałeś?
Jacek Popławski
> Mówisz jak początkujący użytkownik Ubuntu. Ale jeśli chcesz możesz sam sobie
> obalić tę tezę. Postaw sobie ubuntu i przekompiluj jądro dystrybucyjne pod
> sprzęt jaki tam jest. Różnica jest odczuwalna gołym okiem.
Próbowałeś kiedyś wymieniać kabel zasilający w komputerze?
Audiofile od razu słyszą różnicę.
Jacek Popławski
> Nie jest. Ale to nie ma znaczenia. Ważne jest, że kompilując kod z
> włączoną matematyką zmiennoprzecinkową na SSE dostaniesz różny kod od
> zwykłego i686. Poza tym kod mojego programiku to 9 linii, KDE czy GNOME
> mają tych linii znacznie więcej.
Pokaż wyniki testów, nie wykład teoretyczny.
Jacek Popławski
> Zresztą nawet Debian ma jądra/libc6 zoptymalizowane dla różnych wersji
> procka.
Gentoowcy mają sygnaturki na 50 linijek a Debianowcy cytują 100 linijek by
napisać 3. Tyle lat i nic się nie zmieniło.
Łukasz D.
Was ist KLIPS?
>
>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>
>>> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
>>> się średnio mniej niż przez 5% czasu procesora...
>>
>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2% zwykle
>> w okolicach 0,3%
>
> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
> własnoręcznej kompilacji kernela.
O so chodzi?
No tego już nie załapałem
>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>
>>> I raczej niezauważalny.
>> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
>> start desktopa 30 sekund krócej to juz jest warte zachodu
>
> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
kernelu?
>>>
>>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>>
>>> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>>>
>> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
>
> Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
> będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
>
Zawsze to zależy od zastosowania.
Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji no i
chodzą, to jaki to narzut wydajności narzuca to jest sprawa drugorzędna bo
podstawowym paradygmatem jest to że ma to działać.
Ile to jest błąd pomiaru? Bo jeśli założymy że błąd to 5% to przy desktopie
jest to mało ale że przy serwie 32 procesorowym taki "błąd pomiaru" to
wcale mało nie jest.
Jeśli ci chodzi o zależność ekonomiczną bo kompilacja jądra zajmuje czas
pracownika i zasoby komputera ( a jak admin lama to i kilka razy trzeba
będzie restarować maszynę ba potrzebna bedzie asysta dla fizycznego
włączenia przycisku i zanlizowaniu co konsola wypluła ,itp) to w większości
przypadków nie warto.
Jednak kompilacja własnego jądra nigdy nie zaszkodzi.
Maciej Piechotka
Nie wiem dlaczego - nie znam kodu.
a) W gentoo paczka binarna jest słabo zoptymalizowana
b) Domyślnie jest skompilowana z jakąś bardzo_przydatną_funkcją, której nie
potrzebuje (np. integracja z kde)
c) ...
Jest to jedyna paczka na której uzyskałem b. duże przyspieszenie. Oczywiście i kompilacja swoje trwała - i czy to było opłacalne to osobna sprawa.
Stachu 'Dozzie' K.
>>>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>>>> przejścia moduł->kernel
>>>>
>>>> ...które to przejście na ogół jest pomijalnie krótkie...
>>>>
>>>
>>> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z eth0
>>> na poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale
>>> pomijalne nie jest
>>
>> Wtedy i tak najprawdopodobniej potrzeba czegoś więcej niż oferuje
>> dystrybucyjne jądro, na przykład KLIPS.
> Was ist KLIPS?
http://www.google.pl/search?q=klips+kernel
>>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>>
>>>> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
>>>> się średnio mniej niż przez 5% czasu procesora...
>>>
>>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2% zwykle
>>> w okolicach 0,3%
>>
>> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
>> własnoręcznej kompilacji kernela.
> O so chodzi?
> No tego już nie załapałem
Przyznałeś że kod kernela jest wykonywany przez nie więcej niż 2% czasu,
więc jakiekolwiek skrócenie czasu jego wykonania przyspieszy działanie
najwyżej o te 2%.
>>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>>
>>>> I raczej niezauważalny.
>>> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
>>> start desktopa 30 sekund krócej to juz jest warte zachodu
>>
>> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
> kernelu?
Owszem. Licząc oczywiście od wciśnięcia entera w bootloaderze. A po
drodze się uruchamia Samba, Apache, PostgreSQL, Exim i OpenSSH.
>>>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>>>
>>>> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>>>>
>>> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
>>
>> Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
>> będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
>>
> Zawsze to zależy od zastosowania.
> Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji no i
> chodzą, to jaki to narzut wydajności narzuca to jest sprawa drugorzędna bo
> podstawowym paradygmatem jest to że ma to działać.
> Ile to jest błąd pomiaru? Bo jeśli założymy że błąd to 5% to przy desktopie
> jest to mało ale że przy serwie 32 procesorowym taki "błąd pomiaru" to
> wcale mało nie jest.
Systemy 32-procesorowe są na tyle rzadkie i drogie, że są kupowane do
specjalnych zastosowań, więc jest duża szansa że i tak kernel
dystrybucyjny nie będzie się nadawać. Poza tym takie systemy to głównie
systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
niż w user space.
Bartosz Feński aka fEnIo
>> Zresztą nawet Debian ma jądra/libc6 zoptymalizowane dla różnych wersji
>> procka.
>
> Gentoowcy mają sygnaturki na 50 linijek a Debianowcy cytują 100 linijek by
> napisać 3. Tyle lat i nic się nie zmieniło.
Podać Ci chusteczki?
Maciej Piechotka
Nie wiem na ile test jest wiarygodny
(uwaga - niejawne założenie sizeof(int) >= 3):
% cat benchmark.c
#include <stdio.h>
#include <time.h>
float calc(float a, float b) {
return (a*b + a/b)/(a+b - a*b);
}
int main() {
const unsigned int in_iter = 0xffffff;
unsigned int cumul = 0;
unsigned int iter = 0;
while(1) {
time_t start, end;
float f = 5.0f;
time(&start);
for(unsigned int i = in_iter; i; i--)
f = calc(f - 5.0f, f + 5.0f);
time(&end);
printf("Result %f. ", f);
int diff = end - start;
cumul += diff;
iter += 1;
printf("Iteration done in %ds. %d iterations in %ds.\n",
diff, iter, cumul);
}
}
Bez optymalizacji (-O2):
.file "benchmark.c"
.text
.p2align 4,,15
.globl calc
.type calc, @function
calc:
pushl %ebp
movl %esp, %ebp
flds 8(%ebp)
flds 12(%ebp)
fld %st(1)
fmul %st(1), %st
fxch %st(2)
popl %ebp
faddp %st, %st(1)
fdivrp %st, %st(1)
ret
.size calc, .-calc
.section .rodata.str1.4,"aMS",@progbits,1
.align 4
.LC2:
.string "Iteration done in %ds -> %f cps. On avarage: in %ds.\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
xorl %esi, %esi
pushl %ebx
xorl %ebx, %ebx
pushl %ecx
subl $56, %esp
leal -24(%ebp), %edi
movl $0, -40(%ebp)
movl $0, -36(%ebp)
.L4:
leal -20(%ebp), %eax
movl %eax, (%esp)
call time
movl %edi, (%esp)
call time
movl -24(%ebp), %ecx
subl -20(%ebp), %ecx
movl %ecx, %edx
sarl $31, %edx
addl %ecx, -40(%ebp)
adcl %edx, -36(%ebp)
addl $1, %ebx
adcl $0, %esi
pushl %esi
pushl %ebx
fildll (%esp)
addl $8, %esp
fildll -40(%ebp)
fdivrp %st, %st(1)
fstpl 16(%esp)
pushl %ecx
fildl (%esp)
addl $4, %esp
fdivrs .LC1
movl %ecx, 4(%esp)
movl $.LC2, (%esp)
fstpl 8(%esp)
call printf
jmp .L4
.size main, .-main
.section .rodata.cst4,"aM",@progbits,4
.align 4
.LC1:
.long 1266679807
.ident "GCC: (GNU) 4.2.2 (Gentoo 4.2.2 p1.0)"
.section .note.GNU-stack,"",@progbits
Wynik: 15 iterations in 63s
Z optymalizacją (-O2 -march=pentium-m -mmmx -msse -msse2 -mfpmath=sse):
.file "benchmark.c"
.text
.p2align 4,,15
.globl calc
.type calc, @function
calc:
pushl %ebp
movl %esp, %ebp
subl $4, %esp
movss 8(%ebp), %xmm0
movss 12(%ebp), %xmm2
movaps %xmm0, %xmm1
movaps %xmm0, %xmm3
addss %xmm2, %xmm0
divss %xmm2, %xmm1
mulss %xmm2, %xmm3
addss %xmm3, %xmm1
subss %xmm3, %xmm0
divss %xmm0, %xmm1
movss %xmm1, -4(%ebp)
flds -4(%ebp)
leave
ret
.size calc, .-calc
.section .rodata.str1.1,"aMS",@progbits,1
.LC4:
.string "Result %f. "
.section .rodata.str1.4,"aMS",@progbits,1
.align 4
.LC5:
.string "Iteration done in %ds. %d iterations in %ds.\n"
.text
.p2align 4,,15
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %edi
xorl %edi, %edi
pushl %esi
xorl %esi, %esi
pushl %ebx
pushl %ecx
subl $72, %esp
.L4:
leal -28(%ebp), %eax
movl $16777214, %ebx
movl %eax, (%esp)
call time
movl $0x41200000, 4(%esp)
movl $0x00000000, (%esp)
call calc
fstps -60(%ebp)
movss -60(%ebp), %xmm1
.p2align 4,,7
.L5:
movss .LC3, %xmm0
addss %xmm1, %xmm0
subss .LC3, %xmm1
movss %xmm0, 4(%esp)
movss %xmm1, (%esp)
call calc
subl $1, %ebx
fstps -60(%ebp)
movss -60(%ebp), %xmm1
jne .L5
leal -32(%ebp), %eax
addl $1, %esi
movss %xmm1, -56(%ebp)
movl %eax, (%esp)
call time
movss -56(%ebp), %xmm1
movl $.LC4, (%esp)
cvtss2sd %xmm1, %xmm1
movsd %xmm1, 4(%esp)
call printf
movl -32(%ebp), %eax
subl -28(%ebp), %eax
movl %esi, 8(%esp)
movl $.LC5, (%esp)
addl %eax, %edi
movl %edi, 12(%esp)
movl %eax, 4(%esp)
call printf
jmp .L4
.size main, .-main
.section .rodata.cst4,"aM",@progbits,4
.align 4
.LC3:
.long 1084227584
.ident "GCC: (GNU) 4.2.2 (Gentoo 4.2.2 p1.0)"
.section .note.GNU-stack,"",@progbits
Wynik: 15 iterations in 43s.
O ponad 30% krócej u mnie (Celeron M 1.5 GHz).
Łukasz D.
> On 16.02.2008, Łukasz D <l.s.dudi@_pomin_to_gmail.com> wrote:
>>>>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>>>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>>>>> przejścia moduł->kernel
>>>>>
>>>>> ...które to przejście na ogół jest pomijalnie krótkie...
>>>>>
>>>>
>>>> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z
>>>> eth0 na poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale
>>>> pomijalne nie jest
>>>
>>> Wtedy i tak najprawdopodobniej potrzeba czegoś więcej niż oferuje
>>> dystrybucyjne jądro, na przykład KLIPS.
>> Was ist KLIPS?
>
> http://www.google.pl/search?q=klips+kernel
no dobra ale co ma ipsec z tym wspólnego?
>
>>>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>>>
>>>>> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
>>>>> się średnio mniej niż przez 5% czasu procesora...
>>>>
>>>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2%
>>>> zwykle w okolicach 0,3%
>>>
>>> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
>>> własnoręcznej kompilacji kernela.
>> O so chodzi?
>> No tego już nie załapałem
>
> Przyznałeś że kod kernela jest wykonywany przez nie więcej niż 2% czasu,
> więc jakiekolwiek skrócenie czasu jego wykonania przyspieszy działanie
> najwyżej o te 2%.
>
dwa procent PO rekomilacji ręcznej ale nie ważne. Może i wiecej poprawić
zapominasz o czekaniu na jądro.
>>>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>>>
>>>>> I raczej niezauważalny.
>>>> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
>>>> start desktopa 30 sekund krócej to juz jest warte zachodu
>>>
>>> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
>> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
>> kernelu?
>
> Owszem. Licząc oczywiście od wciśnięcia entera w bootloaderze. A po
> drodze się uruchamia Samba, Apache, PostgreSQL, Exim i OpenSSH.
>
desktop?
openssh zgodzę sie ale reszta ? a juz zwłaszcza exim!
>>>>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>>>>
>>>>> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>>>>>
>>>> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
>>>
>>> Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
>>> będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
>>>
>> Zawsze to zależy od zastosowania.
>> Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji no
>> i chodzą, to jaki to narzut wydajności narzuca to jest sprawa drugorzędna
>> bo podstawowym paradygmatem jest to że ma to działać.
>> Ile to jest błąd pomiaru? Bo jeśli założymy że błąd to 5% to przy
>> desktopie jest to mało ale że przy serwie 32 procesorowym taki "błąd
>> pomiaru" to wcale mało nie jest.
>
> Systemy 32-procesorowe są na tyle rzadkie i drogie, że są kupowane do
> specjalnych zastosowań, więc jest duża szansa że i tak kernel
> dystrybucyjny nie będzie się nadawać.
?? a to niby dlaczego nie maja ruszyć? 2-4-8 corowe ruszają bez problemu
> Poza tym takie systemy to głównie
> systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
^^^^^^^^^^
> niż w user space.
>
Od kiedy wątków można w kernelu linuksowym używać bo chyba przegapiłem ten
moment.
Stachu 'Dozzie' K.
> Stachu 'Dozzie' K. naklepał:
>
>> On 16.02.2008, Łukasz D <l.s.dudi@_pomin_to_gmail.com> wrote:
>>>>>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>>>>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>>>>>> przejścia moduł->kernel
>>>>>>
>>>>>> ...które to przejście na ogół jest pomijalnie krótkie...
>>>>>>
>>>>>
>>>>> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z
>>>>> eth0 na poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale
>>>>> pomijalne nie jest
>>>>
>>>> Wtedy i tak najprawdopodobniej potrzeba czegoś więcej niż oferuje
>>>> dystrybucyjne jądro, na przykład KLIPS.
>>> Was ist KLIPS?
>>
>> http://www.google.pl/search?q=klips+kernel
>
> no dobra ale co ma ipsec z tym wspólnego?
Z podkreślonego, jeśli to kilkaset tysięcy przerwań na sekundę, to
najprawdopodobniej to jest normalny router, a routerowi bardzo często
się przydają łaty na kernel wprowadzające dodatkową funkcjonalność.
>>>>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>>>>
>>>>>> ...co powoduje wzrost szybkości działania kodu kernela, który wykonuje
>>>>>> się średnio mniej niż przez 5% czasu procesora...
>>>>>
>>>>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2%
>>>>> zwykle w okolicach 0,3%
>>>>
>>>> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
>>>> własnoręcznej kompilacji kernela.
>>> O so chodzi?
>>> No tego już nie załapałem
>>
>> Przyznałeś że kod kernela jest wykonywany przez nie więcej niż 2% czasu,
>> więc jakiekolwiek skrócenie czasu jego wykonania przyspieszy działanie
>> najwyżej o te 2%.
>>
> dwa procent PO rekomilacji ręcznej ale nie ważne. Może i wiecej poprawić
> zapominasz o czekaniu na jądro.
Ę? Jakim czekaniu?
>>>>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>>>>
>>>>>> I raczej niezauważalny.
>>>>> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
>>>>> start desktopa 30 sekund krócej to juz jest warte zachodu
>>>>
>>>> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
>>> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
>>> kernelu?
>>
>> Owszem. Licząc oczywiście od wciśnięcia entera w bootloaderze. A po
>> drodze się uruchamia Samba, Apache, PostgreSQL, Exim i OpenSSH.
>>
> desktop?
> openssh zgodzę sie ale reszta ? a juz zwłaszcza exim!
Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
A sudo i crontab jak niby mają się komunikować z użytkownikiem? Jak ma
wysyłać pocztę mutt? A że nie widzisz potrzeby stawiać Samby na
desktopie, to już kiepsko świadczy o twoim doświadczeniu z używaniem
desktopów.
>>>>>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>>>>>
>>>>>> Owszem jest, ale teoretyczny, bo praktycznie to on jest niemierzalny.
>>>>>>
>>>>> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
>>>>
>>>> Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
>>>> będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
>>>>
>>> Zawsze to zależy od zastosowania.
>>> Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji no
>>> i chodzą, to jaki to narzut wydajności narzuca to jest sprawa drugorzędna
>>> bo podstawowym paradygmatem jest to że ma to działać.
>>> Ile to jest błąd pomiaru? Bo jeśli założymy że błąd to 5% to przy
>>> desktopie jest to mało ale że przy serwie 32 procesorowym taki "błąd
>>> pomiaru" to wcale mało nie jest.
>>
>> Systemy 32-procesorowe są na tyle rzadkie i drogie, że są kupowane do
>> specjalnych zastosowań, więc jest duża szansa że i tak kernel
>> dystrybucyjny nie będzie się nadawać.
>
> ?? a to niby dlaczego nie maja ruszyć? 2-4-8 corowe ruszają bez problemu
A gdzie ja powiedziałem że *nie ruszy*?
>> Poza tym takie systemy to głównie
>> systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
> ^^^^^^^^^^
>> niż w user space.
>>
> Od kiedy wątków można w kernelu linuksowym używać bo chyba przegapiłem ten
> moment.
Aha. Znaczy nawet nie do końca znasz terminologię używaną przy rozmowach
o kernelu, ale próbujesz przekonywać, że masz dobre techniczne
argumenty?
Janusz Kastyk
A najszybciej zadziała, podwójnie skompilowane, samo "O" ;)
--
Janusz Kastyk
Łukasz D.
> On 16.02.2008, Łukasz D <l.s.dudi@_pomin_to_gmail.com> wrote:
>> Stachu 'Dozzie' K. naklepał:
>>
>>> On 16.02.2008, Łukasz D <l.s.dudi@_pomin_to_gmail.com> wrote:
>>>>>>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>>>>>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>>>>>>> przejścia moduł->kernel
>>>>>>>
>>>>>>> ...które to przejście na ogół jest pomijalnie krótkie...
>>>>>>>
>>>>>>
>>>>>> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>>> eth0 na poziomie kilkuset k na minutę to takie pomijalnie krótkie
>>>>>> wcale
> ^^^^
>>>>>> pomijalne nie jest
>>>>>
>>>>> Wtedy i tak najprawdopodobniej potrzeba czegoś więcej niż oferuje
>>>>> dystrybucyjne jądro, na przykład KLIPS.
>>>> Was ist KLIPS?
>>>
>>> http://www.google.pl/search?q=klips+kernel
>>
>> no dobra ale co ma ipsec z tym wspólnego?
>
> Z podkreślonego, jeśli to kilkaset tysięcy przerwań na sekundę, to
> najprawdopodobniej to jest normalny router, a routerowi bardzo często
> się przydają łaty na kernel wprowadzające dodatkową funkcjonalność.
nie każdy potrzebuje tych samych łat jak ty ale racja łata się.
>>>>>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>>>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>>>>>
>>>>>>> ...co powoduje wzrost szybkości działania kodu kernela, który
>>>>>>> wykonuje się średnio mniej niż przez 5% czasu procesora...
>>>>>>
>>>>>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2%
>>>>>> zwykle w okolicach 0,3%
>>>>>
>>>>> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
>>>>> własnoręcznej kompilacji kernela.
>>>> O so chodzi?
>>>> No tego już nie załapałem
>>>
>>> Przyznałeś że kod kernela jest wykonywany przez nie więcej niż 2% czasu,
>>> więc jakiekolwiek skrócenie czasu jego wykonania przyspieszy działanie
>>> najwyżej o te 2%.
>>>
>> dwa procent PO rekomilacji ręcznej ale nie ważne. Może i wiecej poprawić
>> zapominasz o czekaniu na jądro.
>
> Ę? Jakim czekaniu?
moga ale nie musza zmniejszyć się statystki waitów.
>>>>>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>>>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>>>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>>>>>
>>>>>>> I raczej niezauważalny.
>>>>>> to juz zależy od zastosowania, start serwera 30 sekund krócej
>>>>>> pominąć. start desktopa 30 sekund krócej to juz jest warte zachodu
>>>>>
>>>>> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
>>>> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
>>>> kernelu?
>>>
>>> Owszem. Licząc oczywiście od wciśnięcia entera w bootloaderze. A po
>>> drodze się uruchamia Samba, Apache, PostgreSQL, Exim i OpenSSH.
>>>
>> desktop?
>> openssh zgodzę sie ale reszta ? a juz zwłaszcza exim!
>
> Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
> A sudo i crontab jak niby mają się komunikować z użytkownikiem?
Podaj jeden powód po co? Masz za zadanie administracje wszystkimi desktopami
w firmie?
> Jak ma
> wysyłać pocztę mutt?
procmail fetchmail nbsmtp a nie cały exim
> A że nie widzisz potrzeby stawiać Samby na
> desktopie, to już kiepsko świadczy o twoim doświadczeniu z używaniem
> desktopów.
można używać tylko klienta. Serwer może stać ale nie musi. W dodatku nie
każdy posiada w domu kilka komputerów, jeśli chodzi o firmy, jak
najbardziej.
>>>>>>>> Ale mimo wszystko przyznałeś że wzrost wydajności jest więc EOT.
>>>>>>>
>>>>>>> Owszem jest, ale teoretyczny, bo praktycznie to on jest
>>>>>>> niemierzalny.
>>>>>>>
>>>>>> a co będzie dla ciebie praktycznym wykładnikiem mierzalnosci?
>>>>>
>>>>> Nie o wykładnik mierzalności chodzi, tylko o to, że wzrost prędkości
>>>>> będzie niemierzalny. Będzie tego samego rzędu co błąd pomiaru.
>>>>>
>>>> Zawsze to zależy od zastosowania.
>>>> Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji
>>>> no i chodzą, to jaki to narzut wydajności narzuca to jest sprawa
>>>> drugorzędna bo podstawowym paradygmatem jest to że ma to działać.
>>>> Ile to jest błąd pomiaru? Bo jeśli założymy że błąd to 5% to przy
>>>> desktopie jest to mało ale że przy serwie 32 procesorowym taki "błąd
>>>> pomiaru" to wcale mało nie jest.
>>>
>>> Systemy 32-procesorowe są na tyle rzadkie i drogie, że są kupowane do
>>> specjalnych zastosowań, więc jest duża szansa że i tak kernel
>>> dystrybucyjny nie będzie się nadawać.
>>
>> ?? a to niby dlaczego nie maja ruszyć? 2-4-8 corowe ruszają bez problemu
>
> A gdzie ja powiedziałem że *nie ruszy*?
nadinterpretacja słowa "nadawać" moja wina.
>
>>> Poza tym takie systemy to głównie
>>> systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
>> ^^^^^^^^^^
>>> niż w user space.
>>>
>> Od kiedy wątków można w kernelu linuksowym używać bo chyba przegapiłem
>> ten moment.
>
> Aha. Znaczy nawet nie do końca znasz terminologię używaną przy rozmowach
> o kernelu, ale próbujesz przekonywać, że masz dobre techniczne
> argumenty?
Nie znam TWOJEJ terminologi, wątków nie ma w kernelu i nie będzie.
Kajetan Staszkiewicz
>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>> przejścia moduł->kernel
>>
>> ...które to przejście na ogół jest pomijalnie krótkie...
>>
>
> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z eth0
> na poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale
> pomijalne nie jest
Spraw sobie porządną kartę sieciową, a nie Realteka.
>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>> raczej tylko w szybkości uruchamiania się systemu.
>>
>> I raczej niezauważalny.
> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
> start desktopa 30 sekund krócej to juz jest warte zachodu
1. Po co w(y)łączać komputer? Jest hibernacja.
2. Moje skompilowane pod procesor Gentoo włacza się wolniej od
- Windowsa
- Fedory używającej zupełnie standardowych Fedorowych pakietów
--
| pozdrawiam / greetings | powered by Centos, Gentoo and FreeBSD |
| Kajetan Staszkiewicz | jabber,email,www: vegeta()tuxpowered net |
| Vegeta | IMQ devnames: http://tuxpowered.net |
`------------------------^------------------------------------------'
Kajetan Staszkiewicz
> Zawsze to zależy od zastosowania.
> Jądra dystrybucyjne mają chodzić na wszystkim i w każdej konfiguracji no i
> chodzą, to jaki to narzut wydajności narzuca to jest sprawa drugorzędna bo
> podstawowym paradygmatem jest to że ma to działać.
Narzut wydajności związany z leżącymi na dysku niezaładowanymi modułami?
> Jeśli ci chodzi o zależność ekonomiczną bo kompilacja jądra zajmuje czas
> pracownika i zasoby komputera ( a jak admin lama to i kilka razy trzeba
> będzie restarować maszynę ba potrzebna bedzie asysta dla fizycznego
> włączenia przycisku i zanlizowaniu co konsola wypluła ,itp) to w
> większości przypadków nie warto.
> Jednak kompilacja własnego jądra nigdy nie zaszkodzi.
Normalnie marzę o tym by skompilować sobie jądro, a potem do niego podpiąć
jakieś zamknięte binarne moduły dostarczane przez producenta np. kontrolera
RAID.
matiit
>2. Moje skompilowane pod procesor Gentoo włacza się wolniej od
> - Windowsa
> - Fedory używającej zupełnie standardowych Fedorowych pakietów
Bo więcej do gadania przy starcie mają skrypty startowe. Sam napisz
takie specjalnie dla Ciebie to 15s do kdma problemem nie będzie,
Mariusz Kruk
>>>> Systemy 32-procesorowe są na tyle rzadkie i drogie, że są kupowane do
>>>> specjalnych zastosowań, więc jest duża szansa że i tak kernel
>>>> dystrybucyjny nie będzie się nadawać.
>>> ?? a to niby dlaczego nie maja ruszyć? 2-4-8 corowe ruszają bez problemu
>> A gdzie ja powiedziałem że *nie ruszy*?
>nadinterpretacja słowa "nadawać" moja wina.
A kto nadinterpretował? Ja?
>>>> Poza tym takie systemy to głównie
>>>> systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
>>> ^^^^^^^^^^
>>>> niż w user space.
>>> Od kiedy wątków można w kernelu linuksowym używać bo chyba przegapiłem
>>> ten moment.
>> Aha. Znaczy nawet nie do końca znasz terminologię używaną przy rozmowach
>> o kernelu, ale próbujesz przekonywać, że masz dobre techniczne
>> argumenty?
>Nie znam TWOJEJ terminologi, wątków nie ma w kernelu i nie będzie.
A to bardzo ciekawe co Pan pisze. Pierwszy z brzegu dokument:
http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread
twierdzi coś innego.
--
\.\.\.\.\.\.\.\.\.\.\.\.\.\ Powyższy post został napisany w stanie ogra-
.\.Kr...@epsilon.eu.org.\.\. niczonej świadomości i należy się spodzie-
\.http://epsilon.eu.org/\.\ wać, że gdy dojdę do siebie to wyślę cance-
.\.\.\.\.\.\.\.\.\.\.\.\.\. la.(Dariusz Laskowski)
Łukasz D.
> Dnia sobota 16 lutego 2008 15:24, Łukasz D. napisał(a):
>
>>>> Częściowo na pewno jest to skutek ograniczenia ilości ładowanych
>>>> modułów. Ale nie wszystko. Masz jeszcze wzrost wydajności w wyniku
>>>> przejścia moduł->kernel
>>>
>>> ...które to przejście na ogół jest pomijalnie krótkie...
>>>
>>
>> no to juz zależy, przykładowo jak masz ostro wysyłane przerwania z eth0
>> na poziomie kilkuset k na minutę to takie pomijalnie krótkie wcale
>> pomijalne nie jest
>
> Spraw sobie porządną kartę sieciową, a nie Realteka.
>
>
>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>
>>> I raczej niezauważalny.
>> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć.
>> start desktopa 30 sekund krócej to juz jest warte zachodu
>
> 1. Po co w(y)łączać komputer? Jest hibernacja.
> 2. Moje skompilowane pod procesor Gentoo włacza się wolniej od
> - Windowsa
> - Fedory używającej zupełnie standardowych Fedorowych pakietów
>
1.zmiana kernela/ systemu/ fizycznego położenia maszyny jeszcze jakieś się
pewnie znajdą powody.
2.no cóż moje szybciej
Łukasz D.
> A to bardzo ciekawe co Pan pisze. Pierwszy z brzegu dokument:
> http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread
> twierdzi coś innego.
>
nazywają process wątkiem ale niech będzie
Mea Culpa
kline...@hotmail.com
> Poza tym kod mojego programiku to 9 linii, KDE czy GNOME
> mają tych linii znacznie więcej. I nie wiem (nie czytałem i prawdę
> powiedziawszy nie zamierzam) czy nie ma tam również dedykowanych
> optymalizacji dla SSE (jak takie działają możesz zobaczyć np. na [1]).
Są. Kilka popularnych przykładów z brzega na moim Athlon64:
Sterownik do Geforce: (zrzut z glxinfo):
OpenGL renderer string: GeForce 6150/PCI/SSE2/3DNOW!
OpenGL version string: 1.4 (2.1.2 NVIDIA 171.05)
uruchomienie MPlayer:
MPlayer 1.0rc2-4.2.3 (C) 2000-2007 MPlayer Team
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
kompilacja MPlayer:
Checking for CPU vendor ... AuthenticAMD (15:47:2)
Checking for CPU type ... AMD Athlon(tm) 64 Processor 3000+
Checking for kernel support of mmx ... yes
Checking for kernel support of mmxext ... yes
Checking for kernel support of 3dnow ... yes
Checking for kernel support of 3dnowext ... yes
Checking for kernel support of sse ... yes
Checking for kernel support of sse2 ... yes
Checking for kernel support of cmov ... yes
Checking for mtrr support ... yes
Kompilacja ze źródeł KDE 3.5.8 libs (etap configure):
checking for assembler support for IA32 extensions... MMX yes, SSE yes, SSE2
yes, 3DNOW yes
tych programów jest znacznie więcej. Więcej zrzutów na życzenie.
Obecne oprogramowanie Linuksowe używa SSE2 i 3DNOW oraz XRender, OpenGL,
XvMC dlatego więc jeśli się kompiluje system pod swoją maszynę to warto
wybierać sprzęt który wspiera te funkcje.
I nigdy nie używam gentoo. Jestem fanem Lunar-Linux
Bo distro na źródłach to nie tylko gentoo:
http://distrowatch.com/source.php
--
kline...@hotmail.com is spammer
kline...@hotmail.com
Nie przejmuj się. Ze mnie też się śmiali jak pisałem, że samodzielnie
skompilowane jajo jest szybsze od firmowego. Po prostu są tacy co nigdy nie
wyściubili nosa poza firmowe binarki i nie mają pojęcia, że gdzieś tam jest
lepszy świat oparty o źródełka (nie tylko gentoo).
--
kline...@hotmail.com is spammer
Krzysztof Halasa
> nazywają process wątkiem ale niech będzie
Watki kernela maja niewiele wspolnego z procesami, to sa normalne
watki. W szczegolnosci maja wspolna przestrzen adresowa.
--
Krzysztof Halasa
Mariusz Kruk
>> http://www.linuxquestions.org/linux/articles/Technical/Linux_Kernel_Thread
>> twierdzi coś innego.
>nazywają process wątkiem ale niech będzie
Proces? A gdzie masz procesy w jądrze. To właśnie są wątki. W
szczególności, nie są odseparowane w sensie pamięci.
--
d'`'`'`'`'`'`'`'`'`'`'`'`'Yb Bug: (n.) any program feature not yet de-
`b Kr...@epsilon.eu.org d' scribed to marketing.
d' http://epsilon.eu.org/ Yb
`b,-,.,-,.,-,.,-,.,-,.,-,.d'
Jacek Popławski
>>> Nie jest. Ale to nie ma znaczenia. Ważne jest, że kompilując kod z
>>> włączoną matematyką zmiennoprzecinkową na SSE dostaniesz różny kod od
>>> zwykłego i686. Poza tym kod mojego programiku to 9 linii, KDE czy GNOME
>>> mają tych linii znacznie więcej.
>>
>> Pokaż wyniki testów, nie wykład teoretyczny.
Pokaż wyniki testów prawdziwych aplikacji.
Bo póki co to ma to tyle samo sensu co fascynowanie się potokami i nanometrami.
Jacek Popławski
> uruchomienie MPlayer:
Przyśpieszanie mplayera miało sens siedem lat temu, gdy miałem K6-2 500. Czy
teraz mplayer zbyt wolno odtwarza Ci filmy? A jeśli nie, to na czym konkretnie
polega zysk po przekompilowaniu?
> I nigdy nie używam gentoo. Jestem fanem Lunar-Linux
> Bo distro na źródłach to nie tylko gentoo:
> http://distrowatch.com/source.php
Jedyną dystrybucją, w której kompilacja wszystkie ma sens jest LFS.
Jacek Popławski
>> - Windowsa
>> - Fedory używającej zupełnie standardowych Fedorowych pakietów
>>
> 1.zmiana kernela/ systemu/ fizycznego położenia maszyny jeszcze jakieś się
> pewnie znajdą powody.
> 2.no cóż moje szybciej
Właśnie to jest najlepsze... rozmawiałem kiedyś z fanem Gentoo, który chwalił
Windows XP za to, jak szybko mu startuje. Nie chciałem go dobijać czasem
startowania mojego Archa.
Szybkość startu systemu nijak ma się do kompilacji, o tym decydują przede
wszystkim skrypty startowe oraz liczba systemów do zamontowania i sprzętu do
obsłużenia.
Użytkownicy Gentoo są jak początkujący programiści, którzy nie skończyli
jeszcze zaczynać pisania programu a już chcą go zoptymalizować i w tym celu
czytają o rejestrach procesora.
Łukasz D.
>
> Szybkość startu systemu nijak ma się do kompilacji, o tym decydują przede
> wszystkim skrypty startowe oraz liczba systemów do zamontowania i sprzętu
> do obsłużenia.
Stachu 'Dozzie' K.
>>>>>>>>> oraz jak prawidłowo podasz typ procesora to dostosowanie kodu
>>>>>>>>> z uwzględnieniem rejestrów jaki ten procesor posiada.
>>>>>>>>
>>>>>>>> ...co powoduje wzrost szybkości działania kodu kernela, który
>>>>>>>> wykonuje się średnio mniej niż przez 5% czasu procesora...
>>>>>>>
>>>>>>> no cóż nie chce się licytować ale u mnie to jest niż mniej niż 2%
>>>>>>> zwykle w okolicach 0,3%
>>>>>>
>>>>>> No widzisz? Czyli zyskujesz ostro mniej niż 2% czasu na wykonaniu po
>>>>>> własnoręcznej kompilacji kernela.
>>>>> O so chodzi?
>>>>> No tego już nie załapałem
>>>>
>>>> Przyznałeś że kod kernela jest wykonywany przez nie więcej niż 2% czasu,
>>>> więc jakiekolwiek skrócenie czasu jego wykonania przyspieszy działanie
>>>> najwyżej o te 2%.
>>>>
>>> dwa procent PO rekomilacji ręcznej ale nie ważne. Może i wiecej poprawić
>>> zapominasz o czekaniu na jądro.
>>
>> Ę? Jakim czekaniu?
> moga ale nie musza zmniejszyć się statystki waitów.
Ale o czym ty w ogóle mówisz?
>>>>>>>>> Ogólnie to zależy jak dobrze potrafisz dostosować jądro pod sprzęt,
>>>>>>>>> jeśli tylko wywalisz zbędne moduły to wzrost jakiś tam będzie. Ale
>>>>>>>>> raczej tylko w szybkości uruchamiania się systemu.
>>>>>>>>
>>>>>>>> I raczej niezauważalny.
>>>>>>> to juz zależy od zastosowania, start serwera 30 sekund krócej
>>>>>>> pominąć. start desktopa 30 sekund krócej to juz jest warte zachodu
>>>>>>
>>>>>> Start desktopa można przyspieszyć w ogóle nie dotykając kernela.
>>>>> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
>>>>> kernelu?
>>>>
>>>> Owszem. Licząc oczywiście od wciśnięcia entera w bootloaderze. A po
>>>> drodze się uruchamia Samba, Apache, PostgreSQL, Exim i OpenSSH.
>>>>
>>> desktop?
>>> openssh zgodzę sie ale reszta ? a juz zwłaszcza exim!
>>
>> Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
>> A sudo i crontab jak niby mają się komunikować z użytkownikiem?
> Podaj jeden powód po co?
Logi się same nie rotują, crontab jest potrzebny. To samo z listą
dostępnych pakietów. Znajdzie się jeszcze parę innych spraw, które warto
okresowo wykonywać.
A jeśli wyskoczysz mi że logi są na desktopie niepotrzebne, to cię
wyśmieję.
> Masz za zadanie administracje wszystkimi desktopami
> w firmie?
Nie, skądże. Stacje robocze nie wymagają dozoru, same o siebie dbają
i rozwiązują problemy użytkowników.
Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
>>>> Poza tym takie systemy to głównie
>>>> systemy obliczeniowe, które w wątkach kernela pracują jeszcze rzadziej
>>> ^^^^^^^^^^
>>>> niż w user space.
>>>>
>>> Od kiedy wątków można w kernelu linuksowym używać bo chyba przegapiłem
>>> ten moment.
>>
>> Aha. Znaczy nawet nie do końca znasz terminologię używaną przy rozmowach
>> o kernelu, ale próbujesz przekonywać, że masz dobre techniczne
>> argumenty?
>
> Nie znam TWOJEJ terminologi, wątków nie ma w kernelu i nie będzie.
Drogi chłopcze, może pora się douczyć powszechnie używanej terminologii?
http://www.google.pl/search?q=kernel+thread+site%3Alkml.org
http://lkml.org/lkml/2007/12/22/32
Chyba że Andrew Morton się nie zna i cymbał jeden pisze
o nieistniejących wątkach kernelowych.
Stachu 'Dozzie' K.
Tylko widzisz, niektórzy z nas na tej grupie używają pewnych rzeczy
i otwarcie je krytykują albo wręcz nie lubią. Ja na ten przykład Gentoo
nie lubię, ale używam na codzień, a Slackware uwielbiam, ale potrafię
wskazać w nim kilka baboli. Kernel też mam skompilowany własnoręcznie,
ale dlatego że potrzebuję pewnych specyficznych opcji, których
dystrybucja mi nie dostarcza.
kline...@hotmail.com
> Dnia 17.02.2008 kline...@hotmail.com <kline...@hotmail.com>
> napisał/a:
>> uruchomienie MPlayer:
>
> Przyśpieszanie mplayera miało sens siedem lat temu, gdy miałem K6-2 500.
> Czy teraz mplayer zbyt wolno odtwarza Ci filmy? A jeśli nie, to na czym
> konkretnie polega zysk po przekompilowaniu?
Zajmuje mniej czasu procesora. Dzięki temu można coś odpalić w tle lub
włączyć polepszacze obrazu. Nawet za 10 lat będzie się opłacało kompilować
aby jeszcze bardziej poprawić jakość tych samych filmów.
> Jedyną dystrybucją, w której kompilacja wszystkie ma sens jest LFS.
Ja po użyciu źródełkowej na powolne binarki już nie wrócę.
--
kline...@hotmail.com is spammer
Łukasz D.
>>> Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
>>> A sudo i crontab jak niby mają się komunikować z użytkownikiem?
>> Podaj jeden powód po co?
>
> Logi się same nie rotują, crontab jest potrzebny. To samo z listą
> dostępnych pakietów. Znajdzie się jeszcze parę innych spraw, które warto
> okresowo wykonywać.
>
ale od kiedy wysłanie maila z desktopa wymaga całego systemu pocztowego?
Ciekawe ile maili dostajesz dziennie z tych desktopów? I czy je czytasz w
ogóle? Ile procent "awarii" łapiesz przez te maile?
Mają problem to się logujesz mu na kompa dzięki AD.
Nie znam waszej polityki bezpieczeństwa.
Ale użytkownicy zawsze mają problemy i niezależnie czy dostajesz maile czy
nie.
> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
Zdefiniuj normalność.
Jacek Popławski
>> Przyśpieszanie mplayera miało sens siedem lat temu, gdy miałem K6-2 500.
>> Czy teraz mplayer zbyt wolno odtwarza Ci filmy? A jeśli nie, to na czym
>> konkretnie polega zysk po przekompilowaniu?
>
> Zajmuje mniej czasu procesora. Dzięki temu można coś odpalić w tle
Co konkretnie odpalasz w tle w trakcie oglądania filmu MPlayerem?
Niech zgadnę - kompilację?
>> Jedyną dystrybucją, w której kompilacja wszystkie ma sens jest LFS.
>
> Ja po użyciu źródełkowej na powolne binarki już nie wrócę.
A do czego używasz komputera (poza kompilowaniem nieswojego kodu)?
Maciej Piechotka
Zygmunt M. Zarzecki
> dostosowuje do sprzętu, szczególnie do myszki.
Napisze to inaczej:
Jak się 3 razy przekompiluje jądra, to myszka lepiej pasuje.
Aha, częste czyszczenie myszki też jest dobrym zwyczajem.
;-)
zyga
--
warning!
http://zarzecki.com
We have nothing to fear but fear itself - Franklin Delano Roosevelt
MirMir
następnej linijki wychodzi mi poza limit :-)
Dnia 16.02.2008 Stachu 'Dozzie' K. <doz...@dynamit.im.pwr.wroc.pl.nospam> napisał/a:
>> desktop?
>> openssh zgodzę sie ale reszta ? a juz zwłaszcza exim!
>
> Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
> A sudo i crontab jak niby mają się komunikować z użytkownikiem? Jak ma
> wysyłać pocztę mutt? A że nie widzisz potrzeby stawiać Samby na
> desktopie, to już kiepsko świadczy o twoim doświadczeniu z używaniem
> desktopów.
>
A żeby nawiązać do tematów poruszanych w wątku:
--
G
e
n
t
o
o
s
i
g
n
a
t
u
r
e
Pozdrawiam
MirMir
aparat2 .małpek. wp @kropek@ pl
Krzysztof Halasa
> ale od kiedy wysłanie maila z desktopa wymaga całego systemu pocztowego?
Nie, wystarczy MTA.
Wysylanie poczty bezposrednio na jakas zdalna maszyne jest nieco bez
sensu - co biedny np. cron ma zrobic, jesli nie uda sie (szybko)
wyslac? Jakis spooler musi byc.
Aczkolwiek moga byc desktopy bez poczty, kwestia (specyficznych)
potrzeb. Moga byc tez desktopy bez logow.
--
Krzysztof Halasa
Stachu 'Dozzie' K.
> Stachu 'Dozzie' K. naklepał:
>
>>>> Tak ciężko uwierzyć że system pocztowy na desktopie też jest potrzebny?
>>>> A sudo i crontab jak niby mają się komunikować z użytkownikiem?
>>> Podaj jeden powód po co?
>>
>> Logi się same nie rotują, crontab jest potrzebny. To samo z listą
>> dostępnych pakietów. Znajdzie się jeszcze parę innych spraw, które warto
>> okresowo wykonywać.
>>
> ale od kiedy wysłanie maila z desktopa wymaga całego systemu pocztowego?
Exim jest dostatecznie lekki żeby nie musieć rozważać jakichś ułomnych
implementacji SMTP.
> Ciekawe ile maili dostajesz dziennie z tych desktopów? I czy je czytasz w
> ogóle? Ile procent "awarii" łapiesz przez te maile?
Około 90%. Wyjątkami mogą być awarie systemów pocztowych i sysloga,
które zdarzają się tylko przy bardzo intensywnej rekonfiguracji (tj.
przy pracach nad systemem powiadamiania).
> Mają problem to się logujesz mu na kompa dzięki AD.
Active Directory pod Linuksem? Ciekawe jak.
>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
> Zdefiniuj normalność.
Dla przypomnienia:
>>> Masz za zadanie administracje wszystkimi desktopami
>>> w firmie?
>>
>> Nie, skądże. Stacje robocze nie wymagają dozoru, same o siebie dbają
>> i rozwiązują problemy użytkowników.
>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
Odwróćmy twoje pytanie. Z jakimi sieciami miałeś do czynienia że
uważasz[*], że desktopami się nie administruje?
[*] To przynajmniej sugeruje twoje pytanie, które odbieram jako
zdziwienie, że tym w ogóle trzeba się zajmować.
Łukasz Krotowski
> Dnia 16.02.2008 Łukasz Krotowski <not...@notreal.pl> napisał/a:
>> Nie jest. Ale to nie ma znaczenia. Ważne jest, że kompilując kod z
>> włączoną matematyką zmiennoprzecinkową na SSE dostaniesz różny kod od
>> zwykłego i686. Poza tym kod mojego programiku to 9 linii, KDE czy GNOME
>> mają tych linii znacznie więcej.
>
> Pokaż wyniki testów, nie wykład teoretyczny.
Wyciąłeś wyniki, to raz. Przedstawione przeze mnie testy i ich wyniki
potwierdzają moją tezę, to dwa. EOD.
--
Łukasz Krotowski | lukasz.krotowski_AT_gmail.com
Łukasz D.
> Exim jest dostatecznie lekki żeby nie musieć rozważać jakichś ułomnych
> implementacji SMTP.
bardziej trafia do mnie argument ze spoolerem czy jak to po polsku nazwać
>> Ciekawe ile maili dostajesz dziennie z tych desktopów? I czy je czytasz w
>> ogóle? Ile procent "awarii" łapiesz przez te maile?
>
> Około 90%. Wyjątkami mogą być awarie systemów pocztowych i sysloga,
> które zdarzają się tylko przy bardzo intensywnej rekonfiguracji (tj.
> przy pracach nad systemem powiadamiania).
A że pani krysi nie otwierają się doc'e w przeglądarce tez wyłapujesz? Czy
to nie jest "awaria"?
>
>> Mają problem to się logujesz mu na kompa dzięki AD.
>
> Active Directory pod Linuksem? Ciekawe jak.
Ale openldap jest.
>
>>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
>> Zdefiniuj normalność.
>
> Dla przypomnienia:
>
>>>> Masz za zadanie administracje wszystkimi desktopami
>>>> w firmie?
>>>
>>> Nie, skądże. Stacje robocze nie wymagają dozoru, same o siebie dbają
>>> i rozwiązują problemy użytkowników.
>>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
>
> Odwróćmy twoje pytanie. Z jakimi sieciami miałeś do czynienia że
> uważasz[*], że desktopami się nie administruje?
>
> [*] To przynajmniej sugeruje twoje pytanie, które odbieram jako
> zdziwienie, że tym w ogóle trzeba się zajmować.
>
Jako desktopy pół na pół xp z domieszką,2000,visty i linuksy różnej maści.
Wolność wyboru co tam każdy woli. Firma programistyczna więc większość osób
wie co robi.
Stachu 'Dozzie' K.
> Stachu 'Dozzie' K. naklepał:
>
>
>> Exim jest dostatecznie lekki żeby nie musieć rozważać jakichś ułomnych
>> implementacji SMTP.
>
> bardziej trafia do mnie argument ze spoolerem czy jak to po polsku nazwać
Nigdy nie używałem częściowych implementacji SMTP i kolejkowanie jest
dla mnie oczywiste, to i nie pamiętam że jego brak w ogóle mógłby być
problemem.
>>> Ciekawe ile maili dostajesz dziennie z tych desktopów? I czy je czytasz w
>>> ogóle? Ile procent "awarii" łapiesz przez te maile?
>>
>> Około 90%. Wyjątkami mogą być awarie systemów pocztowych i sysloga,
>> które zdarzają się tylko przy bardzo intensywnej rekonfiguracji (tj.
>> przy pracach nad systemem powiadamiania).
> A że pani krysi nie otwierają się doc'e w przeglądarce tez wyłapujesz? Czy
> to nie jest "awaria"?
Przynajmniej będę wiedział że wstały iksy. To już jest dużo.
>>>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
>>> Zdefiniuj normalność.
>>
>> Dla przypomnienia:
>>
>>>>> Masz za zadanie administracje wszystkimi desktopami
>>>>> w firmie?
>>>>
>>>> Nie, skądże. Stacje robocze nie wymagają dozoru, same o siebie dbają
>>>> i rozwiązują problemy użytkowników.
>>>> Nie miałeś nigdy styczności z normalną siecią firmową, prawda?
>>
>> Odwróćmy twoje pytanie. Z jakimi sieciami miałeś do czynienia że
>> uważasz[*], że desktopami się nie administruje?
>>
>> [*] To przynajmniej sugeruje twoje pytanie, które odbieram jako
>> zdziwienie, że tym w ogóle trzeba się zajmować.
>>
> Jako desktopy pół na pół xp z domieszką,2000,visty i linuksy różnej maści.
> Wolność wyboru co tam każdy woli. Firma programistyczna więc większość osób
> wie co robi.
Ile jest firm zatrudniających prawie samych informatyków? Ile jest
firm mających niewielką ilość informatyków, a komputerów kilkadziesiąt
i więcej? Czy w takich firmach administrować komputerami nie trzeba, czy
może użytkownicy się tym zajmą sami?
edek
Kajetan Staszkiewicz
W lepszym świecie masz kilkadziesiąt maszyn, za których utrzymanie ci płacą.
I wtedy chcesz móc zrobić na wszystkich `yum upgrade kernel\*`, gdy w
kernelu jest dziura, a nie kernelować kompila i balsować alsę.
--
| pozdrawiam / greetings | powered by Centos, Gentoo and FreeBSD |
| Kajetan Staszkiewicz | jabber,email,www: vegeta()tuxpowered net |
| Vegeta | IMQ devnames: http://tuxpowered.net |
`------------------------^------------------------------------------'
Konrad Kosmowski
>> Próbowałeś kiedyś wymieniać kabel zasilający w komputerze? Audiofile od
>> razu słyszą różnicę.
> Nie przejmuj się. Ze mnie też się śmiali jak pisałem, że samodzielnie
> skompilowane jajo jest szybsze od firmowego.
Konkretnie w czym jest szybsze i o ile?
> Po prostu są tacy co nigdy nie wyściubili nosa poza firmowe binarki i nie
> mają pojęcia, że gdzieś tam jest lepszy świat oparty o źródełka (nie tylko
> gentoo).
Wiesz są i tacy, którym kernele to z ręki jedzą tylko po prostu poza *bardzo*
*specyficznymi* środowiskami to nie ma najmniejszego sensu. Ew. zysk z takiej
kompilacji jest w większości przypadków kwestią pomijalną, za to dochodzi Ci od
groma więcej utrzymania. Tzn. może nie tak jakoś aż strasznie dużo utrzymania
bo w sumie sobie robisz pakiet i puszczasz, ale zawsze musisz go zrobić, jak
się jeszcze okaże, że masz kilka platform do obsłużenia to masz więcej
gmerania, potem się okaże, że są różne sprzęty i finalnie wyjdzie Ci albo masa
grzebania albo coś i tak de facto gorszego od tego co jest w dystrybucji. :)
Ile widziałeś systemów, w których własnoręczna kompilacja cokolwiek zmieniała?
I na ile to były specyficzne (jakie) systemy? Możesz rzucić jakieś case study?
:) Co Oracle lepiej orał? A supportu nie żal? :P
--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK
Bartosz Feński aka fEnIo
>>>> Mówisz jak początkujący użytkownik Ubuntu. Ale jeśli chcesz możesz sam
>>>> sobie obalić tę tezę. Postaw sobie ubuntu i przekompiluj jądro
>>>> dystrybucyjne pod sprzęt jaki tam jest. Różnica jest odczuwalna gołym
>>>> okiem.
>>>
>>> Próbowałeś kiedyś wymieniać kabel zasilający w komputerze?
>>> Audiofile od razu słyszą różnicę.
>>
>> Nie przejmuj się. Ze mnie też się śmiali jak pisałem, że samodzielnie
>> skompilowane jajo jest szybsze od firmowego. Po prostu są tacy co nigdy
>> nie wyściubili nosa poza firmowe binarki i nie mają pojęcia, że gdzieś tam
>> jest lepszy świat oparty o źródełka (nie tylko gentoo).
>
> W lepszym świecie masz kilkadziesiąt maszyn, za których utrzymanie ci płacą.
> I wtedy chcesz móc zrobić na wszystkich `yum upgrade kernel\*`, gdy w
> kernelu jest dziura, a nie kernelować kompila i balsować alsę.
Zgadzam się co do tego, że kilka(naście/set) maszyn prościej utrzymać mając
wspólne repozytorium albo przynajmniej binarki, ale traktowanie tego jako
argument przeciw kompilacji jest już lekkim nadużyciem.
Zazwyczaj mając pod opieką circa about 100 serwerów ma się już swoje
repozytorium, a wtedy jednokrotna kompilacja i 100 instalacji nie jest już
jakimś problemem.
pozdr,
fEnIo
--
,''`. Bartosz Fenski | mailto:fe...@debian.org | pgp:0x13fefc40 | irc:fEnIo
: :' : 32-050 Skawina - Glowackiego 3/15 - malopolskie v. - Poland
`. `' phone:+48602383548 | proud Debian maintainer and user
`- http://fenski.pl | xmpp:fe...@jabber.org | rlu:172001
Łukasz D.
>
> Przynajmniej będę wiedział że wstały iksy. To już jest dużo.
>
śmiem twierdzić że dużo wcześniej dowiesz się o tym że Xsy nie wstały od
zainteresowanego telefonicznie lub personalnie.
>> Jako desktopy pół na pół xp z domieszką,2000,visty i linuksy różnej
>> maści. Wolność wyboru co tam każdy woli. Firma programistyczna więc
>> większość osób wie co robi.
>
> Ile jest firm zatrudniających prawie samych informatyków? Ile jest
> firm mających niewielką ilość informatyków, a komputerów kilkadziesiąt
> i więcej? Czy w takich firmach administrować komputerami nie trzeba, czy
> może użytkownicy się tym zajmą sami?
>
Wszystko zależy od potrzeb i możliwości.
Stachu 'Dozzie' K.
>>> Jako desktopy pół na pół xp z domieszką,2000,visty i linuksy różnej
>>> maści. Wolność wyboru co tam każdy woli. Firma programistyczna więc
>>> większość osób wie co robi.
>>
>> Ile jest firm zatrudniających prawie samych informatyków? Ile jest
>> firm mających niewielką ilość informatyków, a komputerów kilkadziesiąt
>> i więcej? Czy w takich firmach administrować komputerami nie trzeba, czy
>> może użytkownicy się tym zajmą sami?
>>
> Wszystko zależy od potrzeb i możliwości.
Tylko ty twierdziles, ze desktopami nie ma po co administrowac,
a przynajmniej tak mozna bylo odebrac twoje pytanie "a musisz sie tym
w ogole opiekowac?".
Łukasz D.
Nie znam twoich odgórnych wytycznych. Jeśli musisz to robić ok ale jak dla
mnie mail o tym że iksy się podniosły to jest zboczenie.
Nie myślałeś o LTSP zamiast tych desktopów?
Maciej Piechotka
> Stachu 'Dozzie' K. naklepał:
>
>
>>
>> Przynajmniej będę wiedział że wstały iksy. To już jest dużo.
>>
> śmiem twierdzić że dużo wcześniej dowiesz się o tym że Xsy nie wstały od
> zainteresowanego telefonicznie lub personalnie.
>
Sądząc po tym co obserwuję[1] to dowiem się, że internet nie działa albo
komputer nie działa...
Pozdrawiam
[1] Czytaj - to co sam przeżywam (w domowej pomocy technicznej ;) ) + to co
słyszę w internecie ;)
Stachu 'Dozzie' K.
A kto mówi o wysyłaniu maila o błędzie przy iksach? Ale same logi
z podnoszenia iksów bywają bardzo pomocne.
> Nie myślałeś o LTSP zamiast tych desktopów?
Nie wiem czy widziałeś na oczy LTSP albo czy liczyłeś koszty. To wymaga
przyzwoitego serwera, a tanie nowe terminale bezdyskowe dość ciężko
teraz kupić.
Zresztą wcale nie powiedziałem że mam pod opieką *dziesiąt desktopowych
Linuksów (fakt, nie zaprzeczyłem temu jawnie, ale na pewno nigdzie nie
potwierdziłem). Po prostu bzdurą jest twierdzenie, że desktopami nie ma
w ogóle potrzeby się zajmować.
Krzysztof Halasa
> Nie wiem czy widziałeś na oczy LTSP albo czy liczyłeś koszty. To wymaga
> przyzwoitego serwera, a tanie nowe terminale bezdyskowe dość ciężko
> teraz kupić.
Nikt normalny nie uzywa LTSP ze wzgledu na koszty terminali
bezdyskowych. Roznica w kosztach jest w bezdyskowosci ->
administracji, backupach, bezpieczenstwie, mobilnosci, jednolitej
konfiguracji itd.
Z przyzwoitym serwerem teraz jest mniej klopotu niz kiedys (np. 4 x
opteron X2 + np. 16 GB RAM mozna kupic zupelnie tanio, a athlona X2
z 8 GB RAM, ktory wciaz udzwignie spore obciazenie, mozna miec za
"grosze", przeciez mozna takich uzyc wiecej niz 1). Nawet kiedys, a
tym bardziej teraz uklad z LTSP mogl byc duzo korzystniejszy niz
"normalne" desktopy.
(Piszac LTSP mam na mysli w ogole terminale bezdyskowe z X11 itd,
samego konkretnego LTSP nigdy nie uzywalem).
--
Krzysztof Halasa
Tomasz Chmielewski
(...)
> Ile widziałeś systemów, w których własnoręczna kompilacja cokolwiek zmieniała?
> I na ile to były specyficzne (jakie) systemy? Możesz rzucić jakieś case study?
> :) Co Oracle lepiej orał? A supportu nie żal? :P
Np. Debianowe jadro (czy ogolnie kazde inne z okresu 2.6.18 +/- ~0.0.2
czy nizej) praktycznie nie nadaje sie do uzytku na cos wiecej niz prosty
serwerek SAN z kilkoma snapshotami LVM.
--
Tomasz Chmielewski
http://wpkg.org
Łukasz D.
> A kto mówi o wysyłaniu maila o błędzie przy iksach? Ale same logi
> z podnoszenia iksów bywają bardzo pomocne.
>
no to się kolego plączesz z zeznaniach
kilka dnie wcześniej napisałeś cos takiego:
>>> Około 90%. Wyjątkami mogą być awarie systemów pocztowych i sysloga,
>>> które zdarzają się tylko przy bardzo intensywnej rekonfiguracji (tj.
>>> przy pracach nad systemem powiadamiania).
>> A że pani krysi nie otwierają się doc'e w przeglądarce tez wyłapujesz?
>>Czy to nie jest "awaria"?
>Przynajmniej będę wiedział że wstały iksy. To już jest dużo.
Mowa była o mailach z desktopu jakie otrzymujesz. Więc jeśli twierdzisz ze
wiesz że iksy wstały to musisz dostawać o tym maile. Inaczej możesz tylko
zakładać że wstały. Same logi i tak oglądasz na maszynie nie przez maile.
>> Nie myślałeś o LTSP zamiast tych desktopów?
>
> Nie wiem czy widziałeś na oczy LTSP albo czy liczyłeś koszty. To wymaga
> przyzwoitego serwera, a tanie nowe terminale bezdyskowe dość ciężko
> teraz kupić.
przyzwoity serwer <20000 zł
sporo desktopów potrafi pracować jako terminal. I zdefiniuj "tanie"
spokojnie zmieścisz się poniżej 1000zł/st w dodatku jak kupujesz dużo to
masz zniżki.
Zalety:
Szybkość aplikacji typu openoffice firefox bezkonkurencyjna. Zarządzanie
scentralizowane. Mobilność stanowiska i jego unifikacja. Możliwość
redundancji. Większe bezpieczeństwo aktualizacji.I jeszcze pewnie kilka.
Wszystko zależy od zastosowania.
Na 5 się nie opłaci ale nad 50 już bym się zastanowił. weź jeszcze poprawkę
na specyfikę używanych programów.
>
> Zresztą wcale nie powiedziałem że mam pod opieką *dziesiąt desktopowych
> Linuksów (fakt, nie zaprzeczyłem temu jawnie, ale na pewno nigdzie nie
> potwierdziłem). Po prostu bzdurą jest twierdzenie, że desktopami nie ma
> w ogóle potrzeby się zajmować.
>
no to nad iloma? dwoma? jeden w domu, drugi w pracy?
Zajmować się trzeba i desktopami, tak samo jak drukarką xerem switchem hubem
telefonem oraz wszystkim co działa na baterie lub da się podłączyć do sieci
energetycznej.
Nie próbuj traktować desktopa jak serwera.
Stachu 'Dozzie' K.
>>> Nie myślałeś o LTSP zamiast tych desktopów?
>>
>> Nie wiem czy widziałeś na oczy LTSP albo czy liczyłeś koszty. To wymaga
>> przyzwoitego serwera, a tanie nowe terminale bezdyskowe dość ciężko
>> teraz kupić.
> przyzwoity serwer <20000 zł
> sporo desktopów potrafi pracować jako terminal. I zdefiniuj "tanie"
> spokojnie zmieścisz się poniżej 1000zł/st w dodatku jak kupujesz dużo to
> masz zniżki.
Ile taki przyzwoity serwer za 20kPLN uciągnie jednoczesnych sesji? Dla
porównania, pojedyncze desktopy kosztują po 2000zł za sztukę, w tym
monitor. I dolicz zniżki gdy kupujesz dużo. Na razie nie bierzemy pod
uwagę aplikacji typu CAD (tego mam dość dużo) i Excela (OO Calc jest
jeszcze za słaby przy tabelach przestawnych żeby w ogóle go rozważać).
[...]
> Wszystko zależy od zastosowania.
> Na 5 się nie opłaci ale nad 50 już bym się zastanowił. weź jeszcze poprawkę
> na specyfikę używanych programów.
>> Zresztą wcale nie powiedziałem że mam pod opieką *dziesiąt desktopowych
>> Linuksów (fakt, nie zaprzeczyłem temu jawnie, ale na pewno nigdzie nie
>> potwierdziłem). Po prostu bzdurą jest twierdzenie, że desktopami nie ma
>> w ogóle potrzeby się zajmować.
>>
> no to nad iloma? dwoma? jeden w domu, drugi w pracy?
> Zajmować się trzeba i desktopami, tak samo jak drukarką xerem switchem hubem
> telefonem oraz wszystkim co działa na baterie lub da się podłączyć do sieci
> energetycznej.
> Nie próbuj traktować desktopa jak serwera.
Nie ja wyrażałem zdziwienie że trzeba się w ogóle zajmować desktopami,
więc nie próbuj mnie pouczać w tej dziedzinie, dziękuję bardzo.
Artur Frydel
> to juz zależy od zastosowania, start serwera 30 sekund krócej pominąć. start
> desktopa 30 sekund krócej to juz jest warte zachodu
>>
Bo na desktopach to się stosuje taki wynalazek jak hibernacja...
--
Artur 'Bzyk' Frydel | artur.frydel[at]gmail-dot-com
"Always look on the bright side of life."
Artur Frydel
> można tylko czy osiągniesz 15s do prompta (bez xów) na dystrybucyjnym
> kernelu?
U mnie 8s. Od startu gruba do otrzymania pulpitu w włączonym KDE.
Zygfryd Homonto
On Wed, 5 Mar 2008 09:33:38 +0000 (UTC)
Artur Frydel <bz...@bzyk.dyndns.org> wysmażył poniższe:
>U mnie 8s.
:-)
--
Zygfryd Homonto
zyghom(AT)yahoo.co.uk
http://photo.janik.es
Janusz Kastyk
> Łukasz D wrote:
>
> > można tylko czy osiągniesz 15s do prompta (bez xów) na
> > dystrybucyjnym kernelu?
>
> U mnie 8s. Od startu gruba do otrzymania pulpitu w włączonym KDE.
Phi. U mnie w momencie wciśnięcia przycisku POWER pojawia się KDE, w
którym odpala się zdziwiony BIOS, a GRUB oznajmia w logach, że czuje się
niepotrzebny i ma kompleksy.
;)
--
Janusz Kastyk