Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
647
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:24)
Offline
Różnica jest taka, że w Openboksie praktycznie niczego nie będziesz miał, więc te benchmarki będą zależały od tego co do niego dołożysz.
Ja nigdy nie zauważyłem różnicy w wydajności pomiędzy takimi menedżerami okien, ale w benchmarki się nie bawiłem.
Raczej wybierz ten, który Tobie będzie pasował (możliwości, obsługa, sposób konfiguracji itp) niż na podstawie jakichś laboratoryjnych różnic w szybkości działania.
Chyba, że testy będą się znacząco różniły.
Offline
649
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:26)
Offline
[quote=uzytkownikubunt]BTW Czy cairo-compmgr da się jeszcze używać? Nie mam takiej paczki w repozytorium 14.04 a podczas kompilacji z kodu źródłowego dostaję mnóstwo błędów. Rozwój wydaje się być całkowicie zawieszony.[/quote]
Brakuje mu tego:
vala-1.0 >= 0.7.10) were not met: No package 'vala-1.0' found
Offline
[quote="uzytkownikubunt"]BTW Czy cairo-compmgr da się jeszcze używać?[/quote]
Da się spokojnie tylko trzeba libvala z ubuntu zaciągnąć
http://www.debian.pl/entries/278-efekty-pulpitu-w-LXDE-przy-u%C5%BCyciu-Cairo-Composite-Managera
Ostatnio edytowany przez menel (2014-04-09 14:37:50)
Offline
Porównanie apetytu na ram
[img]http://l3net.files.wordpress.com/2014/02/cmp-all4.png?w=625&h=617[/img]
[url=http://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/]źródło[/url]
Offline
[quote=menel]Da się spokojnie tylko trzeba libvala z ubuntu zaciągnąć
http://www.debian.pl/entries/278-efekty-pulpitu-w-LXDE-przy-u%C5%BCyciu-Cairo-Composite-Managera[/quote]
Na Debianie 6.0 się poprawnie kompiluje. Jakby ktoś chciał pakiety pisać.
Offline
[quote=Kaleson]Porównanie apetytu na ram
[url]http://l3net.files.wordpress.com/2014/02/cmp-all4.png?w=625&h=617[/url]
[url=http://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/]źródło[/url][/quote]
A co to ma wspólnego z wydajnością?
http://forum.dug.net.pl/viewtopic.php?pid=251184#p251184
Offline
[quote=yossarian][quote=Kaleson]Porównanie apetytu na ram
[url]http://l3net.files.wordpress.com/2014/02/cmp-all4.png?w=625&h=617[/url]
[url=http://l3net.wordpress.com/2013/03/17/a-memory-comparison-of-light-linux-desktops/]źródło[/url][/quote]
A co to ma wspólnego z wydajnością?
http://forum.dug.net.pl/viewtopic.php?pid=251184#p251184[/quote]
Wydajność ma związek z ilością zużytych zasobów sprzętowych min. CPU i ramu. Jeżeli dany wm będzie minimalnie obciążał procesor i przy tym całkowicie zapcha ram to nie będzie wydajny.
Niestety nie wpadłem jeszcze na podobne porównanie obciążenia procka ;) ale strzelam, że w tym przypadku różnice pomiędzy wm'ami nie są spektakularnie duże
Ostatnio edytowany przez Kaleson (2014-04-09 16:48:05)
Offline
Ale ramu nie zapcha, bo to kernel zarządza pamięcią, i jak jakiś program zechce więcej, niż mu kernel przyzna, to dostanie w dziób.
Żeby zapchać skutecznie RAM, trzeba mieć uprawnienia roota, a te wszystkie liby środowiska graficznego wczytywane są przez programy działające w przestrzeni użytkownika.
Linux to nie jest Windows, żeby mu się ram zapychał, np jak kiedyś spróbowałem odpalić stare Ubuntu z LiveCD na kompie ze 128 MB Ram, to w ogóle środowisko graficzne nie wstało, bo nie dostało przydziału pamięci, ale konsola chodziła normalnie.
@Kaleson
Zamiast bzdury wypisywać, to lepiej sobie te kalesony wypierz. ;)
Offline
[quote=Jacekalex]Zamiast bzdury wypisywać, to lepiej sobie te kalesony wypierz. ;)[/quote]
:D
Offline
@Jacekalex Sprawdź sam - uruchom Chromium z 20-30 kartami na KDE i np. JWM (najlepiej na kompie <2GB ram). Różnica jest spora, mimo że procek jest podobnie obciążony. Wina nie leży oczywiście w KDE, ale moim zdaniem środowisko powinno być jak najbardziej transparentne dla aplikacji i przez to wydajne.
PS. Co do kalesonów, to piorę tylko w Vizir
[img]http://userserve-ak.last.fm/serve/126/78170398.gif[/img]
Ostatnio edytowany przez Kaleson (2014-04-09 17:17:22)
Offline
@Kaleson:
To tak nie działa.
W KDE/GNOME mogę mieć 120-150 MB zużytego Ramu i będzie działał wolniej niż taki RazorQT czy Openbox z 3 GB zajętego.
Nie ma żadnej liniowej zależności między zużyciem pamięci, a szybkością działania systemu.
Nie chce mi się już rozpisywać, więc będzie krótko: ten Twój obrazek nie ma nic wspólnego z wydajnością.
No i najważniejsza sprawa. Do bibliotek w Ramie jest szybszy dostęp niż do tych samych bibliotek wczytywanych z dysku.
Offline
[b]Kaleson[/b] mają rację tyż kiedyś myślałem błędnie ale to nie łindołs tu całkowicie inne zarządzanie pamięcią jest...Mi komp nawet wydajnie chodzi jak zajmuje 900/992 ramów..dopiero jak wchodzi powyżej i zacznie swapować zaczyna spadać wydajność..
Ostatnio edytowany przez menel (2014-04-09 17:31:03)
Offline
Poza „zwykłym użyciem“ sporo Ramu Linux używa na cache:
[b]What's going on?[/b]
Linux is borrowing unused memory for disk caching. This makes it looks like you are low on memory, but you are not! Everything is fine!
[b]Why is it doing this? [/b]
Disk caching makes the system much faster! There are no downsides, except for confusing newbies. It does not take memory away from applications in any way, ever!
[b]What if I want to run more applications?[/b]
If your applications want more memory, they just take back a chunk that the disk cache borrowed. Disk cache can always be given back to applications immediately! You are not low on ram![/quote]
http://www.linuxatemyram.com/
Zapamiętaj sobie: „Disk caching makes the system much faster! There are no downsides, except for confusing newbies.” ;)
Offline
Ja jakiś program zaczyna brać za dużo ramu, to można go obciąć przez cgroup, albo odpalić z programem, który po przypilnuje - softlimit z pakietu daemontools.
Faktem natomiast jest, że niektóre programy, wstają i działają na kompie z 1GB ram, a na kompie z 16G ram zajmują sobie z 5GB albo 10 GB na dzień dobry.
Inna sprawa, to zależność użycia RAM od "ekosystemu" czyli zmiennych i sterowników danego systemu operacyjnego, np sławny błąd z Cairo i sterami Nvidii, gdzie każdy program na sterach Nvidii zajmował 2x więcej ramu, niż normalnie.
Jest też problem z Fraknkensteinem znanym jako Xorg, który ma podobno około 130 interfejsów komunikacyjnych, działa z uprawnieniami roota, i u mnie kiedyś po uruchomieniu Chrome dostawał kataru, i w kilka minut zajmował sam 1GB ram, a mniejsze i większe wycieki pamięci w Xorgu, to standard, i każdy program może uszkodzić sesję Xów.
Dlatego z takim utęsknieniem czekam na Waylanda, że z Xorgiem 1.12, 1.13 i 1.14 już miałem takie cyrki, że nikomu podobnych nie życzę.
Ostatnio edytowany przez Jacekalex (2014-04-09 17:52:37)
Offline
Tak, wszyscy macie rację ;) Jednak dalej uważam że porównanie wykorzystania ramu jest dobrym wskaźnikiem, bardzo dokładnie pokazuje które rozwiązanie jest bloat'em a które jest lekkie.
[quote=yossarian]Zapamiętaj sobie: „Disk caching makes the system much faster! There are no downsides, except for confusing newbies.” ;)[/quote]
No comment. Naprawdę nie wiem, jaki to ma związek z tematem. Zawsze czytam ram z wiersza "-/+ buffers/cache:"
Offline
[quote=Kaleson]Tak, wszyscy macie rację ;) Jednak dalej uważam że porównanie wykorzystania ramu jest dobrym wskaźnikiem, bardzo dokładnie pokazuje które rozwiązanie jest bloat'em a które jest lekkie.[/quote]
Bzdura. Dokładne to mogą być wyniki laboratoryjnych testów.
Wystarczy spojrzeć na pasek przy RazorQt lub Cinnamon by się przekonać że ten wykres jest bez sensu.
Użycie Ramu zależy od wielu czynników systemowych, sprzętu i jego sterowników, użytych bibliotek etc. Nawet same środowiska graficzne różnie wykorzystują pamięć na komputerach z różną jej ilością.
[quote=yossarian]Zapamiętaj sobie: „Disk caching makes the system much faster! There are no downsides, except for confusing newbies.” ;)[/quote]
No comment. Naprawdę nie wiem, jaki to ma związek z tematem. Zawsze czytam ram z wiersza "-/+ buffers/cache:"[/quote]
To tylko dowód na to, że sam system zużywa znacznie więcej pamięci niż się na pierwszy rzut oka wydaje, a i tak działa szybciej.
Celem systemu jest jak najefektywniejsze działanie, a nie jak najmniejsze zużycie (bezużytecznej w innym przypadku) pamięci.
Offline
650
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:49:27)
Offline
Ale jednak na kde średnio się gra w TF2 na 4 gb RAM.
Gdy mi wczyta kilka modów pobieranych z serwerów, lubi mi robić OOMC. Na lekkich managerach okien też się trafia gdy zapomnę wyłączyć przeglądarki.
Offline
[quote=Red_Fedora]Ale jednak na kde średnio się gra w TF2 na 4 gb RAM.
Gdy mi wczyta kilka modów pobieranych z serwerów, lubi mi robić OOMC. Na lekkich managerach okien też się trafia gdy zapomnę wyłączyć przeglądarki.[/quote]
Po prostu KDE i GNOME wymagają więcej zasobów do wydajnego działania niż taki Fluxbox lub LXDE.
Gry i dzisiejsze przeglądarki również.
Pytanie w tym wątku było takie:
[quote=uzytkownikubunt]Ciekawy jestem, czy jakieś opcje w plikach konfiguracyjnych Fluxboksa, Openboksa i FVWMa albo parametry dla Comptona lub Xcompmgra mają wpływ zauważalny wpływ na wydajność aplikacji graficznych odpalonych pod X-ami.[/quote]
i żadne bezsensowne obrazki pokazujące użycie pamięci (szczególnie w jakichś zupełnie nienaturalnych warunkach) na to nie odpowiedzą.
Offline
[quote=yossarian]i żadne bezsensowne obrazki pokazujące użycie pamięci (szczególnie w jakichś zupełnie nienaturalnych warunkach) na to nie odpowiedzą.[/quote]
Ta, dokładnie. Takie rzeczy najlepiej przetestować na własnej skórze i działać zgodnie z praktyką "działa szybciej to ciesz się i milcz". A fakt że to się przeważnie pokrywa ze zużyciem RAMu można pominąć :)
Ostatnio edytowany przez Kaleson (2014-04-09 20:02:52)
Offline
[quote=Kaleson][quote=yossarian]i żadne bezsensowne obrazki pokazujące użycie pamięci (szczególnie w jakichś zupełnie nienaturalnych warunkach) na to nie odpowiedzą.[/quote]
Ta, dokładnie. Takie rzeczy najlepiej przetestować na własnej skórze i działać zgodnie z praktyką "działa szybciej to ciesz się i milcz". A fakt że to się przeważnie pokrywa ze zużyciem RAMu można pominąć :)[/quote]
Tu masz wyniki używania:
http://forum.dug.net.pl/viewtopic.php?pid=251186#p251186
http://forum.dug.net.pl/viewtopic.php?pid=251189#p251189
http://forum.dug.net.pl/viewtopic.php?pid=251193#p251193
EOT.
Offline
Disk caching makes the system much faster![/quote]
Ten co to pisał, ssie. Może i to się sprawdza na 16GiB ramu, gdzie 3/4 jest niewykorzystana. Wystarczy używać kompa tak by cały ram zjadł i ten pieprzony cache nawet mnicha z równowagi wyprowadzi. :] Mnie po prostu szlag trafia jak podczas kopiowania, linux uważa, że lepiej wszystkie dane z ramu wrzucić do swap by zrobić miejsce na cache pod kopiowane pliki...np sławny błąd z Cairo i sterami Nvidii, gdzie każdy program na sterach Nvidii zajmował 2x więcej ramu, niż normalnie.[/quote]
To jest błąd? Nie wydaje mi się.Jednak dalej uważam że porównanie wykorzystania ramu jest dobrym wskaźnikiem, bardzo dokładnie pokazuje które rozwiązanie jest bloat'em a które jest lekkie.[/quote]
Jak masz mało ramu, tak jak ja, to może ci się to do czegoś przydać. Ale człowiek na przeciętnej maszynie nawet nie zauważy różnicy. Poza tym mój openbox zjada 220 MiB na starcie, także może lepiej zacznę używać KDE? xDOffline
[quote="morfik"]Poza tym mój openbox zjada 220 MiB na starcie[/quote]
łoł co tak duuuuuuuuuużo? łamiesz pentagony jakieś tam?;)
Ostatnio edytowany przez menel (2014-04-09 20:15:19)
Offline
Time (s) | Query |
---|---|
0.00009 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00099 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='52.15.136.223' WHERE u.id=1 |
0.00074 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '52.15.136.223', 1732539469) |
0.00050 | SELECT * FROM punbb_online WHERE logged<1732539169 |
0.00050 | SELECT topic_id FROM punbb_posts WHERE id=262792 |
0.00006 | SELECT id FROM punbb_posts WHERE topic_id=25575 ORDER BY posted |
0.00084 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=25575 AND t.moved_to IS NULL |
0.00007 | SELECT search_for, replace_with FROM punbb_censoring |
0.00421 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=25575 ORDER BY p.id LIMIT 0,25 |
0.00129 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=25575 |
Total query time: 0.00933 s |