Tvikanje Gnu/Linuxa
- poruka: 171
- |
- čitano: 24.448
- |
- moderatori:
pirat, Lazarus Long, XXX-Man, vincimus
obrisano jer nema smisla
obrisano jer nema smisla
- ne nego nitko nema gunse za benchanje. (većina danonoćno hekla source, kao na svakoj sličnoj temi, kad ne razbijaju atome ili ne spašavaju svijet kao F.Gordon).
Hvala što si otvorio zasebnu temu. Benchanje me nikad nije posebno zanimalo ali ako tebe veseli samo naprijed. Pratit ću iz prikrajka.
obrisano jer nema smisla
obrisano jer nema smisla
Svi tvikaju sustave da dobe vise od njih a benchanje nikog ne zanima
Nije tema o benchanju, zove se tvikanje linuxa. ja sam samo benchom htio pokazati ucinkovitost nekih tvikova za pocetak kompajliranje kernela je osnovni tvik u linuxu.
Samo gradnjom dobrog kernela mozemo postici 50% manje zauzeca resursa, i 10% brzi sistem, pokazati to je bio cilj ovog bencha, tema je i dalje tvikanje
OK. Ali trenutno na svim računalima imam 6+ GB RAM-a i ni u jednom trenutku nije se desila situacija da je sav RAM zauzet. Ako ga ima već toliko onda nek se koristi, šteta je da čami i pati jer ne radi ništa. Za mene kompajliranje nije tvikanje, možda sam u krivu ali tako razmišljam. Kad pričamo o kompajliranju, s moje točke gledišta, u startu se trebaš pripremiti na neočekivane probleme i očekivat da ćeš utrošiti više vremena nego si planirao. Ipak, ako složiš dobru kuharicu... Kao što reče hrvooje, godišnji je pravo vrijeme za kompajliranje.
obrisano jer nema smisla
Svi tvikaju sustave da dobe vise od njih a benchanje nikog ne zanima
Nije tema o benchanju, zove se tvikanje linuxa. ja sam samo benchom htio pokazati ucinkovitost nekih tvikova za pocetak kompajliranje kernela je osnovni tvik u linuxu.
Samo gradnjom dobrog kernela mozemo postici 50% manje zauzeca resursa, i 10% brzi sistem, pokazati to je bio cilj ovog bencha, tema je i dalje tvikanje
Što ti je pristup disku tako spor? Vidim da je noviji laptop, ima SATA disk, šta je na 5400? R/W brzine su maltene iste.
Vidis bas zato sto ne kompajliras neces nikad iskoristiti puni potencijal 6gb memorije. (ne da je neces zauzet)
To je previse memorije, meni je i mojih 2gb previse. Ne posznajem osijecaj kako je to kad linux trosi vise od 300mb memorije.
? šta, u idleu? Pa to je zato jer ne radiš ništa na njima.
- prijedlog /molba, bootni neki live-ArtistX (može i posljednji 1.5 ili stariji..) i odvrti isti bench (+ neki od uključenih appsa, rip-convertera..), tek da vidimo usporedbu. To bi bili referentni rezultati na istom HWu.. i tad bi mogli uspoređivati, pametovati..
obrisano jer nema smisla
- prijedlog /molba, bootni neki live-ArtistX (može i posljednji 1.5 ili stariji..) i odvrti isti bench (+ neki od uključenih appsa, rip-convertera..), tek da vidimo usporedbu. To bi bili referentni rezultati na istom HWu.. i tad bi mogli uspoređivati, pametovati..
Zasto da to uopce radim, pa jasno ti je kakvi ce rezultati biti (sporiji nego na archu ako nista drugo jer nije prompt) i na kraju zasto raditi test na livecdu ? kako to moze biti referentno
može... referentno mjerenje je poznata točka.
-odvrti, tad ćemo vidjeti prednosti tweakanja ili nećemo.. ja ne mogu, jer nije isti HW, nemam konkretni file itd. moj benč bi bio neusporediv, dok tvoj znamo da je razlika samo live-vs-install-vs kompilirano-optimizirano.
-live je najsporiji (u trenutku-taskovima kad to ima utjecaja). ŠBB-KBB bench nam može dati odgovore.
obrisano jer nema smisla
Pa to nesto znaci ?
previše razlika s HDDom, nije svejedno koji fizički dio diska se koristi, kao i koji FS, prvi test je s NTFSa (u pravilu brži..), dok posljednji BTov (fuj!), ide na sda9 koji je najsporiji dio.. više me iznenađuje vrijeme +3m.. (btw postoji razlog za ArtistiX, to je Studio/kernel, lowlatency koji se za multimedijalne stvari osjeti, BT nije distra za to).
ako želiš imati relevantna mjerenja tad bi morao koristiti iste FS u testovima, ako već ne particije (mada ne vidim razloga zašto test nebi išao uvjek s istim particijama, pa i sda9 umjesto neke /home..). Disk je jedna od najsporijih komponenata, često usko grlo i mora se s tim računati.
obrisano jer nema smisla
Stavio sam na sda9 jer mi je ta slobodna. Artistx onda ima prompt kernel kao i arch.
Gle razlika izmedju kompajliranog i instaliranog se vidi i livecd uopce ne igra nikakvu ulogu vise osim u hdparm testu jer bi kod livecd taj test trebao biti najbrzi (ne bi li ?) a opet je pokazalo da je cak i brzi u kompajliranoj instalaciji
Mislim da su bilo kakvi testovi dalje suvisni jer ovo dovoljno govori
FSovi su isti i da arch je na particiji odmah prije gentoo, znaci gentoo mora biti sporiji po toj logici dok arch, evo tek nakon kompjaliranja kernela se priblizio njegovim performansama ali jos malo zaostaje cini mi se, a oboje rade na ext4
Nije to velika razlika je li sda6 ili sda7 (eventualno se radi o stotinkama)
Meni se cini da ti ne zelis prihvatiti rezultate testa pa zato trazis neki artist livecd. Znas da ce biti sporiji ali hoces vidjeti da je sporiji i ne znam sto mozes novoga iz toga zakljuciti. Niti nisi znao da su tetstovi radjeni na istim FS-ima kad si govorio da ih trebam raditi na istim FS. Jednostavno kao da ne zelis da kompajlirano ima bolje rezultate ?
Ako je tako slobodno kompajliraj i skidaj deset livecdova da testiras, ja necu. Meni osobno ni ovaj test nije trebao jer razlike se osijete i bez njega u radu sistema, ali odradio sam ga upravo zbog ljudi koji ne zele da kompajlirano bude brze i spremni su te napasti sa svih strana ignorirajuci sav smisao optimizacije u linuxu jer misle da ona ne vrijedi dokle god imaju jak hardware ali varaju se grdo
... zapravo me benčevi ne zanimaju. Možda stvarno 'najvijam' za neku distru ili live.. Ili sam postavio pogrešno pitanje (nervoza?).
-FS nema uticaja? Ima.
-kad natipkaš: ''..nisi nit znao da su testovi (tipfeler..)...'' -varaš se, tvoja prvi slika, mnt/ntfs/... koji je to FS? Nikad (ok, ponekad) ne lupetam napamet. Nemoj ni ti.
-fizička svojstva su nešto što kompajler ne može ignorirati. Svaki HDD je najsportiji na kraju, provjeri bilo kojim transfer testom (max i min razlika je dvostruka), u tvom slučaju normalan transfer do cca 80% diska je cca 40MB/s dok pri kraju mora pasti. Tad tvoj bench možda uopće nije rezultat tvekanja, nego fizičkih svojstava diska (tj negovog transfera) jer je upravo toliki očekivani transfer kraja diska (u testu cca 25MB/s).. Naravno, disk koji imaš je ipak sporiji nego 'normalan' noviji SATA-2/3 ili desktop, tako da ako netko čita ove brojke ne dobije pogrešan dojam, noramalan disk bi dao recimo dvostruko više rezultate ovo je ipak stariji HDD 2.5/5400 te brzine su normalne na tom HWu.
Ako je HDD usko grlo, tad se kernel-CPU razlika se ne može ovim testom provjeriti, jednako ako što sintetika nije RL.
- svaki test je preporuka ponoviti (bar tri puta) jer ... (nije potrebno objašnjavati?), uspoređivanje na različitom HWu ovakvih stvari je možda besmisleno, zato ne benčam jer to nebi bio (dobar) argument za ovu temu, tj optimizaciju, tj dali su razlike mjerljive ili usporedive pa time i zaključak koji bi izveli, dali uopće optmizirati kompiliranjem. Smisao teme je? (zar nije upravo to..).
----
U ovoj temi bit ću negativac, koji kritizira tvoje rezultate... bez tog je nemoguća 'znanstvena' rasprava. Ako pitanja-odgovori, pogotovo testovi s brojkama, prođu taj kritički test, može se reči da si dokazao svoju tvrdnju. Zapravo, navijam za tebe, ovu temu... zato NHF, ništa osobnog.
obrisano jer nema smisla
Pa normalno da ne radim nista na njima zato se i zove idle jer radi sistem i cijeli desktop
Kad radim sve (muzika, filmovi, internet) onda tek trosi 250mb memorije
kad ne radim nista trosi 50-80 mb cijeli sistem (ovisi o desktopu zato je izmedu 50-80)
U ovo ti ne vjerujem koliko si dug i širok, osim ako na internet ne ideš sa lynxom . Browserovo zauzeće memorije ne ovisi o desktop okruženju, nego o web stranici, količini multimedije i skriptama. OK, ako otvoriš samo google, možda. A ako imaš otvoren jedan po jedan program, bez multitaskanja, onda to nije ono čemu linux služi. VLC, Chrome, Firefox, svi oni jedu podosta memorije.
obrisano jer nema smisla
Browserovo zauzece memorije ovisi prije svega o:
Browserovo zauzeće memorije (i zauzeće memorije bilo koje druge aplikacije kad smo već kod toga) ovisi prije svega o tome koliko je dotični zatražio od operacijskog sustava putem neke od funkcija za alokaciju memorije.
Jedino što OS tu može je:
- ne ispoštovati zahtjev za alokacijom memorije, pri čemu će se aplikacija najvjerojatnije srušiti ili prekinuti svoj rad na neki elegantniji način.
- žonglirati sa memorijskim stranicama aplikacije između fizičke memorije i swap memorije.
Browser ponajprije memoriju upotrebljava za pohranjivanje bitmapa, layout stablo, i memoriju koju skripte koriste (+ memoriju koju koristi javascript VM, koja može biti znatna), kernel to ne može nikako ublažiti. Može samo reći "ne, ne dam", pri čemu browser ostaje bez memorije za neki traženi resurs što će se u najmanju ruku odraziti u prikazu stranice...
Otvoriti about:memory stavku u firefoxu, i pronaći išta što bi kernel mogao ublažiti...
obrisano jer nema smisla
Pa ja na slici vidim da ti Firefox koristi 441 MB adresnog prostora.
obrisano jer nema smisla
Memorija se ne troši, ona se alocira. Da, slika pokazuje više od 5 GB alociranog adresnog prostora (ne vidi se ostatak outputa). Koliko se memorijskih stranica doista i nalazi u fizičkom RAM-u je nešto posve drugo.
http://en.wikipedia.org/wiki/Page_%28computer_memory%29
Segmentacija je zastarjela shema koja se više ne koristi u tolikoj mjeri, i ogromna većina operacijskih sustava (uključujući i linux) koristi šačicu defaultnih segment descriptora za sve aplikacije, te se oslanjaju na virtualnu memoriju za odvajanje memorijskih adresnih prostora različitih procesa.