C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  SCOOP          C++Talk.NET Forum Index -> C++ (German) View previous topic :: View next topic   Author Message Stephan Menzel Guest Posted: Sun Mar 04, 2007 1:40 am    Post subject: SCOOP Hi zusammen, ich habe mir in den letzten Tagen mal das folgende Paper und seine Implikationen angeschaut: http://www.lrde.epita.fr/dload/papers/mpool03.pdf Im Wesentlichen geht es darum, ein Paradigma zu entwickeln das es erlaubt, tradtionelle OOP mit Vererbung, abstrakten Klassen etc. mittels Templates Nachzubilden um den damit normalerweise verbundenen Laufzeitoverhead zu vermeiden. Alles in allem sicher raffiniert, jedoch auch hoechst kompliziert und ueberaus haesslich. Nahezu unlesbar wuerde ich sagen, was das Paper auch als Drawback auflistet. Die Frage ist: Ist es das (dennoch) wert? Wie hoch ist dieser sagenumwobene Performanceverlust durch aktiv genutztes OOP in C++ ueberhaupt? Man hoert immer wieder Werte die mir irgendwie aus den Fingern gesogen klingen, und wenn es sich hier in der Realitaet nur um ein paar Prozent bei Standardaufgaben handelt hab' ich dann doch lieber die Lesbarkeit. Viele Gruesse... Stephan -- Freedom isn't lost in one big step when the storm-troopers show up at your door. It is lost in little pieces, each so small that they tend to be ignored. Richard B. Johnson Back to top Bob Hairgrove Guest Posted: Sun Mar 04, 2007 11:51 pm    Post subject: Re: SCOOP Stephan Menzel wrote: Quote: Hi zusammen, ich habe mir in den letzten Tagen mal das folgende Paper und seine Implikationen angeschaut: http://www.lrde.epita.fr/dload/papers/mpool03.pdf Wann wurde dieses Papier eigentlich geschrieben? Beim ersten Überfliege n scheint es mir, daß dort nichts steht, was nicht schon bei Josuttis und Alexandrescu ausführlich erörtert wurde. Aber vielleicht habe ich ein bißchen zu schnell gelesen... ;) Quote: Im Wesentlichen geht es darum, ein Paradigma zu entwickeln das es erlau bt, Quote: tradtionelle OOP mit Vererbung, abstrakten Klassen etc. mittels Templat es Quote: Nachzubilden um den damit normalerweise verbundenen Laufzeitoverhead zu Quote: vermeiden. Nichts Neues, also... Quote: Alles in allem sicher raffiniert, jedoch auch hoechst kompliziert und ueberaus haesslich. Nahezu unlesbar wuerde ich sagen, was das Paper auc h Quote: als Drawback auflistet. Die Frage ist: Ist es das (dennoch) wert? Wie hoch ist dieser sagenumwo bene Quote: Performanceverlust durch aktiv genutztes OOP in C++ ueberhaupt? Man hoe rt Quote: immer wieder Werte die mir irgendwie aus den Fingern gesogen klingen, u nd Quote: wenn es sich hier in der Realitaet nur um ein paar Prozent bei Standardaufgaben handelt hab' ich dann doch lieber die Lesbarkeit. Bei der Beurteilung jeden Preis-Leistungsverhältnisses muß man natü rlich alle Faktoren mit berücksichtigen. Dabei ist die Wartbarkeit einer Anwendung sehr wichtig; diese wird m.E. meist unterschätzt. Sie ist allerdings nur ein Faktor, aber ein sehr wichtiger. Natürlich hast Du in Deinen Vermutungen soweit recht, weil die meisten Anwendungen 99% der Zeit auf Benutzereingaben warten. Es gibt aber auch andere, und dort kann es bei der Leistungsbeurteilung auf jeden Prozessorzyklus ankommen. Dann hilft nur Testen, und nochmals Testen. Was die Wartbarkeit betrifft: Templates sind ein relativ neues Feature von C++. Viele Programmierer tun sich deshalb noch ein wenig schwer damit, einfach weil sie damit keine (oder schlechte) Erfahrungen haben. Die Vorteile, die eine zur Kompilierzeit mögliche Bindung aller Typen mit sich bringt, müssen natürlich gegen einen längeren (und fehleranfälligeren) Entwicklungszyklus abgewogen werden. Es gibt leider auch ganz handfeste Hindernisse (z.B. dynamische Biblotheken), die den Einsatz von Templates erschweren können. Back to top Marcel Müller Guest Posted: Mon Mar 05, 2007 5:53 am    Post subject: Re: SCOOP Hallo, Bob Hairgrove schrieb: Quote: Im Wesentlichen geht es darum, ein Paradigma zu entwickeln das es erlaubt, tradtionelle OOP mit Vererbung, abstrakten Klassen etc. mittels Templates Nachzubilden um den damit normalerweise verbundenen Laufzeitoverhead zu vermeiden. Nichts Neues, also... ich glaube das wird oft überschätzt. Die meisten Programme sind so meilenweit vom Optimum entfernt, dass das alles in den Nachkommastellen untergeht. Mit geeigneter Programmierung bekommt man auch ohne akrobatische Mengen Templates zu performanten C++-Programmen. Quote: Bei der Beurteilung jeden Preis-Leistungsverhältnisses muß man natürlich alle Faktoren mit berücksichtigen. Dabei ist die Wartbarkeit einer Anwendung sehr wichtig; diese wird m.E. meist unterschätzt. Sie ist allerdings nur ein Faktor, aber ein sehr wichtiger. Full Ack! Insbesondere dann, wenn man nicht der einzige ist. Gilt also für die Arbeit innerhalb einer Entwicklungsabteilung gleichermaßen wie für Open Source. Lediglich bei privatem Eigenbedarf ist das zweitrangig. Aber "Nach mir die Sintflut" ist in Zeiten knapper Budgets und enger Projekttermine auch im kommerziellen Bereich weit verbreitet. Selbst wenn das in der TCO-Rechnung weit nach hinten losgeht. Der erforderliche Skill des Programmierers ist letztlich auch ein Aspekt der Wartbarkeit. Sogesehen ist die klassische Spaghettiprogramierung gar nicht so schlecht. Da wurschteln sich komischerweise viele (fluchend) irgendwie durch, während sie bei einem komplexen OOP-Programm straucheln. Es gibt auch noch einen weiteren Aspekt, der (sinnvolle) Aufwand für die erforderliche Entwicklerdokumentation steigt bei komplexen OOP-Lösungen.. Letztlich muss die Idee, die hinter dem Konzept steht vermittelt werden, sonst wird der Nächste das Modell nicht effizient nutzen können.. Quote: Anwendungen 99% der Zeit auf Benutzereingaben warten. Es gibt aber auch andere, und dort kann es bei der Leistungsbeurteilung auf jeden Prozessorzyklus ankommen. Dann hilft nur Testen, und nochmals Testen. Ja, aber bei letztgenanntem kommen Faktoren rein, die nicht mehr mit den prinzipsbedingten Einschränkungen von C++ oder auch einer anderen Sprache zu erklären sind. Alignmentfragen oder Cachegrößen sowie der verwendete Compiler nebst der Zielarchitektur haben beträchlichen Einfluss. Portabel ist da nichts mehr - jedenfalls nicht die Information über die Performance. Quote: Was die Wartbarkeit betrifft: Templates sind ein relativ neues Feature von C++. Naja, neu ist relativ. So Anfang/Mitte der 90-ger habe ich auch schon Templates verwendet. Wenn auch nicht in der Breite von heute. Zugegeben, erst in den letzten vielleicht 5-7 Jahren ist C++ und die Standardbibliothek so rund geworden, dass es wirklich Spaß macht, generisch zu programmieren. Quote: Viele Programmierer tun sich deshalb noch ein wenig schwer damit, einfach weil sie damit keine (oder schlechte) Erfahrungen haben. Das stimmt in jedem Fall. Nach meiner Erfahrung hat ein erheblicher Teil der Programmierer nach gar nicht begriffen, /warum/ man OOP verwendet. Aus den typischen einfachen Literaturbeispielen oder Übungsaufgaben erschließt sich das jedenfalls selten. Da geht nur hervor /wie/ es geht.. Insbesondere meine Erfahrungen mit kommerziellem Code möchte ich hier lieber nicht breittreten, das gebietet die Höflichkeit. Das Thema Performance leidet da üblicherweise nicht an C++ sondern an völlig hirnrissigen, zusammengefuddelten Konzepten. Das ist im Ergebnis zuweilen kaum besser, als wenn ich einen ambitionierten Schüler dran setze, der einfach ohne Konzept loshackt. Interessanterweise sind die hochpreisigen Marktsegmente besonders betroffen. Da meint wohl jeder, er könnte was, oder es gibt einfach nicht genug wirklich gute Leute. Quote: Die Vorteile, die eine zur Kompilierzeit mögliche Bindung aller Typen mit sich bringt, müssen natürlich gegen einen längeren (und fehleranfälligeren) Entwicklungszyklus abgewogen werden. Das kann ich auch nicht uneingeschränkt bestätigen. Wenn man die Mittel von C++ und speziell auch die Templates, sauber nutzt, sinkt zuweilen die Fehlerrate sogar, weil der Compiler natürlich schon einiges abweist, was sonst erst viel später aufgefallen wäre. Insofern ist es nicht ganz fair, von einem längeren Entwicklungszyklus zu sprechen. Natürlich, wenn man es bis zum Exzess treibt, geht alles nach hinten los. Wesentlich offensichtlicher ist für mich die Korrelation zwischen spät im Produktzyklus gefundenen Programmfehlern und der Häufigkeit mit der der Programmierer Copy & Paste für ganze Codeblöcke eingesetzt hat. Durch das duplizieren werden oft auch Fehler dupliziert, die dann mehrfach korrigiert werden müssen. Zuweilen an Programmstellen, wo sie aufgrund der Umstände erst nach Jahren auffallen. Die Effizienzfrage muss man letztlich bei jeder Performanceoptimierung grob abschätzen. Bei Code, der nur alle paar Stunden mal durchlaufen wird, ist schon das Nachdenken Zeit- und Energieverschwendung. Auf die Aufwandsklasse eines Algorithmus sollte man hingegen schon ein Auge werfen. Und dabei vor allem nicht vergessen, was in einer Schleife aufgerufen wird. Falls es nur irgendeinen vernünftigen Grund gibt, dass die Datenmenge steigen könnte, und sei es nur im Fehlerfall, ist bei allem jenseits von O(n log(n)) Vorsicht angebracht. Tragischerweise habe ich es außer bei STL und mathematischen Bibliotheken noch nie erlebt, dass die Aufwandsklasse von Bibliotheksfunktionen überhaupt Bestandteil der Dokumentation ist. Um wieder auf den C++-Overhead zurückzukommen. Oft ist es möglich, den Overhead in einer niedrigeren Aufwandsklasse zu halten, als die des Algorithmus selbst. Dann ist man im allgemeinen auf der sicheren Seite und macht die Performance durch C++ nicht kaputt. Nach meiner Erfahrung rangieren solche sprachbezogenen Peformanceaspekte auf Platz 3 oder 4 hinter solchen Dinge wie der geschickten Wahl der Datenstrukturen, der Programmstruktur und selbst dem Programmierstil verschiedener Programmierer. Selbst nicht für ihre Performance bekannte Sprachen bekommt man durch geeignete Programmierung ziemlich schnell (Java oder sogar Perl oder ABAP Objects). OK, für Numbercrunching sind die vielleicht nichts. Aber vor C++ schrecke ich selbst bei letztgenannten Anforderungen nicht mehr zurück. Ich habe vor einiger Zeit erst eine objektorientierte, operatorbasierte DSP-Bibliothek in C++ geschrieben, die selbst zu meiner Überraschung sogar mit FIR-Filterkernen von 16384 Samples Länge auf einem alten K6 noch Sounddaten in Echtzeit verarbeiten kann. Quote: Es gibt leider auch ganz handfeste Hindernisse (z.B. dynamische Biblotheken), die den Einsatz von Templates erschweren können. Yep! Aber auch da gibt es Tricks, mit denen man einige Vorteile vereinen kann. Z.B. kann es oft helfen, eine nicht-templatebasierte, unvollständig typisierte Implementierung in eine Bibliothek zu packen und letztlich über eine Template-Klasse mit der Bibliothek zu arbeiten, die nur den typabhängigen Teil der Implementierung enthält. Aber das geht natürlich nicht immer. Insbesondere dann nicht, wenn man sich um die Polymorphie drücken möchte. Und man verliert auch die Typensicherheit in der Bibliotheksimplementierung. Solche Techniken verwende ich zuweilen auch ohne DLLs weil sie den Code schlank und damit auch schneller machen. Die Tatsache, das jeder Objektpointer nach void* und wieder zurück garantiert verlustfrei castbar ist, ist dabei sehr hilfreich. Das kann man z.B. durch eine partielle Spezialisierung geschickt ausnutzen. Marcel PS.: was ist eigentlich mit dem Thunderbird los gewesen? Das Quoting war ja völlig kaputt! Back to top Bob Hairgrove Guest Posted: Tue Mar 06, 2007 2:21 am    Post subject: Re: SCOOP On Mon, 05 Mar 2007 00:53:53 +0100, Marcel Müller <news.5.maazl (AT) spamgourmet (DOT) com> wrote: Danke für das interessante Feedback! Quote: PS.: was ist eigentlich mit dem Thunderbird los gewesen? Das Quoting war Quote: ja völlig kaputt! Wie man sieht, passiert mir das auch beim Forté-Reader (aber nur in dieser NG, komischerweise) ... Dabei hatte ich gehofft, daß ich das Problem mit TB aus der Welt schaffen könnte. -- Bob Hairgrove NoSpamPlease (AT) Home (DOT) com Back to top Stefan Reuther Guest Posted: Tue Mar 06, 2007 3:45 am    Post subject: Re: SCOOP Bob Hairgrove wrote: Quote: On Mon, 05 Mar 2007 00:53:53 +0100, Marcel Müller PS.: was ist eigentlich mit dem Thunderbird los gewesen? Das Quoting war ja völlig kaputt! Wie man sieht, passiert mir das auch beim Forté-Reader (aber nur in dieser NG, komischerweise) ... Dabei hatte ich gehofft, daß ich das Problem mit TB aus der Welt schaffen könnte. Auch wenn's vollkommen OT ist, aber damit es einmal in der Newsgroup steht: Das Problem ist der Newsserver von "hispeed.ch". Dieser setzt zum Transport der Postings zum Moderator das Program "ssmtp" ein, welches die Zeilenschaltungen verdoppelt (und auch noch ein paar andere Macken hat), und tritt unabhängig vom Newsreader in allen moderierten Newsgruppen auf. Stefan (fup2p vorgeschlagen) Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ (German) All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.