Problem mit atan in c - Seite 3

Seite 3 von 4 - Forum: Coding Stuff auf overclockers.at

URL: https://www.overclockers.at/coding-stuff/problem_mit_atan_in_c_38550/page_3 - zur Vollversion wechseln!

FMFlash schrieb am 20.06.2002 um 22:47

also was jetzt :confused:

Vir@s schrieb am 20.06.2002 um 22:48

Zitat von that
Ernsthaft: Pointer sind natürlich langsamer als der direkte Zugriff auf die Variable.

Na Pointer sind schneller

Aber ehrlich - warum glaubst verwendet man Pointer Technik on OO Programmierung? Sicher ned damit es langsamer is

that schrieb am 20.06.2002 um 22:54

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

schrieb am 20.06.2002 um 22:56

da brauchma kein assembler freak sein, da reicht imho logisches denken

Vir@s schrieb am 20.06.2002 um 23:21

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

that schrieb am 20.06.2002 um 23:46

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

Oculus schrieb am 21.06.2002 um 00:21

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

FMFlash schrieb am 21.06.2002 um 01:22

hab mir ein kleines testtool geschrieben, und der direkte zugriff ist um 33% schneller

Vir@s schrieb am 21.06.2002 um 05:51

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]

schrieb am 21.06.2002 um 06:15

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

Vir@s schrieb am 21.06.2002 um 06:34

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!

Ringding schrieb am 21.06.2002 um 11:06

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

Vir@s schrieb am 21.06.2002 um 12:48

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

Indigo schrieb am 22.06.2002 um 13:25

Zitat von Ringding
(normale Befehle brauchen einen Takt, und davon koennen auch noch mehrere im selben Takt ausgefuehrt werden)

nicht alle befehle können in einem taktzyklus ausgeführt werden
->g0t instructionlist???

PHaX schrieb am 28.06.2002 um 09:53

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