Welche Möglichkeiten habe ich, einen bestehenden PC für Synthesen zu
optimieren? Genannt wurden bisher:
- Command Line verwenden, also ohne GUI / IDE
- viel RAM
Gerade zum RAM habe ich mir Gedanken gemacht:
Die Tools laufen ja nicht so richtig viel schneller, wenn man ein
64-Bit-System benutzt, abgesehen von dem RAM-Speicher. So eine arge
Verbesserung habe ich da aber noch nicht gesehen, wenn ich z.B. WinXP32
und Win7-64 vergleiche. Ich führe das auf die Nutzung der Festplatte
zurück: Xilinx z.B. ist Weltmeister im Anlagen von files.
Wäre denkbar, mit W64 einen grossen RAM-Speicher zu verwenden und diesen
als virtual RAM-Disk zu benutzen?
Wie liesse sich das einstellen?
Ralli schrieb:> Welche Möglichkeiten habe ich, einen bestehenden PC für Synthesen zu> optimieren? Genannt wurden bisher:>> - Command Line verwenden, also ohne GUI / IDE> - viel RAM>> Gerade zum RAM habe ich mir Gedanken gemacht:>> Die Tools laufen ja nicht so richtig viel schneller, wenn man ein> 64-Bit-System benutzt, abgesehen von dem RAM-Speicher. So eine arge> Verbesserung habe ich da aber noch nicht gesehen, wenn ich z.B. WinXP32> und Win7-64 vergleiche. Ich führe das auf die Nutzung der Festplatte> zurück: Xilinx z.B. ist Weltmeister im Anlagen von files.
Afaik liefen die Xilinx Toools unter Linux ein gutes Stück schneller als
die Windows Pedants.
Der Austausch der Projekt Harddisk gegen eine (leere) SSD bringt auch
einiges (Stichwrd Disk-IOs).
Alternativ auch gerne eine Ramdisk entsprechender Größe...
>> Wäre denkbar, mit W64 einen grossen RAM-Speicher zu verwenden und diesen> als virtual RAM-Disk zu benutzen?
wie gesagt, Disk-IO ist durchaus ein Thema...
> Wie liesse sich das einstellen?
Kennt jemand eine 64Bit Windows Version?
Gruß Vanilla
Bevor man blind rumrät sollte man in Erfahrung bringen, was denn dabei
die Performance-Bremse ist:
- CPU, nur 1 Thread relevant
- CPU, Last auf mehrere Threads verteilt
- Disk-I/O bremst CPU
- RAM zu knapp, führt zu Paging
SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während
der Synthese wirklich viel auf der Platte malocht wird und die CPU
derweil nicht zum arbeiten kommt. Nicht aber, wieviele Files der
Installer auf die Platter klatscht.
Process Explorer kriegt raus, wie die Lastverteilung auf Threads ist.
Ist das bloss einer, und der ist voll ausgelastet, dann ist einzig die
CPU relevant, und zwar der Turbo-Modus. Der Rest zählt dann wenig.
A. K. schrieb:> Bevor man blind rumrät sollte man in Erfahrung bringen, was denn dabei> die Performance-Bremse ist?>> - CPU, nur 1 Thread relevant> - CPU, Last auf mehrere Threads verteilt> - Disk-I/O bremst CPU> - RAM zu knapp, führt zu Paging>> SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während> der Syntese wirklich viel auf der Platte malocht wird, nicht wieviele> Files der Installer auf die Platter klatscht.>> Process Explorer kriegt raus, wie die Lastverteilung auf Threads ist.> Ist das bloss einer, und der ist voll ausgelastet, dann ist einzig die> CPU relevant, und zwar der Turbo-Modus. Der Rest zählt dann wenig.
Bis vor einigen Versionen startete die gesamte Xilinx Synthese ledigich
einen Thread.
In neueren Versionen ist wohl das Placing? multithreading, einen grossen
Performanceschub bzw. Auslastung von mehr als einer CPU konnte ich in
den gemonitorten Projekten nicht beobachten.
Imho ist ein schneller Kern mit großen Caches deutlich mehr wert wie ein
Sack voll weiterer CPU-Kerne.
Die Menge des zur Verfügung stehenden RAMs ist nur für größere FPGAs von
Relevanz. Hierzu gibt es von Xilinx aber entsprechende Dokumentation.
Imho lassen sich größere Projekte auf den Boliden nicht mit einem 32Bit
Windows synthetisieren...
Gruß Vanilla
A. K. schrieb:> SSD bringt nur was, wenn viel Disk-I/O beteiligt ist. Also ob während> der Synthese wirklich viel auf der Platte malocht wird und die CPU> derweil nicht zum arbeiten kommt. Nicht aber, wieviele Files der> Installer auf die Platter klatscht.
Die Größe der Xilinx Installation ist zwar schon inflationär, aber es
geht hier tatsächlich um Disk-IO der zig bis hunderten teils temporären
Files welche Xilinx anlegt, schreibt appended und anschliessend verwirft
bzw. auf der Platte zurücklässt...
Das können je nach Projekt dann schon ein paar hundert MB sein, welche
in kleinen Häppchen dahinerstellt und prozessiert wurden...
Die ganze Xilixn Toolchain kann Ihre Herkunft einer Vielzahl kleiner?
Funktionen welche sich lustig einander zu pipen nicht verhelen. Das
ganze ist in der UNIX Welt gang und gebe und dort entsprechend
optimiert.
Das dürfte auch schlussendlich der Grund sein, warum die Xilinx-ISE
unter Linux immer schneller fertig war wie unter Windows...
Moin,
Vanilla hat recht, vor ca. 4 Jahren lief ISE, entweder 9.x oder 10.x bei
mir fast doppelt so schnell unter Linux wie unter Windows. Aber nix
multithreaded Synthese, das lustige war allerdings, dass der IDE-Task
zur Anzeige des drehenden "busy"-Icons einen Kern schon fast ausgelastet
hat..
Also ist der Umstieg auf Makefile/Commandline schon mal gar nicht so
schlecht, Memory spart man auch etwas.
Ich würde der Kiste bevorzugt viel RAM spendieren, und unter Linux auch
mal eine RAM-Disk für vielen Temporärkram einsetzen. Das half zumindest
in der Vergangenheit bei riesigen GCC-Projekten. Allerdings braucht man
doch oft die Temporärdateien als nichtflüchtig, und das HD-Caching ist
unter Linux ziemlich gut, dass man damit heuer wohl nicht mehr viel
Performance rausholt.
Grüssle,
- Strubi
Ich hab das erst letztens mal wieder getestet, unter Win x64 ist es bis
auf ein paar Sekunden die für die xml zu html Transformation drauf gehen
egal ob Command Line oder ISE, die ruft doch die gleichen Programme auf.
Auch eine SSD bringt nicht viel, die allermeiste Zeit wird im RAM
gearbeitet. Viel RAM und eine CPU mit viel Cache bringen einiges. Mein
Arbeitsplatz Rechner ist eine HP Z620 mit 16GB und einem Xeon das geht
sehr ordentlich. Map und par können inzwischen MT aber nur beschränkt
und wenn man nicht die -power Option an hat.
Ein Rechnerverbund bringt dann vermutlich auch nichts, oder? Ich kenne
das aus dem Bereich des Renderings, wo sie 8-16 Rechner
zusammenschalten, um auf Tempo zu kommen.
Dazu müsste die Software erst mal parallelisiert sein. Aber bei Xilinx
kann XST überhaupt kein MT, MAP nur maximal 2 Threads und PAR kann
theoretisch alle CPU Kerne benutzen, aber zeitlich btingt das nach
meinen Messungen nichts weiter. Ich vermute die Algoritmen lassen sich
nicht so ohne weiteres parallelisieren, sonst hätten die das schon längt
getan. Bei großen Designs übersetzt man ja eh nur selten, erst wenn die
Simulation alles OK ansagt. Ich muss auf ein Artix 7 200T Design trotz
der Z620 noch etwa eine Stunde warten, und da ist der nicht mal halb
voll.
Christian R. schrieb:> Ich vermute die Algoritmen lassen sich> nicht so ohne weiteres parallelisieren,
Parallelisierung bestehender sequentieller Programme ist harte Arbeit,
wenn sich das von der Arbeitsweise des Programms nicht grad aufdrängt.
Solche Kosten investiert man nur, wenn man dadurch mehr Gewinn einfährt.
Den machen die aber über die FPGAs selbst, nicht über das Programm - und
sucht sich wirklich jemand FPGAs nach der Laufzeit des Designprogramms
aus?
A. K. schrieb:> und> sucht sich wirklich jemand FPGAs nach der Laufzeit des Designprogramms> aus?
Wenn du mal 1 1/2 Stunden gewartet hast bis alles durch ist und dabei
ein FPGA-Entwickler zuschaut oder du immer auf 5 andere warten musst,
bis du einen beschissenen Bugfix durchbringst und das ganze 2 Stunden
dauert dann - JA!
Wenn möglich, bestücken wir generell größere FPGAs in Prototypen.
Dadurch laufen die Tools schneller und man kann auch Alternative
Implementierungen ausprobieren (von Debug-Designs gar nicht zu
sprechen).
Meine Erfahrungen mit Quartus allgemein: MacBook Pro 13 i5 mit 2.5 GHz,
SSD und 16 GByte, Windows/Linux//Quartus in VMware ist rund doppelt so
schnell fertig, wie native auf einem älteren Xeon E5420 (2.5 GHz
Quad-Core) mit Festplatte und 8 GByte RAM.
Auf einem i7-2600K (SSD, 16 GByte RAM, 3,4 GHz) ist das Desin rund 3-4
Mal schneller durch, als auf dem Xeon.
Also:
Xeon: 100 %
MacBook i5 200 %
i7-2600K 300 %
Der nächste Rechner wird mindestens 32 GByte RAM haben, 6 Kerne und SSD
sowieso. Ich habe keine Lust mehr extra Rechner für FPGA-Designs
anzuschmeißen, muss also alles in VMwares laufen.
Grüße
Kest
Kest schrieb:> Wenn möglich, bestücken wir generell größere FPGAs in Prototypen.> Dadurch laufen die Tools schneller und man kann auch Alternative> Implementierungen ausprobieren (von Debug-Designs gar nicht zu> sprechen).
Das größere FPGAs generell schneller synthetisiert werden mag ich nicht
unterschreiben. Oft machen gerade zu grosse FPGAs durchaus Probleme, vor
allem dann wenn Schaltungsteile sich geometrisch über einen weiten
Bereich erstrecken (IOs), dann noch Besonderheiten (DSP/Multiplier),
BRAM und ggfs. Regional Clocks in Spiel kommen... Da passiert es dann
schon mal gerne dass die XST zwischenrein beim größeren FPGA das RAM (im
Rechner) ausgeht, die XST das Handtuch wirft oder aber auch nach ein
paar zusätzlichen Stunden dann doch eine Lösung findet. Das gleiche
Design lief auf einem kleineren FPGA (Füllgrad im kleineren 50-60%) in
wenigen Minuten durch... Is also kein generelles Heilmittel
Manchmal hilft auch den letzten FPGA Synteselauf als Guide mitzugeben,
kann aber ebenfalls wiederum fürchterlich schief gehen.
Tröstet es eigentlich wenn ich erzähle das 1989 ein Syntheselauf für
einen XC2064 (64 FFs, 64 4fach--LUT, keine BRAMs, keine ...) ein
Syntheselauf auf einer Highend Maschine ( 80486-EISA Rechner (Full-Size
AT mit 16MB Speicher!!!), 80486-33MHz, EISA Cache SCSI-Controller mit
>20MB/s !!!) gerne mal 24 Stunden gedauert hat, einem das Design dann
mit 98% vor die Füsse geworfen hat und man dann nochmals 2 Stunden
gebraucht hat um die fehlenden 2 Verbindungen von Hand zu verlegen.
Vanilla schrieb:> Tröstet es eigentlich wenn ich erzähle
Ja, ich kann mich auch noch an Designs hier 2004 erinnern, die 512
Makrozellen eines XC2C512 benutzt haben und dann ISE nach mehreren
Stunden sagte, dass es doch nicht ganz reinpasst...und die Rechner waren
für damalige Verhältnisse schon recht schnell.
Deswegen simuliert man ja und implementiert erst wenn nötig.
Kest schrieb:> Der nächste Rechner wird mindestens 32 GByte RAM haben, 6 Kerne und SSD> sowieso. Ich habe keine Lust mehr extra Rechner für FPGA-Designs> anzuschmeißen, muss also alles in VMwares laufen.>> Grüße> Kest
Hallo Kest,
das hat vor allem auch dann Vorteile wenn Du dein FPGA Design mehrere
Jahre supporten musst.
Eine Syntheseumgebung in eine VM gesperrt und Du kannst sicher sein dein
Design auch nach Jahren noch lauffähig zu synthetisieren.
Bei Xilinx z.B. war es in den vergangenen Jahren mehr als einmal
passiert, dass neuere ISE-Versionen ältere Coregen-Componenten nicht
weiter unterstützen, neuere Versionen kein lauffähiges Design mehr
ergaben (kein Fehler in der (Logik-) Simulation feststellbar, von
Dritt-Firmen gelieferte Netzlisten IPs nicht mehr einzubinden waren
oder,oder...
Vanilla schrieb:> das hat vor allem auch dann Vorteile wenn Du dein FPGA Design mehrere> Jahre supporten musst.
Deshalb gibt es beim Datenrelease von einem Projekt auch ein
VMWare-Image mit allen Tools, mit denen man alles
compilieren/synthetisieren kann :-)
Mittlerweile sind das schon einige ;-)
Es ist auch einfacher verschiedene Tool-Versionen auszuprobieren, als
wenn man alles native installiert. Ein Glück kann Altera alle Quartus
Versionen parallel installieren, und es funktioniert auch ganz gut (samt
ModelSIM und NIOS-Stuff)
Ich muss aber sagen, ein langsamer Rechner ist auch als eine
erzieherische Maßnahme zu verstehen ;-) "Kleine" Änderungen oder "mal
schnell was ausprobieren" ist dann nicht drin
Kest schrieb:> Ich muss aber sagen, ein langsamer Rechner ist auch als eine
Und als allgemeine Ausrede wieso die Arbeit nicht in der projektierten
Zeit erledigt werden konnte ;-)
(geschrieben auf einem AMD Turion Dual Core mit 1,75 GiB RAM und
magnetischer Festplatte)
Wir verwenden ganz normale PCs mit 2,4GHz und 4GB RAM, die aber
offiziell als "Workstation" deklariert sind. Wenn man sich mit sowas
abquälen muss, dauert es dann halt. Wir machen aber auch nur ganz kleine
FPGAs.
