Wie schätzen Entwickler Hardwareanforderungen ab?

[McMoneysack91]

Liebe Freunde,

ich habe mich immer gefragt, wie Entwickler/Programmierer die hardwareanforderungen ihres in Zukunft fertiggestellten Projektes abschätzen. Oder ob sie es überhaupt tun. Insbesondere betrifft es Spiele, denn hier ist ja der Fantasie keine Frenze gesetzt.

Nehmen wir ein kleines deutsches Team, Piranha Bytes im Jahre 2006. Bestehend aus etwa 15 Leuten in einer angemieteten Wohnung in Essen die zum Entwicklerstudio umfunktioniert wurde baut das Team Gothic 3.

Frage: Henne oder Ei zuerst?

Szenario 1:
Björn Pankraz als Leiter geht zu seinen Mannen und sagt: "Leute, wir müssen Gothic 3 so hinbekommen, dass es rund 1024MB RAM verbraucht, eine nVIDIA GeForce 750 ausreicht und ein Intel Core 2 Duo das Ding zieht."

Daraufhin der 3D-Designer so: "Oh okay, dann muss ich hier etwas Gashalme wegmachen, hier in den Blättern die Schatten wegnehmen, da die Sunrays entfernen. Okay, dürfte jetzt hinhauen."

Der World-Builder daraufhin: "Ah ganze 1024MB RAM darfs benutzen? Cool, dann kann ich ja hier noch alles vollpacken, ein Bissl da ein Bissl dort."

etc...

ODER

Szenario 2:

Die Entwickler "machen einfach erstmal" und hoffen, dass es am Ende nicht Hardware der nächsten Jahrzehnte braucht, um zu laufen.


ODER

Szenario 3:

Die Entwickler wissen anhand der Tools, die sie verwenden bereits im Vorfeld Pi mal Daumen, wie die Hardwareanforderungen am Ende sein werden. Sprich:

"Um das Spiel für die breite Masse mit Standard-Hardware heutiger Zeiten zugänglich zu machen, verwenden wir Physics Engine X, Shader Y, die und die Frameworks und peilen etwa 300.000 Zeilen Code in C+ an. Das alles in allem sollte x MB RAM, x Grafikspeicher, x GHz CPU erfodern. WENNS denn am Ende etwas auszuufern droht, kann ja jeder in seinem Bereich schauen, wo er denn vielleicht etwas abspecken kann aber mit dem Set an Werkzeugen werden wir so ziemlich da landen wo angepeilt."

 

[andy_m4]

Man sollte vor allem im Blick haben was die Zielmaschine an Hardware hat. Es bringt ja nix gegen die hochgezüchtete Kisten zu programmieren wenn es dann am Ende beim Kunden in Zeitlupe läuft.

Ansonsten: Ja. Man hat als Entwickler Erfahrung. Und ja. Man wird wenn man sich nicht sicher ist tendenziell erst mal gucken, obs mit dem was man hat funktioniert und erst dann wenns eng wird neue Hardware besorgen (es sei denn es steht sowieso mal ein Hardwarewechsel an oder man weiß schon aus der Abschätzung das es knapp wird).

 

[madmax2010]

die und die Frameworks und peilen etwa 300.000 Zeilen Code in C+ an

darauf haben die wenigsten entwickler einfluss. das macht der compiler.
Man kann halt nur aktuell relevantes imRAM halten und gescheit pre-fetchen
sonst.. steht ja in den datenblaettern von grafikkarten wie viel speicher sie haben, wie viele Polygone pro sekunde machbar sind usw.. Anhand dessen werden dann halt die Anforderungen an die Entwicklung festgelegt
und naja.. die engines sind i.d.r skalierbar

 

[ghecko]

Schreiben - testen - anpassen.

 

[DaysShadow]

300.000 Zeilen Code in C++

Das ist für die Performance eines Programms zur Laufzeit, also beim Endkunden, erstmal ziemlich unerheblich, sondern hat eher Einfluss auf die Buildzeiten während der Entwicklung.

Ansonsten wird gegen das entwickelt was gerade an Hardware aktuell ist mit Blick auf das was in 2-3 Jahren, oder länger je nach Entwicklungszeit, womöglich an Rohleistung hinzugekommen ist. Was soll man auch sonst machen?

 

[BeBur]

Oder ob sie es überhaupt tun.

Im Gegenteil ist das (sicherlich) ein ausführlicher Prozess, der z.B. auch darin besteht, mit den einschlägigen Herstellern zu sprechen. Das ist auch in anderen Branchen so und auch nur logisch, dass Hardware-Hersteller mit den großen Anwendern im kontinuierlichen Dialog sind über aktuelle und vor allem auch zukünftige Kapazitäten und Features der Hardware. Für deine kleine damals unbekannte Beispielschmiede ist das natürlich nicht so, mit denen spricht nvidia selbstredend nicht.

Je kleiner die Schmiede, desto informeller wird das sicherlich laufen. Du weißt ja, was deine Engine leisten kann und was die aktuelle Hardware leisten kann. Und wie viel RAM du brauchst (sind schließlich deine eigenen Daten, die du da rein schaufelst).

Also klar, es wird so gebaut, dass das Produkt am Ende voraussichtlich innerhalb irgendwelcher Vorgaben läuft. Das klappt dann natürlich nicht und dann muss entschieden werden, wo am besten reduziert wird.

Speziell bis in die späten 90er und sicherlich auch Anfang 00 hat man aber soweit ich vernommen habe durchaus "drauf los" programmiert. Siehe z.B. Myst, das nur so gerade eben und unter großem Aufwand überhaupt lauffähig war auf aktueller Hardware (CD-ROM Laufwerke).

 

[nosti]

Allein die Frage finde ich schon toll. Bei uns in der Uni hatten wir in der Grundlagenprogrammierung immer die „Annahme“: Ressource sind unbegrenzt vorhanden….

Für mich als Infrastruktur Admin war das immer grauenhaft anzuhören. Leider entwickeln auch einige Programmierer weiterhin nach dieser Annahme.

Es beginnt schon damit wie Schleifen gebaut werden, wie oft müssen Daten eingelesen oder verarbeitet werden. Welche Datentypen sind wann sinnvoll.
Wenn Daten aus Datenbanken kommen, sollten diese entsprechend gescheit strukturiert sein, sonst wartet man ewig.

Da spricht man noch lange nicht von grafischen Oberflächen oder Effekten. Wenn sich dein Programm die benötigten Daten immer erst aus allen möglichen Quellen zusammensuchen muss, wird es eben nicht wirklich performen können.

Guter Code ist so lang wie nötig, aber gleichzeitig so kurz wie möglich um es verständlich und übersichtlich zu halten.

Richtig interessant wird das bei der Echtzeitverarbeitung von z.B. zeitkritischen Messdaten. sowas wird nicht ohne Grund in Hardwarenahen Sprachen gelöst.

Grüße

 

[DaysShadow]

@nosti Das was du beschreibst ist für mich der Unterschied zwischen einem "Codemonkey", im negativen Sinne, und einem richtigen Programmierer oder Software Engineer, wie auch immer man sich nun betitelt. Der Codemonkey kommt in aller Regel auch ans Ziel, macht sich aber nicht zwingend genügend tiefer- und weitergehende Gedanken über das was er da fabriziert.

In der Uni werden bzgl. Informatik und Programmierung hauptsächlich Konzepte gelehrt und keine Programmierer ausgebildet, weshalb die Ressourcen auch an sich keine Rolle spielen sollen.

Aber ja, ich finde Programmierung mit limitierten Ressourcen auch sehr spannend. Ist herausfordernder

 

[Renegade334]

Allein die Frage finde ich schon toll. Bei uns in der Uni hatten wir in der Grundlagenprogrammierung immer die „Annahme“: Ressource sind unbegrenzt vorhanden….

Es ist aber anders auch schwierig zu planen.
Es gibt immer Flaschenhälse, aber bis das Projekt relativ vollständig ist, weiß man noch nicht in welche Richtung man optimieren muss.
Es gibt z.B. Algorithmen die weniger Rechenleistung brauchen, dafür aber mit Speicher Aasen. Es wäre nicht unbedingt sinnvoll während der ersten Phasen zu optimieren um dann später zu bemerken, dass man mit einem DualCore hinkommen würde, dafür aber 32GB Ram benötigt.

Als Programmierer sieht man meist nur seinen Teilbereich. Wenn die Teile zusammengeführt werden und auch mit mehr als Testdaten gefüttert werden sieht man, wo wirklich Leistung verbraten wird.

Natürlich hat man aber als Programmierer auch Erfahrungswerte. Für viele Probleme gibt es Standardalgorithmen und davon abzuweichen ist nur in Ausnahmefällen sinnvoll.

Bei fertigen Engines kann man auch Vergleichswerte nutzen. Da weiß man in etwa was für bestimmte Features an Leistung gebraucht wird, da die Entwickler der Engine das bereits ausführlich getestet haben.

 

[Axxid]

Ich wuerde vermuten, dass man bei modernen Spielen zunaechst von nahezu unbegrenzten Ressourcen ausgeht und diese dann nachtraeglich ueber Einstellungen reduziert um gestaffelte Anforderungen (Niedrig/Mittel/Hoch/uLtr4!!!) zu haben.
Die Zeiten, in denen man ein Spiel auf 1MB pressen oder die Sichtweite auf 5m reduzieren musste, sind doch vorbei.

 

[SamGecko]

Das Zauberwort lautet Skalierung. Man erinnere sich an Crysis, den Hardwarefresser schlechthin zu seiner Zeit. Man konnte das Ding auch auf halbwegs normalen Rechnern betreiben, wenn man genug Kram abgeschaltet hat und ggf. die Auflösung reduziert hat. Entwickelt wurde es aber definitiv für zukünftige Systeme.

 

[Piktogramm]

Wenn man auf PC als Plattform abzielt, sind die Rechner die zwei Jahre vor Release die (obere) Mittelklasse darstellen, das Ziel, auf dem das Programm/Spiel laufen sollten. Man weiß also mit Vorlauf, welche Features und welche Spezifikationen man unterstützen will/muss.

Bei der restlichen Entwicklung, man nutzt ja sowieso massiv Bibliotheken und APIs. Nutzt man diese, landet man ja mehr oder weniger sowieso in einem Rahmen, der "Stand der Technik" ist.

 

[BeBur]

Ich wuerde vermuten, dass man bei modernen Spielen zunaechst von nahezu unbegrenzten Ressourcen ausgeht und diese dann nachtraeglich ueber Einstellungen reduziert

Ich glaube das haut nicht hin. Z.B. haben Modelle (Figuren, Bäume etc.) in Spielen eine relativ sehr geringe (ja, geringe) Auflösung, relativ zu dem was eigentlich machbar wäre. Sprich ein paar hundert/tausend/zehntausend Eckpunkte. Das ganze wird dann durch kluges ausnutzen der GPU Kapazitäten (Shader) so verwurstet, dass es gut aussieht.
Ich denke also schon, dass man ungefähr schaut in welcher Größenordnung man sichtbare Dinge haben will am Ende. Kann aber natürlich sein, dass man auch nachträglich automatisiert so gut runterskalieren kann, dass man erst mit hochauflösenden Modellen startet.

 

[Raijin]

Insbesondere betrifft es Spiele, denn hier ist ja der Fantasie keine Frenze gesetzt.

Prinzipiell schon, aber es ist nun mal so, dass in der Regel gängige 3D-Engines und Frameworks verwendet werden, die bereits in anderen Titeln eingesetzt wurden - mit entsprechenden Erfahrungswerten. Das ist grundsätzlich schon mal eine gute Ausgangsbasis für eine Abschätzung. Natürlich hängt es auch davon ab wie weit die Entwickler die Möglichkeiten ausreizen und die Engine an ihre Grenzen bringen, aber man hat ja auch schon die eine oder andere News gelesen, in der es hieß, dass das Studio die offiziellen Hardwareanforderungen angepasst hat.

Hinzu kommt, dass es hinter den Kulissen natürlich auch zahlreiche Tests gibt. Die Open/Closed Betas sind ganz am Ende der Kette, kurz vor Release. In der Zwischenzeit kannst du dir aber sicher sein, dass das unfertige Spiel schon auf zahlreichen Systemen getestet wurde, um eben den Stand der Performance realistisch einschätzen zu können. Insbesondere dadurch, dass PC-Spiele ja auch verschiedensten Konfigurationen laufen müssen, ist es schon vor den Betas zwingend nötig, die Funktion und die Performance mit den relevanten Komponenten zu testen, allen voran natürlich Intel vs AMD CPU sowie Nvidia vs AMD GPU. Wäre sonst ein ziemlicher Reinfall, wenn das Studio ihr Spiel zB nur auf Systemen mit Nvidia entwickelt und bei der Beta fällt plötzlich auf, dass es mit einer GPU von AMD gar nicht erst startet............

Abseits der Entwicklung von Spielen bzw. explizit GPU-Performance unterstützt natürlich auch die Entwicklungsumgebung bei der Einschätzung der Anforderungen. Da gibt es Analyse-Tools, die zB den RAM-Bedarf messen, CPU-Auslastung und dergleichen.

Nichtsdestotrotz würde ich behaupten, dass für den Großteil der Anwendungen heutzutage die Performance tatsächlich eine weniger wichtige Rolle spielt als früher. Selbst Einsteiger-CPUs haben heutzutage mehrere Kerne mit vielen GHz und dadurch Leistungsreserven wie man sie noch aus Single- oder maximal Dual-Core Zeiten nicht kannte. Für 08/15 Anwendungen werden Software-Entwickler daher auch tendenziell weniger auf die Performance achten, wenn es nicht gerade um kritische Programmteile geht.

 

[RalphS]

Es gibt immer irgendeinen Zielkorridor, je größer das Projekt wird. Das fällt genauso in die Marktanalyse wie alles andere auch.

Ganz genauso gibt es aber auch immer wieder (dieselben?) Ausnahmen wie zB MS Flight Simulator, wo dann gesagt wurde: wenn es neuere Hardware gibt, dann kann das Ganze weiter skalieren.

Aber schauen wir mal ins Kleinere.

1. Toolset.
Wir entwickeln mit Visual Studio und finden die Plattformunabhängigkeit der aktuellen Net Core faszinierend, weil Windows und Linux und selbe Codebasis und so. Ergo, der "client" (hier: stellvertretend für die Zielmaschine wo meine Anwendung laufen soll) muß die Anforderungen für net6 erfüllen.
Oder wir nutzen irgendeine 1st oder 3rdparty Library, weil die den Aufwand für uns signifikant drückt und/oder weil es da turboflinken Assemblercode gibt. Dazu brauchen wir AVX. Nicht alle CPUs können AVX. Also haben wir offensichtlich eine Mindestanforderung.

2. Parallelisierungsgrad.
Wir haben unsere Köpfe heißlaufen lassen wie wir unseren Kram möglichst performant abbilden können, ohne den Entwicklungsaufwand ad absurdum zu führen. Es gibt nicht viel, aber es gibt ein paar Momente, wo ein weiterer Thread vorteilhaft ist. Andererseits werden nie mehr als 12 Threads gleichzeitig ausgeführt - das gibt die Architektur der Anwendung einfach nicht her. Also testen wir den Kram auf handelsüblichen CPUs - cf Marktanalyse -- und erhalten eine Performancekurve in Abhängigkeit der verfügbaren Threads auf dem Client.
Und sehen, singlecore CPU geht, aber ist kreuzlahm. Dualcore hat signifikantes Plus. Also fordern wir mindestens zwei Kerne ein.
Am anderen Ende der Kurve haben wir aber nur noch logarithmischen Anstieg und zwischen 8 bis 12 Threads gibts kaum noch irgendwas zu sehen.
Also setzen wir 8 als Empfohlen und, wenn wir das wollen, 12 als "Enthusiast". Würde unsere Anwendung mit Kernzahl skalieren, würden wir "k Threads pro Anforderungseinheit" angeben. Oder in Kombination: Jeder weitere parallele Stream erfordert zwei Threads und 1GB RAM.

RAM ist immer so eine Sache, die wird gerne mal als gottgegeben angesehen. Ist RAM aber natürlich nicht. Insbesondere hier hat man dann seinen Zielkorridor für die Anwendung: ich sage vorher, 8 bis 16GB darf meine Anwendung brauchen und dann muß ich sehen, daß ich das erfülle.
Oder wie vorstehend, je nach Anwendung darf ich auch einfordern: jeder Benutzer mehr kostet X Einheiten an RAM. Ein Mailserver mit 10'000 Mailboxen benötigt nun mal mehr Ressourcen als einer mit nur zweien.

Grafik halt hauptsächlich für Spiele. Da sind der Phantasie natürlich nicht mal im ANSATZ Grenzen gesetzt, hier geht es um ganz andere Dinge als "die Freude am Spielen". Hier wird ganz klar abgesteckt, was es wo zu holen gibt und daran haben sich auch die Grafikanforderungen zu orientieren. Natürlich wurde und wird das durch den Übergang auf 2160p alles ziemlich durcheinandergewürfelt- aber ultimativ, wenn mein Spiel auf der Masse der verfügbaren Hardware nicht zufriedenstellend läuft, dann verdiene ich kein Geld damit. Fertig.

Irrelevant ist inzwischen Audio. Das ist pauschal überall vorhanden und sowas wie AWE oder die bloße Anzahl verfügbarer Stimmen interessiert dieser Tage kein Schwein mehr.

Für die Benutzerschnittstelle schließlich gilt dasselbe. Das ist einfach Marktanalyse. Wenn ich weiß, 90% der Mausschubser liefern nur 10% des Umsatzes, dann ignoriere ich die und verlange Joypads/Sticks/Lenkrad/was auch immer.


Kurz, nur ein vergleichsweise kleiner Teil sind wirklich harte Anforderungen, die einfach erfüllt werden müssen, weil es sonst nicht funktionieren würde. Der weitaus überwiegendere Teil ist wirtschaftliches Kalkül.

 

[LencoX2]

Das ist vorrangig bei komplexen 3D Grafiklastigen Games ein Thema.
Bei der Entwicklung geht man von einer bestimmten Ziel Grafik HW aus. Diese lässt sich vor allem durch die Polygonzahl leistungsmäßig einordnen. Die Level und Modelldesigner bekommen also ein bestimmtes Polygonbudget das gleichzeitig maximal sichtbar sein darf.
Dazu kommen dann weitere Kenngrößen wie Texturgrößen, 3D Features usw.

Dazu kommt dann auch noch viele Test und Anpassung Iterationen auf Ziel HW.

 

[McMoneysack91]

Also zusammengefasst Erfahrungswissen analysieren, dadurch eine Pi-Mal-Daumen Richtung angeben und dann on the fly sukzessive justieren, wenn das Projekt droht hier oder da über die Stränge zu schlagen.

Klingt ziemlich menschlich^^

 

[Raijin]

Und testen, testen, testen, testen, testen, testen, testen und .. .. testen.

 

[fgordon]

Letztendlich geht das doch eh nur per dynamischer Anpassung vor allem der Engine, was die dann nutzen kann weil in HW möglich - SW Implementierung wird aber wohl meist vorhanden sein - nur halt nicht wirllich sinnvoll nutzbar.

Auch Spielentwicklung geht doch oft über meist ein paar Jahre

Wer dann z.B 2 Jahre vor RTX angefangen hat und man da ja noch nicht wirklich sicher wusste dass Raytracing im Consumer Markt kommt und dann 1-2 Jahre nach RTX Start ein Game ohne diese Option bringt, ist halt wohl eher nicht der Grafikkracher sondern dann max. gutes Mittelfeld.

Und was die 50x0 oder gar 60x0 von z.B. Nvidia so genau bringt weiss doch auch fast niemand heute - ausser evtl die grossen Dev Studios. Müsste man aber doch fast wissen, wenn man ein Spiel in ein paar Jahren rausbringt das dann Super Grafik haben soll.

 

[BeBur]

Müsste man aber doch fast wissen wenn man ein Spiel in 3-4 Jahren rausbringt das Super Grafik haben soll.

Bringen denn kleinere Unternehmen überhaupt Grafikkracher raus? Ich habe gedacht, dass ist sowieso den großen vorbehalten.

Und die großen sprechen halt miteinander. Nvidia selber entwickelt auch nicht ins Vakuum hinein, sondern holt sich ganz sicher auch Input von ihren großen "Konsumenten" (also in dem Fall Spieleherstellern und Engineherstellern). Das ist ja auch kein Zufall, wenn ein Game mit nvidia gpu ganz besonders gut läuft oder das neuste feature XY verwendet und damit dann noch toller aussieht. Das ist dann natürlich so geplant gewesen und es würde mich Null wundern, wenn es spezielle SDKs gibt, welche APIs noch nicht erschienener GPUs beinhalten. Also z.B. unveröffentlichte CUDA Betaversionen die eben an ausgewählte Partner herausgegeben werden, damit ihr Spiel in 3 Jahren dann die Technologien nutzen kann der Grafikkarte, die in 2 Jahren erscheint aber als Prototyp womöglich schon in 1 Jahr an den Spielehersteller ausgegeben wird.