Hallo, ich habe ein kleines Commandline-Programm in python geschrieben das folgendes macht: - Dateien schreiben/lesen/manipulieren - Daten über TCP-sockets schicken und empfangen (als Client). Leider ist es ein wenig (ok, viel) zu langsam, ich werde es also in C neu schreiben. Unter Linux kein Problem, brauchen würde ich es allerdings unter Windows. Das letze mal dass ich in C für Windows programmiert habe ist gute 15 Jahre her.;) Könnt ihr mir einen einfachen Weg für meine Zwecke weisen? Cross-Entwicklung (mingw, cygwin)? Oder gleich unter Windows entwickeln (einfache IDE)? Bin für jeden Tipp dankbar, andi
Andi schrieb: > Könnt ihr mir einen einfachen Weg für meine Zwecke weisen? > Cross-Entwicklung (mingw, cygwin)? Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre, solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64 bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon. MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das ist bei Dateien kein Problem, weil man das ja sowieso mit den Standardfunktionen von C macht, aber bei den Sockets wird es ungemütlicher.
Nop schrieb: > Cygwin hat den Vorteil, daß es wesentlich ähnlicher zu Linux wäre, > solange Dir das in 32 bit ausreicht (außer die haben inzwischen auch 64 > bit). Du brauchst dann aber die Cygwin-DLL dazu, was zum Hausgebrauch > und auch für GPL-Programme kein Problem ist, sonst aber U.u. schon. 32bit reichen sicher aus. DLL ist kein Problem und Lizenzprobleme sehe ich auch keine. > MingW hingegen erzeugt Dir Windows-Programme in "richtig nativ", aber um > den Preis, daß Du dann auch Windows-spezifisch programmieren mußt. Das > ist bei Dateien kein Problem, weil man das ja sowieso mit den > Standardfunktionen von C macht, aber bei den Sockets wird es > ungemütlicher. Riecht das etwa nach winsocket? Das habe ich noch in schlechter Erinnerung ... und würde lieber einen grossen Bogen um das Thema machen ;) Also werde ich mir mal cygwin anschauen... Danke, andi
Das Buch beschreibt Techniken die auf beiden Platformen funktionieren. https://books.google.de/books?id=Ub4hGNvBpPYC&printsec=frontcover&dq=snader+effetive+tcp+/ip&hl=de&sa=X&redir_esc=y#v=onepage&q=snader%20effetive%20tcp%20%2Fip&f=false
Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das Teil ist nen einziger Hack. Mag ja ok sein, um irgendwelche Posix-Programme zu bootstrappen, aber nichts für den Normalgebrauch - darin geschriebene Programme sind wie ein Fremdkörper im System. Mingw dagegen kann ich empfehlen. Erstellt kleine Programme, und im Gegensatz zu Microsofts Compilern, ohne zusätzliche Runtime-Abhängigkeiten. Für Konsolenanwendungen genau das richtige. Mit etwas Sorgfalt läuft ein und dasselbe Programm dann auf allen Windows-Versionen ab 2000. Für aufwendigere GUI-Anwendungen dürfte allerdings Visual-C & Co am einfachsten sein.
> Riecht das etwa nach winsocket? > Das habe ich noch in schlechter Erinnerung ... und würde lieber einen > grossen Bogen um das Thema machen ;) Ne einfache TCP-Verbindung aufmachen und Daten austauschen geht mit winsock doch genau so wie unter Linux - die Funktionen heißen nur etwas anders. Wenn du dir aber mal anschaust, was Cygwin für Klimmzüge macht, um select(2) zu implementieren ... PS: im vorigen Post muss es "ab Windows NT" heißen ;-)
Konsolenprogramme kannst du auch mit Visual Studio in der kostenlosen Version entwickeln und bequem debuggen. Solange es kein mfc Programm ist (was man bei Konsole so gut wie nie braucht) sind da auch keine Abhängigkeiten zu vc runtimes. MFC geht eh nur in der Bezahlversion. Der MS C++ Compiler ist hoch optimierend, obwohl das bei dir wahrscheinlich nicht relevant ist.
Ich werfe mal C++ mi Qt ins Rennen... Vorteil: + Sourcecode für Win, Linux "Mac" nutzbar (kompilierbar) + Bietet Netzwerkklassen (TCP/UDP Basis und auch einige Server-Klassen) + Wenn eine GUI benötigt wird, ist alles dabei... + Kompilieren unter Windows mit Visual Sudio (Community Studio reicht) oder auch mingw möglich + Qt-Creator als Entwicklungsumgebung für Linux, Windows (nutzt dann Debugger von VS) und Mac Nachteil: - Das Framework ist schon ziemlich "fett" - Nicht wirklich "Keep it simple"
asdfasd schrieb: > Ne einfache TCP-Verbindung aufmachen und Daten austauschen geht mit > winsock doch genau so wie unter Linux - die Funktionen heißen nur etwas > anders. Windows implementiert berkeley sockets. Für die socket-API sind sie sogar ausnahmsweise vom Großbuchstaben am Anfang der Funktion abgerückt. Die Funktionen heißen also nicht etwas anders sondern genau gleich - der einzige Unterschied ist, dass man vorher WSAStartup callen muss.
Naja, ähnlich ;-) Man muss schon einiges ändern: aus dem Kopf (ist schon ne Weile her): WSAStartup/WSACleanup am Anfang/Ende, nen Socket ist kein int, statt read/write/close recv/send/closesocket, anderes Errorhandling.
asdfasd schrieb: > nen Socket ist kein > int, Doch, mit Pointerbreite.
1 | typedef UINT_PTR SOCKET; |
> statt read/write/close recv/send/closesocket
Bei read/write stimmt es schlicht nicht, die sind POSIX und gibt es
dementsprechend auch. recv/send sind auch Teil der Berkeley API und
sollten auch unter Unix verwendet werden, dafür sind sie ja da.
closesocket statt close ist tatsächlich der einzige Unterschied.
Christian R. schrieb: > Solange es kein mfc Programm ist (was man bei Konsole so gut wie nie > braucht) sind da auch keine Abhängigkeiten zu vc runtimes. MFC geht eh > nur in der Bezahlversion. Abhängigkeiten von irgendwelchen Runtimes sind auch bei MFC-Programmierung nicht nötig; man kann den Kram auch statisch linken. Und MFC-Unterstützung ist auch in der kostenlosen "Community Edition" enthalten, die der kastrierten "Express"-Version in mehreren Punkten deutlich überlegen ist. Andererseits würde ich niemandem, der heute anfängt, Windows-Programme zu schreiben, dazu raten, das mit der MFC zu machen. Da gibt es schönere Alternativen. Andererseits wollte der Threadstarter in C programmieren, da ist die MFC (wie jede ander C++-Klassenbibliothek) eh' nicht relevant. Socket-Programmierung ist auch mit der nativen Win32-API möglich, es gibt keinen Grund, nur deswegen den Linux-Emulator "Cygwin" zu verwenden.
Andi schrieb: > Leider ist es ein wenig (ok, viel) zu langsam Sorry fuer den Einwand, aber: Vielleicht solltest du mal schauen wo es da genau klemmt, anstatt dasselbe Problem ein zweitesmal zu loesen. In Python faellt es viel schneller auf, wenn ein Algorithmus schlecht implementiert ist, als in C/C++. Kannst du mal etwas Code zeigen? Dann kann man dir viel besser helfen. Darueberhinaus geht die meiste Zeit des Pythoninterpreters dafuer drauf, festzustellen, welchen Typ die Variablen denn so haben. Du koenntest dir auch mal Cython anschauen: Python mit statischen Typinformationen. Dann kannst du wenigstens deinen Pythoncode nutzen und musst den nur etwas umbauen, anstatt alles in einer anderen Sprache neu schreiben zu muessen. Cython: http://cython.org/ Andi schrieb: > Cross-Entwicklung (mingw, cygwin)? > Oder gleich unter Windows entwickeln (einfache IDE)? Wenn du es unbedingt mit C/C++ machen willst: C/C++ mit Qt und dem QtCreator. Der Qt-Installer bringt dir Mingw mit. Wenn du magst kannst du dir auch Clang als Compiler installieren. Toolchain tauschen ist in QtCreator kein Problem.
Andi schrieb: > Könnt ihr mir einen einfachen Weg für meine Zwecke weisen? > Cross-Entwicklung (mingw, cygwin)? > Oder gleich unter Windows entwickeln (einfache IDE)? Commandline, was willst du mit cygwin. Hole dir das kostenlose Visual Studio Community Express von Microsoft und sage Datei Neu Projekt C++ Win32 Commandline und schreibe deinen Code, falls dir C++ zu kompliziert ist kannst du auch C als Dateinamenerweiterung eintragen. Python ist auch drin, willst du aber nicht noch mal. Nicht jede Library, die du unter Phython genutzt hast, ist gleich dabei, aber eventuell war ja auch die Nutzung der mächtigen vorgefertigten Funktionen das Problem warum es langsam wurde. Kaj G. schrieb: > Wenn du es unbedingt mit C/C++ machen willst: > C/C++ mit Qt und dem QtCreator. Völliger Quatsch, er will ein Commandline-Programm, keine Windows-Oberfläche.
:
Bearbeitet durch User
Andi schrieb: > Leider ist es ein wenig (ok, viel) zu langsam, ich werde es also in C > neu schreiben. Bist du dir sicher, dass du das nicht einfach nur falsch machst? Gerade bei Python kann man als alter C Programmierer viel in der Performance versauen. Viele Dinge werden in Python anders gelöst und sind im C-Style deutlich langsamer.
hat noch keiner lcc gesagt? http://www.cs.virginia.edu/~lcc-win32/ mit lcc32 habe ich schon gute Erfahrungen gemacht
Michael B. schrieb: > Völliger Quatsch, er will ein Commandline-Programm, keine > Windows-Oberfläche. Auch das geht ganz wunderbar mit dem QtCreator. Oh, und die Oberflaeche koennte man sogar unter Linux nutzen. Wenn man keine Ahnung hat, einfach mal Kresse halten!
Felix U. schrieb: > Bei read/write stimmt es schlicht nicht, die sind POSIX und gibt es > dementsprechend auch. Die funktionieren allerdings unter Windows nicht auf Sockets. > recv/send sind auch Teil der Berkeley API und sollten auch unter Unix > verwendet werden, dafür sind sie ja da. Sowohl read()/write() als auch recv()/send() sind erlaubt, denn auch Sockets sind FDs. Es kann sogar passieren, dass stdin und stdout Sockets sind, z.B. beim Start durch inetd.
Andi schrieb: > Könnt ihr mir einen einfachen Weg für meine Zwecke weisen? Bin jetzt so eher der embedded C Gelegenheitsprogger aber vielleicht hilft es: Für Windows nutze ich Pelles C Compiler. Ist so schön simpel und für Commandline gibt es eine Vorlage.
Erstmal danke für die vielen Varianten ... viele Wege führen nach Rom ;) Habe jetzt viel Lesestoff für die nächsten Tage. cython und pypy werde ich auf jeden Fall mal ausprobieren. nicht"Gast" schrieb: > Bist du dir sicher, dass du das nicht einfach nur falsch machst? Ha! Nein natürlich nicht. Andersrum: Ich bin mir sicher, dass ich in python vieles falsch mache ;) > Gerade bei Python kann man als alter C Programmierer viel in der > Performance versauen. Viele Dinge werden in Python anders gelöst und > sind im C-Style deutlich langsamer. Da gebe ich dir 100%ig recht. Mein ständiger Kampf wenn ich mit python arbeite ;) Trotzdem mag ich die Sprache recht gerne... Allerdings ist gerade der kritische Teil sehr einfach gestrickt. Zur Erklärung: Es ist eine relativ einfache Server-Client Applikation. Der Server läuft auf einer Arm mit FreeRTOS und lwip im Raw-Modus. Der Client auf einem PC und eben momentan in Python. Client: - Daten aus Datei auslesen - Daten senden. - Empfangene Daten einlesen. - Und in eine andere Datei schreiben. Zur Simulation habe ich einen einfachen Server auch in Python am Laufen: - Daten empfangen und gleich wieder senden (quasi Echomodus) Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec. Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec. Momentan ausreichend, da die Zielhardware aktuell nicht mehr als 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern ;)
Windows 10 enthält ein komplettes Linux Subsystem, man muss es nur aktivieren. Ich arbeite aber trotzdem immer noch mit Cygwin weil Openssh in diesem neuen Subsystem nur eingeschränkt funktioniert.
asdfasd schrieb: > Ich verstehe nicht, warum immer wieder Cygwin empfohlen wird - das > Teil ist nen einziger Hack. Zum Entwickeln mag ich das ganz gerne, insbesondere weil ich nicht dauernd Linux hochfahren muß, nur um zu checken, ob es auch mit Linux durchcompiliert. Und ich habe keine Lust, dafür jetzt mit VMs herumzufummeln. Außerdem bietet Cygwin auch GDB im Terminal, den ich hin und wieder mal nutze. Meistens bei vertrackten Segfaults, deren Ursache nicht auf Anhieb ersichtlich ist. Eine Einschränkung bei Cygwin ist allerdings, daß die sanitizer-Optionen von GCC nicht funktionieren. Das geht nur mit nativem Linux. Schade eigentlich, denn die sind für Test/Debug-Runs sehr nützlich. Oder auch, um mal eben schnell kleinere Linuxprogramme ans Laufen zu bringen.
Tcp-Verbindungen in Windows geht relativ einfach mit Visual Studio mit dem WinPcap-Treiber.https://www.winpcap.org/ Für daten lesen gibts jede Menge Beispiele vür MS Vs
Stefan U. schrieb: > Windows 10 enthält ein komplettes Linux Subsystem, man muss es nur > aktivieren. Ich arbeite aber trotzdem immer noch mit Cygwin weil > Openssh in diesem neuen Subsystem nur eingeschränkt funktioniert. Tolle Info! Hier steht mehr: https://msdn.microsoft.com/de-de/commandline/wsl/install_guide
Andi schrieb: > Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec. > Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec. > > Momentan ausreichend, da die Zielhardware aktuell nicht mehr als > 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren > 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um mich Nichtigkeiten widmen zu können :) War kein Witz. ich bin wirklich neidisch.
asdfasd schrieb: > Naja, ähnlich ;-) Man muss schon einiges ändern: aus dem Kopf (ist schon > ne Weile her): WSAStartup/WSACleanup am Anfang/Ende, nen Socket ist kein > int, statt read/write/close recv/send/closesocket, anderes > Errorhandling. Socket-Programme so zu schreiben, dass sie sowohl mit Win32 als auch mit Linux funktionieren ist dennoch kein echtes Problem.
Andi schrieb: > Zur Erklärung: Es ist eine relativ einfache Server-Client Applikation. > Der Server läuft auf einer Arm mit FreeRTOS und lwip im Raw-Modus. > Der Client auf einem PC und eben momentan in Python. > > Client: > - Daten aus Datei auslesen > - Daten senden. > - Empfangene Daten einlesen. > - Und in eine andere Datei schreiben. > > Zur Simulation habe ich einen einfachen Server auch in Python am Laufen: > - Daten empfangen und gleich wieder senden (quasi Echomodus) > > Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec. > Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec. Arbeitest du mit dem threading-Modul? Falls ja: Tausch das mal mit dem multiprocessing-Modul. Das threading-Modul laeuft immer im Kontext des Pythoninterpreters, die Threads koennen vom OS nicht auf verschiedene Kerne aufgeteilt werden. Mit dem multiprocessing-Modul geht das. Am Anfang einmal die Datei einlesen und dann: 1. Prozess: Daten senden 2. Prozess: Daten empfangen 3. Prozess: Daten in Datei schreiben Zur Kommunikation zwischen den Prozessen kannst du Pipes oder Queues nutzen: https://docs.python.org/3.6/library/multiprocessing.html#pipes-and-queues
Andi schrieb: > - Dateien schreiben/lesen/manipulieren > - Daten über TCP-sockets schicken und empfangen (als Client). Ich würde für sowas auf jeden Fall noch Go als Sprache in Erwägung ziehen. Das ist fast so schnell wie C, hat eine mächtige Standard-Library und cross-compiling funktioniert auch tadellos. Alles landet in einer einzigen Binary (inkl. der Runtime), ohne dass du irgendwelche externen DLLs oder eine JVM benötigst. Coroutinen für asynchrone IO sind ebenfalls mit dabei, so dass man relativ einfach Prozesse parallelisieren kann. Die Sprache an sich ist trotzdem sehr schlank und wenn du Python magst und C kennst, dann wird dir Go sicher gefallen.
Skyper schrieb: > Ich werfe mal C++ mi Qt ins Rennen... Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine reine Konsolenanwendung? > Nachteil: > - Das Framework ist schon ziemlich "fett" > - Nicht wirklich "Keep it simple" *Ein GUI-Framework für eine Konsolenanwendung?*
Andi schrieb: > Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec. Wenn Du eher kleine Frames versendest, ist das vollkommen normal, denn dann steigt der Overhead des Protokolls. > Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec. Wenn Du mehr zu Deiner Applikation und Deinem Protokoll sagen kannst, wird das sicher helfen. > Momentan ausreichend, da die Zielhardware aktuell nicht mehr als > 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren > 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern > ;) Naja, wenn Du entsprechend viele Sensoren hast, und je nachdem, was Du auf diesem PC machst... Wie gesagt: vielleicht sagst Du mal ein bisschen mehr über Anwendungsfall, Applikation, und Protokoll. ;-)
Nop schrieb: >> ... Cygwin ... > > Zum Entwickeln mag ich das ganz gerne, insbesondere weil ich nicht > dauernd Linux hochfahren muß, nur um zu checken, ob es auch mit Linux > durchcompiliert. Und ich habe keine Lust, dafür jetzt mit VMs > herumzufummeln. > > Außerdem bietet Cygwin auch GDB im Terminal, den ich hin und wieder mal > nutze. Docker?!
> Widerspruch! C++, na klar -- aber ein GUI-Framework wie > Qt für eine reine Konsolenanwendung? Und schon wieder jemand, der Qt nur als GUI Framework kennt. Tatsächlich ist die Qt GUI Komponente ein optinaler Teil von Qt. Die anderen Komponenten kann man sehr gut auf der Kommandozeile nutzen. Gerade für Netzwerk Anwendungen stellt Qt viele hilfreiche Sachen bereit. Das Tutorial von meinem Webserver zeigt, wie man Qt in Konsole Anwendungen nutzt: http://stefanfrings.de/qtwebapp/index.html Das Framework ist übrigen nicht "ziemlich fett". Die Java Runtime und .NET sind wesentlich umfangreicher. Abgesehen davon insteressiert das heutzutage niemanden mehr, der Geld für Softwareentwicklung ausgibt. In den 90er Jahren gab es mal eine Firma, die haben es geschafft, ein Unix ähnliches Betriebssystem mit grafischem Desktop, Dateimanager, Email Client und Web Browser auf nur 2 Disketten zu packen. Das war damals noch cool, heute interessiert es niemanden mehr. Wir leben in einer Zeit, wo handelsübliche Mikrocontroller (keine Exoten) schon mit 1MB internem Flash Speicher zu haben sind und bei PC's zig MB für UEFI verballert werden. Fotos werden standarmäßig mit 12Megapixel und geringer Kompression gespeichert und bei Webseiten scheint es keine Sau mehr zu interessieren, ob der Download einer einzelnen Seite ein paar zig kB oder 2MB umfasst. Die Maßeinheit "kiloByte" verliert an Bedeutung. Viele Laien wissen nichtmal, was das bedeutet. Sie kennen nur Megabytes und Gigabytes.
Sheeva P. schrieb: > Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine > reine Konsolenanwendung? Ich haette gedacht, dass gerade Du es besser weisst :( Man muss damit doch keine GUI basteln. Die Klassen (Netzwerk, Seriell, Bluetooth, usw.) kann man doch auch ganz ohne GUI nutzen. Beispiel: Qt Serial Port Examples - Command Line Enumerator Example http://doc.qt.io/qt-5/qtserialport-cenumerator-example.html
> Client: > - Daten aus Datei auslesen > - Daten senden. > - Empfangene Daten einlesen. > - Und in eine andere Datei schreiben. > > Zur Simulation habe ich einen einfachen Server auch in Python am Laufen: > - Daten empfangen und gleich wieder senden (quasi Echomodus) dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon kann. Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und Binary (Testaufwand)? Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich?
Felix U. schrieb: > Windows implementiert berkeley sockets. Für die socket-API sind sie > sogar ausnahmsweise vom Großbuchstaben am Anfang der Funktion abgerückt. > Die Funktionen heißen also nicht etwas anders sondern genau gleich - der > einzige Unterschied ist, dass man vorher WSAStartup callen muss. Es gibt schon noch ein paar mehr Unterschiede. Beispielsweise heißt es ioctlsocket() statt ioctl(). select() funktioniert im Gegensatz zu Unix nur mit Sockets und nix anderem. Fehlerhandling ist auch anders: Bei den original Berkley-Sockets bekommt man den Fehler in errno, bei Windows muss man WSAGetLastError() aufrufen, und auch die Bezeichnungen für die Fehler heißen allesamt anders. Kaj G. schrieb: > Man muss damit doch keine GUI basteln. Die Klassen (Netzwerk, Seriell, > Bluetooth, usw.) kann man doch auch ganz ohne GUI nutzen. Ja, und man muss die GUI-Lib von Qt dann auch gar nicht erst dazulinken. Seit Qt4 (oder war es schon bei Qt3?) ist es schließlich nicht mehr eine einzelne große Bibliothek, sondern in mehrere Komponenten aufgeteilt (wie z.B. Core, Netzwerk, XML, GUI, SQL, Webbrowser, Multimedia u.s.w.). Stefan U. schrieb: > Das Tutorial von meinem Webserver zeigt, wie man Qt in Konsole > Anwendungen nutzt: http://stefanfrings.de/qtwebapp/index.html Wichtig für Konsolen-Anwendungen sind dabei, wenn man QMake benutzt, die Einstellungen:
1 | QT -= gui |
2 | CONFIG += console |
Das erste sorgt dafür, dass keine GUI-Bibliothek gelinkt wird, das zweite dafür, dass es auch als Konsolen-Anwendung gebaut wird (da Windows da ja aus unverständlichen Gründen Unterschiede macht).
Andi schrieb: > Mit diesen Programmen schaffe ich via localhost gerade mal 500Mbit/sec. > Client und Server auf unterschiedlichen PCs kommen auf max. 200Mbit/sec. Sende einfach mal Testdaten aus dem RAM, Ohne Datei -öffnen, -lesen Ebenso brauchst du die empfangenen Daten nicht abspeichern. Wird es dadurch schneller? Bei http://www.zotteljedi.de/ gibt es auch viele Informationen zu sockets.
nicht"Gast" schrieb: > Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um > mich Nichtigkeiten widmen zu können :) > War kein Witz. ich bin wirklich neidisch. Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit bezeichnen kannst, bin ich neidisch auf Deinen Job ;) Kaj G. schrieb: > Arbeitest du mit dem threading-Modul? >... > Mit dem multiprocessing-Modul geht das. Nein, ich habe bisher nur ein paar Versuche mit coroutinen und asyncio gemacht. Dabei hatte ich allerdings das Problem dass ich das Senden und Empfangen nicht auf 2 Routinen aufsplitten konnte. Ja, da waren sie wieder meine Python-Schwächen ;) Aber eigentlich brauche ich das nicht, da die Datenmenge in beide Richtungen identisch ist. Ich muss also nur dafür sorgen dass die Zielhardware ein wenig mehr Daten kriegt um die Latenzzeiten auszugleichen. Sheeva P. schrieb: > Wenn Du eher kleine Frames versendest, ist das vollkommen normal, denn > dann steigt der Overhead des Protokolls. Das ist klar. Aber auch wenn ich grössere Frames nehme steigt der Durchsatz nicht wirklich großartig an. > Naja, wenn Du entsprechend viele Sensoren hast, und je nachdem, was Du > auf diesem PC machst... Wie gesagt: vielleicht sagst Du mal ein bisschen > mehr über Anwendungsfall, Applikation, und Protokoll. ;-) Am PC passiert sonst nicht wirklich wesentliches mit den Daten. Die eigentlich Arbeit macht die Zielhardware. Kommandozeile vor dem Frühstück für Alle! schrieb: > dieser Beschreibung nach also nichts was NetCat (nc.exe?) nicht schon > kann. Für diesen Test hätte nc wahrscheinlich gereicht (wenn ich daran gedacht hätte) ;) > Warum also doch eigene Quellcode (Erstellungs- & Wartungsaufwand) und > Binary (Testaufwand)? Soo aufwändig war das Erstellen der Testprogramme unter Linux nicht wirklich. Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;) > Und: wie schlägt sich nc durchsatzmässig denn so im Vergleich? Meine kleinen C-Programme unter Linux in einer VBOX zeigen dass ich schnell genug werde. Tests auf einer echten Linuxmaschine stehen allerdings noch aus. Aber wenns in der VBOX schon reicht, sollte es mit nativen Windowsprogrammen erst recht klappen. Ich mag Python aber trotzdem noch nicht aufgeben und werde meine Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen. Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und meine Lücken aufdecken;) Wird aber ein paar Tage dauern... Danke einstweilen noch einmal für die vielen Anregungen!
Ich habe vor >10 Jahren mal Code geschrieben, der TCP Zeug macht und sich im Visual Studio und mit dem gcc kompilieren lässt. Als Anhang ein Tool, das Daten aus einer TCP Verbindung liest und in eine Datei schreibt. Das ganze mit select() und so. Ist von 2014, der olle Code funktionierte immer noch :) in scanner.c wird die Winsock initialisiert/runtergefahren, ansonsten in s400w ein bissel was mit #ifdef (oopensocket) umgebogen. select() selber ist für Windows und Unix identisch.
Andi schrieb: > nicht"Gast" schrieb: >> Ach ja, ich hätte echt gerne auch mal wieder so viel Zeit auf Arbeit um >> mich Nichtigkeiten widmen zu können :) >> War kein Witz. ich bin wirklich neidisch. > > Wenn du das Erreichen der Projekt-Zielvorgaben als Nichtigkeit > bezeichnen kannst, bin ich neidisch auf Deinen Job ;) Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was von 50 MBit geschrieben, die der Controller kann. Welche Geschwindigkeiten sollst du denn erreichen?
Gibt es für Python eigentlich einen Profiler, dass man schauen kann, wo die Zeit verloren geht?
nicht"Gast" schrieb: > Das deine Vorgaben strenger sind konnte ja keiner Ahnen. Du hattest was > von 50 MBit geschrieben, die der Controller kann. > > Welche Geschwindigkeiten sollst du denn erreichen? Ich habe geschrieben 'aktuell': Andi schrieb: > Momentan ausreichend, da die Zielhardware aktuell nicht mehr als > 50Mbit/sec verarbeiten kann, aber die theoretisch erreichbaren > 500Mbit/sec sollten, wenn möglich, nicht am dicken fetten PC scheitern ;) Das heißt dass die Jungs in der Hardwareabteilung auch noch Gas geben müssen (und das auch tun) ;)
Wenn's spartanisch sein darf und 32-bit reichen: http://www.delorie.com/djgpp/ (größere Projekte würde ich damit nicht aufsetzen wollen, aber für quick&dirty ausreichend)
Kaj G. schrieb: > Sheeva P. schrieb: >> Widerspruch! C++, na klar -- aber ein GUI-Framework wie Qt für eine >> reine Konsolenanwendung? > Ich haette gedacht, dass gerade Du es besser weisst :( Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres Handling im Zusammenspiel mit den GUI-Teilen zu haben. Die andere Alternative wäre wohl gewesen, die damals bereits vorhandenen Teile von Qt an die STL anzupassen.
Andi schrieb: > Die Entscheidung ist doch: Kann ich mit Python weiterarbeiten oder muss > ich auf C umsteigen. Beides parallel zu machen habe ich nicht vor ;) Dabei ist das gar nicht so schwierig. Du könntest - die lahmen Teile Deines Python-Programms durch eine Extension ersetzen, die wahlweise in C (siehe Python-Dokumentation oder Cython) oder in C++ (siehe dazu die C++-Bibliothek boost::python) geschrieben sein kann - Dein Python-Programm mit nuitka in C++ und darüber in nativen Code übersetzen - einen anderen Python-Interpreter wie Jython oder Pypy benutzen > Ich mag Python aber trotzdem noch nicht aufgeben und werde meine > Programme aufräumen, aufs wesentlich reduzieren und hier reinstellen. > Vielleicht mag ja einer der Pythonspezialisten mal drüberschauen und > meine Lücken aufdecken;) Wahrscheinlich wäre es nicht die schlechteste Idee, zunächst einmal die Performanceengpässe in Deinem Code zu identifizieren, sprich: einen der vorhandenen Python-Profiler oder ggf. gprof zu benutzen.
Für mich als hauptsächlicher Java Programmierer fühlt sicht Qt viel gewohnter an, als stl. Das ist bei mir der Hauptgrund, warum ich es gerne nutze. > vor allem deswegen hineingebaut wurden, um ein konsistenteres, > einfacheres Handling im Zusammenspiel mit den GUI-Teilen zu haben. Ja das sehe ich auch so. Ich kenne Qt seit Version 1.irgendwas. Allerdings ist das kein nachteil (mehr). Da sind viele nützliche Sachen drin, die abseits der GUI prima funktionieren. Der Verzicht auf die GUI macht hier nichts komplizierter, als nötig.
Type Pun Intended schrieb: > Gibt es für Python eigentlich einen Profiler, dass man schauen kann, wo > die Zeit verloren geht? Liefert Python mit: 27.4. The Python Profilers https://docs.python.org/3.6/library/profile.html#the-python-profilers Karl Käfer schrieb: > Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist > und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor > allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres > Handling im Zusammenspiel mit den GUI-Teilen zu haben. Und das spielt was fuer eine Rolle? Es gibt Module, die man ohne GUI verwenden kann. Fertig. Warum es diese Module in dem Framework gibt, ist doch voellig schnuppe. Sie sind da, und man kann sie verwenden. Und die Qt Doku ist, verglichen mit anderen Frameworks, wirklich erstklassig.
Ich denke, er wollte nur den historischen Grund nennen, warum Qt häufig noch als GUI Framework bezeichnet wird.
Kaj G. schrieb: > Karl Käfer schrieb: >> Trotzdem ist es am Ende so, daß Qt im Wesentlichen ein GUI-Framework ist >> und die Non-GUI-Teile, auch wenn man sie standalone verwenden kann, vor >> allem deswegen hineingebaut wurden, um ein konsistenteres, einfacheres >> Handling im Zusammenspiel mit den GUI-Teilen zu haben. > > Und das spielt was fuer eine Rolle? Es gibt Module, die man ohne GUI > verwenden kann. Fertig. Richtig... aber um die zu benutzen, darf man sich erstmal durch n "Getting Started"-Tutorials fräsen, deren wesentliche Gemeinsamkeit was ist? Genau: die Entwicklung von grafischen Benutzeroberflächen. Insofern sind die betreffenden Module zwar vorhanden, und ein erfahrener Qt-Entwickler kann und wird sie vielleicht benutzen oder vielleicht auch nicht. Aber sich zunächst einmal in ein GUI-Framework einzuarbeiten, um letztlich dann doch mit einzelnen Bibliotheken daraus eine kleine CLI-Applikation zu schreiben: solange man nicht vorhat, das erworbene Wissen noch anderweitig zu nutzen oder die Sache eher als Selbstzweck betreibt, erscheint mir das nicht besonders zielführend. Im Übrigen scheint mir, daß die klassischen GUIs langsam aussterben. Viele Anwendungen, die man vor zehn Jahren mit einer GUI gemacht hätte, werden heutzutage als Web-GUIs umgesetzt -- oft sogar lokale. In Unternehmen, wo Applikationen am Liebsten zentral deployt, gepflegt und verwaltet werden, sind klassische GUIs häufig sogar ein KO-Kriterium, wenn ein Wettbewerber eine schicke WebApp anbietet. Insofern stellt sich je nach Umfeld ohnehin die Frage, wie sinnvoll es heute noch ist, sich in ein umfangreiches GUI-Framework einzuarbeiten. YMMV. ;-)
Karl Käfer schrieb: > Wahrscheinlich wäre es nicht die schlechteste Idee, zunächst einmal die > Performanceengpässe in Deinem Code zu identifizieren, sprich: einen der > vorhandenen Python-Profiler oder ggf. gprof zu benutzen. Korrekt. Ergänzend dazu möchte ich auf den wichtigsten Merksatz zum Thema Performanceoptimierung hinweisen: "Measure, don't guess" (Kirk Pepperdine).
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.