Wird sich Java jemals bei kommerz. Vollpreisspielen als Programmiersprache durchsetze [Archiv]

Gast

2008-12-21, 03:40:11

n?

Oder wird Java aufgrund der Performancekosten immer das nachsehen bei kommerziellen 3d Spielen haben?

Denn man muß folgende Gesichtspunkte ins Auge fassen:

Vorteile von Java:
- die Entwicklung ist günstiger und geht schneller als mit C++
- Java hat weniger Fallstrike als C++
- es läuft überall, auf der es eine Java Virtual Machine gibt, d.h. es ist plattformunabhängig auf Binärebene und ein Spiel hätte somit theoretisch den größten Marktanteil wenn es in Java geschrieben werden würde

Nachteile von Java:
- Spezialrecheneinheiten wie z.b. SSE3, SSE4 etc. können nicht oder nicht effizient genutzt werden
- für 3d Beschleunigung ist Java Abhängig von OpenGL, da es kein DirectX nutzen kann und letzteres auch die Vorteile der Plattformunabhängigkeit vernichten würde.

Und dann gibt es noch folgende Gesichtspunkte im Markt allgemein gesehen, die man ebenfalls bei dieser Frage berücksichtigen muß:

- Die Spieleentwicklung wird immer teurer, daher muß in der Entwicklung gespart werden und die Erschließung der größtmöglichen Kundenmasse hat Vorrang vor allem anderen um die Kosten zu senken. Mit Java wäre z.B. der Markt von Mac OS X und Linux auf einen Schlag erreichbar.
- die CPUs werden immer schneller und GPUs mit abstrahierenden APIs wie OpenGL und OpenGL immer wichtiger, Performancekosten einer Sprache mit einer Virtuellen Maschine fallen immer weniger ins Gewicht.
- die Grafik ist heute schon auf so einem hohen Niveau und jeder kleine Entwicklungsschritt unglaublich teuer, daß man damit rechnen kann,
das zukünftig die Story, das Gameplay, die Physik und KI mehr Gewichtung erhalten werden.

Und zum Schluß folgender Hinweis:
John Carmack hat in einem Interview ja mal gesagt, daß er sich durchaus vorstellen könnte, ein Spiel in Java zu programmieren.

Also, wie sieht es aus?
Wie seht ihr das?
Hat Java jemals, sagen wir in den nächsten 10 Jahre eine Chance im Spielesektor als Programmiersprache Fuß zu fassen und mit der Zeit deutliche Marktanteile von C/C++ abzuluchsen?

Gast

2008-12-21, 03:42:58

nein

btw... spielesektor ist total unwichtig ;)

Gast

2008-12-21, 03:48:34

btw... spielesektor ist total unwichtig ;)

Stimmt, ist ja auch nur ein Milliardenmarkt.

The_Invisible

2008-12-21, 08:35:02

Gast

2008-12-21, 09:41:27

die speicheranforderungen würden sehr steigen wie man ja schon an allerlei miniprogrammen in java sehen kann.

Das war bis jetzt der Hauptgrund warum man keine Spiele in Java entwickelt hat.
Bei 32 Bit Rechnern konnte man einfach nicht genug Speicher adressieren.
Aber dieser Punkt wird zunehmend unwichtiger werden,
da das Problem mit den 64 Bit Rechnern und Betriebssystemen erstmal vom Tisch ist.

Das war beim Umstieg von Assembler zu C/C++ oder für einige Programme von C/C++ zu Skriptsprachen auch nicht anders.
Der nächste Schritt ist also von C/C++ zu C#/Java

außerdem wäre in diesem fall C# sogar die bessere sprache, da man doch mehr freiheiten bekommen kann und moderner als java ist. problem ist aber das die sprache nicht wirklich plattformunabhängig ist.

Tja und dann kann man auch gleich bei C++ bleiben, wenn man den zusätzlichen Markt der anderen Plattformen nicht einfach mitnehmen kann.
C# ist in dieser Hinsicht ne Totgeburt.

Aber es gibt ja noch D das auch einen Garbage Collector hat, den man auch noch bei Bedarf abschalten kann, wenn man möchte. ;)

bzw wie meinst du plattformunabhängig auf binärebene? die vm wird schon auf die jeweilige zielplattform kompiliert, der java code wird ja nur in so ne art bytecode gehalten.

Im Endeffekt kommt es auf das gleiche hinaus.
Die Hardwaremaschine ist egal, solange die JVM vorhanden ist.

Tiamat

2008-12-21, 09:51:17

Naja es hat halt schon seinen Grund wieso sich die Spieleentwickler mit C(++) abquälen. Im Endeffekt geht es ja um die größtmöglichst zu erreichende Performance. Ich hab mal gelesen, dass man die Performance eines in C++ programmierten Spiels in der Form verbessern kann, indem man kritische Teile des Programms in ASM programmiert. Des heißt, dass es mit purem Einsatz von C++ auch nicht getan ist.
Was soll dann bitte schön Java sagen. Klar man kann die VM noch weiter optimieren, aber es wird immer ein gewisses Performance-Defizit gegenüber einer nativen Programmiersprache geben.

Dem Programmierer muss der Umgang mit Multithreading erleichtert werden, um mehr Performance über diesen Weg rauszuholen. Meiner Meinung nach ist der Scheduler in Java nicht so intuitiv einschätzbar, wie ich mir das manchmal wünschen würde ;D
Ich meine mal gelesen zu haben, dass sich da auch bei Java 7 einiges tun wird.

Vielleicht implementiert Sun in Zukunft auch eine Version, die sich zusätzliche Power durch die Rechenpower der GPU verschafft, könnt ich mir sogar vorstellen. Die java.3d Bibliothek wurde meines Wissens schon ne zeitlang nicht mehr aktualisiert.
Andere Programmiersprachen entwickeln sich aber auch weiter.

Also im Endeffekt, wer weiß ;D

Abraxus

2008-12-21, 09:58:09

ich würde allerdings die virtual machine auch als negativpunkt anführen. in manchen fällen ist die manuelle speicherverwaltung eben doch besser, der gc von java arbeitet auch nicht immer optimal, die speicheranforderungen würden sehr steigen wie man ja schon an allerlei miniprogrammen in java sehen kann. Der GC ist eher ein Vorteil gegenüber nicht GC Sprachen, gerade in Zeiten von Manycores würde ich auf einen GC nicht mehr verzichten wollen! (selbst unter C++ setze ich einen GC ein) Zumal die manuelle Speicherverwaltung ihre Tücken hat, im besonderen wenn mehrere Threads auf denselben Objekten arbeiten ist das Löschen nicht mehr ganz trivial, selbst mit Reference-Counting.

außerdem wäre in diesem fall C# sogar die bessere Sprache, da man doch mehr Freiheiten bekommen kann und moderner als Java ist. Problem ist aber das die Sprache nicht wirklich plattformunabhängig ist. C# ist bis einschließlich Version 2.0 auf vielen Plattformen verfügbar. Dabei währen auch die PS2, PS3 und XBOX360 zu nennen. Version 3.0 ist teilweise schon unter Mono verfügbar. Damit währen alle großen Platformen abgedeckt. Selbst Winforms und ASP.net sind schon umgesetzt worden. Was noch fehlt ist natürlich XNA (hier setzt TAO an) sowie WCF WPF und WWF. Letztere sind alles 3.5 Features.
Naja es hat halt schon seinen Grund wieso sich die Spieleentwickler mit C(++) abquälen. Im Endeffekt geht es ja um die größtmöglichst zu erreichende Performance. Ich hab mal gelesen, dass man die Performance eines in C++ programmierten Spiels in der Form verbessern kann, indem man kritische Teile des Programms in ASM programmiert. Kann man mit .net auch machen, ich bezweifel aber das es so viel bringt.
Dem Programmierer muss der Umgang mit Multithreading erleichtert werden, um mehr Performance über diesen Weg rauszuholen. Meiner Meinung nach ist der Scheduler in Java nicht so intuitiv einschätzbar, wie ich mir das manchmal wünschen würde ;D Kein Scheduler ist intutiv, für C++ gibt es TBB, das ist schon ganz vernünftig. Die 3.0er .Net Version hat schon länger einen Task-Scheduler eingebaut, und arbeitet damit wirklich sehr schnell, auf höchst einfachem Wege.

maximAL

2008-12-21, 10:57:22

- es läuft überall, auf der es eine Java Virtual Machine gibt, d.h. es ist plattformunabhängig auf Binärebene und ein Spiel hätte somit theoretisch den größten Marktanteil wenn es in Java geschrieben werden würde
es läuft nicht auf konsolen und alle anderen plattformen sind irrelevant. also ist der markteanteil viel kleiner.
und für die portabilität der binary ist es sowieso nebensächlich. dass man ein C++ programm für eine andere plattform nochmal etwas anpassen und neu kompilieren muss ist bei spielen garantiert nie das problem.

- für 3d Beschleunigung ist Java Abhängig von OpenGL, da es kein DirectX nutzen kann und letzteres auch die Vorteile der Plattformunabhängigkeit vernichten würde.
erstens kann man auch DX nutzen, zweitens hilft dir oGL überhaupt nicht, da es wiedermal nur die portabilität auf irrelevante systeme verbessert. denn auf konsolen läuft eh wieder kein oGL.

- Die Spieleentwicklung wird immer teurer, daher muß in der Entwicklung gespart werden und die Erschließung der größtmöglichen Kundenmasse hat Vorrang vor allem anderen um die Kosten zu senken. Mit Java wäre z.B. der Markt von Mac OS X und Linux auf einen Schlag erreichbar.
ist er auch so, oder glaubst, da gibts keine C++ compiler?

Gast

2008-12-21, 11:38:46

Manchmal it es mit bloßem rekompilieren nicht getan, da sich auch die compiler nicht immer einig sind bei der auslegung gewisser standards, typgrößen etc.
Wer mal unter Linux eine transition von 32Bit zu 64Bit mitgemacht hat, weiß wovon ich spreche. Und das war noch mit GCC, also beidesmal derselbe Compiler.
Ich stell mir lieber nicht vor was passiert wenn einer ein Programm in 32Bit-C++ auf windows geschreiben hat und mit M$-compiler kompiliert, und das versucht "mal eben" für die anderen Plattformen mit GCC zu kompilieren und das womöglich noch auf 64bit.
Da ist Bytecode schon wesentlich pflegeleichter.
Übrigens kann die JVM sehr wohl SSE nutzen. Allerdings hat sie in den akt. Fassungen einen BUG, der verhindert dass sie z.B. per JNI auf SSE-Optimierte Binaries zugreifen kann.
Nebenbei ist das Problem wohl kaum die Sprache und deren Fallstricke, als vielmehr die Tatsache, dass die anderen Plattformen markttechnisch fast irrelevant sind bei den paar Prozent an Anteilen und es sich deswegen gar nicht lohnt sowas zu machen. Dem Kunden ist schließlich wurscht in was das Spiel programmiert ist.
Es gibt bereits ne relativ breite Basis an Bibliotheken, tools etc für/in C++.
Wenn man jetzt plötzlich was anderes nehmen würde, wäre alle bisherige Entwicklung und deren Kosten plötzlich wertlos. Und das tut sich nun wirklich niemand an.
(Zumal die verwendung von JNI wieder die Plattformunabhängigkeit brechen würde und die Schnittstelle auch nicht grade für Komfort und Fehlertoleranz bekannt ist)
Java sit ne schöne Sache für kleine tools die vom Handy bis zum Großrechner nutzbar sein sollen, aber genau das ist auch ihre größte Schwäche.
Die Optimierung für eine Plattform kann auf einer anderen wieder sub-optimal sein...
Daher denke ich eher nicht dass sich da derartiges tun wird, auch nicht mit C#.
C++ Spiele und die Sprache als solche werden uns noch lange erhalten bleiben.

grüßchen
me

][immy

2008-12-21, 11:59:11

also mir ist nicht bekannt das irgendeine engine in zukunft auf java als basis setzen soll. gibt zwar ein os in java (wobei die startroutinen auch in assembler geschrieben sind), aber das tut hier ja nichts zur sache.

ich würde allerdings die virtual machine auch als negativpunkt anführen. in manchen fällen ist die manuelle speicherverwaltung eben doch besser, der gc von java arbeitet auch nicht immer optimal, die speicheranforderungen würden sehr steigen wie man ja schon an allerlei miniprogrammen in java sehen kann.

außerdem wäre in diesem fall C# sogar die bessere sprache, da man doch mehr freiheiten bekommen kann und moderner als java ist. problem ist aber das die sprache nicht wirklich plattformunabhängig ist.

bzw wie meinst du plattformunabhängig auf binärebene? die vm wird schon auf die jeweilige zielplattform kompiliert, der java code wird ja nur in so ne art bytecode gehalten.

mfg

ich würde auch sagen, wenn dann eher C#. Spiele werden eh fast nur für konsolen oder windows umgesetzt und directX ist mit C# kein Problem.

aber plattformunabhängigkeit ist so eine sache. Viele verstehen darunter man nimmt ein beliebiges stückchen code und das läuft dann auf jeder maschine. das stimmt so aber nicht ganz. Die logik würde zwar überall laufen, aber die präsentation bzw. alles was direkt nach draußen geht muss auf das jeweilige system angepasst werden. daher wird ja C# auch immer beliebter bei serverprozessen, weil diese fast ausschließlich aus komponenten bestehen die nichts mit visualisierung etc zu tun haben.

ein großer vorteil wäre zwar die wirklich schnellere entwicklungszeit, aber man sollte auch nicht vergessen, das viele dinge auch einfach ein wenig langsamer sind, eben weil noch ein zusätzlicher layer zwischen bytecode und programmiersprache liegt. früher oder später werden aber wohl auch spieleentwickler auf diesen zug aufspringen müssen, da die entwicklungszeiten derzeit immer länger werden, sachen kaum wiederverwendet werden können und somit der entwicklungsprozess immer teuerer wird. aber erstmal muss die hardware stimmen.

aber bevor sich 64-bit nicht breitflächig durchgesetzt hat, wird es mit managed code wohl nichts. ich will nicht wissen wie viel speicher ein komplexes rollenspiel benötigt wenn es auf .net basiert.

der großer vorteil gerade beim speichermangement ist aber, führt man ein programm in einer 32-bit umgebung aus so ist der speicher auf 2 GB beschränkt (windows halt). führt man das gleiche programm in einer 64-bit umgebung aus, so hat man aus heutiger sicht praktisch so viel speicher zur verfügung wie das system hergibt. sprich das programm/spiel oder was auch immer wäre direkt ein wenig 64-bit optimiert.

Ganon

2008-12-21, 12:03:05

Äh, das Hauptproblem von Spieleportierungen ist doch überhaupt nicht die gewählte Programmiersprache, sondern die APIs für Grafik, Sound usw. Also alles "Treibernahe".

Und auch hier ist Java nicht "plattformunabhängiger" als alle anderen Sprachen, da es auch hier im Endeffekt bei DirectX oder OpenGL bleibt. Hier fangen die Probleme an. Und ein Bug im OpenGL-Treiber auf irgendeinem System wird JOGL auch nicht beheben können.

Demirug

2008-12-21, 12:34:20

Die GC sind tatsächlich ein Problem bei der Spieleentwicklung. Das merkt man übrigens auch schon bei LUA welches gerne für scripting eingesetzt wird. Viele Desktop-GC arbeiten nach dem Prinzip das sie erst mal nur neuen Speicher reservieren bis diese Resource ein Limit errichte. Dann wird aufgeräumt. Diese Vorgehensweise verursacht bei Spielen dann aber jedesmal einen Frame der viel länger als gewöhnlich braucht. Bei LUA gibt es deswegen inzwischen eine Funktion mit der man dem GC jeden Frame etwas Zeit zum aufräumen geben kann. Ich bin jetzt bei Java nicht so ganz auf dem Laufenden aber das letzte Mal als ich es mir angeschaut habe wurde ein solcher GC type noch nicht angeboten. Der Concurrent GC könnte das Problem allerdings weniger drmatisch machen.

Gleichzeitig wäre ein GC aber auch ein enormer Vorteil bei der Spieleentwicklung. C++ Heapfehler gehören zu der übelsten Sorte von Fehlern. Dazu wird die explizite Speicherverwaltung schnell unübersichtlich wenn man komplexe Objekt besitzt Verhältnisse braucht.

Die allgemeine Performancessituation ist dagegen weitaus undramatischer. Wie gesagt wird sehr gerne LUA eingesetzt und das ist nun wirklich nicht schnell. Man verliert heute die Performances in der Regel beim Design und der Auswahl der Algorithmen und nicht wegen der Programmiersprache. Zudem gäbe es zu mindestens theoretisch ja immer noch die Möglichkeit den Bytecode für die Zielplattform einmalig in nativen Code zu übersetzten um den JIT Overhead zu beseitigen. Zudem könnte dann auch aggressiver optimiert werden. JIT Compiler verzichten in der Regel ja darauf.

Defakto gibt es derzeit nur zwei wichtige Gründe warum wir immer noch bei C++ sind.
- Jede Menge Bestandscode den niemand mal so schnell umschreiben will. Auch wenn viele Entwickler immer wieder gerne behaupten sie hätten eine völlig neue Engine für ein neues Spiel geschrieben.
- Es gibt für die Konsolen nur einen C++ Toolchain. Microsoft hat zwar als Teil von XNA einen C# Toolchain der ist aber nicht für Retail Titel freigegeben.

PatkIllA

2008-12-21, 12:46:58

Gibt es bei XNA eigentlich noch mal Fortschritte oder bleibt das bei 32 Bit only und DX9 stehen?

Ganon

2008-12-21, 12:50:38

Gibt es bei XNA eigentlich noch mal Fortschritte oder bleibt das bei 32 Bit only und DX9 stehen?

Da XNA ja für die XBOX360 ist, quasi, wird das wohl so schnell nix.

Monger

2008-12-21, 12:55:02

Vorteile:
...
- es läuft überall, auf der es eine Java Virtual Machine gibt, d.h. es ist plattformunabhängig auf Binärebene und ein Spiel hätte somit theoretisch den größten Marktanteil wenn es in Java geschrieben werden würde

Davon hatten wir es ja schon öfters mal: Plattformunabhängigkeit ist gar nicht so wichtig. Solange es zwischen Windows und Konsole einigermaßen portierbar bleibt, ist der Rest nicht so kritisch. Und das ist weniger ein Problem der Sprache als des richtigen Frameworks.

Nachteile von Java:
- Spezialrecheneinheiten wie z.b. SSE3, SSE4 etc. können nicht oder nicht effizient genutzt werden

Warum nicht?!?
Der Vorteil der Runtime ist ja gerade, dass sie vom Code abstrahiert, und ganz genau auf die Zielplattform hin optimiert werden kann. Ganz genau an der Stelle ist man doch den klassischen Binärkompilaten haushoch überlegen.

- für 3d Beschleunigung ist Java Abhängig von OpenGL, da es kein DirectX nutzen kann und letzteres auch die Vorteile der Plattformunabhängigkeit vernichten würde.

Wie gesagt: ist nicht so entscheidend. Java kann grundsätzlich mal jede Windows API ansprechen wenn es denn möchte. Wie schnell das geht, sei mal dahingestellt.

Hat Java jemals, sagen wir in den nächsten 10 Jahre eine Chance im Spielesektor als Programmiersprache Fuß zu fassen und mit der Zeit deutliche Marktanteile von C/C++ abzuluchsen?
Imho wird langfristig .NET genau in diese Lücke springen. Microsoft hat da imho ganze Arbeit geleistet: .NET ist mittlerweile sackenschnell, typsicher, hervorragend unterstützt, ungeheuer komfortabel, unheimlich breit gefächert, und läuft über XNA sowohl auf Windows als auch auf der XBox360.

Ich bin ja an sich ein Java-Fan, und so manche Sprachfeatures vermisse ich in .NET nach wie vor. Aber ich muss zugeben, dass es sich unheimlich locker-flockig damit programmiert, und das mit einer ähnlichen Robustheit wie unter Java.

Insbesondere auf der XBox360 scheinen sie ja auch von unten den Spielemarkt damit ziemlich aufzurollen. Dort sprießen kleinere Spiele auf XNA Basis ja ständig aus dem Boden. Ich könnte mir durchaus vorstellen, dass XNA in ein paar Jahren auch für größere Spieleprojekte mal interessant wird.

Blacksoul

2008-12-21, 12:55:45

Da XNA ja für die XBOX360 ist, quasi, wird das wohl so schnell nix.

XBox 360 und Zune.

t.b.d

Hamster

2008-12-21, 13:09:18

äh, blöde zwischenfrage, aber wenn ihr von GC sprecht, meint ihr den Garbage Collector, oder?

Aquaschaf

2008-12-21, 13:23:39

Ja. Ich denke GC wäre ein viel geringeres Problem wenn Konsolen nicht so knapp kalkulierten Arbeitsspeicher hätten.

HOT

2008-12-21, 14:06:20

Als Serveraufsatz bei MMORPGs wird Java schon länger verwendet, z.B. bei SOE-Titeln.

Exxtreme

2008-12-21, 14:28:02

Demirug

2008-12-21, 14:45:17

Was verlierst du auf einer Konsole wenn du ein Kompilat daraus machst? Ich sehe hier lediglich den Verlust einer vereinfachten Kompatibilität zur nächsten Generation. Ein verbessertes JIT als Teil der Firm ist zwar denkbar aber nicht unproblematisch. Nicht umsonst werden bei Konsolenspielen die meisten Laufzeitfunktionen immer noch direkt ins Programm gelinkt. Nur so kann man verhindern das zukünftige Änderungen daran bestehenden Spiele zerstören.

Ich darf ja leider noch nicht aus dem Nähkästchen plaudern aber es gibt da durchaus interessante Entwicklungen. Wobei das mehr in Richtung C# und weniger in Richtung Java läuft.

Exxtreme

2008-12-21, 14:54:50

Als Vorteil würde man eben die Möglichkeit verbesserte JIT-Compiler zu laden verlieren. Und Kompatibilität würde es nur dann brechen wenn sich ein Spielehersteller nicht an irgendwelche Vorgaben halten würde. Nur diese Problematik besteht auch bei neuen Revisionen einer Konsole.

Demirug

2008-12-21, 15:07:31

Ich bezeichne das primäre Kompatibilitätsproblem gerne als „Softe-“ oder Implementierungs- Kompatibilität. Eine API Spezifikation kann niemals so genau sein als das sie keinem Interpretationsspielraum lässt. Dadurch entstehen bei den Implementierungen Verhaltensmuster. Nun kommt es sehr leicht dazu dass Programme unbewusst auf diese Muster angewiesen sind. Ändert man nun die Implementierung können sich auch die Verhaltensmuster ändern und damit in bestehende Anwendungen zu Fehlern führen.

Gast

2008-12-22, 02:29:24

äh, blöde zwischenfrage, aber wenn ihr von GC sprecht, meint ihr den Garbage Collector, oder?

Ja, was auch sonst?

Gast

2008-12-22, 02:30:20

- Es gibt für die Konsolen nur einen C++ Toolchain. Microsoft hat zwar als Teil von XNA einen C# Toolchain der ist aber nicht für Retail Titel freigegeben.

Das kann nicht sein, es muß auch eine C Toolchain geben, oder wie sonst könnte JC Quake auf die Konsolen portieren?

Krishty

2008-12-22, 02:32:20

Warum beantwortet man Fragen, die fünf Posts vorher schon beantwortet wurden?
Ich meine, ich habe zumindest einen Post-Counter der für diese zwei Sätze hoch springt… aber als Gast? -.-

Gast

2008-12-22, 02:34:08

Warum nicht?!?
Der Vorteil der Runtime ist ja gerade, dass sie vom Code abstrahiert, und ganz genau auf die Zielplattform hin optimiert werden kann. Ganz genau an der Stelle ist man doch den klassischen Binärkompilaten haushoch überlegen.

Und dennoch ist man flexibler wenn man die MMX und SSEE Einheiten direkt manuell ansprechen kann, denn so schlau wie ein Mensch kann ein Compiler gar nicht sein.
Ein Compiler hat allerhöchstens mehr fundiertes Wissen über die ganzen Assemblerbefehle, aber nicht die Intelligenz um es auch optimiert anzuwenden.

Coda

2008-12-22, 02:59:58

Das kann nicht sein, es muß auch eine C Toolchain geben, oder wie sonst könnte JC Quake auf die Konsolen portieren?
Damit ist natürlich auch C gemeint. Es gibt auch praktisch keinen C++-Compiler der nicht auch C versteht.

Monger

2008-12-22, 09:38:41

Und dennoch ist man flexibler wenn man die MMX und SSEE Einheiten direkt manuell ansprechen kann, denn so schlau wie ein Mensch kann ein Compiler gar nicht sein.
Ein Compiler hat allerhöchstens mehr fundiertes Wissen über die ganzen Assemblerbefehle, aber nicht die Intelligenz um es auch optimiert anzuwenden.
Ein Compiler arbeitet auch kontextsensitiv. Je nachdem wie gut der Compiler ist, schmeißt der intern auch mal den Code komplett um.
Wenn die Compilerregeln klever geschrieben sind, kann der auch auf bestimmte Befehlssätze hin optimieren. Da musst du schon sehr, SEHR gut sein um besser zu optimieren als ein moderner Compiler, und selbst dann hast du unverhältnismäßig viel Entwicklungsaufwand zum Fenster rausgeblasen.

Zumindest in der Theorie ist ein JIT Compiler schneller als ein Binärkompilat - einfach weil er sehr speziell auf die Rechnerarchitektur eingehen kann.

Gast

2008-12-22, 15:28:21

Wenn das ganze wie in der java-vm via jit+hotspot läuft erübrigt sich das Kompilat.

maximAL

2008-12-22, 15:35:31

Ein Compiler arbeitet auch kontextsensitiv. Je nachdem wie gut der Compiler ist, schmeißt der intern auch mal den Code komplett um.
Wenn die Compilerregeln klever geschrieben sind, kann der auch auf bestimmte Befehlssätze hin optimieren. Da musst du schon sehr, SEHR gut sein um besser zu optimieren als ein moderner Compiler, und selbst dann hast du unverhältnismäßig viel Entwicklungsaufwand zum Fenster rausgeblasen.

Zumindest in der Theorie ist ein JIT Compiler schneller als ein Binärkompilat - einfach weil er sehr speziell auf die Rechnerarchitektur eingehen kann.
wunder sollte man sich von prozessor-spezifischen optimierungen nicht erwarten. wirklich viel bringen da eigentlich auch nur SIMD-erweiterungen (SSE etc.) und gerade die kann ein compiler in der praxis eben nicht immer generieren, weil dafür meist eine "höheres wissen" über den code nötig ist. und auch davon ab bringt das nicht so viel wie man glauben könnte, zumindest hab ich beim GCC auch mit prozessor-spezifischer optimierung keine weltbewegenden unterschiede feststellen können.
und das compiler intern mal eben den programmcode wirklich entscheidend umstrukturieren ist leider auch nicht mehr als ein feuchter traum der informatik, dafür eignen sich die verbreiteten imperativen sprachen nicht wirklich.

GamlerHart

2008-12-22, 15:53:25

Man kann natürlich auch probieren, die SIMD-Instruktionen durch spezielle API's für die Hochsprache zugänglich zu machen. Soviel ich ist sowas für Mono in Planung. (Quelle: http://tirania.org/blog/archive/2008/Nov-03.html )

Wie gut das ist bzw wie praxist tauglich das ist weis ich nicht. Ist nicht mein Fachgebiet =)

Monger

2008-12-22, 16:04:50

...und das compiler intern mal eben den programmcode wirklich entscheidend umstrukturieren ist leider auch nicht mehr als ein feuchter traum der informatik, dafür eignen sich die verbreiteten imperativen sprachen nicht wirklich.

Naja, sowohl der Byte Code von Java als .NET ist ziemlich high level. Da bekommt der Compiler schon eine recht gute Idee davon was der Entwickler eigentlich vorhatte. Es ist auf jeden Fall per se mal kein Argument gegen JIT Compiler.

und auch davon ab bringt das nicht so viel wie man glauben könnte, zumindest hab ich beim GCC auch mit prozessor-spezifischer optimierung keine weltbewegenden unterschiede feststellen können.

Das hat wohl in erster Linie damit zu tun, dass ... nunja... der Flaschenhals zumindest auf dem PC selten am Befehlssatz hängt. SSE und Konsorten bringen wirklich nur für sehr, SEHR wenige Anwendungsfälle dramatisch was.

thacrazze

2008-12-22, 17:45:37

es läuft nicht auf konsolen und alle anderen plattformen sind irrelevant. also ist der markteanteil viel kleiner.
Die Konsolen sind nicht das Problem. Da es von Java nun auch eine Open-Source-Variante gibt ist eine Portierung kein Problem.

denn auf konsolen läuft eh wieder kein oGL.
Auf der PS3 und Xbox 360 läuft OpenGL ES. Und außerdem gibt es Java 3D, mit welchem man sowohl OpenGL als auch Direct3D nutzen kann.

Gast

2008-12-22, 17:59:53

Auf der PS3 und Xbox 360 läuft OpenGL ES.
Was für kommerzielle Spiele absolut unbrauchbar ist.

Demirug

2008-12-22, 18:02:37

Die Konsolen sind nicht das Problem. Da es von Java nun auch eine Open-Source-Variante gibt ist eine Portierung kein Problem.

Du ahnst gar nicht was für ein juristischer Albtraum open source und Konsolen sind. GPL ist zum Beispiel ein ganz klares Nogo.

Auf der PS3 und Xbox 360 läuft OpenGL ES. Und außerdem gibt es Java 3D, mit welchem man sowohl OpenGL als auch Direct3D nutzen kann.

OpenGL ES auf der XBox 360? In meinem XDK nicht. Und die PS3 Version nutzt kein AAA Titel weil sie nicht sonderlich performant ist.

thacrazze

2008-12-22, 18:04:17

Was für kommerzielle Spiele absolut unbrauchbar ist.
Hardwaremäßig läuft auch echtes OpenGL auf den Konsolen. Nur man hat eine Softwaresperre (Treiber) gemacht. Wenn Sony schlau wäre, könnten die auch OGL auf der PS4 unterstützen.

Demirug

2008-12-22, 18:08:05

Hardwaremäßig läuft auch echtes OpenGL auf den Konsolen. Nur man hat eine Softwaresperre (Treiber) gemacht. Wenn Sony schlau wäre, könnten die auch OGL auf der PS4 unterstützen.

Sorry aber das ist Blödsinn. Das was da Hardwaremäßig auf der PS3 abgeht hat mit OpenGL nicht viel zu tun.

thacrazze

2008-12-22, 18:09:57

Sorry aber das ist Blödsinn. Das was da Hardwaremäßig auf der PS3 abgeht hat mit OpenGL nicht viel zu tun.
Der G70 unterstützt hardwareseitig OpenGL 2.1. Ich habe nur geschrieben das es technisch möglich wäre OpenGL über die GPU auf der PS3 laufen zu lassen.

Demirug

2008-12-22, 18:23:08

Der G70 unterstützt hardwareseitig OpenGL 2.1. Ich habe nur geschrieben das es technisch möglich wäre OpenGL über die GPU auf der PS3 laufen zu lassen.

Natürlich wäre es technisch möglich einen OpenGL Implementierung für die PS3 zu schreiben. Genauso könnte man auch Direct3D unterstützen. Beides würde aber einen unakzeptablen CPU Overhead verursachen und CPU Leistung zum verschwenden hat man auf der PS3 nun wirklich nicht übrig.

thacrazze

2008-12-22, 19:20:58

Natürlich wäre es technisch möglich einen OpenGL Implementierung für die PS3 zu schreiben. Genauso könnte man auch Direct3D unterstützen. Beides würde aber einen unakzeptablen CPU Overhead verursachen und CPU Leistung zum verschwenden hat man auf der PS3 nun wirklich nicht übrig.
Die PS3 ist doch die Konsole mit der aktuell größten CPU-Leistung

Was ich aber nicht verstehe, wieso sollte der CPU-Overhead von einem Nicht-OpenGL-Spiel höher werden, nur weil es für diese Plattform eine OpenGL-Implementierung gibt (die nicht unbedingt benutzt werden muss)?

Demirug

2008-12-22, 19:49:31

Die SPU Leistung ist schwierig in echte Leistung umzusetzen.

Der Overhead von einem Spiel des einen solchen OpenGL Stack nicht benutzt wird natürlich nicht höher. Mir ging es darum das es sich nicht lohnt eine OpenGL Implementierung für die PS3 zu schreiben weil sie niemand ernsthaft benutzten würde.

Mephisto

2008-12-23, 10:17:34

Ist nicht Chrome (das Spiel von Techland) in Java programmiert, welches beim Laden übersetzt wird?

ScottManDeath

2008-12-23, 16:06:09

AFAIK wurde fuer Chrome Java fuer die Spielelogik und C++ per JNI als Renderengine verwendet.

Coda

2008-12-23, 17:22:43

Naja, sowohl der Byte Code von Java als .NET ist ziemlich high level.
Eine Stack-Machine ist ganz sicher nicht High Level. Es hört sich mal wieder so an als wüsstest du nicht von was du redest, kann das sein?

Gast

2008-12-25, 06:33:28

Du ahnst gar nicht was für ein juristischer Albtraum open source und Konsolen sind. GPL ist zum Beispiel ein ganz klares Nogo.

Schön das wir das begründet haben.

Gast

2008-12-25, 15:21:21

Schön das wir das begründet haben.
Da müsste man für genaue Infos einen Anwalt fragen.
Ein No-Go für die normale GPL ist schon das Problem, dass man nicht statisch gegen non-GPL Code linken darf.

Besonders lustig ist auch immer wieder das Zusammenspiel mit den Lizenzverträgen für die SDKs der Konsolenhersteller.

Anwälte schmeissen auch bei anderen Opensource Lizenzen einem auf Nachfrage immer eine solche Liste an Restriktionen an den Kopf, dass niemand mit gesundem Menschenverstand sagt "wir nutzen es".

thacrazze

2008-12-25, 17:12:42

Es gibt ja noch die LGPLv2.1 und die ist sehr wohl sehr gut einsetzbar

Demirug

2008-12-25, 17:21:49

Es gibt ja noch die LGPLv2.1 und die ist sehr wohl sehr gut einsetzbar

Nein. Bei den Konsolen ist das zum einen mit dem dynamischen linken nicht wirklich eine gute Idee. Das viel größere Problem ist aber das man den Code meist etwas anpassen muss damit er auf den Konsolen läuft. Laut LGPL muss man diese Anpassungen veröffentlichen laut den Konsolen SDK Lizenz darf man das aber nicht. Entsprechend brauche ich unserer Rechtsabteilung mit GPL oder LGPL gar nicht zu kommen. Das gilt für alle Lizenzen in denen irgendwie drin steht das man Codeänderungen veröffentlichen muss.

Shink

2008-12-25, 18:24:02

Du ahnst gar nicht was für ein juristischer Albtraum open source und Konsolen sind. GPL ist zum Beispiel ein ganz klares Nogo.
Hmm... dann eben Apache License (Harmony).

thacrazze

2008-12-25, 19:24:49

Oder eben BSD-Lizenz oder MIT-Lizenz

(Java OpenGL steht unter der BSD-Lizenz)

maximAL

2008-12-25, 19:57:11

blöderweise kann man sich in der regel nicht aussuchen, welche lizenz man gern hätte.

Shink

2008-12-25, 21:04:43

blöderweise kann man sich in der regel nicht aussuchen, welche lizenz man gern hätte.
:confused:
Naja, man kann sich ja wohl aussuchen ob man Apache Harmony oder das Sun JDK portiert, odr?
Davon abgesehen ist die Lizenz doch wohl kein Argument gegen eine Programmiersprache; man kann ja immer noch selbst implementieren wenns einem Spaß macht (gabs das nicht bei der Dreamcast?)

@Topic: Sollte sich mal irgend eine Bytecode-basierte Sprache ala C# für Spiele durchsetzen (davon gehe ich irgendwie aus), ist es ja relativ egal worin man entwickelt und dann könnte z.B. die Java-Affinität der meisten Informatik-Universitäten eine Rolle spielen. Aber wirklich wissen kann mans natürlich nicht.

Gast

2008-12-26, 00:27:26

@Topic: Sollte sich mal irgend eine Bytecode-basierte Sprache ala C# für Spiele durchsetzen (davon gehe ich irgendwie aus),
Da fänd ich eine Begründung sehr interessant.

Luke Undtrook

2008-12-26, 09:47:26

Java ist für Spiele deshalb doof weil es auf Konsolen keinen Sinn macht. Selbst wenn es eine Runtime gäbe, Konsolen haben alle sehr wenig Speicher. Da müllt schon die Runtime wohl das meiste zu. Die gleiche Problematik hat auch .NET, deshalb wird es wohl nur in irgendwelchen Hobbyprojekten eingesetzt, nicht jedoch in AAA-Titeln. Klar könnte man ein Kompilat draus machen aber dann verliert man viele Vorteile und kann gleich wieder bei C++ bleiben.
Runtime? .NET? Sind Coder heute zu nix eigenem mehr fähig? Auf dem C64 reichten 20k ROM für Basic und 0k für Assembler und heute implodiert der 512MB PC schon bei Firefox, wenn ein Url Java braucht.

Gast

2008-12-26, 10:17:32

Nein. Bei den Konsolen ist das zum einen mit dem dynamischen linken nicht wirklich eine gute Idee.

Warum nicht?
Was spricht dagegen?

Also jetzt mußt du das auch schon begründen.

Das viel größere Problem ist aber das man den Code meist etwas anpassen muss damit er auf den Konsolen läuft. Laut LGPL muss man diese Anpassungen veröffentlichen

Ja, muß man.

laut den Konsolen SDK Lizenz darf man das aber nicht.

Wie bitte?

Seit wann darf die Konsolen SDK bestimmen was man mit Open Source Code oder auch eigenen Code machen darf?
In diesem Fall bei einer LGPL Anpassung wäre es ja beides, Open Source Code und eigener Code zusammen verschmolzen.

Entsprechend brauche ich unserer Rechtsabteilung mit GPL oder LGPL gar nicht zu kommen. Das gilt für alle Lizenzen in denen irgendwie drin steht das man Codeänderungen veröffentlichen muss.

Ich gehe jetzt mal davon aus, daß es Spiele wie Ankh für die Konsolen nicht gibt.
Die verwenden nämlich eine 3d Engine die unter der LGPL steht.

Gast

2008-12-26, 10:19:50

Oder eben BSD-Lizenz oder MIT-Lizenz

(Java OpenGL steht unter der BSD-Lizenz)

Diese Bibliotheken mit derartigen Lizenez werden für die Spieleprogrammierung ja auch eingesetzt.

Die zlib mit einer MIT ähnlichen Lizenz, wird z.b. sehr oft von Spielen benutzt.
Das gleiche gilt für die VORBIS Bilbliothek.

ABER und jetzt kommt die große Frage an Demirug!

OpenAL steht unter der LGPL und wird für kommerzielle Spiele verwendet.

Demirug

2008-12-26, 10:59:20

Warum nicht?
Was spricht dagegen?

Also jetzt mußt du das auch schon begründen.

Muss ich das? Selbst wenn dem so wäre tue ich das lieber nicht da wir uns hier schon wieder in den Tiefen der NDA Restriktionen bewegen.

Wie bitte?

Seit wann darf die Konsolen SDK bestimmen was man mit Open Source Code oder auch eigenen Code machen darf?
In diesem Fall bei einer LGPL Anpassung wäre es ja beides, Open Source Code und eigener Code zusammen verschmolzen.

Ein Vertrag zwischen zwei Parteien darf sowas regeln. Und nichts anderes als ein Vertrag ist die NDA eines Konsolen SDKs. Kurzum man darf kein Code veröffentlichen der mit der Hilfe eines Konsolen SDKs entstanden ist. Und ohne SDK ist eine Anpassung ja kaum möglich.

Ich gehe jetzt mal davon aus, daß es Spiele wie Ankh für die Konsolen nicht gibt.
Die verwenden nämlich eine 3d Engine die unter der LGPL steht.

Und jetzt kommt gleich der Hinweis dass es eine DS Version gibt, oder? Da ich aber nirgendwo die Orge DS Version finden kann muss ich davon ausgehen das man die Engine für die DS Version ausgetauscht hat oder einen Verstoß gegen die Orge Lizenz begangen hat. Sollten sie jemals eine XBox oder Playstation Version davon machen wollen müssen sie genauso vorgehen. Theoretisch gibt es noch die Möglichkeit der Doppellizenz. Das dürfte bei einem Projekt mit so vielen Entwicklern wie bei Orge aber problematisch werden.

ABER und jetzt kommt die große Frage an Demirug!

OpenAL steht unter der LGPL und wird für kommerzielle Spiele verwendet.

Aber nicht auf den Konsolen. Das ist allerdings gar nicht der relevante Punkt. Lade dir mal das OpenAL SDK von Creative herunter und lese die Lizenz. Danach dürfte klar sein warum das rechtliche OpenSource Problem hier überhaupt nicht zum tragen kommt.

Aquaschaf

2008-12-26, 11:06:30

Und jetzt kommt gleich der Hinweis dass es eine DS Version gibt, oder? Da ich aber nirgendwo die Orge DS Version finden kann muss ich davon ausgehen das man die Engine für die DS Version ausgetauscht hat oder einen Verstoß gegen die Orge Lizenz begangen hat. Sollten sie jemals eine XBox oder Playstation Version davon machen wollen müssen sie genauso vorgehen. Theoretisch gibt es noch die Möglichkeit der Doppellizenz. Das dürfte bei einem Projekt mit so vielen Entwicklern wie bei Orge aber problematisch werden.

Zu Ogre3D gibt es tatsächlich eine alternative uneingeschränkte Lizenz, weil es für Konsolen nicht anders geht.