Double zerlegen in M und E
-
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.
-
@Ethon
Naja...volkard schrieb:
It0101 schrieb:
Du meinst lzw oder so?
Ja. LZO oder LZ4 wären meine ersten Gedanken.
-
Ich würde nicht im Traum daran denken für 4-8 Byte nen Kompressionsalgorithmus zu bemühen... Also wenn, ich mich dafür entscheide, was, Stand heute, nicht der Fall ist, würde ich die Kompression über die komplette Message ziehen und nicht über einzelne Elemente.
-
It0101 schrieb:
Ich würde nicht im Traum daran denken für 4-8 Byte nen Kompressionsalgorithmus zu bemühen... Also wenn, ich mich dafür entscheide, was, Stand heute, nicht der Fall ist, würde ich die Kompression über die komplette Message ziehen und nicht über einzelne Elemente.
Scherzkeks! Davon reden wir doch.
