Frage zur Geschwindigkeit von Pointern
-
Hi,
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?
-
LukasBanana schrieb:
Wieß also jemand ob es langsamer ist, wenn man auf große Speicherbereiche zugreift?
ja, das weiß jemand.
-
ernsthaft: der c++-standard sagt nichts darüber aus, wie schnell ein zugriff auf einen speicherbereich beliebiger größe zu erfolgen hat. deshalb hat diese frage wenig mit c++, aber viel mit deinem zielsystem zu tun.
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.
-
LukasBanana schrieb:
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?
-
LukasBanana ist mir ein Rätsel. Ist tatsächlich in der Lage, einen 3D-Software-Renderer zu schreiben, weiß aber andererseits nicht über so grundlegende Caching-Mechanismen bescheid, bzw. was ein Profiler ist.
-
@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.
-
LukasBanana schrieb:
@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?! ^^
-
LukasBanana schrieb:
@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.
-
Ich habe noch nie mit Profilern gearbeitet, wo kann ich da sowas herunterladen oder handelt es sich dabei um etwas, das ich selbst im Programm zum Debuggen verwenden bzw. schreiben muss??
-
Freie, gute Profiler sind leider recht rahr.
Wenn du ne AMD CPU hast, dann ist der AMD Code Analyst recht gut. Der geht zwar auch mit Intel CPUs, aber dann nur mit 1ms Samples (was für meine Anwendungen meist viel zu wenig ist).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?)
-
hustbaer schrieb:
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.
-
@hustbaer: mir ist gar nicht bekannt, dass es Hobby-Programmierern überhaupt möglich ist, Programme für die PS3 zu entwickeln. Wenn das geht, sagt mir bitte wie
aber ob du es glaubst oder nicht, ich entwickel einen SoftwareRenderer für PCs (http://softpixelengine.sourceforge.net/GalleryImg30b.PNG)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.
-
LukasBanana schrieb:
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.
-
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
-
LukasBanana schrieb:
@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?
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.
-
LukasBanana schrieb:
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.
-
hustbaer schrieb:
...
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.
-
Simon2 schrieb:
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.
-
Jo. Das nennt sich Vektorisierung und hat mit Threading im Prinzip nix zu tun.
-
Xebov schrieb:
Multithreating
-
hustbaer schrieb:
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.
