[ RC5-72 Key schneller finden ]

Begonnen von TRON, 24. Juni 2004, 16:45:59 Uhr

⏪ vorheriges - nächstes ⏩

0 Mitglieder und 3 Gäste betrachten dieses Thema.

Gudi

Zitat von: .::TRON::. am 12. Juli 2004, 17:28:03 Uhr
... was meint Ihr?


    Am OS rumwerkeln? Oder besser doch den Client verbessern?

    Hab' gehöt der neue Client [> 2.9007-486] soll besser mit AMD CPU's zurechtkommen.


hmm, also das OS ist ziemlich wurscht... Ob du nun Win2k, XP oder ein Linux nimmst, die Performance ist quasi gleich...
Ja und Client verbessern... an den Assembler-Cores wird immer irgendwie rumgedoktort... ist nur nicht so einfach nachzuweisen, dass der algorithmus trotzdem noch korrekt läuft dann... ;) daher die langen entwicklungszyklen dort...

zum link auf www.rc5team.de/?start=howto - da kann ich nat. nur auf die seite mit den fertigen clients verlinken und nicht einfach so auf die  prerelease-seite. denn dort steht jetzt zB gar kein win32-client... von daher geht's leider nicht anders. das ist dann sache der rc5-foren, auf neue clients aufmerksam zu machen... und das klappt auch eigentlich ganz gut...
übrigens haben auch die Pentium4- User durch den neuen Client nen Leistungsschub bekommen...

TRON

13. Juli 2004, 16:54:05 Uhr #21 Letzte Bearbeitung: 04. Dezember 2010, 03:11:07 Uhr von TRON
Tag Gudi!

So so... Du bist also ein Verantwortlicher? - Hm... Deine Erklärung klingt einleuchtend. Aber ich verstehe dennoch nicht, wie ich vor 30Tagen noch an 'nen v2.9007-486 gekommen bin, wo doch im April diesen Jahres schon der ...008-490 vorgestellt wurde. Naja was solls...

Das mit dem Leistungsschub kann ich bestätigen! Nun habe ich ca. 16% mehr. Mein Bruder greift auf 'nen "Old P4" (1,5 Ghz) zurück. bei ihm sind es komischerweise 20% - komische Analogie. :)

Was das mit dem OS angeht... ich hab mich da 'n bissel schlau gemacht und gehört, das mit Linux oft bessere Ergebnisse erzielt werden, da das nervige GUI von Windows (welches ja so fehlerhaft ist) entfällt. Was meinst Du dazu?

Interessieren würde mich vielleicht noch, was es mit dem "Client as a Service" (PARM -install) auf sich hat. Bringt das Vorteile mit sich? Würde das bei meinen Teammates, die z.T. kein NT (NT4, NT4.5 also 2000, NT5.1 also XP) verwenden auch funktionieren?

Zum Schluss noch: Wieso ist es nicht so einfach nachzuweisen, dass der Algorithmus nach einer Core-Verbesserung oder -Implementierung noch richtig läuft? Man kann doch ein kleines RC5-(x<64) Projekt durchlaufen lassen, und sehen ob das gewünschte Paket gefunden wird, oder ob die Cruncher Mist bauen, und das ganze Projekt (also alle Units) erneut gerechnet werden müssen. Oder noch einfacher: Ich schicke eine preparierte Unit in den neuen, verbesserten Client, die nach Fertigstellung ein bestimmtes Ereignis (je nach Fertigstellungszustand) auslösen soll. Das kann ja nicht so kompliziert sein. Oder was meinst Du worin das Problem besteht?


Liebe Grüße!

Gudi

warum du den alten client runtergeladen hast? ich schätze mal, du hast den installer runtergeladen, nicht das zip-file. oft hänt der installer etwas hinterher und enthält noch ne ältere version... siehe auch die release-dates auf der seite.

zum os: das is immer alles hörensagen, dass der client hier oder da schneller läuft. meines erachtens entweder meßungenauigkeiten oder (bei den größeren schwankungen) falsche einstellungen oder komische rahmenbedingungen. unter dos isses zB nicht viel schneller oder langsamer als unter linux... klar, wenn du win9x nimmst, wird's bestimmt ein bissel ekeliger sein... ist halt ein altes os mit nem (schon damals) out-of-date multitasking. das ist so ziemlich auch die gängige erfahrung, die die leute im ghn so gemacht haben im laufe der zeit...

mit dem client als service hat's nur aufsich, dass der client automatisch gestartet wird, wenn das system bootet. dh zB bei winNT, dass der client auch läuft, wenn sich noch niemand eingeloggt hat. das geht auch unter win9x. und der client läuft unsichtbar, ist also nicht im tray zu sehen.

zur verifikation des algorithmus. also in der theoretischen informatik ist die "programmkorrektheit" schonmal ein unendscheidbares problem... ;). das ist in der praxis auch meist zutreffend. wenn ein programm auf x eingaben ein fehlerfreies ergebnis liefert, heißt das ja noch lange nicht, dass auch das x+1 'ste ergebnis richtig ist. dh jemand muß den programmcode (prozessorspezifischer assamblercode an der stelle) per mit zettel und stift durchgehen und verifizieren. gerade bei komplexen asm-anweisungen ist das nicht so leicht... nat. gibt es vorher auch testpatterns, aber wie gesagt ist das keine 100%ige aussage. ein kleineres projekt würde keinen sinn machen, da die cores speziell für rc5-72 geschrieben sind.

TRON

14. Juli 2004, 03:11:56 Uhr #23 Letzte Bearbeitung: 04. Dezember 2010, 03:06:28 Uhr von TRON
Aha... das klingt logisch. Ich habe tatsächlich den Installer heruntergeladen. - Wieso frag' ich mich mittlerweile auch...

Was mich zu den Betriebssystemen noch interessiert ist, ob da ein großer Unterschied zwischen Win9x und DOS (Denk' nicht, dass ich Win9x verwende  ;) ) besteht. Klar könnte ich das selber testen (hab' ich auch vor...), aber ich hätte gerne ein paar Erfahrungswerte.

Was das mit dem "o-o-d Multitasking" angeht, da stimme ich vollkommen zu... gut das das mal jemand genauso sieht!

Das der Client als Service schon vor der Anmeldung läuft, ist mir bekannt, ich bin mit der Begrifflichkeit "Service" sehr gut vertraut. Auch programmiere ich... Meine Frage hat 'nen ganz anderen Hintergrund (Sorry ich habe im letzten Posting zu unkonkret gefragt!) Aber die Anspielung auf den "Service" darf ruhig in Verbindung mit der Überschrift dieses Threads gebracht werden. Mit anderen Worten... bringt der Service Geschwindigkeitsvorteile? (Ich möchte es nicht ausprobieren, da ich "-uninstall" nicht traue...) Oder ist mein Misstrauen unbegründet? Wenn es Fehler erzeugt, habe ich die gleich auf mehreren Maschinen.  :(

Zum Algorithmus... klar das dasx+1-te nicht korrekt sein muss. Ich finde aber, das das Beispiel nicht konkret genug ist. Naja vielleicht stecke ich meine Nase auch in Dinge, in die ich sie nicht stecken sollte... Zumindest denke ich das das Zettel+Stift Denkmodell sicher 'ne Berechtigung hat, aber doch etwas zu theoretisch für ein, bereits seit vielen Versionen existierendes, Programm ist. Sicherlich weiß ich nicht genau, was an den bestehenden Cores geändert wurde. zumindest aber die neuen müssten sich doch analog zu den alten verhalten, oder?
Was das mit dem kleineren Projekt angeht... was heißt ein kleineres Projekt bringt nichts? Der Keyspace verändert sich, viele Variablen und konstanten haben andere Werte, aber die Funktionen sind doch immer noch die selben, oder würde das im Programm zu viele Anpassungen verlangen? Ist das zu aufwendig?

Janko

-uninstall geht ohne porbs....


und eure sorgen möchte ich auch mal haben  ;D

mfg

Gudi

jo, -install und -uninstall machen eigentlich nur den nötigen registry eintrag, mehr nicht.

ja, zum algorithmus. warum ist das beispiel nicht konkret genug? hmm. also es gibt im client (wenn du dir die sourcen runterlädst) ne eingebaute anzahl an testpatterns (ich glaub so bei 20 rum? weiß nicht genau), die den core dann halt schon mal vortesten. läuft da alles glatt, kann der core submitted werden zu distri, dort wird er dann _per hand_ überprüft. ebend genau deshalb, weil sich die korrektheit durch "einfach ausprobieren" nicht beweisen lässt. ja, und am anfang steht ein core, der in c geschrieben ist. da kann man dann noch ziemlich gut sehen, dass der korrekt ist. die weiteren cores werden dann jedoch direkt in asm geschrieben, speziell für gewisse prozessoren. ich weiß nicht, ob du sowas schon mal gesehen hast... aber leg ruhig mal den core vom p4 neben den core vom amd athlon. da siehst du nicht viele parallelen. schlimmer noch beim core für die g4/g5 mac's. der algorithmus für altivec - einheiten ist nicht wirkich simpel... neben dem zettel und nem stift hat man dann nat. auch nen dickes specs-heft des betreffenden prozessors an der hand. und da rechnest du dann tatsächlich nach, was in welchem register steht.
ja und mit dem kleineren projekt... sobald du mit irgendwelchen shift-operationen irgendwas machst und fest damit rechnest, dass deine nutzdaten nun 72 bit lang sind, kannst du da nicht mehr viel mit irgendwelchen umgebungsvariablen ändern... die cores sind da zu sehr optimiert auf das spezielle problem. übrigens wäre es auch nix anderes als x richtige ergebnisse zu rechnen und dann hoffen, dass x+1 auch richtig ist... ;)

TRON

Hmmm... klingt interessant!

Ich werde das mal überprüfen. Mit 'c' komme ich ganz gut zurecht. Assembler habe ich nur ein Jahr unterrichtet bekommen - mal sehn ob ich da was verstehe.

Danke für die interessante Antwort!!!   :)

TRON

Also ich find da keine cores, oder irgendwas, was für mich interessant wäre!

Habe mir [http://www1.distributed.net/source/] angeschaut. Dann [http://www1.distributed.net/source/specs/opcodeauth.html] durchgelesen.
Später bin ich auf [http://cvs.distributed.net/viewcvs.cgi/], wo Fetch/Flush das einzig interessante zu sehn scheint!

Dann bin ich noch hier hin [ftp://ftp.distributed.net/pub/dcti/source/archives/], wobei dich das auf [http://www1.distributed.net/source/] mit dem Teil "Hier ist der Quellcode zu ein paar der anderen, schon veröffentlichten distributed.net-Programmen:" zu beziehen scheint.

Wo sind den nun die Kerne, die ich verbessern muss?   O0


          .::TRON::.

Gudi

http://http.distributed.net/pub/dcti/source/pub-20040528.tar.gz runterladen und entpacken,
dann im verzeichnis client\rc5-72\x86 zB für AMD der derzeit beste core: r72-go2.asm
viel spass. ;)

TRON

Cool - Danke!

Mal 'ne andere unqualifizierte Frage, wiso existiert die selbe Seite unter http://ghn.ath.cx/ und http://teamproxy.dyns.net/?

Liegt es daran, dass die 2Proxies haben, und eben die gleiche seite unter beiden Addressen erreichbar sein soll?


          TXH!

Gudi

damit erreichst du jeweils den gleichen server. die beiden urls sind aus fallback-gründen da. dh wenn ein dyn-dns dienst mal ausfällt, springt halt der andere ein (der client probiert dann halt den nächsten).

TRON

14. Juli 2004, 22:44:59 Uhr #31 Letzte Bearbeitung: 04. Dezember 2010, 03:02:30 Uhr von TRON
OK... hatte ich mir fast gedacht! Danke!

PS: Wieso ist bei den Clients defaultmäßig ein holländischer Server eingestellt? - Hab' ich da was verpasst? Das schreit doch geradezu nach Protest!  >:D

.::TRON::.

Keyfinder

Zitat von: .::TRON::. am 14. Juli 2004, 22:44:59 Uhr

   PS: Wiso ist bei den Clients defaultmäßig ein holländischer Server eingestellt? - Hab' ich da was vepasst?
         Das schreit doch geradezu nach Protest!  >:D

Ganz einfach, in Holland steht nunmal ein Server von Distri. Und das ist wohl der für uns "am günstigsten" stehende Server.
Hat nix damit zu tun, das wir den Käsköppen irgendwelche WU schenken oder so.

TRON

15. Juli 2004, 21:36:42 Uhr #33 Letzte Bearbeitung: 04. Dezember 2010, 02:58:32 Uhr von TRON
 :D Nein das hatte ich auch nicht vermutet - wäre ja auch zu schön!

Mal 'ne Frege wie schnell ist eigentlich ein Cray X1 Supercomputer? 10TFlops?

Mir wurde ein alter C1 (160MFlops) zum Verkauf angeboten. Ist das ernst zu nehmen? Das Ding ist von 1977 und so lahm wie 'n PC mit 233Mhz P2 CPU! - Antwortet doch mal!

Gudi

ich glaub bei rc5 kannste damit nix reißen... ist ja nichts optimiert. wenn's überhaupt nen client dafür gibt...  ::)

TRON

Zitat von: Gudi am 18. Juli 2004, 14:54:49 Uhr
ich glaub bei rc5 kannste damit nix reißen... ist ja nichts optimiert. wenn's überhaupt nen client dafür gibt...  ::)

Hmmm.... ja hast wohl recht. - Hätte ich auch bedenkem müssen!  ::)

Abgesehen davon gilt das Angebot eh' nicht mehr. Wahr wohl aber auch eher ein Fake.  :(


Trotzdem Danke!

TRON

19. Juli 2004, 00:03:26 Uhr #36 Letzte Bearbeitung: 04. Dezember 2010, 02:49:29 Uhr von TRON
Zitat von: Gudi am 14. Juli 2004, 16:58:42 Uhr
http://http.distributed.net/pub/dcti/source/pub-20040528.tar.gz runterladen und entpacken,
dann im verzeichnis client\rc5-72\x86 zB für AMD der derzeit beste core: r72-go2.asm
viel Spaß. ;)

Hab' mir übrigens den Assembler-Code mal angeschaut. Ist recht komplex. Wobei eher der Anfang der Datei. Das letzte Drittel geht. Wie ich das sehe 20+x mal Links u. Rechtsschieben oder so. Dann "verXORt" und Shifting. Ich denke da kann ich nichts machen. Ich habe es aber an einige Informatiker weitergegeben. - Die meinen auch dass sie da nicht wirklich viel optimieren können.

Einer von Ihnen meinte aber, dass er mal überprüfen will ob der ASM-Kern SSE kompatibel wäre. Dann könnte man ein und dieselbe Operation in der gleichen Zeit zweimal durchführen, d.h. unter Umständen 2 Units parallel bearbeiten. Mal sehen...

Gudi

die "2" in dem core-namen GO-2 steht übrigens dafür, dass zwei pipes gleichzeitig laufen... ist übrigens int/mmx - code.

TRON

Aha.

Hab' das ASM File jetzt zur Analyse geschickt... ware auf Antwort.



PS: Ich gebe die Suche nach Möglichkeiten in diesem "Teuflischen Forum" (666) auch weiterhin nicht auf!  ;D

Gudi