Beiträge von Andy

  • Basepointer auslesen mit NomadMemory.au3 oder WinAPI.au3

    Zitat von alpines

    Das blöde an der UDF ist, dass es einfacher für Scriptkiddies ist sich was zusammenzuschreiben, da sie mit DllStructs und sonstigem überhaupt nicht in Kontakt kommen.

    Deshalb wird es ja auch meistens dafür verwendet.

    Naja, mal vorausgesetzt das wäre wirklich so "einfach", dann hätte es diesen und die hunderte anderen Threads mit gesuchten Lösungen zum "NOMAD"-Problem nicht gegeben. Letztendlich sieht es so aus, dass davon ausgegangen wird, dass das 2Problem" durch NOMAD´s UDF gelöst wird, und nicht dadurch entsteht. Wenn man keinerlei Ahnung hat, um was es eigentlich geht, hilft einem auch eine UDF nicht sonderlich weiter. wzbw....

  • Basepointer auslesen mit NomadMemory.au3 oder WinAPI.au3

    Hi,

    eine permanent sichtbare Akkuanzeige halte ich für suboptimal. Die braucht doch ehrlich gesagt kein Mensch. Letztendlich "rechnet" das Gehirn die Anzeige aus dem Bild heraus und stellt nur die "wichtigen" Anzeigen dar.

    Ist übrigens einfach nachzuprüfen, indem man die allseits beliebte FPS-Anzeige einblendet und jemanden bittet, innerhalb der nächsten 20 Minuten mitten im Zockergewühl die Sicherung rauszuschmeissen. Die Kiste geht aus und die Frage " wie hoch waren beim "Abflug" die FPS?" kann NIEMAND beantworten, der sich auf das Spiel konzentriert! Und die "Progamer", die sich bei dieser Gelegenheit damit brüsten, "mit einem Auge" IMMER die FPS im Blick zu haben frage ich, wozu?

    Richtige Progamer verdienen ihr Geld damit, mit genau diesen Müll ihr Gehirn NICHT zu belasten und sich stattdessen ausschliesslich auf das Spiel zu konzentrieren!

    Ich habe mir ein Script erstellt, welches bei mir ab einem Akkustand von 40% alle 5% ein Infofenster zeigt, welches auch nur 1 Sekunde sichtbar ist. Dadurch wird auch im dicksten und stressigsten "Gewühl" beim Zocken, und übrigens auch beim konzentrierten Arbeiten(!), der Countdown und der Schrei nach einer Steckdose wirksam angezeigt.

    Die von Windows erzeugten und einstellbaren Alarmmeldungen bzgl. niedrigem Akkustand funktionierten bei unserem (Intel-)Laptop und auch Tablet bei einigen Vollbild-Anwendungen nicht! Da ging dann einfach das Gerät infolge fehlender Leistung aus....

  • Wie organisiert ihr eure AutoIt-Projektverzeichnisse?

    Hi,

    unabhängig von der verwendeten Programmiersprache empfinde ich das "Chaos" innerhalb des Entwicklungsprozesses als sehr produktiv.

    Jedwege Einschränkung durch meist "von außen" auferlegte Beschränkung bzw. "Vorgaben" (...man MUSS(!)... ) tötet imho. jede Inspiration bzw. Intuition. Wieso ich das so empfinde? Hab´s mehrfach ausprobiert und dokumentiert. Man konzentriert sich schon am Anfang mehr auf die "Organisation" (?!) als auf den Code.

    Auch bei Projekten professioneller Programmierer erkennt man deutlich die Reihenfolge dieser Vorgaben. Der Code ist TOP organisiert, aber unfertig (schlimmere Bezeichnungen spare ich mir jetzt). Auf Nachfrage folgt dann zu 90% die Antwort:"...aus Zeitgründen am Ende der Entwicklung nur noch die Baustellen gefixt...".

    Dazu muss man allerdings sagen, dass der Prozess "Programmieren" individuell zu sehen ist. Ein auf Organisation Wert legender "Buchhaltertyp" oder "Erbsenzähler" hat andere Prioritäten wie ein innovativer und kreativer "Chaotiker". Nichtsdestrotrotz haben beide im Team ihre Existenzberechtigung.

    Was ich auch oft mache, ist nachzufragen. Sich selbst und andere permanent nachzufragen und ehrlich(!) zu reflektieren ist die einzige Möglichkeit, besser (!) zu organisieren und vor allem zu optimieren.

    Fortschritt entsteht nicht durch festlegen auf Arbeitsabläufe. Fortschritt entsteht durch permanente Weiterentwicklung! Und da haben Einschränkungen NICHTS zu suchen. Jedenfalls nicht bei "kreativer" Arbeit.

    Programmierarbeit nimmt ca. 5-10% meiner Arbeitszeit ein, die Umsetzung von Verbesserungen ist meine Hauptaufgabe.

    Dazu gehört auch die Organisation der Mitarbeiter. Der "Erbsenzähler" gehört auf "seinen" Arbeitsplatz. Und der " Chaotiker" auf seinen. Die Arbeit muss sich an den Menschen anpassen damit dieser effizient und produktiv ist, und nicht umgekehrt! Ein motivierter und zufriedener Mitarbeiter liefert messbar immer eine höhere Leistung ab als ein unmotivierter und unzufriedener!

    Was immer hilft, ist diese Mitarbeiter auszutauschen, damit sie auch mal "die andere Seite" sehen! DAS macht wach und regt auch die geistige Auseinandersetzung an!

    Zitat von alpines

    Jetzt würde ich gerne ein paar Ideen sammeln um dann nachher eine Entscheidung zu fällen.

    Das ist immer eine gute Idee. Über den Horizont schauen und die Betriebsblindheit so lange wie möglich abzuwehren zu versuchen. :P Denn DAS ist die einzige Konstante im Spiel, die einschränkende und lähmende "Betriebsblindheit".

    Ich habe viele Betriebe angeschaut, viele Bücher über Organisation und (Projekt-) Management gelesen, mir dort gute Ideen geholt und auch viele Experimente gemacht. Letztendlich scheitert eine Umsetzung IMMER an den beteiligten Mitarbeitern. Eine erfolgreiche Umsetzung hängt IMMER an den beteiligten Mitarbeitern.

    Es gibt also keinen generell "richtigen" Weg! Sondern nur den individuell "richtigen". Und den gilt es zu finden...

  • Portieren Scintilla DirectMessage von C/C++

    sorry, hatte c&p-fehler... so gehts jetzt

    so bekomme ich jedenfalls die richtigen Werte aus dem Scite-Fenster

    Zeilenlänge der Zeile incl CRLF und Zeilenlänge der Zeile in der der Cursor steht

  • Portieren Scintilla DirectMessage von C/C++

    So wie ich das sehe, klappt das so:

  • R128 Lautheitsmesser

    Zitat von Simpel

    Es können ja aber bis zu 6 Kanäle sein, die interleaved, im Wechsel codiert sind. In Post 5 habe ich dieses Verhalten bereits berücksichtigt. Wie bekommt man das jetzt mit Deiner Variante hin? Vergrößert sich die Struct mal der Kanäle und greift die K-Filter-Berechnung nur auf die Werte zurück, die nur zu diesem Kanal gehören?

    Es kommt darauf an, wie die Kanäle innerhalb der Datei bzw. des Dateiformats vorliegen. Rudimentär hatte ich diverse "Umformungen" für WAV-Dateien mit Stereo, also 2 Kanälen, mal in Echtzeit vor fast 15 Jahren hingebastelt. Frag mich heute nicht danach^^

    Grundsätzlich stellt sich die Frage, was du mit dem Programm überhaupt beabsichtigst. Was soll das werden?

    Dann zieht man die Sache entsprechend auf.

    Mit den Structs ist das gar keine große Sache. Da werden einfach Bereiche im Speicher reserviert, und entsprechend bearbeitet. Sieht aus wie ein Array, und wird auch ähnlich angesprochen.

    Grundsätzlich kannst du mit AutoIt bei deinem Vorhaben und den Mengen an Berechnungen keinen Blumenpott gewinnen, auch nicht bei Verwendung von Structs.

    Was geht ist ein "schickes" GUI, die eigentlich einfachen Berechnungen würde ich in Funktionen in eine mit einem Basic-Compiler erstellte DLL auslagern und dann aus AutoIt callen. Dann hast du die Oberfläche in AutoIt, und die Geschwindigkeit eines Compilers.

    Mit dem großen Vorteil, dass jedermann mit egal welchem Compiler und Programmiersprache eine ggf. "schnellere" Berechnung schreiben kann.

    Da macht dann die Verwendung von ASM nur noch Sinn, wenn es wirklich um die absolute Optimierung geht. Da würde ich allerdings die Challenge gegen herkömmliche Compiler aufnehmen.:saint:

    Weiterhin sind die zu berechnenden Teile der Daten doch eher übersichtlich "klein", also eigentlich "winzig", nur einige Kilobytes.

    Eine weitere Alternative wäre dann die parallele Berechnung mehrerer Kanäle bzw. mehrerer Teilbereiche gleichzeitig. Wenn rudimentäres C (ohne ++) kein Problem darstellt, wäre auch OpenCL eine Alternative....

    Zitat von Simpel

    daß mit reinem AutoIt das Array immer die exakten 4800 Werte hat, aber über die DLLStruct die Werte zwischen 4800 und 4812 schwanken. Weißt Du, warum das so ist?

    Nein, die Struct hat immer die Größe von

    Code
    $structlen = ($iBitrate / 8  ) * $i100msSampleCount * $iChannels

    , das ist beim Start des Programms festgelegt.

    Hups, ich habe gerade bemerkt, dass die Länge der TEXT(!)-Daten innerhalb der Struct, also die Stringlänge natürlich unterschiedlich ist. Innerhalb der Struct werden die Daten nicht gelöscht sondern nur überschrieben und somit beim Auslesen wird "der Rest" hinter dem eigentlichen String mitgezählt. Weil dort ein Textende, also CHR(0) fehlt. Wird geändert.

    Code
    $binarycode ="0x8B7424048B7C24088B54240CC1EA028954240C31D28B1C960FBAE31F7306F7D343B02DAA525189D8BB0A00000031C931D2F7F3665280C10109C075F366580C30AAE2F9C6077C83C701595A423B54240C72C3B000AA89D0C3"

    fixt das. Bei _int2string also etwa Zeile 280 austauschen.

  • Ausfüllen von Word Briefvorlagen/Rechnungsvorlagen

    Yaerox,

    In welchem Bereich ist dein Bruder tätig?

    Hier wird über alle möglichen und unmöglichen WAWI-Programme und "halbgaren", weil völlig überfrachteten ERP-Programme gesprochen, aber je nach Branche gibt es spezielle Software, die meist genau das bietet, was der Nutzer braucht. Nicht mehr, und auch nicht weniger.

    Ich hatte mir vor einigen Jahrzehnten, als ich mich in der Baubranche selbstständig gemacht hatte, ziemlich alle frei erhältliche "kaufmännischen" Programme zugelegt. Sowohl ich als auch meine Frau (Dipl. im Steuerrecht) hatten diese Software unabhängig voneinander "getestet" und das komplette(!) Sortiment für ungenügend befunden, weil völlig überfrachtet und produktiv(!!!) NICHT benutzbar.

    Letztendlich hatte ich mir 5 Lizenzen des damaligen StarOffice (jetzt OpenOffice) für zusammen nicht mal 900DM gekauft und damit die Bürorechner ausgestattet. Nach einigen Wochen Programmiererei in StarBasic wurde unser Arbeitsablauf 1:1 umgesetzt und alle steuerlichen Vorgaben/Vorschriften "im Hintergrund" abgewickelt.

    Angebot erstellen ("zusammenklicken") aus Listen bzw. Übernahme aus Branchensoftware, nach Auftragserhalt mit einem Mausklick daraus eine AB und auch Bestellung beim Lieferanten(!) erzeugen, nach Abwicklung mit einem Mausklick Rechnung erstellen und digital ablegen.

    Daneben hatte ich mir von unserem Hauptlieferanten eine von diesem für kleines Geld bereitgestellte Branchensoftware zugelegt. Alles in allem ein System, welches 15 Jahre so gut wie unverändert lief, und von dem ich noch heute profitiere.

    Mittlerweile bin ich in einem größeren Unternehmen angestellt und meine heutigen Kunden sind größtenteils selbst "kleine" Händler, da graust es einer Sau, wenn man denen teilweise bei der Büroarbeit zusieht!

    Die sollen unsere Produkte verkaufen, und sich nicht nächtelang mit SCHEI** Software rumärgern!

    Daher bieten wir ein sog. "Händlerprogramm" für unsere Branche an, welches auf die Bedürfnisse unserer Kunden und auf einen optimierten und organisierten Arbeitsablauf zugeschnitten ist.

    Und ich bin sicher, für die Branche von deinem Bruder existieren Lieferanten, welche ähnliche Produkte anbieten!

  • R128 Lautheitsmesser

    Hi!

    Zitat von Simpel

    Also theoretisch könnten die Audiosamples signed Integer 32bit sein. Ich durchdenke aber auch gerade, ob man allen Audiosamples größer 16bit einfach die lower Bytes klaut und 16bit draus macht. Das könnte eine Ungenauigkeit in der Größe des letzten 16bit-Bits sein, vermute ich, aber es ist, glaube ich, genau genug. Die Lautheitswerte werden am Ende mit einer Dezimalstelle angegeben. Ich muss das mal konkret durchrechnen.

    Ob 8 Nachkommastellen für die Filterberechnung reicht, muß ich auch ausprobieren.

    Daran bin ich in den letzten Stunden gescheitert...

    Nachdem ich die Berechnungen nach Assembler (die SSE-Register beinhalten 4xfloat und werden parallel in einem Takt(!) berechnet) überführt hatte, und für die ersten (hunderte bis tausende) Schleifendurchläufe exakt auf die gleichen (Integer)Werte kam, musste ich dennoch feststellen, dass es mitten in der Berechnung zu einer immer größeren "Drift" der Ergebnisse kam. Letztendlich liegt es an der Konstanten 1.99004745483398, für die es KEINE Entsprechung als float gibt.

    Für die Berechnung würde benötigt ein Wert von float 1.9900474 (man beachte die letzte Stelle hinter dem Komma, also die 4), aber DEN GIBT ES NICHT!

    Wen das näher interessiert, der sei hierhin verwiesen!

    Das letzte Bit in der Mantisse wechselt zwischen 1.9900473 und 1.9900475, und exakt dieses eine (fehlende "halbe" :Face:) Bit führt zu unterschiedlichen Ergebnissen, da sich innerhalb der Schleife der "Fehler" in den hunderten Multiplikationen immer weiter fortsetzt.

    Float hat eine Genauigkeit von 8 Stellen incl. Vorkomma, d.h. bei vier Vorkommastellen bleiben nur 4 Nachkommastellen für die Genauigkeit übrig und da summieren sich dann bei Multiplikationen mit großen Zahlen die "Fehler" gegenüber AutoIt, welches intern mit double, also 64Bit Genauigkeit rechnet.

    Man könnte natürlich in Assembler auch mit double rechnen und die seit 40 Jahren unveränderte FPU im Prozessor bemühen (genau wie das AutoIt bzw. die davon aufgerufenen Funktionen des M$-C++-Compilers machen), das wäre geschätzt Faktor 20 langsamer als der entsprechende SSE-Code für double, aber das war ja nicht die Intention. Nur mal für die Galerie, den Abschnitt

    Code
    $xnK1_2 = $xnK1_1                            ; die Werte für x[n], x[n-1], x[n-2], y[n], y[n-1], y[n-2] stage 1 rücken eins weiter in die Vergangenheit
            $xnK1_1 = $xnK1
            $ynK1_2 = $ynK1_1
            $ynK1_1 = $ynK1
            $xnK1 = $iInteger

    wickelt der Assemblercode in 3 Prozessortakten ab (4x floatwert in einem Register einen Platz nach links shiften und den (vorher in float umgewandelten) Integer einfügen) .

    Die Zeile

    $ynK1 = Int(1.53512485958697 * $xnK1 - 2.69169618940638 * $xnK1_1 + 1.19839281085285 * $xnK1_2 + 1.69065929318241 * $ynK1_1 - 0.73248077421585 * $ynK1_2)

    wird in 12 Takten abgewickelt, davon entfallen allein 8 Takte auf die Umwandlung von float nach int und wieder nach float. Prozessor- bzw. Registerintern wird nur mit float gerechnet!


    Der Gesamtfehler im Vergleich double zu float bewegt sich bei ca. 1-2%. Leider gibt es auch seltene Ausreißer, bei denen es einen Fehler von 25% gibt. Ob du damit leben kannst, musst du herausfinden.

    Den Faktor 1000 als Geschwindigkeitsvorteil (für die Berechnungen innerhalb der Schleife) habe ich nicht ganz erreicht, aber Faktor 600 ist auch nicht schlecht^^

    Im 64-Bit-Modus hätte ich YMM-Register (256Bit) verwenden können, das wäre etwas aufwendiger geworden, hätte aber die Berechnungen massiv beschleunigt, weil KEIN(!) Speicherzugriff zum Abspeichern der Zwischenergebnisse nötig gewesen wäre!


    Generell ist dein Ansatz aus der Sicht eines AutoIt-Programmierers (ich sag es mal vorsichtig, nicht falsch verstehen!) "grenzwertig".

    Einen String aus Zahlen zu erstellen, aus dem dann ein Array gemacht wird, welches wiederum "beschnitten" und ergänzt und letztendlich noch sortiert wird, ist extrem suboptimal.

    Aber dafür kannst du eigentlich wenig, die Beschränkung liegt eher in der generell langsamen (Berechnungs-)Geschwindigkeit von AutoIt aber hauptsächlich in der Behandlung von Arrays.

    Die Daten in der Audio-Datei liegen doch sowieso schon als "Array" vor, ich habe diese einfach ausgelesen und per BinaryToString() in eine Struct aus 16-Bit-integer geschrieben. Keine weitere "Umrechnung" nötig!

    Schreibst du das Script statt "Arrays" auf eine DllStruct() um, dann sparst du dir sämtliche Umrechnungen aus String nach Array, das ArrayDelete/Add (wird ersetzt durch ein ultraschnelles Memcopy).

    Für einen Compiler mit einem 16-Bit-Array im Sourcecode wäre das ein gefundenes Fressen. Das komplette Script (und nicht nur die einzelne (Schleifenberechnung!) wäre in einigen Millisekunden abgehandelt, also ECHTZEIT!

    Und da wäre seitens Optimierung noch reichlich Luft nach oben!

    Versuch mal, dein Script einem Basic-Compiler vorzusetzen, ggf reicht es schon, eine DLL nur mit den Berechnungen/Funktionen zu erzeugen und diese aus AutoIt aufzurufen.

    Anbei der Vergleich des jeweils letzten in der Schleife berechneten Integers, also $ynk2.

    Ich habe mir geschenkt, die vom ASM-Code berechneten Werte in einen String zu schreiben (die gehören in eine 16-Bit-"short" Struct, welche ein "Array" ist!) , das hätte den Code nochmal überdimensional aufgepumpt. Nur um einen String zu machen, der dann wieder per StringSplit() in ein Array zerlegt wird uswusf....DAS war aber schon mal Thema^^ //

    //EDIT habe ich jetzt doch gemacht...

    Aber falls du die Ergebnisse trotzdem vergleichen willst, hier mal ein Ansatz....^^

    Man beachte nach dem ASM-Code die Schleife, die aus der Integer-DllStruct einen String macht, welcher dann in ein Array überführt wird:Face:Ich glaub, ich schreib das Script mal komplett auf Dllstruct um....:rock:

    //EDIT Das bereitet mir körperliche Schmerzen, ich schreibe einen ASM-Code, der aus den Integer einen String macht...


    simpel lautheit ASM_forum1.zip


    In der Anzeige der Zeit für den ASM-Code ist auch die Umwandlung in einen String und das in AutoIt SEHR langsame Lesen dieses Strings aus dem Speicher enthalten, einfach die beiden Zeilen auskommentieren....bei mir ergibt sich für die eigentliche Berechnung 0.08ms, inclusive der Umwandlung in String und das Lesen sind das 0,23ms...die Differenz von 0.11ms ist zwar nicht die Welt, aber völligst unnötig!

    Das darauffolgende Neuberechnen der Arrayinhalte dauert pro Durchlauf bei mir ca. 80-100ms.


    Ich schreibe das Script mal weiter um auf komplette Verwendung von DllStructs statt Array, das macht es selbst in reinem AutoIt-Code schätzungsweise 10x schneller!

    Aber wie gesagt, das vorliegende Script in einer Compilersprache wäre sowieso schon 100x schneller....

  • 32bit oder 64bit

    Zitat von Tweaky

    Aber so ein Problem wie hier ist zumindest bei mir nur mit einer 64Bit-exe zu umgehen.

    Wenn es funktioniert, dann mach es!:thumbup:

    Allerdings hat das imho nichts mit dem Unterschied 32/64-Bit AutoIt-"*.EXE" zu tun, sondern eher mit Win10 und deiner individuellen Konfiguration.

    Wenn das Problem bei anderen nicht auftritt hast du für dein System einen Workaround gefunden, das eigentliche Problem aber nicht gelöst. Glücklicherweise hat AutoIt die Option dazu^^

  • 32bit oder 64bit

    Da AutoIt als reiner Interpreter auf den Bibliotheken der M$-Compiler basiert, gibt es definitiv KEINE Vorteile einer 64-Bit-Version eines Scriptes gegenüber einer 32Bit-Version.

    Vorteile von 64Bit würden ja implizieren, dass für die erstellten Funktionen (aus den Bibliotheken) anderer, d.h. schnellerer bzw. auf 64-Bit optimierter Code GESCHRIEBEN (NICHT(!) compiliert (!) ) wurde. Und das ist mal definitiv nicht so!

    Nur weil ein Programmierer einen Compiler mit einem Häkchen in den Einstellungen dazu zwingt, explizit für eine 64-Bit-Plattform zu kompilieren, entstehen keine Wunder. Der auf die Verwendung mit 8088/86-Prozessoren geschriebene Sourcecode wurde nicht verändert, somit bleibt dem Compiler nur die Möglichkeit, geringfügig (!), bspw. durch Verwendung einer größeren Anzahl zur Verfügung stehenden Registern, den compilierten Code anzupassen.

    Wenn man allerdings 64-Bit-Programme für einen Compiler SCHREIBT(!), dann kann man auch Faktor 2-3 , ggf. auch noch mehr, an Geschwindigkeit aus der Hardware herausholen.

    Imho machen ja die Programmierer in den Hochschulen und Forschungseinrichtungen der Industrie gerade vor, wie man solchen Code schreibt. Google/Amazon/Intel kaufen seit geraumer Zeit humanoides Know-How in Form "kleinerer" Firmen, welche den "großen" zeigen wo der Hammer hängt (bzw. hängen KÖNNTE)!

    Die Softwareindustrie ist nicht mal annähernd in der Lage, aktuelle oder auch 10 Jahre alte Hardware optimal zu nutzen. Braucht sie auch nicht. Wenn du willst, dass das Programm 10% schneller läuft, kauf für 500€ einen neuen Prozessor. Damit ist der Softwarehersteller aus dem Schneider. DEN würde es nämlich Millionen kosten, sein Programm 10% schneller zu machen. Abgesehen davon dass er das gar nicht KANN, denn WER sollte das "schnellere" Programm bzw. den Code dazu erstellen? Wenn der vorhandene Programmierer dazu in der Lage wäre (Compilerschalter anhaken reicht wie gesagt nicht), dann würde er das sowieso schon tun. Oder etwa nicht?

    Zitat von UEZ

    x32 läuft auch auf x64 BS, aber eben nicht umgekehrt.

    Und wenn es keine Vorteile gibt, wieso dann benutzen?

    Zitat von Tuxedo

    Naja, ich würde meinen wenn die x64 Versionen keinen Vorteil bringen, dann kann man ja auch bei den x86 Versionen bleiben, ausser man muss unbedingt den ganzen verfügbaren Speicher ausnutzen,

    dann ist eine 64-Bit Version unverzichtbar.

    Generell stellt sich dann die Frage, ob ein/der (AutoIt-) Interpreter die richtige Wahl für ein Programm darstellt!?

    Wenn man mehrere Gigabytes Speicher mit einem Script/Programm (NICHT API-Funktionen(!)) bearbeiten muss, dann ist ein Compiler sowieso "must have". Dann noch für 64Bit compiliert/optimiert, und der Geschwindigkeitsvorteil zu AutoIt liegt bei Faktor 100 bis 1000. Und ob das Compilat nun 80kb groß ist oder 800kb interessiert heutzutage auch niemanden mehr^^

    Für die generelle Verwendung von AutoIt spricht die schnelle und einfache Code-Erstellung und die vielen Vorteile wie bspw. der Variant-Datentyp, GUI-Erstellung, Arrays, fast die komplette Win-API ist gewrappert (nicht zu vergessen dieses hervorragende Forum <3) uswusf.

    Wer "hardcore" 64-Bit-Software schreiben will, soll sich an einen für alle Sprachen/Dialekte erhältlichen Compiler halten!

  • Ausfüllen von Word Briefvorlagen/Rechnungsvorlagen

    Zitat von Yaerox

    Die Vorstellung ist, dass er nur mein Tool offen hat, dort dann quasi einen Button hat Rechnung erstellen/Brief erstellen und dann hat er dort entsprechende Masken in denen er die Daten eintippt. Diese eingegebenen Daten sollen dann entsprechend in die Word-Dokumente eingetragen werden.

    Schau dir mal den Formularersteller/VBA in Word/Excel an, das ist Koda für Fortgeschrittene.

    Damit Kannst du dir AutoIt völlig schenken, und auch das speichern und wegsortieren (als PDF) anhand der eingegebenen Daten ist nur ein einziger Befehl.

  • R128 Lautheitsmesser

    Sodele, komme gerade erst dazu, bissl zu programmieren.

    Man müsste mal testen, inwieweit der "float" Datentyp für die Berechnung ausreicht. 8 Stellen Genauigkeit sollten ggf hinhauen. Dann könnte man die Berechnung in den SSE-Registern abhandeln, der gesamte Block

    wäre dann in nicht mal 10 Prozessortakten abgewatscht, und nur in einer Handvoll Zeilen ASM-Code. Auf neueren Prozessoren könnte man sogar ein FMA (fused multiply add) verwenden, also a=b+c*d und das mit 4 Registerinhalten gleichzeitig, d.h. die gesamte Zeile

    Code
    (1.53512485958697 * $xnK1 - 2.69169618940638 * $xnK1_1 + 1.19839281085285 * $xnK1_2 + 1.69065929318241 * $ynK1_1 - 0.73248077421585 * $ynK1_2)

    wäre mit einem (!) Prozessorbefehl abgehandelt....schaumamal


    Sollte die Genauigkeit höher sein müssen, dann muss man double verwenden, da kann man immer noch die SSE-Register verwenden. Leider passen da dort in die 128 Bit nur 2xdouble (64Bit) Zahlen rein, aber besser wie nix. Immer noch Welten schneller als die gängigen Compiler mit FPU-Code :o)

  • R128 Lautheitsmesser

    Bin schon weitergekommen^^

    Für das Ein-Kanal-Beispiel aus deinem Script habe ich heute Abend schon eine (schnelle(re)) Variante.

    Generell sollte man aber überlegen, inwieweit eine "universale" Berechnung Sinn macht.

  • R128 Lautheitsmesser

    Hi,

    zunächst würde ich, um all dieses Umgerechne/Hex/Array-Gedöns zu vermeiden, die WAV-Datei komplett in eine DllStruct einlesen.

    Die Daten stehen somit im Speicher und können in Autoit per DllstructGetData() an ihrer jeweiligen Position ausgelesen werden.

    Die eigentliche Berechnung innerhalb der beiden FOR/TO-Schleifen würde ich dann auslagern in entweder eine mit einer Compilersprache erstellten Dll oder direkt in Assemblercode.

    Beides reduziert die Laufzeit innerhalb der Schleifen auf nahezu NULL Millisekunden. Gehe von einer Beschleunigung der Berechnung mit Faktor 1000 aus...

    Bin zzt. unterwegs, aber in der kommenden Woche sollte ich ein erstes Script zusammengebastelt bekommen

  • ASM-Code optimierbar und kann ich Dll-Funktionen aus dem ASM-Code aufrufen?

    Zitat von alpines

    Falls hier jemand das gerne mal ausprobieren möchte (AutoIt-Berechnung mit ASM-Code zu substituieren) soll er das auf jeden Fall machen.

    Ja, definitiv!

    Es ist immer und ewig das gleiche Spiel! Die "langsame" Schleife suchen und diese optimieren bzw. beschleunigen.

    Meistens ist es kein Hexenwerk, und wie hier im Thread gezeigt fehlt meist auch nur ein Fingerzeig oder Tip.

    Niemals würde ich komplette Programme incl. GUI in ASM erstellen, das ist imho auch obsolet und dafür gibt es die "Hochsprachen", aber das ist auch gar nicht die Intension. Mit einer Handvoll Bytes an der richtigen Stelle die (ggf. zeitkritische) Geschwindigkeit des Programms x-fach beschleunigen, DAS ist die Intension!

    Und wie gesagt, man kann sich ja mal anschauen, was bspw. ein (schneller) Compiler aus der Schleife machen würde.

    Langsamer kann´s also schon mal nicht werden:D

    Zitat von alpines

    Wenn man ständig auf seinen x86-Befehlssatzspicker schaut, ist das gar nicht mal so schwierig. Zumindest habe ich kaum mehr Fehler gehabt als normal mit AutoIt zu scripten.

    Ich hatte irgendwo mal geschrieben, dass man für 90% der ASM-Programme mit zwei Handvoll Befehlen auskommt, und das ist auch so!

    Ich habe auch nur einen SEHR groben "Überblick", meistens könnte man mit speziellen Befehlen noch den einen oder anderen Takt einsparen, aber entweder weiß ich nicht ob es da gerade jetzt einen anderen bzw. besser geeigneten Befehl gibt, oder mir ist es schlichtweg egal! Bei SSE/SIMD habe ich schon einen ziemlich guten Draht, da lege ich mich gern mit JEDEM Compiler an. Compiler, NICHT Programmierer, denn wenn dieser weiß was er da tut, zwingt er sowieso dem Compiler sein Compilat auf ;)

  • ASM-Code optimierbar und kann ich Dll-Funktionen aus dem ASM-Code aufrufen?

    Zitat von alpines

    Man kann sicherlich noch bisschen was rauskitzeln aber das ist schon mal ne Wucht!

    Wenn ich den DllCall zur Berechnung komplett auskommentiere, dann ändern sich die Zyklen pro Sekunde NICHT! Logisch, da die Berechnung nur in einer Handvoll Prozessortakten abläuft.

    Per SSE könntest du trotzdem 4 Punkte gleichzeitig berechnen. Macht hier aufgrund der sowieso kaum eingesparten Zeit wenig Sinn, lohnt sich aber bei aufwendigen Berechnungen immens!

    Btw. habe ich auf meinem 27'' Monitor (2560x1440) die Auflösung in Windows auf 125% gestellt, und somit ca. 440 Zyklen/s. Und das mit 273 Bytes Code....:thumbup: