Double zerlegen in M und E
-
Danke. Gut zu wissen, dass ich nicht der einzige bin, dem bei sowas der Kackstift geht
PS: ich baue im Prinzip auch nen Serializer...
Ich hab mir auch schon mal die Frage gestellt, warum ich nicht einfach generell auf Doubles verzichte und einfach alles mit 10^4 multipliziere... Das ist bei meinen Anwendungsfällen ( Wertpapierdaten ) im Prinzip der hauptsächliche Anwendungsfall
Als Beispiel für effiziente Übertragung von Gleitkommazahlen sind z.b. die Kursdatenströme der Deutschen Börse zu empfehlen. Die senden für einen speziellen Börsenplatz innerhalb 14h 40GB raus. Würden die für jede Gleitkommzahl 8 Byte verwenden, würden den Kunden die Leitungen wegplatzen
Aber das Protokoll, welches die nutzen ist DEUTLICH komplexer und den Aufwand will ich nicht (nochmal) betreiben
-
It0101 schrieb:
Andererseits, wenn ich dann jedes mal 8 Byte versende, auch wenn die Zahl nicht mal ansatzweise 8 Byte rechtfertigt, ist das auch ganz schöne Platzverschwendung.
-3,75 braucht z.B. nur 3 Byte, wenn man es brauchbar verpackt. 1 Bit Vorzeichen, 7 Bit Exp, 2 * 7 Bit für die Mantisse ( Basis 10 ) mit Stopbit.
Warum nicht den ganzen Stream ein wenig packen?
-
Du meinst lzw oder so?
Hier hab ich mal ein Beispiel gefunden, für das was ich meinte:
obwohl nee... der Code ist nicht so meins... irgendwie. Gleitkomma-Multiplikationen... schnell kann das nicht sein.
Hier noch was:
http://cpp4theselftaught.com/2013/04/serializing-floats/Aber mit logarithmen und pow... wird immer schlimmer.
-
Entweder du willst Speicher sparen oder Geschwindigkeit optimieren, beides geht selten ...
Was hast du überhaupt vor? Klingt nach extremem Overengineering.
-
It0101 schrieb:
Du meinst lzw oder so?
Ja. LZO oder LZ4 wären meine ersten Gedanken.
Du definierst als Austauschformat einfach "IEEE 754 binary64".
Kannst ja gerne bei Programmstart prüfen, ob der Rechner "double"=="IEEE 754 binary64" hat, indem Du sizeof(double)==8 prüfst und ein paar bekannte Werte nach uint64_t oder char[8] reinterpret_castest. Falls der Rechner pöse ist, mußte für ihn was anpassen. Aber es wird nicht passieren.
-
Frage an den TE: Kennst du eine CPU die nicht IEEE 754 verwendet?
-
It0101 schrieb:
Wertpapierdaten
Damit meinst du aber keine Geldwerte, oder? Ansonsten stimme ich hustbaer zu. Es gibt keinen Grund im Protokoll nicht einfach zu definieren, dass wert xyz nun mal als "IEEE 754 binary64" gesendet wird. Jeder Rechner der das nativ nicht kann soll dann halt konvertieren, ist ja kein Problem. (Kann man mit LE integern btw. genau so machen.)
-
It0101 schrieb:
Wertpapierdaten
Also ich kenn mich mit Wertpapieren jetzt nicht so gut aus, aber ich kann mir nicht vorstellen dass es da viele Daten gäbe die in einer binären Gleitkommazahl gut aufgehoben wären.
=> Nimm was dezimales. Entweder gleich Fixkomma wie du schon selbst geschrieben hast, oder halt ne dezimale Gleitkommazahl.Und nicht nur zur Übertragung, du solltest auch nicht im Programm
floatoderdoubledafür verwenden. Weil die meisten dezimalen Kommazahlen halt nicht in binären Gleitkommazahlen darstellbar sind.ps: zu langsam
-
@volkard: Warum nicht
std::numeric_limits<double>::is_iec559?Was hast du überhaupt vor? Klingt nach extremem Overengineering.
Programmierer wissen bekanntlich nicht wo es wirklich harkt, performancetechnisch.
-
Naja, er hat nachträglich ja editiert:
Die senden für einen speziellen Börsenplatz innerhalb 14h 40GB raus.
Ist doch nichtmal ein MB pro Sekunde. Wenn interessiert da ob beim dekomprimieren "teure" Instruktionen verwendet werden?
-
-
It0101 schrieb:
Als Beispiel für effiziente Übertragung von Gleitkommazahlen sind z.b. die Kursdatenströme der Deutschen Börse zu empfehlen. Die senden für einen speziellen Börsenplatz innerhalb 14h 40GB raus
Ach? Tun wir das bei uns so
? Ist ja interessant.
-
Ethon schrieb:
Naja, er hat nachträglich ja editiert:
Die senden für einen speziellen Börsenplatz innerhalb 14h 40GB raus.
Ist doch nichtmal ein MB pro Sekunde. Wenn interessiert da ob beim dekomprimieren "teure" Instruktionen verwendet werden?
Das ist ja nichts an Bandbreite.
Gehts um Null-Sekunden-Trading? Dann würde ich suchen, wo der "Flaschenhals" ist. "Flaschenhals" im Sinne von Startverzögerung. Oder mich einstellen.
-
40GB sind dann in Ordnung, wenn sie gleichverteilt kommen. Wer von liquiden Wertpapieren was versteht, der weiß, dass dem bei weitem nicht so ist. Jedenfalls nicht bei euch, ne tntnet?
Interne Details spar ich mir hier, bzw. erspar ich euchAber hier gehts nicht um DB1 sondern um meine "Bedürfnisse". Ich denke nochmal drüber nach, was ihr hier vorgeschlagen habt.
-
Selbst wenn alles auf einmal reinkommt kannst du sicherlich mehr entpacken als die Netzwerkkarte reinbringt.
-
Ethon schrieb:
Selbst wenn alles auf einmal reinkommt kannst du sicherlich mehr entpacken als die Netzwerkkarte reinbringt.
Also mit Infinibandverbindung wird das so langsam kritisch
.
-
Reicht doch schon 10GB Ethernet.
-
hustbaer schrieb:
Reicht doch schon 10GB Ethernet.
So viele Daten kommen von der Börse wohl kaum auf einmal.
Bin jetzt kein Hardware-Experte aber ich bezweifle dass der Bus zwischen Netzwerkkarte und RAM schneller ist als der zwischen CPU und RAM.Wenn man bedenkt dass die zu "teuren Operationen" pow/log sind bezweifle ich dass die CPU nicht weiterbekommt was über den RAM-Bus kommt.
-
Also wenn ich ein 7z Archiv entpacke dann geht das selten mit mehr als ein paar hundert MB/Sekunde.
-
hustbaer schrieb:
Also wenn ich ein 7z Archiv entpacke dann geht das selten mit mehr als ein paar hundert MB/Sekunde.
Wir sprechen hier aber nicht von einem komplexen Kompressionsalgorithmus sondern darum ein double als integer zu packen/entpacken.
