Mein Ziel ist ein kleines C-Programm für Forschungszwecke möglichst günstig auf Hardware zu beschleunigen. Es handelt sich letztlich um simple verschachtelte Schleifen, die sich sogar ohne Verzweigungen implementieren lassen. Sie bestehen aus einigen wenigen einfachen Bit- bzw. Integer-Operationen: Inkrement, Shift, XOR, OR, AND, etc. und wenigen Zuständen. Die Laufzeit dieser Schleifen kann bis in die Monate gehen. Es gibt eine gigantische Zahl von Ausgangswerten, die in diesen Schleifen durchgerechnet werden sollen, so dass der Algorithmus prinzipiell sehr gut parallelisierbar ist aber für eine realistische Umsetzung auch parallelisiert werden MUSS, da die Gesamtlaufzeit aller Ausgangswerte sonst in die Jahrzehnte ginge. Bausteine die das Programm ausführen könnten, bräuchten praktisch keinen Datenspeicher, nur wenige Register, eine extrem simple ALU, einen minimalen Befehlssatz, so gut wie keine I/O (eine simple serielle Verbindung oder ein minimales Dual-Port-RAM würde reichen), keine FPU, keine MMU, keine Caches, keinerlei weitere interne oder externe Peripherie, aber einen möglichst hohen Takt und möglichst viele MIPS pro Euro. Jedoch hat der Algorithmus auch ein paar schwierige Eigenschaften. Zum einen ist die Laufzeit der Schleifen je nach Ausgangswerten extrem unterschiedlich (von Millisekunden bis Monaten) und es handelt sich um 64-Bit-Ganzahl-Operationen. Ich habe bisher keine Bausteine gefunden, die in der Lage wäre für begrenztes Geld viel Parallelität für meinen Algorithmus zu bieten. Alles was mir untergekommen ist, war technisch ungeeignet: GPGPUs benutzen SIMD statt MISD und sind fließkommazentriert und haben zu schmale Register. Herkömmliche CPUs andererseits sind viel, viel zu komplex und dadurch zu teuer für meine Anwendung. Meine letzte Idee ist eine Umsetzung auf FPGAs. Da ich das noch nicht gemacht habe, will ich mir Rat holen um möglichst den richtigen Weg zu nehmen. Habe ich etwas übersehen? Gibt es irgendwelche Prozessoren, die das können, was ich brauche? Wenn nicht, gibt es besonders geeignete FPGAs die ich mir für meine Zwecke anschauen sollte?
Wiw ganue sieht das System aus, in das das integriert werden soll? Ich persönlich würde mal vorschlagen, dass du, wenn der Algo sowieso schon in C läuft, auf eine GPU ausweichst und ihn mittels OpenCL / CUDA implementierst. Moderne GPUs sind ziemlich flink. Ich bezweifle, dass man ohne massiv Grips reinzustecken mit einem FPGA in absehbarer Zeit schneller wird. GPUs sind einfach in PCs zu integrieren. Haben teils tausende Cores und mittlerweile Unmengen an breitbandig angebundenem Speicher. Jordy schrieb: > Alles was mir untergekommen ist, war technisch ungeeignet: GPGPUs > benutzen SIMD statt MISD und sind fließkommazentriert und haben zu > schmale Register. Herkömmliche CPUs andererseits sind viel, viel zu > komplex und dadurch zu teuer für meine Anwendung. GPUs können Problemfrei mit 64 bit Zahlen rechnen: https://www.khronos.org/registry/OpenCL/specs/2.2/html/OpenCL_C.html Eine Implementierung auf GPU ist eigentlich relativ einfach. Ich denke du machst nichts kaputt, wenn du das mal am PC auf einer GPU testest. Wenn das aus irgendwelchen Gründen zu langsam sein sollte, kannst du immernoch versuchen auf etwas anderes auszuweichen. Da dann aber noch mehr performance rauszuholen wird dann aber kein Spaziergang.
Bezüglich des Systems bin ich offen. Letztlich muss irgendwie eine PC-Anbindung her. Mit CUDA habe ich mich zuerst beschäftigt. Und ich bin an einer Implementierung dran, auf einer 4000-Core-GPU. Dass das geht ist klar. So wie es aussieht wird das auch deutlich schneller als CPUs, aber es geht extrem viel Effizienz durch die unterschiedliche Schleifenzeiten und die 64-Bit-Integer-Operationen verloren. Für beides sind GPUs nicht gemacht und beides haut brutal ins Kontor.
Achja, Speicher haben GPUs natürlich viel. Meine hat 24GB. Nur brauche ich davon so gut wie nichts. Mir reichen im Notfall einige dutzend Bytes. Warum denkst Du wird eine FPGA-Implementierung so schwierig? Weil es einfach anspruchsvoll ist? Weil FPGAs technisch für mein Problem ungeeignet sind? Oder weil man sehr große teure FPGAs dafür bräuchte?
Jordy schrieb: > Warum denkst Du wird eine FPGA-Implementierung so schwierig? Weil es > einfach anspruchsvoll ist? Weil FPGAs technisch für mein Problem > ungeeignet sind? Oder weil man sehr große teure FPGAs dafür bräuchte? Ohne, dass du etwas mehr Infos rausrückst, kann dir das so genau keiner sagen. Wie viele Eingangswerte hat so ein Algorithmus-Durchlaufg und wie viele Ausgangswerte? Ist die Anzahl statisch oder dynamisch? Hängen die Durchläufe voneinander ab? Wie Gedenkst du, wenn der Algorithmus auch sehr kurzweilig sein kann, schnell genug Daten ins System zu bekommen, um viele prallele Rechenkerne zu füttern? Jordy schrieb: > Bausteine die das Programm ausführen könnten, bräuchten praktisch keinen > Datenspeicher, nur wenige Register, eine extrem simple ALU, einen > minimalen Befehlssatz, Im Zweifelsfall besteht hier die Möglichkeit den Algorithmuis fest in Logik zu gießen. FPGAs sind heutzutage zwar schnell und groß. Aber diese Begriffe sind sehr relativ. Ein 64bit Addierer kann, wenn es dumm läuft und der Router das nicht richtig auf die Kette bekommt, weil bspw. der FPGA langsam voll wird, durchaus zum Takt-Bottleneck werden. Einige hundert MHz Takt sollten bei einem entsprechenden FPGA und einer gut gepipelinten Architektur drin sein. Wenn der Algorithmus in direkte HW gegossen ist, kann man da schon schneller sein als eine GPU. abhängig, welche Operationen du noch brauchst, kann es sein, dass das Ganze dann nochmal massiv runter geht. JKlassiker wären Multiplikationen. FPGAs haben zwar häufig DPS Kerne eingebaut. Aber davion eben auch nur eine begrenzte Anzahl. Nicht vergleichbar mit den 4k Cores einer GPU. Jordy schrieb: > Achja, Speicher haben GPUs natürlich viel. Meine hat 24GB. Nur brauche > ich davon so gut wie nichts. Mir reichen im Notfall einige dutzend > Bytes. Das bezweifle ich. Du sprichst oben von größeren Ausgabemengen deines Algorithmus. Wo sollen die hin, wenn nicht in Speicher?
Jordy schrieb: > Zum > einen ist die Laufzeit der Schleifen je nach Ausgangswerten extrem > unterschiedlich (von Millisekunden bis Monaten) Das kann zum Problem werden. Denn selbst wenn du es schaffst, dass alle Schleifen parallel abgearbeitet werden, dann dauert das immer noch so lange wie eben der längste Schleifendurchlauf braucht. Mehr Informationen wären nützlich, also was muss mit einem Messwert genau gemacht werden? Gibt es Teile die sich nicht parallelisieren lassen? Lade auch gerne mal deinen C Code hoch. Vielleicht lässt sich der auch ganz ohne FPGA/GPU um mehrere Größenordnungen beschleunigen.
Jordy schrieb: > Achja, Speicher haben GPUs natürlich viel. Meine hat 24GB. Moderne FPGA-Systeme haben das auch: Mit einen 50 Euro-FPGA kann man wenigsten 2GB, die größeren 4GB treiben.
> Warum denkst Du wird eine FPGA-Implementierung so schwierig? Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, ist sehr schwierig (wenn überhaupt machbar).
Warum überhaupt eigene Hardware? Warum nicht bei einem Cloud-Anbieter (AWS & Co) ein paar Tausend Nodes mieten und klassisch auf der CPU rechnen? Eventuell macht es Sinn ARM-Nodes mit vielen Kernen zu mieten, das könnte billiger sein. Eventuell den Assembler-Code handoptimieren und/oder Beschleuniger wie NEON oder AVX mit einbeziehen. Wäre eine schöne Übung... Was wird das, Hash-Algorithmen (SHA & Co) brechen?
M. H. schrieb: > Ich persönlich würde mal vorschlagen, dass du, wenn der Algo sowieso > schon in C läuft, auf eine GPU ausweichst und ihn mittels OpenCL / CUDA > implementierst. Moderne GPUs sind ziemlich flink. OpenCL hätte den Vorteil das es das sowohl für GPUs wie FPGAs gibt. Ich habe aber keine Ahnung ob man da nur einen Schalter umlegen muss oder ob es auf komplett neu schreiben raus läuft wenn man die Platform ausnutzen will. https://www.intel.de/content/www/de/de/software/programmable/sdk-for-opencl/overview.html Schwierig deinen Fall einzuschätzen aber bei purer Rechenleistung und Speicherbandbreite liegen GPU vorne, FPGA dagegen bei sonstigem IO.
Mit den entsprechenden HLS-Tools kann man schon recht flott eine linear ablaufende Operationenkette in HW giessen, die GPUs um ein Vielfaches schlägt, sofern sich alles schön auf parallel arbeitente Pipelines demultiplexen lässt. Entweder sind diese Tools aber recht proprietär, erfordern einiges an Einarbeitung, sind nicht billig, usw. Sobald komplexere Hardware-Schleifen und Ablaufverzweigung im Spiel sind, kommst du mit HLS nicht viel weiter und musst manuell eingreifen. Wenn du dann so eine Einheit als Prototyp hat, kannst du den Rest (die Zahl zum 'Vielfachen') extrapolieren und deine Frage selber beantworten, wenn du deine Berechnung im Konkreten nicht offenlegen willst (sehr verständlich). Ansätze in Stichworten: - Vivado HLS anwerfen, Logikbedarf ermitteln - Die Chose in Python modellieren (myHDL oder migen), bei der FPGA-Plattform hast du dann freiere Wahl Für den Rest allerdings bleibt Wegstrecke, um die Daten ins/aus dem FPGA zu kriegen. Mein Favorit ist Gigabit Ethernet/UDP, weil es da genug Fertiglösungen gibt und sich das Ganze wunderbar skaliert. Für viel Ping-Pong-Transaktion mit dem PC ist dann wieder PCIe sinnvoller.
Jordy schrieb: > Bausteine die das Programm ausführen könnten, bräuchten praktisch keinen > Datenspeicher, nur wenige Register, eine extrem simple ALU, einen > minimalen Befehlssatz, so gut wie keine I/O (eine simple serielle > Verbindung oder ein minimales Dual-Port-RAM würde reichen), keine FPU, > keine MMU, keine Caches, keinerlei weitere interne oder externe > Peripherie, aber einen möglichst hohen Takt und möglichst viele MIPS pro > Euro. Das kann nicht sein. Irgendwie müssen die Schleifen ja mit Daten gefüttert werden. Und wenn der Algorithmus wirklich so simpel ist, wie du ihn dargestellt hast, dann verblaßt dessen Laufzeit völlig im Vergleich zu dem Aufwand, der nötig ist, um Ein- und Ausgangswerte zu bewegen.
Es handelt sich um einen Algorithmus zur Bestimmung der Performance von CRC Polynomen. Also NICHT die Berechnung von CRCs, das ist trivial, sondern die Bewertung aller möglichen Polynome. Bitte lasst uns darüber nicht all zu sehr diskutieren, da gab es Leute die sich ausführlich mit dem Problem auseinandergesetzt haben. Ich will den Algorithmus nur portieren. Der ist nichts geheimes. Eine C-Implementierung kann man von Prof. Koopman runterladen. Aber derzeit halt nur für die Ausführung auf CPUs. Also mit vielen Branches und Optimierungen die für eine CPU vorteilhaft sind. Der Algorithmus hat im Minimalfall zwei Eingangswerte: Das Polynom und seine Bitbreite. Ergebnis ist eine Reihe von Payloads (bei 64-Bit-Polynomen max. etwa 30 64 Bit-Werte). Eingabeparameter sind also statisch, Ausgabewerte sind in der Anzahl begrenzt. Die Durchläufe sind unabhängig von einander. Die Dauer der Algorithmendurchläufe wird sich mitteln. Das Gute an dem Algorithmus ist: Schwierig sind vor allem die breiten Polynome, also 30 Bit aufwärts. Die brauchen im Mittel sehr lange für die Berechnung, so dass die Host-PC-I/O kein Problem werden wird. Höhere Datenmengen fallen nur bei kleinen Polynombreiten an, aber die sind so schnell auf CPUs durchgerechnet (im Bereich von Sekunden bis Wochen), dass ich dafür keine spezielle Hardware brauche. Das Höchste wären vermutlich kleine Puffer um die unstete Kommunikation des angebundenen Host-PC auszugleichen. Multiplikation/Division wird nicht benötigt. Für die Kernberechnung nichtmal Addition/Subtraktion. Hier eine Liste von Operatoren: increment, decrement, right shift by one, XOR, test LSB (für bedingtes XOR). Und für jede der drei verschachtelten Schleifen würde ein Zähler gebraucht (1x6Bit, 2x64Bit). Allerdings kommen mehrere Abbruchbedingungen hinzu, die den Population-Count des Akkumulators benötigen. Dieser wird mit verschiedenen Grenzwerten verglichen und entscheidet, ob der Algorithmus fertig ist oder nicht. Diese Vergleichswerte könnten entweder durch -2 oder -3 vom 6-Bit-Zähler gebildet werden oder (wenn das zu aufwändig ist) könnte man einfach zusätzliche 6-Bit-Zähler mit anderem Startwert anlegen und mit diesen vergleichen. Müssen Zähler im FPGA synthetisiert werden ob gibts die auch in HW? Ein wenig Zusatzaufwand könnte noch abfallen, da eine der drei Schleifen derzeit als rekursive Funktion mit geringer Tiefe implementiert ist. Das läßt sich aber immer irgendwie als Schleife umschreiben. Um einen Vorteil gegenüber einer GPU zu erreichen, müsste jeder FPGA-"Kern" definitiv unabhängig arbeiten, also Input holen sobald die vorige Berechnung abgeschlossen ist. Es gibt vielleicht verschiedene Ansatzpunkte. Bei der CUDA-Implementation werde ich, um den Code einfach zu halten, zumindest anfangs nur die innerste der drei Schleifen auf der GPU laufen lassen. Den Rest macht die CPU. Das ginge sicher auch für ein FPGA bei breitbandiger Anbindung. Das hier ist die innerste Schleife inklusive Rekursion (maximale Rekursionstiefe ist 64, wenn ich mich recht erinnere).
1 | bool Searcher::recurse(crc_t pAccumulator, payload_t pMaxLength, bc::number_t pRecursionsLeft) |
2 | {
|
3 | crc_t aRollingValue = mPolynomial; |
4 | |
5 | for (payload_t aLength = 1; aLength < pMaxLength; aLength++) |
6 | {
|
7 | aRollingValue = (aRollingValue >> 1u) ^ ((aRollingValue & 1u) ? aPolynomial : 0u); |
8 | const crc_t aNewAccumulator = aRollingValue ^ pAccumulator; |
9 | |
10 | if (populationCount(aNewAccumulator) <= pRecursionsLeft) |
11 | {
|
12 | return true; |
13 | }
|
14 | |
15 | if (pRecursionsLeft > 0) |
16 | {
|
17 | if (recurse(aNewAccumulator, aLength, pRecursionsLeft - 1)) |
18 | {
|
19 | return true; |
20 | }
|
21 | |
22 | if (populationCount(aNewAccumulator ^ mpolynomial)) <= (pRecursionsLeft - 1)) |
23 | {
|
24 | return true; |
25 | }
|
26 | }
|
27 | }
|
28 | |
29 | return false; |
30 | }
|
Hab früher selbst im High Performance Bereich mit GPGPUs und FPGAs gearbeitet. Wenn du nicht bereits viel Wissen/Erfahrung mit FPGAs hast bzw. das Problem für die GPU ungeeignet ist, hast du gegen GPUs keine Chance. Dein Problem scheint super für die GPU zu passen, nur die unterschiedlichen Schleifenlängen killen dir die Performance (Thread divergence/Warp Split). Folgende Idee: Du speicherst den Berechnungsstaus pro Thread im globalen Speicher. Beim Start holt sich jeder Thread den State und macht nur X Schleifendurchgänge pro Aufruf. Vor dem Beenden schreiben alle ihren Berechnungsstatus zurück in den globalen Speicher. Die CPU verwaltet den Berechnungsstatus und tauscht „fertige“ States gegen Neue aus. Bonus Punkte wenn du mit zwei Stateblöcken arbeitest. Die GPU bearbeitet einen, während der andere von der CPU kuriert wird. Dann langweilt sich die GPU in der Zwischenzeit nicht. Pass beim Zugriff auf den Globalen Speicher auf dein Zugriffsmuster auf. Ansonsten ruinierst du dir die Bandbreite. Kenn jetzt dein Problem nicht im Detail, aber vielleicht hilfst ja.
foobar schrieb: >> Warum denkst Du wird eine FPGA-Implementierung so schwierig? > > Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, > ist sehr schwierig (wenn überhaupt machbar). Spässle g'macht?? Die derzeit schnellste GPU kriegt gerade mal die halbe Bandbreite dessen hin, was ein aktueller Ultrascale packt und die Versal mit ihren Vektor-Alus schlagen jede GPU, weil sie nicht erst umständlich was laden und entladen müssen und dann an der externen Bandbreite laboriert.
@ Jordy: Das ist schon mal nix mit "mal eben durch die HLS kloppen". Ob sich das so elegant manuell in V*HDL umsetzen laesst, ist schwer zu beurteilen, ungut ist schon mal eine Abbruchbedingung in der obigen Art, das bewirkt auch auf einer CPU einen teuren Pipeline-Flush. Sonst ist sowas
1 | aRollingValue = (aRollingValue >> 1u) ^ ((aRollingValue & 1u) ? aPolynomial : 0u); |
2 | |
3 | const crc_t aNewAccumulator = aRollingValue ^ pAccumulator; |
auch m.o.w. trivial in einem Cycle zu schaffen. Frage waere, ob sich die Abbruchbedingung anders verarzten laesst (wenn ein Wort-Stack in der Groessenordnung um 64 reicht). Ist noch nicht klar, wie sich obiges mit 'populationCount()' pipelinen liesse. Die Rekursion muesste man schon mal aufloesen und in Hardwareschleifen umstricken. Ansonsten ist das eine interessante Anwendung. Nehme mal an, dass auf hoeherer Ebene bereits Reduktion stattfindet? (Kenne besagten C-Algo nicht).
Mit einem Stack man man strukturell schon komplett verloren und mit der Nutzung von XI HLS bekommt man eine ausgerollte Version einer CPU-action-pipe, wie ich das gerne nenne: Es wird das in VHDL gegossen, was eine CPU machen müsste, um den Rechenschritt zu lösen. Um das effektiv zu machen, muss man aber angepasste Schaltungen erfinden! Jordy schrieb: > Das hier ist die innerste Schleife inklusive Rekursion (maximale > Rekursionstiefe ist 64, wenn ich mich recht erinnere). Bei dynamischen Rekursionstiefen muss selbige virtuell verwaltet werden, d.h. alle möglichen Prozessschritte müssen mit ALLEN Parametern übergeben werden und dann jeweils ein Rekursionsschritt durchgeführt werden. Das kann man in einem FPGA in einer linearen pipeline machen. Man MUSS es auch so machen, wenn man keine Annahmen über die Dimension des Problems machen kann. Wenn man das kann, ist eine Rekursion als n-dimensionale pipeline zu entwerfen und auch gut zu optimieren, wenn man die Produktsumme der Dimensionen in die Nähe einer 2hochN-Zahl kommt. Als Beispiel verwende ich in meinem Synthesizer eine interative Filterstruktur, welche die 16000:16384 realisiert und irgendwo dafür von 125 auf 128 übersetzt. Dazu braucht man die Dimension 5*5*5. Die füllen die 128 sehr gut. So eine Struktur kann man statisch bauen. Für das Problem wie es sich hier darstellt, muss eine Rekursion in eine Iteration übersetzt werden und bei jedem Schritt eine Verwaltung hinein, die prüft, ob ein neues Element oder ein altes mit Interationsprogress in die pipeline geworfen werden soll. Als Rechentempo bekommt man bei einen durchschnittlichen FPGA dann 100 bis 200 MHz, je nachdem wie breit die MUL / ADD sind. Der Rest der Dimension wird in die pipeline gedrängt. Damit ergibt sich u.a. die Forderung, dass je Iterationsschritt = Rekursion mit Ergebnissen solange gewartet werden muss, bis diese aus der pipeline kommen. Die Anzahl der "Kanäle" = "Szenarien" = "unterschiedliche Ansätze" KANN / MUSS groß genug sein. Konkret dürften solche Rechnungen wie bei dir mal locker 50-100 pipeline steps verbraten. DAS wird dann der limitierende Faktor. Wird durch die Zahl der Kanäle oder der unabhängigen Ansätze diese Zahl nicht ausgelastet, wird es weniger effektiv und man bekommt Zeitlücken. Das gleiche gilt, wenn man die Zahl der unabhängigen Ansätze nicht so hoch bekommt, wie man die pipeline- Strukturen parallelisieren kann. Idealerweise ist die Zahl der parallelen Pfade genau so groß und minimal kleiner, als die pipeline Länge, damit immer dann, wenn ein Datum fertig ist, es entweder vorne in die eigene oder in eine andere freie reingeworfen werden kann. Damit ist es dann EGAL, wie sich die Länge der Rekursionen verteilt, also ob es mal wenige lange oder viele kurze gibt und es ist egal, wieviele man davon parallel nutzt. Ansonsten gibt es wieder viele leere time slots. Für ein solches Problem habe ich eine Architektur entworfen, welche die pipelines verwalten kann. Sie wird in einer industriellen Anwendung sowie in meinem Synthi eingesetzt. Um sie zu portieren, braucht es aber die Randbedingungen des Problems, weil die Verwaltungsstrukturen eingestellt werden müssen, also die Signale, welche die MUX an den pipe-Eingängen bedienen. Zudem müssen dann FFs ausgegossen werden und ein sinnvolles Gesamttiming gefunden werden. Das ist meistens der Killer, die ganzen Daten, die mitgeschleppt werden müssen, in REGs zu halten, um sie schlagartig in die neue pipe kopieren zu können. Da muss man u.U. auch händisch mitdenken und eine partielle optimierung finden, also festlegen, wie dicht man das drängen will und wieviel Verwaltung und Ausgleichs-FF man hat. In meinem Synth ist das so gelöst, dass die rechnenden Einheiten, immer ein bestimmtes Vielfaches ihre Sub-Kanalzahl an Latenz generieren, damit man FFs sparen kann. Ich sehe bisher keine Möglichkeit, das irgendwie zu automatisieren, daher bräuchte man wirklich die step-Analyse der Formel, als einen Graphen, der timing-genau angibt, was wann womit verrechnet werden soll und wie die Querabhängigkeiten sind. Davon hängt ab, wie viele unabhängige pipes man nebeneinander bekommt. Ideal sind Rechnungen mit Enscheidungen im JA/NEIN-Muster, weil man die Folger schon als 2 Szenarien in die Folge-pipe werfen kann und sich dann das richtige schnappt, sobald das Ergebnis da ist. Was man generell sagen kann: Die Struktur lohnt sich bei sehr breiten Daten und vielen Kanälen, die unabhänig laufen. "Breite Daten" sind solche, die mal wenigstens im Produkt 100x50 Bit haben, damit der Verwaltungsaufwand drum herum klein bleibt.
Jordy schrieb: > Mein Ziel ist ein kleines C-Programm für Forschungszwecke möglichst > günstig auf Hardware zu beschleunigen. Jordy schrieb: > Es handelt sich um einen Algorithmus zur Bestimmung der Performance von > CRC Polynomen. Also NICHT die Berechnung von CRCs, das ist trivial, > sondern die Bewertung aller möglichen Polynome. Da du alle Polynome durchrechnen willst, braucht man deine Arbeit ja nur ein mal zu machen, danach weiss man ja dann alles. Darum finde ich es etwas übertrieben, dafür extra Hardware zu bauen/zu kaufen die danach in den Keller wandert. So wie du den Algorithmus beschreibst (parallelisierbar ohne gegenseitige Abhängigkeit, kleine Ein-/Ausgabedatenmengen, wissenschaft) klingt das für mich nach der perfekten Anwendung für BOINC: https://boinc.berkeley.edu/ oder vielleicht einfacher sich an ein Meta-Project zu wenden wie z. B. Yoyo: https://www.rechenkraft.net/yoyo/
Berkley bei kritischen mathematischen Problemen mitlesen zu lassen, damit sie gleich die Resultate haben ... hm (?)
Jürgen S. schrieb: > Mit einem Stack man man strukturell schon komplett verloren Nicht zwingend, es gibt genau fuer solche Zwecke dedizierte Stack-Maschinen, die sind auch klein genug, dass man einige davon parallel auf einem FPGA roedeln lassen kann. Geht etwas in Richtung der auf beiden Ufern (Hardware, Software) vergessen gegangenen Transputer-Konzepte. Aber da ist nichts mit HLS a la Xilinx, man muss sich den Mikrocode manuell entwerfen/auf das Kernproblem anpassen. In klassischer HDL ist das kaum noch sinnvoll machbar, insofern bliebe das fuer eine solche Anwendung ein teurer akademischer Spass.
Kritiker schrieb: > Berkley bei kritischen mathematischen Problemen mitlesen zu lassen, > damit sie gleich die Resultate haben ... hm (?) Wenn du dein eigenes BOINC Projekt hast, musst du auch eigene Server betreiben um Arbeit zu verteilen/einzusammeln. Da liest Berkley nicht mit (ausser die Arbeitspakete die sie vielleicht für dich rechnen).
@InvalidFacts Ich werde das was Du sagst auf jeden Fall beachten. Vielen Dank! Denn mein erstes Ziel ist die GPU-Implementierung. Im Augenblick bin ich aber noch an Test-Code dran, damit ich prüfen kann, ob die alternativen Implementierung tatsächlich die identischen Ergebnisse bringen.
@strubi Stack-Maschinen sind mir kein Begriff. Hast Du irgendwas besonders lesenswertes bei der Hand? Bitte bedenke, dass ich mit FPGAs noch nichts gemacht habe. Welche Sprache, welche Entwicklungsumgebung und welche FPGA-Familie würdest Du empfehlen? Im Augenblick bin ich noch ziemlich am schwimmen. Es hat ja Beiträge gegeben, die sich sicher sind, dass eine FPGA-Optimierung möglich ist und andere, die das für unmöglich halten.
@christophz Das Problem ist so komplex (und zu dem nach oben offen)... die Hardware kann garnicht speziell genug sein. Nur das Geld ist ein Limit. Denn noch ist es ein Hobbyprojekt.
In jedem Fall danke ich für die vielen Hinweise. Was ich definitiv verstehe ist, dass die Schwierigkeit des Problems nicht zu unterschätzen ist und, dass ich mit High-Level Sprachen nicht weit komme. Auch, dass ich nicht jeden X-beliebigen FPGA nehmen kann/sollte. Unter der Annahme, dass eine effiziente Umsetzung möglich ist: Welche Software- und Hardware Plattform würdet ihr mir für einen Versuch empfehlen? Dass mein Weg sehr weit wird, dessen werde ich mir bewusst :-) Um so mehr muss ich mit der erfolgversprechendsten Hardware und Software anfangen!
Bernhard L. schrieb: > Welche Software- und Hardware Plattform würdet ihr mir für einen Versuch > empfehlen? Software von FPGA Herstellern, also Vivado und Quartus. Da ist jeweils ein Simulator mit dabei und auch IPs der Hersteller um die DSP-Blöcke in den FPGAs möglichst gut zu nutzen. Jeder DSP im FPGA hat/ist quasi eine kleine ALU wenn man den so nutzen möchte. Das ist die Lektüre zu den DSP48E2 Blöcken: https://www.xilinx.com/support/documentation/user_guides/ug579-ultrascale-dsp.pdf Bernhard L. schrieb: > Auch, dass ich nicht jeden X-beliebigen FPGA nehmen kann/sollte. Da nimmst du erstmal gar keinen. Das lässt sich alles ganz ohne FPGA zusammenbauen. Iin der Synthese siehst du dann wie viele Ressourcen das so braucht. Und davon machst du dann abhängig welches FPGA du kaufen magst/musst oder ob du das lieber doch noch weiter optimierst damit das weniger Ressourcen braucht und in ein günstigeres FPGA passt.
:
Bearbeitet durch User
Ich vermute die Auswahl zwischen Vivado und Quartus entspringt der Entscheidung ob ich Xilinx oder Intel FPGAs verwenden will. (Ich gehe davon aus, dass die jeweilige Software auch nur die Bausteine des Herstellers unterstützt) Kannst Du mir bei dieser Entscheidung helfen? Gibt es technologisch entscheidende Unterschiede? Preisliche? Bezüglich Größe? Sonstige Unterschiede die für meine Anwendung entscheidend sein könnten? Oder ähneln sich die Produkte inzwischen so stark, dass ich das vernachlässigen kann? Wenn die Unterschiede nicht ins Gewicht fallen, wäre die Erlernbarkeit der IDE ein gutes Entscheidungskriterium für mich. Ich bin mir nicht sicher, wie nützlich die DSPs mir sein werden. Voraussichtlich werde ich keine Multiplikation und Addition benötigen. Andererseits lassen sich offenbar die ALUs zusammenschalten für Bitbreiten >48 und Logikfunktionen beherrschen sie auch. Ich werde wohl einfach ausprobieren müssen.
Bernhard L. schrieb: > Es hat ja Beiträge > gegeben, die sich sicher sind, dass eine FPGA-Optimierung möglich ist > und andere, die das für unmöglich halten. Dazu bringe ich immer mein Waldbetrachtungsbeispiel: 2 Förster berichten von ihren Erfahrungen im Wald. Der eine sagt: "Im Wald gibt es Rehe". Der andere sagt: "Im Wald gibt es keine Rehe". Was schlussfolgern wir? Meine Behauptung: Im angedachten FPGA-Wald ließen sich deine rechnenden Rehe züchten und ernähren. Die Frage ist nur: - schafft man es, die Genetik für sie zu definieren? - wieviel Aufwand ist es, sie zu erschaffen - wieviele Rehe braucht man überhaupt, um die Rechnung zu schaffen? - wie muss man sie positionieren und komunizieren lassen - wie groß muss der Wald sein - wieviel fressen die Rehe? Was man sagen kann: Holz ist derzeit sehr teuer und kaum zu beschaffen.:-) Gfs sind normale, durchschnittlich schlaue Rehe ohne Genmodifikation in einem anderen Wald einfacher zu halten.
:
Bearbeitet durch User
Bernhard L. schrieb: > Ich vermute die Auswahl zwischen Vivado und Quartus entspringt der > Entscheidung ob ich Xilinx oder Intel FPGAs verwenden will. Bernhard L. schrieb: > Kannst Du mir bei dieser Entscheidung helfen? Ja. Fälle die Entscheidung nicht sofort. Guck dir an wie du das Problem optimiert bekommst mit dem was die FPGAs der beiden Hersteller bieten. Und dann entscheide dich. Bernhard L. schrieb: > Wenn die Unterschiede nicht ins Gewicht fallen, wäre die Erlernbarkeit > der IDE ein gutes Entscheidungskriterium für mich. Ist eher nebensächlich. Du kannst deinen Code mit einem Texteditor schreiben und mit Gratissoftware wie Modelsim simulieren. In Quartus/Vivado drückst du dann nur noch auf Synthese und guckst was deine Beschreibung an Ressourcen im ausgewählten FPGA braucht. Bernhard L. schrieb: > Ich bin mir nicht sicher, wie nützlich die DSPs mir sein werden. Ich mir auch nicht. Aber da DSPs feste Hardware sind können die sehr hoch getaktet werden. Wenn du einen Funktionen aus LUTs zusammenbauen lässt kann es sein, dass das langsamer wird. Die DSPs sind ausserdem sehr schön an die BlockRAMs angebunden. Bernhard L. schrieb: > Ich werde wohl > einfach ausprobieren müssen. Exakt! Jürgen S. schrieb: > Gfs sind normale, durchschnittlich schlaue Rehe ohne Genmodifikation in > einem anderen Wald einfacher zu halten. Guter Punkt! Vielleicht wäre es der einfachste Weg für eine kurze Zeit viele Instanzen bei Amazon rechnen zu lassen. Das könnte deutlich günstiger sein als jetzt >> 1 Mannjahr in Entwicklung zu verbraten.
> Es hat ja Beiträge gegeben, die sich sicher sind, dass eine FPGA- > Optimierung möglich ist und andere, die das für unmöglich halten. Ich denke, das bezieht sich auf meine Aussage: > Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, > ist sehr schwierig (wenn überhaupt machbar). Die Betonung liegt dabei auf "schneller als eine hochgezüchtete GPU". Das es per FPGA überhaupt möglich ist, wird, denke ich, niemand bestreiten.
foobar schrieb: > Ich denke, das bezieht sich auf meine Aussage: >> Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, >> ist sehr schwierig (wenn überhaupt machbar). > > Die Betonung liegt dabei auf "schneller als eine hochgezüchtete GPU". Unklar. GPUs sind auf ganz andere Dinge optimiert. Wenn es hier um sehr viele parallele Logikfunktionen geht, dann könnte das schon dass eine FPGA Lösung am Ende deutlich schneller ist. Bei diesen Cryptominern ging es am Anfang auf CPUs los, dann ging es auf GPUs, dann auf FPGAs und dann zu ASICs. (Wobei Manches - speicherintensive Crypto - weiterhin auf GPUs geminet wird.)
foobar schrieb: >> Es hat ja Beiträge gegeben, die sich sicher sind, dass eine FPGA- >> Optimierung möglich ist und andere, die das für unmöglich halten. > > Ich denke, das bezieht sich auf meine Aussage: >> Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, >> ist sehr schwierig (wenn überhaupt machbar). > > Die Betonung liegt dabei auf "schneller als eine hochgezüchtete GPU". > Das es per FPGA überhaupt möglich ist, wird, denke ich, niemand > bestreiten. Dass es per FPGA möglich ist, möchte ich nicht bestreiten, aber ob es für den TO möglich ist? Gustl B. schrieb: > foobar schrieb: >> Ich denke, das bezieht sich auf meine Aussage: >>> Eine FPGA-Implementierung, die schneller als eine hochgezüchte GPU ist, >>> ist sehr schwierig (wenn überhaupt machbar). >> >> Die Betonung liegt dabei auf "schneller als eine hochgezüchtete GPU". > > Unklar. GPUs sind auf ganz andere Dinge optimiert. Wenn es hier um sehr > viele parallele Logikfunktionen geht, dann könnte das schon dass eine > FPGA Lösung am Ende deutlich schneller ist. Bei diesen Cryptominern ging > es am Anfang auf CPUs los, dann ging es auf GPUs, dann auf FPGAs und > dann zu ASICs. (Wobei Manches - speicherintensive Crypto - weiterhin auf > GPUs geminet wird.) Wenn er die gleichen Ressourcen in die Entwicklung steckt, wie die Cryptominer ... vielleicht. Ich habe keine Erfahrung mit dem Problem des TO, aber bis jetzt habe ich hier nichts gelesen, was einer effizienten Implementierung auf der GPU im Wege stehen würde.
Eine Implementierung für GPUs geht vermutlich sogar schneller. Und für CPUs in ordentlich parallel noch schneller. Da sollte er wirklich durchrechnen wie viele CPU-Kern-Sekunden er braucht und das gegen Entwicklungskosten + GPU-Sekunden oder so stellen.
Gustl B. schrieb: > Gratissoftware wie Modelsim simulieren wobei man sagen muss, dass ModelSIM nur bei Altera gratis ist. Will man Xilinx-Designs compilieren, muss man die LIBs erstellen und scheitert oft trotzdem immer schneller, weil Xilinx dazu übergeht, jeden Krümel an VHDL zu verschlüsseln. Kann also sein, dass das Angebot Alteras, nämlich einen freien Simulator zur Verfügung zu stellen, doch wieder mehr zieht und sich mehr auf Altera stürzen, nachdem die Produktpalette und das CORE-Angebot in der letzten Dekade dafür gesorgt hatte, dass auch Bastler mehr mit Xilinx begonnen haben. Gustl B. schrieb: > bei Amazon rechnen Bei Amazon???
Gustl B. schrieb: > könnte das schon dass eine > FPGA Lösung am Ende deutlich schneller ist. Das ist in aller Regel sogar so. Und das ist so, weil ich im FPGA die Hardware genau so bauen kann, dass sie die Aufgabe optimal packt. Konkret dürfte hier beim Integer auch ein großer Vorteil der CPUs/GPUs wegfallen.
Ja, bei Amazon kann man rechnen lassen. Mit sekundengenauer Abrechnung. Mit sehr vielen CPU Kernen. Nennt sich EC2.
Hier gibt es ja anscheinend ein paar Leute, die mit FPGA zu tun haben. Mich würde mal interessieren wie die Hardware sich preislich vergleicht. Wieviel kostet aktuell ein FPGA System das ~1e12 64Bit-Integer Operationen schafft in Einzelstückzahl?
Bernhard L. schrieb: > @strubi Stack-Maschinen sind mir kein Begriff. Hast Du irgendwas > besonders lesenswertes bei der Hand? Nicht wirklich, da solche Architekturen eher Nischendasein fuehren. Es gibt ein paar interessante Referenzen wie ZPU, oder die J1 (sehr kompakt). Spannend sind noch die 'alten Sachen': http://people.cs.bris.ac.uk/~dave/transputer.html Ich denke aber, fuer deine innere Schleife brauchst du das nicht, hoechstens fuer das balancierte Fuettern deiner n-fach instanzierten Pipelines. Da du ja eine Rekursionstiefe von max. 64 hast, kannst du die Rekursion relativ ueberschaubar 'entrollt' ausmodellieren. Unklar war mir beim Drueberlesen, was populationCount() macht. Geht's bei der Geschichte um die Hamming-Distanz? D.h. zaehlt populationCount die gesetzten Bits? Da gibt es diesbezueglich in der Hash-Industrie (kleines Wortspiel..) schon FPGA-Implementierungen die richtig Durchsatz machen. > Bitte bedenke, dass ich mit FPGAs noch nichts gemacht habe. Welche > Sprache, welche Entwicklungsumgebung und welche FPGA-Familie würdest Du > empfehlen? > Mein Favorit ist bereits genanntes myHDL zum Anfangen. Es gibt zwar eklige Limitierungen bei der Konversion in die Transfersprachen (VHDL oder Verilog), und bei der Generierung von Logik im HLS-Sinne, aber fuer eine Machbarkeitsstudie machst du da wohl am wenigsten Baustellen auf. Bei den FPGAs bringt die ganze Diskussion oben betr. DSP-Elementen nur Verwirrung, meist sind die so verteilt, so dass bei der Kaskadierung/Massen-Instanzierung die Performance in die Knie geht. Da du v.a. XOR-Gates brauchst, sind die eh nicht sonderlich dienlich. Also kannst du jegliche Vorauswahl mal offen lassen (Rhetorische Frage: Wieviel Zeit hast du, um dich mit den Tools rumzuschlagen..)
mh schrieb: > Wieviel kostet aktuell ein FPGA System das ~1e12 64Bit-Integer > Operationen schafft in Einzelstückzahl? Ich nutze FPGAs nicht, weil ich x hoch y 64Bit-Integer Operationen pro Sekunde machen muß, sondern aus vielen anderen Gründen. Einer ist z.B. weil bestimmte Daten zu einem ganz bestimmten Zeitpunkt gemessen oder getriggert werden müssen. Und wenn eine Rechenoperation 17 Bit braucht und die andere 28, dann wird das genau so implementiert wie benötigt. Und mehr als 24 Bit wird bei Messdaten selten benötigt, weil die Sensoren i.d.R. gar nicht die Dynamik haben. In Hardware macht es einen erheblichen Unterschied, ob ich addieren/subtrahieren will oder multiplizieren oder gar dividieren. Der nächste Unterschied ist, ob ich das für 8 Bit brauche oder für 52 Bit. Das hat alles Einfluß auf die mögliche erreichbare Taktrate. Als nächstes kommt die Frage zu zulässigen Latenzen. Ein mittlerer Xilinx Artix XC7A50T hat 120 DSP Slices. Damit könntest du theoretisch 120 parallele Multiplikation (25 Bit x 18 Bit) ausführen und das Ganze vielleicht mit 200 MHz takten. Als Milchmädchenrechnung sind das 24 Milliarden Multiplikationen pro Sekunde. Ein Evalboard kostet z.B. 1600 € und der nackte Chip zwischen 70 und 100€. Am Ende bleibt es ein Vergleich mit Äpfeln und Birnen... Duke
ich hatte mich mit CRC für Ethernetverbindung beschäftigt. Hier war meine Diskussionsrunde dazu. Beitrag "Ethernet GMII" Das Polynom der Verschlüsselung war aber konstant.
Duke Scarring schrieb: > Ein Evalboard kostet z.B. 1600 € und der nackte Chip zwischen 70 und > 100€. Ein Artix7-evalboard mit "50,- Euro-Chip" gibt es aber auch schon um 150,-. Selbst den 100er gibt es im ARTY für 250,- (all inklusive). Der hat >700 Multiplizierer, die bis zu 250MHz in einem Takt arbeiten. Er kann also z.B. 512 Frequenzfaltungen mit beliebigen Frequenzen (nicht nur lineare / binäre wie bei FFT) bei einer Länge von 256 TAPs mit 1MHz durchführen. Wieviele Microprozessoren braucht es dazu?
Beitrag #6919382 wurde von einem Moderator gelöscht.
Interessantes Thema. Hat sich inzwischen etwas neues in dem Projekt ergeben? FPGAs lassen sich übrigens auch mieten, wenn man für ein einmaliges Projekt nicht Hardware kaufen möchte: https://aws.amazon.com/de/ec2/instance-types/f1/ Da drin steckt wohl ein UltraScale+ VU9P mit 7k DSP slices. Kosten sind $1.65 pro Stunde, $400 credit gibt's anscheinend unter bestimmten Voraussetzungen geschenkt.
Jordy schrieb: > Es handelt sich um einen Algorithmus zur Bestimmung der Performance von > CRC Polynomen. Also NICHT die Berechnung von CRCs, das ist trivial, > sondern die Bewertung aller möglichen Polynome. Bin ich da jetzt völlig paranoid, oder liefert dieses Forum einem ominösen Professor X und seinem Jordy Hinweise dazu, wie man CRCs reverse "bescheißen" kann? CRC Polynome sind so ungefähr der heilige Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da ne Menge Unsinn anstellen.
Carsten P. schrieb: > CRC Polynome sind so ungefähr der heilige > Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da > ne Menge Unsinn anstellen. Na und? Wenn man das kann, dann kann man das. Wenn Professors X‘s Jordy das mit seinem Taschengeld-Budget hinbekommt, ist das woanders schon längst kein Problem mehr. Oliver
Oliver S. schrieb: > Na und? Wenn man das kann, dann kann man das. > Wenn Professors X‘s Jordy das mit seinem Taschengeld-Budget hinbekommt, > ist das woanders schon längst kein Problem mehr. Das fürchte ich auch, und wir geben da noch Input. Wobei das auch wieder eine gute Seite hat, denn dann muss sich die "andere" Seite auch wieder bewegen und besser werden.
Carsten P. schrieb: > CRC Polynome sind so ungefähr der heilige > Gral, wenn es um CRCs geht. Mit genügend schnellen Systemen kann man da > ne Menge Unsinn anstellen. Der oben skizzierten 'Hash-Industrie' ist nichts heilig und es macht auch durchaus Sinn, Polynome mit Referenz-Daten brute-force durch FPGA-Banken zu schicken. Die obige Problemstellung duerfte schlussendlich dieselbe sein wie beim Hash-Mining fuer Digitalwaehrung unterschiedlichster Art. Um die Guete von CRCs bezueglich typischer Datenstroeme zu bestimmen, muss man sich damit beschaeftigen, insbesondere dann, wenn es um den Nachweis von Fehlerraten geht. Die alten Hasen erinnern sich vielleicht noch an die argen Schwaechen des XMODEM-CRC...
Martin S. schrieb: > Die alten Hasen erinnern sich vielleicht > noch an die argen Schwaechen des XMODEM-CRC... Ja, da hast du Recht. Ich muss mich dringend mal wieder mit Krypto befassen. Bisher habe ich noch jedes System dicht bekommen, indem ich unter anderem Schlüssel mit Faktor 4 benutzt habe, also wenn 1024-Bit-Schlüssel up-to-date waren, habe ich 4096-er benutzt. Aber ich bin mir recht sicher, dass der erste Quantencomputer, der über sowas lacht und ein paar Sekunden dafür braucht, in China stehen wird. Und der chinesischen Regierung ist es erstens völlig wurscht, wie freundlich wir hier in diesem Forum zueinander sind, und zweitens wird sie ihre Technologie an den verkaufen, der zahlt, sei es eine Mafia, seien es die Geheimdienste der USA (mit Hinter(n)tür in diesem Fall natürlich).
:
Bearbeitet durch User
Geht es hier jetzt um die Sicherung der Daten im Sinne der Fehlerkorrektur (Fokus auf Effizienz) oder dem Schutz vor dem Ausspähen (Fokus auf Kryptosicherheit)? Wir machen das so, daß diese beiden Punkte getrennt sind und es mehrere Sicherheitsstufen gibt. Wir übertragen z.B. (wirklich nur ein Beispiel) eine 8 Bit Folge als 11 Bit Wort, die Matrix aus 10 Worten mit einem 11 Bit FEC, der selber mit 7 Bit geschützt ist -> 128 Bit. Dann wird eine Anzahl von z.B. 8 solcher Pakete mit 2-4 Worten an Rauschinformationen und Täuschinformationen (einen scheinbaren Muster) aufgefüllt. Erst danach wird AES-codiert unter Verwendung eines dedizierten Schlüssels, der aber für die nächsten 8/6/32 wieder getauscht wird. Mit brute force kommt man da nicht weiter, weil dem Knacker nicht bekannt ist, wieviele Schlüssel er durch probieren muss und auch kein echtes Kriterium findet, ob ein Datenstrom valide ist, oder nicht. Selbst MIT Schlüssel findet man nach dem Decodieren nur einen Scheindatenstrom, der anhand der Musterworte ein Scheinmuster aufwirft, das zu dekodierbaren, aber nicht interpretierbaren Daten führt. An der Stelle sorgt das Protokoll dafür, dass durch Hacker dekodierte Daten verworfen werden.
Weltbester FPGA-Pongo schrieb im Beitrag #6934723: > Geht es hier jetzt um die Sicherung der Daten im Sinne der > Fehlerkorrektur (Fokus auf Effizienz) oder dem Schutz vor dem Ausspähen > (Fokus auf Kryptosicherheit)? > > Wir machen das so, daß diese beiden Punkte getrennt sind und es mehrere > Sicherheitsstufen gibt. Wir übertragen z.B. (wirklich nur ein Beispiel) > eine 8 Bit Folge als 11 Bit Wort, die Matrix aus 10 Worten mit einem 11 > Bit FEC, der selber mit 7 Bit geschützt ist -> 128 Bit. Dann wird eine > Anzahl von z.B. 8 solcher Pakete mit 2-4 Worten an Rauschinformationen > und Täuschinformationen (einen scheinbaren Muster) aufgefüllt. Erst > danach wird AES-codiert unter Verwendung eines dedizierten Schlüssels, > der aber für die nächsten 8/6/32 wieder getauscht wird. > > Mit brute force kommt man da nicht weiter, weil dem Knacker nicht > bekannt ist, wieviele Schlüssel er durch probieren muss und auch kein > echtes Kriterium findet, ob ein Datenstrom valide ist, oder nicht. > Selbst MIT Schlüssel findet man nach dem Decodieren nur einen > Scheindatenstrom, der anhand der Musterworte ein Scheinmuster aufwirft, > das zu dekodierbaren, aber nicht interpretierbaren Daten führt. An der > Stelle sorgt das Protokoll dafür, dass durch Hacker dekodierte Daten > verworfen werden. Der Ansatz klingt gut. Ihr habt da bestimmt noch das eine oder andere Goodie, das du hier nicht ausplaudern magst. Und eigentlich ist das ein eigenes Thema, das mit dem des OPs nix mehr zu tun hat, aber solange er sich nicht beklagt... ^^ Ich mag grundsätzlich 4 Punkte zur Krypto allgemein anmerken. 1. Security By Obscurity ist keine gute Idee. So obskur etwas auch erscheinen mag, mit genügend Hirnschmalz oder Rechenpower (Mustererkennung) kommt man auf den Kniff. 2. Security By Secrecy ist keine gute Idee. Wir leben in einer miesen Welt, es gibt miese Menschen. Entweder Geld oder Folter machen Menschen weich, und wenn es in Bereiche der jeweils nationalen Sicherheit oder militärischer Geheimnisse geht, gibt es Staaten, die die Geheimnisse wissen wollen, und es gibt Menschen, die Mittel und Wege finden werden, dir die Geheimnisse zu entlocken. Hast du Kinder? Das meine ich übrigens in keiner Weise zynisch oder "lustig". 3. Security By Disclosure ist eine sehr gute Idee. SHA, AES, RSA, PKCS usw usw sind nur deswegen weltweit so anerkannt, weil jeder den Code laden, lesen und analysieren kann -- und weil das auch ständig Leute machen. Inzwischen sind die Leitungen im Internet schnell genug, auch recht große Datenpakete, die mit RSA und genügend langen Schlüsseln verpackt sind, durch die Gegend zu schicken, und die Computer sind, wenn es denn wirklich wichtig ist, im Preis/Leistungs-Verhältnis weit in Richtung Leistung geneigt. Hier etwas zum Lesen: https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords 4. Mit Quantencomputern wird das alles noch ganz anders aussehen. Mit ein bisschen Nachdenken kommen wir doch alle darauf, dass etwa China nicht so unfassbar viel Geld in das Quantencomputing steckt (und die USA auch nicht), weil sie damit Messwerte vom James Webb-Teleskop besonders schön auswerten will oder PI auf die letzte Stelle berechnen möchte für einen Eintrag als Rekordhalter. Die möchten den Generalschlüssel für alle digitalen Schlösser dieser Welt. Aber so schwer ist das eigentlich gar nicht. Es kommt immer darauf an, was du haben möchtest. Möchtest du wissen, wann ich zuhause bin? Dann könntest du dich natürlich bei mir auf die Lauer legen und mich observieren. Oder du könntest eine "WLAN-Falle" aufstellen, die alles an Datenpaketen an dich überträgt, was meine Bude so durch die Gegend sendet. Da langt dir eigentlich schon der gesunde Menschenverstand: Je mehr unterschiedliche Datenpakete es sind, desto wahrscheinlicher werde ich gerade da sein. Wenn es immer nur dieselben "NOP"-Blöcke sind, dann bin ich wohl außer Haus. Du weißt sicher selbst, dass das ganze Smart-Home-Zeug in Sachen "Preis/Leistung" vor allem billig sein muss, damit es sich unter die Leute bringen lässt. Im Automotive-Bereich ist es nicht anders, und auch bei Railway, Aviation, Energy, Healthcare sieht das nicht viel besser aus. Ich rede hier nicht von oller Kinderpornografie. So beschissen das wie in Bergisch-Gladbach war, und so traurig und einfach nur widerlich: Das waren "nur" ein paar hundert Kinder und perverse Arschlöcher. (Das wäre übrigens mal eine prima Anwendung für eine ganze Batterie aus 3090ern: deren Verschlüsselung zu knacken, die Pervs zu überführen und sie ruck-zuck, nicht erst nach zwei Jahren ekliger und ewiger Ermittlungen dingfest zu machen und zu verurteilen.) Woran ich denke, sind Anschläge wie 9/11, einfach von einer Konsole aus ausgeführt. Kapere ein paar Satelliten und die Steuerungen von nicht 3, 4, 5 Flugzeugen, sondern von 50, 100, alles, was du kriegst, löse die Feuerlöscher in den Cockpits aus, um die Piloten k.o. zu setzen, und dann lässt du die Maschinen auf besonders neuralgische Punkte abstürzen. Dann störst du die TK-Infrastruktur und lügst den USA mit entsprechend manipulierten Datenpaketen vor, dass es die Russen waren, aber so, dass die Geheimdienste darauf kommen, dass es eigentlich China war. Klingt nach James Bond? Noch helfen längere Schlüssel. Mal schauen, wie lange noch.
:
Bearbeitet durch User
Carsten P. schrieb: > Ich mag grundsätzlich 4 Punkte zur Krypto allgemein anmerken. Es fehlt Punkt 0: Security by selbstgebastelter „Hochsicherheitsverschlüsselung„ ist gar keine gute Idee, auch nicht, wenn man Pongo heißt. Carsten P. schrieb: > Hier etwas zum Lesen: > https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords Aber nicht irgend einen ernsthaften Schlüssel. Ein symmetrischer 256-Bit-Schlüssel hat über 1e77 mögliche Werte. Ende der Diskussion über brute force. Und ob die Quantencomputer vor einer quantencomputersicheren Verschlüsselung einsatzbereit sein werden, ist immer noch mehr als fraglich. Den heute abgegriffenen und vorratsgespeicherten Daten hilft eine solche neue Verschlüsselung zwar nicht, aber den Datenhaufen muß dann auch erst einmal jemand auswerten. Oliver
Oliver S. schrieb: > Es fehlt Punkt 0: > Security by selbstgebastelter „Hochsicherheitsverschlüsselung„ ist gar > keine gute Idee, auch nicht, wenn man Pongo heißt. Der heißt "Pengo" ;-) > Aber nicht irgend einen ernsthaften Schlüssel. Ein symmetrischer > 256-Bit-Schlüssel hat über 1e77 mögliche Werte. Ende der Diskussion über > brute force. > > Und ob die Quantencomputer vor einer quantencomputersicheren > Verschlüsselung einsatzbereit sein werden, ist immer noch mehr als > fraglich. Ja, bisher. Dennoch sollte man sich vorsorglich mit Themen wie KINDI/PQC befassen.
Carsten P. schrieb: > CRC Polynome sind so ungefähr der heilige > Gral, wenn es um CRCs geht. Eigentlich nur, wenn es "unheilige" Polynome sind, weil die heiligen (z.B. die "goldenen") allesamt bekannt sind. Die wurden schon in den 1970ern untersucht und publiziert. Oliver S. schrieb: > Carsten P. schrieb: >> Hier etwas zum Lesen: >> > https://www.extremetech.com/extreme/316266-the-nvidia-rtx-3090-gpu-can-probably-crack-your-passwords Wenn man es einem System von aussen erlaubt, mit 1MHz Schlüssel zu probieren, ist das logisch. Wenn aber PWD-Sicherungssysteme nach 3 mislungenen Versuchen einen timeout machen, kriegt man nur wenige samples aufs Target, bis es schließt. Auch bei einem Geldautomaten, kommt man ohne die echte Pin nicht weit, obwohl es nur einige Tausend Kombis gibt.
Jürgen S. schrieb: > Wenn man es einem System von aussen erlaubt, mit 1MHz Schlüssel zu > probieren, ist das logisch. Wenn aber PWD-Sicherungssysteme nach 3 > mislungenen Versuchen einen timeout machen, kriegt man nur wenige > samples aufs Target, bis es schließt. Und das sollte wohl Standard sein, wobei das natürlich auch als "Waffe" eingesetzt werden kann, und sei es nur, um den Nachbarn zu nerven, weil man das Piep-Piep-Funkschloss von seiner Karre damit blockieren kann. Es lebe der handgefeilte Nachschlüssel! ^^
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.