Schreibe/kopiere "Männer" in die Console
Öffne in Scite eine EXE-Datei, der Inhalt der Console müsste dann "M寮er" sein...omg...nein, so nicht^^
MxE4nner steht dann bei mir.
Ich vermute(!), Scite versucht, beim Öffnen einer Datei "richtig" zu kodieren, und passt entsprechend die Console an.
Dann würde es reichen, die geöffnete Datei in einer bestimmten Kodierung zu speichern und dann wieder zu laden. Dann müsste die Console auch wieder "richtig" kodieren.
Ihr seid ja gemein!
Bei jeder eurer Lösungen wird vermieden, dass man sein eigenes Geschenk wichtelt! Dabei ist das doch das eigentlich Interessante an der Sache! 
Hi,
ich habe festgestellt, dass die Consolenausgabe je nach Dateityp der in Scite geladenen Datei die entsprechende (falsche) Kodierung anzeigt!
Relativ einfach nachzuprüfen:
Kopiere txt mit Umlauten in die Console, öffne diverse Dateien, der Consoleninhalt wird "mitgezogen". Wenn ich eine bspw. aus einer CMD erstellte Textdatei oder eine EXE im Scite-Editor öffne, verändern sich die Umlaute in der Console!
So wie ich das sehe, versucht Scite die Kodierung je nach geladenem Dateiformat "anzupassen". Entsprechend ändert sich nicht nur der Inhalt im Editor, sondern auch in der Console.
hi,
du musst doch nur die Abfrage in die Schleife packen
#include <ButtonConstants.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>
#include <GuiStatusBar.au3>
#include <StaticConstants.au3>
#include <EditConstants.au3>
Opt('GUIOnEventMode', 1)
Opt('TrayOnEventMode', 1)
Opt('TrayMenuMode', 1)
$Form1 = GUICreate("PN4000", 307, 150, 192, 124)
$Setting_Menu = GUICtrlCreateMenu("Menü")
$Setting_exit = GUICtrlCreateMenuItem("Ende", $Setting_Menu)
GUICtrlSetOnEvent(-1, "_Exit")
$helpmenu = GUICtrlCreateMenu("?")
;GUICtrlSetOnEvent(-1,"_Help")
$Info = GUICtrlCreateMenuItem("Info", $helpmenu)
GUICtrlSetOnEvent(-1, "_showInfo")
$Kommen = GUICtrlCreateButton("AUS", 32, 8, 113, 113)
GUICtrlSetFont(-1, 18, 800, 0, "@Arial Unicode MS")
GUICtrlSetBkColor(-1, 0x0000FF)
$Gehen = GUICtrlCreateButton("Reset", 171, 8, 113, 113)
GUICtrlSetFont(-1, 18, 800, 0, "@Arial Unicode MS")
GUICtrlSetBkColor(-1, 0x4452F0)
GUICtrlSetOnEvent(-1, "_RESET")
GUISetState(@SW_SHOW)
GUISetOnEvent($GUI_EVENT_CLOSE, '_Exit')
GUISetOnEvent($GUI_EVENT_MINIMIZE, '_Minimize')
TraySetOnEvent(-7, '_Restore')
While Sleep(100)
If ProcessExists("notepad.exe") Then
GUICtrlSetData($Kommen, "läuft")
GUICtrlSetBkColor($Kommen, 0x00FF00)
Else
GUICtrlSetData($Kommen, "läuft" & @CRLF & "nicht")
GUICtrlSetBkColor($Kommen, 0xFF0000)
EndIf
WEnd
Func _showInfo()
MsgBox(0, "Info", "Version 0.1 " & @CRLF & "Stand 31.10.2016")
EndFunc ;==>_showInfo
Func _Exit()
Exit
EndFunc ;==>_Exit
Func _Minimize()
TraySetState(1)
GUISetState(@SW_HIDE)
EndFunc ;==>_Minimize
Func _Restore()
TraySetState(2)
GUISetState(@SW_SHOW)
EndFunc ;==>_Restore
Func _RESET() ;Hier passiert was wenn der Button gedrückt wird
Run('Notepad.exe')
;ProcessClose("pn4.exe")
;RunAsWait("abc","neu","12346",0,@ComSpec & " /c " &'net stop "Autostart"',"",@SW_HIDE);Sleep (1000)
;RunAsWait("abc","neu","123456",0,@ComSpec & " /c " &'net start "Autostart"',"",@SW_HIDE)
EndFunc ;==>_RESETIch wette aber, dass es Compiler gibt die den Prozessor bis zum Rand ausreizen können.
Diese Compiler werden aber nicht beliebigen Sourcecode nur durch F5-Drücken in ein bspw. schnellstmögliches Ergebnis verwandeln (können).
"Bis zum Rand ausreizen" tun das heutzutage schon die Programmierer mittels Intrinsics(). Was allerdings nichts weiter als "SIMD-Funktionen per Hand eingefügt" ist! Und dafür kann der Compiler nix!
Die Computer die aktuell genutzt werden sind 0 bis 10 Jahre alt und haben 32 oder 64Bit. Jede "Generation" hat irgendwelche krassen Erweiterungen. Wenn man das optimal nutzen will müsste man den Code 50x Kompilieren (für jedes System einzeln) und beim Programmstart die richtige Version wählen
Ich kann mich an eine Ausgabe einer c´t erinnern, da wurden die damals "neuen" MMX-Befehle (damals exclusiv in x86-AMD-Prozessoren) händisch in ein Programm verpflanzt und auf Geschwindigkeit getestet. Gegenüber einem "normal" compilierten Code war erwartungsgemäß Faktor 2-3, je nach Problemstellung auch mal Faktor 5 in der Geschwindigkeit feststellbar. Was sich mir ins Gehirn gebrannt hat war die Tatsache, dass auf einem PowerPC das Compilat des Sourcecodes genauso schnell lief, wie der "handoptimierte" x86-Code.
Compiler DOCH besser als ein Programmierer? Nö, denn ein PPC hatte damals "von Geburt an" 64-Bit-FP-Register, und die wurden von den Compilern auch selbstverständlich konsequent umgesetzt! Von AltiVec ganz zu schweigen! Schauschau, die Vektorbefehle in Form von Intrinsics werden vom GCC in äquivalente x86-Befehle umgesetzt wenn für x86 compiliert wird, Crosscompiling ftw!
Wenn der Programmierer weiß was er tut, dann holt er auch das Optimum aus einem Compiler heraus! Wobei in diesem Fall (Verwendung von Intrinsics) der Compiler wiederum nichts weiter ist als ein Assembler, der den eingegebenen Code 1:1 umsetzt. Erfordert das seitens Programmierer "erweitertes" Wissen? Ja! Eine "erweiterte" Denke? Sicherlich! Wie hoch ist die Chance, einen solchen Programmierer zu erwischen? Geschätzt 5%!
Btw. Spielconsolen, Jahrzehnte dominierte der PPC die Spielconsolenwelt. Und da waren/sind "schnelle" Programme existentiell! Die Compiler/Programmierer wurden auf die Hardware "optimiert". Auch und gerade die Programmierer! "Schnellen" (auf die Hardware "optimierten") Sourcecode reinkloppen, F5 drücken, "optimales" Ergebnis! Funktioniert doch!
https://gcc.gnu.org/onlinedocs/gcc…ctor-Extensions 
Das "Auf den nächsten Interpreter/Compiler warten und damit das Programm schneller machen" wollte ich bei AutoIt auch schonmal machen.
...
Wobei man fairerweise sagen muss, dass bei einem Interpreter sowieso irgendwann das Maximum an Geschwindigkeit erreicht ist. Und ich denke, da ist AutoIt garnicht mal schlecht!
Ops, habe gelogen... denn seit ein paar Wochen spiele ich auch ein wenig mit AssembleIt rum...
Hast du schon die neueste Version mit dem "schicken" Debugger? Braucht man den/einen Debugger für 64Bit?
//EDIT
Überleg jetzt genau was du antwortest, ansonsten bist du mein Test-Opfer! Oder schlimmer noch, ich frag dich ob du mir dabei hilfst 
In einem (größeren) Unternehmen würde ich als Chef allerdings zumindest einen (guten) Programmierer damit beauftragen, immer ein Auge darauf zu haben, ob es sich bei eigenen Programmen lohnt, diese in ASM zu optimieren.
Naja, wenn 99,9% des Codes eines "guten" (HLL-)Programmierers sowieso nicht durch ASM zu toppen sind (da bin ich voll und ganz bei dir! ) stellt sich die Frage, ob es sich nicht lohnt, gleich einen "guten" Programmierer einzustellen, der (logischerweise) dann "optimalen" Code abliefert!
Die Antwort ist völlig klar, der "gute" Programmierer lohnt sich immer!
Nur, woher weiß denn der "gute" Programmierer, dass sein Code nahezu "optimal" ist, und wann weiß er, dass ein in ASM geschriebener (oder Sourcecodeoptimierter!!! ) Programmteil den Compiler um Längen schlägt?!
Das weiß er nur dann, wenn er sein Werkzeug kennt. Den Compiler und dessen Compilat. Und das auch "lesen" und verstehen/analysieren kann.
ASM hatte mich in vielen Punkten sehr begeistert, vor allem was Klarheit und Geschwindigkeit angeht. Nun befasse ich mich nur noch mit C, C++, AutoIt, FreeBASIC, Bash und PowerShell - mit C und C++ aber nur wegen spezieller Projekte. ....[snip]....FastIPrefs hatte das Original in fast allen Bereichen um Faktor 3~50 geschlagen, was Speed angeht, wobei wir unser Hauptaugenmerk nur auf erweiterte Funktionalität und maximale Stabilität gesetzt hatten. Heute würde ich ein so großes Projekt in ASM nur noch aus nostalgischen Gründen angehen
Wir sind uns einig, dass niemand mehr komplette Programme in ASM schreiben sollte, sondern ausschliesslich geschwindigkeits/größen-relevante Programmteile!
Aber genau DAS ist die Intention dieses Threads! F5-drücken reicht nicht... 
Btw., auch ich habe in den 80ern am liebsten mit der Kombination Basic / ASM gearbeitet. Basic für das Userinterface und in/output, ASM für den geschwindigkeitsrelevanten Teil.
Aber da war die Sache noch überschaubar, 8/16-Bit BS und (ASM/Compiler)Code haben die Hardware zu 100% ausgenutzt.
Heutige Prozessorfeatures werden von gängiger Software (Compiler!!!) garnicht oder nur halbherzig umgesetzt. Imho setzen die heutigen X86-Compiler "technisch" Code für ca. 20 Jahre alte Prozessoren um.
Die einzige Geschwindigkeitssteigerung heutiger Softwareprodukte resultiert aus der Compilierung mit einem "neuen" Compiler, der "schnelleren" Code aus dem "alten" Sourcecode erzeugt! Umgekehrt heißt das doch, die Käufer wurden in den vorherigen Versionen beschissen nach Strich und Faden! Selbstverständlich hätte man vor einigen Jahren schon "schnelle" Programme abliefern können, aber leider waren die vorhandenen Programmierer nur F5-Drücker.... 
Und nicht daß jemand meint, das wäre nur bei kleinen Softwareklitschen so, gestern habe ich Updateangebote von Adobe bekommen. Hauptargument fürs Update ist "20-30% schneller". Da will jemand ernsthaft haufenweise Geld dafür, weil jemand anderes (Compilerhersteller) endlich mal seinen Job ordentlich gemacht hat. Der Sourcecode wurde größtenteils jedenfalls nicht geändert (Aussage Adobe). Das Geschäftsmodell ist klasse, einmal Sourcecode reingekloppt, und mit jeder "neuen" Compilerversion ist nur nach F5-drücken das Produkt "schneller" und kann dann nochmal verkauft werden! Userinterface bissl aufhübschen, fettich! Lizenz zum Gelddrucken!
Andy: ich wollte damit meinen Vorgänger nicht heruntersetzen.
Das hatte ich auch nicht so aufgefasst^^
Es war war nur als Anmerkung gedacht, wie wichtig es sein kann ein Programm zu optimieren.
Und das ist unabhängig, ob Scriptsprache oder Compiler. Wichtig ist doch erst einmal, dass registriert bzw. untersucht wird, wie lange ein Programm läuft und dann jemand sich die Mühe macht und schaut, ob und wie "optimiert" werden kann!
Viele Scripte von mir bestehen nur aus Schleifen, in denen ich auf andere Software warte. Ich brauche also in meinen Scripten keine Codeoptimierung, sondern eher eine Bremse
Bei mir genau umgekehrt, ich optimiere, weil ich selbst nicht gerne auf die Fertigstellung des Scriptes warte! Ich habe Autoitscripte am laufen, welche mit drei anderen Programmen teilweise gleichzeitig interagieren. Die Laufzeit ist abhängig vom Auftragsvolumen, welches ein Mitarbeiter im Lauf des Tages bestimmt. Da werden Daten bereitgestellt, andere Programme per Control-()-Befehlen gesteuert, dort Daten abgespeichert uswusf. Wenn das Script gestartet wird, kann es sein, dass viele andere MA auf eines der Programme und dessen DB zugreifen und alles "träge" wird. Da keiner Lust hat, eine halbe Stunde auf immer denselben Ablauf zu schauen, arbeite ich jetzt teilweise mit API-aufrufen, um Zehntelsekunden einzusparen. ZEHNTELSEKUNDEN wird einer sagen, das ist doch lächerlich...
Ich sehe das anders. 15 Mal 200 Vorgänge pro Tag sind 3000 mal 200 Tage/Jahr ergibt 600000 Vorgänge/Jahr mal 1/10tel Sekunde ergibt 60000 Sekunden = 16 Stunden = 2 Manntage pro Jahr....
Mal sehen was DU sagen würdest, wenn ich als dein Chef dir erzähle, dass du 2 Tage deines Jahresurlaubs abgezogen bekommst, weil dir eine ZEHNTELSEKUNDE keine "Codeoptimierung" wert ist....
Und das bei EINEM Script/Programm von vielen, welche bei uns sowieso schon "langsame" ehemals händisch gemachte Abläufe automatisieren! Bei gerade mal 15 MA, stell sich mal einer vor, was man in Unternehmen "optimieren" könnte, welche 150, 1500, oder gar 15000 MA haben!
Ein Programm (meines Vorgängers), von dem die Optimierung der Produktion unter Berücksichtung aller noch offen Aufträge bis zu einem gewissen Zeitpunkt erreicht werden sollte, lief unglaubliche 7 Stunden. Nach der 1. Optimierung 3 Stunden, am Schluß < 1 Stunde.
Ich habe mittlerweile in der Firma den umgekehrten Fall!
Mein vor ca. 5 Jahren als absoluter Notbehelf schnell hingerotztes Script tat anfangs seine Arbeit tadellos und schnell. Mittlerweile sind quer durch Auftragsabwicklung/Fertigung und Versand viele weitere (selbstgeschriebene) Module hinzugekommen, die sich dem logischerweise täglich größer werdenden Datenmengen bedienen müssen. Dauerte Aktion X früher nur einige Sekunden, laufen Programme heute mehrere Minuten....mich stört das sehr, aber die Kollegen sind heilfroh, denn selbst die langsamen Konstruktionen sind immer noch besser als garkeine (nicht zu erwähnen ist, dass der "Notbehelf" mittlerweile Dreh- und Angelpunkt geworden ist, weil der Verursacher dieser Krücke IMMER NOCH NICHT (richtig) funktioniert, und dieses Programm kommt, das muss hier auch mal erwähnt werden, aus einer "professionellen" Softwareschmiede mit mehreren nur an diesem Programm arbeitenden Mitarbeitern!)
Ende vom Lied müsste eigentlich sein, die Unmengen an Daten in eine Datenbank zu schreiben und die gesamte Kommunikation / Anzeige über ein Datenbankmodul abzuwickeln. Geschätzter Aufwand: ca. 1-2 Mannmonate. Da ich der einzige bin, der sich mit der Migration bzw. mit dem Umschreiben auf eine DB-Anwendung auskennt, und ich "Programmierarbeiten" nebenbei (neben meinen eigentlichen Aufgaben) bzw. in meiner Freizeit abwickle, sehe ich da schwarz....über kurz oder lang wird das System kollabieren, und ich muss mir die dummen Sprüche seitens Softwarefirma anhören, "Sehen Sie, wir haben gleich gesagt, dass Sie das auch nicht hinbekommen!"
@bazii, du machst deinem Namen alle Ehre! Und btw., wenn es damals in der Schule nach den Eignungstests gegangen wäre, hätte ich Gärtner als "optimal für mich geeigneten" Beruf lernen sollen...
Den "grünen Daumen" hab ich jedenfalls, aber das reicht offensichtlich nicht 
Der Großteil der Informatik-Studenten kommt allerdings nicht über Java hinaus.
Was sich imho mit
Also hat man auch mehr qualifizierte Nieten in der Branche.
deckt....bitte nicht falsch verstehen, es gibt werweißwieviele TOP-Java-Programmierer. Und die haben einen gigantischen Vorteil gegenüber den "hardwarenahen" Sprachen, denn dort ist es Sache der Java-Implementation auf dem einzelnen/bestimmten Gerät, welches u.a. die Geschwindigkeit des Codes beeinflusst. Denn dem Java-Programmierer kann es völlig schnuppe sein, ob sein Code auf einer Armbanduhr/Kaffee- oder Spülmaschine oder in einem KFZ läuft!
Nach meiner Auffassung gäb es im Softwarebereich größere "Baustellen" als den Code auf Teufel komm raus zu optimieren.
Mach dazu einen Thread auf und sprich diese "Baustellen" an. Dazu ist ein Forum da. In diesem Thread ist die Baustelle "Compiler - reicht der Hieb auf F5 um optimalen Code zu erzeugen?!".
In den ersten beiden Semestern gibt es Java/OOP, danach kommt Mikroprozessortechnik etc. mit C und Assembler.
hehe, die Microprozessortechnik hat mich erstmal mit C(++) warm werden lassen . Und um OpenCL-Kernel (nicht den restlichen Code, nur den Kernel!) habe ich mich ja auch schon bemüht, der besteht aus (Ansi)-C aus dem vorherigen Jahrhundert 
.
Aber mittlerweile sind die Compiler auch für die Mikroprozessoren am Limit angelangt, da hat selbst ein ASM-Spezialist noch weniger Chancen auf "Optimierung", weder in der Geschwindigkeit, noch in der Größe. Klar eigentlich, der simple und einfache Prozessor hat einen sehr begrenzten Befehlssatz und die Compilerbauer hatten in den vergangenen Jahren genug Zeit, den reichlich vorhandenen hochperformanten ASM-Code passend umzusetzen. So kann es gehen, gerade bei einem "hardwarenahen" Programmieren wirst du von den Spezialisten (alles selbst alte ASM-Hasen) gefragt, ob du noch alle Latten am Zaun hast, wenn du ASM programmierst statt den "bequemen" (und wie gesagt ausoptimierten) Compiler zu benutzen!
Aber schau, genau da liegt ja der "Hund" begraben, oft fragt man sich welches Genie das geschrieben hat - weil es wirklich gut ist - nur bedienen läßt es sich schlecht - da feht dann eben auch etwas.
Richtig, aber was hat das mit "der Arbeit" eines Compilers zu tun? Nichts! Usability optimieren hat absolut nichts mit der verwendeten Programmiersprache/Maschine zu tun.
Abgesehen davon stelle ich bei täglichen Anwendungen fest, dass oft der Programmierer/Entwickler NICHTS mit dem fertigen Produkt zu tun hat, daraus ergeben sich teilweise haarsträubende Unzulänglichkeiten in der Bedienung.
Ich halte jede Wette, dass die meisten Entwickler (nicht nur im Bereich Software) in der Folgegeneration wesentlich "bessere" Produkte erschaffen würden, wenn sie gezwungen wären, einige Wochen mit ihrem "Mist" tagtäglich stundenlang zu arbeiten!
als das letzte Quentchen optimieren zu wollen.
Du hast es nicht verstanden...hier geht es nicht ums "wollen", sondern darum, es zu können. Können im Sinn von analysieren, Lösung erarbeiten und diese umzusetzen. Wenn suggeriert wird, dass ein Gerät "automatisch" das beste Ergebnis erzielt, egal welchen Schrott ich hineinstecke, dann stumpft der Anwender/Bediener natürlich ab...
Umso mehr, wenn er nicht einmal die Möglichkeit erhält, das Ergebnis zu bewerten (bewerten zu KÖNNEN)
//EDIT
Soeben eine Stellenanzeige für Softwareentwickler in einem Unternehmen gelesen, in welchem seit Generationen höchstwertige Fotoapparate/Linsensysteme/Mikroskope/Laborgeräte hergestellt werden. Es werden in vier Bereichen "Software-Typen" gesucht:
- Softwaretester zur nachhaltigen (!) Qualitätsverbesserung,
- Entwickler (von der Anforderungsanalyse über Design bis zur Implementierung)
- Entwickler Firmware (selbstständig (!) neue Technologien zur Produktreife bringen)
- Entwickler Bildverarbeitung und -analyse (entwickelt PERFORMANTE (!) Algorithmen unter zuhilfenahme GPU-basierender Methoden wie CUDA und OpenCL)
ALLES, aber auch alles in dieser ganzseitigen Anzeige in einer Fachzeitschrift schreit geradezu nach "Optimierern" bzw. Anwendern und Verwendern der neuesten Hard- und Softwaretechnologien.
Diese Stellen werden definitiv von Leuten besetzt werden, die nachweislich "optimieren" können, und diesen Vorgang nicht mit "...aber ich hab doch ganz feste F5 gedrückt..." beschreiben.
Wenn du deinen Prozessor kennst, dann produzierst du besseren Code als dein Compiler. Wenn du das nicht tust, dann nicht.
Um der Aussage mal kurz den Interpretationsfreiraum zu nehmen: Jemand der beschissenen Code produziert kann seinen Prozessor selbstverständlich nicht kennen, sonst würde er nicht so töricht sein und beschissenen Code produzieren.
Aha, DAS ist ja extremst interessant! Der Grund eine HLL zu verwenden ist doch "menschlichere" Lesbarkeit des Codes und vor allem Portabilität, das wird irgendwann in jeder Diskussion zwischen (Pseudo) Quiiieeek-in_die_Enge_getriebene-HLL-Anwender und den (ASM)-Optimierern postuliert. Mal abgesehen davon, dass nur ein Bruchteil sämtlicher Programme wirklich portabel IST, besteht doch genau hier das Problem.
Wie kann ich denn mit dem GLEICHEN Sourcecode auf unterschiedlichen Plattformen sichergestellt das "optimale" Ergebnis herausholen?! Das funktioniert doch nur, wenn der Compiler den Sourcecode individuell für die zu verwendete Plattform ausarbeiten kann. Wenn allerdings der Compiler (infolge ca. 15-20 Jahre Rückstand auf die Hardware) besonders "schnelle" Prozessorfeatures garnicht ansprechen kann, schlägt die Stunde der Intrinsics() !
Und das wiederum ist gaaaanz großes Kino, denn diese Intrinsics sind nichts weiter als ein Wrapper für Inline-ASM!
Was heisst das für den Programmierer? Er weiß um die unzulänglichkeiten des Compilers und benutzt Instrincs (somit ASM). Jetzt wird es interessant, denn WELCHER Programmierer weiß um die Unzulänglichkeiten des Compilers und nutzt Intrinsics? Derjenige, der entweder WEIß, dass der Compiler keine "schnellen" Befehle verarbeitet (woher weiß er das?), oder dies eben durch Analyse des compilierten Codes herausgefunden hat!
Vielleicht hat er auch durch Weiterbildung/Kollegen/Freunde/Internet/Forenbeiträgen(wie diesem ^^) von Intrinsics gehört/gelesen und wendet diese Techniken an, um die Laufgeschwindigkeit seines Codes um Faktor 3-4 zu erhöhen!
Und jetzt zum "beschissenen Code". Wie definiert man diesen? Und wie findet man den Unterschied zum besseren/guten/optimalen Code? Wenn ich weiß, dass mein Prozessor bestimmte Codesequenzen nur unzulänglich abarbeitet, aber die Erstellung dieses Codes kaum Zeit kostet, wen juckt das dann? Ich mache das schon seit Jahren so, gelernt ist schliesslich gelernt! Wenn mein Code serienweise Prozessorstalls, Cache-Misses und Abhängigkeiten in den diversen Prozessorpipelines verursacht, dann muss ich das doch erstmal wissen! In das Compilat gucken hilft da jedenfalls nicht....Und übrigens hahahaha, diese Sequenz kann nach Codeumstellung 3x schneller laufen, diese Märchenerzähler immer, die sollen das erstmal beweisen 111elf!!
Jetzt kommts dicke, ich schreibe diesen "beschi****" Code in Funktionen, welche auch noch meine Kollegen benutzen, dann wird der Mist auch noch flächendeckend verteilt! Von denen ist auch jeder heilfroh, besser C&P als mühsam selbstgeschrieben! Von wegen optimieren, das soll man für 11 Euro die Stunde wohl auch noch machen, IHR HABT SIE WOHL NICHT MEHR ALLE! 
(<--für diejenigen, die mich NICHT kennen )
Allgemein ist auch ganz praktisch: Wer Funktionen wie log, exp, pow, usw benutzt kann (falls Genauigkeit nicht wichtig ist) mit einigen wenigen Grundoperationen jedes Prozessors eine gute Approximation bekommen. Vorallem in InnerLoops haut das richtig rein, wenn man bei pow nicht 10 Schritte (angenommen die Biblipthek die man nutzt hat per default so viele), sondern nur 3 oder so benutzt.
Dazu nur einen Link.... Tutorial AutoIt und Assembler UPDATE 24. Oktober 2010 Verwendung von Autoitvariablen im Assemblercode
Dabei ist die Programmiersprache völlig uninteressant, in bspw. C(++) bzw. bei anderen Compilersprachen wäre das ganz genauso gewesen. Aber genau DAS findet man nicht mit F5 drücken, FETTIIIIICH, heraus! Btw. gibt es in vielen Programmiersprachen "schnelle" Varianten von float/double/semi-float usw...
Da die Praxis oft von der Theorie abweicht und es in der Firma niemanden interessiert wie ich programmiere, solange es funktioniert und tut was es soll, halte ich mich an meinen "oberflächlichen" Optimierungen und vernachlässige die tiefere Ebene von der Andy und Xorianator in den Start-Posts reden, und selbst das ist teilweise aufgrund von Zeitmangel sehr schwierig. Kompilieren: F5.
Dem ist nichts mehr hinzuzufügen.
Hi zusammen,
neulich abends beim lecker Bier in der Kneipe kam das Gespräch auf AutoIt vs. Compiler, und einer der Anwesenden (Xorianator) wiederholte sein vorher hier auch schon in der Shoutbox gemachtes Statement, dass Compiler heutzutage Code generieren, welcher (von Menschen) nicht mehr weiter zu verbessern ist.
Ein weiterer Anwesender (AspirinJunkie) benutzt Compiler und insbesondere hochoptimierte Bibliotheken für weitgehend komplexe mathematische Berechnungen. Diese Bibliotheken/Dll´s werden weltweit als "Standard" eingesetzt, es kann davon ausgegangen werden, dass diese Programme "ausoptimiert" sind.
Mit AspirinJunkie bin ich einer Meinung, dass bei der Verwendung von standardisierten, hochoptimierten Funktionen aus Bibliotheken, die tausendfach auf Rechenclustern verwendet werden, die Ersteller dieser Bibliotheken schon aus Eigennutz alle Register ihres Könnens gezogen haben, um das letzte Quentchen Leistung aus der verwendeten Hardware herauszukitzeln.
Allerdings bin ich überhaupt nicht der Meinung, dass ein beliebiger Quellcode, nachdem er durch einen Compiler bearbeitet wurde, "optimal" im Sinne von ausführungstechnisch "schnellstmöglich" zu betrachten ist.
Bei der Erstellung der o.g. Bibliotheken wird optimiert, indem der vom Compiler erstellte Code analysiert und auf seine mögliche Geschwindigkeitssteigerung durch Sourcecodeumstellung/(Inline)ASM/Intrinsics untersucht wird. Das wiederum erfordert tiefere Kenntnisse der Zielarchitektur und natürlich Verständnis dafür "was der Compiler aus dem Sourcecode macht". Erst jetzt kann man beurteilen, ob der Compiler "gute" Arbeit gemacht hat.
Interessant fand ich die Aussage, dass ein Compiler den Sourcecode analysiert und, weil die Compilerbauer ja schliesslich am Besten die Zielarchitektur kennen, "automatisch" den besten Code generiert!
Anders herum gesagt, ein Mensch in Form eines ASM-Programmierers sei im Vergleich zum Compiler maximal "gleich gut".
Wir brauchen hier nicht über die Vorteile einer HLL zu sprechen, aber dass heutzutage von Professoren im (Informatik-) Studium auf Nachfrage zu ASM mit "Vergessen Sie´s!" geantwortet wird, finde ich höchst bedenklich! Wer anderes als der Programmierer soll denn in der Lage sein, sein "Produkt" in Form von erstelltem Code zu bewerten?! Nicht in den vom Compiler erstellten Code zu schauen und dort ggf. "Fehler" oder bestenfalls Optimierungsmöglichkeiten zu entdecken ist imho doch die totale Ablehnung und Ignoranz eines "normalen" Entwicklungsprozesses!
In keinem anderen Ingenieurwesen darf die Verifizierung des Ergebnisses und die Bewertung dessen fehlen. Ein Schweißingenieur lässt definitiv seine Nähte röntgen/brechen. Ein Bauingenieur muss einen Nachweis erbringen bzgl. statischer Festigkeit/Stabilität.
Der "Softwareingenieur" hingegen gibt seinen Code ein, haut auf F5 und der Compiler hat "automatisch" den besten (nicht von Menschen zu verbessernden) Code erstellt?!
Ja, hier geht es darum, ob Quellcode schreiben und auf F5 hauen "reicht" im Sinne von "es läuft doch" (schnell genug)!
Ist Programmieren nichts anderes als das zusammenfügen "fertiger" Funktionen/Bibliotheken, und zu denken "es wird so schon passen"?
Wie programmiert/compiliert ihr? Ist (Code-)Optimierung überflüssig/überbewertet?
Das
mit den zahlen klappt perfekt, sie werden addiert und um gewandelt da
kommt nun eine Zeichenfolge von 56 Zeichen raus, die zusammen in einer
variable den Variablen Type Objekt besitzen.
Ich benutze die Bignum-UDF seit Jahren, und da hatte ich noch nie Probleme.
Poste ein nachvollziehbares Script/Minimalbeispiel!
Hi,
da du nicht in der Lage bist, zu diesem Thema zu googlen, hier eine kleine Hilfe: http://de.lmgtfy.com/?q=autoit+sap+automatisieren
Um mit SAP zu kommunizieren, existiert eine von einem AutoIt-User erstellte sog. UDF, das ist eine Sammlung von Funktionen https://www.autoitscript.com/forum/topic/86574-sap-udf/
Dieser User hat entsprechend Ahnung sowohl von Automatisierung als auch von der zu steuernden Software (in dem Fall SAP). Anfragen zu diesem Thema dann im entsprechenden Thread oder beim User direkt.
Wenn du noch nicht mit AutoIt bzw. einer anderen Script/Programmier-Software gearbeitet hast, schätze den Aufwand ein, das zu lernen oder erstelle einfach eine entsprechende Anfrage zum Erstellen eines kompletten Scripts im entsprechenden Unterforum, entweder hier bei uns oder im oben verlinkten englischsprachigen Forum. Wenn das nur einige Zeilen Code sind, wirst du sicherlich "für lau" eine Lösung bekommen, aufwendige Programmierarbeiten werden nach Aufwand bezahlt. Da SAP-Nutzer per se schon viel Geld investieren (müssen), kommt es da auf die paar Euro für eine Arbeitseinsparung sicher nicht an...
Hier mal ein Anfang als Script:
Genau so sollte das ein Anfänger machen...
Dieser Anfänger muss allerdings für jede Änderung an den "TargetFiles" den Quellcode ändern. Weniger schön...
Wesentlich besser und komfortabler zu bearbeiten wird das Programm, wenn die "TargetFiles" untereinander in einer von jedem User und auch mit jedem beliebigen Editor bearbeitbaren Textdatei stehen. Diese einfach per (Anfänger nehmen dafür) FileReadToArray() einlesen.
Bei AutoIt haben alle 3 Varianten, also GDI, GDI+ und OpenGL in etwa die gleiche Performance, ca. 10 FPS.
FB ist in GDI/GDI+ gerade einmal doppelt so schnell, also 20FPS, das liegt offensichtlich an den "einfachen" Berechnungen.
OpenGL in FB hat "nur" 7 FPS, allerdings bei 130000 Rechtecken/Sekunde und ca. 1 Million Recursions-Calls 
Wenn ich dann im Spiel bin, laggt es irgendwie. Ist das bei euch auch so?
Bei mir nicht, hat bestimmt aber mit dem GuiGetMsg()- Modus zu tun, der "zwingt" AutoIt bzw. das Script in einen Stromsparmodus....
OnEvent()-Modus ftw, deshalb habe ich den für mein Beispielscript genommen, wie gesagt, auf meinem Billig-Laptop 500FPS.
Ersetze einfach mal das while guigetmsg() in zeile 77 durch while 1, dann gehts ab^^, while sleep(1) sollte das Problem lösen.
"Solo" startet das Script nicht . Vielleicht solltest du doch mal über das Ausschlafen nachdenken, wir haben Wochenende
"Früher" konnte man mal Programme aus ZIP-Dateien heraus starten, die haben die benötigten Dateien selbstständig aus der ZIP extrahiert....
Mal ne doofe Frage, wo nimmt er die Bilder her o,O
Sieh zu, dass du mal etwas Schlaf bekommst!
Guckst du Ordner! 
