Cpulimit, zrychlení procesu

[Odra]

Dobrý večer,

lze nějak zefektivnit průběh procesu fcrackzip pomocí cpulimit? Vedle běžícího fcrackzip jsem v dalším okně terminálu spustil cpulimit -p 3626 -l 100 -v, nicméně 100% vytížení stejně nedosahuji. Navíc i v případě zvýšení priority pomocí renice se CPU vytíží u daného procesu pouze na ~80%.
Šlo by podle návodu viz. http://www.howtoforge.com/how-to-limit-cpu-usage-with-cpulimit-on-ubuntu-linux nějak spustit fcrackzip na všech 4 vláknech mého procesoru? Něco na způsob toho jejich

Kód: [Vybrat]

for j in `seq 1 4`; do dd if=/dev/zero of=/dev/null & done
Díky za jakékoliv nakopnutí.

[Petr Merlin Vaněček]

Pokud ta aplikace není psaná jako vícevláknová (Multithreading), pak těžko jeden proces rozložíš mezi více procesorů, jednotlivá jádra (vlákna) si jej mohou maximálně předávat.

PS: Jen dvě slova do googlu dají nápovědu k řešení Tvého problému

[Savalas]

Mohu potvrdit ze, kdyz sem presel na vice jadrovy procesor, nestacil sem se divit jak se nektere procesy zvlastne rozdeluji mezi jadra, a kolik programu porad jeste vic jader nedokaze vyuzit. Jinak k crackovani zipu, nedavno sem testoval co je nejrychlejsi a ukazalose ze win program Advanced ZIP Password Recovery pod wine zpracuje vic hesel nez cokoliv jineho.

[Petr Merlin Vaněček]

Ale ona to vícevláknová aplikace je, jen jí to sdělit, že může více vláken skutečně využít.
Tuším to bude časově kritická aplikace, takže autor uvažuje tak, aby si sám uživatel řekl, kolik systémových prostředků chce uživatel uvolnit, aby taky na tom PC mohl dělat i něco jiného ...

[Martin Šácha]

IMHO te zdrzuje vic disk nez procesor

[Odra]

@ Merlin
Díky za příspěvek, ono fcrackzip multithreading jsem již hledal, ale kromě tohohle: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373185 vlákna kde je návrh na přepínač -t n, jsem žádný náznak multithreadingu nenašel.

@ Savalas
Díky za reakci. Nicméně myšlenka držení zpětně spousty nenativních programů jedoucích pod wine se mi fakt nelíbí. To jsem mohl zůstat pod Widlemi.

@ Šachy
Mám to na SSDčku, co víc pro to můžu udělat? Nahodit to do /tmp který je namapovaný do RAMky?

[Martin Šácha]

RAMka je porad o rad rychlejsi nez SSD... a /tmp defaultne v RAM neni, na to je lepsi /dev/shm

[Odra]

RAMka je porad o rad rychlejsi nez SSD... a /tmp defaultne v RAM neni, na to je lepsi /dev/shm

Já vím, mám tam /tmp namapované ručně.

[Petr Merlin Vaněček]

@ Merlin
Díky za příspěvek, ono fcrackzip multithreading jsem již hledal, ale kromě tohohle: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373185 vlákna kde je návrh na přepínač -t n, jsem žádný náznak multithreadingu nenašel.

@ Savalas
Díky za reakci. Nicméně myšlenka držení zpětně spousty nenativních programů jedoucích pod wine se mi fakt nelíbí. To jsem mohl zůstat pod Widlemi.

@ Šachy
Mám to na SSDčku, co víc pro to můžu udělat? Nahodit to do /tmp který je namapovaný do RAMky?

Ok, soudě dle reakce tedy přepínač nefunguje, pak bych se pídil po tom proč.
Porovnal bych verze, případně kontaktoval autora.

[Odra]

Ok, soudě dle reakce tedy přepínač nefunguje, pak bych se pídil po tom proč.
Porovnal bych verze, případně kontaktoval autora.

Soudě dle těch příspěvků viz odkaz, jedná se pouze o přání a nikdy nic takového implementovaného nebylo.

Nicméně díky, alespoň za nakopnutí a přesunutí souboru do RAMky. Alespoň subjektivně se brute-force zdá být rychlejší. Ale rád uvítám jakékoliv další rady