Wie schätzen Entwickler Hardwareanforderungen ab?

DaysShadow schrieb:
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.
Ist jetzt etwas zu Pauschal.

Klar ich hatte auch so ne Vorlesung (Softwareengineering) bei der man sich an den Kopf gefasst hat und mit dem Dogma rangegangen wurde, aber zumindest bei uns war das eher die Ausnahme.

In Algorithmen und Datenstrukturen ging es rein um die Komplexität, wobei der Prof DEUTLICH darauf hingewiesen hat das es Vorfaktoren gibt, die teils entscheidend sein können. Wir hatten das sogar mal explizit an einem Beispiel durchgesprochen auf Grundlage einer Abschätzung aus der Vorlesung. Fand ich stark, weil es von der reinen Lehre stark abgewichen ist.

Technische Informatik. Da haben wir ne 16 Bit CPU designt mit Blick darauf wie viele Gatter man braucht und wie schnell das Design taktet.

GPU Computing. Performance war da essenziell

Parallele Rechnerarchitektur: Performance war da schon sehr wichtig.

Paralleles Hochstleistungsrechnen: da war Performance extrem wichtig. Wir haben uns da in der Übungsgruppe immer richtig gebattelt. Da wurde alles in den Ring geworfen was man hatte. Compiler, Algorithmen, Parallele Programmierung sogar Assembler wurde da aus dem Hut gezaubert um zu gewinnen... wir waren da aber glaub auch wirklich ein außergewöhnlicher Jahrgang. Der Tutor war zumindest immer ganz erstaunt über unsere Lösungen. Von 7 oder 8 Gruppen waren 3 eigentlich immer deutlich schneller als die Musterlösung. Im Jahrgang danach gab es viele neue Musterlösungen ;D

DaysShadow schrieb:
Aber ja, ich finde Programmierung mit limitierten Ressourcen auch sehr spannend. Ist herausfordernder :D
Ja, aber man kann da echt endlos Zeit drin versenken. Ich hatte bei GPU Computing mal in nen Sortieralgorithmus ca zwei Wochen Arbeit gesteckt. Danach war das Ding aber auch um Faktoren schneller als die Musterlösung. Der Prof hatte mir auch nicht geglaubt, dass das überhaupt so schnell geht. War damals von der Idee sehr beeindruckt, weil er den Trick nicht gesehen hatte, damit es so schnell wird. War aber auch ein bisschen ein böser Hack, weil ich implizit die Funktionsweise der HW ausgenutzt habe, die CUDA damals so nicht hergegeben hat rein nach dem Sprachstandard.

McMoneysack91 schrieb:
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^^
Ja, das trifft es ganz gut. Gute von schlechten Entwicklern unterscheidet dann halt die Fähigkeit direkt von Anfang an zum Beispiel Algorithmen zu nehmen die das Problem effizient lösen.

Dafür brauch man aber schon ein Gefühl, aber auch vernünftige Abschätzungen und dann Stift und Papier.

Aber um ehrlich zu sein, das machen nur wenige Entwickler, geschweige denn in ihrer täglichen Arbeit. Meist hat man ja auch gar nicht die Zeit dafür und die Probleme sind auch meist so klein das es heutzutage einfach auch egal ist. Die Systeme sind schnell genug. Ob der Nutzer 0.1 oder 0.001 Sekunden warten muss ist egal.

Ich selbst muss aber immer wieder aufpassen und Dinge optimieren oder halt gleich von Anfang an richtig machen, weil man sieht, das etwas eben algorithmisch nicht skaliert. Dafür muss man aber seine Input Daten kennen und auch einen Blick dafür haben.

Ein Kollege von mir hat den eher nicht, daher passiert es immer wieder das Dinge plötzlich Minuten laufen oder eben Systeme in die Knie zwingen. Dafür kann er aber andere Dinge deutlich besser als ich.

Am Ende ergänzen sich mehrere Entwickler halt um ein gutes Produkt zu erstellen.
 
  • Gefällt mir
Reaktionen: Raijin und Testa2014
Zurück
Oben