[Beendet] µitLight März

MatthiasG.

Hallo UEZ!

Zunächst danke für deine Messungen! Meine sind ungefähr *2 zu nehmen. Ich hatte zu jeder Belastung 3 Messungen durchgeführt:

Gering belastet: Anwendungen: explorer.exe, SciTE, TaskMgr + laufendes Skript
Mittlere Belastung: Anwendungen: explorer.exe, SciTE, TaskMgr, Firefox (5 Tabs offen, 1 x 100.000 Primzahlen ;); 4 x versch. Flash-Animationen), Thunderbird + laufendes Skript; Vorbereitung: 10 min. rendern eines 3D-Bildes zum "Vorheizen". Glas
Höchste Belastung: Anwendungen: explorer.exe, SciTE, TaskMgr, Firefox (s.o.), Thunderbird, Cinema4d rendert Glaskugeln; Vorbereitung: 2 Stunden rendern einer Animation zum "Vorheizen"

Danach habe ich den Durchschnitt ermittelt, aufgeschrieben und aus den 3 Durchschnitten einen weiteren Durchschnitt gerechnet.

Ich habe die Rechnungen nicht hintereinanderweg gemacht, sondern natürlich Pausen drin gehabt. Ich habe immer versucht, dass möglichst gut zu reproduzieren. Natürlich gehen die Messungen etwas auseinander, habe jetzt aber als Richtwert meinen etwas betagteren WinVista-Laptop genommen (mein Liebling noch dazu).

Entschuldige bitte vielmals, ich habe nur das Atkin in meinem Ordner gefunden, es kann sein, dass mir das weitere fehlte. Ich werde mich leider erst morgen an die Messungen setzen können und das Ganze ergänzen. Aufgrund deiner Zeiten wird aber auch RAPTOR-ONE für sein Skript 6 einen Schnelligkeitsaward erhalten.

Gruß,
Matthias

**Schnitzel**

Wow.
Ich hätte zwar schon gedacht dass ich gut dabei bin aber das nicht...

Danke den beiden Organisatoren: MatthiasG. und Leviathan.
Wirklich ne super Sache dass ihr euch Wettbewerbe einfallen lässt und euch die Zeit nehmt sie auszuwerten.
Ist sicher ne Menge arbeit. Wirklich toll.
Das war wirklich ein sehr intressanter µLight.
Hat richtig Spaß gemacht sich den Algo auszudenken.

**Andy**

Beim Auswerten der "Laufzeiten" sollte man sich bei AutoIt keine großen Gedanken machen. Einige Zehntelsekunden bzw. sogar Sekunden mehr oder weniger bei den einzelnen Durchläufen sind völlig normal. AutoIt bietet auch keinerlei Möglichkeiten, diese Streuung zu vermeiden.
Festplattenaktivitäten im Hintergrund sind generell für die Ausführungsgeschwindigkeit von AutoIt-Scripten störend. Weiterhin bemerkt man deutlich bei Datenbewegungen, ob diese im Cache gelegen haben. Apropos Cache, beim Experimentieren mit dem Assemblercode habe ich Geschwindigkeitssteigerungen von Faktor 100 (ja, das heisst 100x schneller) beim identischen Rechenalgorithmus festgestellt. Wenn man das bei AutoIt "einstellen" könnte wie z.B. bei einigen C-Compilern und seinen Algorithmus auf die Hardware (z.B. Cache) anpasst, werden die in AutoIt "langsamen" Algorithmen (komprimierte Siebe z.B. Atkin) plötzlich x-mal schneller als die bisher schnellen, "normalen" Algorithmen.

Fazit: Zum schnellen "Rechnen" ist AutoIt nur sehr bedingt zu gebrauchen, da reißen auch schnell(st)e Algorithmen nichts raus! Wer Rechengeschwindigkeit braucht, setzt "richtige" Compiler ein und/oder schreibt damit eine per AutoIt verwendbare DLL!
Dann wird aus einem Mofafahrer(AutoIt) bei Verwendung von C(++) ein Hayabusa-Fahrer. Aber selbst darüber kann ein Jetpilot, der mit Mach2 (C mit Hardwareoptimierung, s. Link) durch die Atmosphäre brettert, nur müde lächeln
Schönes Beispiel: http://primzahlen.de/files/referent/kw/sieb.htm

MatthiasG.

Hallo allerseits!

Hier meine nachgereichten Testergebnisse von UEZ - leider wird dieses Skript nicht bewertet, da es auf Nicht-Standard-Includes zugreifft (FASM.au3):

T1: 4488ms
T2: 6137ms
T3: 8920ms
Td: 6515ms
+ Zeigt schön, was über die "Standards" von AutoIt möglich ist!
- Leider Assembler - wäre auch zu schön um wahr zu sein

Der Wettbewerb ist nun entdültig beendet.

Nochmal herzlichen Glückwunsch und Dank für die Teilnahme!

Viele Grüße aus dem Pott,
Matthias

AntiSpeed

Hey
Sry, dass ichs noch poste aber ich kann einfach nicht:
Ich habe leider die langsame Art&Weise ausgewählt danach zu suchen. Die andere war mir damals zu komplizert (Alle Zahlen in String und dann immer Streichen).

Hier meine langsame UDF:

Spoiler anzeigen

[autoit]

Func _GetPrim($from,$to)
$prim=""
For $i=$from To $to
$t=""
For $e=2 To Round(Sqrt($i))
If StringInStr($i/$e,".") Then $t=$t&1
Next
If $i>3 And StringLen($t)=Round(Sqrt($i))-1 Then
$prim=$prim&","&$i
TrayTip("",@CRLF&$i,1)
EndIf
Next
If $from<=4 Then
If $to = 2 Then $prim=",2"&$prim
If $to >= 3 Then $prim=",2,3"&$prim
EndIf
$prim=StringTrimLeft($prim,1)
Return $prim
EndFunc

[/autoit] [autoit][/autoit] [autoit]

Func _IsPrim($i)
If $i = 1 Then Return False
If $i <=3 Then Return True
$t=""
For $e=2 To Round(Sqrt($i))
If StringInStr($i/$e,".") Then $t=$t&1
Next
If $i>3 And StringLen($t)=Round(Sqrt($i))-1 Then Return True
Return False
EndFunc

[/autoit]

und hier mal ein Versuch von mir (5min, dass eig. in 10sek geht wenn man die andere Art&Weise benutzt )
Alle PrimZahlen von 1-1Mio. (im Anhang)

**Andy**

Zitat

leider wird dieses Skript nicht bewertet, da es auf Nicht-Standard-Includes zugreifft (FASM.au3):

Naja, UEZ braucht die FASM.au3 ja nur zum "umwandeln" des Assemblercodes in den Bytecode. Das ist für das Script eigentlich völlig unwichtig. Genauso könnte man die WINAPI-Calls, aus denen sämtliche "hellblauen" AutoIt-Befehle (und auch die "dunkelblauen") größtenteils bestehen, verbieten. Die machen NICHTS anderes! Allerdings würde dann AutoIt natürlich nicht mehr funktionieren....Problem erkannt? JEDE Software wird im Endeffekt vom Prozessor ausgeführt.

Wenn UEZ den Bytecode in den Speicher schreibt ($bytecode=String(FasmGetBinary($Fasm)) und diesen dann aufruft, benutzt er garkeine Includes....s. Beispiel

Spoiler anzeigen

[autoit]

;Liste der Primzahlen bis $maximum
;32-Bit Bytecode by Andy, eine der ersten Versionen, daher unoptimiert und "langsam"

[/autoit] [autoit][/autoit] [autoit]

Local $maximum = 1299709 ;Obergrenze der Primzahlen
Local $file = "Prim_" & $maximum & ".au3" ;Datei, in welche die Primzahlen geschrieben werden

[/autoit] [autoit][/autoit] [autoit]

$t = TimerInit() ;Timestamp sichern
$tStruct = DllStructCreate("uint Limit;uint Limes;char Mem[" & $maximum + 10 & "]") ;char, dann kann man nachher schön mit den stringfunktionen suchen
;die folgenden 4 Zeilen sparen einige Zeilen Assemblercode, außerdem kann man sich den Speicherinhalt in AutoIt anschauen
DllStructSetData($tStruct, "Mem", "001") ;die ersten 3 Zahlen setzen, 0=0 1=0 2=1 , 2 ist die erste Primzahl
DllStructSetData($tStruct, "Limit", $maximum);limit in die Struct schreiben
DllStructSetData($tStruct, "Limes", Floor(Sqrt($maximum)) + 1);wurzel aus limit in die struct schreiben
$bytecode = "0x558B6C24088B5D00B803000000C74405083130313083C00439D876F189EF83C70889FE8B4D00BB0300000089D8F7E0C604063001D839C87CF683C3023B5D007737803C1E3175F2535189D8BB0A00000031C931D2F7F3665280C10109C075F366580C30AAE2F9C6070D83C701595B3B5D047CB83B5D007CC1C607005DC3"
$tCodeBuffer = DllStructCreate("byte[" & StringLen($bytecode) / 2 & "]") ;Speicher für den bytecode reservieren...
DllStructSetData($tCodeBuffer, 1, $bytecode);...und mit dem Bytecode beschreiben
;die folgende Zeile startet den bytecode im Speicher und kehrt danach hierher zurück
$a = DllCall("user32.dll", "int", "CallWindowProcW", "ptr", DllStructGetPtr($tCodeBuffer), "ptr", DllStructGetPtr($tStruct), "int", 0, "int", 0, "int", 0);bytecode aufrufen, rückgabe in a[0]

[/autoit] [autoit][/autoit] [autoit]

$primzahlen = "2" & @CR & "3" & @CR & DllStructGetData($tStruct, "Mem");2 und 3 sind die ersten Primzahlen, dann folgt der Rest
$m = TimerDiff($t) ;Zeit seit Programmstart

[/autoit] [autoit][/autoit] [autoit]

FileDelete($file) ;Primzahldatei löschen
FileWrite($file, $primzahlen) ;Ausgabe der Primzahlen in Datei
$m1 = TimerDiff($t);Zeit seit Programmstart incl Datei schreiben

[/autoit] [autoit][/autoit] [autoit]

StringReplace($primzahlen, @CR, @CR, 0, 1) ;alle CR im String zählen.....auch AutoIt hat SPEEEEED^^
$anzahlprim = @extended ;hätte man auch vom Assembler zurückgeben lassen können^^

[/autoit] [autoit][/autoit] [autoit]

MsgBox(262144, "Primzahlen bis " & $maximum, $anzahlprim & " Primzahlen ermittelt in " & Int($m) & " Millisekunden" & @CRLF & _
"Primzahlen ermitteln und in Datei schreiben in " & Int($m1) & " Millisekunden." & @CRLF & _
"Ausgabe der Zahlen folgt in die Datei " & $file & @CRLF & _
"Die Primzahldatei wird nun angezeigt...")
ShellExecute($file) ;in Scite anzeigen

[/autoit]

Wäre der Abräumer bzgl Geschwindigkeit und Kompaktheit des Codes....oder war verboten, Prozessormnemonics zu verwenden?

MatthiasG.

Hallo Andy!

Ja, ein Code wird natürlich auf dem Prozessor ausgeführt (mal von Nvidias CRUDA ganz abgesehen ;)).
Nein, es stand nirgendwo verboten, dass "Prozessormnemonics" nicht verwendet werden dürfen.

Soweit richtig, aber mir geht es eben um diesem FASM-Include. Indirekt müsste ich ja rein theoretisch dann auch eukalyptus Variante erlauben: Er benutzt doch auch keinen wirklich wichtigen Include.

Das wäre aber ungerecht den "Unerfahrenen" gegenüber. Grundsätzlich soll sich der µitLight nur auf natives AutoIt beziehen - alles was darüber hinaus geht wird in der Aufgabenstellung erwähnt - hier Datenbanken z.B., im Captcha-Wettbewerb GDI+ (da es zu den Standard-Includes gehört).

**UEZ**

Ich wollte nur erwähnen, dass mein Code von Post#106 keine extra Includes benötigt und der ASM Code von mir geschrieben wurde mit reichlich Unterstützung von Andy (keine 3rd party DLLs!)

Der Code beinhaltet die AU3 + ASM (als Bytecode) Versionen!

Was ist nativer AutoIt Code? Nun ja, darüber kann man sich streiten...

Da stimme ich mit Andy überein. Z.B. sind alle WinAPI oder GDI+ Aufrufe keine nativen AutoIt Codes, denn die DLLs erledigen ja die Arbeit, was in Maschinensprache erfolgt!

In Zukunft sollte man besser die Rahmenbedingungen definieren, damit es nicht zu Ungereimtheiten kommt.

Gruß,
UEZ

**Andy**

Ja, es soll nicht der Eindruck aufkommen, daß AutoIt nur als Wrapper für einen (schnelleren/anderen) Code benutzt werden kann. Weil genau das nicht der Sinn eines µ-It ist, habe ich ja auch meine (Asm)-Varianten ausgeklammert.
Vielleicht sollte man sich darauf einigen, daß keine anderen externen Funktionscalls als die in den mit der aktuellen AutoIt-Version mitgelieferten UDF´s verwendet werden sollten. (umpft, was ein Satz....)

"Native" gefällt mir einerseits gut, aber in meinem Beispiel aus #126 ist auch alles "native"^^. Aber ich denke, wir verstehen uns...
Der Ärger fängt ja schon damit an, daß die "getunten" Scripte nicht unter 64 Bit usw laufen.

Die Richtung ist klar, fehlt nur noch eine Idee fürs nächste µ-It, aber da steckt mir schon was in der Nase....

MatthiasG.

Abend UEZ, abend Andy!

Verbleiben wir so: ich werde den Regel-Threat noch mal rauskramen und einmal überarbeiten, klarer formulieren - ist das ein Angebot?

Gute Nacht/Abend/Morgen - bitte das passende aussuchen

Matthias