Aus der x87 Zeit kommt noch das FSINCOS aber das ist langsamer als die
heutigen Lib-C Implementierungen die auf SSE,AVX basieren, aber es gibt
doch so viele Simulationssysteme bei denen schnelle Trigonometrische
Berechnung sehr bedeutend sind - also warum nicht mehr in-chip?
Meine Ideen,Vermutungen
-die Algorithmen ändern sich zu oft und immer mal wieder gib es einen
kleinen Performanzsprung der man mit einer harten In-Chip
implementierung schwer folgen kann?
-In-Chip ist einfach zu Umfangreich, zu viel Platzverbrauch auf dem Die?
(Die einzelwert double precision glibc avx implementierung ist locker 2
Seite assembler)
-zu viele Varianten nötig: Fixpoint,single,double precission,...?
-Überschätze ich die Gescheindigkeitssteigerung die mit einer In-chip
Lösung möglich wäre?
Das gleiche frage ich mich auch bei Verschlüsselungsalgorithmen
Die SHA extension von Intel ist wirklich ordentlich schneller (z.b.
Faktor 7 bei SHA256 gegenüber Intels eigener AVX2 Implementierung), aber
eben nicht für alle CPUs verfügbar
Was lässt dich vermuten, dass Hardware oder Microcode schneller sei, als
eine optimierte Folge von Grundbefehlen?
Voraussetzung wäre ein Algorithmus, der spezielle Operationen benötigt,
die nicht als Einzeloperationen zur Verfügung stehen. Im Crypto-Bereich
ist das der Fall.
Ein Projekt von mir ist eine Kinematik wo ich sincos für mehrere
Rundachsen berechnen muss und in Performanztest mit
VTune,prof,Cachegrind sieht man deutlich das sincos teilweise 60% oder
mehr der Zeit braucht
in einem anderen Projekt rede ich mit vielen kleinen Hardwaredevices die
geSHA256te pakete ueber TCP/IP wollen und da ist der Einfluss der reinen
Verschlüsselung auch sehr deutlich, mit der Intel-Extension konnte ich
da den Durchsatz ordentlich steigern
> Was lässt dich vermuten, dass Hardware oder Microcode schneller> sei, als eine optimierte Folge von Grundbefehlen?
Weil man mit hart verdrahteter Logik mehr Arbeit pro Takt machen kann
als wenn man einzelne Opcodes mit Prefetching usw. durchtakten muss?
> Voraussetzung wäre ein Algorithmus, der spezielle Operationen benötigt,> die nicht als Einzeloperationen zur Verfügung stehen. Im Crypto-Bereich> ist das der Fall.
Den SHA256 gibt es als AVX2 basierte Implementierung die einen plain C
Algorithmus schlägt, der SHA256 aus den Intel Extension Opcodes ist aber
trotzdem deutlich schneller, der sincos wird ähnlich komplex berechnet,
was ist da genau der Unterschied?
Die Auswahl von CPU-Fähigkeiten ist immer ein Kompromiss. Wenn man einen
Sin/Cos-Beschleuniger implementiert bleibt weniger Platz- und
Energie-Budget für andere Funktionen. Wahrscheinlich ist die Überlegung
dass man im Durchschnitt mit schnellem Sin/Cos weniger Performance
gewinnt als z.B. mit mehr Cache oder besserer Branch Prediction. Wenn
man alle erdenklichen Funktionen einbaut kommt ein realitätsfernes
Monstrum heraus...
cppbert3 schrieb:> Weil man mit hart verdrahteter Logik mehr Arbeit pro Takt machen kann> als wenn man einzelne Opcodes mit Prefetching usw. durchtakten muss?
Möglicherweise könnte man eine spezialisierte Trigonometrie-Engine
bauen, die schneller ist als ein Programm. Aber Microcode macht ein
Programm zwar kürzer, jedoch nicht schneller, denn die Operationen sind
ohne spezialisierte Hardware die gleichen.
Instruction-Fetch/Decode spielen bei häufig ausgeführtem Code - und um
den geht es hier - keine Rolle mehr. Die aktuellen x86 oberhalb der
Atoms besitzen einen Cache für dekodierte Befehle, und RISCs wie Apples
M1 brauchen das sowie nicht.
(prx) A. K. schrieb:> Aber Microcode macht ein Programm zwar kürzer, jedoch nicht schneller,> denn die Operationen sind ohne spezialisierte Hardware die gleichen.
Ich meinte mit In-Chip eine Hardwarelösung, die müsste dann aber doch
schon schneller sein, oder?
cppbert3 schrieb:> Ich meinte mit In-Chip eine Hardwarelösung, die müsste dann aber doch> schon schneller sein, oder?
Keine Ahnung, inwieweit sich per spezialisierter Trigonometrie-Engine
wieviel einsparen lässt. Wenn dich das wirklich interessiert, dann such
mal im FPGA-Bereich, ob es das gibt und wieviel das bringt. Damit kann
man nämlich ausprobieren.
Das Kernproblem wurde schon angesprochen: Universal-CPUs sind zunächst
Generalisten statt Spezialisten, die alles irgendwie lösen können, aber
nichts perfekt. Befehlssätze sind daraus ausgerichtet, viele sehr
verschiedene Probleme halbwegs performant auszuführen. Nicht aber, für
100 Probleme 100 nur darauf spezialisierte Recheneinheiten
zusammenzukleben, die beim 101sten versagen.
Mittlerweile kommen zwar immer mehr spezielle Units hinzu, wie eben die
zu Crypto, aber das macht man bei nicht-trivialem Aufwand nur, wenn der
Vorteil sehr gross oder der Druck sehr hoch ist. Für Faktor 10 mag es
lohnen, für 20% investiert man die Die-Fläche lieber woanders.
cppbert3 schrieb:> Ganz gute Erklärung, Danke>> Gibt es sin/cos Beschleuniger, so als ASIC?
Spontan muss ich da an Audio DSPs denken. Die kommen als USB Geräte oder
PCI Karte daher und übernehmen einige Filter-Berechnungen. Dadurch kann
man dann auch große Projekte mit vielen Spuren & vielen Plugins noch
flüssig bearbeiten.
Ich denke das wäre auch für eine Maschinensteuerung denkbar. Eine "DSP"
Box die sich um die Geometrie kümmert... In die Richtung ging das doch
schon mit den Mesa Karten & Smoothstepper. Da wurde die Takt/Richtung
Signal Erzeugung in Hardware ausgelagert damit die Achsen flüssig
laufen.
cppbert3 schrieb:> Ein Projekt von mir ist eine Kinematik wo ich sincos> für mehrere Rundachsen berechnen muss
Naja, Zahlen wären schon hilfreich: Wie genau brauchst
Du das, und über welches Intervall an Argumenten?
> und in Performanztest mit VTune,prof,Cachegrind sieht> man deutlich das sincos teilweise 60% oder mehr der> Zeit braucht
Naja, was heißt das? 3 Takte je sin/cos? 30? 300?
Per Software wirst Du es kaum schaffen, einen genäherten
Sinus in unter 10 Takten zu berechnen.
Andre schrieb:> cppbert3 schrieb:> Ich denke das wäre auch für eine Maschinensteuerung denkbar. Eine "DSP"> Box die sich um die Geometrie kümmert... In die Richtung ging das doch> schon mit den Mesa Karten & Smoothstepper. Da wurde die Takt/Richtung> Signal Erzeugung in Hardware ausgelagert damit die Achsen flüssig> laufen.
Nicht zufällig haben die STM32G4 und STM32H2xx/H3xx einen CORDIC
co-processor. Der liefert zwar nur 24 Bit genaue Werte (und
Festkommaformat), für eine Maschinensteuerung reicht das jedoch in aller
Regel.
Aber für jede extra Hardware stellt sich die Frage: Brauchen das viele
Anwender aus meiner Zielgruppe? Wenn nein, ist das totes Silizium, das
aber trotzdem kostet. Und umgekehrt: Wieviel Markanteil verliere ich,
wenn ich das nicht anbieten kann, die Konkurrenz aber schon?
cppbert3 schrieb:> aber es gibt> doch so viele Simulationssysteme bei denen schnelle Trigonometrische> Berechnung sehr bedeutend sind
Wirklich? Mir fällt jetzt irgendwie keine Anwendung ein wo der
sincos-Durchsatz limitierend wäre. Spezielle Embeddedsysteme mit wenig
Rechenleistung, da könnte ich es mir vorstellen. Aber sonst?
Andreas schrieb:> cppbert3 schrieb:> aber es gibt> doch so viele Simulationssysteme bei denen schnelle Trigonometrische> Berechnung sehr bedeutend sind>> Wirklich? Mir fällt jetzt irgendwie keine Anwendung ein wo der> sincos-Durchsatz limitierend wäre. Spezielle Embeddedsysteme mit wenig> Rechenleistung, da könnte ich es mir vorstellen. Aber sonst?
Seversoftware die Kinematik basierte Material Abtragssimulation für
hunderte von Clients berechnet - Millionen von Achswerten - da merkt man
sin/cos z.b. bei mir ordentlich, neben anderen Dingen, mind 6
Nachkommastellen sind relevant
(prx) A. K. schrieb:> Was lässt dich vermuten, dass Hardware oder Microcode schneller sei, als> eine optimierte Folge von Grundbefehlen?
Weils doch schon früher(tm) so war ;)
Intel 80387 Programmer's Reference Manual,
Chapter 4.6
"Transcendental Instructions"
Oliver
Oliver S. schrieb:> Weils doch schon früher(tm) so war ;)
... aber heute nicht mehr so ist. Das war vor 40 Jahren.
Heutiger Microcode ist über den Daumen gepeilt eine Abfolge jener Sorte
interner Befehle, wie sie im decoded instruction cache stehen und aus
den normalen Befehlen gebildet werden. Da ist nichts Magisches dran.
Es wird vmtl sogar darauf rauslaufen, dass die Nutzung internen
komplexen Microcodes auf die Gesamtlaufzeit gerechnet langsamer ist.
Beispielsweise durch sequentielle Abhängigkeiten von Operationen, deren
Latenzen in längerem Microcode nicht von unabhängigen Operationen
genutzt werden können. So kann anwendungsoptimierter Code Unrolling
nutzen, um Operationen zu interleaven und damit die Latenzen zu füllen.
Microcode kann das nicht.
(prx) A. K. schrieb:> Oliver S. schrieb:>> Weils doch schon früher(tm) so war ;)>> ... aber heute nicht mehr so ist. Das war vor 40 Jahren.>> Heutiger Microcode ist ...
Der Microcode in deinem Inroniedetektor braucht allerdings mal ein
Update ;)
Oliver
Oliver S. schrieb:> Der Microcode in deinem Inroniedetektor braucht allerdings mal ein> Update ;)
Der nutzt RISC und ist nicht von IBM, hat also keinen Microcode. ;-)
Das war allerdings inhaltlich auch eher eine Antwort auf die
Originalfrage, als auf dich.
Mark B. schrieb:> cppbert3 schrieb:>> Und beim SHA256 rede ich teilweise mit 200 oder mehr Geräten>> Wozu braucht man da einen Sinus?
das war nur mein SHA256 Anwendungsfall - das Gerät möchte alle Pakete
(send und receive) werden damit "verschlüsselt" - ich denke zur
Absicherung oder Injektion attack (nennt man das so?) Erschwerung
cppbert3 schrieb:> das war nur mein SHA256 Anwendungsfall
Und grade bei SHA256 gab es da einen sehr sehr starken
Optimierungsdruck...
Zuerst wurde es auf die Grafikkarte ausgelagert, als die CPUs dafür zu
langsam waren, dann auf FPGAs, und schließlich in eigene ASICs die
inzwischen ganze Rechenzentren füllen...
Denselben Weg kann der TE ja für seinen Sinus gehen, und dann 50
Terra-Sinusse/Sekunde aus dem Miner ziehen...
Leider finde ich keine Infos zu SinCos und SHA256 support in Apples
"Monster" M1 Chip, so wie ich das gelesen haben sind da sogar 8 bis 16GB
RAM direkt im Chip integriert und z.b. auch ein DSP, aber ich finde kaum
Details
https://erik-engheim.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2
So wie die mit integrierter Funktionalität um sich geschlagen haben
müsste da doch auch ein SHA265 und SinCos zu finden sein
cppbert3 schrieb:> mind 6 Nachkommastellen sind relevant
Okay, das ist die Antwort auf die eine Frage.
Die andere Frage ist aber noch offen: Wieviel Takte
braucht die Kiste im Moment für einen Sinus bzw.
Cosinus?
Wenn das 3..5...8 Takte sind, hast Du m.E. mit einer
Softwarelösung keine Chance, schneller zu werden.
Wenn das 30 oder 70 Takte sind, sieht das schon anders
aus.
Egon D. schrieb:> cppbert3 schrieb:> mind 6 Nachkommastellen sind relevant>> Okay, das ist die Antwort auf die eine Frage.>> Die andere Frage ist aber noch offen: Wieviel Takte braucht die Kiste im> Moment für einen Sinus bzw. Cosinus?> Wenn das 3..5...8 Takte sind, hast Du m.E. mit einer Softwarelösung> keine Chance, schneller zu werden. Wenn das 30 oder 70 Takte sind, sieht> das schon anders aus.
Ich habe bisher nur die Zeiten von aktuellen VS2017,VS2019 clibs, glibcs
nebst aktuelle clang,gcc 10+ und Intel unter Linux,Windows angeschaut,
und die Intel IPP, kann ich die Takte irgendwo im Vtune sehen oder muss
ich die im Assemblercode abzählen?
Egon D. schrieb:>> mind 6 Nachkommastellen sind relevant>> Okay, das ist die Antwort auf die eine Frage.
Nur 6 Stellen? Damit geht der ganze Sinus in eine Lookup-Table, die mehr
oder weniger komplett im L3-Cache einer aktuellen CPU Platz findet.
Opfer halt mal je nach gewünschter Genauigkeit ein paar MB Ram für eine
Tabelle und jag' das dann durch den Profiler.
Εrnst B. schrieb:> Nur 6 Stellen? Damit geht der ganze Sinus in eine Lookup-Table, die mehr> oder weniger komplett im L3-Cache einer aktuellen CPU Platz findet.
Allerdings kostet ein Zugriff auf den L3-Cache auch ein paar Dutzend
Taktzyklen.
Εrnst B. schrieb:> Egon D. schrieb:> mind 6 Nachkommastellen sind relevant>> Okay, das ist die Antwort auf die eine Frage.>> Nur 6 Stellen? Damit geht der ganze Sinus in eine Lookup-Table, die mehr> oder weniger komplett im L3-Cache einer aktuellen CPU Platz findet.>> Opfer halt mal je nach gewünschter Genauigkeit ein paar MB Ram für eine> Tabelle und jag' das dann durch den Profiler.
6 stellen nach dem komma, ich dachte zugriffe auf solche grossen
tabellen sind ein totaler cache killer?
cppbert3 schrieb:> Εrnst B. schrieb:> Egon D. schrieb:> mind 6 Nachkommastellen sind relevant> Okay, das ist die Antwort auf die eine Frage.> Nur 6 Stellen? Damit geht der ganze Sinus in eine Lookup-Table, die mehr> oder weniger komplett im L3-Cache einer aktuellen CPU Platz findet.> Opfer halt mal je nach gewünschter Genauigkeit ein paar MB Ram für eine> Tabelle und jag' das dann durch den Profiler.>> 6 stellen nach dem komma, ich dachte zugriffe auf solche grossen> tabellen sind ein totaler cache killer?
Ich brauche ja nicht nur permanent sincos
Sorry, meine Berechnungen müssen am Ende mind. 6 "genaue"
Nachkommastellen aufweisen, bin mir nicht sicher welche Präzision mein
Sinus dann braucht, aber ist nur ein bisschen plus,minus,mal was da noch
so drum ist
cppbert3 schrieb:> Sorry, meine Berechnungen müssen am Ende mind. 6 "genaue"> Nachkommastellen aufweisen, bin mir nicht sicher welche Präzision mein> Sinus dann braucht, aber ist nur ein bisschen plus,minus,mal was da noch> so drum ist
Und es werden natürlich Rundachsen miteinander verrechnet, dadurch
steigt Fehler in den Nachkommastellen weiter
Nils schrieb:> Eine kleine Tabelle (512 Entries) und Circular Interpolation> sollte gut> genug sein. Das ist auch kein L3 Cache Killer.>> https://namoseley.wordpress.com/2015/07/26/sincos-generation-using-table-lookup-and-iterpolation/
ich werde es mir mal anschauen - aber glaube nicht das ich damit für
eine Simulation bei der Präzision primär wichtig ist (und dann sofort
danach
Geschwindigkeit) auf einen grünen Zweig komme - aber wer weiss...
cppbert3 schrieb:> Simulation bei der Präzision primär wichtig
Was denn nun? Reichen 6 Stellen oder nicht?
Vielleicht solltest Du erstmal mit einem geeigneten Tool (z.B. matlab)
rauskriegen, was du bei deiner Rechnung überhaupt benötigst.
Bei manchen Rechnungen reicht die Präzision von float32 nicht aus, bei
wieder anderen sind 4 Bit völlig ausreichend...
Bernd schrieb:> cppbert3 schrieb:>> Simulation bei der Präzision primär wichtig> Was denn nun? Reichen 6 Stellen oder nicht?> Vielleicht solltest Du erstmal mit einem geeigneten Tool (z.B. matlab)> rauskriegen, was du bei deiner Rechnung überhaupt benötigst.>> Bei manchen Rechnungen reicht die Präzision von float32 nicht aus, bei> wieder anderen sind 4 Bit völlig ausreichend...
bisher brauche ich double-Precision sonst sind die Ergebnisse nicht gut,
die Simulation geht bis auf 10-5 µ runter - es werden damit
Feinst-Metall-Bearbeitungen (und die resultierende Oberflächenstruktur)
simuliert
für die echte Maschine brauche ich mind. 6 Signifikante Stellen nach dem
Komma für die Achsbewegung - d.h. nach Durchnudelung der
5-Achs-Kinematik und Simulation des Abtrags
(X(lin),Y(lin),C(rund),A(rund),B(rund))
cppbert3 schrieb:> Seversoftware die Kinematik basierte Material Abtragssimulation für> hunderte von Clients berechnet - Millionen von Achswerten - da merkt man> sin/cos z.b. bei mir ordentlich,
Sieht aus als wäre der Server, vorsichtig formuliert, nicht ganz optimal
gewählt worden. Aber egal, da ha(tte)st Du vermutlich keinen Einfluss
drauf.
> mind 6 Nachkommastellen sind relevant
Die Hardware hat aber doch garantiert eine float (IEEE single) FPU, und
das würde von der Genauigkeit hinkommen. Also in etwa
1
#include<math.h>
2
...
3
doublex;
4
doublesin_x=(double)sinf((float)x);
wobei man die expliziten Casts nicht wirklich braucht.
> Die einzelwert double precision glibc avx implementierung ist locker> 2 Seite assembler
Das kann viel sein oder wenig...
Falls aufgrund Genauigkeit float keine Option ist, kann man
unterschiedliche Dinge versuchen:
* GCC kennt __builtin_sincos. Falls sincos schneller ist als sin+cos
bringt das vielleicht schon eine Beschleunigung — falls sich jemand die
Mühe gemacht hat, das zu implementieren. Lohnen tut sich das ja nur,
wenn sin und cos genügend Gemeinsamkeiten haben, die es
rauszufaktorisieren lohnt, was davon abhängt wie welche
Funktionalgleichungen umgesetzt wurden (z.B. Argumentreduktion).
* Man könnte versuchen, die glibc Algorithmen nachzuvollziehen und zu
beschleunigen, z.B. indem nur auf eine kleinere Genauigkeit genähert
wird wie Du sie brauchst.
* Algorithmen entrümpeln von Sonderfällen wie Inf, Nan, -0, etc. Bringt
vermutlich nicht viel, ist dafür aber einfach umzusetzen wenn man 'nen
vollständigen Algorithmus hat.
* Evtl. Optionen wie
-ffast-math
-ffinit-math-only
-fno-signed-zeros
-fno-trapping-math
etc (GCC). Dies sind keine Multilib-Optionen, sie wirken also nicht auf
Code, der aus der glibc gelinkt wird, sondern nur auf genuin vom
Compiler erzeugten Code. Und Voraussetzung ist natürlich, dass man auf
die Features verzichten kann / will.
Johann L. schrieb:> * GCC kennt __builtin_sincos
Gerade mal folgenden Code compiliert
1
voidd_sincos(doublex,double*sin_x,double*cos_x)
2
{
3
__builtin_sincos(x,sin_x,cos_x);
4
}
Mit gcc v4.7 -O2 -ffast-math auf nem steinalten Werkstatt-Laptop
(Pentium 5 ohne SSE2) bekomm ich[*]:
1
_d_sincos:
2
fldl 4(%esp)
3
fsincos
4
fxch %st(1)
5
movl 12(%esp), %eax
6
fstpl (%eax)
7
movl 16(%esp), %eax
8
fstpl (%eax)
9
ret
Wenn das auf
> Server[...] die Kinematik basierte Material Abtragssimulation> für hunderte von Clients berechnet
nicht unterstützt wird, ist irgendwas bei der Systemauswahl sehr falsch
gelaufen.
[*] Allerdings braucht's dazu -ffast-math, das noch einiges an anderen
Flags triggert. Keine Ahnung warum das gebraucht wird, ziemlich sicher
weil die FPU-Instruktionen nicht 100% IEEE-konform sind. Ohne
-ffast-math gibt's nen Linkerfehler gegen _sincos, was soviel bedeutet
wie "exercise left to the reader".
Johann L. schrieb:> fsincos
ist sehr langsam - und wird von den libc sse/avx Implementierungen
umgangen - deswegen ja meine initiale Fragen warum solche Opcodes nicht
mehr verbessert/integriert werden
Johann L. schrieb:> Sieht aus als wäre der Server, vorsichtig formuliert, nicht ganz optimal> gewählt worden. Aber egal, da ha(tte)st Du vermutlich keinen Einfluss> drauf.
keine Ahnung was du meinst, was wäre denn ein "optimalerer Server" -
falls ich doch Einfluss hätte :)
(prx) A. K. schrieb:> Die aktuellen x86 oberhalb der> Atoms besitzen einen Cache für dekodierte Befehle, und RISCs wie Apples> M1 brauchen das sowie nicht.
Und warum hat ein Cortex-A77 so etwas?
cppbert3 schrieb:> Johann L. schrieb:>> Sieht aus als wäre der Server, vorsichtig formuliert, nicht ganz optimal>> gewählt worden. Aber egal, da ha(tte)st Du vermutlich keinen Einfluss>> drauf.>> keine Ahnung was du meinst, was wäre denn ein "optimalerer Server" -> falls ich doch Einfluss hätte :)
mein Test-Server hat diese 28 Kerne CPU:
https://www.mindfactory.de/product_info.php/Intel-Xeon-Scalable-8280-2-7Ghz-38-5M-Cache-FC-LGA3647-Tray-CPU_1318448.html
und es ist auch nicht so das die Gesamtbelastung mit Client das Problem
ist
das kann ich ja mit mehreren Servern/CPUs abfedern, aber die Single-Core
Performanz zu erhöhen wäre schon fein :)
cppbert3 schrieb:> aber die Single-Core Performanz zu erhöhen wäre schon fein :)
Ich glaube fast da liegt deine Denkfehler. Sinnvoller wäre es eher ein
Algo zu finden der maximal Parallelisiert werden kann so dass alle zur
Verfügung stehenden Core auch genutzt werden. Bei deinem System sind das
ja bis zu 8 x 28 x 2 = 488 threads. Die gleichmäßig auszulasten ist
schon eine sehr sportliche Aufgabe. Wenn es aber klapp ist das schon
einiges an Rechenleistung. Zur Not dazu noch zwei Xeon Phi oder Tesla
Karten pro CPU - das wäre dann aber schon sehr heftige Parallelisierung.
Das mit der separaten Hardware für sin/cos scheint seit den 387er und
den ganzen bis heute dazu kompatible Nachbauten eher selten vorzukommen.
Nvidia hatte bei den Fermi Coprozessoren mal sowas eingebaut.
Ich konnte aber nichts darüber finden ob das bei den nachfolge Modellen
noch vorhanden ist oder ob das wieder verschwunden ist.
https://www.nvidia.com/content/pdf/fermi_white_papers/nvidia_fermi_compute_architecture_whitepaper.pdf
Seite 9:
Four Special Function Units Special Function Units (SFUs) execute
transcendental instructions such as sin, cosine, reciprocal, and square
root. Each SFU executes one instruction per thread, per clock; a warp
executes over eight clocks. The SFU pipeline is decoupled from the
dispatch unit, allowing the dispatch unit to issue to other execution
units while the SFU is occupied.
https://de.wikipedia.org/wiki/Nvidia_Tesla
Irgend W. schrieb:> Ich glaube fast da liegt deine Denkfehler. Sinnvoller wäre es eher ein> Algo zu finden der maximal Parallelisiert werden kann so dass alle zur> Verfügung stehenden Core auch genutzt werden. Bei deinem System sind das> ja bis zu 8 x 28 x 2 = 488 threads.
1. Wie kommst du auf 8x ? Ich hab hier nur 2 CPUs
2. Ich skaliere voll auf alle verfügbaren "echten" 56 threads per CPU
für multiple Clients, das ist unproblematisch d.h. Verteilung ist
effizient und hält die Threads schön beschäftigt, geht natürlich auch
mit noch mehr oder weniger Threads
3. Im Kern gibt es leider eine Stelle an der man nur iterativ mit
leichter Einschränkbarkeit zum Ergebnis kommt, da beissen sich schon ein
paar - natürlich nicht so gute :) - Mathematiker die Zähne dran aus es
algorithmisch noch stärker zu vereinfachen
4. Sollte ich den Schritt Richtung Azure, AWS Cloud, Cluster usw. machen
ist CPU Zeit auch ganz schnell ein Kostenfaktor der sehr relevant wird
Aber ich wollte eh nur wissen warum solche Extension nicht mehr
weierentwickelt werden oder nur noch in Spezialbereichen Einsatz finden
Das hat ein Grossteil aller beteiligten gut und treffend beschrieben,
Danke!
hier im Detail den ganzen Entwicklungsbackground für das Projekt
auszuprägen macht hier wohl nicht viel sinn weil:
10% keinen Sinn in solchen Softwareanforderungen sehen
10% noch niemals an irgendwelche Grenzen gestossen sind und gar keine
Ahnung haben wie man so was überhaupt löst
10% kommen mir mit fsincos :)
10% gehen per se davon aus das der Code wohl einfach nur ineffizent ist
10% das man wohl nicht gut skaliert, keine Threads oder Prozesse nutzt
10% das alles irgendwie auf Microcontrollern läuft
10% das eine trivial lösung das ganze Thema einfach abdeckt
10% das man sich eben für Performanz ODER Präzision entscheiden muss
10% das die Hardware einfach nicht genug Leistung hat
10% Grafikkarte das spielend berechnen
...
cppbert3 schrieb:> 3. Im Kern gibt es leider eine Stelle an der man nur iterativ mit> leichter Einschränkbarkeit zum Ergebnis kommt, da beissen sich schon ein> paar - natürlich nicht so gute :) - Mathematiker die Zähne dran aus es> algorithmisch noch stärker zu vereinfachen
im übrigen auch der der Teil wo SinCos fuer zwei verschiedene Winkel
sehr sehr häufig berechnet werden muss - aber auch nur die 2
meine Versuche mit Vektor Versionen die z.B. SinCos für 4 Winkel
"gleichzeitig" berechnen sind leider langsamer als nur die 2 zu
berechnen die ich brauche, auch MKL,IPP usw sind langsamer
muss wohl doch darauf hoffen das die Mathematiker da noch einen Trick
finden oder in den sauren Apfel beißen und was eigenes entwickeln - das
ich dann leider dauerhaft pflegen muss (und prüfen ob nicht die
Std-C-Lib Version über die Zeit nicht doch plötzlich schneller sind...)
cppbert3 schrieb:> Weil man mit hart verdrahteter Logik mehr Arbeit pro Takt machen kann> als wenn man einzelne Opcodes mit Prefetching usw. durchtakten muss?
Deshalb wird sich RISC auch nie durchsetzen....
cppbert3 schrieb:> 1. Wie kommst du auf 8x ? Ich hab hier nur 2 CPUs
Weil der 8280 für bis zu 8 Sockel Systeme gedacht ist und in freier
Wildbahn eher selten als Single Prozessor vorkommt.
Aber zwei von denen ist schon einiges an Rechenleistung. Wenn es mit
denen schon "zu langsam" ist hilft ein "Erschlagen des Problems rein mit
Hardware" meist eh nichts.
> 2. Ich skaliere voll auf alle verfügbaren "echten" 56 threads per CPU> für multiple Clients, das ist unproblematisch d.h. Verteilung ist> effizient und hält die Threads schön beschäftigt, geht natürlich auch> mit noch mehr oder weniger Threads
Das ging aus deinen vorherigen Antworten nicht so wirklich hervor (und
in einem Forum wo für viele alles über 8 Bit Voodoo ist geht man auch
nicht gerade davon aus dass das ganze wohl schon sehr professionell
aufgearbeitet ist).
> 3. Im Kern gibt es leider eine Stelle an der man nur iterativ mit> leichter Einschränkbarkeit zum Ergebnis kommt, da beissen sich schon ein> paar - natürlich nicht so gute :) - Mathematiker die Zähne dran aus es> algorithmisch noch stärker zu vereinfachen
Solche Probleme gibt es leider öfters als mancher "Manager" denkt. Ich
habe es zwar eher mit größeren Datenmengen zu tun die in definierter
Zeit durch ähnliche Hardware verarbeitet werden müssen und eher nicht
mit Trigonometrie. Aber man kommt einfach immer wieder mal an Stellen wo
man weder vereinfachen noch vernünftig parallelisieren kann usw. Da kann
eine neue/andere Idee zur Verarbeitung(schritte) der Daten schonmal ein
Vielfaches bringen gegenüber den paar Prozent die man als Programmierer
so rausholen kann.
> 4. Sollte ich den Schritt Richtung Azure, AWS Cloud, Cluster usw. machen> ist CPU Zeit auch ganz schnell ein Kostenfaktor der sehr relevant wird
Jo, je nach benötigter CPU-Zeit geht das ganz schnell ins Geld und
eigene Server in ein RZ zu stellen kann durchaus billiger sein. Vor
allem wenn das ganze längerfristig genutzt werden soll. Dazu kommt noch
das die Anwendung auch erstmal gut auf mehreren verteilten Rechnern
skalieren muss. Wenn die Einzelteile kräftig Daten untereinander
austauschen müssen kann das ganz schnell mal nach hinten losgehen wenn
da plötzlich (weil irgendeine VM in eine anderes Segment oder gar
Standort verlagert wurde oder so) größere Latenzen ins spiele kommen
oder man die Bandbreite abgedreht bekommt (ich von unserem RZ schon
einige Gelbe Karten bekommen wegen zu viel Traffic der die anderen
Anwendungen beeinträchtigt:-).
> 10% das man sich eben für Performanz ODER Präzision entscheiden muss
Manchmal kommt man einfach nicht drum herum einen vernünftigen
Kompromiss dazwischen finden zu müssen. Aber nicht entweder oder, das
mach selten sinn.
> 10% das die Hardware einfach nicht genug Leistung hat
Hardware hat nie genug (bezahlbare)Leistung:-)
> 10% Grafikkarte das spielend berechnen
Ich meinte keine Grafikkarte, sondern eine ganz bestimmte
Nvidia-Beschleunigerkarte die eben Sin/Cos in Hardware hatten.
Wenn bei euch ein Forschungsprojekt/Uni/Große Firma oder so hinten dran
steht würde ich glatt mal direkt bei Intel, AMD und Nvidia anfragen ob
die eine Idee dazu haben. Wenn die dass Projekt interessant finden,
können die durchaus sehr hilfreich sein.
cppbert3 schrieb:> meine Versuche mit Vektor Versionen die z.B. SinCos für 4 Winkel> "gleichzeitig" berechnen sind leider langsamer als nur die 2 zu> berechnen die ich brauche, auch MKL,IPP usw sind langsamer
Ich vermute mal durch die hier beschrieben Varianten (und die ganze dort
angegebene Links) hast du dich schon durchgearbeitet:
https://stackoverflow.com/questions/2683588/what-is-the-fastest-way-to-compute-sin-and-cos-together
Daher eher als kleiner Wink eher mal dort nachfragen als hier bei der µC
Fraktion:-)
Irgend W. schrieb:>> 3. Im Kern gibt es leider eine Stelle an der man nur iterativ mit>> leichter Einschränkbarkeit zum Ergebnis kommt, da beissen sich schon ein>> paar - natürlich nicht so gute :) - Mathematiker die Zähne dran aus es>> algorithmisch noch stärker zu vereinfachen> Solche Probleme gibt es leider öfters als mancher "Manager" denkt. Ich> habe es zwar eher mit größeren Datenmengen zu tun die in definierter> Zeit durch ähnliche Hardware verarbeitet werden müssen und eher nicht> mit Trigonometrie. Aber man kommt einfach immer wieder mal an Stellen wo> man weder vereinfachen noch vernünftig parallelisieren kann usw. Da kann> eine neue/andere Idee zur Verarbeitung(schritte) der Daten schonmal ein> Vielfaches bringen gegenüber den paar Prozent die man als Programmierer> so rausholen kann.
das ist auch noch die Hoffung - wenn man das Iterative weg bekommt kann
man eher Sprünge in der Performanz machen
Irgend W. schrieb:>> 10% Grafikkarte das spielend berechnen> Ich meinte keine Grafikkarte, sondern eine ganz bestimmte> Nvidia-Beschleunigerkarte die eben Sin/Cos in Hardware hatten.
das hatte ich auch so verstanden - blöd ist nur das der Iterative
Algorithmus auf eine Grafikkarte auch nicht so toll laufen wird - nur
eben könnten die Einzeloperationen eine Mücke schneller sein - aber man
auch wieder den Datentransfer/Latenz usw.
Irgend W. schrieb:>> meine Versuche mit Vektor Versionen die z.B. SinCos für 4 Winkel>> "gleichzeitig" berechnen sind leider langsamer als nur die 2 zu>> berechnen die ich brauche, auch MKL,IPP usw sind langsamer> Ich vermute mal durch die hier beschrieben Varianten (und die ganze dort> angegebene Links) hast du dich schon durchgearbeitet:> https://stackoverflow.com/questions/2683588/what-is-the-fastest-way-to-compute-sin-and-cos-together> Daher eher als kleiner Wink eher mal dort nachfragen als hier bei der µC> Fraktion:-)
Es wurde noch nicht alles ausgelotet - aber kleine Versuche mit
Tabellen-Lösungen sind zu ungenau und dann ist es schneller aber das
Ergebnis nicht mehr brauchbar
cppbert3 schrieb:> das hatte ich auch so verstanden - blöd ist nur das der Iterative> Algorithmus auf eine Grafikkarte auch nicht so toll laufen wird - nur> eben könnten die Einzeloperationen eine Mücke schneller sein - aber man> auch wieder den Datentransfer/Latenz usw.
was bringt dich zu dieser Aussage? Iterationen sind kein Problem, vor
allem, wenn man die Anzahl der Iterationen einfach auf einen festen Wert
setzen kann. Wenn du nix anderes auf der GPU machst, hast du auch einige
GB Platz für ne lookup-Tabelle und brauchst nicht itereieren ;-).
Allerdings ist der Overhead zum kopieren der Daten und starten des
Kernels sehr hoch für so wenig Rechenaufwand.
mh schrieb:> Wenn du nix anderes auf der GPU machst, hast du auch einige> GB Platz für ne lookup-Tabelle und brauchst nicht itereieren ;-).
Bei einem solchen Projekt gilt das doch genauso für den Rechner ohne
Grafikkarte. Daran sollte es doch nun wirklich nicht scheitern.
Oliver
mh schrieb:> cppbert3 schrieb:>> das hatte ich auch so verstanden - blöd ist nur das der Iterative>> Algorithmus auf eine Grafikkarte auch nicht so toll laufen wird - nur>> eben könnten die Einzeloperationen eine Mücke schneller sein - aber man>> auch wieder den Datentransfer/Latenz usw.> was bringt dich zu dieser Aussage?
weil ich den Algorithmus kenne :)
> Iterationen sind kein Problem, vor> allem, wenn man die Anzahl der Iterationen einfach auf einen festen Wert> setzen kann.
da ist nichts fest - um SinCos sind ein Haufen Schleifen und Bedingungen
> Wenn du nix anderes auf der GPU machst, hast du auch einige> GB Platz für ne lookup-Tabelle und brauchst nicht itereieren ;-).
wenn, dann mache ich noch viele andere Clients (komplett andere Daten)
auch auf der GPU, und ich iterieren nicht auf einem festen Bereich
- der Algorithmus ist viel viel komplizierter
> Allerdings ist der Overhead zum kopieren der Daten und starten des> Kernels sehr hoch für so wenig Rechenaufwand.
und das verursacht das ich die ganzen Daten in der GPU brauche - und
damit auch alle Algorithmen welche diese Daten erzeugen und modifizieren
cppbert3 schrieb:> und das verursacht das ich die ganzen Daten in der GPU brauche - und> damit auch alle Algorithmen welche diese Daten erzeugen und modifizieren
ich habe einen Eingangsdatensatz (bis zu paar hunder MB) und mache damit
dann keine homogene Berechnung
sondern die Eingangsdaten werden modifiziert und immer weiter veraendert
und es sind viele Daten (ich muesste ordentlich hunderte MBs zwischen PC
und GPU hin und her schaufeln)
aber ich kann auch nicht einfach so den ganzen Algorithmus - sind schon
ein paar zig-tausend Zeilen auf die GPU, zum mal probieren, portieren
mh schrieb:> cppbert3 schrieb:>> weil ich den Algorithmus kenne :)>> Bis eben, war nur von sin/cos die Rede ...
Initial habe ich nur gefragt warum die CPUs keine Extension wie SinCos
usw. mehr pflegen (FSINCOS ist sehr langsamm) - dann wurde daraus eine
"Wir haben Ideen wie wir dein Problem lösen können" Diskussion
Ich hab schon geschrieben das es ohne komplette und sehr Umfangreiche
Beschreibung der Algorithmen kaum möglich ist mir dazu Tips zu geben -
dafür ist das alles viel zu Umfangreich ~50.000 Zeilen - nur die
Algorithmen, da ist alles drin von dem man irgendwann schon mal in einer
Vorlesung oder im Heise.de Forum gehört hat :)
mh schrieb:> Bis eben, war nur von sin/cos die Rede ...
Wie oft ist 'pi' nach dem Starten eines komplexeren Windows10-Spiels
durchschnittlich in CPU Cache, RAM + GPU initialisiert?
M_PI = 3.14159265358979323846;
(☞^o^)☞ Da wurde doch bestimmt auch schon mal was in Hw gemacht!??
____
Die Funktionen in HW könnten evtl auf verschiedenen Architekturen zu
unterschiedlichen Ergebnissen kommen. Nicht sicher portabel!? Es braucht
für sin/cos ja unbedingt ein statisches Pi oder?
Tim S. schrieb:> mh schrieb:> Bis eben, war nur von sin/cos die Rede ...>> Wie oft ist 'pi' nach dem Starten eines komplexeren Windows10-Spiels> durchschnittlich in CPU Cache, RAM + GPU initialisiert?> M_PI = 3.14159265358979323846;>> (☞^o^)☞ Da wurde doch bestimmt auch schon mal was in Hw gemacht!??> ____>> Die Funktionen in HW könnten evtl auf verschiedenen Architekturen zu> unterschiedlichen Ergebnissen kommen. Nicht sicher portabel!? Es braucht> für sin/cos ja unbedingt ein statisches Pi oder?
Absolut keine Ahnung was das für ein Statement oder Frage sein könnte
cppbert3 schrieb:> Tim S. schrieb:> [...]>> Absolut keine Ahnung was das für ein Statement oder Frage sein könnte
Ja ... ich frag mich wie der Beitrag aussah, bevor er ihn bearbeitet
hat. War er lesbarer, oder ...
Es gibt einfach keinen Standard. Daher in Software wo sich die
Entwickler austoben dürfen. z.B. Abhängigkeit Pi (oder andere). Wie viel
Digits / Bits? Das muss ja irgenwie "global gleich" funktionieren,
sonnst kommt nur bei jedem irgend ein anderes Ergebniss und
zwischendrinnen Wirrwar bei raus. (als einfaches Beispiel: bei
Online-Spielen). Das wäre dann eben auf die Hardware limitiert (auf der
es immer gleich läuft) und nicht portabel - solange es keine exakt
gleiche Software-Routine davon gibt. Die "Ideen und Vermutungen" vom
Eingangspost sind auch meine Vermutung - meinte ich damit. Was soll man
daran nicht verstehen?
cppbert3 schrieb:> Absolut keine Ahnung was das für ein Statement oder Frage sein könnte
Jetzt besser?
Tim S. schrieb:> Es gibt einfach keinen Standard. Daher in Software wo sich die> Entwickler austoben dürfen. z.B. Abhängigkeit Pi (oder andere). Wie viel> Digits / Bits? Das muss ja irgenwie "global gleich" funktionieren,> sonnst kommt nur bei jedem irgend ein anderes Ergebniss und> zwischendrinnen Wirrwar bei raus.
Willkommen in der realen Welt. Es kommt "bei jedem" ein anderes Ergebnis
raus.
Tim S. schrieb:> Das wäre dann eben auf die Hardware limitiert (auf der> es immer gleich läuft)
Da liegst du falsch. Auch jetzt unterscheidet sich die Hardware
deutlich.
Tim S. schrieb:> Die "Ideen und Vermutungen" vom> Eingangspost sind auch meine Vermutung - meinte ich damit. Was soll man> daran nicht verstehen?
...weil deine Frage/Statement absolut nichts mit meinem Eingangspost zu
tun hat? Für mich ist die Vergleichbarkeit von Pi über verschiedene
Software/Hardware-Platformen völlig unrelevant - nur die Geschwindigkeit
und Präzision, wobei sich keine Platform erlaubt eine Standardlib
anzubieten die, wenn double precision verfügbar ist, es nicht schafft
gleichwertig präzise Ergebnisse zu liefert
cppbert3 schrieb:> Tim S. schrieb:> Die "Ideen und Vermutungen" vom Eingangspost sind auch meine Vermutung -> meinte ich damit. Was soll man daran nicht verstehen?>> ...weil deine Frage/Statement absolut nichts mit meinem Eingangspost zu> tun hat? Für mich ist die Vergleichbarkeit von Pi über verschiedene> Software/Hardware-Platformen völlig unrelevant - nur die Geschwindigkeit> und Präzision, wobei sich keine Platform erlaubt eine Standardlib> anzubieten die, wenn double precision verfügbar ist, es nicht schafft> gleichwertig präzise Ergebnisse zu liefert
Pi, Sin, Cos etc.
mh schrieb:> Auch jetzt unterscheidet sich die Hardware deutlich.
Es gibt scheinbar nicht DEN sincos Standard, und daher auch viele
Varianten wie du ja weißt. Dazu müsste sich alles und jeder an jene
maximal-Standards halten, die garantiert immer das selbe Ergebniss
liefern - damit das auch in HW klappt. Es ist momentan -wie ihr
schreibt- einfach zu groß und ASIC, und müsste wohl ähnlich laufen, wie
man z.B. AGEIA PhysX ASICs dank Nvidia nun einfach immer dabei hat, um
das ernst nehmen zu können.
Wenn nun mein HW Sound Synthesizer anders klingt als duchschnittlich,
oder die Triangle-Textur wegen meiner Hardware leicht anders ist, als
bei den meisten anderen, mag das ja jeder verkraften. Das ist ja mein
Geschmack und so weit darf ich ja gehen!
mh schrieb:> Es kommt "bei jedem" ein anderes Ergebnis raus.
Falls das tatsächlich(?) mangels Standard immer noch so ist: Bei solchen
Rechnungen ist jede Abweichung dramatisch! Das ist ja im CPU-Core, und
dient zur "Weiterverarbeitung", worauf ggf. noch zehntausende male
zugegriffen wird, um weitere Schlussfolgerungen oder Folge-Rechnungen zu
meistern. Wenn "MEIN" sincos einfach mal abweicht, weil meine Hardware 8
Bit mehr/weniger irgendwo hat: 'wo komm ma denn da hin'?
Aber dazu kenn ich mich zu wenig aus. Da sind es eben nicht nur die
Lautsprecher die Quäken oder mein Bildschirm der bunt leuchtet. Das
könnte unter Umständen viel größere Auswirkungen haben, wenn man dank
verschiedener HW voneinander wegdriftet - würde ich behaupten.
Tim S. schrieb:> [...]> Aber dazu kenn ich mich zu wenig aus.> [...]
Da kann ich dir zustimmen. Dem Rest kann ich nicht folgen, denn
Tim S. schrieb:> cppbert3 schrieb:>> Absolut keine Ahnung was das für ein Statement oder Frage sein könnte>> Jetzt besser?
es ist immer noch nicht besser.
Tim S. schrieb:> Es gibt scheinbar nicht DEN sincos Standard, und daher auch viele> Varianten wie du ja weißt. Dazu müsste sich alles und jeder an jene> maximal-Standards halten, die garantiert immer das selbe Ergebniss> liefern
das ist alles klar - es ist keine Anforderung das über alle Systeme
immer das selbe Ergebnis geliefert wird, das wird es nie und war es auch
noch nie - du redest also von einem Problem das nur du als solches
erkannt hast :)
die Berechnungs-Ergebnisse müssen nur nur präzise genug sein - und wie
gesagt kann sich keine Platform erlaube in Single oder Double Precision
irgendwie grob andere Werte zu bekommen als anderen Single/Double
Precision Platformen
das ist alle viel klarer und definierter als du er hier unwissend
umschreibst
Was man machen kann:
-weniger Präzise rechnen (falls man einfach nicht so viele
Nachkommastellen braucht) - das kostet dann auch weniger Zeit
-oder andere Algorithmen verwenden - davon gibt es ein paar mit ihren
Vor- und Nachteilen
das kann man alles kaum oder gar nicht mit solchen FPGA/ASIC Minern
vergleichen - die schon durch den verwendeten Algorithmus massiv
parallel arbeiten können - was bei mir aber nicht der Fall ist
cppbert3 schrieb:> (Warum werden diese Funktionen - die seit dem x87 bis heute immer noch> vorhanden sind nicht mehr weiter verbessert/gepflegt) zu tun hat?
Ich verstehe ja immer noch nicht, wem oder was du da nachweinst.
Zum ehrwürdigen 386 ohne FPU gab es damals den Rechenknecht 387. Eine
Generation später hieß die CPU 486, und dazu gabs dann keinen 487 mehr,
weil der 486 die FPU schon mit an Bord hatte, und das ist heute immer
noch so. Damals wie heute gabs für wirklich schnelles Rechnen DSPs.
Oliver
Oliver S. schrieb:> Ich verstehe ja immer noch nicht, wem oder was du da nachweinst.
wenn du alle Post gelesen hättest wüsstest du das
ich wollte "nur" wissen warum die In-Chip eingebauten Funktionen nicht
mehr weitergepflegt/verbessert werden (z.B. FSINCOS) - weil diese viel
langsamer sind als die heutigen Standard-C-Lib-Implementierung auf
SSE/AVX Basis
weil ich einen iterativen und nicht parallelisierbaren Algorithmus
(schon von mehreren Mathematikern durchgekaut) habe der von der
Einzelperformanz von Double Precision SinCos profitiert bei dem ich
schon die SSE/AVX-Varianten (verschiedene durchprobiert) einsetze aber
gerne mehr rauskitzeln würde
ein FPGA bringt mir nichts weil mein Umgebender Algorithmus zu
Datenintensive ist (zu viel kopiere), alles auf GPU würde ich gerne
probieren - das scheitert aber leider am Code-Umfang (>50kLOC) (und
wieder mal der Zeit) und ein DSP würde auch aufgrund der kopiererei
nicht helfen
Oliver S. schrieb:> Zum ehrwürdigen 386 ohne FPU gab es damals den Rechenknecht 387. Eine> Generation später hieß die CPU 486, und dazu gabs dann keinen 487 mehr,> weil der 486 die FPU schon mit an Bord hatte, und das ist heute immer> noch so.
weiß das jemand nicht?
cppbert3 schrieb:> ich wollte "nur" wissen warum die In-Chip eingebauten Funktionen nicht> mehr weitergepflegt/verbessert werden (z.B. FSINCOS)
Je nun, du kennst die Antwort: Weil das außer jetzt dir die ganzen Jahre
niemand gebraucht hat. Ruf bei Intel und AMD an, und sag, daß du das
unbedingt brauchst. Vielleicht hilft das ja.
Oliver
cppbert3 schrieb:> aber es gibt> doch so viele Simulationssysteme bei denen schnelle Trigonometrische> Berechnung sehr bedeutend sind - also warum nicht mehr in-chip?
Da würde mich die Anwendung interessieren. Im
Mehrkörpersimulationskontext werden die schnellen trigonometrischen
Berechnungen immer unwichtiger. Da geht es mehr in Richtung homogene
Koordinaten, weil die mit SIMD sehr angenehm bearbeitet werden können,
während Euler-Matrizen und auch langsam die Quaternionen auf dem
absteigenden Ast sind ("the computer shapes the theory").
Oliver S. schrieb:> Je nun, du kennst die Antwort: Weil das außer jetzt dir die ganzen Jahre> niemand gebraucht hat.
ist schon ein sehr spezieller Simulations-Kontext der wirklich
Mathematisch nicht im Bereich Rendering, Raytracing, 3D-Engines usw. zu
finden ist weil sich dort alles relativ gut parallelisieren lässt -
physikalische Simulation von Oberflächenveränderung
> Ruf bei Intel und AMD an, und sag, daß du das> unbedingt brauchst. Vielleicht hilft das ja.
die Antwort habe ich schon hier schon bekommen "die Anforderunge ist
nicht allgemein genug das es sich für einen spezifische Implementierung
In-Chip lohnt" - das war meine gewollte Antwort
Walter T. schrieb:> cppbert3 schrieb:>> aber es gibt>> doch so viele Simulationssysteme bei denen schnelle Trigonometrische>> Berechnung sehr bedeutend sind - also warum nicht mehr in-chip?>> Da würde mich die Anwendung interessieren. Im> Mehrkörpersimulationskontext werden die schnellen trigonometrischen> Berechnungen immer unwichtiger. Da geht es mehr in Richtung homogene> Koordinaten, weil die mit SIMD sehr angenehm bearbeitet werden können,> während Euler-Matrizen und auch langsam die Quaternionen auf dem> absteigenden Ast sind ("the computer shapes the theory").
das hört sich doch interessant an
Hast du irgendein Paper oder Linkwas diese abkehr von schnellen
trigonometrischen Berechnungen durchkaut/anreisst
Oliver S. schrieb:> Ruf bei Intel und AMD an, und sag, daß du das> unbedingt brauchst. Vielleicht hilft das ja.
Hehe danke dass du es geschrieben hast. Ich wollte es gestern nicht mehr
posten. Echt: 1 zu 1 DIE Worte!!! Danke.
Tim S. schrieb:> Oliver S. schrieb:>> Ruf bei Intel und AMD an, und sag, daß du das>> unbedingt brauchst. Vielleicht hilft das ja.>> Hehe danke dass du es geschrieben hast. Ich wollte es gestern nicht mehr> posten. Echt: 1 zu 1 DIE Worte!!! Danke.
trefft euch doch privat wenn es zwischen euch so gut klappt :)
cppbert3 schrieb:> trefft euch doch privat wenn es zwischen euch so gut klappt :)
btw: ihr habt beide Post getätigt die entweder Abseits vom Thema waren
oder auf veralteter Informationslage basierten - aber gut das ihr euch
gefunden habt :)
cppbert3 schrieb:
[...]
> ich wollte "nur" wissen warum die In-Chip eingebauten Funktionen nicht> mehr weitergepflegt/verbessert werden (z.B. FSINCOS) - weil diese viel> langsamer sind als die heutigen Standard-C-Lib-Implementierung auf> SSE/AVX Basis
Eben genau deshalb. Das geht in die alte Richtung RISC vs. CISC - die
allgemeiner nutzbaren SSE/AVX Operationen lassen sich besser nutzen als
eine spezielle FSINCOS-Operation. Das bringt im Gesamtmix über alle für
die CPU-Hersteller relevanten Applikationen/Kunden mehr als die eine
Trig-Op. Es würde mich auch wenig wundern, wenn die irgendwann mal
wegoptimiert würde, um den dafür notwendigen Platz sinnvoller zu nutzen.
Und was wäre denn der Ersatz, Microcode des SSE-basierten Algorithmus?
Wenn man eine Nischenanwendung hat, dann passen diese
Designentscheidungen der CPU-Entwickler halt nicht unbedingt perfekt auf
die eigene Situation. Muss man so hinnehmen oder sich selbst eine CPU im
FPGA zusammenstöpseln, wenn sich das lohnt.
Ralf D. schrieb:> Muss man so hinnehmen oder sich selbst eine CPU im> FPGA zusammenstöpseln
ich finde nur sehr einfache SinCos Implementierungen (mit Tables,
relativ ungenau) für FPGAs mit Double Precision - scheint auch nicht
wirklich relevant für viele zu sein, oder kennt jemand einen guten
Double Precision (Core?) wo schon viel drin ist?
und leider ist meine FPGA Erfahrung so auf Hello-World Niveau müsste
also relativ schnell einen vielleicht teuren Spezialisten ins Boot hole
dessen arbeit ich nicht wirklich bewerten kann
und ich hab ja auch noch einen Haufen andere Algorithmen darum liegen wo
es dann schnell in vielen PC<->FPGA Kopieraktionen ausartet
aber trotzdem danke für die Tips
cppbert3 schrieb:> das ist alles klar - es ist keine Anforderung das über alle Systeme> immer das selbe Ergebnis geliefert wird, das wird es nie und war es auch> noch nie - du redest also von einem Problem das nur du als solches> erkannt hast :)
Es ist also definiert, das ein Ergebniss -mehr oder weniger- undefiniert
ist, aber definiert genug, es nicht als undefiniert zu bezeichnen. Toll.
Ein "Problem" dass natürlich wieder nur ich sehe. Na gut, dann lass es
eine Lösung sein und bau mal Hardware mit dieser Anforderung. Natürlich
kannst du dann auch behaupten, dass DEIN sincos "Richtig(er), besser u.
schneller" ist. Nun kannst du an einer Hand abzählen wen das juckt.
cppbert3 schrieb:> Gibt es sin/cos Beschleuniger, so als ASIC?Tim S. schrieb:> M_PI = 3.14159265358979323846;> (☞^o^)☞ Da wurde doch bestimmt auch schon mal was in Hw gemacht!??
Im Grunde ist das die selbe Situation und die selbe Frage. Nur mit
anderem Inhalt. Die Antworten sind dennoch analog genau die selben!
cppbert3 schrieb:> die Antwort habe ich schon hier schon bekommen "die Anforderunge ist> nicht allgemein genug das es sich für einen spezifische Implementierung> In-Chip lohnt" - das war meine gewollte Antwort
Weil es eben nicht verallgemeinert und spezifiziert wurde - sich also
kein gemeinsamer finaler Standard für eine gewollte Implementierung
ausgedacht wurde. WAS sollte man daran also pflegen können, wenn es
nicht mal eine gezielte Anforderung zum Pflegen und Ausarbeiten gibt?
Zumindet kommt mir das so vor... Auch wenn du selbst kein "Problem"
darin erkennen kannst. Und das wird sich so lange im Kreis drehen, biss
es dann einfach jemand durchgesetzt hat: C ASM VHDL alles dabei zum
selber Gießen.
Tim S. schrieb:> cppbert3 schrieb:>> das ist alles klar - es ist keine Anforderung das über alle Systeme>> immer das selbe Ergebnis geliefert wird, das wird es nie und war es auch>> noch nie - du redest also von einem Problem das nur du als solches>> erkannt hast :)>> Es ist also definiert, das ein Ergebniss -mehr oder weniger- undefiniert> ist, aber definiert genug, es nicht als undefiniert zu bezeichnen. Toll.> Ein "Problem" dass natürlich wieder nur ich sehe. Na gut, dann lass es> eine Lösung sein und bau mal Hardware mit dieser Anforderung. Natürlich> kannst du dann auch behaupten, dass DEIN sincos "Richtig(er), besser u.> schneller" ist. Nun kannst du an einer Hand abzählen wen das juckt.
Ich hab so langsam die Vermutung, dass du keine Ahnung hast, was
Fließkommazahlen sind, und wie man mit ihnen rechnet.
Ich hab gelesen das bei sincos die hintersten Bits je nach
implementierung wie im "rauschen" aufgehen, die Nachkommastellen also
nicht immer stimmen müssen. Das hast du mir ja auch bestätigst. Denn es
ist keine Anforderung. Wenn dir das reicht OK. Wenn du mit Cross- und
Portablen Code keine Lauf- oder Langzeitprobleme bekommst, OK. Wenn du
das eventuell auftretende driften durch Rundungsfehler etc. verantworten
willst, OK! Ich könnte es warscheinlich nicht.
mh schrieb:> was Fließkommazahlen sind, und wie man mit ihnen rechnet.
Nicht hundertprozent-genau, das überlass ich dem Compiler und der
Hardware. Ich brauch meist nur das Ergebniss.
Tim S. schrieb:> Ich hab gelesen das bei sincos die hintersten Bits je nach> implementierung wie im "rauschen" aufgehen, die Nachkommastellen also> nicht immer stimmen müssen. Das hast du mir ja auch bestätigst. Denn es> ist keine Anforderung. Wenn dir das reicht OK. Wenn du mit Cross- und> Portablen Code keine Lauf- oder Langzeitprobleme bekommst, OK. Wenn du> das eventuell auftretende driften verantworten willst, OK! Ich könnte es> warscheinlich nicht.
deine Argumente sind völlig sinnentleert weil es noch NIE anders war -
du sprichst von einem Problem das so immer schon existierte für jede
Software die irgendeine IEE545 konforme Hardware nutzt (das ist fast
alles was da so draussen für Geld kaufbar ist)
Und auftretenden driften reduziert man mit geeigneten Algorithmen die
nicht stupide die bekannte Fehlerrate ins unendliche steigern - und das
machen auch schon alle Algorithmen/Spiele/und und unnd so seit sehr sehr
vielen Jahren
Warum bei einem Thema mitreden von dem man so wenig Ahnung hat?
cppbert3 schrieb:> Warum bei einem Thema mitreden von dem man so wenig Ahnung hat?
oder sogar noch besser: Themenfremde (nur weils mit Fließkomma zu tun
hat hat es noch lange nichts mit dem Thema zu tun) Posts einstreuen UND
keine Ahnung haben
Tim S. schrieb:> cppbert3 schrieb:>> und das>> machen auch schon alle Algorithmen/Spiele/und und unnd so seit sehr sehr>> vielen Jahren>> ... in Software.
Wer hätte gedacht, dass auf Computern Software läuft?
mh schrieb:> Wer hätte gedacht, dass auf Computern Software läuft?cppbert3 schrieb:> weiß das jemand nicht?cppbert3 schrieb:> trefft euch doch privat wenn es zwischen euch so gut klappt :)
Eigentlich geht es schon loß, mit "dem im Kreis drehen"...
'Pi' ist doch keine Abhänigkeit von sincos oder?? Man braucht nur
Winkel. Ich weiß es nicht. Sorry dass ich zu sehr vom Thema abgelenkt
habe :-)
Tim S. schrieb:> Sorry wegen nochmal OT: Kann man das nicht auch vielleicht analog lösen?> Mit DAC + ADC an einem LCR-Netz?
Welches Problem willst du analog lösen? Und wie soll diese Lösung
funktionieren?
mh schrieb:>> 'Pi' ist doch keine Abhänigkeit von sincos oder?? Man braucht nur>> Winkel.> Was genau willst du damit sagen? Ich verstehe dich nicht.
Das ganze ist 360° und Teile davon.
mh schrieb:> Welches Problem willst du analog lösen?
'performantes sincos als opcode?'
Schon vergessen?
> Und wie soll diese Lösung funktionieren?
Man bräuchte schon "echte" ADCs, mit Schmitt-Trigger, und nicht diese
mit Puffer- und Umlade-Schei***dreck, die wiederum einfach nur Zeit und
Genauigkeit kosten würden.
Aber wie (/ob?) man aus einen Sinus den Cosinus mit diskreter Schaltung
macht? (/machen kann?) Auch -Keine Ahnung. Darum hab ich ja dieses Forum
hier so lieb, wo man so etwas eigentlich anfragen und erfahren kann.
Spreche ich spanisch oder was? Nein.
So schwer von Begriff bist du nun auch nicht!
Und lesen kannst du doch auch?
Konntest du wirklich keinerlei Zusammenhang oder Erklährung finden!?
Mehr können Vorlesungen dann auch nicht mehr bieten. Jaa kann sein, das
ich das ein oder andere missverstehe, weil ich nicht komplett auf die
Intel-Welt reduziert bin. Aber das wesentliche wurde doch gesagt, und
was zu tun ist, und wie / warum es so gemacht wird. Du hast dir ja von
Anfang an schon selbst relativ alle Antworten und Gründe im Eingangspost
mit gegeben.
Tim S. schrieb:> Konntest du wirklich keinerlei Zusammenhang oder Erklährung finden!?
Nein. Du hast keinen deiner Beiträge ausformuliert, so dass sie
verständlich sind. Ich rede nichtmal von flüssig lesbar.
Ich frage jetzt nochmal nach. Was genau willst du analog lösen? Wie
willst du es analog lösen?
Du hast bist jetzt einen Schmitt-Trigger-ADC, einen DAC und ein LCR-Netz
aufgelistet. Aber welche was genau du damit vor hast ist mir nicht klar.
Tim S. schrieb:> Spreche ich spanisch oder was? Nein.> So schwer von Begriff bist du nun auch nicht!> Und lesen kannst du doch auch?> Konntest du wirklich keinerlei Zusammenhang oder Erklährung finden!?> Mehr können Vorlesungen dann auch nicht mehr bieten. Jaa kann sein, das> ich das ein oder andere missverstehe, weil ich nicht komplett auf die> Intel-Welt reduziert bin. Aber das wesentliche wurde doch gesagt, und> was zu tun ist, und wie / warum es so gemacht wird. Du hast dir ja von> Anfang an schon selbst relativ alle Antworten und Gründe im Eingangspost> mit gegeben.
nein ehrlich, deine Post sind zu 90% unverständlich - und warum du jetzt
mit einer Analog-Lösung anfängst verstehe ich wirklich gar nicht mehr
Konstruktiv bedeutet nicht das du alles was dir in den Sinn kommt hier
einfach postest - und danach sieht es aus
Oliver S. schrieb:> Eine> Generation später hieß die CPU 486, und dazu gabs dann keinen 487 mehr,
echt? ;-)
https://upload.wikimedia.org/wikipedia/commons/2/22/KL_Intel_i487SX.jpg
OK ich weiss ja was dort steht:
i487
Der i487 (Codename: P32S / P23N) war der mathematische Koprozessor (FPU)
für die i486SX-Prozessoren. Allerdings war der i487 kein wirklicher
Koprozessor, sondern ein vollwertiger i486DX. Der i487 deaktivierte den
i486SX und übernahm alle Prozessor-Funktionen im Rechner. Um dies zu
ermöglichen, besitzt der i487 im Vergleich zum i486DX einen zusätzlichen
Pin. Dieser Pin verhindert außerdem die eigenständige Nutzung des i487
als vollwertigen i486DX.
Tim S. schrieb:> Nicht hundertprozent-genau, das überlass ich dem Compiler und der> Hardware. Ich brauch meist nur das Ergebniss.
Ne ne, zum Rechnen gehört mehr als nur die Implementation.
Fehlerfortpflanzung, Rundungsmodi, Behandlung subnormaler Zahlen, etc.
sind Themen für den Programmierer.
cppbert3 schrieb:> Walter T. schrieb:>> [...] Da geht es mehr in Richtung homogene>> Koordinaten, weil die mit SIMD sehr angenehm bearbeitet werden können,>> während Euler-Matrizen und auch langsam die Quaternionen auf dem>> absteigenden Ast sind ("the computer shapes the theory").>> das hört sich doch interessant an>> Hast du irgendein Paper oder Linkwas diese abkehr von schnellen> trigonometrischen Berechnungen durchkaut/anreisst
Nennt sich "natural co-ordinates". Das International Journal of
Computational Mechanics wirft da jede Menge neue und alte Artikel zu
aus. Ist im Prinzip eine homogene Transformation mit nicht-euklidischer
Basis.
Tim S. schrieb:> Falls das tatsächlich(?) mangels Standard immer noch so ist: Bei solchen> Rechnungen ist jede Abweichung dramatisch!
Nein, weil sich die Unterschiede in irgendwelchen Nachkommastellen
manifestieren dürfte.
Wenn der Algo so empfindlich ist, mußt du eine gescheite Testsuite
mitliefern, die checkt ob auf der jeweiligen Hardware plausible
Ergebnisse rauskommen.
Selbst bei Taschenrechnern rechnet jeder (ein bißchen) anders:
http://www.datamath.org/Forensics.htmcppbert3 schrieb:> ich wollte "nur" wissen warum die In-Chip eingebauten Funktionen nicht> mehr weitergepflegt/verbessert werden (z.B. FSINCOS) - weil diese viel> langsamer sind als die heutigen Standard-C-Lib-Implementierung auf> SSE/AVX Basis
Warum sollte jemand den alten, getesteten und gut abgehangenen '387' in
aktuellen Prozessoren nochmal anfassen?
Da besteht doch die Gefahr, das es wieder zum FDIV-Desaster kommt:
https://de.wikipedia.org/wiki/Pentium-FDIV-Bug
Hast du eigentlich mal belastbare Zahlen?
Wie schnell ist FSINCOS? Wie schnell ist SSE/AVX? Und wie schnell
brauchst du es wirklich?
Bernd schrieb:> Hast du eigentlich mal belastbare Zahlen?> Wie schnell ist FSINCOS? Wie schnell ist SSE/AVX? Und wie schnell> brauchst du es wirklich?
Fsincos ist langsamer als die heutigen SSE/AVX Lösungen deswegen wird
FSINCOS von keinem aktuellen Codegenerator mehr (ohne zu tricksen)
erzeugt, auch nicht von Intel selbst, liegt u.a. auch daran das man die
Werte erst mal in die ollen FPU Register bekommen muss (und Intel wohl
nicht die 80Bit Genauigkeit von FSINCOS irgendwie beschneiden kann oder
will) und das wohl langsam ist, ich werde aber noch einen Benchmark
erstellen um das sauber aufzuzeigen
Wie schnell? so schnell wie möglich ohne die erforderliche Double
Präzision zu verlieren, jede Performanzsteigerung and der Stelle wird
sich direkt aus, am besten wäre natürlich 1000 mal schneller ;)
Aber wie schon x mal gepostet sprengt der vollständige Algorithmus den
Forenrahmen bei weitem und SinCos steht auch nicht alleine als
Performanzfresser
Es ging mir hier auch nie um die Verbesserung von FSINCOS - die intiale
Frage war warum solche Routinen nicht (mehr) als Extensions angeboten
werden weil z.B. ein SHA256 auch als Extension existiert (die um bis zu
Faktor 8 schneller ist als Intels/und andere AVX2 Implementierungen) -
da wurde mir hier erklärt das in dem SHA256 Algorithmus zu viele direkt
nicht in AVX/usw. abbildbare Anforderunge gibt weswegen der Algorithmus
von AVX nicht profitiert
und es wurde auch erklärt das Micro-Code/AVX genau so schnell ist wie
was integriertes - was ich aber nicht wirklich glaube kann - sonst würde
es nicht so viele FPGA/DSP Tips geben
Mir ist aber klar das so eine Double Precision SinCos schon ordentlich
Platz auf dem Die brauchen kann und es wohl dann auch 1,2,3,4-Winkel
Funktionen nebst Float und Double geben müsste - was dann noch viel mehr
Platz braucht, und solche Spezialbefehle sich wohl auch nicht so gut in
die interne Optimierung des Befehlsausführung einreihen lässt, und und,
und...
aber sicher würde sich auch kaum jemand wirklich beschweren wenn es das
geben würden :)
und wenn man sich anschaut was der M1 von Apple alles so direkt
integriert hat z.B. 8GB oder 16GB RAM direkt in diesem Monster-Chip,
frage ich mich was Apple davon abgehalten hat solche Funktionen zu
integrieren - aber ich hab bisher auch noch keine Opcode- oder
Extensions-Liste vom M1 gefunden
cppbert3 schrieb:> frage ich mich was Apple davon abgehalten hat solche Funktionen zu> integrieren
Kosten-Nutzen-Analyse.
Wenn nur 0.001% der Apps davon einen Vorteil hätten, der im Schnitt
vielleicht bei 1% Performance-Zuwachs liegt, aber im Gegenzug die CPU in
der Herstellung 2% teurer wird, fliegt das Feature unter den Tisch.
Da schauen die drei Numbercruncher-Hanseln halt in die Röhre und kaufen
sich keinen Mac. Dafür verdient sich Apple an den 999 Mio anderen Kunden
je einen Zusatz-Dollar.
Sonderlocken zur "Rosetta-Beschleunigung" hingegen bringen fast allen
Anwendern einen Vorteil (zumindest bis alle Software einmal portiert
ist), da lohnt es sich, Silizium-Fläche zu investieren.
cppbert3 schrieb:>> Hast du eigentlich mal belastbare Zahlen?>> Wie schnell ist FSINCOS? Wie schnell ist SSE/AVX? Und wie schnell>> brauchst du es wirklich?>> Fsincos ist langsamer als die heutigen SSE/AVX Lösungen deswegen wird> FSINCOS von keinem aktuellen Codegenerator mehr (ohne zu tricksen)> erzeugt, auch nicht von Intel selbst, liegt u.a. auch daran das man die> Werte erst mal in die ollen FPU Register bekommen muss (und Intel wohl> nicht die 80Bit Genauigkeit von FSINCOS irgendwie beschneiden kann oder> will) und das wohl langsam ist, ich werde aber noch einen Benchmark> erstellen um das sauber aufzuzeigen>> Wie schnell? so schnell wie möglich ohne die erforderliche Double> Präzision zu verlieren, jede Performanzsteigerung and der Stelle wird> sich direkt aus, am besten wäre natürlich 1000 mal schneller ;)>> Aber wie schon x mal gepostet sprengt der vollständige Algorithmus den> Forenrahmen bei weitem und SinCos steht auch nicht alleine als> Performanzfresser
Wieviel Sin und Cos Operationen musst du in der Sekunde berechnen?
Eventuell kannst du ja den Tan = Sin/Cos verwenden,
da wäre ca. ein Faktor 2 gewonnen.
Εrnst B. schrieb:> cppbert3 schrieb:>> frage ich mich was Apple davon abgehalten hat solche Funktionen zu>> integrieren>> Kosten-Nutzen-Analyse.
wer 16GB RAM direkt auf seinen Chip baut hat doch wohl kein ernsthaftes
Problem mehr mit Silizium-Fläche :) - oder sind das nur Anbauten in
anderer Technik, größerer Strukturbreite
cppbert3 schrieb:> frage ich mich was Apple davon abgehalten hat solche Funktionen zu> integrieren
Die Antwort dürfte darauf hinauslaufen, daß der gewöhnliche Apple-Kunde
nicht mal weiß, was ein Sinus ist oder wofür man den braucht...
Oliver
cppbert3 schrieb:> wer 16GB RAM direkt auf seinen Chip baut hat doch wohl kein ernsthaftes> Problem mehr mit Silizium-Fläche :)
RAM skaliert viel besser als komplizierte Anbauten an die ALU bzw. FPU,
die sich ja auch in die Pipeline einfügen müssen usw.
cppbert3 schrieb:> oder sind das nur Anbauten in> anderer Technik, größerer Strukturbreite
Das werden separat gefertigte dies sein, die dann mit in ein Package
kommen.
PS: Mehr RAM nützt allen Anwendungen, denn alle brauchen RAM. Den RAM zu
integrieren erlaubt kleinere Geräte, was viele Kunden freuen dürfte.
Superschnelle Trigonometrie hingegen nützt nur ganz wenigen und fliegt
daher wie schon erläutert raus. So ist das mit dem Massenmarkt; man muss
es der großen Masse recht machen, damit es sich rentiert. Bei
Sonderwünschen wird es schnell kompliziert und teuer.
udok schrieb:> Und wieviele Sin und Cos Operationen musst du jetzt in der Sekunde> berechnen?>> Oder wird das jetzt ein Rentner-Dauer-Jammer-Thread?
es wird ein Ergebnis simuliert (auf das man wartet) - also so schnell
wie möglich, damit es nicht langweilig wird
Oliver S. schrieb:> cppbert3 schrieb:>> frage ich mich was Apple davon abgehalten hat solche Funktionen zu>> integrieren>> Die Antwort dürfte darauf hinauslaufen, daß der gewöhnliche Apple-Kunde> nicht mal weiß, was ein Sinus ist oder wofür man den braucht...>> Oliver
Platz 1 der lustigsten Antwort :)
Danke für die vielen Antworten - wie schon tausend mal gepostet ist der
Algorithmus viel zu groß um ihn hier zu diskutieren und das möchte ich
auch gar nicht denn da sitzen auch ein paar Mathematiker mit dran die
ziemlich genau wissen was sie tun - hätte ich den Algorithmus
diskutieren wollen hättet ihr schon lange ein kompilierbares
realtistisches Beispiel-Szenario mit Benchmarks usw.
udok schrieb:> Eventuell kannst du ja den Tan = Sin/Cos verwenden,> da wäre ca. ein Faktor 2 gewonnen.
Zu geil.
Da hat der TE schon öfter angemerkt dass da ein ganzes Team an
hochspezialisierten Spezialisten dransitzt und den Algo seit Jahren
optimiert, und dann kommt sowas.
Ich warte auf den ersten der vorschlägt, die Berechnung auf einen Atmel
oder 'nen Raspberry auszulagern ;-)
cppbert3 schrieb:> oder sind das nur Anbauten in> anderer Technik, größerer Strukturbreite
Da sind zwei LPDDR4-Dies auf dem selben Träger ("BGA Substrate") neben
dem CPU-Die.
Von der Packungs-Dichte (& Leitungslänge) ein Rückschritt gegenüber PoP
(was Apple z.B. bei den A4/iPhone-Chips verwendet hat) aber für die
Kühlbarkeit natürlich ein Vorteil.
d.H. Der Speicher geht nicht in die CPU-Silizium-"Kosten" mit ein, kann
vor der Hochzeit separat getestet werden, kommt evtl. sogar aus einer
anderen FAB.
Εrnst B. schrieb:> cppbert3 schrieb:>> oder sind das nur Anbauten in>> anderer Technik, größerer Strukturbreite>> Da sind zwei LPDDR4-Dies auf dem selben Träger ("BGA Substrate") neben> dem CPU-Die.
Und sieht dann so aus:
https://d3nevzfk7ii3be.cloudfront.net/igi/ZRQGFteQwoIVFbNn
Ist noch nicht HBM wie bei manchen Grafikkarten aber eben doch näher an
der CPU als auf dem Mainboard und kann damit schneller angebunden
werden.
