Double zerlegen in M und E
-
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.
-
Das du das weißt, ist mir klar. Bei Ethon war ich mir nicht so sicher, deswegen wollte ich das nochmal betonen.
-
Du hast geschrieben dass dir die 754 Pack/Unpack Algorithmen zu langsam wären.
Programmierst du denn für ausgelastete 10gbit Leitungen?
-
Ich habe nur vermutet, dass das nicht sehr schnell ist. Wobei "schnell" ja auch sehr relativ ist. Aber vermutlich reichen die Funktionen locker. Heutzutage kann das ja für ne CPU nicht mehr so die große Nummer sein, zwei Gleitkommazahlen zu multiplizieren. Ich denke, das ist ein Aufwand den man durchaus akzeptieren kann.
