Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
OT@Flash: Doppelpunkte werden in Unixen bei Pfadangaben gerne verwendet, um mehrere mögliche Pfade abzutrennen. Beispielsweise in der PATH-Variable (wo Ausführbare Dateien gesucht werden), steht bei mir folgendes (verkürzt): /usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/horazont/bin
d.h. er sucht erst in /usr/local/bin, dann in /usr/bin, dann in /bin usw., bis er das entsprechende gefunden hat.
greetings
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,
ich habe noch ein Ant-Skript angefertigt, dann wäre das Start-File zumindestens auch plattformunabhängig
Was mich wundert ist, das noch die alte 1.1.1 Jogl-Version benutzt wurde. Ist der Benchmark eigentlich schon irgendwo im SVN-Repository auffindbar?
Viele Grüße dj3hut1
P.S.: der Parameter "Djava.library.path" ist übrigens nur dafür da, daß die Native Libraries gefunden werden, nicht für die Jars ( die müssen nur im Klassenpfad sein ), also theoretisch könnte der Pfad zu der xmlBeans-Bibliothek dort rausgenommen werden.
_________________ Wenn Gauß heute lebte, wäre er ein Hacker. Peter Sarnak, Professor an der Princeton University
Zuletzt geändert von dj3hut1 am Fr Apr 09, 2010 21:09, insgesamt 1-mal geändert.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Wenn ich das richtig verstehe dann haben wir jetzt: - Windows Support (getestet von Flash) - Mac (intel) Support (getestet von damadmax) - Plattformunabhängigen Starter auf ANT Basis (von dj3hut1 - getestet auf ?????)
Es fehlt noch ein Nachweis für Linux...damit hätte ich nicht gerechnet.
Im Repository ist der Benchmark noch nicht, da er erst getestet werden sollte und die Startscripte inkl. beschreibung ergänzt werden sollten.
Wegen JOGL - die Frage ist, ob die neue JOGL Version kompatibel ist. Ansonsten muss man nochmal den Code anpassen.
Am Benchmark fehlt außerdem noch das Feature die Hardware auszulesen.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Code:
===<Start DGL Benchmark>============== Checking Parameters.... Found 1 parameter -> Using benchmark.conf as config file Create Window for Benchmark Exception in thread "main" java.lang.UnsatisfiedLinkError: no gluegen-rt in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1678) at java.lang.Runtime.loadLibrary0(Runtime.java:840) at java.lang.System.loadLibrary(System.java:1047) at com.sun.gluegen.runtime.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:102) at com.sun.gluegen.runtime.NativeLibLoader.access$000(NativeLibLoader.java:51) at com.sun.gluegen.runtime.NativeLibLoader$1.run(NativeLibLoader.java:70) at java.security.AccessController.doPrivileged(Native Method) at com.sun.gluegen.runtime.NativeLibLoader.loadGlueGenRT(NativeLibLoader.java:68) at com.sun.gluegen.runtime.NativeLibrary.ensureNativeLibLoaded(NativeLibrary.java:399) at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:163) at com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:129) at com.sun.opengl.impl.x11.DRIHack.begin(DRIHack.java:109) at com.sun.opengl.impl.x11.X11GLDrawableFactory.<clinit>(X11GLDrawableFactory.java:99) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:186) at javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111) at javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520) at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:131) at javax.media.opengl.GLCanvas.<init>(GLCanvas.java:90) at com.delphigl.dglbenchmark.DglBenchmarkMain.<init>(DglBenchmarkMain.java:78) at com.delphigl.dglbenchmark.DglBenchmarkMain.main(DglBenchmarkMain.java:52)
bekomme ich beim Ausführen von damadmax' Script. Irgendwelche Dependencies, die ich installieren sollte? Eine Suche in den Repos ergab weder für gluegen-rt noch für jogl einen Treffer …
greetings
ps:
Flash hat geschrieben:
Es fehlt noch ein Nachweis für Linux...damit hätte ich nicht gerechnet.
Meinerseits ist da mangelndes Interesse an einem Java-Benchmark und mangelnde Zeit / Motivation, etwas in Pascal zu implementieren, schuld
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Nachdem ich das Archiv jogl-1.1.1-linux-amd64-Archiv entpackt, den Inhalt des Unterordners lib in das Verzeichnis des Startskriptes kopiert und außerdem im Startskript den $LIBRARY_PATH angepasst hatte, sah das ganze dann so aus wie im Anhang. Soll das so? Sieht reichlich merkwürdig aus … Außerdem kommt beim Ändern der Fenstergröße immer ein
Code:
[GLEventListener.reshape] Leere Methode gerufen.
im Terminal (und das Bild bleibt gleichklein, der neue Fensterbereich wird nur von Schwarz erschlossen).
Sieht also so aus, als wäre für Linux und MacOS auf jeden Fall jeweils ein anderes Startskript notwenig (und das mit den Libs bitte dazusagen ).
greetings
Dateianhänge:
benchmark.png [ 7.92 KiB | 7185-mal betrachtet ]
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Sa Aug 18, 2007 18:47 Beiträge: 694 Wohnort: Köln
Programmiersprache: Java
Der Test scheint wohl auf ein Resize zu warten. Wenn man das Fenster häufig in der Größe ändert kommt er auch mal zum Ende. Auf meiner Windows Kiste tut er das nicht.
_________________ Es werde Licht. glEnable(GL_LIGHTING); Und es ward Licht.
Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
Registriert: Di Dez 27, 2005 12:44 Beiträge: 393 Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,
das Build-File wurde von mir unter Windows und Linux getestet. Unter Ubuntu scheint sich auch bei mir das Fenster nicht von alleine zu schließen. Wenn man es selbst schließt werden keine XML-Dateien erzeugt.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Auch wenn mich die Richtung in die diese Diskussion geht (Benchmark und Java sind für mich ein absolutes No-Go, und der ganze Shellkram hier *hust*) wollt ich nur mal nebenbei anmerken dass wir "früher" schonmal an nem DGL-Benchmark gearbeitet haben und es da sogar was lauffähiges mit (wenn ich nicht irre) DLL-Support von LarsMiddendorf gab.
Warum wird eigentlich nicht darauf aufgebaut, statt jetzt sowas unendlich kompliziertes in einer Sprache zu machen die fast die komplette Userbase aussperrt? Der im internen Link gepostet Source von Lars lässt sich übrigens noch kompilieren und es ist ein Beispielmodul dabei dass eine Test-DLL kompiliert die dem Benchmark ein FPS-Ergebnis zurückliefert.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich schreib mir hier echt noch die Finger wund: Der Benchmark ist NICHT in Java geschrieben. Der Benchmark existiert nur als Spezifikation und es soll dann Implementationen für verschiedene Sprachen geben. Ich hab absolut nichts dagegen, wenn hier jemand eine Delphi/Pascal Variante davon schreibt. Die Spec macht keine Annahmen über Fähigkeiten von Sprachen.
Wenn der Code von Lars funktioniert, dann kann man den ja so umbauen, dass er der Spec entspricht und schon haben wir eine zweite Referenzimplementierung. Anstatt einzelnen JARs hat man dann halt einzelne DLLs.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
Es geht mir auch eher darum dass wir damals (Ende 2003!) bereits ein laufendes Framework hatten, und dort via DLL eigentlich in jeder Programmiersprache Module erstellt werden können. Und dies hat auch prima funktioniert (die Testmodule haben bereits FPS und sogar nen Screenshot zurückgegeben), es gab Interesse, zwei (oder evtl.) mehr Chatabende zu dem Thema etc. Daher versteh ich nicht warum jetzt wieder alles komplett neuaufgezogen wird statt auf dem alten Benchmark (dem ja letztendlich nur die DB-Andindung, dank Delphi aber ein Klax, sowie eine hübsche GUI fehlen).
Denn die neue Idee mit der Implementation in verschiedenen Sprachen sagt mir nicht wirklich zu, zumal ich beim alten Benchmark rege mitdiskutiert, gewerkelt hab. Was bringt eine OpenGL-Benchmarkimplementation in verschiedenen Sprachen? Das macht die Sache doch unübersichtlich, da so doch auch die Performance der Programmiersprache teilweise in die OpenGL-Benchmarks einfliesst, was ja nicht sein soll. Denn durch die Performanceunterschiede in den Sprache wäre es ja unmöglich Werte untereinander zu vergleiche bzw. würde das in der DB dann sicherlich Verwirrung stiften.
Ich will hier keinesfalls die Spezifikationen oder die Diskussion in Frage stellen (ganz im Gegenteil, find es generell toll wenn Communityprojekte angegangen werden), sondern wollte drauf hinweisen dass wir sowas bereits 2003 in Planung hatten und auch was Lauffähiges.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2621 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich muss mich da Sascha anschliessen, die Idee ein Framework für jede Sprache zu liefern ist keine gute Entscheidung. Die Resultate eines Benchmarks im vergleich mit einem anderen sind völlig nutzlos, da z.B. ein Java und C++ Benchmark so unteschiedlich ausfallen werden, aufgrund des Overhead vom JNI für OpenGL, GC und einiges mehr, ganz zu schweigen von den Compileroptimierungen. Es gibt eine gemeinsame Basis die alle Sprachen gleich haben und wo der Code auch gleich komplex umgesetzt wird und das sind dynamische Bibliotheken. Diese werden von allen Sprachen in die gleiche ABI von C zusammen geführt und machen Test zwischen verschiedenen Sprachen wesentlich sinnvoller. Ob nun das Benchmark Framework selber in Delphi,FreePascal, Java, c#, swing, scala, c++ oder einer anderen sprache geschrieben ist ist nebensächlich. Da eine in Delphi schon existent ist , würde ich eher dazu tendieren dieses in Freepascal mal unter Windows, Linux und MacOSX zu testen und wenn nötig zu erweitern.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Hmmm... was soll ich dazu sagen.... die Diskussion hier läuft auch nicht erst seit gestern.
Verschiedene Sprachen hätten noch den Effekt, dass man ungefähr die Performanceverluste durch die Sprachen messen kann.
Ist mir eigentlich auch egal wenn das hier alles verworfen wird. Was ich will ist, dass endlich ein DGL Benchmark zur Verfügung steht und dieser auch genutzt wird. Meine Javaimpl. hat den Vorteil, dass sie extrem simpel erweitert werden kann. Einfach ein Jar in einen Ordner kopieren und ein Configfile erweitern - fertig.
Ich für meinen Teil habe noch nie DLLs geschrieben - mal schnell einen Benchmark wird man da von mir also nicht sehen. Aber wenn andere das rege nutzen, fände ich das sehr gut.
Dann sollte man den DLL Benchmark mal so erweitern, dass er die Hardware ausließt und eine Ausgabe wie die laut spec liefert, so dass man die Benchmarkergebnisse sammeln könnte.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
was ich mich bei dem ganzen Benchmark Geschichten immer frage ist.. wozu ist das alles gut?
Ich meine, wenn ich den Geschwindigkeits unterschied zwischen Triangles und Triangle-Strips wissen will bau ich mir das kurz in meinem Programm/Engine/Spiel/WasAuchImmer ein und teste es direkt am lebenden Objekt.
Für so einen Testfall dann extra ein externes Tool hernehmen um dafür ein Plugin zu schreiben wäre mir viel zu aufwändig, zumal ich dann wenn sich herausgestellt hat das Variante B schneller ist ich das ganze nochmal bei mir in der Engine implementieren muß.
Und, das ganze dann als DLL zu verteilen bringt auch recht wenig, denn wenn bei mir Variante B schneller ist als A, wird das tendenziell bei jedem so sein.. also wozu muß jeder das nochmal Benchmarken?
Das einzige was es halt als sinnvollen Benchmark meiner Meinung nach gibt sind dinge wie "Wieviele Trianlges kann Grafikkarte XYZ pro sekunde verarbeiten", "Wie viel FPS bekommt man mit Fullscreen Shading bei Grafikkarte XYZ" etc.
Aber auch die Tests sind wieder recht irrelevant für die allgemeinheit und eher ansprechend für den einzelnen zum sehen wie toll seine Grafikkarte ist
Mitglieder in diesem Forum: 0 Mitglieder und 29 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.