Ich versuche meinen SoftwareRenderer immer noch etwas schneller zu kriegen. Beim SoftwareRendering muss man sich leider über jedes "" oder "/" Gedanken machen und versuchen, ob man es nicht mit einem ">>" oder einem "<<" ersetzen kann.
Jetzt bin ich bei mehrmaligem Herumprobieren auf den Verdacht gekommen, dass mein C++ Programm auch ein wenig an Geschwindigkeit verlieren könnte, wenn ich auf die "unsigned char ImageData = new unsigned char[width*height*4]" Puffer zugreife und dabei eben sehr große Wete für den Index des Puffers zu stande kommen
(z.B. "Texture->ImageData[(100*80)<<2]"). Auf das "clampen" der Texture Koordinaten macht das alles - für jeden Pixel eben - sehr langsam.

Wieß also jemand ob es langsamer ist, wenn man auf große Speicherbereiche zugreift?

Wieß also jemand ob es langsamer ist, wenn man auf große Speicherbereiche zugreift?

ja, das weiß jemand.

in der praxis sieht es so aus, dass cpus einen cache haben, in den daten vorsorglich für den schnelleren zugriff geladen werden können.
das funktioniert meistens so lange gut, wie auf aufeinanderfolgende adressen zugegriffen wird. machst du dann beim zugriff auf einen großen buffer (zu) große sprünge, geht die geschwindigkeit runter. mit kleinen buffern passiert das seltener.

was "groß" und "klein" konkret heißt, kann man so pauschal nicht sagen. das hängt immer vom system ab.

Jetzt bin ich bei mehrmaligem Herumprobieren auf den Verdacht gekommen, [...]

Willst du uns ersnthaft erzählen, dass du versuchst dein Programm durch herumprobieren und Verdächtigungen zu optimieren?

@jupp: danke aber für den Tipp wegen den Cache, ich guck mal wie ich das hinbekomme.

@all: Ich habe nicht gesagt, dass ich den SoftwareRenderer nur durch Herumprobiererei zu optimieren versuchen, aber ich bin mit meinem Latain am Ende, was die Optimierung betrifft.

@jupp: danke aber für den Tipp wegen den Cache, ich guck mal wie ich das hinbekomme.

ähm... gar nicht?! ^^

@all: Ich habe nicht gesagt, dass ich den SoftwareRenderer nur durch Herumprobiererei zu optimieren versuchen, aber ich bin mit meinem Latain am Ende, was die Optimierung betrifft.

Und wenn man nicht mehr weiter weiss, versucht man auf gut Glück etwas, das das Laufzeitverhalten mit grosser Wahrscheinlichkeit nicht wesentlich verbessert, im Gegenzug aber zu hässlichem Code führt?

Im Ernst, bevor du denkst, dass eine Multiplikation durch einen Shift ersetzt werden sollte, wäre es hilfreich, mit einem Profiler die wirklichen Performanceprobleme aufzuspüren. Was Shift & Co. betrifft, sind Compiler ganz gut im Optimieren.

Profilen solltest du allerdings immer auf der Zielplattform. Da ich mir grad nicht ganz vorstellen kann, dass du nen Software-Renderer für PCs schreibst, bräuchtest du also einen Profiler für ... was auch immer deine Zielplattform ist. (Lass mich raten... Nintendo DS? Playstation 3?)

Profilen solltest du allerdings immer auf der Zielplattform.

Für wirklich spezifische Optimierungen schon. Oft kann es allerdings sein, dass man zuerst gröbere Flaschenhälse (z.B. durch falsche Datenstrukturen oder ineffiziente Algorithmen) aufdeckt, die sich auch portabel behandeln lassen.

Ich habe einen "Intel Core 2 Duo" aber die MultiKernel CPUs helfen einem beim SoftwareRendering nicht sehr viel, höchsten in Verbindung mit MultiThreading.

Insgesammt denke ich, werde ich wohl doch einfach versuchen müssen, die Algorithmen zu verbessern.

Ich habe einen "Intel Core 2 Duo" aber die MultiKernel CPUs helfen einem beim SoftwareRendering nicht sehr viel, höchsten in Verbindung mit MultiThreading.

Das ist sehr weise. Ungefähr so als würde man sagen: Ein ComPuter hilft beim Rechnen nicht sehr viel, höchsten in VerBindung mit ElekTrizität.

Aber ich seh' schon wo hin das fürt, also ist es glaube ich das Beste, dises Diskussion einfach zu beenden und zu vergessen

@hustbaer: mir ist gar nicht bekannt, dass es Hobby-Programmierern überhaupt möglich ist, Programme für die PS3 zu entwickeln.

Na ganz einfach mit Linux.
Der Grund warum ich auf die PS3 komme: der Hypervisor der PS3 lässt dich von Linux aus nicht auf den 3D Chip zugreifen. D.h. entweder nur 2D, oder Software-Rendering.

aber ob du es glaubst oder nicht, ich entwickel einen SoftwareRenderer für PCs

Wozu?

@Nexus:

Für wirklich spezifische Optimierungen schon. Oft kann es allerdings sein, dass man zuerst gröbere Flaschenhälse (z.B. durch falsche Datenstrukturen oder ineffiziente Algorithmen) aufdeckt, die sich auch portabel behandeln lassen.

Da hast du Recht, habe mich ungenau ausgedrückt. "Immer" ist falsch.

In diesem Fall wäre es unsinnig woanders zu profilen -- Performanze von Speicherzugriffen ist ja wohl sehr plattformabhängig. Da die Zielplattform allerdings doch ein PC ist, ist das ja jetzt egal.

Mit MultiThreading meinte ich Thread-Programmierung im eigenen Programm, nicht vom Betriebsystem aus

Aber ich seh' schon wo hin das fürt, also ist es glaube ich das Beste, dises Diskussion einfach zu beenden und zu vergessen

Nein. Er hat Recht.

Wenn du bei einem Software-Renderer nicht mehrere Threads (ja, in einem Programm) verwenden willst, wo dann???

Rendering von 3D-Szenen lässt sich *wunderbar* parallelisieren.

...
Wenn du bei einem Software-Renderer nicht mehrere Threads (ja, in einem Programm) verwenden willst, wo dann???...

Hi,

ich vermute, dass er hofft, dass das Betriebssystem oder irgendeine andere Instanz "automatisch" sein Programm "multithreaded".
Das ist auch gar nicht so weit hergeholt ... als ich mal vor Ewigkeiten einen Programmierkurs für "Vektorrechner" mitgemacht habe, spielte immer eine wesentliche Rolle, dass man sein Programm auf eine bestimmte Weise strukturieren musste. Nur dann war "die VAX" (ich vermute allerdings eher den Compiler) in der Lage, Berechnungen zu parallelisieren.

Gruß,

Simon2.

Nur dann war "die VAX" (ich vermute allerdings eher den Compiler) in der Lage, Berechnungen zu parallelisieren.

Die Frage ist dann aber eher war damit wirklich Multithreating gemeint oder (was ich eher glaube) SSE oder eine vergleichbare Technik, SSE ist ja heute serienmäßig bei AMDs und Intels drin.

Multithreating

Jo. Das nennt sich Vektorisierung und hat mit Threading im Prinzip nix zu tun.

Wenn Ihr der Meinung seid, dass dieser Unterschied dem Fragesteller schon bewusst war und er garantiert das eine und nicht das Andere und schon gar nicht einfach nur "irgendeine Form beiläufiger Verarbeitung" gemeint hat, habe ich mich natürlich gräßlich geirrt und bitte vielmals um Verzeihung.

Gruß,

Simon2.

Vektorisieren kann man Code auch schon für die alten Single-Core CPUs mit MMX/SSE/SSE2/...
Das können auch einige Compiler, allerdings eher schlecht als recht.
Vernünftigerweise muss man es selbst machen, indem man die (hoffentlich vorhandenen) Compiler-Intrinsics verwendet. Aber ich schweife ab, das is wieder ein anderes Thema.

Wie kann er Vektorisierung gemeint haben ...

Unterstell mir doch bitte nichts, was ich weder sagte noch meinte.
Das Beispiel mit der VAX habe ich lediglich gebracht als Beispiel dafür, dass man an einen Mechanismus denken kann, bei dem beiläufige Verarbeitung ohne eigenes Zutun des Programmierers zum Tragen kommen kann.

Also habe ich weder behauptet, er würde auf einer VAX programmieren, noch an Vektorrechnung denken oder irgendetwas Anderes aus meinem Beispiel.

Ganz einfach: Ich vermute, dass der OP davon ausgeht, dass es "irgendeine" Form der Beiläufigkeit gibt, um die er sich nicht selbst kümmern muss.

Gruß,

Simon2.