Du bist nicht angemeldet.

Werbeanzeige

61

10.06.2012, 15:18

Zitat

...Man stelle sich ein 3D-Szenario vor, in dem einige Asteroiden platziert werden sollen. Was spricht dagegen, eine Obergrenze für deren Anzahl festzulegen? Aus Performancegründen können sowieso nicht beliebig viele Objekte animiert und gerendert werden. Speicherverschwendung ist das auch nicht, wenn man davon ausgeht, dass zu irgendeinem Zeitpunkt die Obergrenze erreicht wird...

Aber das ist doch Blödsinn. Nur weil du einen anderen Typ nimmst, hast du noch lange keine Obergrenze. Wenn du dann ein weiteres Objekt dazupackst, hast du einen Überlauf, was vermutlich noch viel katastrophaler ist. Und wenn du eh eine Abfrage brauchst, ist der Datentyp wieder egal.
Lieber dumm fragen, als dumm bleiben!

S4My

unregistriert

62

10.06.2012, 15:45

Aber das ist doch Blödsinn. Nur weil du einen anderen Typ nimmst, hast du noch lange keine Obergrenze. Wenn du dann ein weiteres Objekt dazupackst, hast du einen Überlauf, was vermutlich noch viel katastrophaler ist. Und wenn du eh eine Abfrage brauchst, ist der Datentyp wieder egal.
Das mag schon sein, es ging aber genau darum das man eben kein weiteres Objekt dazupackt, deshalb ja auf Grenze. Wobei das hier nun mehr oder weniger hinfällig ist. Es ging in dem Artikel primär darum nicht unendlich viele Objekte zu erstellen und zu rendern. Ich kann mir kaum vorstellen das hier alle Rechner haben welche nicht von 2000 Asteroiden mit ihren Grafiken und Flugbahnen in die Knie gezwungen würden. Dies war nur ein Ausschnitt aus eben diesem Artikel.
Unendliche Erweiterbarkeit ist zwar schön und gut, aber ich frage mich immer noch was daran so schwer zu verstehen ist das, besonders bei Spielen, das einfach Wunschdenken ist. Rechner können schlichtweg nicht immer weiter und mehr verarbeiten. Auch sie, so gut sie auch sein mögen, haben irgendwann ihren Punkt an dem sie nicht mehr können. Wenn ich dann noch dazu ein Spiel für die Allgemeinheit entwickeln möchte so kann ich nicht davon ausgehen, dass jeder PC ein High End-Modell ist.
Noch schlimmer ist es jedoch wenn man trotz des Wortes Grenze immer wieder von dazupacken spricht. Wo es aus sein soll gibt es kein "wenn aber dann". Ich für meinen Teil halte meine selbst gesteckten Grenzen was das Programm betrifft ein, sonst würden sie ja auch keinen Sinn ergeben. Große Spieletitel, um bei Spielen zu bleiben, haben auch Begrenzungen. "Morrowind" aus der "The Elder Scrolls"-Reihe hat so viel ich weiß eine Art Nebel implementiert, damit können kleine Spielareale größer wirken und so verhindert man einerseits das überlasten des Rechners und andererseits das endlose herumlaufen in der Spielwelt. Endlosigkeit ist zwar eine schöne Idee, jedoch schlichtweg nicht machbar, zumindest nicht so, dass dann auch wirklich alle noch Spaß ohne Framedrops haben können.

Mlg
S4My

63

10.06.2012, 18:34

Hm, so meinte ich das nicht, ich war schon für eine Begrenzung. Ich wollte nur anmerken, dass diese nicht durch kleinere Variablentypen automatisch kommen. Letztendlich bin ich mir jetzt aber gar nicht mehr sicher, ob das überhaupt so vorgeschlagen worden ist :D Sry für die Verwirrung.
Lieber dumm fragen, als dumm bleiben!

dot

Supermoderator

Beiträge: 9 833

Wohnort: Graz

  • Private Nachricht senden

64

10.06.2012, 18:54

Aber das ist doch Blödsinn. Nur weil du einen anderen Typ nimmst, hast du noch lange keine Obergrenze. Wenn du dann ein weiteres Objekt dazupackst, hast du einen Überlauf, was vermutlich noch viel katastrophaler ist. Und wenn du eh eine Abfrage brauchst, ist der Datentyp wieder egal.

Genau das hab ich vorhin auch gemeint, ist offenbar nicht ganz angekommen.

Ich kann mir kaum vorstellen das hier alle Rechner haben welche nicht von 2000 Asteroiden mit ihren Grafiken und Flugbahnen in die Knie gezwungen würden.

Ich würde mal sagen, das hängt ganz stark davon ab, was genau so ein "Asteroid" sein soll. ;)

Unendliche Erweiterbarkeit ist zwar schön und gut, aber ich frage mich immer noch was daran so schwer zu verstehen ist das, besonders bei Spielen, das einfach Wunschdenken ist. Rechner können schlichtweg nicht immer weiter und mehr verarbeiten. Auch sie, so gut sie auch sein mögen, haben irgendwann ihren Punkt an dem sie nicht mehr können.

Das ist eh klar und niemand hat was anderes behauptet. Der Punkt ist, dass du durch die Wahl des Datentypen kein geeignetes Mittel hast um die Anzahl der Objekte zu beschränken. Du brauchst in jedem Fall eine Abfrage; ob dein Counter nun short oder int oder unsigned long long ist, kann daran nix ändern.

Wenn ich dann noch dazu ein Spiel für die Allgemeinheit entwickeln möchte so kann ich nicht davon ausgehen, dass jeder PC ein High End-Modell ist.
Noch schlimmer ist es jedoch wenn man trotz des Wortes Grenze immer wieder von dazupacken spricht. Wo es aus sein soll gibt es kein "wenn aber dann". Ich für meinen Teil halte meine selbst gesteckten Grenzen was das Programm betrifft ein, sonst würden sie ja auch keinen Sinn ergeben. Große Spieletitel, um bei Spielen zu bleiben, haben auch Begrenzungen. "Morrowind" aus der "The Elder Scrolls"-Reihe hat so viel ich weiß eine Art Nebel implementiert, damit können kleine Spielareale größer wirken und so verhindert man einerseits das überlasten des Rechners und andererseits das endlose herumlaufen in der Spielwelt. Endlosigkeit ist zwar eine schöne Idee, jedoch schlichtweg nicht machbar, zumindest nicht so, dass dann auch wirklich alle noch Spaß ohne Framedrops haben können.

Wie gesagt, die Tatsache, dass Ressourcen endlich sind, hat nichts mit dem zu tun, worüber wir hier diskutieren. Zumindest seh ich nicht wirklich den Zusammenhang.

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »dot« (10.06.2012, 19:00)


S4My

unregistriert

65

10.06.2012, 19:45

Ja, ist mir schon klar das das nichts damit zu tun hat. Ich hab mich doch bereits geschlagen gegeben dot, hab erbarmen :D . Ich hab mir das ganze nochmal genau durch den Kopf gehen lassen und sehe ein das Integer besser für gewisse Dinge geeignet ist.
Worum es mir ging war eigentlich dieses ewige hätte, wäre, könnte was Größen und Grenzen betrifft. Jonny, ich wage es einmal dich so zu nennen, sollte ich mir dies nicht erlauben dürfen bessere ich dies gerne aus, ich müsste mich eigentlich entschuldigen, gleich so zu reagieren war nicht wirklich notwendig :) .

Man bekommt natürlich nicht automatisch eine Begrenzung durch kleinere Variabeltypen, das ist auch nicht der Sinn der Sache gewesen. Es war nur eben so, dass man meiner Meinung nach nicht den Overflow als Argument in betracht ziehen sollte um von shorts oder dergleichen abzuraten, schließlich kann dieser bei allen auftreten und bei guten und sicheren Programmcode ist dies sowieso unwahrscheinlich. Die Verwendung dieser sollte nur zeigen welchen Wertebereich man in etwa im Auge hat.

Was dann noch die Asteroidensache angeht, ich würde sagen das sind die bösen Dinger, welche der tollkühne Held der 80er Jahre zu bekämpfen hat :thumbsup: .
OK, wenn ich diese Beispiele aus dem Keller hole so denke ich immer an die momentane Grafikgeneration. Klar gibt es Unterschiede, das Prinzip ändert sich jedoch nicht. Ob ich nun Pixelbrei auf den Bildschirm bringe oder nicht, Begrenzung muss immer mit an Bord sein. Selbstverständlich nicht durch den Datentyp ;) .

Nun, wie gesagt, kann man also darauf verbleiben das int Datentypen die bessere Lösung für die am häufigsten auftretenden Fälle sind, weil Architektur bezogen?

Mlg
S4My

Schrompf

Alter Hase

Beiträge: 1 415

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

66

11.06.2012, 15:34

Weil das gerade in etwa zum Thema passt: https://community.rapid7.com/community/m…y-flaw-in-mysql

memcmp gibt einen int zurück. Manche Leute sind aber schlauer als die Doku und nehmen einen char zum Speichern des Rückgabewerts, weil sie gelesen haben, dass die Rückgabewerte immer -128 bis 127 sind. Tja. Außer manchmal halt. Hier in diesem Fall sorgt das halt dafür, dass auf bestimmten MySQL-Installationen zufällig jedes 256ste Passwort als richtig akzeptiert wird

Und die MySQL-Leute haben wahrscheinlich sogar eine gute Ausrede: die ersten Code-Zeilen davon stammen wahrscheinlich wirklich noch aus Zeiten, als es noch Vorteile brachte, mit einem Byte anstatt zweien oder vieren zu rechnen. Heute dagegen gibt es wirklich keine Ausrede mehr, das noch zu machen. Im Idealfall erkennt der Compiler den Kontext und erweitert selbsttätig auf 32bit- oder 64bit-Mathematik, oder er ist nicht schlau genug, den Fehler des Programmierers zu erkennen, und generiert zusätzlichen Code, um eine Schleife korrekt mit short anstatt int laufen zu lassen.

Nunja, falls das in diesem Thread nicht eh schon klar sein sollte: "Gefühlte Optimierungen" wie die Nutzung eines kleineren Datentypen für alltägliche Aufgaben sind nicht nur kontraproduktiv, sondern potentiell auch gefährlich. Damit ich aber nicht nur als nörgelnder Opa rüberkomme, versuche ich mich an was Produktivem:

Datentypen-Empfehlung *

size_t - wird in 32Bit-Exen ein unsigned int, ansonsten ein unsigned long long. Kann also nicht negativ werden. Ist zu nutzen für:
- Array-Indizes
- Größenrechnungen
- Element-Anzahlen
- Speicherallokationen
- praktisch immer, falls im Zweifel

uint32_t - aus stdint.h, eigene typedefs für solche grundlegenden Typen sind ebenso eine dumme Idee. Immer 32bit unsigned int, auch auf 64Bit-Systemen. Ist zu nutzen für:

- Hashes
- Datenübertragung an Festplatten oder Netzwerkpartner

int - 32Bit vorzeichenbehaftet. Ist zu nutzen für:

- diskrete (schrittweise) Koordinatenrechnungen, z.B. Adressierung der Zellen einer TileMap, weil man da für Bereichsrechnungen auch gern mal ins Negative kommt

short, unsigned short, char, unsigned char - 16bit und 8Bit, mit oder ohne Vorzeichen. Sind zu nutzen für:

- Datenübertragung an Festplatten oder Netzwerkpartner
- spezielle Datenstrukturen, die Abermillionen Mal auftreten und daher ohne solche Optimierungen nicht in den Speicher passen würden
- spezielle Datenstrukturen, die in großen Zahlen auftreten und Abermilliarden Mal pro Sekunde verarbeitet werden müssen - dort kann es sich nach Profiling erweisen, dass eine Reduzierung der Speicherbandbreite einen Gewinn darstellt

NACH PROFILING!

float - 32Bit-Fließkomma-Zahl. Ist zu nutzen für:

- alle Werte, die fließend über die Zeit hinweg geändert werden sollen - Bildschirmkoordinaten, 3D-Koordinaten, aber auch Lebenspunkte, Mana, usw.
- hat nur etwa 7 Stellen Genauigkeit, und zwar Vorkomma und Nachkomma zusammen.

double - 64Bit-Fließkomma-Zahl. Ist zu nutzen für:

- besonders große Absolutwerte, die aber trotzdem eine große Genauigkeit haben sollen
- besonders langsam verändernde Werte
- hat etwa 15 Stellen Genauigkeit - wiederum Vorkomma + Nachkomma zusammen.

Anekdote am Rande: Die Splitterwelten hatten mal das Problem, dass sich die Gesundheit gar nicht mehr regeneriert hat, wenn man vom Splitterrand in den leeren Himmel geschaut hatte und VSync aus war. Der Gesundheits-Wert war ein float und wurde jedes Frame ein bisschen erhöht. In diesem Fall einer besonders hohen Framerate waren das dann so viele winzige Teilschritte, dass die Genauigkeit eines floats nicht mehr ausreichte.

Ich hoffe, das hilft.


* alle Bitbreiten gelten für die gängigen Desktop-Systeme: Windows, Linux, Mac, und müssten auch Bestand für Konsolen (XBox, PS, Wii) sowie für aktuelle Mobilgeräte haben. Laut C-Standard sind diese Angaben aber nicht garantiert, exotische Systeme können davon abweichen.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

BlueCobold

Community-Fossil

Beiträge: 10 859

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

67

11.06.2012, 16:30

Weil das gerade in etwa zum Thema passt: https://community.rapid7.com/community/m…y-flaw-in-mysql

memcmp gibt einen int zurück. Manche Leute sind aber schlauer als die Doku und nehmen einen char zum Speichern des Rückgabewerts, weil sie gelesen haben, dass die Rückgabewerte immer -128 bis 127 sind.
(...)
Nunja, falls das in diesem Thread nicht eh schon klar sein sollte: "Gefühlte Optimierungen" wie die Nutzung eines kleineren Datentypen für alltägliche Aufgaben sind nicht nur kontraproduktiv, sondern potentiell auch gefährlich.

Einen Rückgabewert zu beschneiden ist natürlich potentiell gefährlich. Das hat aber an sich nichts mit der Wahl eines Datentyps an sich zu tun, sondern mit der Konvertierung.

Zu Deiner Anekdote: Aus diesem Grund halte ich inkrementelle Verfahren ebenfalls für potentiell gefährlich. Sie sind numerisch nicht stabil. Wenn sie sich vermeiden lassen, sollte man es tun - aber ja, das bedarf eventuell mehr Aufwand.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Schrompf

Alter Hase

Beiträge: 1 415

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

68

11.06.2012, 17:12

Einen Rückgabewert zu beschneiden ist natürlich potentiell gefährlich. Das hat aber an sich nichts mit der Wahl eines Datentyps an sich zu tun, sondern mit der Konvertierung.

Das stimmt, aber ich empfand die Geschichte im Ganzen als exemplarisch für die Diskussion in diesem Thread. Der MySQL-Bug begründete sich ja darin, dass eigentlich ein int zurückgegeben wird, aber ein Programmierer mit "Kontextwissen" der Meinung war, dass da für immer und ewig ein char ausreicht. Und das noch dazu an einer Stelle, die wahrscheinlich schon damals keine solche "Optimierung" nötig hatte... immerhin reden wir hier von der Authentifizierung, die bestenfalls einmalig bei Erstellen der Verbindung passiert.

Zitat

Zu Deiner Anekdote: Aus diesem Grund halte ich inkrementelle Verfahren ebenfalls für potentiell gefährlich. Sie sind numerisch nicht stabil. Wenn sie sich vermeiden lassen, sollte man es tun - aber ja, das bedarf eventuell mehr Aufwand.

Wir rechnen inzwischen nur noch halbsekündlich - da muss man dann halt den Zeitpunkt des nächsten Auftretens mitspeichern, aber dafür ist die Rechnung stabil und unabhängig von der Bildrate. Aber ich halte es nicht für "gefährlich" im gleichen Sinne wie die anderen "gefährlichen" Punkte, die ich hier im Thread genannt habe. Das Schlimmste, was hier passieren kann, ist dass nach einer Weile der tatsächliche Gesundheitswert vom erwarteten Gesundheitswert abweicht. Das ist doch eine subtil andere Gefahr als ein Absturz oder Variablen-Überlauf mit potentiell unbegrenzten Logik-Folgefehlern.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

BlueCobold

Community-Fossil

Beiträge: 10 859

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

69

11.06.2012, 19:37

Solange es nicht dazu führt, dass jemand mit 0 HP unsterblich rumläuft, ist das kein Problem ;) (Dieses Problem hatten bisher übrigens sowohl Lineage 2, als auch WoW und Diablo 3 :D) Halb-sekündlich klingt übrigens sehr vernünftig.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

S4My

unregistriert

70

11.06.2012, 22:09

@Schrompf, Wow, danke :D . Mehr kann ich nicht dazu sagen, sehr hilfreich und einfach, naja, unfassbar gut :thumbsup: .

Vielleicht noch eine Anmerkung zu der stdint.h: Es gibt sehr viele dieser Bibliotheken welche mit .h enden. Diese wurden größtenteils zumindest noch in C compiliert. Ob das nun wirklich stimmt, dass kann ich an dieser Stelle leider nicht bestätigen, ich verlasse mich einfach mal auf das von mir Gelesene. Nun ist es doch so, Code welcher in C compiliert wird muss nicht auf die selbe Weise wie mit einem C++ Compiler compiliert werden. Deshalb gibt es mittlerweile Bibliotheken welche den selben Inhalt haben, jedoch so angefertigt sind, dass es keine Probleme geben sollte in Bezug auf die Art der Compilierung, sofern wirklich welche vorhanden waren. Diese besitzen den selben Namen, lediglich ohne die Endung und mit einem "c" davor, ungefähr so: stdint.h -> cstdint. Aber wie gesagt, lediglich gelesen und sonst sind bei mir auch noch keine Probleme aufgetreten bei der Verwendung von "älteren" Bibliotheken. Erwähnt wollte ich es trotzdem haben.

Mlg
S4My

Werbeanzeige