Servus Erdnuss! Ich habe mir aus Spaß ein Java Programm geschrieben um Pi auf >1E6 Stellen zu berechnen. Dazu haben ich eine BBP Formel programmiert, funktioniert auch. Es blockiert mir aber meine PC, den ich auch nicht 24/7 laufen lassen will. Würde es Sinn machen das Programm irgendwie auf einem FPGA umzusetzen? Wie gut muss der FPGA sein um zu einem i7 Laptop gleich auf zu sein? Gibt es eine Möglichkeit Java Code auf einem FPGa zu benutzen? Ich würde mir wünschen, dass ich einen "start" Knopf drücke und den FPGA eine Woche laufen lasse, dann möchte ich Pi irgdendwie aufrufen, zB. als .txt auf einer SD Karte. Ist dies als Anfänger Aufgabe für einen FPGA geigent? Könnt ihr ein Dev-Board empfehlen? tschüss
Java geht nicht auf einem FPGA. Und so wie du dir das vorstellst, geht es nicht. Lerne erst einmal die Grundlagen, dann kannst du dich langsam an Mathematik wagen
Java ist für diese Aufgabe ohnehin nicht geeignet. Die Applikationen laufen dort ja nicht auf der eigentlichen CPU, sondern auf einer virtuellen CPU. Die Umsetzung vom Java-Prozessor auf den Intel-Prozessor ist zwar seit 1994 (da kam Java raus) immer besser geworden, aber Du verlierst trotzdem Leistung. Nimm C(++) oder eine andere Sprache, bei der direkter Maschinencode erzeugt wird (also nicht C#, managed C++, Phython oder ähnliches) und sorge dafür, dass der Compiler SSE4 oder AVX-Code erzeugt. Plus: verwende möglichst viele Prozessorkerne gleichzeitig und parallelisiere möglichst viele Aufgaben, sofern es das Verfahren zulässt. Wenn das Verfahren es nicht zulässt, dann nehme ein anderes Verfahren. Dann hast die optimalen Voraussetzungen für eine kürzestmögliche Rechenzeit. Wenn Du dann noch die Priorität des Prozesses im Taskmanager heruntersetzt, dann kannst Du nebenher noch andere Sachen machen, weil Dein Programm dann einfach die freie Rechenzeit verwendet und im Bedarfsfall anderen Programmen den Vortritt lässt. Insbesondere die Parallelisierbarkeit ist für eine erfolgreiche FPGA-Implementation wichtig. Ein FPGA besteht ja eh nur aus Millionen von Logikgattern, und die arbeiten eh parallel. Gleiches gilt für Code auf Grafikkarten (Cuda, OpenCL). Der ist nur dann schnell, wenn alle Recheneinheiten parallel laufen und gleichermaßen ausgelastet werden. fchk
Samuel schrieb: > Wie gut muss der FPGA sein um zu einem i7 Laptop gleich auf zu sein? Egal wie du es programmierst: Der FPGA ist für einen Prozess immer im Nachteil, das kann man klar sagen. Erst ab starker Parallelisierung wird ein FPGA effektiv, wenn man die Anzahl der Cores überschreitet und zudem der Prozessor an die Speicherbandbreite des DDR-Rams herankommt, um Zwischenergebnisse zu speichern. Das Bandbreitenverhältnis von FPGA zu I7-PC (Rechen- und IO-Leistung) ist etwa 20:1, dies kann man aber nur mit einem voll ausgebauten FPGA erreichen, das zu etwa 50% rechnet und zu 50% Zwischenergebnisse in Registern und BRAMs speichert und 100% ausgelastet ist, also in jedem Takt etwas tut. Es braucht also mehrere parallele Prozesse, die von unterschiedlichen Startzuständen ausgehend, die Zahlen testen und diese Recheneinheiten müssten zahlenmäßig so viele sein, dass der FPGA voll ist. Grundsätzlich wäre das machbar, nur ist gerade beim Thema Rechnen ein I7 auch technisch im Vorteil, was Bit-Auflösung und Divisionen angeht. Der FPGA dürfte da von seinem Vorteil kaum etwas überbehalten. Hinzu kommt das Problem der Entwicklung: Du musst das System, also die Rechenkerne und die Verwaltung auch bauen. Klar, man kann solche Systeme auf MATLAB entwickeln, muss dann aber in Integer rechnen und das, was da aus dem HDL-Coder kommt, ist weder automatisch pipeline-fähig (und wenn, dann nicht optimiert) noch rundet es geschickt genug, um effektiv rechnen zu können. Sobald ein FPGA nämlich Multiplikationen ausführen muss, die den embedded MUL überschreiten, wird es nochmal langsamer und verliert Flächeneffizienz.
Als kleines Beispiel: Ich hatte probehalber mal meinen alten C-Code für einige Soundmodule in HLS übersetzen lassen und mir das Ergebnis in Vivado angesehen: Was da raus kam, hatte weder die maximale Taktfrequenz, die ich mit händischer Codierung erreicht hatte, noch deren Genauigkeit. Besonders das Thema Rundung und "bits sparen" wird nicht abgedeckt. Der Code resultiert in deutlich erhöhter CHIP-Fläche. Auch ohne pipelining kommt da schon zwischen 150% und 250% raus. Das rotierende pipelining drüber gestülpt erfordert dann nochmals mehr FFs, um das Timing zu treffen. Für das primäre Pyra2-Modul läuft es dann auf über 128 Takte Verzögerung hinaus, was dazu führt, dass man nicht weniger, als 128 Kanäle bauen kann, weil das alte Sample, dass man beim neuen Durchlauf braucht, noch nicht aus der pipeline rausgekommen ist. Klar kann man jetzt sagen, man baut 256 Kanäle, aber dann verliert man einen Faktor 2 für die Abtastfrequenz und die ist schon reduziert. Oder man muss die Module dann einzeln(er) kaskadieren oder parallelisieren, was weitere FFs und Chipfläche kostet. Viele besondere Verschaltungstechniken, quer über die pipeline, die Zeiten und Raum gleichzeitig überstreichen, lassen sich in HLS / MATLAB erst gar nicht formulieren. Um FPGAs auszunutzen, muss man selber ran und das ist aufwändig. Es ist einfacher, solche verschachtelten und verketteten Operationen in C zu machen und mehr Rechenleistung mit DSPs zu kaufen, also mehr davon, oder auf den nächst besseren warten, oder eben Aufgaben auf mehrere Rechner zu verteilen.
Für das gestellte Problem hast Du m.E. mit dem BBP-Algorithmus schon das für FPGA geeignetste Werkzeug am Wickel: + damit lassen sich beliebige Stellen von Pi berechnen, ohne dass man alle vorherigen schon kennen müsste. Damit hat man bei der Parallelisierung keine Probleme, weil die einzelnen Rechenwerke nicht aufeinander Rücksicht nehmen müssen + es gibt schon x Abhandlungen darüber, wie man die notwendige Stellenanzahl innerhalb der Berechnung durch zusätzliche Rechenschritte so gering wie möglich hält. Die folgen üblicherweise einem festen Schema, das sich relativ einfach pipelinen lässt Nehmen wir der Einfachheit halber (die Zahlen entbehren jeder Grundlage) an, Du schaffst es, den Algorithmus so weit zu optimieren, dass er bei - sagen wir mal - 10 MHz bei jeder hundertsten Taktflanke eine Ziffer ausspuckt (0,1 MHz), während dein Laptop bei 3 GHz bei jeder 1000sten Taktflanke eine liefert (3 MHz), brauchst Du im FPGA dreissig parallele Rechenwerke, um gleich zu ziehen. Wenn Du dein Programm auf dem Rechner noch so optimierst, dass es mehrere Prozessorkerne gleichzeitig beschäftigen kann, musst Du beim FPGA noch zusätzlich Briketts auflegen. Ob Du den Laptop "überholen" kannst, hängt einzig und allein davon ab, wieviel FPGA- (und RAM-) Ressourcen (=€€) Du einzusetzen bereit bist.
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.