Thread-Geschwindigkeit
-
Du musst wahrscheinlich die klassische OnIdle-MessageLoop verwenden mit PeekMessage.
-
Tolga. schrieb:
Ein Forummitglied von diesem Board hat auf seiner Website ein Programm zum knacken von Windows-Passwörter mit BruteForce online gestellt.
Du meinst meins: http://www.luckie-online.de/Programme/PWRecover
Fand ich interessant und lud mir das runter nur zu meinem Erstaunen sah ich, dass er 10 Euro für die unbeschränkte Version verlangt. Das fand ich schon hart, da das programm ca. 2 Std. Programmierzeit erfordert.
Warum nicht, wenn es Leute gibt, dienen das wert ist?
Jetzt hab ich selbst so'n Ding programmiert. Läuft sogar mit ner GUI nicht auf Konsole wie seins, ist jetzt schon 2,4 mal so schnell und nimmt nicht 100% CPU - Leistung wie seins sondern nur 80%.
Ähm, ja und? Warum soll ich nicht den ganzen Power der CPU nutzen? Der Thread läuft mit der Priorität normal, gibt also Rechenzeit ab, wenn andere Prozess sie benötigen und legt nicht den ganzen Rechner lahm.
Ausserdem kann man bei mir den Stand speichern und später fortsetzen. UND: Kostet NIX! (^^Verzeiht die kurze Eigenwerbung
Das ist natürlich ein sehr gutes Feature. Da muss ich an dem Bruteforce-Algorithmus noch etwas basteln. habe aber bisher noch keine Zeit dazu gefunden.
-
Könntest du bitte den Thread nicht mit sinnlosen Rechtfertigungen zuspammen?
-
Das Problem mit der CPU-Auslastung liegt am Windows Task Scheduler. Der behält sich das Recht vor, jeden Thread für eine beliebige Zeit zu unterbrechen. D.h. unter Windows ist es technisch unmöglich, eine garantierte Thread-Antwortzeit zu bekommen. In der Regel liegt die Zeit, bis ein Thread wieder drankommt, im günstigsten Fall bei einigen µs, im ungünstigsten Fall zwischen 5 und 20 ms.
Bei GNU/Linux beispielsweise liegt die maximale Ausfallzeit i.d.R. unter 1 ms.
Man sollte seine Programme so schreiben, daß sie von der Geschwindigkeit der Threadumschaltung nicht abhängig sind, aber das kann manchmal durchaus ein Problem sein.
Echtzeitfähige Betriebssysteme wie AmigaOS bieten oftmals garantierte Reaktionszeiten (z.B. durch Software-Interrupt-Chains, die an Hardware-Interrupts gekoppelt sind, mit denen man in fest definierten Zeitabständen Signale an Threads schicken -- und damit sofort aufwecken -- kann).
Leider kann man sich nicht ohne Weiteres in den Interrupt-Mechanismums von Windows einklinken.
-
Ich vermute, dass eine API-Funktion der Flaschenhals meines Codes ist aber warum bekomme ich keinen erhöhte Geschwindigkeit, wenn ich höhere Priritt angebe?
ich kenne das Problem - immer wenn ich dann von Debug auf Release stelle ändert sich das aber
-
Ringding schrieb:
Könntest du bitte den Thread nicht mit sinnlosen Rechtfertigungen zuspammen?
Und warum sollte ich bitte sehr nicht? Jetzt sag nicht, dass es den Threadersteller nicht geholfen hat, das hat dein sinnloses Posting noch weniger.
-
Tolga. schrieb:
warum bekomme ich keinen erhöhte Geschwindigkeit, wenn ich höhere Priritt angebe?
Die Priorität gibt nur an, welcher Prozess die CPU benützen darf, wenn er etwas tun will. Solange niemand was tun will, ist die CPU idle. Wenn nur ein Prozess was tun will, kann er das uneingeschränkt (100%) tun. Die Priorität kommt erst ins Spiel, sobald mehrere Prozesse gleichzeitig etwas tun wollen, das ist aber bei dir nicht der Fall. Anscheinend will dein Programm nicht einmal die ganze CPU-Zeit, die es bekommen könnte. Es wartet also auf irgendetwas.
-
ähm unter windows gibt es mehr als einen prozess der cpu zeit verlangt
also kann unter windows niemals ein Porgramm wirklich 100% CPU leistung über die gesamte laufzeit des Programms bekommen.
Es wird immer, wenn auch für sehr kurze zeit, unterbrochen.
-
Stimmt, aber das würde ich so ca. bei < 0,1% ansiedeln.
-
Vielleicht wurde die Möglichkeit hier noch nicht aufgeführt.
Benutze einen Profiler um die Performance-Engpässe TATSÄCHLICH
zu identifizieren, statt rumzuraten und mutzumassen.
Das Windows kein Echtzeit-Betriebssystem mit garantierten
Reaktionszeiten ist, weisst du hoffentlich auch.
-
Stimmt,
dazu brauchst du schon ein Unix bzw Unix ähnliches System.
Die Priorität teilt dem sceduler nur mit, wie viel Zeit er einem
Prozess geben soll, also, wie lange dieser an der Reihe ist bevor der Nächste kommt. Steigert nur äusserst geringfügig die Geschwindigkeit.
-
ne,langsamer
[quote="MFK"][quote="Tolga."]Das Programm lagert den BruteForce-Vorgang auf nen eigenen Thread aus[/quote]Durch zusätzliche Threads werden Programme nicht schneller.[quote]Demnach schließe ich ein Warten aus. [/quote]Du weißt also genau, welche API-Funktionen intern auf irgendwelche Synchronisierungsobjekte warten? Respekt.
[quote]Ich hatte gehofft, es gäbe noch möglichkeiten Threads schneller zu machen, die ich nicht kenne.[/quote]Benutz einen Profiler.[/quote]
-
Power Off schrieb:
Leider kann man sich nicht ohne Weiteres in den Interrupt-Mechanismums von Windows einklinken.
na klar geht das
-
Würde mich wundern wenn man unter der WIN32API Einfluß auf die Interruptvektoren nehmen könnte (so wie unter DOS) oder diese gar umlenken könnte und es würde mich brennend interessieren wie!Schließlich ist oder soll es ja eines der 'hervorragenden' Merkmale von Windows zu sein alle Prozesse und Threads zu kapseln und mittels der verschiedenen Prozessorarbeitsweisen (Protected Mode und Virt. 8086 Mode) so eine 'stabileres' System zu gewährleisten.Das das manchmal nicht hinhaut liegt an anderen (anwendungsspezifischen) Gründen,was aber die meisten Leser eher langweilen dürfte. Also,jetzt bist du dran......
-
Mit ein Treiber.
-
ok,das ist so...aber: kannst du Treiber proggen?Wenn ja,laß ma' watt sehn....denn:die einzige Lit zum Thema Treiber die mir bis jetzt untergekommen ist ist von Peter Vascola und ansonsten sieht's ziemlich dünn aus!Das will sagen,das ich denke das die meisten Leute (ich reflektiere da von mir aus auf meine Umgebung,mag sein,daß ich damit machmal auch falsch liege...)sowie so mehr reden als tun (ohne dich diskreditieren zu wollen).Meinung: ist nicht alles Gold was glänzt oder Spreu vom Weizen oder Wahrer Jakob unso
Where to hell are all the freaks wid de moderfucking quellcodes?
-
Und warum sollte ich dann dein Programm verwenden, wenn es einen pfuschhaft geschriebenen Treiber installieren will, der mein System instabil macht?
EDIT: Es gibt nur ganz ganz wenige Leute, die gute Treiber für Windows schreiben können. Und bei denen hat's jahrelang gedauert.
-
Buddy Love schrieb:
ok,das ist so...aber: kannst du Treiber proggen?Wenn ja,laß ma' watt sehn....denn:die einzige Lit zum Thema Treiber die mir bis jetzt untergekommen ist ist von Peter Vascola und ansonsten sieht's ziemlich dünn aus!Das will sagen,das ich denke das die meisten Leute (ich reflektiere da von mir aus auf meine Umgebung,mag sein,daß ich damit machmal auch falsch liege...)sowie so mehr reden als tun (ohne dich diskreditieren zu wollen).Meinung: ist nicht alles Gold was glänzt oder Spreu vom Weizen oder Wahrer Jakob unso
Where to hell are all the freaks wid de moderfucking quellcodes?*LOL*
-
[*LOL*
[/quote]Ganz besonders konstruktiv der Kleine.....na ja,beim nächsten Mal geb ich mir beim Texten nicht so viel Mühe gell...und jetzt geh hin und üb noch en' bischen dispatchen
und außerdem: was hat das alles mit WIN32API toe doen?
Das gehört in die C-Ecke....
Syyysop...
-
[quote="Ringding"]Und warum sollte ich dann dein Programm verwenden, wenn es einen pfuschhaft geschriebenen Treiber installieren will, der mein System instabil macht?
EDIT: Es gibt nur ganz ganz wenige Leute, die gute Treiber für Windows schreiben können. Und bei denen hat's jahrelang gedauert.[/quote]
genau so siehts aus...