"Wir kompilieren fast täglich neu"

[der_wahre_hannes]

Ja... und? So ist das nunmal, wenn man was neues entwickelt. Man kompiliert und debuggt ständig. Ich kann in dieser Aussage das Besondere nicht entdecken.

[m00hk00h]

Kam bei mir nicht so an, als sollte es etwas Besonderes sein...schlicht eine kurze zusätzliche Erläuterung in der Story um die "drei magischen Bildschirme".

[Psy2063]

der_wahre_hannes schrieb:
--------------------------------------------------------------------------------
> Ja... und? So ist das nunmal, wenn man was neues entwickelt. Man kompiliert
> und debuggt ständig. Ich kann in dieser Aussage das Besondere nicht
> entdecken.

es wird bei Projekten im zweistelligen Gigabytebereich eigentlich nicht täglich im ganzen neu kompiliert, weil das kompilieren und ausrollen auf die Rechner der Qualitätssicherung gerne mal mehrere Stunden dauern kann.

da hat eher jeder Programmierer bzw jedes Team sein eigenen Codebereich und wenn ein neuer meilenstein bzw ein wichtiger schritt im debugging fertig ist dann merged man das alles wieder zusammen.

[aPollO2k]

So ein rießen Projekt zu kompilieren dauert ewig bzw. erfordert sehr starke Hardware. Da macht geht man meist etwas strukturierter vor. Man kann nicht kurz mal was ändern, compilen und gucken ob es funktioniert. Bis eine gemachte Änderung getestet werden kann dauert es oft Stunden bis Tage.

Darum macht man oft einen Schnitt an dem man sagt jetzt haben alle wichtige Änderungen vorgenommen jetzt wird Compiler. Anders wäre das ja auch garnicht mehr managebar.

[tunnelblick]

man wollte nur zeigen, dass es cdp so macht. das heisst nicht, dass andere es nicht genau so machen oder andere firmen für ihre programme ebenso. nicht jeder hat eine vorstellung davon, wie spieleentwicklung "geht".

[smurfy]

Psy2063 schrieb:
--------------------------------------------------------------------------------
> es wird bei Projekten im zweistelligen Gigabytebereich eigentlich nicht
> täglich im ganzen neu kompiliert, weil das kompilieren und ausrollen auf
> die Rechner der Qualitätssicherung gerne mal mehrere Stunden dauern kann.

Den größten Platzbedarf bei einem Spiel dürfte wohl der Inhalt (Grafiken, Musik, Videos, etc.) haben, und nicht das Programm anversich. Und dieser Inhalt wird ja auch höchstens gepackt und nicht kompiliert. Ich halte es für sehr unwahrscheinlich dass The Witcher 3, also das eigentliche Programm welches kompiliert werden muss, auch nur annähernd in den zweistelligen Gigabytebereich kommt.



1 mal bearbeitet, zuletzt am 27.01.15 15:25 durch smurfy.

[waswiewo]

Der reine Programmcode der meisten Spiele beträgt ein paar Megabyte. Grafiken, Videos, Sounds, Animationen etc. werden natürlich nicht kompiliert.

[PiranhA]

Wenn man Debug-Symbole mitrechnet, aber auf jeden Fall. Eines der größeren Projekte bei uns an der Arbeit sind nach der Installation knapp über 500 MB. Für das Kompilieren werden aber über 25 GB benötigt. Wenn man dann sowohl 32bit als auch 64bit testen möchte, kommt man fast auf 50 GB.
Hier wären das ja mindestens drei Zielplattformen (ich vermute mal, dass es auf dem PC nur noch 64bit gibt).

[PiranhA]

Die Engine wird mehr als ein paar MB sein. Die ganzen Skripte und Shader ebenso. Am schlimmsten sind aber die ganzen Debug Symbole und Object Files. Das ganze dann multipliziert mit der Anzahl der Plattformen. Da werden locker einige GB zusammen kommen. Wenn man das auf einem normalen Rechner bauen möchte, kann man sicherlich ein paar Stunden einplanen. Wenn man die Last auf alle Arbeitsrechner verteilt, wird es immer noch lange dauern. C++ kompilieren ist im Vergleich zu C#/Java schnarch langsam.

[picaschaf]

Wir haben gute Erfahrungen gemacht mit Buildsystemen die Amazon EC2 integrieren. Ein commit Hook spawnt eine neue RAM optimierte EC2 Instanz die das Projekt auscheckt, baut, die Ergebnisse in S3 ablegt und eine Benachrichtigung mit Uusammenfassung per SMS oder E-Mail schickt. Damit bauen selbst Projekte mit > 4 Mio. LOC bereinigt in rund 10 Minuten. Kosten pro Build rund 60cent, gesparte Kosten durch Zeitersparnis gut 1.500 EUR.

[Trockenobst]

PiranhA schrieb:
--------------------------------------------------------------------------------
> locker einige GB zusammen kommen. Wenn man das auf einem normalen Rechner
> bauen möchte, kann man sicherlich ein paar Stunden einplanen. Wenn man die
> Last auf alle Arbeitsrechner verteilt, wird es immer noch lange dauern. C++
> kompilieren ist im Vergleich zu C#/Java schnarch langsam.

Man kann da **viel** machen. Parallelisierung ist z.B. eine Möglichkeit
C++ Freunde nutzen etwa https://code.google.com/p/distcc
Für VisualStudio gibt es das Kommerzielle incredibuild.com

Rechenpower ist gegenüber Menschenpower **rotzbillig**. Wenn man statt 4h nur 25minuten Build hat, weil xx Maschinen ständig pumpen hilft das immens beim Turnaround.

Bei Spielen ist es häufig so, dass die Grafiken und Objekte in einem virtuellen Dateisystem liegen. Die 3d-Objekte müssten gerne nachträglich vereinfacht werden. Das nennt sich "baking" und kann z.T. Tage dauern. Auch hier kann man durch intelligente Tools und Parallelisierung extrem Zeit sparen.

Viele große Game-Firmen release nur alle paar Tage, weil sie solche Systeme nicht im Einsatz haben und/oder die Ausgaben/Aufwand scheuen.

Gerade fürs automatische Testing kann man nicht genug "Bots" haben, die die Engine und das Game 24h am Tag bis zum Umfallen testen.

[PiranhA]

Wir nutzen auch IncrediBuild, was die Sache schonmal deutlich verbessert. Ich bräuchte allerdings mal so langsam einen neuen Rechner. Bei meinen Kollegen ist der Build in gut 25 Minuten durch, bei mir dauert das gerne doppelt so lange.
Dennoch sind das immer noch himmelweite Unterschiede zu C#/Java. Alleine schon weil der Compiler immer mal wieder auf den Linker wartet. Wir haben allerdings auch schon vieles in einzelne Projekte ausgelagert, die bereits fertig gebaut sind (C#) und nur noch durch den Linker müssen. Um die zu testen, muss man auch nicht laufend das Hauptprojekt bauen.
Den Build-Prozess in die Cloud auslagern, könnte ich mir bei meiner Firma auch nicht vorstellen. Da wird das eher noch alles intern aufgezogen (also nicht nur in der Abteilung, sondern im gesamten Intranet).

[elgooG]

Den Build-Prozess lagert man aber auch aus. Continuous integration sollte inzwischen schon bei allen Entwicklern angekommen sein und ist nun mal wichtig um möglichst frühzeitig Fehler zu erkennen.

Außerdem glaube ich nicht, dass ihr 25 GByte Debugging-Symbole tatsächlich auch braucht und noch dazu allesamt jedes einzelne mal neu erzeugen müsst. Wie wäre es denn Build-Prozess mal zu optimieren?

Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite



2 mal bearbeitet, zuletzt am 28.01.15 11:06 durch elgooG.

[bofhl]

Psy2063 schrieb:
--------------------------------------------------------------------------------
> der_wahre_hannes schrieb:
> ---------------------------------------------------------------------------
> -----
> > Ja... und? So ist das nunmal, wenn man was neues entwickelt. Man
> kompiliert
> > und debuggt ständig. Ich kann in dieser Aussage das Besondere nicht
> > entdecken.
>
> es wird bei Projekten im zweistelligen Gigabytebereich eigentlich nicht
> täglich im ganzen neu kompiliert, weil das kompilieren und ausrollen auf
> die Rechner der Qualitätssicherung gerne mal mehrere Stunden dauern kann.

Vergiss die Q-Sicherung - für Komplett-Tests werden bei allen Projekten je nach eingesetzter Rechnerkapazität durchaus täglich mindestens ein kompletter Build durchgeführt! (Bestes öffentlich bekanntes Beispiel: Eclipse!)
Und gehen diese Tests tatsächlich mal fehlerfrei durch - was eher selten passiert! - dann erst geht dieser Build (auch wenn er dann schon wieder veraltet sein mag) an die Qualitätskontrolle, die aus diesen Build für Updates entsprechende Patchdateien erstellt - oder auch nicht!

>
> da hat eher jeder Programmierer bzw jedes Team sein eigenen Codebereich und
> wenn ein neuer meilenstein bzw ein wichtiger schritt im debugging fertig
> ist dann merged man das alles wieder zusammen.
Das geschieht so wie so! Nur wird eben jeden Tag aus den daraus entstehenden Dateien ein Komplett-Projekt-Build erstellt um auch den korrekten Zusammenspiel aller Codeteile sicher zustellen.

[PiranhA]

elgooG schrieb:
--------------------------------------------------------------------------------
> Den Build-Prozess lagert man aber auch aus. Continuous integration sollte
> inzwischen schon bei allen Entwicklern angekommen sein und ist nun mal
> wichtig um möglichst frühzeitig Fehler zu erkennen.

Schön wärs. Wir machen vielleicht ein bis zwei mal die Woche einen kompletten Build. Erst da können die Änderungen verifiziert werden. Besonders interessant wird es, wenn sich die Entwickler untereinander abstimmen müssen, weil die eine Änderung nicht ohne die andere funktioniert und umgekehrt. Wenn man unterschiedliche Teilprojekte hat, welche auf 80 Entwickler verteilt sind, passt der aktuelle Stand häufiger nicht zusammen. Manche Komponenten kommen auch aus anderen Abteilungen, da ist die Kommunikation noch schwieriger.
Ich hab mal kurz geschaut, wie viele Assemblies da zusammen kommen. Aktuell habe ich hier 790 DLLs und knapp 60 EXE Dateien (ohne .net Assemblies, welche als Resourcen eingebettet wurden).

> Außerdem glaube ich nicht, dass ihr 25 GByte Debugging-Symbole tatsächlich
> auch braucht und noch dazu allesamt jedes einzelne mal neu erzeugen müsst.
> Wie wäre es denn Build-Prozess mal zu optimieren?

Naja, grundsätzlich braucht man von jeder Komponente die Debugging-Symbole. Wenn es irgendwo knallt, will ich das wissen. Auch wenn das gar nicht mein Aufgabengebiet oder Schuld ist. Und bei mir machen die Object Files für den 32bit Build schon mal 18 GB aus, ohne die Debugging-Symbole. Die kann man ja auch nicht weglassen.
Wenn man seine Änderungen testen möchte, reicht natürlich vor einmal zu bauen. Danach gehen inkrementelle Builds recht flott. Sobald aber größere Änderungen reingeflossen sind, geht ein kompletter Build deutlich schneller als ein inkrementeller (teilweise auch Schuld von IncrediBuild). Aber wenigstens einmal die Woche muss man schon einen kompletten Build machen.

Also perfekt ist es nicht gerade und ich würde das gerne modernisieren. Aber zum einen ist das nicht so einfach bei Projekten dieser Größe, welche schon seit 15 Jahren laufen. Zum anderen fehlt der Zwang etwas zu machen, weil es bisher noch funktioniert. Und nur um des Optimieren Willens steckt hier niemand Aufwand darein. Da muss schon konkreter Bedarf bestehen und da haben wir einfach andere Prioritäten. Da holt man doch lieber schnellere Rechner ;)

[elgooG]

Ok, aber ein Projektmanager müsste solche Problem erkennen und gegensteuern. Das ein Projekt bereits lange läuft ist in keinem Fall ein Argument. Ein verteiltes Build-System ist zudem sehr viel flexibler als nur immer stärkere und stärkere Hardware zur Verfügung zu stellen. So wie sich das anhört kompiliert ihr außerdem nochmal selber.

Ein gutes Continuous integration System wie Jetbrains TeamCity verteilt nicht nur die Last und verwendet brach liegende Ressourcen auf den Entwicklerrechnern, sondern erlaubt es auch zeitgesteuert Builds direkt aus der Versionsverwaltung zu machen. Schlägt ein täglicher Build einer Komponente oder die automatischen Tests fehl, kann man zum Testen immer noch auf ältere zugreifen. Wenn du einen eigenen Build brauchst, wird die Last außerdem auf alle Rechner verteilt und nicht nur auf deinen eigenen.

Was die Debugging-Symbole betrifft: Es werden sich doch nicht sämtliche Komponenten ständig ändern und neue Fehler produzieren, oder? Bereits hier kann man ansetzen die Generierung von neuen Debugging-Symbolen wegzulassen.
Gerade .NET hat damit keine Probleme und abgesehen von den Dateinamen und den Zeilennummern die sich bei einzelnen Methoden nicht auslesen lassen, gibt es kaum Informationsverlust.

Kann Spuren von persönlichen Meinungen, Sarkasmus und Erdnüssen enthalten. Ausdrucke nicht für den Verzehr geeignet. Ungelesen mindestens haltbar bis: siehe Rückseite

[PiranhA]

elgooG schrieb:
--------------------------------------------------------------------------------
> Ok, aber ein Projektmanager müsste solche Problem erkennen und
> gegensteuern. Das ein Projekt bereits lange läuft ist in keinem Fall ein
> Argument. Ein verteiltes Build-System ist zudem sehr viel flexibler als nur
> immer stärkere und stärkere Hardware zur Verfügung zu stellen. So wie sich
> das anhört kompiliert ihr außerdem nochmal selber.

Ein Projektmanager ist gut^^ Da sind etwa 8-10 Produktmanager und dutzende Projektleiter involviert. Es muss halt jeder Entwickler einmal selbst bauen, um seine Änderungen an der aktuellen Baseline zu testen. Ein mal die Woche wird dann vom Build-Server ein kompletter Build gemacht, aus dem dann die neue Baseline erzeugt wird. Wenn ein Entwickler sein Checkout aktualisieren will, wird eben die aktuelle Baseline als Zip extrahiert und mit aktuellen Builds aus anderen Quellen versorgt. Damit hat man schon den Großteil erschlagen. Die ganzen Nebenprojekte muss man dann nicht mehr bauen. Aber um die letzte Meile, das Hauptprojekt einmal durchzubauen, kommt man aktuell nicht herum.

> Wenn du einen eigenen Build brauchst, wird die
> Last außerdem auf alle Rechner verteilt und nicht nur auf deinen eigenen.

Dafür verwenden wir ja IncrediBuild. Das hat auch jeder Entwickler installiert. Sonst würde es ja Stunden dauern.

> Was die Debugging-Symbole betrifft: Es werden sich doch nicht sämtliche
> Komponenten ständig ändern und neue Fehler produzieren, oder? Bereits hier
> kann man ansetzen die Generierung von neuen Debugging-Symbolen
> wegzulassen.

Vom Build-Server wird immer alles gebaut. Auch wenn es gar keine Änderungen gab. Die Debug-Symbole braucht man immer. Der Fehler kann ja auch erst durch Randbedingungen auftreten, welche so vorher nicht existiert haben.

> Gerade .NET hat damit keine Probleme und abgesehen von den Dateinamen und
> den Zeilennummern die sich bei einzelnen Methoden nicht auslesen lassen,
> gibt es kaum Informationsverlust.

Wie gesagt ist der Großteil der Daten erstmal C++ Object Files und die gesamte Basis-Entwicklung auch C++ bzw. C++/CLI. C# wird bei dem Hauptprojekt eigentlich gar nicht mehr gebaut. Da werden die ganzen Dateien einfach aus den Nebenprojekten kopiert. Und spielt ja auch keine Rolle. Es hilft und schadet nicht.
Wäre es ein reines .net oder Java Projekt, wäre das sicherlich einfacher. Dazu wird es allerdings niemals kommen (Echtzeit-Anforderungen). Viele der Nebenprojekte sind zum größten Teil C#, da könnte man sowas machen. Allerdings sind da die Build-Zeiten ja sowieso kein Problem.

[gadi]

Sehr interessante Methode, ich schätze mal der Flaschenhals ist in dem Fall nur noch die Internetverbindung?