Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
kaiserludi hat geschrieben:1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.
Sind etwa 20 Jahre * ~200 Engineers ;)
Treiber fuer 5-6 unterstuetzte Generationen von Hardware, mehrere voellig unterschiedliche Karten pro Generation. Dazu die User Software. Laeppert sich.
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Jonathan hat geschrieben:Wie viele Tage braucht das so zum kompilieren?
Kann ich gar nicht so genau sagen. Wir nutzen sogenannte Wink-Ins: Kompilierte Object-Files, die zentral im Netz gelagert werden. Bei einem Compile werden die herangezogen, falls der Code nicht geaendert wurde.
Mit Winkins etwa 3-4h auf einer HP Z800 (16 Cores, 16-32GiB RAM, 10k oder 15k RPM Platten).
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Schon zum dritten Mal hat sich mein Bildschirm in Schlieren von Magenta aufgelöst. Wenn ich Pech habe, verabschiedet sich meine Grafikkarte demnächst nach nicht mal einem halben Jahr "Forschungsgebrauch".
CodingCat hat geschrieben:Wenn ich Pech habe, verabschiedet sich meine Grafikkarte demnächst nach nicht mal einem halben Jahr "Forschungsgebrauch".
Und wenn du Glück hast, sind seit dem Kauf noch keine 6 Monate vergangen und du kannst beim Händler auf Gewährleistung pochen, wobei der Händler die Beweislast tragen muss. Nach diesen 6 Monaten dreht sich die Beweislast um, und du hast es sehr viel schwerer. Also nicht die Graphikkarte im Backofen grillen, sondern auf Beseitigung des Mangels bestehen. ;)
Sobald man einen Zuweisungsoperator hinzufügt, hört eine C++-Klasse auf, POD zu sein.
Wäre ja an sich nicht schlimm, wenn da nicht ein winziges Detail wäre: Die Standardinitialisierung ändert sich von nullen zu undefiniert lassen. Und Visual C++ spuckt nirgends auch nur den Hauch einer Warnung aus, dass die Daten, die ich mühsam mit () initialisiert habe, jetzt voll Dreck sind. Wer hat sich diese scheiß Schikane bloß ausgedacht? Wenn ich es nicht initialisiere soll es ruhig undefiniert bleiben, in Ordnung. Aber wenn ich explizit eine Initialisierungsaufforderung hinschreibe?! WTF?
Das hat mich daran denken lassen, dass ich immernoch viel zu wenig Annahmen im Quelltext dokumentiere. Hätte
static_assert(type_traits<Foo>::is_pod, "Jedes Mal, wenn du eine Mikrooptimierung einbaust, pflanzt irgendwo auf der Welt ein besoffener MS-Programmierer einen Bug in den Optimizer!");
vor der betroffenen Stelle gefunden, hätte ich es sofort gemerkt.
Warum sind die meisten von Mobys Hits nun schon über zehn Jahre her? Ich komme mir so alt vor.
Habt ihr euch mal die Pläne alter Intel-CPUs angeschaut, z.B. des 4004er von 1969? Ich schätze, dass etwa um diese Zeit herum CPUs so kompliziert wurden, dass nur noch Autisten die Funktionsweise bis auf die Transistoren runter verstehen konnten. Mitte der 80er dann so, dass sie menschlich nicht mehr vollständig verstehbar wurden. Ich komme mir so jung vor.
kaiserludi hat geschrieben:1.5GiB, nicht 15, ist natürlich immer noch eine riesige Menge. Das müsste ja locker in der Größenordnung von 100 Millionen Zeilen Code sein.
Sind etwa 20 Jahre * ~200 Engineers ;)
Treiber fuer 5-6 unterstuetzte Generationen von Hardware, mehrere voellig unterschiedliche Karten pro Generation. Dazu die User Software. Laeppert sich.
Ist das dann in Brainfuck oder Malbolge geschrieben? :D Ne mal ehrlich da kann man ja quasi mehrere Betriebssysteme draus machen ... Aber ich kenne solche Riesenteile leider nur zu gut hier von Siemens ...
Die CUDA-OpenGL interop ist echt der letze Dreck...
cudaGraphicsGLRegisterBuffer(..) funktioniert bei 2 von vier Buffern einwandfrei bei den anderen beiden zerschiest es mir den Speicher und ich bekomm ein Race zwischen OGL und CUDA :(
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Jonathan hat geschrieben:Wie viele Tage braucht das so zum kompilieren?
Kann ich gar nicht so genau sagen. Wir nutzen sogenannte Wink-Ins: Kompilierte Object-Files, die zentral im Netz gelagert werden. Bei einem Compile werden die herangezogen, falls der Code nicht geaendert wurde.
Mit Winkins etwa 3-4h auf einer HP Z800 (16 Cores, 16-32GiB RAM, 10k oder 15k RPM Platten).
Ihr benutzt ClearCase? Das wäre in der Tat ein Grund zu jammern... Gerade die Winkins können einem bei einem recht großen Repo das Netzwerk zu dichtmachen.
kimmi hat geschrieben:hr benutzt ClearCase? Das wäre in der Tat ein Grund zu jammern... Gerade die Winkins können einem bei einem recht großen Repo das Netzwerk zu dichtmachen.
Ja, Clearcase. Das Netzwerk ist auch oft genug "langsam" oder faellt halt mal aus. Sehr lustig, wenn der Backup-Switch nicht anspringt und spontan 200 Leute nicht mehr arbeiten koennen bis HP Ersatz liefert :lol:
Code ist groesstenteils C mit etwas C++ und bischen Java.
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Würde mich mal interessieren, wie viel Duplicated Code bei solch einem riesigen Projekt existiert. Ich tippe, ohne je an solch einem Projekt gearbeitet zu haben, auf 15%. :D
j.klugmann hat geschrieben:Würde mich mal interessieren, wie viel Duplicated Code bei solch einem riesigen Projekt existiert. Ich tippe, ohne je an solch einem Projekt gearbeitet zu haben, auf 15%. :D
Ich kann sicherlich nicht fuer das ganze System sprechen, doch fuer die Teile, die ich kenne: Dort gibt es erstaunlich wenig duplizierten Code. Was es auch nicht gibt, es einheitliche Fehlerbehandlung (wahlweise ueber Exceptions, die einfach weggeworfen werden, einfache Ausgaben auf stdout/stderr bis hin zu zu asserts(), die in Release-Builds deaktiviert werden :roll: ). Oder ein Memory Management. Oder hilfreiche Fehlermeldungen. Oder ...
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Punkt 1 kann ich aus verschiedenen Multiplayer-Spielen (Mass Effect 3, Rage, ... ) definitiv bestaetigen :evil: Sobald es schwierig wird, quitten viele Leute. Oder wenn sich jemand mit Light Armor einem grossem Mech in den Weg stellt und stirbt, ist natuerlich das Spiel dran Schuld :roll:
Ein Hoch auf uns Männer... Auf die Frau, die uns HAT ( oder hat, und nicht weiß, dass sie uns hat ) ...auf die Idiotinnen ... besser gesagt VOLLPFOSTINNEN ... die uns hatten und uns verloren haben ... und auf die GLÜCKLICHEN, die das Vergnügen & Glück haben werden uns kennenzulernen!
Matthias Gubisch hat geschrieben:Die CUDA-OpenGL interop ist echt der letze Dreck...
cudaGraphicsGLRegisterBuffer(..) funktioniert bei 2 von vier Buffern einwandfrei bei den anderen beiden zerschiest es mir den Speicher und ich bekomm ein Race zwischen OGL und CUDA :(
Nähere Informationen? Ich habe mich gerade selbst 2 Wochen mit DX11/CUDA rumgeärgert. Was nicht zuverlässig ging: Interop mit StructuredBuffers, Interop mit sehr großen Puffern. Außerdem haut cudaGraphicsMapResource() gigantische Verzögerungen ins Programm, sobald allgemein der VRAM knapp wird.
Matthias Gubisch hat geschrieben:Die CUDA-OpenGL interop ist echt der letze Dreck...
cudaGraphicsGLRegisterBuffer(..) funktioniert bei 2 von vier Buffern einwandfrei bei den anderen beiden zerschiest es mir den Speicher und ich bekomm ein Race zwischen OGL und CUDA :(
Nähere Informationen? Ich habe mich gerade selbst 2 Wochen mit DX11/CUDA rumgeärgert. Was nicht zuverlässig ging: Interop mit StructuredBuffers, Interop mit sehr großen Puffern. Außerdem haut cudaGraphicsMapResource() gigantische Verzögerungen ins Programm, sobald allgemein der VRAM knapp wird.
Kommt demnächst in nem eigenen Thread
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
auto nicePointer = std::unique_ptr<char>(new char[123]);
Schön, oder?
Gratulation, wir haben gerade ein Speicherloch erzeugt. Genauer: Unter Visual C++ 2010 werden 122 chars nicht freigegeben, weil nur delete, aber nicht delete[] aufgerufen wird. unique_ptr wählt den auszuführenden Deleter (d.h. delete oder delete[]) anhand des Template-Parameters, und der ist nun einmal kein Array. Richtig lautet es:
eXile hat geschrieben:
Wenn man sich mit C++03 den Fuß abschießen kann, dann kann man sich wohl mit C++11 den halben Torso wegblasen. :roll:
Mal schauen, wie viele Standardversionen es noch dauert, bis bei Fehlern ganze Universen ausradiert werden :lol:
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da :)
"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
eXile hat geschrieben:Wenn man sich mit C++03 den Fuß abschießen kann, dann kann man sich wohl mit C++11 den halben Torso wegblasen. :roll:
Zum Glück bläst man sich nicht den Kopf weg, sonst würde man ja kopflos programmieren ;)
Da wäre dann wohl das Ausradieren des Universums die bessere Alternative. Man kann wenigsten keine Programmierfehler mehr machen. ;)
Ich komme mir grad blöd vor. Ich suchte ein regelmäßiges Muster, um ein 32x32-Feld zu beackern, so dass nicht immer benachbarte Pixel drankommen, am Ende aber trotzdem alle erwischt werden. Überschaubare Zahlenbereiche, also schnell mal in Code gegossen:
Und siehe da: es klappt für jede ungerade Zahl. Ich komme mir gerade ziemlich dumm vor, dass ich das nicht sofort gesehen habe. Grmpf.
[edit]Korrektur: noch einen Test für "doppelt erreicht" eingebaut und immernoch das selbe Ergebnis. Jetzt fühle ich mich richtig blöd. Eigentlich logisch... es klappt nicht für Schrittweiten, die durch Teiler der Größe teilbar sind.
Zuletzt geändert von Schrompf am 15.08.2012, 13:03, insgesamt 1-mal geändert.
Schrompf hat geschrieben:
[edit]Korrektur: noch einen Test für "doppelt erreicht" eingebaut und immernoch das selbe Ergebnis. Jetzt fühle ich mich richtig blöd. Eigentlich logisch... es klappt nicht für Schrittweiten, die durch Teiler der Größe teilbar sind.
Das kommt mir aus der Krypto Vorlesung sehr bekannt vor.