Zitat von
Olli:
Zitat von
Der_Unwissende:
Hinzu kommt auch noch, dass man mit Makros oder den Verzicht auf Funktionen den Overhead erspart, der nun mal mit jedem Funktionsaufruf statt findet. Allerdings dürfte kaum ein sinnvolles Projekt entstehen, wenn man hier einfach mal den ganzen Code in eine einzelne Anweisung schreibt. Da wird die Fehleranfälligkeit und die fehlende Wartbarkeit bei weitem den vermeintlichen Geschwindigkeitsvorteil überwiegen.
Schlechte Idee, denn damit erspart man sich auch gleich die Typensicherheit (mit Makros). Daher wurden Templates und inline-Funktionen/Methoden bereitgestellt die es besser als Makros bringen.
Schon klar, aber moderne Compiler entscheiden afaik selbst einige Funktionen einfach inline zu setzen, egal ob dies im Code explizit vorgegeben wurde oder nicht.
Es ging mir eigentlich nur darum zu sagen, dass ein objektives "Ist schneller" auch fempto-Sekungen bezeichnen kann, mekrt keiner, ist aber schneller. Nur zählt beim Code nie alleine die Perfomance. Ist der Code voll von Fehlern, wird der in keinem System eingesetzt (zumindest nicht all zu oft). Da gibt es halt noch andere Punkte, warum Code sauber und lesbar sein sollte und ich glaube niemand sollte sein Sprache rein nach der (vermeindlichen) Perfomance aussuchen. Immerhin bleibt nun mal jede Indirektion ein klarer Perfomance-Killer, erlaubt aber ein paar nette Dinge bei der Programmierung, deren Vorteile vielleicht die eine Indirektion mehr oder weniger locker überwiegen.
Zitat von
Olli:
Zitat von
Der_Unwissende:
Wenn es danach geht, muss man doch schon zwischen reinen RISC und eben auch CISC Architekturen unterscheiden.
Reines CISC gibt es meines Wissens nach nicht mehr bei Intel und AMD. Beide benutzen einen Mix. Wobei AMD eher auf RISC-Elemente setzte.
Wiedermal nur afaik sind die Kerne der CPUs natürlich RISC und nur sehr sehr sehr wenige Befehle noch CISC (eh schlechte Benennung CISC), aber trotzdem kann es nunmal schon durch die Archtitektur zur Interpretation kommen (genauso wie Code halt nur schneller sein kann, hat wie ja oft genug gesagt wurde nichts mit der Sprache zu tun).
An sich ist es halt nur immer etwas langweilig die These zu lesen, dass Sprache A noch viel perfomanter ist als Sprache B. Wichtiger ist da doch eh, dass Entwickler C in A und B schnelleren Code erstellt als D, weil D einfach keine effizienten Datenstrukturen kennt...