Echtzeitperformance von aktuellen Intel und AMD CPUs

[badb100d]

Hallo zusammen,

Vielleicht bin ich hier völlig falsch, aber ich versuche es einfach mal :-) ich habe mal eine Frage an die Experten hier insbesondere vermutlich im Bereich Audiorecording, aber vlt. gibt es ja auch den ein oder anderen Experten im Bereich Echtzeitanwendungen.

Kurz zum Kontext:
Ich würde gerne einige aktuelle CPUs benchmarken im Hinblick auf ihre Performance, Latenzen und Jitter. Interessant ist das für mich vor allem im Hinblick auf leistungshungrige Regelungsalgorithmen mit Taktraten im Bereich 1000 - 10.000Hz. Bisher wurden dafür meistens Embedded Intel Systeme gekauft und mit einem echtzeitfähigen Linuxkernel auf unter 10µs jitter getuned. Da diese aber inzwischen oft mit ihrem Basistakt performancetechnisch an die Grenze kommen will ich mich mal in anderen Bereichen umsehen.

Nun zu meiner Frage:
Hat hier schon jemand diesbezüglich Erfahrung gesammelt mit Prozessoren aus der AMD Desktop und/oder Threadripper serie?
Insbesondere vergleiche von 7950x und 7950x3d im Basistakt und bei der gleichzeitigen auslastung mehrerer Kerne würden mich interessieren

Viele Grüße!

 

[Darkblade08]

Das ist schon ein sehr spezieller Fall, aber eventuell als Hinweis. Auch AMD bietet Embedded Systeme an. Dazu gehört auch die Ryzen 7000 Familie oder auch EPYC Prozessoren.

Aber deine Frage kann ich leider nicht direkt beantworten.

 

[Tamron]

Auch keine direkte Antwort, aber ist dein UseCase bei PugetSystems vielleicht aufgeführt?
Die haben sonst echt coole Benchmarks/Tests für professionelle Anwendungen bzw. Bereiche.

 

[Piktogramm]

Wäre nicht erst einmal sinnvoll zu definieren von was genau du die Latenz und Jitter du testen willst?
Du nennst zwar Audio, allein da machst es aber einen erheblichen Unterschied, ob du via I²S, USB, Thunderbolt und/oder PCIe direkt von der CPU oder dem Chipsatz misst.

Regelungsalgorithmen mit Taktraten im Bereich 1000 - 10.000Hz

Was sollen Regelungsalgorithmen sein? Regelkreise sind egal ob digital oder analog ausgeführt eigentlich immer eine Implementierung eines oder mehrerer Algorithmen.
Wobei auch hier zu Nennen wäre, was geregelt werden soll.

 

[SpamBot]

Wäre nicht erst einmal sinnvoll zu definieren von was genau du die Latenz und Jitter du testen willst?

Das ist Standard Kram bei audio Bearbeitung, einfach Mal googeln. Dazu gibt es Tests/ Benchmarks.

Mein System fällt hier im Benchmark gnadenlos sls untauglich durch.

Edit: ist aber ganz viel settings Sache. Viele Dinge die beim zocken und co. die Leistung steigern knallen hier mit spiks/ schlechtrm Latenzen rein

 

[Piktogramm]

Das ist Standard Kram bei audio Bearbeitung,

Wenn du behauptest, dass es ein Standard ist, nenne die Norm, ein RFC.
In der Regel ist es eben kein Standard der da in irgend einer Form definiert ist, es sind allenfalls Konventionen, die es je nach Blase in div. Abänderungen gibt.
Ganz abgesehen davon, dass ich ja schon aufgezählt habe, dass es verschiedene Pfade geben kann, die allein soviel Varianz reinbringen, dass es nicht weiter lohnt drüber nachzudenken solang der TE nicht konkreter wird.

 

[SpamBot]

Standard

Das hab ich nicht geschrieben! Standard Kram =/ Standard.

Es ist bei audio Zeug dann eben geläufig. Ich musste Mal Freunden bei einem Studio helfen. Wenn du Beispielsweise 20 Audikanäle mit der Band einspielst passiert da viel in Echtzeit. Hierfür gibt es Tools die schauen wie nahe ein System an "Echtzeit" herankommt. Je nach Abweichung ist das System dann tauglich oder nicht.

Ein 0815 Zocker system ist jedenfalls nicht geeignet. Zumindest solange man kein zweites cleanes Windows aufspielt. Und selbst dann ist manche Hardware nicht geeignet

 

[badb100d]

Wäre nicht erst einmal sinnvoll zu definieren von was genau du die Latenz und Jitter du testen willst?
Du nennst zwar Audio, allein da machst es aber einen erheblichen Unterschied, ob du via I²S, USB, Thunderbolt und/oder PCIe direkt von der CPU oder dem Chipsatz misst.


Was sollen Regelungsalgorithmen sein? Regelkreise sind egal ob digital oder analog ausgeführt eigentlich immer eine Implementierung eines oder mehrerer Algorithmen.
Wobei auch hier zu Nennen wäre, was geregelt werden soll.

Konkret geht es um Regelung komplexer Mechatronischer Systeme. Grundsätzlich aber grob abstrahiert immer der gleiche Ablauf:

• Telemetrie wird von Hardware gelesen; Quelle kann im Grunde alles sein: PCIe, USB, CAN, EtherCat, Ethernet, I2C, SPI, ...
• Telemetrie wird durch Regelung verarbeiter und neue Kommandodaten generiert
• Kommandodaten werden zurück an Hardware gesendet

das ganze dann im genannten Takt und takthaltend. D.H. die Hardware hat immer rechtzeitig einen Kommandodatensatz in der Pipeline um arbeiten zu können. Wenn der nicht innerhalb eines gesetzten Zeitfensters da ist passieren schlimme Dinge.

Beispiel:
Regeltakt sind 8Khz: Alle 128µs kommt ein Telemetriepaket von der Hardware über Kernel und Middleware in den Regelungssoftware und die berechneten Kommandodaten gehen den selben Weg zurück an die Hardware

Meistens laufen mehrere dieser Pipelines parallel auf einem Rechner.
Die genannten 10µs jitter sind das was sich maximal an Abweichungen im takt ergeben darf, damit schritthaltend verarbeitet werden kann.

 

[Tornhoof]

Afaik ist das normale Windows dafür nicht geeignet, diese Tests prüfen nur gewisse Latenzen um zu testen ob man in die Nähe kommt.

Ggf mal Windows IOT anschauen, das hat ein konfigurierbares soft-rt Feature.
https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time

Aber die benötigen, dann genauso wie die Linux Systeme, spezielle Hardware und ggf Treiber.

 

[badb100d]

Afaik ist das normale Windows dafür nicht geeignet, diese Tests prüfen nur gewisse Latenzen um zu testen ob man in die Nähe kommt.

Ggf mal Windows IOT anschauen, das hat ein konfigurierbares soft-rt Feature.
https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/soft-real-time/soft-real-time

Das ist mir schon klar. Es kommt immer ein Linux mit Echtzeitkernel zum Einsatz. Die Frage ist auch nicht ob das geht, denn das mache ich ja aktuell schon mit normalen Intel Server-CPUs. Mich interessiert ob da jemand Erfahrung mit AMD CPUs im Echtzeitbereich hat und mir sagen kann ob er da z.B. Unterschiede im Vergleich zu einem Intel System festgestellt hat oder ob vlt jemand mit einem ähnlichen Problem mal eine AMD CPU mit 128MB L3 cache ausprobiert hat, da ich mir erhoffe, dass das die cache miss rate verbessert und somit den jitter verbessert.

Ergänzung (14. Juni 2024)

Auch keine direkte Antwort, aber ist dein UseCase bei PugetSystems vielleicht aufgeführt?
Die haben sonst echt coole Benchmarks/Tests für professionelle Anwendungen bzw. Bereiche.

Die scheinen sich ja auf etwas speziellere Fälle spezialisiert zu haben. Vlt. frage ich dort mal nach, Danke für den Tipp

 

[Piktogramm]

Du bist da glaub derart spezifisch unterwegs, dass du da wenig finden wirst, die deine Probleme teilen und offen kommunizieren dürfen.

Grundlegend ist was Latenzen angeht Intel etwas besser aufgestellt[1] und innerhalb AMDs Portfolio stehen die APUs[2] besser da als die großen CPUs mit Chiplets. Die Kommunikation zwischen den Chiplets frisst Zeit und Kommunikation zwischen den CCDs ist vergleichsweise lahm, das Verschieben von Prozessen zwischen den CCDs wäre in deinem Fall wohl die Hölle (Threads auf Cores zu pinnen ist Pflicht, das gilt aber auch für Intel).

da ich mir erhoffe, dass das die cache miss rate verbessert und somit den jitter verbessert.

Vermutest du Cachemisses oder hast du hast du bereits Werte der Performcecounter der CPU? Zudem kennst du den Code und wir nicht. Du kannst am ehesten abschätzen, wie groß der Datensatz ist, und ob größerer L3 Cache überhaupt die Chance hat die Trefferquote zu erhöhen.

PCIe, USB, CAN, EtherCat, Ethernet, I2C, SPI, ...

Ähhh, dass sind gleichmal verschiedene Baustellen und das Zeitverhalten jede dieser Schnittstellen auf einer bestimmten Hardware auf einem Echtzeitlinux zu charakterisieren und zu optimieren dürfte je eine Bachelorarbeit sein.
Pauschal kann ich dir sagen, dass man aus USB mit Microframes 8kHz Polling hinbekommen sollte bei gutem Wetter, Rückenwind und Bugfreier Hardware wie Software.. Bei den Anforderungen würde ich da aber zu einem: "Kann man machen, dauert aber, wird teuer und bleibt Scheiße". Ethernet sollte gehen, ich würde aber erwarten, dass TCP an der Stelle nicht zum Einsatz kommt.
uuund die genannten Protokolle sind teils nicht Resistent gegen Kollissionen, ohne zu wissen wie Kollissionen behandelt werden oder vermieden werden, wird das Ganze noch komplexer.

Wenn ich das lese, denke ich auch eher an einen dicken µController bis FPGA.


[1]Genaugenommen kommt es da auch sehr auf spezifische CPUs drauf an. Designs mit P/E-Cores sind Großmeister im FullRND-Jitter .
[2] Wobei es da mittlerweile auch ab Zen4 die "normalen" und "c" Kerne gibt, die tendenziell abweichendes Laufzeitverhalten haben.

######################

Achso, eine Frequenz von 8kHz bei einem Jitter 10µs ist ganz nett, aber wie lang darf das Delay sein zwischen Ein- und Ausgabe?

 

[badb100d]

Erstmal danke für deine ausführliche Antwort!. Das war jetzt auch nur ein Beispiel um den Rahmen besser zu verdeutlichen. Die praktischen Anforderungen an die Echtzeit schwanken natürlich auch stark je nachdem welche Hardware angebunden wird und ein USB Interface wird normalerweise nicht verwendet um mit 8Khz zu regeln.

Das Thema komplett auszubreiten würde aber auch viel zu weit gehen und das ganze ist ja auch kein neues Problem was jetzt gelöst werden soll. Es gibt ja bereits eine funktionierende Lösung, nur kommt die aktuell an ihre Grenzen, da die Regelungsmodelle immer komplexer werden und damit die (mittlerweile auch etwas ältere) CPU von der Leistung her nicht mehr hinterherkomt. Cache misses sind bei den größeren Modellen auf jeden Fall auch ein zunehmendes Problem.

Es geht also wirklich nur darum einen Sinnvollen Nachfolger für das Rechenherz zu finden.

Mir ist auch klar, dass mir hier jetzt keiner fundiert sagen kann: "Nimm den 14900k oder den 7965WX und dann geht das auf jeden Fall"

Ich muss so oder so verschiedene Systeme benchmarken und ich kann jetzt natürlich einfach die nächstbesten aktuellen CPUs kaufen und probieren aber jedes System das ich benchmarken muss kostet Geld und vor allem viel Zeit.

Ich versuche also irgendwie die Liste der in Frage kommenden CPUs sinnvoll einzugrenzen.

Vlt war es auch der völlig falsche Ansatz von mir das Problem zu beschreiben und ich werfe einfach mal konkretere Fragen in den Raum die mir durch den Kopf gehen:
Größeren caches nah an der CPU bei Intel prozesoren sind vlt besser oder doch der größere L3 cache bei AMD?
Macht es überhaupt sinn mit dem 3D cache oder hole ich mir da wieder zusätzliche Probleme rein?
Macht die neue Architektur mit Performace und Effizienzkernen von Intel evtl Probleme abseits von CPU pinning?
Wie viele kerne kann eine CPU überhaupt voll auslasten ohne in ihr TDP limit zu laufen (vor allem bei embedded prozessoren ein problem)?
Macht das chiplet design von AMD evtl probleme bei konkurrierenden IO zugriffen der Kerne?
Wie kommt es, dass der Basistakt von AMD so viel höher ist als bei intel? Das macht mich skeptisch. Verstehen Intel und AMD das gleiche darunter?
Gibt es bei der Plattform noch sonstige einschränkungen die ich aktuell noch gar nicht auf dem schirm habe?
Kann ich 16 Kerne bei einem 7950x überhaupt sinnvoll parallel verwenden ohne einen neuen Flaschenhals zu finden oder versuche ich besser gleich einen 7900x oder sogar besser 7800x?

 

[Piktogramm]

Größeren caches nah an der CPU bei Intel prozesoren sind vlt besser oder doch der größere L3 cache bei AMD?
Macht es überhaupt sinn mit dem 3D cache oder hole ich mir da wieder zusätzliche Probleme rein?

An sich habe ich das bereits angeschnitten.
Die getrennten CCDs sorgen bei Kommunikation zwischen Kernen auf einem CCD und verschiedenen CCDs zu stark unterschiedlichen Latenzen (https://www.anandtech.com/show/1758...ryzen-5-7600x-review-retaking-the-high-end/10 ). Ob das Relevant ist, benötigt Wissen um den Code der laufen soll. Bei Prozessen mit viel Interprozesskommunikation und Zugriff auf den selben Speicherbereich wird das zum Problem. Da müsstest du entsprechend Prozesse so pinnen, dass sie nur auf einem CCD laufen.
Beim L3 Cache, gut du hast aktuell Cachemisses. Die Frage bleibt aber, wie die Zugriffsmuster ausschauen. Wenn du da ne Lookuptable über Gigabyte groß ist und zufällig ausgelesen wird, bringt dir der größere L3 Cache kaum etwas. An der Stelle willst du die CPU mit dem dicksten Speicherinterface und den geringsten Latenzen (also Intel oder ne AMD APU).
Passt die Datenstruktur bzw. die häufigsten, wiederkehrende Zugriffe auf knapp 90MB, dann bringt dir dicker L3 Cache enorm viel (dann müsstest du die entsprechenden Prozesse exklusiv auf das entsprechende CCD pinnen). Ein Nachteil ist im Zweifelsfall, dass die CPUs bzw. Dies mit 3D Cache mit geringerem Takt laufen, auch da musst du wissen, das dein Code da für Anforderungen hat.

Macht die neue Architektur mit Performace und Effizienzkernen von Intel evtl Probleme abseits von CPU pinning?

Wenn du harte Anforderungen an Jitter hast, sind CPU Kerne mit stark unterschiedlichem Durchsatz beim Speicher und bei den Recheneinheiten eine unglaubliche Steigerung der Komplexität. Es gibt Intel Celeron, i3, i5 und Xeon mit ausschließlich P-Cores. Der Aufpreis ist im Vergleich zur reduzierten Komplexität (aka: Manntage für Entwicklung und Evaluation) lächerlich.

Wie viele kerne kann eine CPU überhaupt voll auslasten ohne in ihr TDP limit zu laufen (vor allem bei embedded prozessoren ein problem)?

Kommt auf den Code an. 800% Auslastung bei einem 8Kerner der zu 750% mit I/O-Wait beschäftigt ist, geht weit unter dem TDP Limit. Wirf auf die selbe CPU stark vektorisierten Code drauf und das TDP-Limit ist erreicht und die CPU nähert sich tendenziell dem Basistakt an, selbst wenn du normalerweise mehr erzwingst.

Macht das chiplet design von AMD evtl probleme bei konkurrierenden IO zugriffen der Kerne?

I/O auf was? Es gibt Ressourcen, die global nur einmal vorhanden sind, blockieren und vergleichsweise lahm sind (der Hardware Zufallsgenerator zum Beispiel)[1]. Sowas wie internes SPI/I²C ist im Vergleich zu modernen, großen CPUs unglaublich langsam. Da müsstest du dich so oder so drum kümmern einen Broker zu nutzen. Bei PCIe ist es fast egal, solang der Bus nicht übermäßig belastet wird.
Die Probleme sind aber überwiegend die Selben bei allen Mehrkernsystemen, die Chiplets stehen da potentiell schlechter da, aber bei erlaubten 10µs Jitter sollte das in vielen Fällen weniger ins Gewicht fallen.

Wie kommt es, dass der Basistakt von AMD so viel höher ist als bei intel? Das macht mich skeptisch. Verstehen Intel und AMD das gleiche darunter?

Grob sollte der Basistakt das sein, was die CPUs schaffen, wenn man den fordernsten Code auf alle Kerne wirft und die CPU dazu verdonnert in ihrem TDP-Limit zu bleiben.
Ob da nun extremer, synthetischer Code genutzt wird, oder ein forderndes aber reales Beispiel, mit welcher Kühlung da hantiert wird etc. pp. ist großteils unbekannt.
In deinem Fall kannst du Komplexität beim Timing verringern, wenn du die CPU auf eine Frequenz festlegst und damit das Ramping der Frequenzen vermeidest und Jitter bei der Laufzeit. Es ist halt nur fraglich, welche fixe Frequenz bei deinen Lasten sich kühlen lassen, im TDP-Limit liegen und gewünschte Latenzen ermöglichen.

Gibt es bei der Plattform noch sonstige einschränkungen die ich aktuell noch gar nicht auf dem schirm habe?

So wenig konkret wie du fragst, scheinst du die spezifische Architektur des Systems nicht zu kennen. Da lauert noch Einiges. Schon allein die Software + RTLinux bietet Komplexität mit wenig tausenden Parametern. Herauszufinden welche davon empfindlich sind und welche nicht ist der halbe Spaß!

Kann ich 16 Kerne bei einem 7950x überhaupt sinnvoll parallel verwenden ohne einen neuen Flaschenhals zu finden oder versuche ich besser gleich einen 7900x oder sogar besser 7800x?

Patschehändchen hoch, wer sollte das System und den Code kennen? Wer immer die Hand oben hat ist die Person, die die Frage beantworten können sollte.



[1] Gibt es bei Intel sicher auch, ich hatte zuletzt nur kein Intelsystem

 

[ropf]

Kurze Zwischenfrage - warum nimmst du für die Aufgabe keinen Signalprozessor statt einer Universal-CPU?

Nicht genug Rechenleistung? Die Dinger falten inzwischen mehr als ein Dutzend Audiokanäle mit mehreren Tausend Taps langen Filtern in Echtzeit, und der ganze Overhead, die Kompexität und die Unwägbarkeiten eines "grossen" Betriebssystems fallen komplett weg.

Man muss bei der Programmierung ein bisschen umdenken (nach jedem eintreffenden Sample wird der Algorithmus komplett durchlaufen) - aber gerade für Regelungsaufgaben, wo determinierte Antwortzeiten gefordert werden, ist das Konzept doch viel besser geeignet ...

Ansonsten - die "Jitter-Optimierung" für "klassische" Rechner interessiert mich auch, lese gespannt mit.

 

[badb100d]

Weil das ganze in einem Wissenschaftlichen Kontext läuft. Das heißt: ständig wechselnde Themengebiete, häufig wechselnde Hardware, Häufig wechselnde Bediener mit wenig Know How im Bereich Informatik. Wenn an so einem System ein Team sitzt was das System kennt kann ich all die schönen Fragen da oben immer beantworten, den Code passend optimieren oder spezialisierete Hardware einsetzen. Leider bin ich aber in der Situation, dass Ich das System so am laufen halten muss, das Morgen ein neuer Student der Regelungstechik daherkommen kann und in 3 Monaten seine Wissenschaftliche Arbeit da zustande bringt.
Der will/kann sich einfach nicht mit der Gesamtkomplexität des Systems beschäftigen.

Daher wird das ganze so aufgebaut, dass es für den Bediener möglichst einfach ist und das heißt im Zweifellsfall: er kann seine Ideen einfach in Matlab Simulink reinklopfen und dann läuft das mit ein paar Klicks in seiner bunten Software auf der Hardware. Wenn dann 3 Takte Versatz zwischen seinen Kommandodaten und der zurückkommenden Telemetrie sind dann steht der bei mir in der Tür und weiß nicht weiter.

Und aktuell stehe ich halt leider an dem Punkt, dass die Leistung dafür nicht mehr reicht und handlungsbedarf besteht.

Ergänzung (15. Juni 2024)

Auf jeden fall schon mal vielen Dank für eurer Feedback dazu dazu. Ich glaube das hilft mir schon meine Gedanken ein wenig zu sortiren.

 

[Piktogramm]

@badb100d
Also Anforderungen beschreiben solltest du echt nochmal üben[1]! Nach ganzen fünf Beiträgen kommst du um die Ecke und schreibst, dass Matlab zum Einsatz kommt -.-
Bei Matlab gibt es die Möglichkeit verschiedene Bibliotheken für die Mathematik (Math Kernel in Englisch) einzubinden. Typisch ist, dass IntelMKL (heißt jetzt oneMKL) genutzt wird, wobei IntelMKL prüft, ob es auf einer Intel CPU läuft und nur dann die besten Codepfade nutzt[2]. Wenn die Anwendungen viel auf Signalen rechnen, dann machen die Mathekernel viel aus.

Wenn du aktuell Probleme mit der Performance hast, kann eine neuere Version des verwendeten Mathekernels die Performance verbessern.

Wenn du AMD CPUs testen willst, aber IntelMKL/oneMKL verwendet wird, solltest du auch gegen AMDs AOCL testen und/oder OpenBLAS. Wobei du an der Stelle dann ein System schaffst, welches gut dokumentiert gehört und wo jeder, der dieses System mal übernimmt auch irgendwie verklickert werden muss, dass die Abweichung vorhanden ist!

Jenachdem was ihr für ein Altsystem habt (wieso ist das eigentlich nicht genannt?) und viel Rechnerei notwendig ist, wäre für Aufgaben mit viel Signalverarbeitung über Matlab zu empfehlen aktuelle Prozessoren zu verwenden, die AVX512 können[3] und tendenziell auch Intel AMX[4].
https://en.wikipedia.org/wiki/Sapphire_Rapids
https://en.wikipedia.org/wiki/Granite_Rapids



[1] Wobei in Unis und Hochschulen ist es total normal Anforderungen sehr halbherzig zu schreiben und dann doof zu schauen, wenn sich Studenten innerhalb der Anforderungen etwas anderes denken als der/die Prof. wollte.

[2] Für bestimmte Versionen von IntelMKL gibt es Workarounds, die Intel aber mit neueren Versionen abgestellt hat.

[3]AMDs Zen4 kann auch AVX512, zerlegt die 512bit Vektoren aber in 256bit. Damit sind die Zen4 flott unterwegs, aber halt tendenziell langsamer als jene Intel CPUs, welche auch AVX512 können. Zen5 sollte da einen größeren Sprung machen. Die Frage ist dann nur, wie gut Zen5 mit den erwähnten Mathekerneln wirklich Durchsatz liefert.

[4]Braucht dann aber wieder möglichst die aktuelle Version der oneMKL und wahrscheinlich auch recht frische Versionen von Mathlab. Naja und Recherche, ob Matlab + oneMKL davon wirklich profitiert. (Also ich weiß, dass Intel AMX für digitale Signalverarbeitung und KI gut ist, aber ich kenne nicht jede Software )

 

[Nolag]

Mir ist auch klar, dass mir hier jetzt keiner fundiert sagen kann: "Nimm den 14900k oder den 7965WX und dann geht das auf jeden Fall"

Um einfach mal dieses konkrete Beispiel zu kommentieren. Ich würde weder einen 14900k noch eine AMD CPU mit mehreren CCDs verwenden. Beim Intel dürfte einem die hybride Core Architektur den Jitter verderben und bei den AMD CPUs mit mehreren CCDs ist es die IF. Ich würde bei dieser speziellen Anwendung auch weiterhin auf monolithische Server/Workstation CPUs setzen.

 

[badb100d]

Also Anforderungen beschreiben solltest du echt nochmal üben[1]! Nach ganzen fünf Beiträgen kommst du um die Ecke und schreibst, dass Matlab zum Einsatz kommt -.-

Weil es nicht wichtig ist. Ich habe keinen Einfluss darauf was da letzten Endes ausgeführt wird. Matlab ist auch nur ein Beispiel. Ich sorge nur dafür, dass es in 95% der Fälle keine Probleme gibt und bei 5% der Fälle helfe ich dann mit etwas tuning an den buildflags oder div. Bibliotheken. Ich habe versucht mich auf die nötigsten Informationen zu begrenzen weil ich ja schlecht hier die Dokumentation eines kompletten Systems aus diversen PCs, Microcontrollern, FPGAs, selbst gebauten PCIE Steckkarten, und ..., und, ... und reinkopieren kann.

Ich habe jetzt auch schon mehrfach gesagt, dass es "nur" darum geht ein Herzstück des Systems auszutauschen und eine Auswahl für in Frage kommende CPUs zu finden und dabei will ich mal über den aktuellen Tellerrand der bisher genutzten Xeons schauen.

Den ganzen Rest habe ich schon im Griff, da brauche ich keine Hilfe. Trotzdem noch mal vielen Dank für deine Mühe das alles zusammenzuschrieben.

Um einfach mal dieses konkrete Beispiel zu kommentieren. Ich würde weder einen 14900k noch eine AMD CPU mit mehreren CCDs verwenden. Beim Intel dürfte einem die hybride Core Architektur den Jitter verderben und bei den AMD CPUs mit mehreren CCDs ist es die IF. Ich würde bei dieser speziellen Anwendung auch weiterhin auf monolithische Server/Workstation CPUs setzen.

Ja das fasst es denke ich ganz gut zusammen. Danke

 

[ropf]

Weil es nicht wichtig ist.

Naja, interessant wäre, wenn auch nur beispielhaft:

• die Grundlaufzeit des Algorithmus (in CPU-Zyklen oder Elemenratoperationen wie MultiplyAdds)
• der Overhead der Laufzeitumgebung (Mathematica, Simulink, whatever)
• zusätzliche Lags und besonders deren Varianz (durch Betriebssystem, Treadwechsel, Cachmisses, IOs ...)

Mein Eindruck aus dem Gelesenen (verzeih wenn ich falsch liege) - liegt genau in Punkt 3. Während sich die ersten beiden recht präzise voraussagen lassen, kann man letzteren nur in einer konkreten Umgebung messen (Timer einbauen, loggen, auswerten ...).

Nun steigst du auf leistungsfähigere Hardware um, verringerst damit die mittlere Antwortzeit. Durch eine "bessere" Architektur verringerst zu vielleicht auch deren Varianz. Dadurch werden "Aussreisser" vielleicht seltener, aber keinesfalls ausgeschlossen - und wenn dann in der realen Welt "böse Dinge geschehen", bleibt das Ergebnis immer noch "böse".
--------------------------------------------------

Deshalb - auch wenn es zZt nicht infrage kommt - wäre eine Lösung besser, die das Problem an der Wurzel packt, statt an den Symptomen - gerade für des "Herzstück" der Anlage.

Moderne DSPs haben längst graphische Programmierumgebungen (etwa Sigmastudio für die DSPs von AnalogDevices), wo du das Programm aus den selben Grundelementen und auf dieselbe Weise zusammenklicken kannst, wie in jeder anderen Entwicklungsumgebung auch - ohne eine Zeile Code zu schreiben.

Jedenfalls löst du das Problem des Jitters damit komlett. Und es würde mich sehr wundern, wenn es zB im SimuLink keine Schnittstelle gäbe, um den DSP-Code direkt zu erzeugen, auf den Prozessor zu schieben, live Parameter zu setzen, Zwischenergebnisse zu verfolgen ...

Soweit als Gedanke für den Hinterkopf - was jetzt nicht geht, kann ja noch werden.