Trading-Stocks.de

Normale Version: Open Source Tools und Daten
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Seiten: 1 2 3 4 5
(04.01.2023, 11:18)Lancelot schrieb: [ -> ]...
Echt erstaunlich was man da auf einem einzelnen Server hinbekommt. Und auch wenn man mal mit der Sprache ne weile gearbeitet hat...tut echt aua danach wieder zu C/Java/C#/Python zu wechseln.

Ich habe mir mal kurz auf youtube angeschaut, was dieses Kdb+ ist. Schnell mag es ja sein, aber mit der Lesbarkeit habe ich so meine Probleme, und glaubt, dass auch dei Autoren nach einer Woche rätseln, was sie da so zusammengeschraubt haben. Ich finde es auch erstaunlich, dass dabei üerhaupt was sinnvolles bei rauskommt, insbesondere, wenn es schnell gehen muss. Aber dafür gibt es ja die hyper-optimierten build-ins, um die man sich in anderen Sprachen selber kümmern muss, oder sich über vielfältige Bibliotheken importieren muss.
Ich habe eine Handvoll Batch-ETL Jobs die wir in Spark nächtlich laufen lassen und über die Zeit relativ aggressiv optimiert hatten auf kdb+ portiert. 

Aus X Zeilen code sind ein paar Zeilen geworden. Das ist fast 100 mal schneller und mit einem deutlich kleineren memory footprint.   

Zum Spaß habe ich auch eine Microservice Komponente die in Kafka Streams umgesetzt wurde portiert. Das läuft auf einem Prozess und schlägt bei Lasttest in Sachen Latenz und Throughput  die Originallösung um ein Vielfaches (die habe ich aber nicht selber geschrieben, vielleicht ist das einfach schlecht umgesetzt worden).

Lass es mich so formulieren: wenn dur ein richtig richtig guter Fortran/C/C++/Rust Programmierer bist, kannst du die gleiche Geschwindigkeit erreichen. Ich kenne nur ne Handvoll richtig richtig guter Programmiere. Ne Menge die sich dafür halten. 



Ich lass bei den Juniors "lesbar" nicht mehr gelten. Ich muss inzwischen echt sagen, code nach "clean code" Dogma über X Klassen und Methoden zu verteilen....ist vielleicht auch nicht der Weisheit letzter Schluss (ist code wirklich einfacher zu lesen wenn du x mal got to implementation clicken musst?). .  
Das ist Gewohnheit und eigentlich streng mathematische Notation. Stur von rechts  anch links ausgewertet ....f(g(h(x))). 

Ich bin da leider noch nicht. Aber die Profis mit denen ich da gearbeitet habe, die lesen das wie Fließtext. Die Komplexität der Anwendungen, Rechenleistung und Daten Volumen und Velocity waren von de Art wie du sie von Alibab am Black Friday hörst. Verwaltet von ner kleinen Truppe Ü-40 bis Ü-50 geeks.  
 
Ist anders...aber ich es kann sein, das wir allle in den 60-70ern falsch abgebogen sind.
Ich habe mir das auch mal auf Youtube angesehen:
https://www.youtube.com/watch?v=gBJ2QilHDXo

Schon nett was er da macht. Wo kriegt er die Börsendaten her?

q oder kdb+ ist eben speziell für diese Sachen entwickelt, klar. Dann ist es auch schnell. Muss ja sonst auch nicht viel können. Vielleicht direkt in Assembler programmiert?

Ich habe in den 80igern ein bisschen Assembler programmiert, pain in the ass, sage ich nur. Aber schnell. Gibt es das überhaupt noch?

Übrigens ist zB auch Matlab bei bestimmten Anwendungen verblüffend schnell. Ich hatte so was mal ausprobiert, und Matlab hat tatsächlich kompiliertes Delphi und natürlich Basic deutlichst geschlagen.
Matlab hat ja ein ähnliches Konzept. Matlab ist auch array optimiert. Wenn du da X'X oder inv(X) eintippst, rattert da unter der Haube pervers optimierter C code los. Wenn du das Problem in vektorisierter Form beschrieben bekommst ist es schnell. Ähnlich wie Python numpy oder pytorch (selbst ohne GPU). Da liegen über Jahrzehnte optimierte Fortran/C Routinen drunter. 

Ich würde da jetzt ungern nen Web Shop in k schreiben, aber die Sachen die ich so mache (viel Daten, Regelungstechnik, OLAP, Echtzeitsysteme.) da ist das schon schnell. Es lässt sich leider nicht so einfach in die Cloud Welt portieren, bzw verliert viele seiner Vorteile wenn man da einen Object Store wie AWS S3 drunter hängt. Und damit ist es für viele Anwendungen gestorben.
(04.01.2023, 17:33)Lancelot schrieb: [ -> ]Ich habe eine Handvoll Batch-ETL Jobs die wir in Spark nächtlich laufen lassen und über die Zeit relativ aggressiv optimiert hatten auf kdb+ portiert. 

Aus X Zeilen code sind ein paar Zeilen geworden. Das ist fast 100 mal schneller und mit einem deutlich kleineren memory footprint.   

Zum Spaß habe ich auch eine Microservice Komponente die in Kafka Streams umgesetzt wurde portiert. Das läuft auf einem Prozess und schlägt bei Lasttest in Sachen Latenz und Throughput  die Originallösung um ein Vielfaches (die habe ich aber nicht selber geschrieben, vielleicht ist das einfach schlecht umgesetzt worden).

Lass es mich so formulieren: wenn dur ein richtig richtig guter Fortran/C/C++/Rust Programmierer bist, kannst du die gleiche Geschwindigkeit erreichen. Ich kenne nur ne Handvoll richtig richtig guter Programmiere. Ne Menge die sich dafür halten. 



Ich lass bei den Juniors "lesbar" nicht mehr gelten. Ich muss inzwischen echt sagen, code nach "clean code" Dogma über X Klassen und Methoden zu verteilen....ist vielleicht auch nicht der Weisheit letzter Schluss (ist code wirklich einfacher zu lesen wenn du x mal got to implementation clicken musst?). .  
Das ist Gewohnheit und eigentlich streng mathematische Notation. Stur von rechts  anch links ausgewertet ....f(g(h(x))). 

Ich bin da leider noch nicht. Aber die Profis mit denen ich da gearbeitet habe, die lesen das wie Fließtext. Die Komplexität der Anwendungen, Rechenleistung und Daten Volumen und Velocity waren von de Art wie du sie von Alibab am Black Friday hörst. Verwaltet von ner kleinen Truppe Ü-40 bis Ü-50 geeks.  
 
Ist anders...aber ich es kann sein, das wir allle in den 60-70ern falsch abgebogen sind.

Ich komme auch noch aus einer Zeit, in der man im C-Code Assembler für kritische Teile eingefügt hat, um das ganze akzeptabel auf Kleinstcomputern laufen lassen zu können. Oder aber das ganze gleich in Assembler programmiert hat.
Bei "Clean Code" bin ich ganz bei dir, aber leider sind wir derzeit in der Situation, dass schnellere Rechner leichter zu bekommen sind als gute Entwickler/Programmierer. Bei kritischen Anwendungen kommt man da dann natürlich an seine Grenze, wenn es technisch nicht schneller geht, wie z.B. beim Hoch-Frequenz-Handel. Da braucht man dann Gehirnschmalz - und Leute die den haben.

Das drastischste Beispiel dass ich mal mitbekommen habe war in den 70/80ern eine Simulation einer Sternenexplosion auf einem Crayrechner(Vektorrechner). Die hochgerechnete Simulationszeit betrug über 3 Jahre Non-Stop. Entwickelt war das Programm von Astrophysikern. Dann haben sich Cray-Experten um das Programm gekümmert. Das Ergebnis war eine Reduktion der Rechenzeit auf wenige Wochen. 


Mit f(g(h(x))) meinst du das Q bzw. Kdb+ eine funktionale Sprache ist?
(04.01.2023, 21:37)TomJoe schrieb: [ -> ]Mit f(g(h(x))) meinst du das Q bzw. Kdb+ eine funktionale Sprache ist?

Genau. Das von links nach rechts auswerten in k ist sehr funktional-(als erst y= h(x) und dann z = g(y) und dann f(y)) 

Es gibt tatsächlich wohl wieder viel Bewegung in der assembler Welt. Da kenne ich mich aber nicht aus.  

Schau dir doch als "old-schooler" mal Rust an. Was sagst du dazu?
(04.01.2023, 22:25)Lancelot schrieb: [ -> ]Genau. Das von links nach rechts auswerten in k ist sehr funktional-(als erst y= h(x) und dann z = g(y) und dann f(y)) 

Es gibt tatsächlich wohl wieder viel Bewegung in der assembler Welt. Da kenne ich mich aber nicht aus.  

Schau dir doch als "old-schooler" mal Rust an. Was sagst du dazu?

Rust hatte ich mir schon mal angeschaut. Macht einen guten Eindruck, aber ich werde mir keine neue Sprache mehr antun. Ich habe schon mehr Sprachen vergessen als ich noch neu lernen kann. Aktuell verwende ich für die Finanzprogrammiererei python, weil es da gibt was ich brauche oder meine zu brauchen.
(04.01.2023, 19:17)rienneva schrieb: [ -> ]Ich habe mir das auch mal auf Youtube angesehen:
https://www.youtube.com/watch?v=gBJ2QilHDXo

Schon nett was er da macht. Wo kriegt er die Börsendaten her?

Würde mich auch interessieren (bzw. in welcher Form). Ob man die Daten von IB über deren API in nutzen könnte?
(05.01.2023, 11:07)lomo schrieb: [ -> ]Würde mich auch interessieren (bzw. in welcher Form). Ob man die Daten von IB über deren API in nutzen könnte?

Da besteht wohl ein Missverständnis. kdb+  ist eine Time Series Datenbank + Real Time Analytics. Das ist Software. kdb+ ist kein Datenlieferant. Das wird auch von Formel 1 Teams und Telecoms benützt. Das ist erstmal agnostisch zu Daten. Da ist kdb+ keine Magie (wie alles). Da liegen auch nur Files in einem Filesystem. 

Wie die Daten in die Datenbank kommen, ist eine andere Fragestellung. Dafür bist du selbst zuständig. Du kannst natürlich Daten über IB in die kdb+ Datenbank ziehen. IB bietet auch FIX an. Da gibst überall Code Schnippsel für. Wenn du die Client API verwendest kannst du das mit ein bisschen code in den Ticker Plant von kdb+ schieben. 

So etwa:
https://github.com/mfitsilis/ibfeed

Aber das ist natürlich von der Performance der IB Client das Bottleneck.
(05.01.2023, 12:01)Lancelot schrieb: [ -> ]Da besteht wohl ein Missverständnis. kdb+  ist eine Time Series Datenbank + Real Time Analytics. Das ist Software. kdb+ ist kein Datenlieferant. Das wird auch von Formel 1 Teams und Telecoms benützt. Das ist erstmal agnostisch zu Daten. Da ist kdb+ keine Magie (wie alles). Da liegen auch nur Files in einem Filesystem. 

Wie die Daten in die Datenbank kommen, ist eine andere Fragestellung. Dafür bist du selbst zuständig. Du kannst natürlich Daten über IB in die kdb+ Datenbank ziehen. IB bietet auch FIX an. Da gibst überall Code Schnippsel für. Wenn du die Client API verwendest kannst du das mit ein bisschen code in den Ticker Plant von kdb+ schieben. 

So etwa:
https://github.com/mfitsilis/ibfeed

Aber das ist natürlich von der Performance der IB Client das Bottleneck. Du kannst das nur 10 mal pro Minute aufrufen. 
Seiten: 1 2 3 4 5