float oder double für OpenGL?

Erst einmal, danke für die Antworten. Ist Float tatsächlich schneller? Ich habe mal gelesen, dass Double eher direkt von der CPU unterstützt wird und float eh in double dann aufgepumpt wird. Na, da habe ich wohl falsch gelesen.

Ist es so, dass der Compiler mit SSE etc besser mit floats optimieren kann?

Ich denke, ich werde es dann doch mal mit Templates probieren, habe mich bis dato da noch nicht ran getraut.

Was ist guardband size und warum Ints?

Ach noch dazu. Ich komme aus der Javaecke und probiere mich jetzt in C++. Ich hatte auch den Softwarerenderer in Java angefangen, war dann aber mit der Performance unter OSX überhaupt nicht zufrieden. Mein PC nahm sich 3% Rechenleistung für meine Gameloop und der Mac immer so im Schnitt 50%. Gut der PC hat einen i7 und der Mac einen i5, aber so einen großen Unterschied sollte das nicht ausmachen. Java ist unter OSX extrem mies zu benutzen, in meinen Augen. Und von wegen einmal schreiben und überall benutzen. Das Java unter OSX hat teilweise ein anderes Verhalten als das unter Windows, es macht z.B. einen Unterschied wann ich pack() aufrufen usw. Ganz schlimm wurde es nach einem Update auf Mavericks und Yosemite, da war dann selbst Eclipse langsam im Scrollen. Ich musste dann wieder downgraden auf Mountain Lion. Steve Jobs hat da wohl noch Wert auf Qualität gelegt, auch wenn Java dort extrem an den Ressourcen zieht.

Wird dann auch mein letztes Appleprodukt gewesen sein. Lenovo baut auch auch schöne Rechner und OSX hat auch viele Negativpunkte die mich total nerven. Aber das ist alles total Offtopic.

Wäre schön wenn ihr mir bei meinen Fragen helfen könnt.

SeppJ

DerHomogene schrieb:

Erst einmal, danke für die Antworten. Ist Float tatsächlich schneller? Ich habe mal gelesen, dass Double eher direkt von der CPU unterstützt wird und float eh in double dann aufgepumpt wird. Na, da habe ich wohl falsch gelesen.

Du has nicht falsch gelesen, du hast bloss etwas von vor 10-15 Jahren gelesen. Auch wenn die Technik nicht mehr ganz so rasant fortschreitet wie im letzten Jahrtausend, so sind 10 Jahre doch immer noch ein gewaltiger Sprung in der Computertechnik und man sollte solch alte Quellen mit Vorsicht geniessen.

Ist es so, dass der Compiler mit SSE etc besser mit floats optimieren kann?

Wenn du "doppelt so viele gleichzeitig verarbeiten" als Optimierung ansiehst, dann ja.

Komisches Apple-Bashing

Hat deine Geschichte irgendeinen fuer diesen Thread relevanten Punkt oder willst du einfach nur oeffentlich demonstrieren, dass du keinen blassen Schimmer hast, wer die Standard-JVM fuer OS X schreibt?

Danke für die Aufklärung und nein ich habe keine Ahnung wer die JVM für Apple schreibt, ist doch wohl auch Oracle oder? Gibt es Gründe warum Java unter OSX so schlecht läuft wie es läuft?

Ich meine in C++ ist Apple ja vorbildlich, da wird mit Clang gearbeitet und das Qt-Paket mit Qt-Creator arbeitet auch standardmäßig mit Clang zusammen, was ich mir wiederum für Windows wünschen würde.

hustbaer

rapso schrieb:

typedef float myReal;

+1

Also raten doch mehr zu typedef als zu Templates. Mit Templates habe ich noch nie gearbeitet, musste man da nicht Deklaration und Definition der Klasse nur im Header machen? Und ist das nicht viel schwieriger zu handeln als ein einfaches typedef?

rapso

soviele fragen

erstmal die off topic
java ist auf osx so scheisse, weil apple die updates kontrolliert und sich viel zeit laesst. Ich hatte auch mal etwas in java geschrieben weil es auf OSX laufen sollte und ich "runs everywhere" glaubte und dann startete es auf OSX garnicht. musste dann eine version aelter zum kompilieren nutzen und da fehlte eine sache die ich nutze. cumbersome.
Aber das ist nur ein ganz kleiner teil von apple. Du kannst ja auch mit c++ darauf arbeiten. (wie du schon sagtest).

zum topic.
floats und doubles werden eigentlich gleich schnell vom prozessor verarbeitet, compiler optimieren eher schlecht als recht auf SSE. auf anderen platformen ist double um einiges langsammer (arm, cell,...), aber das betrifft dich erstmal nicht.

typedef und templates schliessen sich nicht aus. typedef kannst du nutzen um grundsaetzlich einen typen festzulegen. innerhalb eine vector klasse hingegen moechtest du vielleicht nicht explizit auf einen typedef zugreifen, da kannst du dann den typen als template parameter nutzen und damit das template typedefen

typedef float myReal;
typedef Vector<myReal> myVector;

ints benutzt man weil es sich deterministischer verhaelt. bei float bekommst du unterschiedliche resultate je nachdem welche operationen du waehlst und in welcher reihenfolge du sie verarbeitest. aber damit solltest du dich nicht zu frueh befassen. spaeter schau dir mal: http://forum.devmaster.net/t/advanced-rasterization/6145 an.

Danke für die ausführliche Erklärung und den Link.

Unter OSX hatte ich aber beim Testen die aktuelle Oracle Java8 JDK installiert. Es war exakt dasselbe JDK, von der Versionsnummer, wie unter Windows. Ist aber auch egal. Mit dem Qt-Creator, auf beiden Plattformen, komme ich bestens klar und die Ergebnisse sind wesentlich identischer als mit Java. Wenn dann noch Clang unter Windows gleich mit dem Qt-Creator mitgeliefert werden würde, wie unter OSX, dann wäre es perfekt.

Osbios

Auf aktuellen CPUs ist double marginal schneller als float.

Auf GPUs sind float berechnungen meist um einige faktoren schneller. Da Spiele so gut wie nie double verwenden.
Faktoren gehen grob von 16/1 bis 4/1 für float/double performance.
Wobei günstige GPUs schlechter und top Modele bessere faktoren haben.

Double ist meist nur für Cuda oder OpenCL compute shader interessant. Und Modele mit double leistung werden entsprechend nicht für den Spielermarkt sondern für forschung/industrie bepreist.

SeppJ

Osbios schrieb:

Auf aktuellen CPUs ist double marginal schneller als float.

Das solltest du noch einmal checken.

dot

Osbios schrieb:

Auf aktuellen CPUs ist double marginal schneller als float.

nope

rapso

Osbios schrieb:

Auf aktuellen CPUs ist double marginal schneller als float.

du bist raus </DieterModus>

hustbaer

double schneller als float kann eigentlich nur sein wenn man mit double nen Haufen Denormals vermeidet die man mit float hätte.

Anders kann zumindest ich es mir nicht vorstellen.

ps: Falls mein "Wissen" veraltet ist, und Denormals keine Penalty mehr bringen, lasst es mich bitte wissen

dot

hustbaer schrieb:

ps: Falls mein "Wissen" veraltet ist, und Denormals keine Penalty mehr bringen, lasst es mich bitte wissen

Seit Sandy Bridge können Denormals afaik in den meisten Fällen ohne Performanceeinbruch bearbeitet werden. Auf älteren Architekturen kann man Flags setzen, um Denormals zu ignorieren (auf Null zu setzen), ansonsten können sie dort massiv zu Buche schlagen.

hustbaer

dot schrieb:

Seit Sandy Bridge können Denormals afaik in den meisten Fällen ohne Performanceeinbruch bearbeitet werden.

Muss ich mal googeln wenn ich Zeit habe...

dot schrieb:

Auf älteren Architekturen kann man Flags setzen, um Denormals zu ignorieren (auf Null zu setzen), ansonsten können sie dort massiv zu Buche schlagen.

Ja, das wusste ich beides. Die CPU wirft da (ohne flush to zero) bloss nen Trap/Interrupt, der Rest geht dann über Software-Emulation wenn ich mich richtig erinnere.

dot

hustbaer schrieb:

dot schrieb:

Auf älteren Architekturen kann man Flags setzen, um Denormals zu ignorieren (auf Null zu setzen), ansonsten können sie dort massiv zu Buche schlagen.

Ja, das wusste ich beides. Die CPU wirft da (ohne flush to zero) bloss nen Trap/Interrupt, der Rest geht dann über Software-Emulation wenn ich mich richtig erinnere.

Afaik werden die Operation lediglich nicht direkt nativ von den Rechenwerken unterstützt und dann durch einen Haufen µops umgesetzt, passiert aber dennoch alles direkt in der CPU. Mit Traps und Softwareemulation wäre der Penalty vermutlich noch mindestens eine Größenordnung schlimmer...

rapso

dot schrieb:

Seit Sandy Bridge können Denormals afaik in den meisten Fällen ohne Performanceeinbruch bearbeitet werden.

ich glaube es sind nur ein paar faelle die ohne einbruch laufen z.B. float add auf SSE. float mul auf SSE sollte schonwieder langsam sein. auf x87/fpu sollte das meiste weiterhin langsam sein.