C++ schneller als andere Sprachen?
-
fricky schrieb:
camper schrieb:
Es scheint aber, dass es einigen C-Fanatikern nicht in den Kopf geht, dass nicht jedes kleine Programm jedes einzelne Sprachfeature nutzen muss und diese überflüssige Nutzung ungeeigneter Sprachmittel natürlich der Performance nicht zuträglich sein wird. Da beide Sprachen (C und C++) grundsätzlich auf dem selben Maschinenmodell beruhen und für jedes Sprachmittel eine offensichtliche und effiziente (wenn auch nicht unbedingt optimale) Implementierung möglich ist, gibt es keinen Grund für fundamentale Unterschiede hinsichtlich Geschwindigkeit, Speicherverbrauch etc.
die unterschiede sind zwar marginal, aber summieren sich auf. z.b. verwendet der c-coder gern char* mit zeichenketten. wer mit c++ rummacht, der nimmt lieber std::string. wo bei einem 'char *hallo = "hallo";' einfach eine adresse in den speicher geschrieben wird, führt 'std::string hallo = "hallo";' eine vielzahl von schritten aus. man erkauft sich höhere flexibilität für speed und speicherverbrauch.
andererseits kannst du mit c++ dinge wie z.b. http://www.flipcode.com/archives/Faster_Vector_Math_Using_Templates.shtml machen die kaum in c zu machen sind, klar koennte man alle formeln auch per hand ausschreiben in c, aber dann waeren bibliotheken unnuetz. mit template math kann man hingegen dem compiler sehr helfen optimierten code zu schreiben.
-
Asm-Hacker schrieb:
Ich spüre sogar den Unterschied zwischen mov eax,0 und test eax,eax!!!
troll
-
Das Assembler schneller ist als gut optimiertes C kann, muss aber nicht mehr sein.
Ich hab mir einmal das Assembler Resultat von einem Programm-Stück angeschaut, der ein wenig langsam lief. Mitten in einer Schleife hab ich ein eigentlich völlig unnötigesxor eax, eax
gefunden. Der Wert von EAX wurde danach eigentlich nicht mehr gebraucht, deshalb hab ich das mal gelöscht und neu assembliert. Resultat: Das ganze wurde langsamer.
Ich nehme an, dass der Prozessor durch das eindeutige Löschen von EAX den Rest des Codes (der nicht vom Ergebnis davor abhängt) nebenher ausführen kann. Was die Prozessoren mit ihren MicroOps machen ist ja nicht mehr so ganz verständlich...
-
da hab ich die gegenteilige erfahrung gemacht
-
C >> Java >> C++ :p
-
DEvent schrieb:
C >> Java >> C++ :p
Also dafür möchte ich nun wirklich einen Beweis (und zwar nicht so einen in der c't Art, die den Javacode relativ gut geschrieben hatten, den C++ Code aber so schlecht aufgebaut hatten, das man ebensogut einen geschobenen Düsenjäger mit einem gefahrenen Trabi hätte vergleichen können).
cu André
-
asc schrieb:
DEvent schrieb:
C >> Java >> C++ :p
Also dafür möchte ich nun wirklich einen Beweis (und zwar nicht so einen in der c't Art, die den Javacode relativ gut geschrieben hatten, den C++ Code aber so schlecht aufgebaut hatten, das man ebensogut einen geschobenen Düsenjäger mit einem gefahrenen Trabi hätte vergleichen können).
cu André
Ich habe eigentlich meine persoehnliche Favoriten aufgezaehlt
Ich denke das viele denken C++ seih die schnellste Sprache liegt einfach daran dass z.B. Spiele-Engines, Datenbaken, Server usw. in C++ geschrieben sind.
Dabei kann man einen Server auch in Java schreiben, z.B. Tomcat, DNS Server, Mail Server, SMTP Server usw. In Java kann man auch Spiele schreiben, da eh 90% der Berechnungen in der GPU stattfindet.
In C schreibe ich Programme die extrem viele Berechnungen machen, aber kein Speicherverwaltung oder Benutzereingaben haben/brauchen, oder Programme die Hardwareanbindung brauchen. Ebenso Bibliotheken, weil C der kleinste gemeinsame Nenner ist.
In Java schreibe ich den Rest, komplexe Projekte, GUI, Server, Anwendungen mit Thread und Sockets.
C++ ist fuer mich irgendwie obsolete geworten. Den Overhead fuer C++ will ich nicht mehr haben. Overhead ist z.B. Anwendungen portabel machen, die Include-Lib-Hoelle, das staendige neu kompelieren usw.
-
DEvent schrieb:
C++ ist fuer mich irgendwie obsolete geworten.
-
DEvent schrieb:
Ich habe eigentlich meine persoehnliche Favoriten aufgezaehlt
Okay, unter den Umständen habe ich keine Probleme damit, dann sähe es bei mir auch anders aus: C# >> C++ >> Java >> C (Was aber nichts mit der Geschwindigkeit zu tun hat).
DEvent schrieb:
C++ ist fuer mich irgendwie obsolete geworten. Den Overhead fuer C++ will ich nicht mehr haben. Overhead ist z.B. Anwendungen portabel machen, die Include-Lib-Hoelle, das staendige neu kompelieren usw.
Also ich habe mit C nicht mindere Probleme (Wobei ich dich durchaus verstehe, nachfolgendes ist meine Meinung). C++ gibt mir Konstrukte zur Vereinfachung, selbst wenn ich in Schnittstellen teilweise (je nach Portabilitätsanforderungen) auf C zurückgreifen muss.
Und auch ein C-Programm muss man neu kompilieren (Wenn du auf die TMPL abziehlst wirst du das eh unter C nicht haben können, damit wäre der Vergleich obsolente; Und wenn man C++ entsprechend Programmiert sind die Compilezeiten auch nicht wirklich ein problem).
Aber in Teilen kann ich es wirklich nachfühlen. Bis heute gibt es in C++ keine portablen Libs (wenn man wirklich mit C++ in den Schnittstellen arbeiten will), keine Standard-UI (Okay, auch nicht unter C)... Für mich hat sowohl C wie auch C++ den Zahn der Zeit verschlafen, man hätte vieles im nächsten C++ Standard nachholen können, aber der ist mir noch nicht weitreichend genug.
Dennoch muss ich gestehen das ich bei privaten Projektideen nach geraumer Zeit wieder zu C++ zurückkehre...
cu André
-
DEvent schrieb:
Ich denke das viele denken C++ seih die schnellste Sprache liegt einfach daran dass z.B. Spiele-Engines, Datenbaken, Server usw. in C++ geschrieben sind.
du scheinbar auch:
In Java kann man auch Spiele schreiben, da eh 90% der Berechnungen in der GPU stattfindet.
sonst wuerdest du ja nicht im gleichen atemzug behaupten dass man es auch in java coden kann da man nicht cpu limitiert ist.
btw. ist deine verallgemeinerung allgemein falsch
-
asc schrieb:
Also ich habe mit C nicht mindere Probleme (Wobei ich dich durchaus verstehe, nachfolgendes ist meine Meinung). C++ gibt mir Konstrukte zur Vereinfachung, selbst wenn ich in Schnittstellen teilweise (je nach Portabilitätsanforderungen) auf C zurückgreifen muss.
Ich vermisse nichts in C++ was ich nicht in C haben kann. Templates, Klassen und Operatorueberladung brauche ich nicht. OOP kann ich genauso gut in C machen und man hat den Vorteil das man C Code viel einfacher in andere Sprachen einbinden kann.
-
hi wer code mit mmorpg die quellzeilen bitte!!!!!!!!!!!
ich will es verkaufen du kriegst 1% ab also gib mmo
beeil dich
-
Hi,
was ich immer noch nicht so ganz verstehen kann, ist das herumreiten auf Portabilität. Sicher, für manchen ist es wichtig, aber ich behaupte mal, daß 95% aller Programmierer nur für eine Umgebung coden. Wer macht denn wirklich regelmäßig Programme, die sowohl unter Win als auch unter Linux, Unix und Mac laufen müssen.
Und was die Bandbreite von Win 3.1 bis Win Vista betrifft, wers braucht... Für die meisten Programme die heute noch entwickelt werden reicht es doch völlig aus, wenn die ab XP oder meinetwegen ab Win 2000 laufen. Auch die Frage welcher Prozessor ist in vielen Fällen nicht bolle, weil das langsamste Glied der Kette meist 30 cm vor dem Rechner sitzt.
So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???
In vielen fällen sitzt doch da nachher ein Nutzer vor dem Rechner, für den ein Computer ein Kasten mit vielen Knöpfen ist. Dem geht Portablität oder das letzte Ausreizen der Geschwindigkeit so was am Kreuz vorbei... der will einfach daß jedes neue Programm genau so aussieht, wie die die er bisher von Windows kennt damit er sich zurechtfindet und sich nicht neu einarbeiten muß...Gruß Mümmel
-
muemmel schrieb:
So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???
Das sehe ich absolut nicht ein - in C oder C++ vielleicht (auch nicht, wenn du dir einfach angewoehnst multiplattform-Frameworks zu verwenden). Aber wenn du in Java oder Python entwickelst, ist das Ganze kein Thema. Und ich reduziere meine Moeglichkeiten dabei mitnichten auf den kleinsten Nenner, da das unterliegende Framework in der Regel Features, die auf einer Plattform nicht vorhanden sind, mit eigenen Mitteln implementiert. Da ist Portabilitaet kein Thema, sie ist impliziert.
-
muemmel schrieb:
was ich immer noch nicht so ganz verstehen kann, ist das herumreiten auf Portabilität. Sicher, für manchen ist es wichtig, aber ich behaupte mal, daß 95% aller Programmierer nur für eine Umgebung coden.
Ja, sicherlich mag das stimmen. Aber schon einmal daran gedacht das dann irgendeiner aus der Höheren Etage dem Kunden verspricht das die Anwendung in Kürze auch für xyz verfügbar ist (So etwas in leicht entschärfter Form habe ich schon erlebt).
Okay, lassen wir das Thema Portabilität mal weg: Nenn mir bitte eine C++ UI-Bibliothek (Plattform sei erstmal egal) die mit relativ modernen C++ klarkommt, und wo man nicht dauernt zwischen Anwendungslogik und Oberfläche portieren muss. Zudem sei die Anforderung das man eine möglichst freie IDE-Wahl hat, und nicht auf irgendeine Bibliotheksspezifische auszuweichen.
muemmel schrieb:
Und was die Bandbreite von Win 3.1 bis Win Vista betrifft, wers braucht... Für die meisten Programme die heute noch entwickelt werden reicht es doch völlig aus, wenn die ab XP oder meinetwegen ab Win 2000 laufen.
Weißt du was die erste Reaktion war als ich vor etwa einem halben Jahr meinen Chef gesagt habe das es eine Sprache+UI gibt, die seine UI-Anforderungen und die der Kunden weitgehend zufriedenstellen könnte, als ich den Nachteil (Lauffähig erst ab XP Servicepack 2) genennt hatte.
muemmel schrieb:
So schön komplett portable Programme sein mögen, aber Portabilität heißt unweigerlich IMMER auch eine Einigung auf den KLEINSTEN Nenner. Ob das immer im Interesse des Kunden ist???
Schon richtig, was mich aber auch auf einer Plattform stört wenn man unter C++ entwickelt, ist das man für die UI in der Regel noch ein paar Kompromisse machen muss. Nichts gegen C++, wenn man davon absieht (und von der fehlenden Binärkompatibilität) bin ich mit der Sprache voll zufrieden.
muemmel schrieb:
der will einfach daß jedes neue Programm genau so aussieht, wie die die er bisher von Windows kennt damit er sich zurechtfindet und sich nicht neu einarbeiten muß...
Dieser Satz hat ich schon so häufig in Konflikte mit meinen Chef gebracht. Da seine Interpretation von Oberflächenstandard dem von etwa 95% aller Windowsanwendungen zuwider läuft.
cu André
-
Hi André,
vielleicht sollte Dein Chef mal darüber nachdenken, wer den "Spaß" wirklich bezahlt, er oder der Kunde.
Daß Chefs immer zu großen Versprechungen neigen hab ich leider selbst erlebt... (natürlich können wir auch...).
Meist wird dann viel Arbeit in eine ganz kleine Sache reingesteckt, die man unter Umständen mit ienem Bruchteil an Aufwand gleich mal in Excel machen könnte...
Es gibt immer noch die alte Regel, daß 80 % der Wünsche mit 20 % vom Aufwand befriedigt werden können. Für die restlichen 20 % benötigts dann 80 %, also ein mehrfaches...
Sicher ist Kunde König, aber man muß immer unterscheiden, zwischen Brot- und Butter-Software die für die Masse der Kunden die die Geldbüchse nur ganz wenig aufmachen ist, und handgeschmiedeter Edelsoftware für die Goldcard-Kunden die dann aber auch adäquat dafür zahlen müssen.
Oft ist es aber so, daß die Masse Dinge bezahlt, die sie nie im Leben braucht, weil ein paar ganz wenige Sonderwünsche haben und glauben, daß die mit ihrem 08/15-Einkauf auch abzudecken sein müssen.
Lieber ein paar Mäkel-Kunden verlieren, aber dem Rest eine soliede und preiswerte Lösung anbieten.
Was die IDE und das GUI betrifft, so ist CodeGears VCL sicher nicht optimal, zumals ja eine in Pascal geschriebene ist aber ich hab mich daran gewöhnt und kann bisher ganz gut damit leben.
Gruß Mümmel
-
Nenn mir bitte eine C++ UI-Bibliothek (Plattform sei erstmal egal) die mit relativ modernen C++ klarkommt, und wo man nicht dauernt zwischen Anwendungslogik und Oberfläche portieren muss. Zudem sei die Anforderung das man eine möglichst freie IDE-Wahl hat, und nicht auf irgendeine Bibliotheksspezifische auszuweichen.
gtkmm + Bakery ist z.B. so ein Kandidat, kannst du mind. mit MSVC und GCC benutzen... IDE ist dir somit auch frei gestellt.
Weißt du was die erste Reaktion war als ich vor etwa einem halben Jahr meinen Chef gesagt habe das es eine Sprache+UI gibt, die seine UI-Anforderungen und die der Kunden weitgehend zufriedenstellen könnte, als ich den Nachteil (Lauffähig erst ab XP Servicepack 2) genennt hatte.
Dann muß das der Kunde bezahlen, wenn er spezielle Anforderungen hat. Die meisten Chefs haben aber leider keinen Arsch in der Hose. Da ruft der Kunde am Freitag an, will was zu Montag haben, und der Chef sagt "Klar, machen wir!". Hallo??? Und der kleine Angestellte darf das Wochenende durcharbeiten. Warum? Weil der Chef keinen Mumm hat, dem Kunden zu verklickern, das es so einfach nicht geht oder der ordentlich für die Wochenendarbeit draufzahlen muß!
Genau das gleiche, wenn der Kunde vielleicht von Uralt-Systeme einsetzt aber Ansprpüche stellt, die man nur mit modernen Systemen kostengünstig erfüllen kann. Entweder verklickert man das dem Kunden, oder man hält die Hand auf für den Extraaufwand.
-
Übrigens haben diese Probleme nichts mit C++ speziell zu tun. Unser Kunde setzt Java 1.4 ein. Und nein, wir dürfen keine Java 1.5 Features einsetzen. Wenn der Kunde Features haben will, die nur mit 1.5 bereits vorhanden sind, sagen wir "Kostet jetzt aber natürlich extra-Arbeit und somit mehr Geld."
Aber hat der Kunde selber schuld, wenn er nicht auf 1.5 umsteigt. Gut für uns, die Arbeit geht uns nicht aus.
-
muemmel schrieb:
vielleicht sollte Dein Chef mal darüber nachdenken, wer den "Spaß" wirklich bezahlt, er oder der Kunde.
Mir egal *aufkalenderschau*, noch 14 Tage dann war es das...
muemmel schrieb:
Es gibt immer noch die alte Regel, daß 80 % der Wünsche mit 20 % vom Aufwand befriedigt werden können. Für die restlichen 20 % benötigts dann 80 %, also ein mehrfaches...
Das Problem ist hierbei extremer. Wenn wir nur die Kundenwünsche betrachten würden, und dann erstmal 80% mit normalen Möglichkeiten umsetzen würden, wäre den Kunden schon mehr geholfen. Aber die Standardoptik von MS gefällt dem Chef nicht (Was dazu führt das man an der UI deutlich länger hängt als nötig, und sie danach aussieht... naja, jeder hat einen Eigenen Geschmack). Controls die sich Standardkonform verhalten (und ggf. da zugekaufte ActiveX, damit es "schneller" geht, auch nicht komplett änderbar sind, sollen grundlegend anders eingesetzt werden als geplant) werden nach dem Geschmack vom Chef mit seinem "Standard"-verhalten angepasst...
muemmel schrieb:
Sicher ist Kunde König, ...
Manchmal frage ich mich wie masochistisch oder abhängig Kunden von einer Software sein können, das sie alles mit sich machen lassen. Und das schlimmste ist wenn man dann einen Kunden weitervermittelt bekommt, der etwas von der Bedienung nicht versteht, und man ihn nur an den Chef weiterleiten kann, da man selbst nicht versteht warum man es so, und nicht wie in anderen Anwendungen lösen sollte... (Wenn man z.B. etwas in eine Anwendung einbaut, würde ich mich in erster Linie grob an dem orientieren, was der Kunde schon kennt bzw. was auf dieser Plattform der Standard wäre [zumindestens von der Bedienung her]).
muemmel schrieb:
Oft ist es aber so, daß die Masse Dinge bezahlt, die sie nie im Leben braucht, weil ein paar ganz wenige Sonderwünsche haben und glauben, daß die mit ihrem 08/15-Einkauf auch abzudecken sein müssen.
Ich würde sagen bei uns ist 80% Chefwunsch, vom Rest 80% Kundenwunsch... Das der Kunde dann effektiv noch deutlich weniger erhält als geplant ist logisch (Oder man soll ein komplexes Modul entwerfen, und bekommt dazu ganze 2(!) Sätze an Informationen. Wenn man dann ständig nachfragt heißt es das man nicht selbstständig arbeitet - wenn man aber sich an bestehenden Orientiert ohne nachzufragen wird am Schluß alles auseinander gerissen).
muemmel schrieb:
Lieber ein paar Mäkel-Kunden verlieren, aber dem Rest eine soliede und preiswerte Lösung anbieten.
Lieber Kunden haben als keine Kunden haben.
muemmel schrieb:
Was die IDE und das GUI betrifft, so ist CodeGears VCL sicher nicht optimal, zumals ja eine in Pascal geschriebene ist aber ich hab mich daran gewöhnt und kann bisher ganz gut damit leben.
Ich muss gestehen das ich die VCL trotz aller Nachteile auch nicht schlecht finde. Ohne die Extremsonderwünsche meines Chefs wäre das auch DIE Umgebung für unsere Firma (statt dessen setzen wir auf Compiler die seit 10 Jahren nicht mehr supportet sind).
Nur wegen der vielen Sonderwünsche wäre für unsere Firma tatsächlich .Net und WPF besser (1. kann man dann das Aussehen der Controls mit einheitlichen Templates versehen, 2. Ist die Oberfläche skalierbar und 3. kann man dann auch Wünsche wie Checkbuttons in Karteireitern, Buttons und andere Elemente in Treeviewelementen etc. ohne riesigen Aufwand einbauen).
cu André
P.S. Bevor ich zu meiner jetzigen Firma kam, die ich nun nach 4 Jahren verlasse dachte ich, ich hätte Chaosprojekte gekannt. Jetzt muss ich sagen das ich mich zurücksehne an die vorherigen Firmen die wenigstens etwas Kundenorientierter, Standardkonformer und vor allem auch mit zumindest maginaler Dokumentation gearbeitet haben (Ich schätze das 95% der Dokumentation zu der Software von mir stammt, und das auch nur dort wo ich etwas Zeit hatte - und 99% aller Dokumentation dürfe rein im Sourcecode sein).Konzepte, kann man das essen?
-
BarnieGeroellheimer schrieb:
Weißt du was die erste Reaktion war als ich vor etwa einem halben Jahr meinen Chef gesagt habe das es eine Sprache+UI gibt, die seine UI-Anforderungen und die der Kunden weitgehend zufriedenstellen könnte, als ich den Nachteil (Lauffähig erst ab XP Servicepack 2) genennt hatte.
Dann muß das der Kunde bezahlen, wenn er spezielle Anforderungen hat. Die meisten Chefs haben aber leider keinen ***** in der Hose.
Der Chef ist mehr das Problem als die Kunden. Die wären schon zufrieden wenn man 25% aller Fehler beseitigen würde.
cu André