Problem mit atan in c

also was jetzt

Bitte informier dich erst (schau dir z.b. den generierten Assemblercode an, oder mach Performancetests), bevor du postest.

Ich will ja nix sagen aber:

http://www.cantrip.org/wave12.html
http://www.codeproject.com/cpp/garb....asp?print=true
http://www.relisoft.com/book/lang/poly/2implem.html

und am wichtigsten:
http://www.eventhelix.com/RealtimeM...Performance.htm

und da gibts noch einiges...

und nochwas: http://www.cantrip.org/realworld.html

des is doch alles vollkommen irrelevant

OO is natürlich viel langsamer, als wennman alles komplett händisch in maschinensprache programmiert
aber das isja net da sinn der sache

OO soll das programmieren erleichtern. man soll kompliziertere zusammenhänge und vorgänge einfacher darstellen können, als wennman alles händisch macht
und da spielt performance a untergeordnete rolle

natürlich optimiert man bei einem performance-kritischen einsatz des programms den code, bevor es released wird
aber da spielen sachen wie pointer oder direkte variable, wert ausrechnen oder gleich reinspeichern, nur eine sehr kleine rolle
da gehts mehr um strukturelle optimierung
zb. nicht 3 schleifen hintereinander, um etwas zu analysieren, sondern versuchen, es in einer zu schaffen

Zitat von that

Und wo in den vielen Dokumenten steht, dass ein Zugriff auf int *p schneller ist als auf int i ?

Niergends, aber steht drinnen des beides overhead erzeugt und es sich letztendlich im allgemeinen Aufhebt. Bei nicht OO programmierung wird zwar alles "hardcoded", allerdings verlangsamt sich des ganze durch andere Faktoren.

In allen Dokus steht eigentlich drinnen des wir uns alle geirrt haben und des sich sauber OO im Endeffekt mit nicht OO gleicht!

[edit]
Okay hab jetzt selber mal gschwind nen mini test geschrieben uns muss euch leida Recht geben
Allerdings hebt sich im Endeffekt der Speed wieder auf, da bei nich OO oft zusätzliche Paras an Fuktionen übergeben werden die dann wieder für overhead sorgen
Aber mit der var habt ihr Recht!
[/edit]

Zitat von .deRElict.

ein doc, in dem steht, "dass sich im endeffekt eh alles aufhebt" nehm ich mir vielleicht als einsteiger her, aber als Guide wenns um Performanceoptimierung geht, isses eher unbrauchbar.

bzgl. der Performance von OO in C++ kann ich nicht wirklich eine Aussage machen, da ich mich mehr in der C-Welt zuhause fühle

Ja klar die doc war ja auch nur da damit ich ned ganz so dumm dasteh

Naja C++ erleichtert einem des Leben schon sehr, muss aber sagen dadurch des ich mit C angefangen hab tendier ich auch mehr zu C.

Bei C++ (also jetzt OO mit C++) kommt sicher dazu des man sich einige Parameter erpsart usw, und das alles macht die Performance natürlich auch wieder besser, auf der anderen Seite sind Pointer zugriffe aber eben langsamer - also es is ne Streitfrage und kommt ganz drauf an was man machen will!

Zitat von Ringding

Wenn man's gescheit anstellt, hat man in C++ keine Performanceeinbußen gegenüber C.

Ich weiß, des war des was ich gesagt habe

Nur ab und zu ist es einfacher was in C zu machen, aber es gibt auch Dinge die in C++ wieder leichter sind - also im Endeffekt kommt es auch drauf an was man eigentlich machen will!

Mfg, Vir@s

Hey Jungs!

Um ein paar Dingle klarzustellen: auf einem P2/P3 wird sogar ein Sinus in einem Taktzyklus bearbeitet. Der ASM-Befehl dafür ist fsin.
Bzgl. des Variablenzugriffs:

int *i = new int;

macht intern unter anderen so was:

void *i = malloc (sizeof (int));

D.H. er muß jedes mal von der Runtimelibrary (MSVCRT, LIBC, ...whatever) Speicher allokieren. Diese legt davor und danach noch Checkbytes um sicherzustellen, das der Speicher zwischen new und delete nicht überschrieben wurde.
Auf gut Deutsch da hängt ein ziemlich langer Rattenschwanz dran!

Unter Window$ läuft es bei automatischen Variablen (int i so,
das am Anfang das ESP Register um 4 Byte (die Größe eines ints) geändert wird und anschließend kann mit einer relativen Anweisung [ESP+x] direkt drauf zugegriffen werden!

Und kümmert euch bitte nicht darum statt (1 + 4) (5) hinzuschreiben, das checkt echt JEDER noch so blöde Compiler (Sogar das alte Turbo Pascal konnte das, obwohl der nun wirklich nicht sonderlich optimiert hat)! Im Zweifelsfall den Compiler arbeiten lassen - der macht es besser und kennt meistens mehr Tricks!

Nochmal bzgl. Pointer:
Pointer sind wichtig wenn man eine Struktur ab zB. 50 Byte verwendet. Um zu vermeiden, das bei jedem Funktionsaufruf 50 Byte kopiert werden müssen wird nur ein Register (der Pointer) kopiert. Außerdem sind Pointer (als Arrays) wichtig, wenn man erst zur Laufzeit weiß wieviele Elemente ein Array fassen soll. Bei Performance kritischen Operationen sollte sogar hier ein statisches (überdimensioniertes) Array verwenden werden.

So, genug geschwafelt.
Regards
PHaX