Zitat von bredator:

Jo, kann schon sein. Aber das ist weder sinnvoll, noch gebräuchlich. Da wäre der exorbitant hohe Stromverbrauch, der für den privaten Gebrauch oder gar fürs Spielen absolut nicht zu rechtfertigen ist, ebenso wie das Kühlsystem, das wohl kaum mehr unter den Schreibtisch passt. Und zu guter Letzt natürlich ein Preis, für den man einen Neuwagenkauf in Erwägung ziehen kann. ;)

Ich hatte ein Mal eine Dual-GPU-Karte. Für mein 3D-Design-Zeugs war die astrein (genauso wie meine beiden FireGL-Karten jetzt), allerdings im "normalen" Rechner nicht wirklich sinnvoll. Zwar waren besagte Berechnungen, die ich auf die GPUs ausgelagert hatte wesentlich schneller als auf der Quadcore-CPU, allerdings war das Ding ansonsten unbrauchbar. Am meisten haben mich dabei die Mikroruckler gestört, die auch heute noch ein Problem darstellen, das man nicht einfach wegargumentieren kann. Aber gut, ich glaube, wir kommen vom Thema ab. Es sind also 4 Karten, die via SLI miteinander verbunden werden können. Wie diese für sich nochmal aufgebaut sind, spielt dabei ja keine Rolle.

Zitat von Papa-Schumpf:

...Hmmm, was man mit 16 GPU - Kernen so alles anstellen könnte, ich denke unvorstellbar.

Zitat von ZER0-CooL:

Ich weiß nicht an was du denkst, aber ich frag mich gerade ob man damit schneller wäre als mit einer Rainbow Table bei Brute Force

Zitat von bredator:

??
Gerade dafür sind GPU-Systeme doch geeignet. Ich verstehe gerade nicht, was du mit dem Satz sagen willst.

Zitat von ZER0-CooL:

Äh okay, blöd formuliert, ich versuchs anders.
Ich frag mich welche Variante wohl schneller ist, direkt die Hashs mit den GPUs zu berechnen und zu vergleichen oder die Hashs aus einer Rainbow Table auszulesen.

Zitat von bredator:

Bei 16 GPUs vermutlich auch weiterhin die Rainbowtable. Allerdings die Rainbowtable mit den GPUs auslesen und vergleichen, wäre interessant. Alles andere wäre eh blödsinnig.

Zitat von ZER0-CooL:

Naja Rainbow Tables mit 10+TB sind halt doch etwas "lästig"

Zitat von ZER0-CooL:

Naja Rainbow Tables mit 10+TB sind halt doch etwas "lästig"

Zitat von Papa-Schumpf:

gibt doch auch Karten die mittlererweile 2 Dual-GPU´s haben, wären somit 8 Dual GPU´s oder eben 16 GPU-Kerne.

Das system was ich da im Kopf habe, hatte soweit ich weiß auch
4 16x PCi-Express slots und die Karten wurden der Kühlung wegen mit solchen flexiblen PCI-Express Slot Verlängerungen angeschlossen.

Zitat von Mystic-Car:

"Nur" 4 PCIe Karten? Mir fiel da gerade das Projekt "Fastra II" ein, dort sind es immerhin 7 PCIe Slots, mit 7 Grafikkarten.

Und mehr als 4 Grafikchips sind bei SLi doch gar nicht möglich?
Die zwei GPUs einer Multi-GPU Grafikkarte sind ja auch mit SLi "verbunden".

Zitat von Klischeepunk:

Ich komm nicht ganz mit, ich habe 2 mal exakt den gleichen Vorgang an dem sich nichts ändert, nur dass ich einmal auf bestehende Daten zurückgreife und im anderen Fall diese Datenbasis selbst erschaffen muss. richtig? falsch?

Es stellt einen Mehraufwand dar, diese Datenbasis zu schaffen, gehen wir nun davon aus, dass die Erschaffung eines Datensatzes weniger Zeit benötigt als das schlußendliche verwerten dieses Datensatzes, dann ist mein Maximaler Zeitgewinn 0 und in jedem anderen Fall Negativ. richtig? falsch?

Zitat von Klischeepunk:

Ah jetzt komm ich mit. nja, käm auf n Performancetest an und bedenke dabei in ner DB hast du suchbäume über die du dich orientieren kannst, in deiner Programmlogik müsstest du etwas vergleichbares abbilden .. $belibiger_hash abfeuern ist nicht die lösung, du hättest den anspruch an den hash unique zu sein, und sich nach bestimmten regeln aufzubauen (hashseitig), in ner DB kannst du hierfür die Indizierung nutzen und so optimierte Suchergebnisse erzielen.


Klar im besten fall würdest du dir "datei öffnen", "suchen" etc. sparen, und direkt "hash berechnen", "vergleichen", volltreffer. Aber die wahrscheinlichkeit ist zu niedrig.