Tvikanje Gnu/Linuxa

Zanemarujem firefox dio jer ionako koristim chrome.

Objasni točno kako se to sustav uspori na tim distribucijama. Što ih to točno uspori? Ja to u svim godinama korištenja linuxa kao primarnog OS-a nisam doživio pa bi molio da me prosvjetliš. Je li možda fragmentacija? A da, nema fragmentacije. Registry? Ah da nema registry-a?

Jedino što može usporiti sustav (i boot) jest trpanje startup aplikacija, widgeta i servisa, ali to se dogodi na bilo kojoj distri pa da joj je i sam Torvalds kompajlirao kernel.

Eto sad ti pokazuješ da ne znaš osnove linuxa kako ti drugima voliš govoriti. Uostalom neš ti znanja odabirati flagove prilikom kompilacije.

U vasionu  Raspao se od smijeha.

Nije samo u Mozilli, GCC ARM EABI verzija 4.8.2 ne radi dobro na O3 i Os (arhitektura ARMv7, CPU je Cortex-M3). Nekada funkcionira kao da uzmeš nekakve nasumične binarne brojeve i ideš to pokrenuti. Te razine optimizacije sada nazivam "Nek' ih Bog razvrstava".

Ako zanemarim kako me tema na prvi pogleda asocira na - bradata žena, čovjek topovska kugla, proricanje iz kristalne kugle, slon koji balansira na jednoj nozi - nekakva mala ubrzanja ovisno o svičevima možeš dobiti ako je autor aplikacije znao da se zbog-tog-i-tog razloga mogu npr. koristiti SIMD instrukcije, pa je to i predvidio u kodu. Ili ako imaš nekakvu perverziju od koprocesora koji treba dodatno aktivirati. No i tu ima razlika između istog koda koji je kompajliran za x86 i nešto drugo. Barem sam ih imao na Cortex-A8 i dvoglavom Intel Atomu.

No, zato ljudi, kompajlirajmo, reče zaposlenik HEP-a.

Idem po kantu masti za vodove.

Ta aplikacija treba 8kb prostora po defaultu ali tebi ce uvijek za to uzeti 16kb jer je procesor koji operira memorijom preopterecen zbog neoptimizacije.

usporedbe kernela su ti bile odmah na prvoj stranici a ti cekaj i dalje nesto sto ne znas ni sam sto

Neki ljudi ce jednostavno ostati u windows nacinu rada i u svakom osu ce razmisljati na windows nacin, tako da cijela ova tema nema smisla

procitaj gcc link koji sam ti dao i tamo ti pisu sve instrukcije, i to ti je tesko, lakse je spamati temu i derati po svome

Ovdje treba linux moderator da vas sve pobanira zbog trolanja i davljenja pitanjima kako 2+2 moze biti 4 kad vi mislite da je 5

i da to napravim opet bi bilo uzaludno jer bi ti derao svoje teorije (gluposti)  koje nemaju veze s pameti

Sto je bilo ? problem nerazumjevanja objasnjenja na gcc stranici ? Sve ti tamo lijepo pise, ti ne protivis meni nego gcc developerima

daj odabi vise, popeo si mi se znas gdje

Optimizing Linux Memory usage

-Recompiling the Kernel

-Compiling Applications

(nazalost ni autor linka nije dobro upucen u ove dvije stavke koje je naveo)

Sramite se svi kakvi ste linux nubovi.

To su kriva vremena kad linux moze instalirati svaka budala u 3 klika, a onaj ko zna kopirati i instalirati u terminalu se smatra nekim advanced userom. Da smo u devedesetima sutili biste ko picke a sad tu nesto glumite da znate

I pristup temi vam je los, da pitate sve bi se objasnilo ali ne pitate nego flejmate svojim neznanjem maskirajuci ga kao znanje (koje ste stekli koristeci windows)

Rusty, ne trolaj, dao sam ti link i uci nesto ako te nre zanima ne znam sta imas raditi u ovoj temi

S obzirom da ne možeš sročiti pošten odgovor, budući da vrlo vjerojatno ne razumiješ materiju ja ću se još jednom osvrnuti na ovaj citat:

"Overhead" o kojem ti vjerojatno pričaš zapravo nije overhead. Ti zapravo pričaš o tranformacijama na programskom kodu kojima se neke instrukcije uklanjanju a neke druge dodaju. Odnosno pričaš o najobičnijim optimizacijskim tranformacijama koje radi gotovo svaki kompajler a koje opisuješ svojom uvrnutom terminologijom.

I ne, ušteda (memorijska) koju dobiješ tim putem je na desktopu zanemariva, štoviše unrollanje, inlining i slične transformacije će ti i povećati konačni executable. No to je primarno poradi ubrzavanja izvršavanja (unrollanje petlji umanjuje uvjetno grananje, inlining eliminira overhead poziva funkcija...). Os provodi samo skup tranformacija koje za cilj imaju ili umanjiti ili barem ne uvećati konačni strojni kod.

Možeš se eventualno žaliti da veći kod više udara instrukcijski keš procesora. Ali bez opsežnih testova to je nategnuto samo tako dovoditi u korelaciju sa lošim perfomansama. Podatkovni keš je generalno govoreći bitniji.

Gušenje pipelinea mi nije jasno ni malo. Pipeline je u pravilu uvijek pun, osim ako ne dođe do flusha (što se smatra lošim za perfomanse, iz očiglednog razloga, jer se pipeline ponovno treba napuniti).

Svaki proces ima vlastiti adresni sustav koji se uništi nakon što i proces bude ubijen, te se kreira svježi kada proces nastaje. Svaka fragmentacija adresnih prostora pojedinih procesa pri tome potpuno nestaje. A i to ovisi o prirodi samog procesa, nešto sa statičnim spremnicima ti sigurno neće fragmentirati vlastiti adresni prostor.

I ne, memorijska fragmentacija je problem uglavnom zbog nemogućnosti alociranja kontinuiranog bloka memorije određene veličine, manje zbog perfomansi (svatko tko se doveo u situaciju da mu perfomanse vise o tome koliko malloc/free brzo rade si je sam kriv zbog toga). Kada malloc uslijed masovnih alokacija raznih veličina iskasapi memorijski adresni prostor, postaje problem naći dovoljno veliki komad, onda free može ići spajati pojedine prazne komade u nadi kako bi se stvorio veći kontinuirani blok, ali ako to ne uspije imaš sranje. Taj je problem doduše znatno umanjen sa 64 bitnim adresnim prostorom.

Ako su cpu keš i data locality od kritične važnosti, to se onda rješava programski, a ne kompajliranjem kernela.

Pun je procesorskih instrukcija, eto. Ovo o nepotrebnim instrukcijama je posebno smiješno.

Kada su već tu onda su itekako potrebne. Uzmi neki disassembler i nasumce prebriši "nepotrebne" instrukcije serijom NOP instrukcija pa vidi koliko su "nepotrebne". Možeš samo reći da je niz potrebnih instrukcija kako bi se nešto napravilo mogao biti i kraći (što, ironično, ne podrazumijeva i kraće izvršavanje), ali pipeline će u idealnim uvjetima uvijek biti pun.

Ista stvar vrijedi, samo što OOM greške iz ring0 koda rade jako ozbiljne probleme.

Ne znam koji si to moduli dozvoljavaju tako olako masovno alocirati i dealocirati memoriju da bi ju uspjeli fragmentirati. Najpametnija stvar je unaprijed alocirati blokove i držati ih cijelo vrijeme, kao što se to radi sa windows driverima.

Hvataj se ti za glavu do sutra, ali zapinješ na elementarnim stvarima. Još ne razumiješ ni kako se to točno memorijski adresni prostor fragmentira i što to implicira, a igrao bi se kernelovog defragmentera.

Da, i? To je identičan koncept koji se krije i iza windows drivera. To ne mijenja ništa od ovog što sam napisao.

Vidiš da ne razumiješ virtualnu memoriju. Virtualni adresni prostor modula je u komadu. Fizičke memorijske stranice po kojima je on razbacan su nebitne, procesor sam spaja dijelove i prevodi linearne virtualne adrese u fizičke adrese.

Vratit se na 80386 i pogledati "kak' to šljaka".

Za CPU sasvim je sporedno koliko su dvije memorijske stranice blizu, i jesu li čak i jedna do druge. Bitno je samo je li u kešu ili nije u kešu. Ako nije u kešu mora se čekati na RAM, ako jest onda se ne mora. U teoriji možeš imati penalizirani pristup memoriji koja se nalazi u jednoj jedinoj memorijskoj stranici ako kod skače naokolo kao blesav i ako je keš dovoljno malen.

Tvoj izvor:

"By the time you load an LKM, real memory is all fragmented -- you can't simply add the LKM to the end of the base kernel. But the LKM needs to be in contiguous virtual memory, so Linux uses vmalloc to allocate a contiguous area of virtual memory (in the kernel address space), which is probably not contiguous in real memory."

Linux dakle, modulu, stvori virtualni adresni prostor. Budući da su fizičke adrese negdje pune negdje prazne pa ne može samo nakačiti modul izravno i kontinuirano nakon kernela. Stoga modul operira sa virtualnim adresama.

Ne. Kernel je statičan, učitan na svoju početnu adresu u kontinuiranom bloku i ne mrda odatle.