Funktion optimieren?

Bashar

Verstehst du meinen Vorschlag nicht, findest du ihn Sch****, oder warum ignorierst du ihn?

Geo

Ohne Matrix zu optimieren könnte man schreiben:

float *ConvertMatrixToFloatArray (float* Output, const CMatrix &Matrix) 
{ 
  static float result[16];
  if (!Output) Output = result; 
  float* fptr = Output;

  *fptr++ = Matrix._11; 
  *fptr++ = Matrix._12; 
  *fptr++ = Matrix._13; 
  *fptr++ = Matrix._14; 

  *fptr++ = Matrix._21; 
  *fptr++ = Matrix._22; 
  *fptr++ = Matrix._23; 
  *fptr++ = Matrix._24; 

  *fptr++ = Matrix._31; 
  *fptr++ = Matrix._32; 
  *fptr++ = Matrix._33; 
  *fptr++ = Matrix._34; 

  *fptr++ = Matrix._41; 
  *fptr++ = Matrix._42; 
  *fptr++ = Matrix._43; 
  *fptr   = Matrix._44; 

  return Output; 
}

Shade Of Mine

Geo schrieb:

Ohne Matrix zu optimieren könnte man schreiben:

und was ist daran optimiert?

das Output=result; hat auch nicht die gewünschte Wirkung...

Geo

1. Die Codegröße ist optimiert.

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

Bashar schrieb:

Verstehst du meinen Vorschlag nicht, findest du ihn Sch****, oder warum ignorierst du ihn?

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

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,