Beiträge von Andy

  • Unterschied zwischen Run() und ShellExecute()

    Hi,
    was ist an den Angaben der (deutschen) Hilfe missverständlich?
    Sowohl die deutsche, als auch die "orginale" Hilfe erklären detailliert, was die Unterschiede sind!

    Zitat von mtzE91

    Beide führen mein gewünschtes Kommando aus

    Bei mir nicht...

    AutoIt
    FileDelete("test.txt")
FileWrite("test.txt", "Das ist ein Test!")
$ret = Run("test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF)  ;### Debug Console
$ret = ShellExecute("test.txt")
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $ret = ' & $ret & @CRLF & '>Error code: ' & @error & @CRLF)  ;### Debug Console

    Run() führt zu einem error, Shellexecute() nicht....und nu?

    Zitat von mtzE91

    aber welche Vor- oder Nachteile bringt mir der Einsatz der jeweiligen Funktion?

    Was würdest du von einer Programmiersprache halten, welche zwei völlig identische Funktionen mit unterschiedlichem Namen bereitstellt?
    Wenn es zwei unterschiedliche Funktionen gibt, dann deshalb, weil diese auch zwei unterschiedliche Anwendungsbereiche haben, welche auch dokumentiert sind....wobei wir wieder bei der Hilfe wären.

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    Zitat von Alina

    Das habe ich dann gemacht und später dann habe ich auch die ersten Bauteile wieder rangelötet.

    Warte ab, wenn du das erste Programm laufen hast, wo du einen NTC (temperaturabhängiger Widerstand) ausliest und die Temperatur auf einem Display ausgibst, fühlst du dich wie ein König! 8o

    Übrigens brauchst du am PI und auch an den anderen µ-Controllern nicht rumlöten, die haben alle Steckkontakte. Zum experimentieren reicht dann ein Breadboard (Steckbrett) und eine Handvoll "Hühnerfutter" (elektronische Baurteile wie LED´s/Widerstände/Sensoren uswusf) um die Schaltungen zusammenzustecken. Lötkolben ist trotzdem unabdingbar, man will ja das fertige Projekt langfristig in eine Kiste sperren und der Kabelsalat soll so klein wie möglich bleiben...

  • UDF - TrueType Fonts im Script mitgeben und verwenden

    hab was viel besseres :D
    Dank dir!

  • UDF - TrueType Fonts im Script mitgeben und verwenden

    Danke erstmal, allerdings war nicht das "aktivieren" der Fonts über die API-Funktionen das Problem, sondern die Umwandlung der *.ttf, welche eukalyptus über das "generate.au3"-Script abgewickelt hatte.
    Hat jemand noch irgendwo die generate.au3?

    //EDIT
    Mir geht es darum, einen Font im Script zu integrieren, also keine *.ttf-Datei dem Script mitzugeben! Beim Scriptstart wird der Font vorübergehend im System installiert und bei Scriptende wieder rausgeworfen.
    Irgendwo hatte ich da auch mal Beispiele :(

    //EDIT2
    UEZ hatte ein schönes Beispiel !

  • Battle: Autoit vs. FreeBasic - Runde 1+2+3

    Zitat von Xorianator

    Ausgehend von der Aussage mit den Registern: In C kannst du direkt die Register ansprechen

    KANNST...du hast es erfasst...KANNST..., das ist genau wie alles andere was man eben KÖNNEN muss!
    Wenn sich Profis, die sich jahrelang mit ggf. diversen Compilern auseinander gesetzt haben, Code analysiert, ihre Algorithmen verfeinert/angepasst haben, die Wirkung ihrer Compilerschalter kennen und "natürlich" auch die Hardware kennen und WISSEN (durch lesen des erstellten ASM-Codes) was der Compiler aus ihrem Getipper macht, dann ist das etwas völlig anderes wie ein "Programmierer" der irgendwelchen HLL-Code in eine IDE kloppt, auf F5 drückt und dann behauptet, ein Compiler würde daraus den schnellsten/besten/kürzesten Code bauen (welcher keinesfalls zu verbessern ist)!

    Zitat von Xorianator

    ich kann aber nicht damit mit gehen, dass vorher guter Code im Compilat immer noch riesige Differenzen zum reinen ASM Code hat.

    Hat er auch nicht, hab ich auch nie behauptet. Was ich behaupte ist, dass der Compiler (noch nicht) aus einer unzureichenden Implementation/Algorithmus das "Optimum" rausholt. Woher soll er auch wissen was das Ziel des Programmierers ist? Der Compiler nudelt stur seinen Quellcode durch, optimiert auf Teufel komm raus, und letztendlich muss er aufgeben und das abliefern, was er als schnellstes/bestes/kleinstes betrachtet!

    Guck mal auf die oben geposteten "Benchmarks/FPS", da wird sonnenklar, dass das Compilat "pro Intel" erstellt wurde. Ich denke mal, sicherlich nicht mit Absicht :D Wenn du aber nur einen Prozessor/Prozessorfamilie hast um auf diesen zu entwickeln, dann optimierst du logischerweise auch dafür!
    Vielleicht ist aber auch nur zufällig eine bestimmte Sequenz an Code von Intel-Prozessoren schneller zu verarbeiten, ggf. nur einige Takte, im Endeffekt macht das bei gleichem Code auf der Maschine mit gleichem Takt einen Unterschied von 20-30%, vielleicht in ungünstigen Fällen noch wesentlich mehr!
    Ich hatte in den ASM-Threads schon davon berichtet, dass ich bei Messungen von Codesequenzen 50 Takte erwartet hatte, die Hardware aber durch Pipelining und andere "optimierende" Schweinereien daraus ca. 2000Takte machte. In einem Loop mit Millionen Durchläufen ist das der Supergau! Und genau DAS meine ich! Wenn du dann nicht merkst "da stimmt was nicht", dann läuft etwas gewaltig schief! Einfach nur davon auszugehen, dass der Compiler aus Sch*** Gold macht, funktioniert nicht!

    Ich wäre übrigens dafür, die verschachtelten Schleifen mit den Berechnungen auch mal bei anderen Compilern und Sprachen durchlaufen zu lassen, dann hätte man mal Vergleiche. Ich sage jetzt einfach mal Unterschiede in der Laufzeit von 100% voraus...also halb/doppelt so schnell. Für die gleiche Schleife. Und dann noch auf unterschiedlicher Hardware laufen lassen. Das ist übrigens in div. ASM-Foren "Standard", also das benchen eigener Implementierungen auf div. Maschinen. Das kenne ich auch aus einigen C-Foren, allerdings "optimiert" man dort für den Compiler, d.h. man schaut, aus welchem C-Code der Compiler den schnellsten ASM-Code bastelt 8)

    Zitat von Xorianator

    denke ich bei "fähigem ASM Programmierer" eher an dich,

    Mit Sicherheit bin ich nicht "fähig" im Sinne von programmieren....

  • Battle: Autoit vs. FreeBasic - Runde 1+2+3

    Zitat von Xorianator

    Genau das meine ich anders herum: Nein, gibt es nicht.

    Dann treib dich in einschlägigen Foren rum, da wirst du eines besseren belehrt...incl. Beispielen.

    Zitat von Xorianator

    Widerspreche ebenfalls: Der Code wird heutzutage akribisch vom Compiler untersucht, bevor er übersetzt wird.

    Selbst der Intel-Compiler, welcher SEHR guten Code fabriziert, muss sich immer noch an das Compiler-Procedere halten, und das macht er auch!
    Allerdings hat er auch mit SSE/SIMD seine (zugegeben marginalen) Schwierigkeiten, was auch völlig normal ist, denn ein Programmierer setzt die Befehle bei SIMD "von hinten nach vorne" um, da hat der Compiler schlechte Karten, denn zzt. kann der nur "von vorne nach hinten". Ich gehe davon aus, in der nächsten Version wird da noch einiges gehen.
    Und wir reden hier von einem Compiler, der in der 2000 bis 3000€-Klasse spielt. Was er auch wert ist, nicht wegen dem (fast kostenlosen) Compiler, sondern den wirklich geilen Programmen, die eine komplette Infrastruktur bereitstellen. Wer einmal seine rechenintensiven Programme mittels Profiler verbessert hat, möchte solch ein Programm nicht mehr missen!
    Und auch dieser Compiler versucht erst in der neuesten Version selbsständig die vom (ahnungslosen) Programmierer eingehackten AoS in SoA zu "transferieren"

    Zitat von INTEL-Paper

    If possible, it is desirable to reorganize data into a Stucture of Arrays (SoA) organization. Unfortunately, for real world applications this may prove to be a non-trivial amount of effort. However, the benefits of doing such a transformation may be quite significant.

    Auf deutsch übersetzt steht da, wenn der Programmierer Ahnung von dem hätte was er da tut, würde er solch einen Mist garnicht erst machen...


    Bei den hier vorgestellten Basic-Compilern (und auch anderen X86-Compilern) brauchst du mit "akribisch Code untersuchen" nicht kommen, genau wie bei den meisten C(++)-Compilern. Die werden ALLE von halbwegs fähigen ASM-Programmierern geschlagen.
    Wegen "nichts" haben nicht sämtliche Compilerhersteller Intrinsics() implementiert. Diese ermöglichen auch "Otto-Normal-Programmierer" die Verwendung von ASM-Code, so er denn weiß, was er da tut....

    Schreib eine rechenintensive Funktion, nudel diese durch einen beliebigen Compiler und schau dir das Compilat an, wenn dort in jeder 3.Zeile irgendein Speicherzugriff stattfindet, kannst du schon einpacken.

    //EDIT
    https://groups.google.com/forum/#!topic/…x86/TtF6aaS8MeQ
    Acker das mal komplett durch, damit du weißt, was abgeht :D

  • ERLEDIGT --> Raspberry Pi® 2 Model B Advanced-Set 1 GB

    @Alina, der RasPi ist genau wie alle anderen "Bastel"-Geräte (Arduino) etwas zum basteln. Auch Kinder können damit Spass haben.
    Wenn ich dann in der SB lese, dass du einen "Elektriker" damit beauftragen willst, an dem Ding rumzulöten, frage ich mich ernsthaft, ob das das richtige für dich ist....

    Das ist wie wenn du dir einen Kasten LEGO/Playmobil kaufst und dann jemandem Geld gibst, damit er dir das Modell aufbaut und damit spielt!

  • Battle: Autoit vs. FreeBasic - Runde 1+2+3

    Zitat von autoBert

    Und da ich dem Source entnehme, das du zeitkritische Aufgaben mit Inlineassembler löst,

    Hihi, DER hat gesessen :thumbup:
    Der Inline-ASM-Code berücksichtigt genau das, was ich bereits sagte, ersetzen von "langsamen" (API-)Funktionen durch "schnellere".
    Was dann die Frage erlaubt, wieso nicht gleich die komplette "langsame" Schleife (der Compiler kanns halt nicht besser...) in "schnell" gecodet wird... :theke:


    Zitat von Xorianator

    Du wirst, wenn du nicht mit der Architektur vertraut bist, niemals einen besser optimierten Code, als dein Compiler ihn schreibt, schreiben können. Niemals....

    Ich bin mir nicht ganz sicher ob ich dich jetzt verstanden, und/oder ob ich mich vielleicht ungeschickt ausgedrückt habe. Daher noch mal deutlich:
    JA, für "Otto-Normal-Programmierer" bleibt der vom Compiler erstellte Code "der schnellste/beste".
    Und JA, für 99,9% von rechenintensivem, von Compilern erstelltem Code gibt es die schnellere Version in handoptimiertem ASM. Das hängt einfach mit der Art und Weise zusammen, wie der Compilerbauer seine Arbeit gemacht hat. "Klassisch" reserviert ein Compiler Speicher für verwendete Variablen (meist auf dem Stack). Da idR ein "dummer" Compiler (und das sind die allermeisten) Code nicht im Vorfeld auf die Verwendung bspw. dieser Variablen analysiert, "merkt" er auch nicht, dass statt dieses Speichers die wesentlich schnelleren Prozessorregister verwendet werden könnten.
    Bei der Verwendung von SSE-Schaltern und anschließender Analyse des Compilates kommt dann bspw. heraus, dass zwar einzelne SSE-Register verwendet werden, aber die damit möglichen SIMD-Berechnungen überhaupt nicht oder nur rudimentär verwendet werden. Idr. "sieht" man dem Compilat schon an, ob es beschleunigt werden kann.
    In den gängigen ASM-Foren ist man sich durchaus bewußt, dass die Compiler (glücklicherweise) immer besser werden, allerdings ist genauso klar, dass ein ein guter ASM-Programmierer (glücklicherweise) immer noch den einen oder anderen Hasen aus dem Hut zaubern kann....
    Aber genau das ist doch der Punkt! Kein Compilerbauer hätte einen Anreiz, besseren Code zu schreiben, wenn das für die jeweilige Architektur erstellte Compilat schon optimal wäre. Die handoptimierten ASM-Bibliotheken, egal für welche Architektur, machen es doch vor!
    Die Frage ist dabei, inwieweit sich die "Handoptimierung" überhaupt lohnt. Wenn ich sehe, dass bspw. sehr grafikintesive Programme mit extrem gut zu parallelisierbaren Filtern mit Techniken aus dem vorigen Jahrhundert arbeiten, aber kein einziger Anwender sich an der "Wartezeit" stört, weil auf dem Markt keine einzige Alternative besteht, dann wird klar wie der Hase läuft: nur wenn "Druck" seitens Wettbewerb auf das Produkt ausgeübt wird, entscheidet sich der Entwickler dazu "schnellere" Techniken einzusetzen.

    Zitat von Xorianator

    Ja, das deckt sich aber auch direkt mit der Aussage darüber, dass ein beschissener Algorithmus immer noch beschissen bleibt, egal wie viele Operationen in einer Sekunde wir auch ausführen können.

    Trifft somit den Nagel auf den Kopf! Wenn der "beschissene" Code aber nur Millisekunden zur Ausführung benötigt, was dem Programmierer idR völlig egal ist, juckt das NIEMANDEN! Nun nimmt jemand anderer diesen Code, schreibt ihn in eine Funktion und ruft diese Funktion auch noch Millionen Male auf....mit dem Ergebnis dass extrem lange Wartezeiten entstehen. Solange auch das NIEMANDEN juckt, ist alles schick!
    Wenn aber ein "richtiger" Programmierer den Hebel ansetzt und den Algorithmus optimiert und danach noch ggf. mit den Compilerschaltern so herumspielt, dass letztendlich eine x-fache Beschleunigung herauskommt, fängt das vorwurfsvolle Gequieke der Gemeinde an: "DAS müsste eigentlich der Compiler von alleine können...."
    Und so analysieren und optimieren die führenden Compiler mittlerweile den hingerotzten Source-Code, stellen ihn um und beheben die Defizite der "Otto-Normal-Programmierer", welche sich mit den von dir angesprochenen Architekturen absolut nicht mehr auskennen, und machen letztendlich "aus Scheiße Gold". Und genau diese "Otto-Normal-Programmierer" wundern sich dann, wenn sie nur noch einen Knopp und einen Klicker verdienen, da sie von x-beliebigen "Developern" weltweit ersetzt werden können....
    Wer sich auf das KnowHow von anderen verlassen muss, ist schnell selbst verlassen!

  • Battle: Autoit vs. FreeBasic - Runde 1+2+3

    Zitat von alpines

    mit Benchmarks die der realen Welt nahekommen?

    Was sind denn Benchmarks in "der realen Welt"?
    Textver/bearbeitung, sobald mit den nativen AutoItfunktionen vorgenommen, bedienen sich der API bzw. sind C(++)-Funktionen, von Regex ganz zu schweigen.
    Dateien benennen...na gut, wieviele tausende/millionen Dateien benennst du am Tag um? Ich verschiebe in einigen AutoIt-Scripten bei mehrmals täglichem Aufruf alle Dateien (einige hundert) älter als 14 Tage ins Nirvana bzw. in Sicherungsverzeichnisse, das ist im Vergleich zum restlichen Programmablauf (Aufbereitung von Maschinendaten) zeitlich völlig irrelevant.
    Und da alle meine in der Firma laufenden Scripte per Netzwerk auf Serverdaten zugreifen bzw. teilweise auch miteinander kommunizieren, ist deren Geschwindigkeit abhängig von der Netzwerkleistung/Infrastruktur. Und nicht von der Programmiersprache.

    Viel interessanter wäre u.a. Arraymanagement, bspw. Arraysort(). Da brauchen wir garnicht anzufangen, mehrere ineinander verschachtelte FOR/TO, siehe Anmerkungen/Beispiele in den obigen Posts, ich schätze Faktor 50-100 schneller als AutoIt.

    Alles, was mit aufwendigen (!) "Berechnungen" zu tun hat, bzw. mit langen/häufigen Schleifenaufrufen, läuft in FB wesentlich schneller.
    Um beispielsweise Börsenkurse aus dem Internet zu laden und grafisch darzustellen sind einige hundert Schleifendurchläufe nötig. Da ist es völlig unerheblich, ob die Grafik in 20 oder 200 Millisekunden dargestellt wird, wenn der InetGet() an sich schon mehrere Sekunden dauert.

    Imho ist es wesentlich wichtiger/sinnvoller, einen geeigneten/schnellen Algorithmus für die Problemlösung zu finden. Und da sind diverse Techniken und Programmiererskill gefragt, und nicht die "schnellste" Programmiersprache. Ein "langsamer" Algorithmus wird immer "langsam" bleiben, auch wenn er auf eine schnellere Hardware/Programmiersprache portiert wird.
    Nicht umsonst sind Assemblerprogrammierer in den letzten Jahren immer mehr gefragt, bzw. der Einsatz von "prozessornahen" Operationen in diversen Sprachen. Scheiss auf Portabilität, in den neuen Compilern/Bibliotheken werden je nach Architektur höchstoptimierte, genau auf DIESE EINE Architektur erstellte ASM-Sequenzen angesprungen. Die Zeiten von "der (Cross-)Compiler macht das schon..." sind nämlich vorbei. Die Compiler werden zwar immer besser, doch handoptimierter Code ist bei aufwendigen Aufgaben immer noch einen Tick schneller. Und im Bereich des Supercomputings, wo Zeit SEHR VIEL Geld kostet, verwendet niemand die Standard-Bibliotheken wenn es eine hochoptimierte Alternative gibt!

  • Frage an alle Raspberry Pi & Co - Bastler

    Zitat von BugFix

    vielleicht kann ich auf dem PC der mit der USV verbunden ist, die Shutdown-Message verarbeiten und über Netzwerk die anderen PC herunterfahren.

    So würde ich das machen. Die "dummen" (ohne Shutdown-Message) USV müssen demnach nur ca. 5min Spannung liefern.

    Ich hab eben mal nachgeschaut, selbst eine USV mit Shutdown-Message über USB kostet weniger als 100€.
    Das ist in dem von dir betreuten Bereich Medizin sicher kein Ausschlußkriterium.
    Und das Gefrickel, alle im Netz befindlichen Rechner remote runterzufahren, bist du auch los 8o
    Wobei das Runterfahren ja noch ganz einfach geht, aber wie holst du die Rechner denn wieder hoch? Das funktioniert per TCP und magic packet imho nur aus dem Standby, alternativ bietet dir das BIOS ja ggf einen "System Status on Power Failure" oder "Reboot on Power Loss" oder etwas ähnliches an, damit der Rechner nach einem Stromausfall automatisch wieder hochfährt.

  • Timer und Knopfdrücke gleichzeitig

    Zitat von LaMagnos

    Aber vielen Dank für die Antworten und das sich hier Leute Zeit nehmen denn ganzen Code einfach so zu schreiben, Danke!

    Du hast in "Hilfe und Unterstützung" gepostet, damit man dir hilft, und nicht damit man dir den Code komplett schreibt!

    SOLLTE GENAU DAS (den Code schreiben) jemand tun, kann er/sie sich auf etwas gefasst machen!

  • Battle: Autoit vs. FreeBasic - Runde 1+2+3

    Zitat von BananaJoe

    Kann man mit FB auch Programme automatisieren?

    Man kann mit jeder Programmiersprache Programme automatisieren.
    Im Prinzip reduziert sich alles auf das Wrappern/Aufrufen einfachster API-Funktionen. Sobald du mit einer Programmiersprache Zugriff auf die Windows-API hast, kannst du dich austoben!
    Und da die Laufzeit der API-Funktionen für alle Programmiersprachen gleich ist, unterscheidet sich die Laufzeit der Programme lediglich durch den Overhead des Aufrufs. Was allerdings (wie bspw. auch bei Autoit) schon empfindlich die Laufzeit (gerade in Schleifen) beeinflussen kann!
    Ich habe neulich im Assembler-Forum gelesen, dass sich jemand über die Langsamkeit von GetPixel() aufgeregt hat. Da gab es dann wieder ellenlange Diskussionen, ich frage mich dann immer was diese Leute geraucht haben, KEIN MENSCH MIT HIRN liest 1000x1200 Pixel nacheinander mit einer API-Funktion aus.
    Eins steht fest, ES GIBT KEINE SCHNELLE API_FUNKTION. Punkt. Diskussion beendet.
    Die KANN es gar nicht geben, denn aus "sicherheitspolitischen" Gründen werden sämtliche Anwender (aus gutem Grund) als Vollspaten angesehen. Und daher wird oft mehr Error-Management in die Funktion gepackt, als letztendlich nötig wäre.
    Ein Sinus() per API dauert 3x so lange wie ein FSIN() per Opcode. In C(++) sind Intrinsics voll in Mode, damit lassen sich die "langsamen" C(++)/aka API-Befehle/Funktionen massiv beschleunigen. Sobald man weiß, was man tut....

  • Theorie: AutoIt3-Compiler

    Ich sehe das genau wie UEZ.

    Natürlich wäre ein (auch eingeschränkter) AutoIt-Compiler eine feine Sache, aber wozu? Schnelleren Code erzeugen? In 99% aller Fälle unnötig. Kleinere Files erzeugen? In 99% aller Fälle unnötig.
    Reputation? Lächerlich, sämtliche "Gegner" eines solchen Projekts (ihr wisst, wo diese sitzen) würden ALLES dafür tun, dieses Projekt runterzuziehen...

    Wenn ich schnellstmöglichen Code benötige, dann bediene ich mich für diesen Codeteil (!) einer Dll/AssembleIt/OpenCL. Oder benutze eine andere Programmiersprache!
    An kleineren EXE´s hatte ich in den letzten Jahren absolut keinen Bedarf. Vielleicht wird das aber mit Blick auf kommende x86-IoT-Devices ein Grund.