Beiträge von Andy

Hi,

Zitat

Also manipuliere ich mit WinSetTitle über die Microsoft-Desktopmanager-API das eigene Fenster - krass. Von Hinten durch die Brust.

wie auch sonst?! Oder glaubst du, das "eigene" Fenster wäre etwas besonderes?

Zitat

Und die Funktion WinSetTitle habe ich (leider) in meinen Überlegungen nicht einbezogen, da ich sie als Methode zum Manipulieren von anderen, externen Fenstern wahrnahm - ich suchte halt nach einen "internen" Lösung - die es anscheinend nicht gibt. Eigentlich eine Funktions-Lücke.

Wenn du "interne" (was das auch immer für Funktionen sein mögen) brauchst, steht dir frei, eigene Funktionen zu schreiben!
Allerdings habe ich immer noch nicht verstanden, was der Unterschied von "deinem" zu den "anderen" Fenstern sein soll?! Wie anders als über die API willst du API-spezifische Funktionen verwirklichen?

Hi,

Zitat

Sucht man in den Foren oder über eine Suchmaschine nach GUICreate und GUICtrlSetData

Ich dachte, du wolltest den Fenstertitel ändern?!
Dann sucht man in einer Suchmaschine mittels

fenstertitel ändern site:www.autoit.de

und bekommt die entsprechenden Treffer.
Oder man sucht in der AutoIt-Hilfe, um

WinSetTitle()

zu finden...

-Update 13.07.2013
Assembler-Code angepasst bei der Kräfteberechnung von 1/sqrt() ^4 zu 1 / sqrt() ^3 (Thx an eukalyptus), beeinflusst die Benchmarkergebnisse nicht.
Vergleichbare Berechnungsschritte pro Sekunde zum Benchmark hinzugefügt
Setzen der Prozessorflags FTZ Flush To Zero und DAZ Denormals Are Zero, um auch bei unterschiedlichen Betriebssystemen gleiche Startparameter für das Behandeln von Floating-Point-Exceptions zu erhalten.

Beim Testen ist mir aufgefallen, dass eine höhere Threadanzahl eine höhere durchschnittliche Performance nach sich zieht!
Die Antwortzeiten der Threadschleife werden besser, was die Schlussfolgerung nach sich zieht, dass einem Prozess mit mehr Threads auch mehr Rechenzeit zugeordnet wird.
Mit meinem 4-Core Prozessor bekomme ich bei 16 Threads die besten Durchschnittswerte.
Die ersten Threads sind extrem schnell "fertig", je weniger Threads noch zu bearbeiten sind, desto länger dauert deren Ausführungszeit.
Ich werde mal testen ob es sich lohnt, einen neuen Thread anzuwerfen, sobald einer fertig geworden ist. Zzt. wird ja so lange gewartet, bis ALLE Threads fertig sind.

Weiterhin habe ich keine Auswirkungen beim Setzen bzw. Ausschalten der Prozessorflags FTZ Flush To Zero und DAZ Denormals Are Zero bemerkt. In der Literatur wird von stark verbesserter Performance gesprochen, ihr könnt das ausprobieren, indem ihr die entsprechenden Zeilen im Assemblercode (ganz am Anfang) aus bzw. einschaltet. (Neu Assemblieren danach nicht vergessen^^)

Um die Ergebnisse der verschiedenen Prozessoren untereinander vergleichbar zu machen, wurde beim Benchmark der Wert "Steps per second" eingeführt. Er beschreibt die Anzahl der Berechnungsschritte pro Sekunde (ähnlich FPS).

Ohne hier jemandem zu nahe treten zu wollen...
Wenn ICH suche, dann finde ich allein im Forum hunderte Treffer.
Auf der ersten Seite u.a. diesen Thread und hier , in dem die schnellsten Dateisucher gegeneinander antreten und verglichen werden.
Wenn ich mich recht erinnere, gab es sogar mal einen µ-It zu diesem Thema.

Und btw. mit Wildcards in der Hilfe suchen bringt am allermeisten...Ich habe noch nie ohne die * vor und hinter dem Suchbegriff gesucht.
Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Hi,

Zitat

Ich dachte erst, meine Funktion wäre abgestürzt.
Nein, Excel ist wirklich so langsam!

dann sei froh, dass du in Excel nicht VBA benutzt, um die DB-Abfrage zu machen, DAS ist langsam....

Ich habe auch bisher noch nicht herausgefunden, wieso AutoIt, wenn ich bspw. in einer Exceltabelle durch die Zeilen loope, ca. 10x schneller ist als die äquivalente Schleife in VBA!

idR bin ich auch dafür, die Spracheinstellungen innerhalb des Scripts OHNE Neustart zu verwalten, allerdings hat die Version von Xor den großen Vorteil, dass man verschiedene "Spracheinstellungen" gleichzeitig geöffnet haben kann (man muss nur das EXIT nach dem shellexecute entfernen).
Alle Wege führen nach Rom

i2c weist auf die

AutoItSetOption ( "option" [, param] )

hin, und dort speziel auf den GUICoordMode

klick mal hier im Forumstext auf den AutoItSetOption-Schriftzug, dann sollte die Online-Hilfe dazu direkt aufgehen

Zitat

ok ich bin heute offenbar extrem blöd, sorry!

NEIN! Das liegt einfach daran, dass du dir die "nützlichen" Erweiterungen von Scite nicht auf die F2-F10 Tasten legst...und diese auch benutzt!
OrganizeIncludes liegt bei mir auf der F2, AlignComment auf der F4, SendToPastebin auf der F6, F1, F3+F5 ist klar^^
F7-F10 habe ich mit internen Scripten belegt.

Die Arbeitsmittel haben sich an den Menschen anzupassen, nicht umgekehrt!

...und subjektiv betrachtet (das ist ein Wortspiel^^) sieht sowieso niemand den Unterschied!

Zitat

Dafür dass der PC schon fast 5 Jahre alt ist und die früher nach dieser Zeit hoffnungslos veraltet waren, ist mein Prozessor im Vergleich erstaunlich gut:

im Vergleich zu den in der c´t mit diesem Algorithmus beaufschlagten Kalibern wie XEON ES, Opteron und XEON Phi schlagen sich die 08/15 Prozessoren hier erstaunlich gut! Gegen die Tesla K20x mit CUDA-Kerneln ist aber kein Kraut gewachsen....
Weder wurde im vorliegenden Programm AVX verwendet (bringt ca. Faktor 2), noch irgendwelche schweinischen Tricks wie "flush denormals to Zero" (fängt underflows ab). Ich glaube mit einigen weiteren Optimierungen könnte man sogar noch etwas Speed herausholen.
Als C/C++-Programmierer hat man es einfach und die Optimierungen sind ruckzuck per diversen Compilerschaltern erledigt. WENN man SoA beachtet, ansonsten hilft einem der schönste und beste Compiler nichts, ein schlecht designtes Programm optimiert auch kein INTEL-Compiler zu einem guten...wzbw.

Ich werde mal die Prozessorflags zur "schnelleren" Berechnung von floats aktivieren und ggf. noch Tiling (optimiertes Verfahren um die im Cache befindlichen Daten möglichst häufig zu nutzen) einbauen. Und mir von einigen von euch noch Tips fürs MultiThreading holen (müssen^^)
Dann wird es spannend, denn die Benchmarks soll(t)en in überschaubaren Zeiten auch bis zu 100000 Partikel berechnen 8o.

Ich hab mir schon diverse Profiling-Tools runtergeladen, leider habe ich es bis jetzt nioch nicht fertiggebracht, den Code zur Laufzeit zu untersuchen. Ggf. muss ich eine DLL erstellen, um Zugriff über die Symbolbibliotheken zu erhalten...
Kennt sich jemand von euch mit CodeAnalyst oder CodeXL aus?

Zitat

Ist ja nicht selbstverständlich solche Hilfestellungen zu geben

Hier schon, genau deshalb brauchen wir so ein LIKE-Gedöns auch nicht...

Zitat

hier mal von nem halbwegs altem Quad-Core(AMD)

hehe, ich glaube ich habe meine Aufrüstprozessor für meinen X2 250^^, den X4 955 gibts für 70€, der hält mit den doppelt so teuren Intels ja locker mit
...wobei es für einen 10er mehr gibts schon nen Quadcore-Piledriver mit FM4A und AVX
...und für noch nen 10er mehr gibts den als 6-Core....ich denke, da gibts nicht mehr viel zu diskutieren

Zitat

Ist noch wesentlich mehr drin, da lief noch so einiges nebenbei. Außerdem bleibt die CPU konstant bei 2.20 GHz, und feuert nicht in den Turbo.

Das würde ich gerne sehen, denn imho schalten die INTEL Prozessoren einen Core nur dann in den Turbo-Modus, wenn dafür ein anderer Schlafen gelegt wird.
Daher auch der Vorsprung der single-thread-Performance gegenüber AMD.

Starte doch mal mit nur einem oder zwei Threads, dann sollte sich der Turbo einschalten. Dann aber den Prozessortakt mit bspw. CPUZ verifizieren und per Hand in das Ergebnis eintragen.
Bei mir funktioniert die richtige Darstellung des Prozessortaktes im Benchmark nicht (ich benutze K10STAT )

Benchmark n-Body-Simulation


Number Particles:		30000
Processor:		AMD A6-3400M APU with Radeon(tm) HD Graphics
Number Processors(Cores):	4
Number Threads:		1
Overall Time:		38.16 Seconds
Number Loops benchmarked:	26


Average Interacts/sec:	2.56e+009
Maximum Interacts/sec:	2.57e+009


Average Ticks/Interact:	8.72    CAUTION! Depends on real Clockticks!
Minimum Ticks/Interact:	8.69    CAUTION! Depends on real Clockticks!


Average Clockticks[Mhz]:	2300 ungefähr, 
Maximum Clockticks[Mhz]:	2667   der maximale Takt liegt immer an dem Core an, der vorher ohne Last war!  Geht also bei jedem gestarteten thread auf einen anderen Core


Average Looptime:		1406.88 Milliseconds
Fastest Looptime:		1398.86 Milliseconds

Das sind zwei unterschiedliche Methoden.
Bei der Abfrage per GuiGetMsg() läufst du gewissermassen "zu Fuß" ständig durch die Liste der Windows-Ereignisse (Events) und wartest bis bspw. das passende "Buttonpressed"-Ereignis in der Liste auftaucht. Dann kannst du z.B. eine Funktion anspringen und dieses Ereignis auswerten.
Beim OnEventMode verknüpfst du ein Ereignis (Event) mit einer selbstgeschriebene Funktion und überlässt Windows das komplette Handling. Sobald das Ereignis abgefeuert wurde, ruft Windows deine Funktion auf. Das ist zwar "schöner" aber auch etwas aufwendiger zu implementieren.

Zu Anfang sind die Scripte nicht so aufwendig, dass man den OnEventMode bräuchte^^

Oscar hat natürlich Recht!
Generell gehören die Sleeps() nicht in eine GuiGetMsg()-Schleife. Im vorliegenden Fall gings eher um die Logik, und bei "kleinen" Sleeps taucht das Problem auch nicht auf

Hi,

Zitat

Wenn ich rdtscp herausnehme, dann läuft das Script - allerdings ohne Benchmark.

Vielen Dank für diese Info!
Warum und wieso das so ist, kann ich allerdings nicht nachvollziehen.
Ich meine irgendwo gelesen zu haben, dass Windows die Benutzung der TSC Time-Stamp_Counter einschränken kann. Also sollte man das auch irgendwo "freischalten" können, ggf. hängt das hiermit zusammen.
Die Performance-Counter sind bei mir (Win7-64) soweit ich das sehe, freigeschaltet. Eingabeaufforderung: perfmon

// EDIT stürzt das Script bei der Verwendung von nur einem Thread auch ab?
// EDIT2 RDTSC muss bei mehreren Threads serialisiert werden, neue Version in Post #1, bitte mal neu benchmarken und die neuen Ergebnisse mit den alten vergleichen, gibt es Unterschiede?

An deiner Stelle würde ich schnellstens posten, WIE du es hinbekommen hast und ggf ein Script anhängen.
Ansonsten kannst du dir sicher sein, dass dir beim nächsten Mal kaum jemand hilft.
Dieses Forum lebt davon, LÖSUNGEN zu bieten! Wenn hier ein Suchender im letzten Post des Threads lediglich liest: "Ich hab jetzt anders hinbekommen!", dann ist das keine Hilfe sondern ein Armutszeugnis für die User dieses Forums und eine Beleidigung für jeden Helfer in diesem Thread!

ggf suchst du auch

FileSelectFolder("Ordner wählen", "")

Marthog,

Zitat

Zur Zeit machst du es auch so, dass du jeden Frame neue Threads erstellst, dabei geht natürlich auch Zeit verloren. Dann kannst du in der Schleife, die wartet, bis alle Threads beendet haben, auch noch Sleep(0) einbauen, denn dadurch gibst du anderen Threads die Chance zur Ausführung.

Da hast du sicherlich Recht.
Ich habe testweise

Until $flag = 1 and sleep(10)

eingebaut, aber bei kleinen Anzahlen Partikeln (<10000) bietet der Schleifenoverhead von Autoit genug Zeit zum Interrupten, und bei Partikelanzahlen von >30000 und allen Cores unter Volldampf habe ich, egal, welche Sleeps eingestellt sind, Mausruckler und Unterbrechungen beim bspw. Fensterschieben. Was aber auch an meiner schwachbrüstigen CPU liegen kann.
Ausserdem möchte ich ja sehen, was der Prozessor macht, wenn er nicht in jeder Millisekunde 50x in den tiefschlaf fällt

Eine weitere Möglichkeit wäre, sofort nach Beenden eines Threads einen neuen anzuwerfen und die Anzeige alle 50ms aufzurufen, schaumamal was das bringt

Klar, mache ich...

Dann werde ich aber auch auf deine Funktionen zur Ermittlung des genauen Prozessortaktes zurückgreifen müssen. RDTSC ist bei den neueren Prozessoren nämlich ABHÄNGIG vom Takt!
Es ist definitiv nicht (mehr) so, dass die Time-Stamp-Counter bei jedem Takt um eins erhöht werden, vielmehr ist noch ein Teiler eingebaut, der abhängig vom Bustakt ist!
Wieder ein eingebauter Stolperstein, um zu verschleiern, dass die neuen Prozessoren keinen Deut besser sind, als die "alten"!