Folyik a lázas munka a kézimeccs alatt.

Addig is, amíg nincs megfejtés: a hét képei a londoni olimpia bűvöletében – Nagyítás-fotógaléria

Azert irtam cpu optimalizalast, mert nagyon cpu zabalok 🙂 99-100% pcu -t esznek...

Pl. egy filemásolás is zabál egyébként CPU-t is, főleg sw raid esetén.

100-at nyilván nem jó együtt futtani és nem a CPU lassulás miatt, hanem amiatt, hogy a taskok közötti váltogatás fogja elvinni az erőforrást.Négy magon egy 4-8 viszont egész jó eredménnyel futhat. (Hogy melyik az optimális, csak kísérlettel állapíthatnád meg. Ideális esetben HT-vel szinte veszteség nélkül is futhat a 8 is.)a) Azaz, ha nem szálbiztos az algoritmusod, akkor kell 4-8 lista, amiből egyesével futtatnak a szálak. A veszteséged a legerősebb és legygyengébb lista közötti idő.b) Ha szálbiztos az algoritmusod*, akkor egy listád lesz és abból futat a 4-8 szál. Enneak az az előnye, hogy kb. 3 script lehet a maximális veszteség.*Ez vélhetőleg időkiesés, azaz itt a scriptek száma és működésük hossza határozza meg, hogy mennyire éri meg.Én azt mondanám, hogy simán elég lehet (a) megoldás is (főleg, ha jól válogatod össze a listát és lehet, hogy nem érdemes vele szenvedni) 1) ha nem fut más 8 szálon, 2) ha még más is fut 4 szálon. Azért a (2)-es pont elég valószínű.

Néhány ötlet, kontár tanács, kötözködés, aminek veszed…Nyilván erre a problémára nem használnék C++-t, csak C-t mert 1) minden függvény C-ben van 2) C++-nak semmi gyakorlati hasznát nem látom ebben az esetben. (Mert most ugye egy egyféle kevés függvényű felhasználói szinten futó device driveregykét akarunk csinálni. Egyébként van ami meg sokkal körülményesebb C++-ban.)Ezzel nem is biztos, hogy keverném a grafikus vezérlést. Jó esetben egy démonként futna root alatt.Mint mondtam az ioperm-hez kell a root jogosultság, mert csak rootal tudod a közvetlen hozzáférést engedélyezni. Nyilván így is veszélyes, ha nem tudod mit csinálsz. De ugye te konkrétan tudod, hogy csak a párhuzamos portot fogod vezérelni és másra nem is adtál engedélyt... sőr abból is csak az elsőre, hogy ne legyen gond.Attól nem lesz C++ valami, hogy std::cout-ot használsz. Igen, C++ fordítóval fordítható és függő lesz az egész C++ libtől, és így önmagában felrúgja a C kompatibilitást is, de praktikusan nem C++.Én értem, hogy azt akarod gyakorolni. Ezzel nincs is semmi baj, de akkor viszont a legnagyobb ágyúval tedd azt.Kezdjük a C++ wrapperokkal.Mi lenne, ha a valami_parancs(valami_objektum, ...) fügvényeket C++-ba helyeznéd:class Valamiés természetesen valamiX->parancs(...) függvények lennének belőle.A struktúrák helyett lehet használni privát/védett változókat/struktúrákat az objektumon belül. És ne felejtsük el, hogy az elemek hozzáférésénél: type &Valami::getElem() és type Valami::getElem() constLehetne használni Valami::setOn(bool on) akármi függvényeket.Operátor felülírásokat. (Ezt én speciel mindig is imádtam.)Tegyük fel, hogy van több portunk, vagy bármi, amiből több van: type &Valami::operator[] (size_t i) jopófa módszer.És természetesen kivételkezelést hiba kiírása helyett. Makrókkal egyébként remek kivételkezelőket is lehet írni, mellyel visszakövethető, hogy hol a hiba és mitől keletkezett.Természetesen privát módon nevet is adhatunk az objektumunknak megfelelően védve lekérdezve.Mindig ellenőrizzük, hogy a függvényeink kapott paraméterei megfelelnek-e, valósak-e. Egy assert makróval be lehet küldenünk a kivételkezelőnknek.stb.Persze ezek csak olyan ötletek...Egy nyulfarknyi programnál sok hülyeség, mint mondtam, de tanulásnak kiváló, meg kihasznál néhány C++ lehetőséget. De akkor viszonyt kezdettől foggva így kellene írni.A binárisokkal nem tudok mit kezdeni, mert nálam amúgy sincs se hw, meg a párhuzamos portot is hanyagolom.Majd mindjárt utánanézek, hogy hogy működnek open, ioctl stb függvények parport esetén. Ebben az esetben nem kell root, ha jogod van a rendszer alatt a parporthoz, viszont a Linuxhoz és libjeihez leszel kötve.