Anzeige:
Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 16 bis 30 von 39

Thema: 3D Engien

  1. #16
    Registrierter Benutzer
    Registriert seit
    13.12.2004
    Beiträge
    15
    Zitat Zitat von ceisserer
    Nein, einfach den Train-Collector benutzen (ist jetzt ein anderer Algorythmus nicht mehr der Train aber genauso kleine Pausen) mit -Xincgc
    Dabei treten selbst bei großen heaps nahezu keine GCs auf die länger als 1ms dauern, dafür sinkt der durchsatz, aber müllen in der engine ist sowieso verboten.
    Kenn ich ehrlich gesagt nicht. Ist der Befehl Xincgc nur beim gcj (oder wie der auch heisst) verwendbar oder auch beim Compiler von sun?

    Und in 10 tagen ist Weihnachten! Nein - nix wird übersehen!
    Keine Referenz drauf == tot bei voller GC!
    Dir ist sicher bekannt, dass dispose() in Java 1.5 deprecated ist. Die Alternative ist der Garbage Collector. Ich habe ihn mal explizit aufgerufen und konnte keine Speicherplatzminderung feststellen. War aber auch nur ein 0815 Test, liegt vielleicht daran.


    Der 10%ige Vorsprung von C ist hier relativ, da die C-benchmarks genau für die Zielhardware kompiliert worden sind.
    In der Praxis tut man das nicht, und muss 20-35% Leistungsverlust hinnehmen. Java optimiert immer genau auf die prozerror-features, wenn SSE da ist, wirds verwendet, wenn nicht dann nur FPU.
    Kannst du mir die Quelle mal dazu geben? Würde mich interessieren.
    Ansonsten: Die VM ist auch nicht optimiert.

    Nein, die Compiler sind am Ende!
    Optimierende C/C++ Compiler gibts seit über 15 Jahren, es wird heutzutage ziemlich alles gemacht was gerade noch erlaubt und möglich ist, die einzigen neuerungen sind feaure-anpassungen an neue proziis.
    Das würde ich nicht sagen. Der gcc 3.4 soll z.B. 30% (wenn ich´s richtig im Kopf habe) schneller sein, als der Vorgänger. Außerdem hat man nicht alle Algorithmen und somit Optimierungen entdeckt.

    Liebe Grüße
    Reality

  2. #17
    Registrierter Benutzer
    Registriert seit
    28.04.2001
    Beiträge
    62
    Zitat Zitat von ceisserer
    Scharn! das einzige was grenzenlt ist die Grafikkarte und dein prozessor beim verarbeiten von den OpenGL-Schamrn. Das bissi Kollision-Detektion und Logik machen heutige Prozessoren mit links.
    (Sonst hätte man wohl nie eine Spiele-Engine in Python schreiben können, das 10x langsamer als Java ist (bei reiner codeperformance)).
    Und wieso ist die Spieleengine in Python 10x langsamer? Irgendwie sehe ich darin keinen Wiederspruch zu dem was ich gesagt habe. Eher wiedersprichst du dich mit dieser Aussage selber.
    Geändert von chrizel (14-12-2004 um 20:04 Uhr)

  3. #18
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm...

    Kenn ich ehrlich gesagt nicht. Ist der Befehl Xincgc nur beim gcj (oder wie der auch heisst) verwendbar oder auch beim Compiler von sun?
    Das ist ein JVM-switch, also der Runtime übergeben, nicht dem Compiler.
    Diesen Switch hat IMHO nur SUN, Bea und IBM bieten ähnliche switches an, die im grunde das selbe tun: Pausen minimieren auch wenn dadurch der Durchsatz leidet (oftmals ca nu 1/2).
    Beim GCJ ist's was Garbage-Collector angeht leider etwas schlechter bestellt, der hat nur einen "Conservativ GC", der bei jeder Collection den gesamten Heap nach toten Objecten absucht und da dieser Kollektor eigentlich für C designt wurde, muss es noch raten, welche Variablen nun adress-pointer sind und welche nicht.
    Zu gute halten muss man diesem GC ("Boehm GC"), dass er sehr portabel und gut getestet ist.

    Dir ist sicher bekannt, dass dispose() in Java 1.5 deprecated ist. Die Alternative ist der Garbage Collector. Ich habe ihn mal explizit aufgerufen und konnte keine Speicherplatzminderung feststellen. War aber auch nur ein 0815 Test, liegt vielleicht daran.
    1.) Dispose gibts nur bei Objekten mit Peers, wo ein GC nicht die richtige Methode zum Freigeben ist - gibts aber immer noch und wird auch bleiben.
    2.) Java reserviert Speicher in einem eigenen bereich, dem sogenannten heap. Was du im taskmanager siehst ist die Größe des heaps, auch wenn der heap nur 10% voll ist belegt er mehr.

    Das würde ich nicht sagen. Der gcc 3.4 soll z.B. 30% (wenn ich´s richtig im Kopf habe) schneller sein, als der Vorgänger. Außerdem hat man nicht alle Algorithmen und somit Optimierungen entdeckt.
    Jo, beim Kompilieren, weil er (nun endlich auch!) mit vorkompilierten header-dateien umgehen kann *endlich*. Zur Laufzeit sind wenn du Glück hast im Schnitt 2% drinnen (auf x86).

    Und wieso ist die Spieleengine in Python 10x langsamer? Irgendwie sehe ich darin keinen Wiederspruch zu dem was ich gesagt habe. Eher wiedersprichst du dich mit dieser Aussage selber.
    Nein, das war natrlich nicht so gemeint.
    Obwohl Python mind. 10x langsamer als Java oder C++ ist, ists bei einer Spiele-Engine annähernd egal, vieleicht läuft diese dann um 20% langsamer.
    Hätten die das allerdings in C gemacht, wären die nie in den Genuss der excelenten Python-Sprache gekommen und hätten sich mit allerlei Low-Level Zeugs herumschlagen müssen - wären also nie soweit gekommen.


    Abschließend bleibt mir nur noch die Nachteile von Java (=die Sun JVM aufzuzählen):
    * Langsamer Start für kleine, grafische Anwendungen (-> Swing ist Overdressed)
    * Hoher Speicherverbrauch (auch bei C#/.NET, dagegen kommt man bei VMs nur schwer an).
    * Nicht OpenSource. Das ist meinem Meinung das allergrößte Problem, wird aber erstaunlicherweise überhaupt nicht ernst genommen.

    Das sind so relativ alle Nachteile, welche Rang und Namen haben. Was der JVM über geschwindigkeit etc. nachgesagt wird ist schlicht und einfach falsch.

    Relativ schade ist, dass es derzeit keine guten bytecode-VMs gibt, obwohl ich diese Technik sehr vielversprechend finde. Mono ist derzeit gut dabei, allerdings bringts Mono trotz arbeiten an der Runtime/GC erst auf ca. 1/3 bis 1/2 moderner JVMs oder .NET was Speed angeht.
    Geändert von Lin728 (20-08-2017 um 20:39 Uhr)

  4. #19
    Registrierter Benutzer
    Registriert seit
    28.04.2001
    Beiträge
    62
    Zitat Zitat von ceisserer
    Nein, das war natrlich nicht so gemeint.
    Obwohl Python mind. 10x langsamer als Java oder C++ ist, ists bei einer Spiele-Engine annähernd egal, vieleicht läuft diese dann um 20% langsamer.
    Dann zeig mal diese Spiele-Engine her oder gib einen Link. Ich denke mal 20% Geschwindigkeitsverlust sind da schon untertrieben. Ein Python Function Call ist allein schon >8x langsamer als bei C oder Java.

    Hätten die das allerdings in C gemacht, wären die nie in den Genuss der excelenten Python-Sprache gekommen und hätten sich mit allerlei Low-Level Zeugs herumschlagen müssen - wären also nie soweit gekommen.
    Ich kenne PyGame und einen Freund der sich damit sehr intensiv beschaeftigt hat. (http://pygame.org/). Das ganze ist recht nett und mag fuer einfache 2D-Spiele auch voll ausreichend sein, aber bei grafisch aktuellen Spielen kann ich es mir nicht vorstellen dass man das aus Python rausholen koennte. Du sagst selber 20% langsamer. Ich schaetze noch mehr, und bei 3D-Spielen (mit guter Grafik) zaehlt der Speed sehr wohl. Und es ist falsch zu glauben dass alles in der Grafikkarte ablauft. Die OpenGL-Befehle muessen schliesslich auch zur Grafikkarte geschickt werden und das bei jedem Frame.

    Ich wuerde dann doch eher Common Lisp vorziehen, denn da habe ich Garbage Collection, dynamic und static Typing, Inkrementelle und optimierte Kompilierung (bis auf Funktionsebene) in Maschinencode, hoehere Abstraktionsmoeglichkeiten usw. Ein sehr bekanntes Spiel das zu grossen teilen auf einer Lisp-Implementierung setzt ist z.B. das PS2-Spiel Jak&Daxter und seine Nachfolger Jak2 und Jak3.

    http://c2.com/cgi/wiki?LispInJakAndDaxter

    Sorry falls ich euch vollgelabert hab, lg Clemens
    Sorry auch von mir, ich will hier nicht grossartig diskutieren, mir gehts nur um Python bei Spielen... den Speed von Java zweifle ich gar nicht an... (dafuer aber andere Aspekte, aber das ist Off Topic )
    Geändert von chrizel (20-12-2004 um 21:16 Uhr)

  5. #20
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Zitat Zitat von ceisserer
    * Nicht OpenSource. Das ist meinem Meinung das allergrößte Problem, wird aber erstaunlicherweise überhaupt nicht ernst genommen.
    Ist OpenSource
    Nur nicht im Sinne der OSI. Aber das ist ein Detail
    Und ja, mich stört auch dass es das Teil nicht unter einer vernünftigen Lizenz gibt.

    Was mich allerdings immer wundert ist dass es eine brauchbare freie Implementierung von .NET gibt (Mono, wies mit .GNU steht weiss ich nicht, aber deren Windows.Forms sieht auch gut aus) - und bei Java diesbezüglich immer noch arg an brauchbarem und aktuellem Fehlt.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  6. #21
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmmm...

    Jetzt wirds schön langsam interresant ;-)

    Was mich allerdings immer wundert ist dass es eine brauchbare freie Implementierung von .NET gibt (Mono, wies mit .GNU steht weiss ich nicht, aber deren Windows.Forms sieht auch gut aus) - und bei Java diesbezüglich immer noch arg an brauchbarem und aktuellem Fehlt.
    Naja, Mono wird meiner Meinung nach überbewertet, deren Runtime steht meiner Meinung nach noch immer erst am Anfang, ist vieleicht Kaffe ein wneig überlegen, aber das wars dann schon.
    Windows.Forms werden schön langsam was, weil sie wine über bord geworfen haben und die windows.forms jetzt komplett neu in C# schreiben. Ich bin gespannt wie die das mit der geschwindigkeit hinkriegen.

    Der Hauptgrund warum Mono so gut forwärts kommt, ist relativ simpel: Es gibt einfach keine Alternative!
    Warum sollte jemand unter Linux (außer aus ideologischen Gründen) eine freie JVM verwenden, wenn es sowieso die SUN/IBM-JVMs gibt, die den selben Code 5x so schnell und 10x so stabil ausführen können?

    Zu Mono gibts bis auf Portable.NET (was auch nicht besser ist) keine Alternative, drum arbeiten alle dran, dass Mono besser wird.

    Ich hoffe Mono wird was - das wäre endlich das ende dieser unendlichen Inkompatibilitäten, nie wieder irgendwas kompilieren, wenn ich ein stinknormales Programm installieren will
    Geändert von Lin728 (20-08-2017 um 20:41 Uhr)

  7. #22
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Mit .GNU gibts schon eine Alternative zu Mono, die imo unterbewertet wird. (Magst recht haben dass Mono überbewertet wird).

    Allerdings gabs Java ja lange Zeit nicht (wirklich) für Linux. Auch zu der Zeit gabs keinen aktuellen freien Port von Java.

    Bis Mono wirklich 100%ig kompatibel zu .NET ist dürfte wohl noch sehr viel Zeit vergehen: Microsoft schläft ja auch nicht (.NET 2.0 wartet schon) - und die 100%ige Kompatibilität zeichnet sich ja dadurch aus dass wirklich jedes kitzekleine Detail gleich ist weil sich garantiert irgendwer drauf verlässt dass dem so ist.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  8. #23
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Naja...

    Hmm, es kommt auch draufan, wie man Mono einsetzen will und als was man es sieht.
    Mono wird auf keinen Fall das "nimm einfach eine beliebige .NET Anwendung von VC.NET und start sie an", wie man das von WINE erwartet.
    Geändert von Lin728 (20-08-2017 um 20:42 Uhr)

  9. #24
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Zitat Zitat von ceisserer
    Hmm, es kommt auch draufan, wie man Mono einsetzen will und als was man es sieht.

    Mono wird auf keinen Fall das "nimm einfach eine beliebige .NET Anwendung von VC.NET und start sie an", wie man das von WINE erwartet.
    Wenn nicht wozu denn Kompatibilität mit .NET? Wozu das Risiko von MS-Klagen eingehen? Wieso dann nicht eine der bestehenden freien JVMs verbessern (in Bezug auf Linux-Funktionalität, weniger Nachbau von Java)? Wieso nicht was mit parrot?

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  10. #25
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm...

    Wenn nicht wozu denn Kompatibilität mit .NET?
    Nun, wenn sich der Entwickler an die Mono-APIs hält und die Schnittmenge mit .NET berücksichtigt gibts eh keine Probleme.
    Wenn man sich aber heutige .NET-(Windows)-Anwendungen ansieht, kommt einem eher das Graußen.
    Da wird haufenweise über PInvoke nativer Code aufgerufen, und das ist natürlic genauso portabel, wie Java mit JNI ;-)

    Wieso dann nicht eine der bestehenden freien JVMs verbessern (in Bezug auf Linux-Funktionalität, weniger Nachbau von Java)?
    Hmm, ne JVM tut nicht wirklich das, wozu .NET gedacht wurde. .NET soll eher ein virtueller Prozessor sein die die Maschine abstrahiert, eine JVM bietet dazu zu wenig Kontrolle über Speicher etc...
    Geändert von Lin728 (20-08-2017 um 20:42 Uhr)

  11. #26
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Zitat Zitat von ceisserer
    Jaja, Parrot. Das Hauptproblem an Parrot ist, dass sie keine Class-Libraries mitliefern wollen.
    So gut bin ich über das Projekt ja auch nicht informiert. Aber das kann man ja ändern.
    Nicht das informiert sein meine ich, das mitliefern.

    Also wiedereinmal das typische (Linux-)Desaster:
    Tonnenweise konkurrierende Projekte, obwohl sicher was viel besseres rauskommen würde, wenn alle zusammenarbeiten würden.
    Vielleicht, vielleich auch nicht. Bei den Klassikern diesbezüglich (Editoren, DEs, etc) finde ich den Ist-Zustand gar nicht so schlecht.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  12. #27
    Registrierter Benutzer
    Registriert seit
    20.11.2004
    Beiträge
    122
    Also wiedereinmal das typische (Linux-)Desaster:
    Tonnenweise konkurrierende Projekte, obwohl sicher was viel besseres rauskommen würde, wenn alle zusammenarbeiten würden.
    Das siehst du so. So ist es aber definitiv nicht.
    Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?

    Meine Meinung,
    `kk
    C, Python, OCaml

  13. #28
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Zitat Zitat von `kk
    Das siehst du so. So ist es aber definitiv nicht.
    Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?
    Das einzige was dich motiviert ist dass es jemand anderes gibt der droht es besser zu machen als du
    Naja, auf jeden Fall funktioniert das sowohl bei Scribus als auch bei K3b bestens - und bei beiden gibts nicht wirklich Konkurzenz (imo).

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

  14. #29
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmm...

    Das einzige was dich motiviert ist dass es jemand anderes gibt der droht es besser zu machen als du
    Naja, auf jeden Fall funktioniert das sowohl bei Scribus als auch bei K3b bestens - und bei beiden gibts nicht wirklich Konkurzenz (imo).
    Vielleicht, vielleich auch nicht. Bei den Klassikern diesbezüglich (Editoren, DEs, etc) finde ich den Ist-Zustand gar nicht so schlecht.
    Das siehst du so. So ist es aber definitiv nicht.
    Da enststeht doch keine Konkurrenz, warum sollte man sich anstrengen?
    Das ganze bezieht sich auch Programme - nicht auf Laufzeitbibliotheken/-umgebungen.
    Bei Programmen schadet Konkurenz nie, solange es nicht tonnenweise verschiedenste Dateiformate etabliert werden, welche natürlich dann nicht kompatibel sind.

    Bei Laufzeiumgebungen sehe ich das etwas anders:
    Die einen Programme wollen Mono, die anderen Portable.NET und wieder andere wollen Parrot, Java und Python nicht zu vergessen.
    Ja, dann gibts Konkurrenz, aber das ist nur schlecht, zudem anscheinend sich die Laufzeitumgebungen gegenseitig nicht anstacheln, so ist das jedenfalls bis jetzt.

    Dann muss man 6 verschiedene Laufzeitumgebungen installieren und das Ziel des ganzen, eine einheitliche Laufzeitumgebung zu schaffen, welche endlich mit den Abhängigkeiten und den verschiedensten ABIs aufräumt, ist dahin.

    Der Status-Quo ist unter Linux ja schon gegeben: GTK+ (besteht aus gtk, gdk, atk, pango, glib), QT (1.x, 2.x, 3.x nicht komatibel), glibc-2.2/2.3 (natürlich auch nicht kompatibel), libstdc++ (in allen möglichen versionen) ...
    Tonnenweise shared libs die im Grunde alle das selbe machen und feinerweise natürlich nicht kompatibel sind.
    Geändert von Lin728 (20-08-2017 um 20:42 Uhr)

  15. #30
    Registrierter Benutzer Avatar von peschmae
    Registriert seit
    14.03.2002
    Ort
    Schweizland
    Beiträge
    4.549
    Zitat Zitat von ceisserer
    Ja, dann gibts Konkurrenz, aber das ist nur schlecht, zudem anscheinend sich die Laufzeitumgebungen gegenseitig nicht anstacheln, so ist das jedenfalls bis jetzt.
    Ein bisschen schon. Nur reagiert Sun imo sehr lahm auf die Herausforderung von Microsoft (Naja, generics gibts mittlerweile immerhin).

    Dann muss man 6 verschiedene Laufzeitumgebungen installieren und das Ziel des ganzen, eine einheitliche Laufzeitumgebung zu schaffen, welche endlich mit den Abhängigkeiten und den verschiedensten ABIs aufräumt, ist dahin.
    Da magst du recht haben.
    Aber nur eine einzelne fände ich u.U. auch kritisch - du willst etwas was die nicht kann. Pech gehabt.

    MfG Peschmä
    The greatest trick the Devil ever pulled was convincing the world he didn't exist. -- The Usual Suspects (1995)
    Hey, I feel their pain. It's irritating as hell when people act like they have rights. The great old one (2006)

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •