Liebes Forum, ich verfolge einige Themen hier schon seit einiger Zeit anonym und finde es wirklich äußerst spannend, was sich so mancher von euch einfallen lässt :-) Nun stehe ich aber mit meiner Uni-Arbeitsgruppe (keine Angst, keine Hausaufgaben oder Ähnliches) selbst mit so vielen Fragen da, dass ich mich gerne direkt an euch wenden möchte. Kurz zum Hintergrund: wir sind alle Informatiker und haben im Bereich Elektronik nur minimale Grundkenntnisse. Für den Fall, dass wir unseren Plan in die Tat umsetzen, würden wir uns natürlich auch Hilfe von der entsprechenden Fakultät holen. Meine Fragen hier sind also sehr allgemeiner Natur und haben für uns den Zweck vor allem ein paar Erfahrungen abzufragen und eine Entscheidungsgrundlage zu erstellen. Nun zu dem Vorhaben: Wir haben in der Arbeitsgruppe eine sehr große Datenbank, die das Ergebnis einer ziemlich einfachen Berechnung ist. Es geht hierbei nur um Stringoperationen. Leider wächst die Datenmenge exponentiell und es ist definitiv kein Ende in Sicht. Die vorhandenen und zukünftigen Kapazitäten mit normalen Computern sind also ausgereizt und werden es auch definitiv bleiben. Wir testen gerade zwar auch die Beschleunigung durch GPGPU und einige SIMD Erweiterungen, aber gleichzeitig denken wir auch in die "Special Purpose Hardware" Richtung. Eventuell kennen von euch schon einige das COPACOBANA Projekt (http://www.copacobana.org/). Im Prinzip würde uns eine ähnliche Architektur vorschweben, also möglichst viele FPGAs, die parallel durch einen Controller koordiniert die Instanzen des Problems abarbeiten. Besonders viele Anforderungen haben wir nicht an die Hardware. Der FPGA Speicher darf relativ klein sein, wir haben als maximale Obergrenze dafür mal ca. 25kbit berechnet. Dafür sollte er dann einen möglichst hohen Takt fahren. Die Implementierung des Algorithmus im FPGA bekommen wir selbst vernünftig hin. Ein Eval-Board von Xilinx zum Spielen ist schon auf dem Weg ;-) Besonders viele Logikblöcke sollten wir auch nicht brauchen, der Algorithmus ist eine verschachtelte Schleife mit einer einfachen Updateoperation. Habt ihr hier eventuell auch Vorschläge, welchen FPGA wir uns genauer ansehen sollten? Was für uns nun interessant zu wissen ist, wie man die ganzen FPGAs koordinieren soll. Über einen parallelen Bus würde ja sicher Sinn ergeben, aber dieser darf natürlich nicht zum Flaschenhals werden. Für einen "Job" müsste an einen FPGA eine Gesamteingabegröße von etwa 15kbit geschickt werden, das Ergebnis ist maximal ein 8bittiger Wert. Die Berechnung selbst sollte ziemlich schnell ablaufen, also ist mit einem hohen Durchsatz zu rechnen. Was für bestehende Systeme könnten hier in Frage kommen, wenn z.B. 200 bis 300 FPGAs in einem System gebündelt werden sollen? In dem Zusammenhang gibt es noch ein paar Überlegungen und somit evtl. Constraints: in dem System sollte zur Vor- und Nachbearbeitung eventuell noch ein "normaler" Computer stecken, also großzügig dimensionierter Xeon mit viel RAM und Ethernet. Wäre es z.B. denkbar die Anbindung direkt über PCIe zu machen? Oder bräuchte man eher einen Bus zum Verbinden der FPGAs und dann eine Brücke zu PCIe? Abschließend möchte ich noch sagen, dass wir genau wissen, dass dies ein ambitioniertes Projekt ist, also möchte ich euch bitten konstruktiv auf meine Fragen einzugehen. Sollte ich (und davon gehe ich aus) Anforderungen oder Daten vergessen haben, die u.U. wichtig sind, bitte gebt mir Bescheid. Vielen Dank für euren Input! Simon
Simon D. schrieb: > Besonders viele Logikblöcke sollten wir auch nicht brauchen, der > Algorithmus ist eine verschachtelte Schleife mit einer einfachen > Updateoperation. Das solltest Du evtl. etwas genauer ausführen. Das "Besonders viele Logikblöcke sollten wir auch nicht brauchen" ist nicht unbedingt davon abhängig wie der C-Code aussieht ;-)
Simon D. schrieb: > Wir haben in der Arbeitsgruppe eine sehr große Datenbank, die das > Ergebnis einer ziemlich einfachen Berechnung ist. Willst Du die Datenbank erzeugen, oder verwenden? Oder ist die sehr große (wie groß ist sehr groß?) Datenbank nur ein Zwischenergebnis? Falls nicht, dann kann das leicht gegen :'COPACOBANA is suitable for parallel computation problems which have low communication requirements.' Hast Du relativ 'low' communication requierements? Also : Wie groß ist der Eigangstring (i.e. Datenbank?), wie viele Operationen werden ausgeführt? Wie lange dauert das ganze auf einem normalen PC?
Zunächt schon einmal vielen Dank für eure Antworten. Grendel schrieb: > Das solltest Du evtl. etwas genauer ausführen. > Das "Besonders viele Logikblöcke sollten wir auch nicht brauchen" ist > nicht unbedingt davon abhängig wie der C-Code aussieht ;-) Ich habe die Aussage von anderen Projekten transferiert, die ich so auf FPGA Basis gesehen habe. Es handelt sich hierbei um den Dynamic Programming Algorithmus von Smith und Waterman (http://en.wikipedia.org/wiki/Smith_Waterman_algorithm). Bevor jetzt jemand sagt, der braucht aber O(nm) Speicher: theoretisch ja, lässt sich aber auch linear umsetzen. Wie ich also schon geschrieben hatte, es handelt sich um zwei Schleifen und eine Maximumsabfrage über drei Werte. Zusätzlich können wir für unsere Bedürfnisse noch ein paar speziellere Konditionen einführen, die die Laufzeit deutlich reduzieren können. Wenn mich mein Gefühl jetzt nicht arg trügt, sollte das eine ziemlich kleine Aufgabe für ein FPGA sein, oder? lalala schrieb: > Willst Du die Datenbank erzeugen, oder verwenden? Oder ist die sehr > große (wie groß ist sehr groß?) Datenbank nur ein Zwischenergebnis? > Falls nicht, dann kann das leicht gegen :'COPACOBANA is suitable for > parallel computation problems which have low communication > requirements.' > Hast Du relativ 'low' communication requierements? > > Also : Wie groß ist der Eigangstring (i.e. Datenbank?), wie viele > Operationen werden ausgeführt? Wie lange dauert das ganze auf einem > normalen PC? Die Datenbank existiert, müsste aber auf jeden Fall neu gerechnet werden, es geht also um Erzeugen. Nach aktuellem Stand müsste der Algorithmus etwa 5 Billiarden Mal ausgeführt werden (und nein, ich habe mich nicht verschrieben), Tendenz leider exponentiell steigend. Daher eben auch die Überlegungen, in welche Richtung es gehen soll. Die durchschnittliche Wortlänge unserer DB haben wir kalkuliert und um nicht zu viel RAM im FPGA zu benötigen, haben wir eine Obergrenze von fünf Standardabweichungen genommen, damit würde der absolute Großteil durch die FPGA-Berechnungen erschlagen werden, nur ein kleiner Teil würde auf herkömmlichem Wege berechnet werden müssen. So bin ich auch auf die eingangs erwähnten Inputgrößen gekommen. EDIT Genau die Geschichte mit den "low communication requirements" liegt mir etwas im Magen. Ich glaube für COPACABANA wurde ein 64bit Bus benutzt, an dem dann aber eben auch 128 FPGAs hängen. Ich denke das ist der Bottleneck, den sie beschreiben. Bei uns müsste das wohl wesentlich breiter dimensioniert werden. Ich hatte ja ursprünglich an mehrere CAN-Busse gedacht, da ich mich dafür schon für ein anderes Projekt ein klein wenig eingearbeitet hatte. Wie schnell nun die Berechnung auf einem FPGA im Detail ist, weiß ich natürlich leider nicht, aber sie wird wohl einiges schneller sein, als 1s. Ob dann die 1Mbit/s von CAN reichen, fraglich. /EDIT Ich hoffe, die Infos helfen erstmal weiter. Danke für eure Zeit! Simon
:
Bearbeitet durch User
Simon D. schrieb: > Nach aktuellem Stand müsste der > Algorithmus etwa 5 Billiarden Mal ausgeführt werden (und nein, ich habe > mich nicht verschrieben) Naja, eine Billiarde ist auch nicht sooo viel. Aktuelle GPUs schaffen 3 TFlop/s. D.h. falls wir für Deinen 'einfachen' Algorithmus (den ich wirklich noch nicht verstanden habe) mal 20 Flop annehmen, dann rechnet sich das in 10 Stunden durch. Also machbar. Natürlich ist dann > Tendenz leider exponentiell steigend. nicht so schön.
lalala schrieb: > Naja, eine Billiarde ist auch nicht sooo viel. Aktuelle GPUs schaffen 3 > TFlop/s. D.h. falls wir für Deinen 'einfachen' Algorithmus (den ich > wirklich noch nicht verstanden habe) mal 20 Flop annehmen, dann rechnet > sich das in 10 Stunden durch. Also machbar. Natürlich ist dann >> Tendenz leider exponentiell steigend. > nicht so schön. Da hast Du wohl recht. Ein kurzer Vergleich: mit einer deutlich aufwändigeren Implementierung dieses Algorithmus (Vorfilter, diverse Constraints,...) wurde diese Datenbank in etwa 10 Jahren durch ein Public Distributed Computing Projekt erstellt, da war schon immer relativ viel Rechenleistung zur Verfügung. Bei der Abschätzung, wie viele Operationen nötig sind, tue ich mich etwas schwer, da mir das Vorwissen um die FPGAs noch fehlt. Es lässt sich aber runterbrechen auf (alles Maximalwerte): 3000 Additionen (Schleifenvariablen) 9 Mio Zahlenvergleiche 13,5 Mio Additionen (für Werte in der Matrix) 2,25 Mio Lookups in einem "Array", also Zeichenvergleiche an Stellen in den Inputstrings EDIT: Es geht übrigens immer nur um Ganzzahlen. Die Inputstrings können sogar so codiert werden, dass 5bit pro Stelle ausreichen. Für die Werte in der Matrix reichen 7bit, da wir einen Cutoff einführen, der größere Zahlen überflüssig machen würde. HTH Simon
:
Bearbeitet durch User
Simon D. schrieb: > Ich hatte ja ursprünglich an mehrere CAN-Busse gedacht, da ich mich > dafür schon für ein anderes Projekt ein klein wenig eingearbeitet hatte. Das vergiss mal ganz schnell wieder. Auch wenn der eher lahm ist, DA wäre der 64 Bit Bus der Copacobana schon deutlichst besser geeignet... Da hast Du mit FPGAs gaaanz andere Möglichkeiten als mit 0815 Mikrocontrollern die Du vielleicht vorher angeschaut hast. Sieht mir aber so aus als wäre das mit FPGAs machbar. Gibt ja schon einige Paper dazu da stehts ja drin ;-)
Smith-Waterman klingt nach Sequenzsuche, die 5Bit nach Proteinen. Hab mich vor ~5 Jahren auch mal kurz damit beschäftigt. Unser Biologe wollte auch was schnelleres ;) Da sollte es aber inzwischen doch schon einiges geben, gerade auch mit FPGAs. Gefühlt war Smith-Waterman 1:1 in HW umgesetzt eher unpraktisch, gerade wegen dem "Dynamic Programming", was den Ablauf schon sehr unregelmässig macht. Ein Problem ist auch noch die Datenmenge, die man durchs FPGA bekommen muss.
Die Bandbreite ist doch bei FPGAs am Höchsten. Da würde ich mir keine Sorgen machen. Das k.o. kommt durch die dynamischen Rechenzyklen. Das lässt sich nur virtuell abbilden und da sind CPUs einfach prädestinierter, wenn es komplizierter wird.
Grendel schrieb: > Das vergiss mal ganz schnell wieder. > Auch wenn der eher lahm ist, DA wäre der 64 Bit Bus der Copacobana schon > deutlichst besser geeignet... > Da hast Du mit FPGAs gaaanz andere Möglichkeiten als mit 0815 > Mikrocontrollern die Du vielleicht vorher angeschaut hast. Das dachte ich mir ehrlich gesagt bereits :-) Grendel schrieb: > Sieht mir aber so aus als wäre das mit FPGAs machbar. Gibt ja schon > einige Paper dazu da stehts ja drin ;-) Richtig, daher auch die Aussage, dass die Implementierung von uns durchführbar ist, auch wenn noch einige Anpassungen vorzunehmen sind. Georg A. schrieb: > Smith-Waterman klingt nach Sequenzsuche, die 5Bit nach Proteinen. Hab > mich vor ~5 Jahren auch mal kurz damit beschäftigt. Unser Biologe wollte > auch was schnelleres ;) Alles vollkommen richtig erkannt :-) Ich wusste nicht, wie viel Vorwissen in dem Forum dazu vorhanden ist und wollte den Inhalt auf die für uns interessanten Punkte fokussieren. Georg A. schrieb: > Da sollte es aber inzwischen doch schon einiges geben, gerade auch mit > FPGAs. Gefühlt war Smith-Waterman 1:1 in HW umgesetzt eher unpraktisch, > gerade wegen dem "Dynamic Programming", was den Ablauf schon sehr > unregelmässig macht. Ein Problem ist auch noch die Datenmenge, die man > durchs FPGA bekommen muss. Ich bin mir dessen auch bewusst, habe die Literatur einschlägig studiert. Es geht hier auch nicht darum das für eine kleine Workstation oder so zu basteln, wir brauchen die Vorschlaghammermethode, um unseren Datenmengen beizukommen. Insofern ist es ok, wenn der Algorithmus nicht der Idealfall für FPGAs ist, aber trotzdem ein ordentlicher Speedup raus kommt. Das mit der Datenmenge ist allerdings ein interessanter Punkt. Meine Kalkulationen haben ja schon die Obergrenze an Daten gezeigt, die in den FPGA geschaufelt werden müssen. Nun fehlt mir eben die Erfahrung um einschätzen zu können, ob das sehr viel, oder nicht ist. Stauffenbiehl schrieb: > Die Bandbreite ist doch bei FPGAs am Höchsten. Da würde ich mir keine > Sorgen machen. Das k.o. kommt durch die dynamischen Rechenzyklen. Das > lässt sich nur virtuell abbilden und da sind CPUs einfach > prädestinierter, wenn es komplizierter wird. Siehe mein Kommentar oben. Den Vergleich zu den CPUs machen wir aktuell auch, haben testweise Xeon Phi Karten geordert. Am Ende ist es eine Frage des Preis/Leistungsverhältnis. Auch wenn die FPGA Implementierung die CPU nicht um Welten schlägt, so kosten 100 (kleine) FPGAs immer noch weniger in Anschaffung und Unterhalt, als 10 große Server und sind laut meinen Recherchen trotzdem noch ein gutes Stück schneller. Und hier geht es dann eben um die Anschaffung in einer Größenordnung von deutlich mehr, als diese Hausnummer. Zusätzlich gibt es starke Akademieprogramme der Hardwarehersteller, ein paar Spenden in Form von Silizium sind also immer drin. Um also den Thread wieder etwas auf Spur zu bringen: Ob die FPGA-Strategie umgesetzt wird, hängt von unseren Leistungstests mit dem Dev-Board ab. Und natürlich auch davon, wie sich Tesla und Xeon Phi Karten verhalten. Was uns nun interessiert ist der Aufbau des Gesamtsystems und dabei vor allem, wie der Bus spezifiziert werden müsste, um einen vernünftigen Durchsatz zu erhalten. Die Parameter dafür denke ich sind genannt, wenn euch noch Infos fehlen, sagt es mir bitte. zusätzlich ist dann noch offen, wie dieses System an ein normales Board angeschlossen werden könnte, um einerseits die Anbindung ans Netz zu bekommen und andererseits noch Vor- und Nachbearbeitung auf den Datensätzen durchführen zu können. Oder ob es Sinn macht, einen eigenen kleinen Controller zu bauen, der von dem Bus (oder auch mehreren Bussen) auf Ethernet überbrückt. Vielen Dank für eure wirklich konstruktiven Kommentare, Simon
Es hört sich alles unheimlich spannend und interessant an. Was mir nicht ganz klar ist ist der Kostenrahmen. Mag sein, dass die "FPGA"s preiswert sind, aber wenn man die Entwicklung, Produktuion/Programmierung/Fehlersuche dazurechnet, dann wird es schon teuer. Klar, als Student arbeitet man ja vielleicht für umsonst, aber meist geht es doch schief. Holt euch jemanden dazu, der sich damit auskennt (ich meine mit Konzepten und mit FPGAs). Sicher, die erste Kostenschätzung wird auf jeden Fall ein Schocker ("WAS? Dafür bekommen wir doch 10 schnelle Server!"), aber da muss man eben durch. Wenn eine FPGA-Lösung in Betracht kommt, dann sollte man sich natürlich überlegen, wo der Flaschenhals liegen würde. Vielleicht wäre ein PC-Modul gar nicht mal so schlecht, welches über PCIe mit dem "großen" Mainboard verbunden ist und worauf dann mehrere kleinere "FPGA"-Karten steckbar sind. Oder über USB 3.0 angebunden. Oder man setzt auf Cyclone 5 (oder Xilinx Äquivalent) mit einem ARM Prozessor drauf und baut daraus einen Grid. Über Ethernet verteilt man die Aufgaben, der Arm läuft mit 800 MHz (Dualcore, Linux) und kommuniziert direkt mit dem FPGA-Core (mehr Bandbreite bekommt man einfach nicht hin). Die einzelnen Platinen sind "klein", universell... Dann setzt man alles in einen 3 HE-Rack rein (16-32 Mal) und gut is (Switch und Stromversorgung baut man halt noch mal rein)... So würde ich es machen... aber ich habe kein Plan davon, wie die Anforderungen an den Algorithmus sind. Grüße Kest
Kest schrieb: > Es hört sich alles unheimlich spannend und interessant an. Was mir nicht > ganz klar ist ist der Kostenrahmen. > Mag sein, dass die "FPGA"s preiswert sind, aber wenn man die > Entwicklung, Produktuion/Programmierung/Fehlersuche dazurechnet, dann > wird es schon teuer. Klar, als Student arbeitet man ja vielleicht für > umsonst, aber meist geht es doch schief. > Holt euch jemanden dazu, der sich damit auskennt (ich meine mit > Konzepten und mit FPGAs). Sicher, die erste Kostenschätzung wird auf > jeden Fall ein Schocker ("WAS? Dafür bekommen wir doch 10 schnelle > Server!"), aber da muss man eben durch. > > Wenn eine FPGA-Lösung in Betracht kommt, dann sollte man sich natürlich > überlegen, wo der Flaschenhals liegen würde. Vielleicht wäre ein > PC-Modul gar nicht mal so schlecht, welches über PCIe mit dem "großen" > Mainboard verbunden ist und worauf dann mehrere kleinere "FPGA"-Karten > steckbar sind. Oder über USB 3.0 angebunden. > > Oder man setzt auf Cyclone 5 (oder Xilinx Äquivalent) mit einem ARM > Prozessor drauf und baut daraus einen Grid. Über Ethernet verteilt man > die Aufgaben, der Arm läuft mit 800 MHz (Dualcore, Linux) und > kommuniziert direkt mit dem FPGA-Core (mehr Bandbreite bekommt man > einfach nicht hin). Die einzelnen Platinen sind "klein", universell... > Dann setzt man alles in einen 3 HE-Rack rein (16-32 Mal) und gut is > (Switch und Stromversorgung baut man halt noch mal rein)... So würde ich > es machen... aber ich habe kein Plan davon, wie die Anforderungen an den > Algorithmus sind. Danke für Deine Antwort. Vollkommen klar, ohne fachkundige Hilfe wird das nicht umzusetzen sein. Deshalb habe ich ja eingangs bereits erwähnt, dass wir uns die E-Techniker von der TU ins Boot holen wollen, falls wir uns für dieses Vorgehen entscheiden. Nichtsdestotrotz brauchen wir erstmal eine Entscheidungsgrundlage für uns im Haus. Und wenn wir ganz mit leeren Händen ankommen, kann es schnell so wirken, als ob wir nur Arbeit abwälzen wollen, daher die intensiven Recherchen vorneweg. Zum Kostenrahmen: Das ist natürlich nicht ganz leicht zu sagen, aber ich will es mal so ausdrücken: Manpower ist vorhanden und Doktoranden kosten nicht die Welt ;-) es geht also hier wirklich primär um die für unseren Zweck beste Implementierung im Large-Scale Bereich. Klar, man kann auch nochmal 10 Racks mit Servern voll klatschen, das würde auch irgendwer bezahlen, aber die Aussicht auf die stetig wachsende Datenmenge verlangt einfach einen etwas "more sophisticated" Plan. Daher sollte das Konzept auch möglichst modular und erweiterbar sein. Und wie ich bereits gesagt habe, Hardwarespenden sind definitiv in Aussicht (in Form von FPGAs). Intel hat sich bisher noch nicht gemeldet und wollte uns ein par Hundert Xeons schicken ;-) EDIT Vielleicht noch ein kleiner interessanter Nachtrag: Wir haben von Firmen Angebote für so ein System bekommen, da wären dann ~100 FPGAs drin und das soll dann so zwischen 80k und 90k kosten. Das Problem ist halt nur, dass uns die Leistung nicht reicht (laut den Leistungsangaben der Hersteller) und damit zwei, drei, vielleicht vier solcher Systeme her müssten. Um das Geld einerseits sinnvoller (sprich in mehr Silizium) zu investieren und andererseits ein noch besser auf uns zugeschnittenes Design zu haben, wollen wir das selbst angehen (wie gesagt, falls die Tests positiv ausfallen). In dem Zusammenhang wäre es dann noch sehr hilfreich, wenn ihr mir erläutern könntet, was die Performance bei den FPGAs ausmacht. Ist das nur der Takt alleine? Oder gibt es andere Werte (Speicherzugriffszeiten, spezielle arithmetische Einheiten, etc.) die das beeinflussen? /EDIT Entwicklungskosten bezogen auf die Implementierung schätze ich als gering ein, da auf diesem Feld (wie weiter oben schon richtig erwähnt wurde) schon sehr viel Arbeit gemacht wurde und wir nur Änderungen einfügen müssen. Dann bleibt noch die Infrastrukturentwicklung und Debugging und ja, das kann dauern. Aber wir haben als Zeitrahmen auch locker ein Jahr zur Verfügung. Die Sache mit dem ARM finde ich aber interessant. Wie muss ich mir das vorstellen? Ist das ein ARM direkt mit FPGA integriert? Und die Verbindung von einer Recheneinheit (mit einem FPGA) soll dann über Ethernet laufen? Das erscheint mir aber viel Overhead. Deshalb fand ich COPACABANA so reizvoll, weil eben richtig viel Rechenleistung in eine Kiste gepackt wird und nicht jedes einzelne Bauteil integriert werden muss. Weil Du USB erwähnt hast: Macht die Anbindung darüber wirklich mehr Sinn, als z.B. PCIe? Die USB3.0 Performance ist ja schon nicht ganz so schlecht :-) So wird es bei COPACABANA übrigens auch gehandhabt, der Controller übersetzt von dem internen Bus auf USB. Auf jedem Serverboard gibt es auch eine interne USB-Schnittstelle, also wäre es von der Verdrahtung einfach. Aber dann weiß ich nicht, ob der Controller nicht einen Flaschenhals bildet. Und es wäre auch immer noch nicht ganz klar, welche Bussysteme für die Kommunikation zwischen FPGAs und Controller sinnvoll ist. Man könnte ja, wie oben schon erwähnt, auch mehrere Controller mit jeweils einem FPGA Busstrang dahinter haben, z.B. 4 à 50 FPGAs oder so. Aber welches Bussystem kommt für die beschriebenen Datengrößen dann in Frage? Reichen da bekanntere RS*** Typen? Vielleicht habt ihr ja ein paar Stichworte, nach denen ich mal suchen kann, um mich schlau zu machen. Vielen Dank und viele Grüße, Simon
:
Bearbeitet durch User
Guck mal die Systeme von Picocomputing an: http://picocomputing.com/ Simon D. schrieb: > In dem Zusammenhang wäre es dann noch sehr hilfreich, wenn ihr mir > erläutern könntet, was die Performance bei den FPGAs ausmacht. Ist das > nur der Takt alleine? Oder gibt es andere Werte (Speicherzugriffszeiten, > spezielle arithmetische Einheiten, etc.) die das beeinflussen? Wie immer: Alles beinflusst die Performance wenn man darauf optimieren kann. Grundsätzlich: Takt x Daten pro Takt x parallele Einheiten. Je nach Problem/Algorithmus ist der Durchsatz höher, wenn z. B. mit 128 bit Zahlen gerechnet wird (statt 64) dafür der Takt um z. B. 30% kleiner ist (da komplexeres Design). Wie bei CPUs sagt der Takt auch nur einen Bruchteil aus. Alle grösseren FPGA Architekturen bieten sog. DSP Einheiten um integer Berechnungen zu beschleunigen. Diese Einheiten unterscheiden sich in ihren Fähigkeiten aber zwischen den Herstellern also ist der Takt dieser Einheiten nur schwer vergleichbar. Limitierend heute ist das Routing, also die Zeit, die die Signale von A nach B benötigen innerhalb des FPGA. Theoretsich macht dein Logikblock 600 MHz, real macht dein Design vielleicht 200 MHz weil da noch Leitungslatenz reinkommt. Mein Bauchgefühl sagt mir, dass ihr den Rechenblöcken/FPGAs grössere Arbeitspakete geben solltet, damit ihr auch genug Zeit habt, neue Arbeit anzuliefern. Auch schon deshalb, weil PCIe und DDRx-RAM nur hohen Datendurchsatz hat, wenn Daten als Blöcke übertragen werden. Das kann auch in mehreren Layern erfolgen, also z. B. pro FPGA ein externes RAM (grösse durch Berechnung/Simulation bestimmt) für die Arbeitspakete (gefüllt per DMA über PCIe), der FPGA verteilt dann diese selbständig intern in seine Recheneinheiten.
Simon D. schrieb: > Für > einen "Job" müsste an einen FPGA eine Gesamteingabegröße von etwa 15kbit > geschickt werden, das Ergebnis ist maximal ein 8bittiger Wert. Und Du hast Größenordnung 5 Billiarden 'Jobs'? D.h. ein Gesamtdatenvolumen von 5 * 10^15 * 15*10^3 /8 Bytes? ~ 8 * 10^15 kbytes = 8 Exabytes ? wo kommen die her? Von einem Magnetband? Festplattenmegaarray? Wieviel Datendurchsatz hast Du da? Sagen wir mal Du kannst (auch auf die FPGA) so um die 10 Gbyte/s schaufeln, bist Du dann nicht auch bei 8* 10^5 s = 9 Tagen? Mit exponentieller Zunahme wird das aber auch hart? Oder hab ich da was falsch verstanden? Kannst Du vielleicht mal den gesamten Ablauf skizzieren? Und zusätzlich zu den Kosten. Wie lange soll den die Berechnung maximal dauern? 1h, 1d, 1m oder 1a?
Simon D. schrieb: > Zum Kostenrahmen: > Das ist natürlich nicht ganz leicht zu sagen, aber ich will es mal so > ausdrücken: Manpower ist vorhanden und Doktoranden kosten nicht die Welt > Entwicklungskosten bezogen auf die Implementierung schätze ich als > gering ein, da auf diesem Feld (wie weiter oben schon richtig erwähnt > wurde) schon sehr viel Arbeit gemacht wurde und wir nur Änderungen > einfügen müssen. Dann bleibt noch die Infrastrukturentwicklung und > Debugging und ja, das kann dauern. Aber wir haben als Zeitrahmen auch > locker ein Jahr zur Verfügung. > Nicht die Dokumentation vergessen, wenn die Doktoranden weg sind, soll das Ding ja auch weiterlaufen. Spricht denn schon einer der Doktoranden z.B. VHDL? Da ihr nur Änderungen einfügen müsst, habt ihr denn Zugriff auf die (VHDL?) Source Codes? Ein Jahr im universitären Bereich ist gar nichts. Ich wär schon (positiv) überrascht wenn ihr den Algorithmus auf dem Eval-Bord in 6 Monaten zum laufen bringt. Natürlich wenn ihr ein paar FPGA Spezialisten habt, ist das alles machbar. Dann würdest Du hier aber auch nicht solche Fragen stellen, oder?
Christoph Z. schrieb: > Guck mal die Systeme von Picocomputing an: > http://picocomputing.com/ > Werde ich unter die Lupe nehmen, danke. Christoph Z. schrieb: > Wie immer: Alles beinflusst die Performance wenn man darauf optimieren > kann. > > Grundsätzlich: Takt x Daten pro Takt x parallele Einheiten. > > Je nach Problem/Algorithmus ist der Durchsatz höher, wenn z. B. mit 128 > bit Zahlen gerechnet wird (statt 64) dafür der Takt um z. B. 30% kleiner > ist (da komplexeres Design). > > Wie bei CPUs sagt der Takt auch nur einen Bruchteil aus. Alle grösseren > FPGA Architekturen bieten sog. DSP Einheiten um integer Berechnungen zu > beschleunigen. Diese Einheiten unterscheiden sich in ihren Fähigkeiten > aber zwischen den Herstellern also ist der Takt dieser Einheiten nur > schwer vergleichbar. > > Limitierend heute ist das Routing, also die Zeit, die die Signale von A > nach B benötigen innerhalb des FPGA. Theoretsich macht dein Logikblock > 600 MHz, real macht dein Design vielleicht 200 MHz weil da noch > Leitungslatenz reinkommt. Danke für die Aufklärung. Hatte schon so eine Antwort erwartet. Kann man denn allgemein ein gutes Vorgehen nennen, wie man einen angemessenen FPGA raussucht? Ich habe z.B. gesehen, dass sich in MATLAB ganz angenehm FPGAs simulieren lassen und dabei auch Nutzungsstatistiken rauskommen. Oder "reicht" die Analyse von Hand, also zu untersuchen welche Ressourcen die Implementierung nutzen wird? Christoph Z. schrieb: > Mein Bauchgefühl sagt mir, dass ihr den Rechenblöcken/FPGAs grössere > Arbeitspakete geben solltet, damit ihr auch genug Zeit habt, neue Arbeit > anzuliefern. Auch schon deshalb, weil PCIe und DDRx-RAM nur hohen > Datendurchsatz hat, wenn Daten als Blöcke übertragen werden. > Das kann auch in mehreren Layern erfolgen, also z. B. pro FPGA ein > externes RAM (grösse durch Berechnung/Simulation bestimmt) für die > Arbeitspakete (gefüllt per DMA über PCIe), der FPGA verteilt dann diese > selbständig intern in seine Recheneinheiten. Das ist ein wichtiger Teil. Ich dachte mir auch schon, dass wir die Arbeitspakete irgendwo "queuen" müssen, ich dachte dabei aber an den Controller vor allen FPGAs. Wenn ich Dich richtig verstehe schlägst Du also vor, die Pakete vor jedem FPGA vorzuhalten, so dass er sie dann abarbeiten kann. Das Ergebnis wird dann anschließend zurückgeschickt (z.B. als Tupel (PaketID, Score)) und abgelegt. Vergrößert sich dadurch nicht der Aufwand für den FPGA? Ich habe zwar gesehen, dass viele/die meisten mittlerweile Memory Interfaces haben, aber das sind ja dann nicht mehr die Low-End-Varianten an die ich jetzt in großer Anzahl zur Beschleunigung gedacht habe, oder liege ich da falsch? Um mal konkret zu werden: ich hatte an die Spartan-3A Reihe gedacht. Und weil Du die Anbindung an PCIe genannt hast: Kann ich denn mehrere FPGAs direkt an den Bus hängen (die Pico Boardbeschreibungen lassen sowas in der Art vermuten)? Sollte das möglich sein, wäre man aber sicherlich noch immer in der Anzahl limitiert, oder? Vielen Dank und liebe Grüße, Simon
lalala schrieb: > Und Du hast Größenordnung 5 Billiarden 'Jobs'? > D.h. ein Gesamtdatenvolumen von 5 * 10^15 * 15*10^3 /8 Bytes? > ~ 8 * 10^15 kbytes = 8 Exabytes ? > > wo kommen die her? Von einem Magnetband? Festplattenmegaarray? > > Wieviel Datendurchsatz hast Du da? > > Sagen wir mal Du kannst (auch auf die FPGA) so um die 10 Gbyte/s > schaufeln, bist Du dann nicht auch bei 8* 10^5 s = 9 Tagen? > Mit exponentieller Zunahme wird das aber auch hart? > > Oder hab ich da was falsch verstanden? Kannst Du vielleicht mal den > gesamten Ablauf skizzieren? > > Und zusätzlich zu den Kosten. Wie lange soll den die Berechnung maximal > dauern? 1h, 1d, 1m oder 1a? Ok, ganz konkret: Die Datenbank ist eine Ähnlichkeitsmatrix von allen Proteinsequenzen gegen sich selbst, also #(aller öffentlichen Sequenzen)^2. Auch wenn die DB relativ sparse ist, so müssen doch z.B. neue Sequenzen auch gegen alle anderen gerechnet werden. Neue Sequenzen kommen heute fast täglich hinzu (letztens gab es erst ein major update von einem großen Projekt, das selbst einfach mal 100 Mio Sequenzen hatte). Die bisherige Sequenzlängenverteilung zeigt eine Standardabweichung von ~300, also 5sigma sind 1500 Zeichen als Längenbeschränkung von Inputstrings für den FPGA. Bei einem Alphabet von 20 (plus noch ein paar) Zeichen braucht man 5 Bit zum Codieren (= 7500 bit). Der Algorithmus selbst braucht zwei Inputstrings und einmal diese Wortlänge zum Zwischenspeichern der Matrixwerte, wobei die Zwischenwerte nur 7 Bit haben müssen, da unser Score bei 80 abgeschnitten wird (= 25500 Bit). Hinzu kommen noch einige Schleifenvariablen und ein paar andere kleinere Geschichten. Alle Werte sind Ganzzahlen. Die Inputstrings liegen in Datenbanken und Flatfiles und sind in der Tat nicht klein. Text lässt sich ja zum Glück gut komprimieren und so sind es ein paar hundert Terabyte in Summe. Die Matrix soll nicht in kurzer Zeit neu berechnet werden. Wir haben schonmal über den Daumen gepeilt, dass das z.B. auf SuperMUC (Petaflop Größenordnung) schon ein paar Tage dauern kann (bzw Wochen). Mit der Neuimplementierung würde allerdings die Heuristik im aktuellen Algo verschwinden, eine Neuberechnung (komplett) wäre also notwendig. Wenn das in ein paar Wochen/Monaten auf den FPGA-Systemen laufen könnte, wäre das sicherlich gut. lalala schrieb: > Nicht die Dokumentation vergessen, wenn die Doktoranden weg sind, soll > das Ding ja auch weiterlaufen. Spricht denn schon einer der Doktoranden > z.B. VHDL? > > Da ihr nur Änderungen einfügen müsst, habt ihr denn Zugriff auf die > (VHDL?) Source Codes? > > Ein Jahr im universitären Bereich ist gar nichts. Ich wär schon > (positiv) überrascht wenn ihr den Algorithmus auf dem Eval-Bord in 6 > Monaten zum laufen bringt. > > Natürlich wenn ihr ein paar FPGA Spezialisten habt, ist das alles > machbar. Dann würdest Du hier aber auch nicht solche Fragen stellen, > oder? Sourcecode gibt es, ja. Und ich habe die Simulation davon in MATLAB z.B. auch schon zum Laufen gebracht, ist ja jetzt nicht der riesen Aufwand. Sicher, da kommt noch einiges an Optimierung etc hinterher, aber über Monate sprechen wir hier nach meiner aktuellen Einschätzung nicht. Was allerdings an Implementierungen rundherum gemacht werden muss, kann ich jetzt noch nicht wissen. Wenn wie im vorigen Beitrag z.B. genannt noch Speicherinterfaces und Queues hinzu kommen, wird es für mich/uns als Neulinge in dem Feld natürlich nicht trivialer. HTH Simon
Ich möchte ja nicht abstreiten, dass an den Unis fähige Leute sitzen. Aber das ist nicht damit zu vergleichen, dass jemand, der Projekterfahrung hat die Kontrolle hat. Sich ein tolles Teil zu überlegen ist eine Sache, aber eine realistische Schätzung abzugeben und zu koordinieren ist eine andere! mit 100kE für ein Gerät mit 100 FPGAs hat jetzt natürlich null Aussagewert (welche FPGAs?), aber ich vermute mal, das sind die Geldsummen, mit denen man rechnen muss. Man kann sich vieles überlegen, aber wer baut die Teile? Und wie sieht es aus, wenn in 3 Jahren weitere gebaut werden sollen? Das alles muss miteinbezogen werden, ansonsten ist es nach einem Defekt nur ein Haufen Elektronikschrott, wo sich keiner damit auskennt :-) Ein Cyclone 5 hat einen/2 ARM-Core im FPGA selber (+Ethernet, +USB, +Speicherkontroller,...). Wenn ich soetwas bauen müsste, würde ich z.B. so vorgehen (wie gesagt, ohne Wissen, ob das Sinnvoll ist oder nicht): A: Eine doppel-Eurokarte (Steckkarte) mit einem ARM-FPGA, welches über Ethernet an einem gemeinsamen Bus hängt. Dieses FPGA hat vielleicht 1/2 Gbyte RAM. Da läuft Linux drauf. An diesem FPGA (auf dem gleichen Board) hängen 4-8 FPGAs, die keinen ARM haben (reine Rechenkerne). B: Ein 3HE-Gehäuse, wo 16-32 Solche Karten drin sind. Vielleicht noch eine "Master" Karte, die die Kommunikation nach Außen herstellt (über Ethernet). Im Rack ist die Stromversorgung, Überwachung, ... C: Ein Rack mit mehreren solchen Gehäusen. Host | +----- Rack | | | +--- Master + 16-32 FPGAs (Cores) | | | +--- Master + 16-32 FPGAs (Cores) | | | +--- Master + 16-32 FPGAs (Cores) | +----- Rack | +--- Master + 16-32 FPGAs (Cores) | +--- Master + 16-32 FPGAs (Cores) | +--- Master + 16-32 FPGAs (Cores) Soetwas könnte man beliebig erweitern, der Host verteilt die Aufgaben zwischen den Racks/Mastern. Ein Master verteilt die Aufgabe zwischen den einzelnen Karten. Und jede Steckkarte verteilt die Aufgabe zwischen den 16-32 FPGAs. Das mit der BAndbreite muss man sich genau überlegen -- da weiß ich nicht so recht, wieviele Daten da anfallen. Kann mir aber vorstellen, dass man alles "verschränkt" macht: solange die Daten an ein eine Karte übergeben werden, rechnen alle anderen. Na ja, da könnte ich noch weiter spinnen, aber ich lasse es lieber ;-) Grüße Kest
Äh... da habe ich was durcheinander gebracht: also Ein 3HE-Rack = Master + 16-32 Karten zu je Master + 1GB RAM + 8 FPGAs... Insgesamt also 128-256 FPGAs (Rechnenknechte) im Rack, die über Ethernet angebunden werden.
Naja, ein Algorithmus exponentieller Komplexität lässt sich nicht relevant mit FPGAs beschleunigen ;-) Ihr müsstet die Komplexität reduzieren ...
Simon D. schrieb: > Die bisherige Sequenzlängenverteilung zeigt eine Standardabweichung von > ~300, also 5sigma sind 1500 Zeichen als Längenbeschränkung von > Inputstrings für den FPGA. Langsam fange ich an zu verstehen. Ich hab aber noch der Rechnung hier ein Problem. Ich dachte 5 Sigma Umgebung bedeutet 5 Sigma nach 'links' vom Mittelwert (natürlich nicht weniger als 0) und 5 Sigma nach 'rechts' vom Mittelwert. D.h. ich komme auf denselben Wert falls die durchschnittliche Sequenzlänge 0 ist. Das kommt mir etwas kurz vor. Was ist der richtige Wert?
Simon D. schrieb: > Kann man denn allgemein ein gutes Vorgehen nennen, wie man einen > angemessenen FPGA raussucht? Ich habe z.B. gesehen, dass sich in MATLAB > ganz angenehm FPGAs simulieren lassen und dabei auch Nutzungsstatistiken > rauskommen. Oder "reicht" die Analyse von Hand, also zu untersuchen > welche Ressourcen die Implementierung nutzen wird? Für ein so umfangreiches Projekt kommst du nicht drum herum das im Detail zu untersuchen. Also Algorithmus für bestimmten FPGA optimieren und sehen wie schnell das läuft. Läuft bei euren anderen Varianten ja auch so, ob ATI oder Nvidia weisst du auch erst nach dem du optimiert hast. Simon D. schrieb: > Das ist ein wichtiger Teil. Ich dachte mir auch schon, dass wir die > Arbeitspakete irgendwo "queuen" müssen, ich dachte dabei aber an den > Controller vor allen FPGAs. Wenn ich Dich richtig verstehe schlägst Du > also vor, die Pakete vor jedem FPGA vorzuhalten, so dass er sie dann > abarbeiten kann. Das Ergebnis wird dann anschließend zurückgeschickt > (z.B. als Tupel (PaketID, Score)) und abgelegt. > > Vergrößert sich dadurch nicht der Aufwand für den FPGA? Ja, dafür wird der Controller warscheinlich einfacher. Auch dabei: Ein überschlagsmässige Abschätzung kann man machen. Für eine überschaubare Anzahl an Systemvarianten würde ich aber empfehlen eine Simulation des gesammten Datenflusses vom Input (Storage System, Steuerrechner, Netzwerk dazwischen etc.) bis zum Output (Datenbank). Du musst wissen wo dein Flaschenhals steckt und du musst wissen wie viel es kosten diesen zu beheben. So kann dann entschieden werden, welche Systemvariante den grössten Durchsatz hat bei gegebenem Budget.
Simon D. schrieb: > Um mal konkret zu werden: ich hatte an die Spartan-3A Reihe > gedacht. Denk in der Zukunft und nicht in der Vergangenheit. Simon D. schrieb: > Und weil Du die Anbindung an PCIe genannt hast: Du brauchst ein paar Grundlagen zu PCI Express. Finde aber gerade keinen Link, der das schön kurz beschreibt. Wer kann helfen?
Christoph Z. schrieb: > Du brauchst ein paar Grundlagen zu PCI Express. > Finde aber gerade keinen Link, der das schön kurz beschreibt. Wer kann > helfen? Wenn man was mit PCIe von Grund auf selber entwickeln will ist: http://www.pcisig.com/home m.M. die Anlaufstelle. Mitgliedbeitrag ist jedoch 3kUSD/a Ansonsten sollte man sich überlegen, ob man einen IP-Core lizensiert.
@lalala Ich glaube Christoph meinte damit nur, dass PCIe Punkt zu Punkt ist und kein echter "Bus".
Grendel schrieb: > @lalala > Ich glaube Christoph meinte damit nur, dass PCIe Punkt zu Punkt ist und > kein echter "Bus". Hast schon Recht. Hab das etwas ausserhalb des Kontextes gelesen, und zu weit gedacht.
Wow, ich bin beeindruckt. Danke schon jetzt für eure vielen Antworten. Die Idee mit der Simulation finde ich ziemlich gut, daran hatte ich ehrlicherweise gar nicht gedacht. Tja, wenn einen der Tatendrang gepackt hat, dann übersieht man doch gerne mal die Basics ;-) Auch den Vorschlag mit den integrierten ARMs finde ich ziemlich elegant. In diese Richtung werden wir sicherlich weiter denken und dann mit den Spezis diskutieren. Danke @ Kest. @lalala Es stimmt, die 5 Sigma sind nur rechtsseitig, die obere Längenabschätzung reicht uns ja aus. @ Christoph Z. Du hast wahrscheinlich recht, dass wir die Implementierung einfach mal ausprobieren müssen. Ich bin jetzt mal auf das Xilinx DevBoard gespannt, sollte bald kommen. Dann werden wir mal noch ein paar andere Modelle/Hersteller vergleichen. Bis dahin sind dann auch sicher Benchmarks von GPGPU, bzw. der massive Multicores (Xeon Phi) da. @ dagfagr Das mit dem Komplexität reduzieren ist so eine Sache :-) Da haben sich schon Generationen an Wissenschaftlern die Zähne ausgebissen. Wenn Du einen guten Vorschlag hast, immer her damit. Wobei ich Dir die Science Titelseite eigentlich nicht wegnehmen will ;) Viele Grüße, Simon
Simon D. schrieb: > @lalala > Es stimmt, die 5 Sigma sind nur rechtsseitig, die obere > Längenabschätzung reicht uns ja aus. Dann musst Du doch aber noch den Erwartungswert addieren. Wenn ein sigma bei 300 liegt, dann kann schätze ich jetzt mal wild mu>=600 (gibt mal den richtigen Wert raus). Und dann bist Du nur bei weniger als 3 sigma mit Deinen 1500 Zeichen.
Hast schon recht, habe das nicht so ausführlich beschrieben, aber nicht vergessen in meiner Berechnung, da die Werte nur gerundet sind. Mean liegt bei irgendwas um die 200 und ein paar, sd bei 260 oder sowas, kann gerade nicht nachschlagen, bin unterwegs und muss was an ner SW für ne andere AG fixen..
>dass wir uns die E-Techniker von der TU ins Boot holen wollen,
Vergiss die schnell mal wieder. Die haben ein paar Miniprojekte
durchgezogen.
Fuer so ein Projekt muss erst mal eine Projektvereinfachung hin.
Irgendein Kurzwert, der ausdrueckt, ob sich ein Vergleich ueberhaupt
lohnen koennte.
Und dann geht es um Korrelation. also muss man die verschiedenen
Sequenzen aneinander vorbeiziehen, multiplizieren und integrieren. Also
muss man nur Schieberegister mit Laenge gegen Unendlich haben und die
Daten mit zB 200MHz seriell durchclocken.
Nein?
Christoph Z. schrieb: > Je nach Problem/Algorithmus ist der Durchsatz höher, wenn z. B. mit 128 > bit Zahlen gerechnet wird (statt 64) dafür der Takt um z. B. 30% kleiner > ist (da komplexeres Design). Man braucht nicht unbedingt 30% mehr Takt, nur weil das Design breiter wird. Wenn es tiefer wird, steigt die Anforderung und man bekommt Probleme, diese lassen sich aber oft durch ein Übermass an FFs kontrollieren.
Implementierung einfach mal (eben) ausprobieren wenn die Boards da sind.... Der war gut :D FPGA mit Arm Core kann man währenddessen beschnacken während ein mega-Projekt für einen ganzen Lehrstuhl mal eben in einem Forenthread gelöst wird. Da ist doch immens viel Detailwissen nötig - in ganz vielen Bereichen. Möglicherweise bin ich auch zu wenig selbstbewusst, habe meine jugendliche Phantasie verloren, aber ist das alles Ernst? Wie viele Mannjahre siehst du in dem Projekt zu veranschlagen. Exponentiell steigende Komplexität bleibt aber nun immer noch exponentiell und da du eingangs sagst ohne Ende in sicht ist das doch wenig ermutigend. Du sagst auf mathematischer Ebene seht ihr keine Möglichkeit, aber bist du sicher daß die Dampfhammer Methode hier wirklich das Richtige ist? Ich meine wenn sich schon andere Gruppen die Zähne ausgebissen haben, warum haben die dann den viel hilft viel Weg nicht beschritten. Darunter mögen auch sehr wahrscheinlich welche sein, für die technologische Aspekte nciht von Null angegangen werden müssen. Ich meine das jetzt übrigens gar nicht negativ, ich sehe nur wirklich wenig Chancen ohne einige mit erheblichem Fachwissen. Nicht nur beim vhdl Code schreiben. Die Leute braucht man am Lehrstuhl wenn der Prof schon nicht dazu gehört. Viel verrennen und neu angehen nach paar Monaten kann man sich ja zeitlich und finanziell nicht unbedingt erlauben. Aber viel Glück und berichte mal zwischendurch wo die Reise hingeht
Genau, nur mit dem jugendlichen Leichtsinn ist es möglich sich solche Projekte zu überlegen. Das Gute dabei ist, dass diejenigen, die sich sowas zusammenspinnen (gut gemeint) keine Ahnung von der wirtschaftlichen Seite haben :-) Und ja, da sind mehrere MannJahre drin und ein Paar hundert Tausend Euro wohl auch, da muss man nicht BWL studiert haben, um das zu sehen: Hardware-Entwicklung (100kE), Algorithmus-Portierung (10-50 kEuro), Übergeordnete Software entwickeln (Netzwerk,...) 20-50 kEuro, Prototypen-Bau (wohl 100kEuro für EIN solches Gerät), Testen/Verifikation (50kEuro), ein wirtschaftlich sinnvolle Produktion aufziehen (unbezahlbar). Das soll aber nicht heißen, dass man soetwas nicht in Angriff nehmen sollte! Erstens, muss man ja an der Uni irgendwas machen und die Doktoranten beschäftigen. Die Studenten machen dann die winzigen Teilaufgaben im Rahmen der Projekte/Seminare/Diplomarbeiten. Die Kunst besteht darin, damit schneller fertig zu werden, als die Hardware (z.B.GPUs) sich weiter entwickelt. In 5 Jahren, sind die Prozessoren und die GPUs so weit, dass die Entwicklung sich niemals lohnen würde. Nicht destotrotz bin ich darauf gespannt, welche Wege der TO gehen wird -- ob FPGA überhaupt in Frage kommt und man nicht z.B. mit Tesla-GPUs besser fahren würde. Grüße Kest
Kest schrieb: > Die Kunst besteht darin, damit schneller fertig zu werden, als die > Hardware (z.B.GPUs) sich weiter entwickelt. In 5 Jahren, Also zumindest Die Hardwareentwicklung muss man sowieso jemandem überlassen der sich damit auskennt. Währenddessen kann man an den FPGA Designs für den Algo arbeiten. 5 Jahre halte ich definitiv für übertrieben. Würde (mit passenden Leuten) eher 2 Jahre schätzen und da kann sich die FPGA Lösung dann doch lohnen. > und man nicht z.B. mit Tesla-GPUs besser fahren würde. In so ein paar Papern hatte ich gesehen das GPUs bei Smith Waterman wohl nicht ganz so toll sein sollen. Ob das immer noch so ist weiss ich natürlich nicht.
@Simon: Du solltest vielleicht nochmal ganz genau in Dich gehen, was Du an funktionellen Absichten hast. "Beschleunigung" heisst für mich, einen vorhandenen Algo beizubehalten- ihn aber nicht mit langsamen (?) Prozessoren, sondern einer Vielzahl derselben in FPGAs rechnen zu lassen. Dies tut man für gewöhnlich, um den Algo unverändert zu verwenden, weil man ihn gerade nicht umentwickeln möchte. Dazu realisiert man genügend viele FPGAs, um auf das Tempo zu kommen, und gut ist. Vor allem tut man das aber dann, wenn es keine ausreichend schnellen DSPs mit der genügenden IO-Bandbreite gibt. Da bin ich nicht so sicher, ob das wirklich bei Dir der Fall ist und ob man nicht mit einer DSP-Farm ausreichende Echtzeit bekommt. Der andere Ansatz wäre, wie angedeutet, einen Algo speziell für FPGAs zu erzeugen, womit man ganz andere Dimensionen der Bandbreite und der Latenz erreichen kann, was aber nach meinem Verständnis einem -> redesign entspräche und keiner "acceleration". Ob das Sinn macht, hängt davon ab, wie gut sich der Algo linearisieren und pipelinen lässt und wie gut er von der parallelen Verfügbarkeit von Daten und Zwischenergebnissen anderer Zeitpunkte im FPGA profitiert bzw. wie homogen dieses Gefüge wiederum ist. Nimmt man z.B. einen in der Rechentiefe sehr dynamischen Algo, wie den der Apfelmännchenberechung, sieht es nicht gut aus, was den Effizienzvorteil der FPGAs angeht, weil man entweder mit statischen Tiefen und damit ungenutzten Rechenzyklen arbeiten muss, um eine echte pipeline zu nutzen oder eben doch wieder einen virtuellen Ablauf mitsamt seiner Verwaltung einbauen muss. Für solche Systeme sind DSPs mit ihrer auf virtueller Rechentechnik ausgelegten Architektur finanziell erheblich effektiver - sofern, wie erwähnt, die Bandbreite passt und die Latenz akzeptabel ist. Zu diesen Dingen hast du noch nicht viel geschrieben, daher ist es schwer zu urteilen, ob FPGAs hier nötig und/oder angezeigt sind. Bei der Hardware selber kommt es darauf an, wie man die Datenströme lenken kann. Sobald da ein Master-Slave-System läuft, braucht es wieder Busse mit dynamischer Verwaltung. Je nach Isolationsgrad der Subrechner ist eine Stern- oder Linearbusverdrahtung sinnvoller, um den Datendurchsatz im Master zu maximieren. Bei linear verketteten Daten sind FPGAs definitiv von Interesse. Vom Selbstbau würde ich generell abraten. Ich habe das mal mit Spartan 2 FPGAs trainingsweise getan (Mini-Rack mit Einsteckplatinen) und stiess genau an das Beschaffungs- und Erhaltungsproblem. Die Sub-Einheiten müssen in gewisser Weise austark arbeiten und brauchen zumindest RAM als Puffer, da empfiehlt sich ein System aus käuflich erworbenen eval boards, deren Zahl man dynamisch ausbauen kann und die sich schlimmstenfalls auch mal durch andere Typen ersetzen lassen. Gerade beim Thema IB und Fehlersuche ist es nötigt, dass sich die Einheiten selber testen und booten können. Von daher kannst Du Dich mal bei den Systemen von Trenz oder Enclustra umschauen. Und dann bliebe da noch das Thema Auslastung der FPGAs: Das Runterbrechen des Algos führt zwangsweise zu einer Art Wolke von mehr oder weniger kompakten Rechenmodulen in 2- oder auch 3-dimensionaler Anordnung, die erst noch funktionell in ein FPGA gemappt werden muss. Da die Grössen sehr wahrscheinlich kaum zueinander passen werden, entsteht z.B. die Anforderung, N (=x*y*z) Module auf C (= a*b) FPGAs verteilen zu müssen. Um das zu automatisieren und dynamisch zu halten, ist ein sript nötig, dass die Funktionen passend verteilt und die benötigten FPGA-Modul-Instanzen generiert, wenn Du nicht bei jder Algo-Änderung manuelle Anpassungen vornehmen willst. Ich habe dies seinerzeit mal für ein virtuelles Audio-DSP-Modul vorgezeichnet: http://96khz.org/htm/scalable%20audiodsp.htm Damit wird eine beliebige Anzahl von DSP-Elementen mitsamt der nötigen Busverdrahtung auf ein FPGA-Array gemappt, wodurch abhängig von der Bus-Latenz (Rechnen und Schieben sind in einander geschachtelt) im Prinzip jedes Element, jedes Ergebnis eines jeden anderen Elementes sehen und verwerten könnte, was dann real natürlich nicht passiert. In jedem Fall wäre das ein ein Beispiel eines "hochparallelen" FPGAs. Ob es aber auch "hocheffizient" für die jeweilige Aufgabe ist, stünde auf einem anderen Blatt.
Morgen, was der Herr Schuhmacher sagt, kann man mehrfach unterschreiben. Ich würde auch mal sagen: Simulieren. Das alleine gibt schon eine leckere Diplomarbeit ab. Nach aller vorliegender Information könnte ich nicht mal im Ansatz eine Aussage machen, ob der Algo auf dem FPGA 'sinnvoll' umgesetzt werden könnte. Die Diskussion ist also nahezu hinfällig.. Bisher fallen mir so generell drei Sachen zur Evaluation ein: 1) Algo komplett "brute force" in HW umsetzen (klappt nur gut, wenn pipeline-bar) 2) Sich eine spezielle CPU eigens für die gängigen Operationen bauen und mit Microcode programmieren. 3) Ein DSP-Cluster und cleveres Interfacing. (1) kann irgendwann aufwendig/komplex/schlecht debugbar werden, besonders bei dynamischem Wachstum. (2) kann elegant sein und kompakt, aber es braucht etwas Erfahrung im GPU-Design. Die Lösung wird aber u.U. gut skalierbar, 8 Cores auf einem Spartan6-LX45 sind kein Problem, nur die Speicheranbindung an externes RAM ist ev. flaschenhalsbehaftet bis knifflig. (3) Da gab es mal am MIT ein Projekt mit einem ganzen DSP-Rack. Die DSPs kommunizierten untereinander per I2S. Die Daten kamen parallel per Glasfaser rein. Siehe auch hier (Beitrag "Multi-DSP-System Infoquellen") Zum Thema Simulation: Mit dem freien GHDL-Simulator kann man unter Linux (also nicht mit der mcode-Version unter Windows) einige nette Sachen betr. Co-Simulation mit Software machen. Z.B. kann man eine qemu-Simulation (C-Programm) über ein virtuelles Interface mit dem virtuellen FPGA quatschen lassen. Das geht gut auf verteilten Systeme (also per Netzwerk im Cluster), wenn die Simulation auf dem eigenen PC zu langsam läuft. Für solche Features latzt man im kommerziellen Pool richtig viel Geld (ich glaube, die volle Simulations-Suite von Cadence ging bei einigen 10k€ los) Für so ein ambitioniertes Vorhaben könnte man sicher gut ein paar Studenten ankokeln (aber nicht verheizen!). Grüsse, - Strubi
Ui, hier sind ja die richtigen FPGA-Super-Cracks versammelt. Da hätte ich doch gleich ein paar Fragen zum Thema paralles Rechen mit FPGAs: Jürgen Schuhmacher schrieb: > Damit wird eine beliebige Anzahl von DSP-Elementen mitsamt der nötigen > Busverdrahtung auf ein FPGA-Array gemappt, wodurch abhängig von der > Bus-Latenz (Rechnen und Schieben sind in einander geschachtelt) im > Prinzip jedes Element, jedes Ergebnis eines jeden anderen Elementes > sehen und verwerten könnte, Schaut sehr interessant aus. Hast Du diese DSPs selbst entworfen? Was können die? Martin S. schrieb: > Co-Simulation mit Software machen. Z.B. kann man eine > qemu-Simulation (C-Programm) über ein virtuelles Interface mit dem > virtuellen FPGA quatschen lassen. Das geht gut auf verteilten Systeme > (also per Netzwerk im Cluster), wenn die Simulation auf dem eigenen PC > zu langsam läuft. Auch das interessiert mich. Hättest Du so eine Art "Anleitung", wie man das mit der Co-Simulation hinbekommt? Ich habe das auf einer Demonstrationsveranstaltung von MATHWORKS gesehen wie sie es mit MATLAB und Modelsim machen. Das war richtig prima: FPGA-Design schnappen, im Simulink instanziieren und auf den Knopf drücken. Dann rennt die Simulation wie ein D-Zug. >MircoProgrammierung Da steige ich immer noch nicht so ganz dahinter, wie das so genau gehen soll. Ich hatte hier schon mal dazu was gefragt, was das Thema von Georg aufgeworfen wurde: Beitrag "Re: FPGA grafisch programmieren"
Markus Wagner schrieb: > Auch das interessiert mich. Hättest Du so eine Art "Anleitung", wie man > das mit der Co-Simulation hinbekommt? Ich habe das auf einer > Demonstrationsveranstaltung von MATHWORKS gesehen wie sie es mit MATLAB > und Modelsim machen. Das war richtig prima: FPGA-Design schnappen, im > Simulink instanziieren und auf den Knopf drücken. Dann rennt die > Simulation wie ein D-Zug. Hi Markus, so simpel läuft es leider nicht, es braucht etwas Programmierarbeit, bzw. Scripting. Anleitung per se gibt es auch nicht, nur etwas Doxygen-Dokumentation und div. Präsentationen. Sind ansich zwei Libraries: 1) ghdlex: virtuelle I/O-Interfaces für GHDL Simulator (nicht mcode) 2) netpp: Ansprechen der virtuellen HW per Netzwerk Etwas Intro hats hier: http://www.fpgarelated.com/showarticle/20.php Die einfachste Variante ist die mit dem virtuellen FIFO: Software schiebt Daten ins virtuelle FPGA, und liest verarbeitete Daten wieder aus. Eine Anwendung z.B.: Co-Simulation eines Hardware-JPEG-Encoders. Siehe auch http://tech.section5.ch/news/?p=181. Die qemu-Sache habe ich gar nicht dokumentiert, das geht ansich am simpelsten über named Pipes/virtuelle COM-Ports. Grüsse! - Strubi
Eine Idee, die ich mit unserem Biologen dazu damals besprochen habe, war ein zweistufiges Konzept. Zuerst sehr grob und einfach "Kandidaten" im FPGA finden (da kann man recht schludrig vorgehen, vereinfacht die HW deutlich) und danach mit dem PC nochmal fein bearbeiten. Aus Zeit- und Studentenmangel konnte das aber nicht konkret simuliert werden. Kann also auch eine Schnappsidee sein... Wie gesagt, ich halte es aber bei der Anwendung auf keinen Fall sinnvoll, den vorhandenen Algoritmus 1:1 aufs FPGA umzusetzen. Macht nur Arbeit und bringt effektiv nix. Man muss das FPGA für Sachen nutzen, die es am besten kann. Und das ist hier massiv paralleles Bitgefummel mit kleinen Lookuptabellen.
Wer in seinem Anwendungsgebiet am Anschlag ist mit der Bandbreite zum Speicher wird sich über diese Nachricht freuen: http://www.eetimes.com/document.asp?doc_id=1320156&itc=eetimes_node_193&cid=NL_EET_ProgrammableLogicDL_20131121&elq=85368f54a52742eb9a4e8307af0b4114&elqCampaignId=2661 Ein massives FPGA Board mit einem hybrid memory cube (HMC) von Micron (160 GB/s Bandbreite).
lecker :-)
Mmmmh kostet nur leider sicher gut 5 stellig ;-)
Strubi schrieb: > Hi Markus, > > so simpel läuft es leider nicht, es braucht etwas Programmierarbeit, > bzw. Scripting. Anleitung per se gibt es auch nicht, nur etwas Danke für Deine Hilfe. Schaue ich mir mal an.
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.