Gerade aus einem anderen Thread entnommen, warum Assemblerkenntnisse auch sinnvoll sind: "Was bei dir in der Liste noch fehlt: grundlegende Assemblerkenntnisse für die verwendete(n) Plattform(en). Damit sollst du nicht programmieren (dauert viel zu lange), aber du musst das lesen und analysieren können, was der Compiler ausspuckt. Spätestes im Disassembler-Listing des Debuggers solltest du in der Lage sein nachzuvollziehen, was der Compiler da zusammen gestöpselt hat." Es ging dort um den Erwerb von Programmierkenntnissen für µC und den Absatz habe ich aus einer Antwort von Jörg kopiert.
Beitrag #6958152 wurde von einem Moderator gelöscht.
Beitrag #6960811 wurde von einem Moderator gelöscht.
Horst G. schrieb: > Denn C und Python sind per se immer noch C und Python, egal um welche > Version es sich handelt; das ist schon vergleichbar bzw. kann auf dieser > Ebene in einen Topf geworfen werden. Äh... Also bei Python ist das nicht ganz so. Das fängt schon mit dem Interpreter an -- neben dem Standard-Interpreter CPython gibt es auch noch den performanten Pypy und obendrein die Interpreter Jython und IronPython in, und zur Interaktion mit, Java respektive .NET. Und dan ist es auch eine Frage von Bibliotheken und Laufzeitmodell, denn es gibt beispielsweise Compiler für Python wie nuitka, das den Python-Quelltext in C-Quellcode übersetzt, und im Bereich der Bibliotheken gibt es zum Beispiel viele wie numpy, das intern alles in C implementiert. Vor einiger Zeit haben kluge Leute hier mal das Sieb des Erastothenes (oder das, was sie dafür hielten) in mehreren Skriptsprachen implementiert und gemessen. Ergebnis dieser durchaus spannenden Versuche war, das Pythons Standardinterpreter den Code am langsamsten, der optimierte Pypy-Interpreter hingegen am schnellsten ausgeführt hat. Das noch viel spannendere Ergebnis war dann aber, als jemand den irrtümlich für den korrekten Algorithmus gehaltenen durch eine korrekte Implementierung ersetzt hat, und damit um etliche Faktoren schnelleren Code produziert hat. Interessierte können den Thread hier [1] nachlesen. Mir persönlich hat der damalige Thread jedenfalls einmal mehr gezeigt, daß Algorithmen in der Regel wesentlich mehr Einfluß auf die Performance haben als die verwendeten Werkzeuge. [1] Beitrag "Python oder besser bei C bleiben?" Patrick L. schrieb: > Ändert aber dennoch nichts daran das Der Programmierer sich kaum mehr > mit der Hardware selber befasst und so in sehr vielen Fällen daher nicht > mehr Optimiert Programmiert. Mit der Aussage magst Du Recht haben, aber IMHO ziehst Du die flashcen Schlüsse daraus. Denn wenn sich viele Entwickler nicht mehr ausgiebig mit der Hardware auseinandersetzen müssen, dann deswegen, weil sie es nicht mehr müssen. Das resultiert in portablerer Software und darin, daß eine größere Anzahl von weniger spezialisierten Entwicklern zur Verfügung steht. Das kann man schade finden, wenn man die Beschäftigung mit Hardware, Architekturen und Befehlssätzen für einen hochheiligen Selbstzweck hält, aber für Unternehmen und auch für die Entwickler selbst ist diese größere Flexibilität eine ausgesprochen feine Sache. Mir ist auch Dein Fetisch von der "Optimierten Programmierung" aus professioneller Sicht ein wenig unverständlich. Denn Softwareentwicklung kostet Geld, und am Ende ist die Abwägung zwischen kleineren Mikrocontrollern und produktiveren Werkzeugen immer dieselbe. Es nutzt Dir ökonomisch nichts, wenn Du bei einer Serie von 1.000 Geräten zwar 50 Cent pro Gerät am Mikrocontroller sparst, aber einen Arbeitstag eines Entwicklers zusätzlich bezahlen mußt, der kostet nämlich etwa 560 Euro und Dich damit 56 Cent Mehrkosten pro Gerät... Und am Ende gilt: für nicht genutzte Ressourcen gibt es leider kein Geld zurück.
Beitrag #6961301 wurde von einem Moderator gelöscht.
Dieter D. schrieb: > Chris D. schrieb: >> Nein, das möchte ich mir auf Assemblerebene nicht mehr antun. C steht >> beim Speicherplatzverbrauch einem Assemblerprogramm kaum nach - wie das >> Moby-Beispiel vor ein paar Jahren zeigte, konnte das der Compiler sogar >> besser ;-) > > Das ist auch nicht so verwunderlich, wenn ich daran zurückdenke denke > wieviele Veröffentlichungen von Doktorarbeiten es zum Beispiel zur > Optimierung von Compilern im letzten Jahrtausend gab, die bestimmte > Strukturen bereits im Sourcecode erkennen um einen effektiven > compelierten Code auszuspucken. > > Im Vergleich zu diesem Aufwand, der im Compiler steckt, schnitt die > genannte Person des erwähnten Beispiels erstaunlich gut ab. Für ein Projekt von ausgesprochen überschaubarer Komplexität, um nicht zu sagen: ein geradezu triviales Projetchen. Je umfangreicher sowas wird, desto stärker wird der Compiler und desto schlechter der Mensch.
Ein T. schrieb: > Mir ist auch Dein Fetisch von der "Optimierten Programmierung" aus > professioneller Sicht ein wenig unverständlich. Denn Softwareentwicklung > kostet Geld, und am Ende ist die Abwägung zwischen kleineren > Mikrocontrollern und produktiveren Werkzeugen immer dieselbe. Es nutzt > Dir ökonomisch nichts, wenn Du bei einer Serie von 1.000 Geräten zwar 50 > Cent pro Gerät am Mikrocontroller sparst, aber einen Arbeitstag eines > Entwicklers zusätzlich bezahlen mußt, der kostet nämlich etwa 560 Euro > und Dich damit 56 Cent Mehrkosten pro Gerät... Und am Ende gilt: für > nicht genutzte Ressourcen gibt es leider kein Geld zurück Da hängen sehr viele Faktoren mit zusammen, kann man wenn man will so sehen, ist aber in der Realität oft anders. Angefangen damit dass wen das Mitbewerbergerät 56 Cent günstiger ist wirst du keins verkaufen. Aber das ist nicht der Springende Punkt. Der liegt wen die Stückzahlen in die 100'000 de gehen. Oder auch nicht nur die 56 Cent am µP Gespart, da kommen noch zig Faktoren mit ins Spiel. Global gesehen hast du recht, Nur sind es oft zig andere Faktoren die Entscheidend sind den kleineren µP zu nehmen. In vielen Fällen, die wir umsetzen ist ein Faktor den Stromverbrauch. So verrückt es klingt aber da wird um jedes 0,0x µA Gekämft. In Chemieanwendungen bspw. wurde vom Kunden bezahlt, dies so weit runter zu brechen wie nur irgend möglich. Es ging da um Sensoren mit Netzwerkkommunikation, die aus dem Netzwerk gespiesen werden mussten. Raus kam dann, von Anfangs einem STM32xx schlussendlich ein F2013 Einsparung an Strom 2000% Einsparung PCB und Bauteile 200% Kostenersparnis lag bei rund 1%, wenn man es wieder mit allem Hochrechnet (Inkl Programmieroverhead) Man kann sich natürlich dann Fragen, "War es das Wert?", Dem Kunden scheinbar schon, den es wäre sonst weder vom Platz, noch vom Strom, noch vom Design her realisierbar gewesen. Der Kunde hätte es wohl auch machen lassen wenn es 500% mehr gekostet hätte, nur ob wir dann zum Zug gekommen wären, steht wo anders geschrieben. Wie dem auch sei, es wurde so gefordert, den das Geld einsparen war nicht das primäre Kriterium. So kann man einfach nicht Global sagen, das oder dies oder jenes sei besser. Das muss immer von Fall zu Fall abgewogen werden.
Beitrag #6961492 wurde von einem Moderator gelöscht.
Beitrag #6961760 wurde von einem Moderator gelöscht.
Beitrag #6962988 wurde von einem Moderator gelöscht.
Beitrag #6964074 wurde von einem Moderator gelöscht.
Beitrag #6967359 wurde von einem Moderator gelöscht.
Beitrag #6969015 wurde von einem Moderator gelöscht.
Beitrag #6969021 wurde von einem Moderator gelöscht.
Beitrag #6969041 wurde von einem Moderator gelöscht.
Beitrag #6969144 wurde von einem Moderator gelöscht.
Beitrag #6969695 wurde von einem Moderator gelöscht.
Beitrag #6970153 wurde von einem Moderator gelöscht.
Beitrag #6970408 wurde von einem Moderator gelöscht.
Beitrag #6971215 wurde von einem Moderator gelöscht.
Beitrag #6971293 wurde von einem Moderator gelöscht.
Beitrag #6971385 wurde von einem Moderator gelöscht.
Beitrag #6973502 wurde von einem Moderator gelöscht.
Beitrag #6973534 wurde von einem Moderator gelöscht.
Beitrag #6974132 wurde von einem Moderator gelöscht.
Beitrag #6974344 wurde von einem Moderator gelöscht.
Beitrag #6974536 wurde von einem Moderator gelöscht.
Beitrag #6974650 wurde von einem Moderator gelöscht.
Beitrag #6975109 wurde von einem Moderator gelöscht.
Beitrag #6975687 wurde von einem Moderator gelöscht.
Beitrag #6975719 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.