Kezdőlap › Fórumok › Vegyes felvágott › Programfordítások, optimalizáció
- This topic has 126 hozzászólás, 9 résztvevő, and was last updated 18 years, 1 months telt el by
gabaman.
-
SzerzőBejegyzés
-
2007-06-23-17:14 #2118698
Gondolom valami ilyesmi lehet: mig a cpu el van foglalva a forditassal az egyik folyamaton, addig a masik folyamat beolvashatja a lemezrol a forrasfajlt, amit majd neki fog allni forditani. (amit te mondtal, annak egy sajatos esete)
2007-06-23-17:14 #2118699Gondolom valami ilyesmi lehet: mig a cpu el van foglalva a forditassal az egyik folyamaton, addig a masik folyamat beolvashatja a lemezrol a forrasfajlt, amit majd neki fog allni forditani. (amit te mondtal, annak egy sajatos esete)
2007-06-23-17:20 #2118700Már többször próbáltam, de nem tudom úgy leírni a lényeget, hogy egyszerűen és röviden legyen megfogalmazva, és ne legyen félreérthető.
Ha egy procis géped van, akkor csak a -j1 (vagy a -j elhagyása) a leggyorsabb, mert a több aktívan futó szál rendszeresen üríti a gyorstárat, ezért sokkal több a fő memóriából történő olvasás (10-100x lassabb mint a gyorstár). Több mag esetén azért kell több szál mint mag, mert a zárolások miatt nem mindíg futásra kész az összes szál, ezért kell legalább egy tartalék, ami ilyenkor „beugrik” a várakozó szál helyére.
Azért adnak meg -j2 paramétert a legtöbb esetben, mert 2 mag esetén nagyobb a gyorsulás, mint 1 mag esetén a lassulás, így ez egy általánsan használható – de nem hatékony – félmegoldás. Ezzel megspótolták a processzorok számának beolvasását egyszerű statisztika alkalmazásával.
„Most ezzel mi volt a baj? Nem helyes a feltételezésem?”
Az volt a baj, hogy alapvető dologban voltál bizonytalan. Egy mag végeredménye vagy több, ugyanaz az eset, mint 1 kg toll és 1 kg acélgolyó tömege közötti különbség. Aki bizonytalan bármelyikben, nincs értelme a többiről beszélni.„Na, akkor majd egy nagyobb (=hosszabb fordítási idejű) progin kipróbálom, és stopperolom (inkább egy time parancsot ráeresztek), hogy tényleg gyorsabb-e.”
Próbáld ki 1, 2, 4, 8, 16 -j paraméterekkel. Tuti egyre lassabb lesz. Természetesen egy mérés nem mérés.„Ha jól értem, akkor leegyszerűsítve azért lehet gyorsabb, mert nem csak a processzort használjuk, hanem más erőforrásokat is, és fordításkor leginkább a proci erőforrásai a leghamarabb elfogyóak, a többi erőforrás meg többet is bírna.”
Nem egészen. Egy processzor és egy futó példány esetén ritkán van az összes erőforrás használva, ezért a pihenő időt (pl. vinyórol olvasásra várakozás) nem szükséges egy másik példánynak kitöltenie (de ki lehet).2007-06-23-17:20 #2118701Már többször próbáltam, de nem tudom úgy leírni a lényeget, hogy egyszerűen és röviden legyen megfogalmazva, és ne legyen félreérthető.
Ha egy procis géped van, akkor csak a -j1 (vagy a -j elhagyása) a leggyorsabb, mert a több aktívan futó szál rendszeresen üríti a gyorstárat, ezért sokkal több a fő memóriából történő olvasás (10-100x lassabb mint a gyorstár). Több mag esetén azért kell több szál mint mag, mert a zárolások miatt nem mindíg futásra kész az összes szál, ezért kell legalább egy tartalék, ami ilyenkor „beugrik” a várakozó szál helyére.
Azért adnak meg -j2 paramétert a legtöbb esetben, mert 2 mag esetén nagyobb a gyorsulás, mint 1 mag esetén a lassulás, így ez egy általánsan használható – de nem hatékony – félmegoldás. Ezzel megspótolták a processzorok számának beolvasását egyszerű statisztika alkalmazásával.
„Most ezzel mi volt a baj? Nem helyes a feltételezésem?”
Az volt a baj, hogy alapvető dologban voltál bizonytalan. Egy mag végeredménye vagy több, ugyanaz az eset, mint 1 kg toll és 1 kg acélgolyó tömege közötti különbség. Aki bizonytalan bármelyikben, nincs értelme a többiről beszélni.„Na, akkor majd egy nagyobb (=hosszabb fordítási idejű) progin kipróbálom, és stopperolom (inkább egy time parancsot ráeresztek), hogy tényleg gyorsabb-e.”
Próbáld ki 1, 2, 4, 8, 16 -j paraméterekkel. Tuti egyre lassabb lesz. Természetesen egy mérés nem mérés.„Ha jól értem, akkor leegyszerűsítve azért lehet gyorsabb, mert nem csak a processzort használjuk, hanem más erőforrásokat is, és fordításkor leginkább a proci erőforrásai a leghamarabb elfogyóak, a többi erőforrás meg többet is bírna.”
Nem egészen. Egy processzor és egy futó példány esetén ritkán van az összes erőforrás használva, ezért a pihenő időt (pl. vinyórol olvasásra várakozás) nem szükséges egy másik példánynak kitöltenie (de ki lehet).2007-06-23-17:28 #2118702Ahan. Azt nem mondom, hogy teljesen értem meg már csúcsszuper vagyok, de egy pöttyet világosodtam. Köszi.
Azért majd kipróbálom, én kiváncsi vagyok rá.
Az LFS-es linken azt írják, hogy néhány progi nem szereti (elhasal) a párhuzamos fordítást, tehát lényegében a keletkezett binárisok között van különbség 😛
(nehogy félreértsd, csak hülyéskedek)Szerk.:
„Az volt a baj, hogy alapvető dologban voltál bizonytalan.” – mentségemre szolgáljon, hogy azért nem tényként állítottam se őt, se az ellenkezőjét 😉2007-06-23-17:28 #2118703Ahan. Azt nem mondom, hogy teljesen értem meg már csúcsszuper vagyok, de egy pöttyet világosodtam. Köszi.
Azért majd kipróbálom, én kiváncsi vagyok rá.
Az LFS-es linken azt írják, hogy néhány progi nem szereti (elhasal) a párhuzamos fordítást, tehát lényegében a keletkezett binárisok között van különbség 😛
(nehogy félreértsd, csak hülyéskedek)Szerk.:
„Az volt a baj, hogy alapvető dologban voltál bizonytalan.” – mentségemre szolgáljon, hogy azért nem tényként állítottam se őt, se az ellenkezőjét 😉2007-06-23-17:40 #2118704„Az LFS-es linken azt írják, hogy néhány progi nem szereti (elhasal) a párhuzamos fordítást”
Persze hogy nem minden progi szereti. Gondold csak végig, ha az egyik szálon fut a függőség meghatátozása, a másikon meg a fordítás, az egyértelmű hogy nem jó. A párhuzamosság megváltoztatja a végrehajtási sorrendet. Ezért van külön a ‘make dep’ sok helyen.2007-06-23-17:40 #2118705„Az LFS-es linken azt írják, hogy néhány progi nem szereti (elhasal) a párhuzamos fordítást”
Persze hogy nem minden progi szereti. Gondold csak végig, ha az egyik szálon fut a függőség meghatátozása, a másikon meg a fordítás, az egyértelmű hogy nem jó. A párhuzamosság megváltoztatja a végrehajtási sorrendet. Ezért van külön a ‘make dep’ sok helyen.2007-06-23-17:48 #2118706Ááá, tényleg! Sose értettem, miért van külön a make dep!
(hát igen, a képzelet<valóság, legalábbis ebben az esetben)
2007-06-23-17:48 #2118707Ááá, tényleg! Sose értettem, miért van külön a make dep!
(hát igen, a képzelet<valóság, legalábbis ebben az esetben)
-
SzerzőBejegyzés
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz