0 like 0 dislike

Nos, az eb ott van elhantolva, hogy fejlesztek. (Saját programnyelvet, de ez mindegy. Csak azért írom, mert megelőzöm a kérdést). Lényeg, hogy naponta több tucatszor újrafordítom a projectet, sőt, emellé majdnem minden újrafordítás után elindítom a magam által írt automatikus test frameworkot is, ami több mint kétszáz szkriptet lefuttat, s leellenőrzi az eredményüket a referenciafájllal, hogy kompatibilis maradtam-e a módosítás után.
Na most ez elég sok idő. Alkalmanként az újrafordítás is majdnem egy perc már, és idegbajos ember vagyok, nem szeretem ha valami tovább tart, mint amíg felemelem az ujjamat az Enterről...
Ellenben, a gépemben 16 giga RAM van. Ebből már kreáltam ramdiszket 1 gigát, mert hátha jó lesz valamire, de szinte sosem használom. Lecsíphetném azonban akár a felét is, 8 gigát, vagy tizet is, mert nagyon ritka hogy 3-nál többet használjak. És minek álljon ott a sok ram kihasználatlanul!
Az jutott tehát az eszembe, hogy tanácsot kérjek tőletek, miként tudnám a C/C++ fordításaimat ramdiszkre áttenni, minél nagyobb mértékben. Úgy tudom ugyanis, az ilyesmi rengeteg kis fájl írásával/olvasásával jár, sok ideiglenes fájléval is, ami mi a szösznek legyen az SSD-re írogatva, ha úgyis ott a sok ram!
Az nem gond, hogyan csináljak ramdiszket az fstab által, olyanom most is van, legfeljebb a méretet kéne átírnom nagyobbra. Jelenleg ez a sor vonatkozik ott rá:

none /_/Mount/RAM ramfs size=1024M,mode=777 1 0

De én ezt nem úgy szeretném használni, hogy a projectemet másolom át a ramdiszkre, mert az rém kockázatos ugye. Kitelik tőlem a hülyeség, hogy aztán úgy kapcsolom ki a masinát, hogy nem backupoltam valami tartósabb könyvtárba...
És különben is, igazából ezt ki is próbáltam, s nem lett semmi sokkal gyorsabb. (Alaposan kipróbáltam, ramdiszken fordítottam le az egész LFS-emet régebben).
Feltételezem, amiatt nem lett gyorsabb, mert itt a lényeg nem az én pár tucat állományom, ami úgyis hamar bekerül a memóriába, hanem a glibc meg a gcc sok fájlja, amit fordításkor hívogat.
Tehát én valami olyasmin töröm a fejemet, arrafelé keresek megoldást, miként tudnám elérni, hogy e fájlok (glibc, gcc, stb, amik ilyenkor általában kelleni szoktak, headerek, stb) hamar bekerüljenek mind a ramdiszkre (akár a gép bootolásakor is már), aztán utána már onnan hívogassa és töltögesse őket, ha neki az úgy tetszik.
Azellen se volna kifogásom, ha a /tmp könyvtárat áttenném a ramdiszkre ilyenkor, IDEIGLENESEN. Csak ezzel meg az a bibi, hogy fejlesztés közben nemritkán keresgélek is a neten (stackoverflow meg hasonlók), és azt már NEM akarom, hogy a böngészőm cache része vagy akármi ideiglenes állománya is a ramdiszkre kerüljön! Tudom hogy gyorsabb lenne, de annyit nem ér meg. Nem bánnám ezt se ha nem 16, hanem 160 giga ramom volna. De annyi nincs... A fordítás gyorsításáért viszont szívesen használnám a ramdiszket.

Na remélem sikerült ecsetelnem a problemuszt. Várom a bölcs ötleteket meg hatleteket! Köszi előre is!

kérdezve Feb 7, 2016 C / C++ kategóriában FossilCodger (61 pont) által

poliverzum, Te vagy az?

2 válasz

0 like 0 dislike
Legjobb válasz

A RAMdisket sajnos sokan jelentősen túlértékelik. A modern operációs rendszerek a gyakran használt fájlokat az un. file cachebe cachelik, azaz ha egy filet elolvasol, akkor az bekerül a RAM-ba, és ha van elég elérhető RAM, akkor ott is marad. Magyarán ELMÉLETBEN a file olvasását nem gyorsítod meg, csak átteszed egy másik időpontra.

Namost, ha egy-egy processzt vagy csoportot korlátozni szeretnél, arra vannak más megoldások. A cgroupokkal csoportokba tudod helyezni a processzeket, és a cgroupokra lehet file cache limitet mondani.

Innentől pedig csak megfelelő simogatás kérdése a kívánt konfig elérése. Persze ettől függetlenül a RAM disk egyszerűbb megoldásnak bizonyulhat, de vannak hátrányai.

megválaszolva Feb 7, 2016 Pásztor János (494 pont) által
kiválasztott Feb 8, 2016 FossilCodger által

Szóval tömören az a véleményed, hogy lényegében mindegy mit varázsolok, mert legfeljebb az aznapi legislegelső fordítást tudnám felgyorsítani, még ezt is csak TALÁN (és ennek valóban nem volna nagy jelentősége), utána már úgyis ott van minden a ramban nálam, hacsak közben esetleg el nem kezdek gigabájtnyi filmeket vagy mást másolni, ami kikergeti a cache-ban levő korábbi fájlokat...
Hm, hát belegondolva, végülis igazad lehet. És most is, használom itt a Palemoont (firefox-klón), nyitva van 13 tab, köztük a gmail is, és a statusbaromon látom, hogy a ram-nak csak a 6%-a foglalt... Azaz a 16 gigából durván 1 giga. Szóval a többi eszerint úgyis automatikusan cache. Hát jól van, beletörődök. Megjelölöm a tiedet „megoldásként”. Végtére a matematikát tisztelem, s ott megtanultam, hogy a negatív eredmény is eredmény...

2 like 0 dislike

Ha kipróbáltad ramfs-re másolva és nem lett számottevően gyorsabb, akkor biztos, hogy a disk IO a szűk keresztmetszet? Egyébként ha 16 giga RAM-od van és abból átlagosan 3-at használsz, akkor a rendszered a maradék 13-at egyébként is cache-nek fogja használni, vagyis az első fordítás után már szinte teljesen memóriából fog dolgozni (íráskor kell csak a lemezhez nyúlnia).

Milyen build módszert használsz? A tényleges időből milyen arányban jön a fordítás és utána a tesztek lefutása? A rendszererőforrásokat mérted a futás közben? Nézz esetleg rá a ccache projektre (https://ccache.samba.org/), a Samba team fejleszti, ha sok fájlod van, de egy-egy build közben csak néhány változik, akkor gyorsíthat a cachelés.

Disclaimer: nem fejlesztek C-ben, úgyhogy nincs tapasztalatom azzal, hogy mekkora növekedést lehet elérni, de a Samba kódbázis szép nagy és a fejlesztői megbízhatóak annyira, hogy rámondjam, működhet.

megválaszolva Feb 7, 2016 BlackY (117 pont) által

Nekem is a ccache jutott eszembe :)

A CCACHE már rég installálva van nálam (és beállítva is). :) Csak én, a telhetetlen, ennél is szerettem volna gyorsabbat.
Emlékszem, még amikor megvettem a laptopomat, már akkor tervben volt nekem ez a projectem, (bár előbb még az LFS-en akartam túllenni - sikerült is), és előre tudtam, hogy emiatt rengeteget fogok fordítani. Így aztán nem spóroltam se a RAM-mal (igazából 32 gigát szerettem volna, de 16 a maximum amit ez képes kezelni), se a processzorral (i7-es). Sokan már akkor is mondták, idióta vagyok, mire ez az erőmű a DWM ablakkezelőhöz... Nos, EMIATT. A sok fordítás miatt... Videokártyából csak inteles van benne, mert semmi szükségem egy nvidia képességeire. Azon spórolhattam. A procin meg a ramon, úgy gondoltam, nem.
Igazából ha nem programoznék, ahhoz ami nekem kell, elég volna egy T60-as is. És ez biztos, mert épp olyanom volt korábban, és valóban teljesen megfelelt addig.
Lehet persze, hogy ennél gyorsabbra nem lehet felturbózni, csak gondoltam hátha lesz nagy mázli, semmit nem veszthetek vele ha megkérdem róla a nálam tapasztaltabbakat, ugye.

Amúgy a tesztek lefutás a legkisebb bajom, arra az 5 percre felállok és iszom egy kávét vagy csinálok egy teát. Naponta talán 3-4 alkalommal futtatom őket. Ha azonban leülök a gép elé programozni, hát fordítok néha egy nap akár 20-szor is. Persze ki lehet bírni, csak bosszant a dolog, na... SSD dübörög a gépemben, i7 procival, de nem mindig volt benne SSD, és érzésre nem sokkal gyorsabb vele se a fordítás, mint amikor még HDD zörgött benne. Van ami gyorsabb, igen, de ez nem. Holott épp ez lenne nekem a legfontosabb, a boot-időre tojok magasan, egyszer kapcsolom csak be, utána dolgozom vele órákig...

Erdemes az adatparticiot egy kicsit optimalizalni esetleg.
Mountold atime-mal, legyen ext4 v. xfs es a mindenkori tuning opcioit allitsd be.
Ha Linux, hasznald mindig a legujabb a disztribuciodban elerheto kernelt, altalaban az a leggyorsabb is.

De egyebkent valoban mindennek be kell kerulnie a fs cache-be.
Megneznem tovabba, hogy hol van a szuk keresztmetszet. Valoban az IO-ra megy el tobb? Ha igen, tegyel bele +1 SSD-t, fuzd ossze raid0-ba es egybol nagyot fog rajta dobni.
De meglepoen sokat tud az is dobni, ha a pl. van egy leterhelt diszked es amit gyorsitani akarsz, azt egy teljesen kulon diszkre rakod. Tehat nem osszefuzod, hanem dedikalsz neki egy kulon HW-t.

Mindezzel egyutt valoszinuleg legtobbet ugy tudsz dobni a buildek es a tesztek futasi idejen, hogy annak a szisztemajat optimalizalod, pl. inkrementalisan buildelsz.

Hm, hát ugye hogy a mindenkori disztrib kerneljét használjam, kiesik, mert LFS-em van. Viszont, nagyon örülök a hozzászólásodnak mégis, azon részének, hogy valami másik SSD egységet is tegyek a gépembe, s arra tegyek át dolgokat. Nem tudom persze előre, ez fog-e gyorsítani rajta, de érdemes kipróbálnom, mert úgyis rég tervezem, hogy teszek bele egy másodikat. A DVD író helyén most úgyis már rég egy HDD morog, egy 500 gigás. Eredetleg az volt a mostani SSD helyén, csak ugye odapakoltam amikor megvettem az SSD-t. Érik bennem rég a gondolat, hogy azt is kicserélem SSD-re, mindössze amiatt, hogy ne legyen mozgó cucc a laptopomban. De ezzel még várok, mert okvetlenül egy 2 TB-osat szeretnék, de annak manapság még elég húzós ára van. Talán karácsonyra összejön, ennek reális esélye van.
Addig viszont hadd kérdezzelek meg, te mit pakolnál arra, hogy kifejezetten a C/C++ fordítás gyorsabb legyen? Tehát nem a projektemet, az marad ahol van, különben is lehet akármikor másik projektem is. Véleményed szerint jó ötlet-e, hogy átmásolom oda a Glibc és Gcc könyvtárakat, s a régi helyükre besymlinkelem őket?

Tudniillik ezt könnyen megtehetem, mert amikor az LFS-emet építettem, akkor igazán alaposan átvariáltam azt. A könyvtárszerkezetem hasonló a GoboLinuxéhoz: Minden csomag egy külön könyvtárba van telepítve! Például ezesetben:

//P/GCC/verziószám/alkönyvtárak
/
/P/Glibc/verziószám/alkönyvtárak
stb.
Az alkönyvtárak meg ugye olyanok hogy headers, lib, bin stb. Ezekből meg minden szintén be van symlinkelve egy külön könyvtárba (persze fájltípusonként külön könyvtárba: include állományok, végrehajthatóak, stb), s így a $PATH-omban csak azt az egy könyvtárat kell szerepeltetnem, hehehe... (akit érdekel, ezen LFS-em építésének teljes leírása a szkriptekkel együtt megtalálható (ingyen) a neten, ha van érdeklődés, idemásolhatom a linket).
Na most, ennek alapján, nem tartana sokáig, hogy átmásoljam e két könyvtárat majd a másik SSD-re, s átírjam a symlinket rá. Szerinted ez gyorsítana, vagy valami másra gondoltál eredetileg?

Az LFS-rol nem sokat tudok.

De erdemben akkor segithetsz rajta, ha az alapanyagot szeparalod. Szoval ha a gcc ott van, azzal sokat nem segitesz.
Amugy de, a projektet raknam oda. Mar csak azert is, mert a nagy ssd-k eleve stripe-olt kisebb ssd-kbol tevodnek ossze, szoval ertelemszeruen jellemzoen gyorsabbak is.

Van meg1 lehetoseg egyebkent ha valoban az IO (lenne) a szuk keresztmetszet, a tomorites. Ha kevesebbet kell kiirnia/felolvasnia, akkor gyorsabb az IO termeszetesen es mindezt a CPU terhere.
De erosen ketlem, hogy nalad ez a helyzet.

Néhány észrevétel:

  1. Kellene egy statisztikát csinálni, hogy a fordítás során mennyi adatot olvas be a rendszer.
  2. Mekkora a forráskódod mérete?
  3. Mennyi ideig tart, míg az 1. (ill. 2.) pontban megadott adatmennyiséget beolvasod?
  4. A 3. pontban megadott időnél többet ezzel nem fogsz tudni spórolni. Ha az egész 0.5 másodperc, miközben a fordítás ideje percekben mérhető, hol kellene spórolni? A fél másodpercen vagy a perces nagyságrenden?
A Veremcsere a Refaktor Magazinhoz kapcsolódó, barátságos kérdezz-felelek oldal, ahol felteheted a webfejlesztéssel és üzemeltetéssel kapcsolatos kérdésedet.

A részletekért olvasd el az üdvözlő postunkat!
Az oldal valamennyi tartalma a Creative Commons Attribution NonCommercial ShareAlike 3.0 licenc alatt érhető el.

Kapcsolódó kérdések

2 like 0 dislike
4 válasz
0 like 0 dislike
0 válasz
0 like 0 dislike
2 válasz
0 like 0 dislike
2 válasz
kérdezve Ápr 22, 2016 PHP kategóriában kocsisdavid99 (13 pont) által
0 like 1 dislike
1 válasz
67 kérdés
142 válasz
354 hozzászólás
214 felhasználó