Muss hier innerhalb von ein paar (möglichst Milli-)Sekunden einige tausend Handles auslesen, und das schreit geradezu nach ASM.
Ich habe leider dein Tools bislang noch nie verwendet und will mich da jetzt (wenn möglich) bessern :-).
Als "Opa" hat man öfters mal Schwierigkeiten, neue Sachen sofort komplett umzusetzen (und auf Anhieb zu kapieren ), bitte also nicht wundern, wenn ich vorneweg ein paar Grundsatzfragen stelle, die eigentlich schon lange klar sein sollten...
1.) Muss ich unbedingt IF's Precompiler für XPIA verwenden? Ich mache ja etwas speziellere Sachen, bei denen ich oft tricksen muss, damit die mit Profan überhaupt laufen. IF's Precompiler macht mir einfach zuviel - ich kann da nicht genau beurteilen, ob der mir meine Tricksereien wieder wegbügelt und warum dann mancher Code evtl. nicht läuft. Was brauche ich als "Minimalvoraussetzung" für Inline Assembling und wie wende ich das zusammen an?
XPIA - was brauche ich
-
-
-
Vielleicht informierst Du Dich einfach an Ort und Stelle.
http://xprofan.com/xpse - sogar mit Peters Einbauanleitung.
Ob und wie XPIA auch ohne XPSE gangbar gemacht werden kann, weiss ich jedoch nicht - aber nach einmaligem ENH-Datei-erstellen und Betrachten dieser, sollten sich alle Fragen in Luft aufgelöst haben.
-
Hallo Opa,...schau dir mal die Xpia-Beispiele an oder du nimmst Profan2Cpp. Macht ein Windhund aus deinem Programm.
Ich bin jetzt auch schon über 60zig, dann wirst du es wohl auch noch begreifen.:-)
Du wirst doch nicht schon bald ins "Grass beissen..."
Hält fit.... -
Zitat
Muss ich unbedingt IF's Precompiler für XPIA verwenden?
Nein, das ist nicht zwingend nötig. XPSE wird nur als Precompiler benötigt, um Hauptprogramm und Include-Dateien zusammen zu führen. Wenn du nur einen Hauptcode benutzt oder z.B. Pre.exe von meiner Seite für den Zusammenbau verwendest und XPIA manuell aufrufst oder per Batch, kannst du auf XPSE durchaus verzichten.
XPIA erwartet als Übergabeparameter einen String auf einen Quellcode-Namen. Aber arbeite bitte nur mit einer Kopie, weil die Datei in der Regel umgeschrieben wird!ZitatAls "Opa" hat man öfters mal Schwierigkeiten, neue Sachen sofort komplett umzusetzen (und auf Anhieb zu kapieren ), bitte also nicht wundern, wenn ich vorneweg ein paar Grundsatzfragen stelle, die eigentlich schon lange klar sein sollten...
Da du MASM32 beherrscht, solltest du keine Schwierigkeiten bekommen, weil XPIA 100% kompatibel dazu ist. Du kannst auch eigene Libraries/Includes einbauen, indem du die "Basis.inc" im Include-Ordner entsprechend anpasst, so wie ich es für mich auch immer mache.
Ich baue fast alle zeitintensiven Passagen meiner Programme in Assembler.Geplant ist eine neue XPIA-Version, die ohne MASM32 und XPSE auskommt und trotzdem 99% kompatibel zu den vorhandenen Codes ist. Momentan komme ich aber einfach nicht dazu.
-
Zitat von Frabbing;696356
Wenn du nur einen Hauptcode benutzt oder z.B. Pre.exe von meiner Seite für den Zusammenbau verwendest und XPIA manuell aufrufst oder per Batch, kannst du auf XPSE durchaus verzichten.
Danke, das wollte ich wissen. Habe PRE.EXE noch nicht heruntergeladen - wird da erklärt, wie man PRE.EXE zusammen mit XPIA verwendet?
Zitat von Frabbing;696356
Da du MASM32 beherrscht,
Na ja, zum Treiberschreiben reichts gerade so - zu mehr bin ich noch nicht gekommen.
Zitat von Frabbing;696356
solltest du keine Schwierigkeiten bekommen, weil XPIA 100% kompatibel dazu ist.
Es geht mir da eher um das "Zusammenspiel" von ASM und Profan - Übergabe von Daten zum Beispiel. Werde da noch ein paar Fragen an dich haben, dann wird's für mich einfacher. Werde erst mal schauen, ob ich mit dem Paket zurechtkomme.
Zitat von Frabbing;696356
Du kannst auch eigene Libraries/Includes einbauen, indem du die "Basis.inc" im Include-Ordner entsprechend anpasst, so wie ich es für mich auch immer mache.
Eine Frage ist schon beantwortet.
Zitat von Frabbing;696356Geplant ist eine neue XPIA-Version, die ohne MASM32 und XPSE auskommt und trotzdem 99% kompatibel zu den vorhandenen Codes ist. Momentan komme ich aber einfach nicht dazu.
Schade - kenne das aber. Schiebe manche Sachen auch Jahrelang vor mir her. -
Zitat von profanfan;696295
Hallo Opa,...
Hallo Enkel...Zitat von profanfan;696295
schau dir mal die Xpia-Beispiele an
NICHT SO SCHNELL - bin erst beim Precompiler .Zitat von profanfan;696295
oder du nimmst Profan2Cpp. Macht ein Windhund aus deinem Programm.
Der Windhund ist bei mir eingeschlafen - ist eher langsamer mit Profan2Cpp. Desweiteren macht es meine Tricksereien in diesem Fall nicht mit.Zitat von profanfan;696295
Ich bin jetzt auch schon über 60zig, dann wirst du es wohl auch noch begreifen.:-)
Der geistige Abbauprozess macht sich bei mir schon stark bemerkbar - muss alles sehr einfach haben 8O.Zitat von profanfan;696295
Du wirst doch nicht schon bald ins "Grass beissen..."
Das sagt meine Frau auch immer zu mir - besonders wenn ich mal wieder ein Baugerüst nicht über die Leiter, sondern über die äußeren Verstrebungen hochklettere :(.Zitat von profanfan;696295
Hält fit....
Trage jeden Tag 13 Stunden lang Gewichte zwischen 40kg und 120kg allein (ohne mich dabei großartig anzustrengen) durch die Gegend (Spitzname King Kong :() - vielleicht hält das ja auch fitt . -
Desweiteren macht es meine Tricksereien in diesem Fall nicht mit.
Du solltest lernen, übersichtlich zu proggen, dann geht alles wie "von selbst" und man kann die Fehlermeldungen besser auswerten.
Ich wüsste nicht, das der Cpp-Code langsamer ist, ausser man baut fehler ein;)
Ich progge mit Profan 11.2, baue dort ASM-Code ein:
Code
Alles anzeigen........ dim b#,groesse&,z& ........ If 0 AsmStart rgb_farbe Parameters b#,groesse& LOCAL r :BYTE LOCAL g :BYTE LOCAL b :BYTE LOCAL n :DWORD mov eax,para2 mov n,eax mov ecx,0 mov ebx,para1 .while ecx<=n mov al,[ebx+ecx] mov r,al mov al,[ebx+ecx+1] mov g,al mov al,[ebx+ecx+2] mov b,al mov al,b .if al>252 mov eax,255 .break .endif mov al,g .if al>252 mov eax,255 .break .endif mov al,r .if al>252 mov eax,255 .break .endif add ecx,4 .endw AsmEnd(z&) ' der Rückgabewert ist in "eax" endif .......
und rufe diese Routine so auf, mit Rückgabewert z& :
Dann lasse ich das ganze mit Profan2Cpp compilieren, kann jauch mit XPIA/Xpse zusammenarbeiten,
schneller gehst nimmer....mfg
-
Der geistige Abbauprozess macht sich bei mir schon stark bemerkbar - muss alles sehr einfach haben....
Macht wohl das Bier auf dem "Bau"...,wie?
Der schlechte "Ruf" eilt immer vorraus..., ohne Bier kein "Hausbau"...
mfg
-
Zitat von profanfan;696453
Desweiteren macht es meine Tricksereien in diesem Fall nicht mit.
Du solltest lernen, übersichtlich zu proggen, dann geht alles wie "von selbst" und man kann die Fehlermeldungen besser auswerten.
Das hat mit dem zu tun, was ich mit der Sprache schreibe, nicht wie - und was funktionieren soll, auch wenn es normalerweise gar nicht geht - zum Beispiel eine Art "Multithreading".Zitat von profanfan;696453
Ich wüsste nicht, das der Cpp-Code langsamer ist, ausser man baut fehler ein;)
Sei froh, jetzt weißt du's ja, dass es solche Dinge geben kann.Zitat von profanfan;696453
Ich progge mit Profan 11.2, baue dort ASM-Code ein:
Code
Alles anzeigen........ dim b#,groesse&,z& ........ If 0 AsmStart rgb_farbe Parameters b#,groesse& LOCAL r :BYTE LOCAL g :BYTE LOCAL b :BYTE LOCAL n :DWORD mov eax,para2 mov n,eax mov ecx,0 mov ebx,para1 .while ecx<=n mov al,[ebx+ecx] mov r,al mov al,[ebx+ecx+1] mov g,al mov al,[ebx+ecx+2] mov b,al mov al,b .if al>252 mov eax,255 .break .endif mov al,g .if al>252 mov eax,255 .break .endif mov al,r .if al>252 mov eax,255 .break .endif add ecx,4 .endw AsmEnd(z&) ' der Rückgabewert ist in "eax" endif .......
und rufe diese Routine so auf, mit Rückgabewert z& :
Dann lasse ich das ganze mit Profan2Cpp compilieren, kann jauch mit XPIA/Xpse zusammenarbeiten,
schneller gehst nimmer....
mfg
Danke, das hilft schon.
Zitat von profanfan;696455Der geistige Abbauprozess macht sich bei mir schon stark bemerkbar - muss alles sehr einfach haben....
Macht wohl das Bier auf dem "Bau"...,wie?
Nö, eigentlich arbeite ich da nie.
Bin eher im medizinisch pflegerischen Bereich tätig.:-)Zitat von profanfan;696455
Der schlechte "Ruf" eilt immer vorraus..., ohne Bier kein "Hausbau"...
mfg
An meinem Haus baue ich eigentlich nur in meiner Freizeit. Bin eher jemand, der noch nicht mal Alkohohl besonders gut verträgt . Es liegt also nicht am Alkohol, sondern eher wohl am Alter. Ich lehne es als Opa eben komplett ab, mich geistig oder körperlich in irgendeiner Art und Weise besonders anzustrengen - egal ob ich nun irgendwelche Gewichte trage oder in der Sicherheitstechnik von Windows herumprogge - ich mache es mir so einfach wie möglich -ich denke mal, das sieht man auch an meinen Beiträgen hier. Wichtig ist, sich die Welt so einfach zu machen, dass man sie versteht - alles was man nicht verstanden hat, ist für das eigene Leben unwichtig und bedeutet nur einen Fallstrick, an dem man sich früher oder später das Genick bricht, wenn man damit umgeht.
Das ist genau so wie mit der Lebenserwartung - meine Frau sieht einfach nicht, dass ich mich generell nur mit Sachen beschäftige, die für mich komplett ungefährlich sind - bin ja kein Idiot . -
Zitat
Habe PRE.EXE noch nicht heruntergeladen - wird da erklärt, wie man PRE.EXE zusammen mit XPIA verwendet?
Nein, es ist ja ein eigenständiges Batch-Tool.
Du rufst einen Code auf und PRE kombiniert Hauptsource und alle seine Include-Dateien zu einem einzigen großen Code.Du könntest im Texteditor per Batch erst PRE aufrufen, dann XPIA und dann den Compiler/Linker, um zu deiner Exe zu kommen.
ZitatEs geht mir da eher um das "Zusammenspiel" von ASM und Profan - Übergabe von Daten zum Beispiel. Werde da noch ein paar Fragen an dich haben, dann wird's für mich einfacher. Werde erst mal schauen, ob ich mit dem Paket zurechtkomme.
Wenn die Parameterzahl dir nicht reichen sollte, kannst du jederzeit den Zeiger auf einen Speicher übergeben, in dem sich alles Mögliche befinden darf.
Frag einfach, wenn noch Fragen auftauchen sollten.
-
Zitat von Frabbing;696591
Frag einfach, wenn noch Fragen auftauchen sollten.
Danke, im Prinzip habe ich durch euch beide jetzt schon ein Bild davon, wie die Sache läuft - das brauchte ich für den Anfang erst mal. -
Ich wusste es.
-
Mal eine Randbemerkung: Wenn etwas mit Profan2Cpp nicht funktioniert, wäre ich für eine genauere Beschreibung sehr dankbar! Probleme, die ich nicht kenne, kann ich auch nicht beheben...
MfG
Sebastian
-
Sebastian: Ich konnte keine Stelle entdecken, an der ein Fehler von Profan2Cpp genannt wurde. Es wurde - glaube ich - nur gesagt, dass ein nach Cpp übersetzter Code nicht zwangläufig schneller läuft als der entsprechende XProfancode, was so ja auch stimmt. Als Beispiel möchte ich mal "Addfiles" angeben.
-
Zitat von Frabbing;697238
Sebastian: Ich konnte keine Stelle entdecken, an der ein Fehler von Profan2Cpp genannt wurde.
Genau.Zitat von Frabbing;697238
Es wurde - glaube ich - nur gesagt, dass ein nach Cpp übersetzter Code nicht zwangläufig schneller läuft als der entsprechende XProfancode, was so ja auch stimmt. Als Beispiel möchte ich mal "Addfiles" angeben.
Ja, die GDI Befehle laufen teilweise auch langsamer - zumindestens langsamer als in Profan 6. Die meisten Sachen laufen in Profan2CPP wirklich wesentlich schneller, aber eben nicht komplett alle - ich sehe das nicht als Fehler an.
Profan2CPP ist scheinbar genausowenig multithreadingfähig wie XProfan - das ist nun mal so. Die "Fehler" die dort entstehen, sind aber etwas anders gelagert, als die, die in Profan passieren - habe mich darum aber bislang nicht weiter gekümmert, sorry (siehe Timer Callback).
Habe noch Version 1.5a. Wenn du möchtest, schaue ich in meiner Version mal etwas genauer nach, müsste dafür aber noch sehr viel lernen und es kann deshalb dauern, bis ich dir so einigermaßen sagen kann, was da genau vor sich geht. -
Zitat von Frabbing;697238
Sebastian: Ich konnte keine Stelle entdecken, an der ein Fehler von Profan2Cpp genannt wurde. Es wurde - glaube ich - nur gesagt, dass ein nach Cpp übersetzter Code nicht zwangläufig schneller läuft als der entsprechende XProfancode, was so ja auch stimmt. Als Beispiel möchte ich mal "Addfiles" angeben.
Mir ging es jetzt vornehmlich um das hier:Zitat von AHTDesweiteren macht es meine Tricksereien in diesem Fall nicht mit.
Mit einer genaueren Beschreibung, was hinter diesen "Tricksereien" steckt, könnte ich mir die Sache mal vornehmen.
Bei AddFiles muss ich mal schauen - das ist ja komplett in den Bibliotheken implementiert. Ist meine Version da wirklich langsamer als Rolands?
MfG
Sebastian
-
Zitat von AHT;697269
Profan2CPP ist scheinbar genausowenig multithreadingfähig wie XProfan - das ist nun mal so. Die "Fehler" die dort entstehen, sind aber etwas anders gelagert, als die, die in Profan passieren - habe mich darum aber bislang nicht weiter gekümmert, sorry (siehe Timer Callback).
Habe noch Version 1.5a. Wenn du möchtest, schaue ich in meiner Version mal etwas genauer nach, müsste dafür aber noch sehr viel lernen und es kann deshalb dauern, bis ich dir so einigermaßen sagen kann, was da genau vor sich geht.
Profan2Cpp ist zumindest insoweit Multithreading-fähig, dass man im Gegensatz zu XProfan die Callback-Funktionen prinzipiell als ThreadProc benutzen kann. An einigen Stellen habe ich intern auch Anpassungen zum Multithread-Betrieb vorgenommen, ein offizielles Feature ist das ganze aber nicht. Und man muss natürlich sehr genau aufpassen, dass nicht mehrere Threads auf die gleichen Resourcen zugreifen... spontan fällt mir zum Beispiel ein, dass die Option "Alle Variablen global deklarieren" (die ohnehin nur als Holzhammer-Notnagel für bestimmte Codes gedacht ist) für Multithread-Programme nicht benutzt werden darf. Ansonsten komme ich auf das Angebot einer genaueren Problembeschreibung natürlich gern zurück!MfG
Sebastian
-
Zitat von sekoenig;697289
Ansonsten komme ich auf das Angebot einer genaueren Problembeschreibung natürlich gern zurück!
Wie gesagt, das wird leider dauern. Insgesammt habe ich den Verdacht, dass das gesammte Problem bei dir nicht so leicht zu beheben sein wird, wie bei Roland - da dürfte es einfach sein.
Kann aber gut sein, dass du da schon auf einem guten Weg bist - habe mir lange keine neue Version von Profan2Cpp angesehen. -
Zitat von sekoenig;697286
Mir ging es jetzt vornehmlich um das hier:
Mit einer genaueren Beschreibung, was hinter diesen "Tricksereien" steckt, könnte ich mir die Sache mal vornehmen.
Ich verwende einen Timercallback, um die Fenstergröße anzupassen, während gleichzeitig mehrere tausend Handles ausgelesen werden. In Profan nutze ich folgendes:
Ein Timercallback wird nur abgearbeitet, wenn Messages verarbeitet werden. Wo es in Profan dabei Probleme geben kann, ist bei allen Create und Control Klamotten. Warum? Da man Profans interne Messageverarbeitung abschalten kann, hat Roland in seiner "Virtual-Machine" eine Delphi-Messageverarbeitung hinter das CreateWindowEx gesetzt, dass das Fenster erzeugt (das würde sonst gar nicht angezeigt). Hier kommt es dabei zu einem rekursiven Aufruf der "Virtual Machine" von Profan, was dazu führt, dass die Delphi Variable vom Callback überschrieben wird, auf die das Handle von CreateWindowEx zwischengespeichert wird, um es als Returnwert später zurückzugeben. Da ein solcher Callback ja nur rekursiv aufgerufen werden kann, wenn die Messageverarbeitung von Delphi innerhalb der "Virtual Machine" angesprochen wird, vermeide ich es einfach, Fenster über die Profanbefehle zu erzeugen, solange der Timer läuft. In Profan2Cpp reicht das aber nicht aus (Version 1.5a).
PS: Roland könnte zum Beispiel diese Variable in eine Prozedur packen, um sie zu deklarieren. Aus dieser Prozedur heraus müsste dann erst die "Virtual Machine" aufgerufen werden, wie es ja auch bei einem Profan Callback geschieht. Als Folge würde die Variable bei einem rekursiven Aufruf durch den Callback neu deklariert werden und sich nicht selbst überschreiben. Mit allen anderen Variablen, die die "Virtual Machine" intern zum Rechnen nutzt, müsste das gleiche geschehen. Ist aber nur graue Theorie, ohne genau bestätigt bekommen zu haben, was an meiner Sicht der Sache nun stimmt oder nicht - und so kann man eben nicht weiterdenken und auch keine Lösung finden. Ist aber auch nicht so wichtig :-).
Wie gesagt, bei dir liegen andere Probleme vor. -
Zitat
Bei AddFiles muss ich mal schauen - das ist ja komplett in den Bibliotheken implementiert. Ist meine Version da wirklich langsamer als Rolands?
Nein, nein. Hab ich auch gar nicht getestet. Ich meinte nur, dass XProfan mitunter (diverse Befehle) so schnell ist, dass es auch mit C++ oder Assembler kaum schneller programmiert werden kann. Das ist aber kein Makel von P2Cpp, also mach dir keinen Kopf!
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!