1. Foren
  2. Kommentare
  3. Games
  4. Alle Kommentare zum Artikel
  5. › The Witcher 3: Hinter den Kulissen der…

"Wir kompilieren fast täglich neu"

  1. Thema

Neues Thema Ansicht wechseln


  1. "Wir kompilieren fast täglich neu"

    Autor: der_wahre_hannes 27.01.15 - 14:51

    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.

  2. Re: "Wir kompilieren fast täglich neu"

    Autor: m00hk00h 27.01.15 - 14:57

    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".

  3. Re: "Wir kompilieren fast täglich neu"

    Autor: Psy2063 27.01.15 - 14:59

    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.

  4. Re: "Wir kompilieren fast täglich neu"

    Autor: aPollO2k 27.01.15 - 15:01

    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.

  5. Re: "Wir kompilieren fast täglich neu"

    Autor: tunnelblick 27.01.15 - 15:13

    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".

  6. Re: "Wir kompilieren fast täglich neu"

    Autor: smurfy 27.01.15 - 15:20

    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.

  7. Re: "Wir kompilieren fast täglich neu"

    Autor: waswiewo 27.01.15 - 15:34

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

  8. Re: "Wir kompilieren fast täglich neu"

    Autor: PiranhA 27.01.15 - 16:02

    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).

  9. Re: "Wir kompilieren fast täglich neu"

    Autor: PiranhA 27.01.15 - 16:07

    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.

  10. Re: "Wir kompilieren fast täglich neu"

    Autor: picaschaf 27.01.15 - 16:40

    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.

  11. Re: "Wir kompilieren fast täglich neu"

    Autor: Trockenobst 27.01.15 - 16:46

    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.

  12. Re: "Wir kompilieren fast täglich neu"

    Autor: PiranhA 27.01.15 - 18:25

    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).

  13. Re: "Wir kompilieren fast täglich neu"

    Autor: elgooG 28.01.15 - 11:04

    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.

  14. Re: "Wir kompilieren fast täglich neu"

    Autor: bofhl 28.01.15 - 11:29

    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.

  15. Re: "Wir kompilieren fast täglich neu"

    Autor: PiranhA 28.01.15 - 12:14

    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 ;)

  16. Re: "Wir kompilieren fast täglich neu"

    Autor: elgooG 28.01.15 - 15:38

    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

  17. Re: "Wir kompilieren fast täglich neu"

    Autor: PiranhA 28.01.15 - 16:04

    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.

  18. Re: "Wir kompilieren fast täglich neu"

    Autor: gadi 02.02.15 - 12:37

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

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. über Dr. Maier & Partner GmbH Executive Search, Stuttgart
  2. Stadtwerke München GmbH, München
  3. websedit AG, Ravensburg
  4. Bechtle Onsite Services GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. (reduzierte Überstände, Restposten & Co.)
  2. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


Sendmail: Software aus der digitalen Steinzeit
Sendmail
Software aus der digitalen Steinzeit

Ein nichtöffentliches CVS-Repository, FTP-Downloads, defekte Links, Diskussionen übers Usenet: Der Mailserver Sendmail zeigt alle Anzeichen eines problematischen und in der Vergangenheit stehengebliebenen Softwareprojekts.
Eine Analyse von Hanno Böck

  1. Überwachung Tutanota musste E-Mails vor der Verschlüsselung ausleiten
  2. Buffer Overflow Exim-Sicherheitslücke beim Verarbeiten von TLS-Namen
  3. Sicherheitslücke Buffer Overflow in Dovecot-Mailserver

Elektroschrott: Kauft keine kleinen Konsolen!
Elektroschrott
Kauft keine kleinen Konsolen!

Ich bin ein Fan von Retro. Und ein Fan von Games. Und ich habe den kleinen Plastikschachteln mit ihrer schlechten Umweltbilanz wirklich eine Chance gegeben. Aber es hilft alles nichts.
Ein IMHO von Martin Wolf

  1. IMHO Porsche prescht beim Preis übers Ziel hinaus
  2. Gaming Konsolenkrieg statt Spielestreaming

Weltraumsimulation: Die Star-Citizen-Euphorie ist ansteckend
Weltraumsimulation
Die Star-Citizen-Euphorie ist ansteckend

Jubelnde Massen, ehrliche Entwickler und ein 30 Kilogramm schweres Modell des Javelin-Zerstörers: Die Citizencon 2949 hat gezeigt, wie sehr die Community ihr Star Citizen liebt. Auf der anderen Seite reden Entwickler Klartext, statt Marketing-Floskeln zum Besten zu geben. Das steckt an.
Ein IMHO von Oliver Nickel

  1. Theatres of War angespielt Star Citizen wird zu Battlefield mit Raumschiffen
  2. Star Citizen Mit der Carrack ins neue Sonnensystem
  3. Star Citizen Squadron 42 wird noch einmal verschoben

  1. Datendiebstahl: Facebook warnt eigene Mitarbeiter erst nach zwei Wochen
    Datendiebstahl
    Facebook warnt eigene Mitarbeiter erst nach zwei Wochen

    Nach dem Diebstahl von Festplatten mit unverschlüsselten Gehaltsabrechnungen und persönlichen Daten hat sich Facebook laut einem Medienbericht offenbar sehr viel Zeit gelassen, die betroffenen Mitarbeiter zu informieren.

  2. Ultimate Rivals: Apple Arcade eröffnet Sportspielreihe mit Hockey
    Ultimate Rivals
    Apple Arcade eröffnet Sportspielreihe mit Hockey

    Eishockeylegende Wayne Gretzky gegen Fußball-Weltmeisterin Alex Morgan oder andere Sportstars: Das ist die Idee hinter einer neuen Sportspielserie auf Apple Arcade. Nach dem Hockey-Auftakt namens The Rink geht es im Frühjahr mit Basketball weiter.

  3. T-Mobile: John Legere warnt US-Richter vor Scheitern von Fusion
    T-Mobile
    John Legere warnt US-Richter vor Scheitern von Fusion

    Mehrere US-Bundesstaaten kämpfen gegen die Fusion von Sprint mit T-Mobile in den USA. Dessen Chef John Legere hat sich jetzt bei der Gerichtsverhandlung zu dem Thema geäußert - aber die Aktionäre verlieren offenbar die Geduld.


  1. 14:08

  2. 13:22

  3. 12:39

  4. 12:09

  5. 18:10

  6. 16:56

  7. 15:32

  8. 14:52