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.
:
Bearbeitet durch User
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...
Ganz gute Erklärung, Danke Gibt es sin/cos Beschleuniger, so als ASIC?
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.
:
Bearbeitet durch User
(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.
:
Bearbeitet durch User
Es gibt sogar einen Chip von Infineon https://www.infineon.com/dgdl/XC886_CordicMDU_V13.pdf%3FfileId%3Ddb3a304412b407950112b40c77960b30 aber üblicherweise wird das in ein FPGA gebrannt, man braucht ja auch drumherum als Einsatzzweck, und da gibt es reichlich https://www.google.com/search?q=cordic+hardware
cppbert3 schrieb: > Gibt es sin/cos Beschleuniger, so als ASIC? Ich würde mal bei den Grafikkarten suchen.
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
Und beim SHA256 rede ich teilweise mit 200 oder mehr Geräten
(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
cppbert3 schrieb: > Und beim SHA256 rede ich teilweise mit 200 oder mehr Geräten Wozu braucht man da einen Sinus?
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.
:
Bearbeitet durch User
Plessey hatte mal solche speziellen DSP-ICs, z.B. einen "Pythagoras", also Umrechnung kartesich zu polar.
(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.
:
Bearbeitet durch User
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
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/
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 | double x; |
4 | double sin_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 | void d_sincos (double x, 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?
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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
Hab mal nachgeschaut, GEC Plessey. "Digital Signal Processing. IC Handbook". November 1990. scheint im Web kaum vorzukommen. In der Zeit, als ein 386er noch einen mathematischen Coprozessor 387 hatte, gab es solche Spezialchips. http://www.computinghistory.org.uk/det/17386/Digital%20Signal%20Processing%20IC%20Handbook/ eine Abbildung der Titelseite der 1993er Ausgabe und kurz die Überschriften der Datenblätter http://13.124.15.139/pdf/download.php?id=8706265829cbeb78718c20687440c83ec65a04&type=O&term=gec%2520plessey%2520ula http://13.124.15.139/pdf/download.php?id=6f6a6f8f7d2c81f719e3442d545672806d2be4&type=O&term=gec%2520plessey%2520ula http://13.124.15.139/pdf/download.php?id=3708e0be326d7f1fc5e1bc60bda503b04e8b1d&type=O&term=gec%2520plessey%2520ula drei Auszüge, FFT-Prozessor, komplexer Multiplizierer und FIR-Filter heute hat man sowas als "intellectual property" im FPGA.
Christoph db1uq K. schrieb: > Hab mal nachgeschaut, > GEC Plessey. "Digital Signal Processing. IC Handbook". November 1990. > scheint im Web kaum vorzukommen. In der Zeit, als ein 386er noch einen > mathematischen Coprozessor 387 hatte, gab es solche Spezialchips. > > http://www.computinghistory.org.uk/det/17386/Digital%20Signal%20Processing%20IC%20Handbook/ > eine Abbildung der Titelseite der 1993er Ausgabe und kurz die > Überschriften der Datenblätter > > http://13.124.15.139/pdf/download.php?id=8706265829cbeb78718c20687440c83ec65a04&type=O&term=gec%2520plessey%2520ula > http://13.124.15.139/pdf/download.php?id=6f6a6f8f7d2c81f719e3442d545672806d2be4&type=O&term=gec%2520plessey%2520ula > http://13.124.15.139/pdf/download.php?id=3708e0be326d7f1fc5e1bc60bda503b04e8b1d&type=O&term=gec%2520plessey%2520ula > drei Auszüge, FFT-Prozessor, komplexer Multiplizierer und FIR-Filter > > heute hat man sowas als "intellectual property" im FPGA. ich hab auch bei deinem Post leider keine Ahnung was das mit dem Thema (Warum werden diese Funktionen - die seit dem x87 bis heute immer noch vorhanden sind nicht mehr weiter verbessert/gepflegt) zu tun hat? und ich kann mir auch kaum vorstellen das jemand für schnelle einfach-SinCos Berechnungen (also keine Wolke aus Daten durchkauen, sondern einzeln) einen FPGA programmiert und den anbindet - ist einfach viel zu langsam - wegen der Übertragungsdauer(Latenz) der Daten
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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
cppbert3 schrieb: > und das > machen auch schon alle Algorithmen/Spiele/und und unnd so seit sehr sehr > vielen Jahren ... in Software.
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 :-)
Sorry wegen nochmal OT: Kann man das nicht auch vielleicht analog lösen? Mit DAC + ADC an einem LCR-Netz?
Tim S. schrieb: > 'Pi' ist doch keine Abhänigkeit von sincos oder?? Man braucht nur > Winkel. Was genau willst du damit sagen? Ich verstehe dich nicht.
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.
Tim S. schrieb: > [...] Von dir bekommt man einfach keine Antwort, die man lesen und verstehen 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.htm 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 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
Und wieviele Sin und Cos Operationen musst du jetzt in der Sekunde berechnen? Oder wird das jetzt ein Rentner-Dauer-Jammer-Thread?
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 ;-)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Ε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.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.