Funktion optimieren?

Christoph

iSAK schrieb:

casts sind langsam! sagt jetzt nicht das ist UNSINN! TGGC hats bewiesen! Und lame Funktionen kann man für games nicht gebrauchen!

Es ist ja so bequem, wenn man auf Autoritäten (?) verweist, anstelle selbst nachzudenken...

Bashar

cd9000: Das ist offensichtlich ein Fake.

Christoph

Bashar schrieb:

cd9000: Das ist offensichtlich ein Fake.

Danke für diesen Hinweis.

Deswegen habe ich keine Gegenargumente oder Links gebracht.

hier der beweis oh ihr großen meister:

http://www.c-plusplus.net/forum/viewtopic.php?t=53847&highlight=trash

Shade Of Mine

Geo schrieb:

2. Output=result; hat die (hier) gewünschte Wirkung.

Ah, obfuscated. Jetzt hab ichs verstanden...

@iSAK:
*lol*

float <-> int ist lahm, aber auch nur relativ

Bashars Variante finde ich am besten, vorausgesetzt man ersetzt den cast durch ne ordentliche Konvertierung.

Bashar

Shade Of Mine schrieb:

Geo schrieb:

2. Output=result; hat die (hier) gewünschte Wirkung.

Ah, obfuscated. Jetzt hab ichs verstanden...

Dann ist die gewünschte Wirkung aber eine sehr seltsame. C++ hat immer noch Call-by-value, dh output wird nicht verändert.

@iSAK:
*lol*

float <-> int ist lahm, aber auch nur relativ

hier wird nirgends float in int umgewandelt. erstens nur float in float und zweitens sowieso nur ein CMatrix* in einen float*. Zeigerkonvertierungen sind kostenlos (mal Memberpointer und ähnliches rausgelassen) und werden nur gemacht, um den Gott des statischen Typsystems zu besänftigen.

Bashars Variante finde ich am besten, vorausgesetzt man ersetzt den cast durch ne ordentliche Konvertierung.

Was verstehst du unter ordentlicher Konvertierung? Ich fürchte diese würde am Kernpunkt meiner Variante vorbei gehen.

Was ist an einem Pointer-Cast (oder reinterpret_cast, wo gar nichts an den Daten geändert wird), bitte langsam? AFAIK werden da einfach nur die Daten an der Adresse anders interpretiert beim Auslesen.
Aber was solls, du willst einfach nichts von ein paar Leuten lernen, die sich mit der Materie auskennen. Stattdessen berufst du dich auf ein kurzes Trash-Programm von TGGC, was völlig andere Konvertierungen vornimmt und sagst, casts sind langsam.

Bashar schrieb:

... und werden nur gemacht, um den Gott des statischen Typsystems zu besänftigen.

*lol*

Mis2com

casts sind langsam!

reinterpret? lol?

sagt jetzt nicht das ist UNSINN! TGGC hats bewiesen!

LOL

Und lame Funktionen kann man für games nicht gebrauchen!

Und Leute, die Quatsch reden dieses Forum auch nicht, schon mal überlegt, dass reinterpret einfach nur den Speicher anders interpretiert, daran ist nichts langsam.

MfG MAV

Shade Of Mine

Bashar schrieb:

Shade Of Mine schrieb:

Geo schrieb:

2. Output=result; hat die (hier) gewünschte Wirkung.

Ah, obfuscated. Jetzt hab ichs verstanden...

Dann ist die gewünschte Wirkung aber eine sehr seltsame. C++ hat immer noch Call-by-value, dh output wird nicht verändert.

Die gewünschte Wirkung scheint zu sein, dass man am Ende return Output; schreiben kann.

das also Output auf den static Buffer zeigt, wenn es NULL ist. Und genau das ist irgendwie sehr verwirrend.

hier wird nirgends float in int umgewandelt.

Genau das habe ich gemeint. Ich wollte darauf hinweisen, dass int <-> float nicht ideal ist - andere casts aber deswegen nicht auch 'teuer' sind.

Was verstehst du unter ordentlicher Konvertierung? Ich fürchte diese würde am Kernpunkt meiner Variante vorbei gehen.

Dann würdest du davon ausgehen, dass Matrix so implementiert ist:

class Matrix
{
 float values[x][y];
};

das ist aber IMHO gefährlich, denn ein

class Matrix
{
 unsigned x,y;
 float* values;
};

erscheint mir als Matrix Implementation genauso logisch. Oder ich habe den Kern echt nicht verstanden sorry.

Geo

Geo schrieb:
2. Output=result; hat die (hier) gewünschte Wirkung.

...

Dann ist die gewünschte Wirkung aber eine sehr seltsame. C++ hat immer noch Call-by-value, dh output wird nicht verändert.

Richtig erkannt, wenn Output==NULL ist, wird Output hier zu einer normalen Variablen "degradiert".

Bashar

zu der Output-Geschichte: Sorry, ich war etwas zu voreilig.

Shade: Achso. Nein, iSAK hat seine Implementation schon gepostet:

class CMatrix {
  public:
    float _11, _12, etc...;
};

Wenn man keinen besonders böswilligen Compiler vor sich hat funktioniert meine Variante. Ich hab ja auch dazugesagt, das es nicht standardkonform ist, aber bei Hochleistungsanwendungen wie Spielen, die noch dazu auf eine sehr enge Plattformauswahl eingeschränkt sind, spielt Portabilität nicht so die Rolle.

Shade Of Mine

Bashar schrieb:

Shade: Achso. Nein, iSAK hat seine Implementation schon gepostet:

Oh, das habe ich übersehen. Dann ist deine Variante natürlich OK.

SirLant

Was ist an Bashars Variante überhaupt anzuzweifeln? Kann mich mal er aufklären?

Bashar

die einzelnen floats (_11, _12 usw.) müssen nicht zwingend lückenlos aufeinander im Speicher liegen, das kann der Compiler nach gutdünken entscheiden. Beispielsweise sind auf heutigen PCs 32-Bit-Speicherzugriffe auf Daten, die an durch 4 teilbaren Adressen liegen, deutlich schneller als wenn sie an krummen Adressen liegen. Da ist es also sinnvoll, eine char und eine int-Variable intern so zu verpacken:

struct A {
  char c;
  char __dummy[3];
  int i;
};

Wenn ein Compiler Lust hat, kann er das auch mit lauter floats machen, der Standard verbietet es nicht.

Mis2com schrieb:

casts sind langsam!

reinterpret? lol?

sagt jetzt nicht das ist UNSINN! TGGC hats bewiesen!

LOL

1. lies mal das 2. wort von reinterpret_cast.

2. Im gegensatz zu dir hat er mal was bewiesen und zu ende gemacht,

Bist du so dumm, oder tust du nur so. da steht ganz offensichtlich "float*" !!! Das heit, es findet keine umwandlung, sondern tatsächlich eine reine reinterpretation statt!!! und die kosten gar nichts. Überhaupt nichts. Wogegen deine Version jenach dem ob der erste Parameter NULL ist oder nicht eine oder zwei komplette Kopien der Matrix anlegt.

Und TGGC's Beispiel ist korrekt, hat aber überhaupt nichts mit dem hier gezegten zu tun. Dort wurde tatsächlich umgewandelt.

cast ist cast, ob reinterpret, static, dynamic und co. cast ist cast

Schafft es mal endlich einer, diesen Thread zu schließen und unregistrierte, grüne kleine Wichte mit blauen Haaren aus diesem Forum zu verbannen?

wieso damit wieder so ein Scheiss wie im Grafik und Spieleprogrammierforum passiert?

Da schaffen die Mods ja nix! Da wird seit Tagen rumgeflamet zwischen diversen Membern und die Mods oder Admins greifen nicht ein oder gucken sich den shice erstmal an!

Für mich sind einige Mods hier sehr inkompetent!!!!! Und das selbe würde hier auch Passieren!!!!

Mis2com

Ein für alle Mal, TGGC hat nur den static_cast überprüft, oder vielleicht den C-Cast der diesem entspricht.
Nur weil an 2. Stelle cast steht, bedeutet das noch lange nicht, dass das Teil langsam ist.
Und anstatt jetzt pausenlos einzuwenden, dass dieser ,,Cast'' langsam ist, solltest du es mal selber ausprobieren, dann können wir gerne weiterreden.

Unter diesen Voraussetzungen hat eine Diskussion keinen Sinn.

So, ich habe selber mal getestet:

#include <iostream>
#include <windows.h>

int main()
{
	const double NPASSES = 100000000.;
	float  f = 100;
	int    n;
	DWORD dw1, dw2;

	dw1 = GetTickCount();

	for(int f_n = 0; f_n < NPASSES; ++f_n)
		n = static_cast<int>(f);

	dw2 = GetTickCount();

	std::cout.flags(std::ios::fixed);

	std::cout << "Dieser Cast benötigt " << (dw2-dw1)/NPASSES << " Millisekunden.\n";

	return 0;
}

Ich weiß ja nicht, was du unter schnell verstehst...

#include <iostream>
#include <windows.h>

int main()
{
	const double NPASSES = 100000000.;
	float* pf = new float;
	int*   pn;
	DWORD dw1, dw2;

	dw1 = GetTickCount();

	for(int f_n = 0; f_n < NPASSES; ++f_n)
		pn = reinterpret_cast<int*>(pf);

	dw2 = GetTickCount();

	std::cout.flags(std::ios::fixed);

	std::cout << "Dieser Cast benötigt " << (dw2-dw1)/NPASSES << " Millisekunden.\n";

	return 0;
}

Gemessen:

static_cast: 0.000054 ms
reinterpret_cast: 0.000010 ms

Wobei mein PC ein Athlon mit 900 MHz ist...

MfG MAV