Cosinus-Chip bzw. Maschinenbefehl, gibt's so etwas?
-
In diesem Thread findest du vielleicht etwas
-
Darf man fragen wozu du so häufig cos() brauchst?
-
alle 32bit microsoft betriebssysteme setzen mindestens eine 386dx cpu voraus, entsprechend sind alle kompilate auch fuer FPUs gebaut.
eine sinus berechnung 'kostet' bis zu 100 cycle auf einer intel cpu, in optimalen faellen kann das auf knapp ueber die haelfte runter gehen. du kannst dabei zwei davon gleichzeitig abarbeiten lassen und zudem kannst du sinus und cosinus in einem befehl ausfuehren.
weiter kannst du bei visual studio in den optionen einstellen dass du weniger auf genauigkeit achtest und "fast" floats willst.
am ende kannst du auf einer schnellen cpu auf vielleicht ne milliarde kommen (alle cores nutzen, fsincos, zwei in der pipe, und hoher takt vorausgesetzt).
-
rapso schrieb:
alle 32bit microsoft betriebssysteme setzen mindestens eine 386dx cpu voraus, entsprechend sind alle kompilate auch fuer FPUs gebaut.
Ja aber nicht mit SSE optimierter code. Und der ist schneller. Beim gcc kann man z.B. mit einem switch (-msse, -msse2, -msse3) dafür sorgen, dass SSE optimierter Code erzeugt wird. Soweit ich weiß, sollte da auch die Cosinus-Funktion von profitieren.
Falls dir die Genauigkeit nicht so wichtig ist, kann man gucken, ob man irgendwie günstiger daran kommt. Also z.B. mit Lagrange-Interpolation von einem relativ niedrigen Grad. Das reicht manchmal schon aus.
-
ProgChild schrieb:
rapso schrieb:
alle 32bit microsoft betriebssysteme setzen mindestens eine 386dx cpu voraus, entsprechend sind alle kompilate auch fuer FPUs gebaut.
Ja aber nicht mit SSE optimierter code.
und was hat das mit dem topic zu tun die eingebauten sinus befehle der cpu zu nutzen? bzw worauf willst du hinaus?
Und der ist schneller. Beim gcc kann man z.B. mit einem switch (-msse, -msse2, -msse3) dafür sorgen, dass SSE optimierter Code erzeugt wird. Soweit ich weiß, sollte da auch die Cosinus-Funktion von profitieren.
sse hat keinen sinus, der wird emuliert, falls du 4sinus auf einmal berechnen willst, kommst du vielleicht sogar auf die geschwindigkeit der fpu.
Falls dir die Genauigkeit nicht so wichtig ist, kann man gucken, ob man irgendwie günstiger daran kommt. Also z.B. mit Lagrange-Interpolation von einem relativ niedrigen Grad. Das reicht manchmal schon aus.
das ist sicher die frage, was an genauigkeit reicht einem? es gibt sehr viele moeglichkeiten sinus-naehrungen zu erhalten die einen bruchteil kosten, die simpelste waere eine lookup table, falls die im L1 ist, ist man mit 3 cycles dabei (je nachdem wie man indiziert).
-
Hier, in diesem Dokument auf Seite 46 unten steht was zum cos Befehl: fcos
http://dlc.sun.com/pdf/817-5477/817-5477.pdf
-
/rant/ schrieb:
In diesem Thread findest du vielleicht etwas
absolut gut getrickst mit den parabeln. *alle_daumen_hoch*
-
Tim schrieb:
Darf man fragen wozu du so häufig cos() brauchst?
Gute Frage, interessiert mich auch.
Was macht man mit einer Milliarde cos() Ergebnisse pro Sekunde? Anders ausgedrückt, ein Ergebnis pro eine Nanosekunde... Irgendwo speichern - kann man ja vergessen, das sind eine Milliarde, sagen wir mal, floats (4 Byte) pro Sekunde. Sprich, 4 GByte pro Sekunde !
-
abc.w schrieb:
Was macht man mit einer Milliarde cos() Ergebnisse pro Sekunde?
keine phantasie? dicketale signalverarbeitung, dft in echtzeit z.b.
-
+fricky schrieb:
abc.w schrieb:
Was macht man mit einer Milliarde cos() Ergebnisse pro Sekunde?
keine phantasie? dicketale signalverarbeitung, dft in echtzeit z.b.
Ob ich Phantasie habe, weiss ich nicht, aber was immer man mit dieser einen Milliarde cos() Ergebnisse anstellt, kostet ja noch weitere CPU Takte.
-
abc.w schrieb:
Ob ich Phantasie habe, weiss ich nicht, aber was immer man mit dieser einen Milliarde cos() Ergebnisse anstellt, kostet ja noch weitere CPU Takte.
deswegen nimmt man gern dedizierte hardware für sowas. stell dir vor, unserere weit verbreiteten x86-gurken hätten keinen rechenknecht drin, dann könnteste bestimmt kein ruckelfreies mpeg-video betrachten. oder es gäbe keine 3d-grafikkarten für unsere killerspielenden freunde, die müssten dann mit games vorlieb nehmen, die grafisch auf dem stand von 1980 a.d sind, also wo die blutflecken noch lauter kleine rechtecke sind, usw.
-
+fricky schrieb:
abc.w schrieb:
Ob ich Phantasie habe, weiss ich nicht, aber was immer man mit dieser einen Milliarde cos() Ergebnisse anstellt, kostet ja noch weitere CPU Takte.
dann könnteste bestimmt kein ruckelfreies mpeg-video betrachten.
mpeg4-avc kann man mit nur integer dekodieren, auf einem normalen x86