Beiträge von Andy

Zitat von Make-Grafik

Desweiteren fügst du in Zeile 34 ein Chr(0) an's Stringende

Was man sich sparen kann, wenn man die char-Struct um einen weiteren Char ergänzt. Dieser hat dann immer den Wert 0

Schöne Funktion!
die solltest du dahingehend erweitern, JEDEN Datentyp (String, (U)INT, FLOAT usw.) in die Struct zu bringen, damit man auch mal richtig rocken kann^^

Ok, ein Array aus Strings.
Um die Stringlänge völlig ausser Acht zu lassen, lege ich diese einfach mal auf 20 fest.
Das Array besteht aus 4 Spalten und 3 Zeilen, also 12 Elementen

Zitat von Make-Grafik

Schwieriger wird es sobald du nach Möglichkeit Platzsparend programmieren möchtest. Dann muss da was anderes her.

Naja, da nimmt man eine verkettete Liste, bzw. eine einfache Liste die aus stringlen1,string1, stringlen2, string2, stringlen3, string3 ....besteht.
Um dann den Pointer des 5. Strings innerhalb der Struct zu finden, hangelt man sich von Stringlen zu Stringlen, bis der 5. String erreicht ist.
Oder man schreibt einfach alle Strings hintereinander und notiert sich in einer weiteren Struct (oder Array ) die Startpointer.
Entspricht in etwa einer LUT (lookuptable)

Nur mal interessehalber, wie löst ihr das Problem von "guten" (lösbar in 25 Zügen) und "bösen" (lösbar in >40 Zügen) Rätseln innerhalb von einem Set (ich löse 16x16 Rätsel)?

Ich habe 3 (einfache) Algorithmen am Start, und vergleiche diese mit je 100 Rätseln. Mal gewinnt der eine, mal der andere!
@Mars, man sollte zuerst alle Rätsel zufällig erstellen, und danach alle Algorithmen auf jeweils das gleiche Rätsel loslassen.

Ich bin mir nicht genau sicher, was du meinst.
Deine "Tabelle" ist unzweifelhaft ein 2D-Array!
Oder soll das die Entsprechung von _ArrayDisplay() sein?
Bei der Struct ist es völlig unerheblich, in welcher Reihenfolge die Daten angeordnet sind, hauptsache DU weisst es^^. Da gibt es weder Reihen noch Spalten!

Zitat von rynow

Weil aktuell kann ich zwar beliebig viele Spalten erstellen aber nur eine Zeile? Oder muss ich tatsächlich für jede Zeile ein neues struct erstellen?

Das verstehe ich nicht.
Zeig doch dein Array mal. Und deine Entsprechung in einer Struct.

Weil du nur das eine Byte im Char-Array abfragst!
Um den gesamten String zurückzugeben, darfst du den index nicht verwenden.

$struct=dllstructcreate("char[100]")
dllstructsetdata($struct,1,"Hallo AutoIt")
$string =dllstructgetdata($struct,1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $string = ' & $string & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$buchstabe=dllstructgetdata($struct,1,1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $buchstabe = ' & $buchstabe & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

Zitat von habenureinproblem

Ach...für mich alles ein Rätsel.

Willkommen in der Welt der Programmierung!

Zitat von habenureinproblem

Will man bei bestimmten Aktionen, wie von Andy vorgeschlagen, alles verstecken? Sieht sicher komisch aus, schon nur ein GUICtrlCreateGroup zu verstecken bei Befüllen von einem Listview wirkt eigenartig (aber um 4 Sekunden zu sparen bzw im oberen Beispiel 14 Sekunden wäre es es sicher wert).

Wen interessiert, was "merkwürdig" aussieht, wenn man dadurch massiv Zeit spart?!

Mich würde in diesem Zusammenhang auch interessieren, wieviel Zeit und somit auch Geld die berühmte "Sanduhr" täglich kostet. Ich schätze mal niedrig einige Milliarden Euros. Windows-Nutzer haben die Sanduhr aber inzwischen dermaßen verinnerlicht, da fällt schon auf, wenn man sie einige Minuten NICHT sieht!

Zitat von rynow

Andy hast du evtl. ein Beispiel wie ich ein SOA erstelle?

Ein einfaches Beispiel ist eine Bitmap.
Jedes einzelne Pixel besteht aus den 4 Kanälen (Bytes) Alpha, Rot,Grün, Blau, also ARGB als DWORD (4 mal 8 Bit)
Im Speicher stehen die Pixel byteweise nacheinander ARGBARGBARGBARGBARGB... bezeichnet als ein Array of Structures.
Möchte man nun bspw. 64 rote Farbanteile (64 Bytes passen genau in eine Cacheline) aus dem Speicher lesen und verarbeiten, müssen nun 4x64 Bytes, also 4 Lines im Prozessorcache, gefüllt werden! Drei viertel der Daten im Prozessorcache wären also unnötiger Müll (Cache pollution)!

Um jetzt die einzelnen Farbkanäle anzusprechen also beispielsweise nur die roten Farbbestandteile, könnte man alle diese Bytes nacheinander in den Speicher schreiben, also als
AAAAAAAAAA...RRRRRRRRRRRRRRRR...GGGGGGGGGGGGGG...BBBBBBBBBBBBB....Structure of Arrays
Würde man jetzt 64 rote Farbanteile lesen bzw. bearbeiten wollen, würde der Prozessor mit einem Lesebefehl nur EINE Cacheline füllen müssen!

Gerade bei der Verarbeitung mit den SSE-Befehlen, also SIMD (Single Instruction Multiple Data), sollte man also tunlichst die Daten entsprechend vorbereiten, damit diese Prozessorbefehle überhaupt ihre Geschwindigkeit ausspielen können!
Mittlerweile "optimiert" bspw. der INTEL-Compiler schon den C(++)-Code VOR dem Compilieren, um dem Prozessor die "richtige" Reihenfolge der Daten im Speicher zur Verfügung zu stellen. U.a. dadurch wird der Geschwindigkeitsunterschied der compilierten Programme zu anderen Compilern erreicht.
Btw. kann man über die Shuffle-Befehle die Daten umorganisieren, aber wenn man sich diese "teuren" Befehle sparen kann, um so besser. Eukalyptus hat dazu ein schönes Script geschrieben!

Wie man schon erahnen kann, hilft einem das o.g. in einem AutoIt-Script geschwindigkeitsmäßig nicht sonderlich viel, dazu ist der Overhead des Interpreters viel zu groß.
Allerdings schadet es auch nicht. Sollte man bspw. für eine schnelle Berechnung eine Dll, bspw. per C(++) oder Freebasic oder einem beliebigen anderen Compiler erstellen wollen und diese dann mit AutoIt verwenden, wird sich mit Sicherheit die "richtige" Organisation der Daten im Speicher bemerkbar machen!

Hi,
altbekanntes "Problem", denn lt. Windowsparadigma hat sich jedes Programm selbst um seine Fenster(-inhalte) zu kümmern!
Da wird dann bspw. "nur um ein Item einer Listview hinzuzufügen" eine unglaubliche Menge Messages abgefeuert, und so gut wie sämtliche Funktionen, welche das BS zur Verfügung stellt, abgeklappert. Und natürlich wird bei jedem deiner 4000 Items nachgeschaut, ob dieses jetzt gerade nicht zufällig doch dargestellt werden soll....

Abhilfe schafft, die Darstellung bei bestimmten Operationen einfach abzuschalten. Damit wird verhindert, dass der gesamte Rattenschwanz an Funktionen zur Fensterdarstellung (da reicht eine Mausbewegung im Fenster! ) ausgeführt wird.
Windows ist idR so clever, bei bspw. einem WinSetState() (in anderen Programmiersprachen heisst die Bildschirmaktualisierung anders) nur den zzt. im Fenster sichtbaren Bereich upzudaten. Das geht auch Ruckzuck!
In VBA wird per ScreenUpdating = False bei so manchem Script der Turbo eingeschaltet. Faktor 10 und schneller sind da keine Seltenheit!
Würde mich wundern, wenn man in AutoIt so nicht auch zum Erfolg kommen könnte....

Interessant ist, welche Wörterbücher verwendet werden. Ich habe im jugendlichen Leichtsinn gedacht, in der deutschen Wikipedia würden so gut wie alle Wörter verwendet werden, aber das war ein Irrtum.
Mittlerweile habe ich einen ganzen Pool von Wörterbüchern, in Englisch ist das Ganze noch viel schlimmer, da gibt es Wörterbücher nur mit Eigennamen, Ortschaften, Straßennamen uswusf. allein die Suche danach ist eine Sysiphosarbeit!
Wer übrigens denkt, "Na dann mach doch aus den ganzen Wörterbüchern ein großes bzw. füttere damit eine Datenbank", der sollte sich mit dem Thema mal intensiv beschäftigen, VIEL Geld und vor allem Zeit und einen Haufen Mitarbeiter zur Verfügung haben und dann gegen rennomierte Institute in den Ring steigen

Hi,
schau dir mal an, wie man Scripte debugged! Und dabei würde helfen, wenn du dir bei dieser Gelegenheit in der Hilfe (gibts auch auf Deutsch! ) den Abschnitt über die Datentypen zu Gemüte führst.

In deinem Beispiel mit der $variable schreibst du nicht den WERT 50 der Variablen in den String, sondern den Text "$variable1"
Um Strings und Werte miteinander zu verbinden, benutzt man in AutoIt das & - Zeichen

,"{" & $variable1 & " 50}"

Hi,

Zitat von Techmix

Testläufe: "GPU" = 780Fps (richtiges Bild), "MULTI" = 580Fps (Doppelbildausschnitt)

yepp, hängt daran, dass du 2x den Puffer von der Graka ins RAM transferierst, was, wie schon oben beschrieben, wesentlich länger dauert als die eigentliche Berechnung!
Die oberen Halbbilder siehst du deshalb, weil du diese jeweils auch genau so darstellst. Lt. deinem Script ist das auch so gewünscht

Zitat von Techmix

Fehlt noch völlig... Man könnte den zweiten Parameter so abfragen, wenn ein Array übergeben ist wird der Kernel auf alle Devices verteilt und wenn ein $command_queue angegeben ist, soll der Kernel eben nur auf den einem Device ausgeführt werden. ...Diese globale Variable $KernelSource ist völlig überflüssig und verwirrt den Techmix nu

Den Kernel auf alle Devices zu verteilen macht imho ja nur dann Sinn, wenn diese Devices auch verwendet werden sollen. Wir könnten das nun natürlich als "Standard" implementieren, also einfach erstmal per se den Kernel auf ALLE verfügbaren Devices verteilen (wird ja aber schon gemacht, über die einzelnen Command-Queues)

So wie es aussieht, funktioniert ja bei dir schonmal die Darstellung so, wie ich mir das vorgestellt hatte.

Zitat

; Ich komme einfach nicht darauf WIE ich den Kernel sagen kann, das er bei 'stop' aufhören soll.. (if (threadid = stop+1) {break}) ?!?
; Momentan wird dieser trotzdem durchlaufen aber alle Berechnungen und die Rückgabe werden ausgelassen

Naja, ich denke, es gibt noch Erklärungsbedarf....
Du musst, ausser bei speziellen Aufgaben (wenn Ergebnisse synchronisiert werden müssen), den Kernel überhaupt nicht bearbeiten!
Durch die Kernelparameter legst du fest, welche "Teilbereiche" des Bildes berechnet werden.
Beispiel Apfelmännchen/Mandelbrotmenge.
Welchen "Bildausschnitt" du angezeigt bekommst, bestimmen AUSSCHLIESSLICH die Kernelparameter. Der Kernel (Rechenvorschrift) berechnet immer nur EIN EINZIGES Pixel (ThreadID)!
OpenCL verteilt nun diese eine Rechenvorschrift auf alle verfügbaren Recheneinheiten.
Ich schreib mal ein Beispiel

Zitat von Techmix

Kernelintern wird ja width*height berechnet, entspricht also $DATA_SIZE, die Rückgabe des Kernel soll ja nur $DATA_SIZE/2 groß sein - entsprechend müssen die Buffer also auch nur die Größe von $DATA_SIZE/2 haben. Richtig?

Jein (eigentlich ein klares NEIN )
Kernelintern wird EIN Pixel berechnet! Anhand der get_global_id(0). Sonst NIX! Punkt!
WELCHES Pixel berechnet wird, entscheidet ausschliesslich OpenCl. Ansonsten würde niemand ( niemand!!!! ) eine parallelle Berechnung brauchen!
Ich habe schon OCL-Kernel von gestandenen Programmierern gesehen, die sich darüber ausgelassen haben, dass der Kernel so unglaublich langsam seien. Das lag genau an deinem Problem! Die sind einfach hingegangen und haben den Kernel so geschrieben, dass ALLE Workitems (von ca. 1000 verfügbaren) ALLE Berechnungen für den gesamten Speicherbereich durchgeführt hatten. Das wäre so, als ob jedes einzelne Workitem ALLE Pixel des Apfelmännchens berechnen würde. Und das 1000 mal...umgangssprachlich nennt sich so etwas SCHWACHSINN! Die würden niemals auf die Idee kommen, 1000 Threads anzuwerfen, um in jedem Thread die KOMPLETTE Berechnung durchzuführen. Dieses "Problem" durchzieht die Foren wie ein roter Faden!

Aber dass jeder einzelne Puffer bei Verwendung von 2 Geräten jeweils nur halb so groß sein muss, hast du ja richtigerweise festgestellt! Wenn man 2x die Hälfte berechnet, kommt immer noch ein Ganzes raus

Bzgl. deiner Frage zu den Threads, da mache ich mir keinen Kopp! Ob das nun "Parallelisierung" heisst, oder "Threading", ist mir persönlich schnurz. Wichtig ist, dass man begriffen hat, WIE muss mein Kernel aussehen, damit ich das Problem in möglichst VIELE Einzelteile zerlegen kann, welche ALLE gleichzeitig(!) berechnet werden!
Beispiel: Einzelne Buchstaben in einem String zählen
Schreib doch mal einen Kernel, der sämtliche "a"´s (oder ggf. nur die Vokale) in einem Text zählt....

Da die solve-Funktion sowieso in eine eigene Datei ausgelagert sein soll, ist es imho egal, ob dort noch weitere Funktionen mit drinstehen!

So schön wie MakeGrafik das erklärt hat, macht das übrigens auch jeder Compiler.
Ins Eingemachte geht es dann, wenn man sich Gedanken über Array of Structs (AoS) oder einer Struct of Arrays (SoA) macht. Mit dem, was MakeGrafik erklärt hat, wird hoffentlich klar, dass es bei Speicherzugriffen eben NICHT völlig unerheblich ist, ob die Daten direkt hintereinander im Speicher liegen (und somit über den Prozessorcache x-mal schneller gelesen werden können) oder über den "falschen" Index angesprochen, völlig verteilt im Speicher liegen (Cachemisses/Cachepollution bei jedem Zugriff)
Bei diversen Programmen, welche intensiv mit gespeicherten Daten arbeiten (Datenbanken) wurde schon Faktor 2.5 bis 3 an Beschleunigung erreicht, NUR weil von AoS auf SOA umgestellt wurde, also aus einem Array[x][y] ein Array[y][x] gemacht wurde!

Zitat von rynow

???? Wie kann ich eine Array in ein struct setzen?

Du musst nur definieren, was dein Array als Inhalt hat!

Dim $a[11] ;nullbasiert
$struct = DllStructCreate("int[10]") ;einsbasiert

For $i = 1 To 10
$wert = Random(1, 100000, 1) ;irgendeinen wert
$a[$i] = $wert ;wert in array
DllStructSetData($struct, 1, $wert, $i) ;wert in struct
Next

For $i = 1 To 10 ;auslesen
ConsoleWrite("Array = " & $a[$i] & @CRLF);array
ConsoleWrite("Struct = " & DllStructGetData($struct, 1, $i) & @CRLF)
ConsoleWrite("Struct = " & _a($i) & @CRLF & @CRLF)
Next

Func _a($inhalt) ;dllstructgetdata in "kurz"
Return DllStructGetData($struct, 1, $inhalt)
EndFunc ;==>_a

Im AutoIt-Array hast du den unschlagbaren Vorteil, verschiedene Datentypen mischen zu können, ohne dich um die ....Datentypen kümmern zu müssen, "variant" sei Dank!
Allerdings muss man beim Zuweisen bzw. Auslesen sowieso die "richtigen" Datentypen haben, also kann man sie auch direkt in bspw. einer Struct definieren.
Übrigens ist die "Arrayschreibweise" nichts anderes als ein einfacheres Abbild der Datenstruktur (sic) im Speicher! Intern liegen die Daten sowieso in einem Speicherbereich, ob man den nun Struct, Liste, verkettete Liste oder was auch immer nennt, ist unerheblich.

/EDIT
Um das mal deutlicher zu machen, bis auf die blutigsten Anfänger würde es niemandem einfallen, beispielsweise die Pixel in einem Bild in ein Array einzulesen, dann zu bearbeiten und dieses Array dann wieder in Pixel zu übertragen.
Eine Bitmap IST bereits ein Array, genau wie die Daten in einem WMV-Musikstück, der Text in einem *.au3-Script uswusf

Es ist völlig egal, in welcher Form die Daten übergeben werden, Hauptsache ist, es werden genügend Bytes reserviert
Und ob man ein 3D oder nD-Array übergibt ist auch unerheblich, bis es 3D-Speicher gibt, dauert es noch etwas. (ok, ne tesafilmrolle wird ja schon als 3d-Speicher beworben)
Speicher ist grundsätzlich linear angeordnet, also ist das bei Arrays genauso!
Übrigens kann man sich, wenn man denn weiss was man tut, komplett auf Arrays verzichten! Mit DllStructs sind idR. in höherer Geschwindigkeit identische Funktionen wie bei Verwendung von Arrays machbar.
Die Umwandlung wie bei rynow kann man sich also sparen^^

Zitat von General Kaboom

Warum nicht einfach WIRKLICH ein Sudoku-Löser..

Weil wir das schon hatten? µIt-März 2009
Übrigens eines meiner Lieblingsbeispiele für ASM-Programme. Ein Sudoku-Löser incl Ein- und Ausgabe in 62 (zweiundsechzig) Bytes!

Habe schon einige Runden "von Hand" gespielt, und natürlich schon angefangen zu "botten"

Genau wie beim Sudoku-Löser bei dem es "gute" und "böse" Sudokus gibt, ist das hier natürlich auch so!
Daher würde ich, damit alle Teilnehmer wirklich gleiche Voraussetzungen haben, auch jedem Teilnehmer eine bestimmte Anzahl Rätsel vorgeben, die der Lösungsalgorithmus dann knacken muss. Ich denke, 30 bis 50 sollten reichen.

@Mars,
beim "von Hand" spielen habe ich festgestellt, dass ab und zu zusammenhängende Farben nicht vollständig "eingegraut" werden. Bspw. wurden in einem Fall ein "Winkel" von 3 waagrechten und drei senkrechten, also 5 zusammenhängenden Flächen nicht vollständig grau. Die 3 Waagrechten wurden grau, die beiden Senkrechten blieben farbig. Seltsamerweise wurde beim nächsten Zug mit dieser Farbe wieder nicht beide, sondern auch nur ein Feld eingegraut.
Das ist mir öfter mit verschiedenen zusammenhängenden Feldern aufgefallen. Absicht ist das nicht, oder?

//EDIT
Bin zzt. bei einem 16x16 Feld bei einem Schnitt von 33 Zügen, fast so gut wie "von Hand" (nur minimal besser)
Aber die "Streuung" ist viel zu hoch, Züge von 28/29 wechseln sich mit >40 ab. Übrigens ist das bei "von Hand" ebenso!

Anhand der Pointer kannst du natürlich auch verschiedene Structs an EINER Speicherposition erstellen und somit bestimmte (Teil-) Daten schreiben oder lesen.

HIER ein Beispiel, wie man so etwas gebrauchen kann, der gesamte Thread ist übrigens lesenswert.

Hi,

eine Struct ist doch nichts weiter als ein Array?!
Darin kannst du natürlich jedes Element einzeln ansprechen.

$struct = DllStructCreate("BYTE[8]")

for $i=1 to 8
dllstructsetdata($struct,1,$i*10,$i)
next

$ANTWORT_BYTE1 = DllStructGetData($struct, 1,1)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ANTWORT_BYTE1 = ' & $ANTWORT_BYTE1 & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$ANTWORT_BYTE2 = DllStructGetData($struct, 1,2)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ANTWORT_BYTE2 = ' & $ANTWORT_BYTE2 & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$ANTWORT_BYTE3 = DllStructGetData($struct, 1,3)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ANTWORT_BYTE3 = ' & $ANTWORT_BYTE3 & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console
$ANTWORT_BYTE4 = DllStructGetData($struct, 1,4)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ANTWORT_BYTE4 = ' & $ANTWORT_BYTE4 & @crlf & '>Error code: ' & @error & @crlf) ;### Debug Console

Das was du suchst, ist der "Index" (s. Hilfe zu DllStructGetData() )