Konzeptfrage: dynamischer Speicher
-
Wie fordert der string gleich nochmal intern seinen Speicher an? Oha, dynamisch...
-
Ja und? Was hab ich als Programmierer damit zutun? Ich habe schliesslich auf tfa's Beitrag geantwortet. Dem es rein um den Aufwand für den Programmierer ging: "ohne GC viel mehr Tipparbeit und mehr nachdenken, wenn ich Scopeobjekte habe"... was aber falsch ist. Egal was der String intern macht.
Und falls es um Performance geht: wie kann ein GC generell schneller sein als ein new/delete? Notfalls nimm ich SmartHeap dazu. was aber auch beweist, das ein Heap-Management nur "schlau" implementiert sein muß. Völlig unabhängig ob ich einen GC nehme oder eine Library wie SmartHeap. Ein GC ist schliesslich keine Zauberei, oder doch? Und weiterhin: auch ei GC kann schlecht implemntiert und designed sein. Wer garantiert mir, wenn ich einen GC nehme, das ich auch Perfomancevorteile bekomme? Rein Zufällig mögen die GC von MS gut sein, aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern. Auch wenn ich das Weltbild einiger SUN-Fans damit zerstöre...
Artchi
PS: Mist, ich habe jetzt Java mit ins Spiel gebracht. Das wird mir jetzt zum Verhängnis!
-
Ein GC ist schon nett, da man beim selbst Managen schnell Fehler einhandeln kann. Wobei man zu den Geschwindigkeitsvorteilen die Optimizer aufgezählt hat aber sagen muss, dass dies oft nur die Frage des Allokators/Deallokators ist. Man kann ja auch einen Allokator/Deallokator schreiben, der wie ein moderner GC funktioniert. Der Deallokator sagt einfach nur "der Speicher hier ist zwar noch reserviert aber eigentlich frei" und der Allokator durchsucht diese Liste bevor er neuen Speicher anlegt (oder so ähnlich).
groovemaster schrieb:
Ihr seht schon, es ist also eine Art in die Sprache integrierter auto_ptr.
wozu sollte man auto_ptr in die Sprache integrieren, wenn man es genauso gut als Template-Klasse schreiben kann, wie es bisher ist?
-
wozu sollte man auto_ptr in die Sprache integrieren, wenn man es genauso gut als Template-Klasse schreiben kann, wie es bisher ist?
Das Argument vieler ist halt, das alles Buildin sein muß. Egal ob es Sinn macht oder nicht. Genau das werden wir aber in Zukunft in C++ weniger sehen, laut C++ Komitee. Mehr über Libraries und Templates, in die C++-Core nur noch das nötigste.
-
Artchi schrieb:
auch ei GC kann schlecht implemntiert und designed sein. Wer garantiert mir, wenn ich einen GC nehme, das ich auch Perfomancevorteile bekomme? Rein Zufällig mögen die GC von MS gut sein, aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern. Auch wenn ich das Weltbild einiger SUN-Fans damit zerstöre...
Einen schlechten GC kann man ja leicht ersetzen (also leicht im Sinne von ich nehme einen besseren GC und packe den dazu und entferne den schlechten, nicht leicht im Sinne von ich schreib mir mal eben einen guten GC ;)). Die manuelle Verwaltung zu ändern dürfte deutlich schwieriger sein
-
Ja, worum geht es denn nun? Um die Manuelle Verwaltung vs. Automatische Verwaltung? Oder um Performance?
Wenn es um Performance geht (GC soll schneller sein), sage ich, dann kann ich einfach die Standardlibrary durch eine bessere tauschen (z.B. die SmartHeap nutzt). Hab ich also auch einen Austausch vorgenommen. Muß ich zwar neu kompilieren, interessiert aber den Endanwender nicht, welche Lib ich nutze. Hauptsache das Ding rennt.
Wenn es um den Programmierer geht: spielt das "Austauschen können" des GCs keine Rolle. Entweder ich nimm einen GC oder nicht. Beides kann ich heute machen. Ich kann es manuell machen, ich kann Smartpointer nehmen, oder ich nehme einen GC. Und ab 2009 haben wir eh offiziell einen GC im ISO-C++. Die Diskussion werden wir ab dann hoffentlich hier nicht mehr haben.
-
rüdiger schrieb:
Wobei man zu den Geschwindigkeitsvorteilen die Optimizer aufgezählt hat aber sagen muss, dass dies oft nur die Frage des Allokators/Deallokators ist. Man kann ja auch einen Allokator/Deallokator schreiben, der wie ein moderner GC funktioniert. Der Deallokator sagt einfach nur "der Speicher hier ist zwar noch reserviert aber eigentlich frei" und der Allokator durchsucht diese Liste bevor er neuen Speicher anlegt (oder so ähnlich).
Hmmm. Ein Grundproblem bleibt aber auch mit eigenen Allokatoren bestehen: Du machst jede Freigabe explizit. Der Allokator kann das natürlich ansammeln und dann größere Bereiche auf einmal freigeben, aber *irgendetwas* machst du immer beim Deallokieren. Ein gescheiter GC dagegen deallokiert nicht.
Artchi schrieb:
Und falls es um Performance geht: wie kann ein GC generell schneller sein als ein new/delete?
IEs ist in der Praxis wirklich oft so (ich sag jetzt mal absichtlich nicht "meistens"). Das hat viele Gründe, new muss freien Speicher suchen, delete muss ausgeführt werden (ein guter GC macht kein delete), Speicher kann fragmentieren und schlechte Lokalität haben, es gibt hunderte Gründe, warum ein GC schneller oder langsamer ist. Du wirst natürlich trotzdem immer was konstruieren können, wo eine klassische Heap-Verwaltung geiler ist. In der Praxis ist er aber oft schneller. Ein eigener Allokator kann wieder noch besser sein, aber darauf hast du doch auch eher selten Lust.
aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern
Der ist wirklich grottig, hat Pause-Times im Zehntelsekunden-Bereich, da schaudert's mich echt. Die, die am meisten rumlabern, bauen echt den schlechtesten.
-
Artchi schrieb:
Und ab 2009 haben wir eh offiziell einen GC im ISO-C++. Die Diskussion werden wir ab dann hoffentlich hier nicht mehr haben.
Was glaubst du, wie die dann erst losgeht.
"soll ich ihn verwenden oder nicht?"
-
GCs sind doch im Prinzip schneller, weil sie Arbeit verschieben können und weil sie leicht den Heap aufräumen können. Aber das ist auch mit anderen Allokatoren möglich.
@Optimizer
dieses irgend was ist aber vermutlich nicht der Rede wert. Wenn doch, dann kann man bei der manuellen Verwaltung die Freigabe ja einfach auf einen günstigeren Zeitpunkt verlegen. (So wie man den meisten GCs ja auch sagen kann "Nerv getz nich!" ;))Artchi schrieb:
Ja, worum geht es denn nun? Um die Manuelle Verwaltung vs. Automatische Verwaltung? Oder um Performance?
Wenn es um Performance geht (GC soll schneller sein), sage ich, dann kann ich einfach die Standardlibrary durch eine bessere tauschen (z.B. die SmartHeap nutzt). Hab ich also auch einen Austausch vorgenommen. Muß ich zwar neu kompilieren, interessiert aber den Endanwender nicht, welche Lib ich nutze. Hauptsache das Ding rennt.
Bei manueller Verwaltung kannst du natürlich die Allokatoren austauschen, aber du kannst nicht einfach die interne Verwaltung umstricken. Das wollte ich eigentlich sagen. Man kann ja teilweise die GCs sogar vor dem starten einer Anwendung wählen.
-
rüdiger schrieb:
Wenn doch, dann kann man bei der manuellen Verwaltung die Freigabe ja einfach auf einen günstigeren Zeitpunkt verlegen.
Dann ist dieses Vormerken dieses etwas und spätestens das kannste nicht verlegen. Wie ich sagte, man kann die Deallokationen ansammeln und wird sicherlich auch gemacht. Am Ende steht man aber immer 2 Nachteilen da:
- man muss beim delete *irgendwas* machen
- man muss freie Speicherbereiche wieder zusammenfassen
Man hat viel rumgeforscht an manueller Speicherverwaltung, schon länger als an GCs und da gibt es alle möglichen Tricks. <Troll>Deshalb ist sie überhaupt noch gerade so konkurrenzfähig. </Troll>Der GC hat natürlich auch Arbeit die manuelle Speicherverwaltung nicht hat, zum Beispiel Referenzen ändern und Write-Barriers implementieren. Scheint aber durchaus sehr tragbar zu sein. Vor allem aber kann ich beim GC nahezu beliebig mehr Laufzeit einsparen und dafür mehr Speicher verbrauchen, also eintauschen, das ist schon sehr nett.
-
tfa schrieb:
rapso schrieb:
tfa schrieb:
Darüber hinaus kommt hinzu, dass moderne GC-Verfahren grade bei kurzlebigen Objekten (d.h. die nur in einem engen Scope existieren) besonders effektiv sind - Stichwort Generation Scavenging. Heutzutage gibt es wirklich keinen Grund mehr, vor Garbage-Collection angst zu haben.
nur wenn man es selbst schon richtig managed, dann ist ein GC nur ueberfluessig.
Managt man es denn richtig?
Die meisten scheinen dazu unfaehig zu sein. Leuten die soeinen anschein machen empfehle ich auch aus voller ueberzeugung auf Java/C#/VB zu setzen.
Es ist doch grade der Vorteil, dass man mit GC sehr viel weniger selber managen muss.
alles hat seinen preis, lange ladezeiten, suboptimale leistung, massig speicherverschwendung, einmal laenger nachdenken oder immer diese kosten in kauf nehmen... aber vielen faellt das garnicht mehr auf, leider.
Die eingesparte Zeit kann man prima nutzen, um Software zu entwicklen, statt sich tagelangen Debug-Sessions hinzugeben um Speicherlecks zu finden.
wenn man kontrolle abgibt, hat man weniger ahnung was passiert und dadurch kommen erst die langen debugsessions. es waere unsinnig zu glauben, dass nur weil ein objekt "garbage" ist statt deletet zu werden, dass man sich nicht um sein ableben kuemmern muss, denn resourcenfreigabe usw. muss dann immer noch gemacht werden, was viele programmierer von sprachen mit GC absolut nicht drauf haben ala "das liegt am GC, mein program hat kein Leak, das kann garnicht sein, das passiert nur in C++."
Die Performance-Einbußen durch GC sind meiner Meinung nach auch zu vernachlässigen.
ich finde den imensen speicheranstieg von manchmal 10fach gegenueber dem vorher existierendem tool in anderen sprachen nicht vernachlaessigbar. die manchmal langen ladezeiten bei denen man sich wundert, ob das OS den doppelklick realisiert hat und die starke traegheit der anwendungen sehr uebel.
Die Steigerung der Entwickler-Performance allerdings ganz und gar nicht.
die entwicklungsgeschwindigkeit ist nicht trvial zu messen. jemand der mit C# anfaengt ist zu anfang sicherlich viel schneller als jemand der in assembler schreibt, aber sobald man seine sprache beherrscht ist die entwicklungsgeschwindigkeit von jedem individuell und nicht sonderlich von der highlevel-sprache abhaengig, vor allem wenn man sein Hirn oefter trainiert und nicht auf vorgefertigtes setzt, kann mann bessere leistung bringen... ist wie mit dem kopfrechnen.
-
Optimizer schrieb:
rüdiger schrieb:
Wenn doch, dann kann man bei der manuellen Verwaltung die Freigabe ja einfach auf einen günstigeren Zeitpunkt verlegen.
Dann ist dieses Vormerken dieses etwas und spätestens das kannste nicht verlegen. Wie ich sagte, man kann die Deallokationen ansammeln und wird sicherlich auch gemacht. Am Ende steht man aber immer 2 Nachteilen da:
- man muss beim delete *irgendwas* machen
- man muss freie Speicherbereiche wieder zusammenfassen
Man hat viel rumgeforscht an manueller Speicherverwaltung, schon länger als an GCs und da gibt es alle möglichen Tricks. <Troll>Deshalb ist sie überhaupt noch gerade so konkurrenzfähig. </Troll>Aber der GC kann auch irgend wann seine Runde fahren und dann kostet es mich mehr als das bisschen was ein delete macht <gegentroll>und bei den meisten Sprachen die einen GC haben dürfte fast jede Operation teurer sein, als das delete meines vorgeschlagenen Allokators in C++ :p </gegentroll>
-
rüdiger schrieb:
Aber der GC kann auch irgend wann seine Runde fahren und dann kostet es mich mehr als das bisschen was ein delete macht
Das ist exakt das, was wir noch rausfinden müssen. Da ich Speicherbedarf gegen Laufzeit eintauschen kann, verlierst du auf jeden Fall schon mal, wenn es Hart auf Hart kommt. Für nen vernünftigen Speicherverbrauch hilft jetzt wohl nur, wenn jeder an seines glaubt (ich messe zum Beispiel 0.3 % der Laufzeit im GC, bietest du weniger in new/delete) oder wir battlen uns jetzt mit nicht-repräsentativen Benchmarks.
-
Bei manueller Verwaltung kannst du natürlich die Allokatoren austauschen, aber du kannst nicht einfach die interne Verwaltung umstricken.
Was meinst du damit genau? Das die Objekte nicht hin und her geschoben werden können, ist klar. Aber auch dieser Vorgang müsste eigentlich in dem Moment Performance kosten?
Ansonst hier ein paar Infos zum SmartHeap-Design (bei dem man übrigens seinen Code nicht nachtäglich ändern muß):
http://www.microquill.com/smartheap/sh_tspec.htm#2.2
-
@rapso: Dieser Epic Games chief irgendwas blubb hat ja übrigens anscheinend mal einen interessanten Vortrag darüber gehalten, wie er sich eine Programmiersprache für Spieleentwickler vorstellt und den kennst du doch bestimmt. Er hat u.a. bemängelt dass heutige Programmiersprachen ein unvernünftiges Exception-Modell ("exception everywhere, everytime") haben und nicht hinreichend für Nebenläufigkeit ausgelegt sind. Du kennst doch diesen Vortrag bestimmt, was hältst du als Spieleentwickler eigentlich von seinen Aussagen? Gut, dass du "Garbage collection should be the only option" nicht gut findest, vermute ich jetzt einfach mal.
Da waren noch mehr Punkte, aber ich bin grad in der Arbeit und hab die Präsentation nicht da.
-
Optimizer schrieb:
Hmmm. Ein Grundproblem bleibt aber auch mit eigenen Allokatoren bestehen: Du machst jede Freigabe explizit.
auch ein GC muss irgendwann die trennung zwischen garbage und nicht garbage machen, das macht ein memorymanager den man selber schreibt gleich und fuer den fall optimiert, der GC macht das generisch, irgendwann und kann nicht die geschwindigkeit eines spezialisierten memorymanagers uebertreffen, denn auch ein GC hat eine memorymanager strategie, nur ist es selten die optimale die sich ein programmiere auswaehlen wuerde.
Ein gescheiter GC dagegen deallokiert nicht.
ja, wie du sagtest, er kopiert z.b. alle genutzten objekte um, also nicht nur dass er dabei jedesmal das speicherlayout aendert und somit das programm radom ist von der laufzeiteigenschaft, man zahlt die vermeitlich kuerzere allokationszeit (wenn man keinen guten allokator in c++ hat) gegen massige speicherkopiererei (natuerlich macht das ein GC nicht am stueck sondern zieht kontinuirlich zeit im hintergrund).
IEs ist in der Praxis wirklich oft so (ich sag jetzt mal absichtlich nicht "meistens"). Das hat viele Gründe, new muss freien Speicher suchen, delete muss ausgeführt werden (ein guter GC macht kein delete), Speicher kann fragmentieren und schlechte Lokalität haben, es gibt hunderte Gründe, warum ein GC schneller oder langsamer ist. Du wirst natürlich trotzdem immer was konstruieren können, wo eine klassische Heap-Verwaltung geiler ist. In der Praxis ist er aber oft schneller. Ein eigener Allokator kann wieder noch besser sein, aber darauf hast du doch auch eher selten Lust.
ein GC ist schneller weil man zum vergleich immer nur die allokations und deallokationszeit nimmt, dass dafuer imens zeit fuer die verwaltung im hintergrund draufgeht, ganz zu schweigen vom manchmal doppelten speicherverbrauch wird fleissig uebergangen. ganz logisch mal verglichen:
in c++ geht ein allokator inkrementel sein budget an speicher durch und vergibt es, wenn es erreicht ist, dann wird bei jeder allokation in der freelist geschaut was der beste speicherbereich ist denn er zurueckgibt.
mit nem GC wird ebenfalls bis zum budget speicher vergeben, ist das budget erreich wird der ganze speicher zusammenkopiert, entweder in einen paralellen speicherblock (also massig memorymoves) oder der GC geht den speicher durch und versucht die luecken die da sind (dafuer muss er aufwendig evaluieren ob es ueberhaupt ne luecke ist) mit allokierten bereichen fuellen (die er ebenfalls erstmal finden muss). da ist aus meiner sicht garkeine ersparnis.aber die SUN Java-GC ist z.B. schlechter als der von anderen Java-Implementierern
Der ist wirklich grottig, hat Pause-Times im Zehntelsekunden-Bereich, da schaudert's mich echt. Die, die am meisten rumlabern, bauen echt den schlechtesten.
bei jeder version von der JVM hat sun wieder nen komplett neuen und supergeilen GC der alles vorhergewesene topt
leider sind GCs die besser sind als die speichermanager die man sonst verwendet nur marketingblub. der einzige wirkliche vorteil ist, dass man leute mit weniger plan vom coden dransetzen darf ohne angst haben zu muessen, dass sie etwas unbenutzbares erstellen. dieser sicherheitsaspekt ist aus meiner sicht ein echtes/klares Plus.
-
Optimizer schrieb:
rüdiger schrieb:
Aber der GC kann auch irgend wann seine Runde fahren und dann kostet es mich mehr als das bisschen was ein delete macht
Das ist exakt das, was wir noch rausfinden müssen. Da ich Speicherbedarf gegen Laufzeit eintauschen kann, verlierst du auf jeden Fall schon mal, wenn es Hart auf Hart kommt. Für nen vernünftigen Speicherverbrauch hilft jetzt wohl nur, wenn jeder an seines glaubt (ich messe zum Beispiel 0.3 % der Laufzeit im GC, bietest du weniger in new/delete) oder wir battlen uns jetzt mit nicht-repräsentativen Benchmarks.
Ähhh (vorab: Ich habe nichts gegen GCs - sobald es sinnvoller ist, einen einzusetzen, tue ich das ohne Probleme) ... ein delete teilt "der Speicherverwaltung" (sei es ein GC oder etwas anderes) mit, dass dieser Speicher nicht mehr gebraucht wird.
Ohne diese "aktive Information" ist der GC darauf angewiesen, es selbst herauszufinden .... wo das per se schneller sein soll (oder durch ein mehr an Speicher ausgleichbar), ist mir schleierhaft.
Natürlich kann man direkt im delete auch die Speicherfreigabe machen, aber das wollte rüdiger mit seinem Allokator ja gerade nicht....EDIT: Hat rapso schon besser erklärt.
Gruß,
Simon2.
-
rapso schrieb:
ein GC ist schneller weil man zum vergleich immer nur die allokations und deallokationszeit nimmt, dass dafuer imens zeit fuer die verwaltung im hintergrund draufgeht, ganz zu schweigen vom manchmal doppelten speicherverbrauch wird fleissig uebergangen.
Ich muß sagen, da hast du einen ganz wichtigen Punkt angesprochen, der mir ehrlich gesagt nie richtig bewusst war. Natürlich wusste ich das das Aufräumen nur zeitlich verschoben wird, aber das es dadurch "geschönt" wird, wenn man es nicht mit in die Messung einbezieht, war mir nie bewusst. "aufgeschoben ist nicht aufgehoben" oder wie geht das Sprichwort?
-
rapso schrieb:
ja, wie du sagtest, er kopiert z.b. alle genutzten objekte um, also nicht nur dass er dabei jedesmal das speicherlayout aendert und somit das programm radom ist von der laufzeiteigenschaft, man zahlt die vermeitlich kuerzere allokationszeit (wenn man keinen guten allokator in c++ hat) gegen massige speicherkopiererei (natuerlich macht das ein GC nicht am stueck sondern zieht kontinuirlich zeit im hintergrund).
Ich denke aber schon, dass man da auch berücksichtigen muss, dass ein GC eben *nicht* mit allen Objekten etwas macht. Deshalb belegt er ja auch so viel Speicher. Er lässt 10,000 Objekte allokieren, wenn er die Collection dann macht, schiebt er nur die 100 noch lebenden rüber und mit den anderen 9900 hat er nichts gemacht. Da kannst du auch beim Deallokator noch eine ganze Menge rumtricksen, aber in jedem Fall hast du 9900 mal delete aufgerufen und *irgendwas* dabei gemacht.
denn auch ein GC hat eine memorymanager strategie, nur ist es selten die optimale die sich ein programmiere auswaehlen wuerde.
Das ist etwas, dem ich nicht wiedersprechen würde. Man nimmt sich ein "typisches" Allokationsprofil her und optimiert den GC darauf. Aber bei new und delete ist es auch nichts anderes. Wenn du nicht immensen Aufwand betreibst, deine eigenes Allokationsprofil zu bestimmen, immer up-to-date zu halten und deine Speicherverwaltung darauf anpasst, sondern wenn du standard new und delete verwendest, ist es doch vorstellbar, dass ein Standard-GC besser sein kann als das standard new und delete.
Artchi schrieb:
rapso schrieb:
ein GC ist schneller weil man zum vergleich immer nur die allokations und deallokationszeit nimmt, dass dafuer imens zeit fuer die verwaltung im hintergrund draufgeht, ganz zu schweigen vom manchmal doppelten speicherverbrauch wird fleissig uebergangen.
Ich muß sagen, da hast du einen ganz wichtigen Punkt angesprochen, der mir ehrlich gesagt nie richtig bewusst war. Natürlich wusste ich das das Aufräumen nur zeitlich verschoben wird, aber das es dadurch "geschönt" wird, wenn man es nicht mit in die Messung einbezieht, war mir nie bewusst. "was aufgeschoben ist, ist nicht aufgehoben" oder wie geht das Sprichwort?[/quote]Angesprochen aber nicht ausgeführt? Was genau bezieht man in die Messung nicht ein? Das mit dem erhöhten Speicherverbrauch ist ja kein Geheimnis - wie gesagt, man kann Speicher gegen Laufzeit tauschen und macht man auch gern.
-
Optimizer schrieb:
@rapso: Dieser Epic Games chief irgendwas blubb hat ja übrigens anscheinend mal einen interessanten Vortrag darüber gehalten, wie er sich eine Programmiersprache für Spieleentwickler vorstellt und den kennst du doch bestimmt. Er hat u.a. bemängelt dass heutige Programmiersprachen ein unvernünftiges Exception-Modell ("exception everywhere, everytime") haben und nicht hinreichend für Nebenläufigkeit ausgelegt sind. Du kennst doch diesen Vortrag bestimmt, was hältst du als Spieleentwickler eigentlich von seinen Aussagen? Gut, dass du "Garbage collection should be the only option" nicht gut findest, vermute ich jetzt einfach mal.
Da waren noch mehr Punkte, aber ich bin grad in der Arbeit und hab die Präsentation nicht da.
ja, hab mit tim mal drueber gesprochen gehabt vor ewigkeiten, die sichtweise ist halt, dass es immer mehr auf staffelungen beim programmieren gibt. auch die unreal engine bietet dazu ja extra na scriptsprache. ich kann jetzt nicht 100%ig sagen, dass es auch seine aussage ist (wie gesagt, ist schon etwas her, auch seit ich sein paper las), aber grundlegend sollte es so sein:
- unterste eben ist der Core, auch die UE3 hat einen ganz grundlegenden Core, dieser ist sowas wie ne standard lib, je nachdem sind teile in assembler, in c, in c++ oder sogar stark templatisiert geschrieben (also schon fast funktional). gecodet wird das von wirklich faehigen leuten, ich glaube bei Epic hat Tim das meiste davon gemacht, aber es gibt wohl noch ein paar die das supporten (3leute glaube ich)
- darauf setzt die engine, keine stl, boost, etc. nur mittels des cores als sprachen-lib wird entwickelt, dabei baut man auch ne VM mit jeglicher speicherverwaltung usw. das wird dann von den normalen (immer noch sehr skillten) programmierern gemacht
- darauf setzt bei epic dann der c++ gamecode auf, der leider, gerade bei externen, viel zerschiessen kann und jeder engine programmierer kennt das leid, wenn es einen absturz gibt heisst es "ist im .. modul der engine abgestuerzt, das muss R&D fixen" und dann verschwendet man zeit um rauszufinden wo die 'anwender' den fehler machten.
hier kommt nun im optimalen fall fuer spieleprogrammierer die sprache mit aller moeglichen sicherheit zum einsatz. das spart massig debuggen, weil viele dummheiten aufgrund von sprachrestriktionen erst garnicht moeglich sind.
-oberster layer ist nun die scriptsprache, sie liegt noch eins drueber und erlaubt es zur laufzeit zu coden und zur codezeit instant zu sehen was passiert.(- ok, noch ein layer drueber, hier kommt die visuelle graph-sprache die es erlaubt ohne geringste code erfahrung logik zu erstellen, perfekt fuer artists, gamedesigner usw. wenn es auch nur fuers prototyping benutzt werden wuerde).
jeder dieser layer hat seine vollste existenzberechtigung, es ist nur das image das diese sprachen so durchkreuzt. es gibt sicherlich javascript scripter die meinen dass sie ne ganze engine in JS machen koennen, gibt ja auch doom-clones die im browser laufen.
es gibt leute die meinen sie koennen alles mit C#, VB, Java. Es gibt das natuerlich auch fuer C++ oder assembler. nur ist diese fixierung total unnuetz und suboptimal. um einen weisen mann zu zittieren "the right tool for the right job"