ist reif für die Insel Java. JavaScript im Browser ist eine wahre Freude an Tempo im Gegensatz zu Applets. Es gibt einen netten Emulator für mobile Websites, wo ein Handy simuliert wird. Heißt mobilokchecker oder so. Der IE hat 200 MB Ram eingenommen, bevor kapituliert hat. Der Firefox war glaube ich bei 500 und hat kapituliert. In Opera lief das Teil dann halbwegs flüssig.
Java Applets lassen sich im übrigen auch auf performance programmieren ;)
Leider haben die meisten keine Lust dazu.
Das ist so die Universalausrede. Angeblich kann kein einziger auf der Welt richtig Java programmieren, da ja alle Programme davon langsam sind.
Mit "alle" meinst Du welche Anwendungen?
Mal andersrum gefragt:
Welche (bis zum jetzigen Zeitpunkt) real existierende, in Java geschriebene Anwendung läuft denn flüssig?
Äh hallo? JSPs sind auch Java und wenn du dich mal im Banken und Versicherungsumfeld umschaust läuft das dort auch. Ohne Performanceprobleme.
Erzählt doch nicht soviel Unsinn. Ich habe mal vor Jahren einen C&C 1 Klon als Java Applet geschrieben, der lief damals auf meinem alten System schon richtig flüssig. Es gibt eine Menge Firmen die ihre gesamte Software mit Java entwickeln lassen.
Kein Wunder, dass wir ne Bankenkrise haben.. :-D
Nee, Spaß beiseite. Aber Javaanwendungen sind schon langsamer als C++ oder ähnliches (Vorausgesetzt natürlich bei gleichem Optimierungsgrad des Quellcodes)
Super, viel kombiniertes Halbwissen.
Die JVM ist die wohl am weitesten entwickelte Stack-basierte VM. Sie optimiert einzigartig und ist in vielen Fällen schneller als ein optimiertes C++-Kompilat. Sei es compiled by Intel, MS, GCC, whatever.
Die Oberfläche von Java-Anwendungen kann langsam sein, wenn man ein GUI-Toolkit wie z.B. Swing oder das darunter liegende AWT verwendet. Doch auch hier hat sich in den letzten Jahren viel getan.
Der moderne Ansatz ist, bei Oberflächen auf Toolkits wie SWT zu setzen. Oder QTJambi, was leider nicht mehr großartig entiwckelt wird. Das gesamte Eclipse-Ökosystem basiert darauf und nahezu alle modernen Architekturen haben eine auf Eclipse-basierende Entwicklungsumgebung.
Das Problem bei Swing / AWT in der Oberflächen-Renderinggeschwindigkeit liegt darin, das pro Betriebsystem eine unterschiedliche Grafik-API angebunden werden muss. Die Wahl der ursprünglichen JVM-Entwickler war, die am tiefsten gelegene API zu wählen. Also API's die Linien, Rechtecke etc. rendern. Und alle Widgets (Buttons, Panels, etc.) selbst zu rendern. So entstehen viele Schichten von Calls (20-Schichtcalls um einen Button zu renden) welche in der JVM verarbeitet werden und am Ende an die native API des Systems zum rendern weitergereicht werden. Das ist natürlich inperformant. Moderne API's wie SWT stellen eine Java-API-bridge dar. Bei SWT wird eine Bridge zum GTK-Toolkit geschaffen, welches nativ ebenfalls auf verschiedenen Systemen portiert wurde. So wird bei SWT beim Rendern eines Buttons direkt die native Klasse zum rendern des Buttons aufgerufen und der Mehrschicht-Call vermieden.
Bei Applets sieht die Sache wieder anders aus. Hier wird standardmäßig AWT verwendet. Es ist aber auch möglich SWT-Libraries per Applet auszuliefern. Das macht nur niemand, weil die nativen Libs mit ausgeliefert werden müssten. Und da gibts dann neben Security-Policy-Problemen auch Probleme mit der Downloadgröße...
Also im Web entweder Javascript verwenden. Oder als Notnagel Flash (auch eine JVM-ähnliche VM...).
Javascript (EcmaScript!) ist die Zukunftsperspektive. Demnächst kommen mit Tamarin, V8, TraceMonkey etc. die nächsten Generationen von Javascript-VM's. Teilweise Stack - teilweise Memory-basiert.
Es gibt keinen Grund warum Javascript in der Ausführung nicht genauso schnell sein kann wie Java, Smalltalk, oder nativ kompiliertes C++...
krymel2k10 schrieb:
--------------------------------------------------------------------------------
> Die JVM ... ist in vielen Fällen schneller als ein
> optimiertes C++-Kompilat.
Quelle / Beispiel?
> Es gibt keinen Grund warum Javascript in der Ausführung nicht genauso
> schnell sein kann wie ... nativ kompiliertes C++
Doch: eine VM verbraucht zusätzliche Ressourcen.
>Quelle / Beispiel?
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Performance
Und lies dir bitte den ganzen abschnitt durch (aber das machst du eh nicht)
>Doch: eine VM verbraucht zusätzliche Ressourcen.
http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B#Resource_management
Ach, du bist mein held. Java nimmt dir durch sein pointer management (u.a.gb zeugs) sehr viel ab. Ziel in der software entwicklung sollte es sein, schnell zu entwickeln, überall laufen, sicher und performant. Und weil deine 3d games in c++ sind... ach, ich hab keinen bock
mi san trob schrieb:
--------------------------------------------------------------------------------
> >Quelle / Beispiel?
> en.wikipedia.org#Performance
>
> Und lies dir bitte den ganzen abschnitt durch (aber das machst du eh
> nicht)
Hab dir den Gefallen getan, damit du nicht noch mehr jammerst ;)
War jedenfalls verschwendete Zeit; keine konkreten Zahlen.
> - Java could potentially be faster than C++
> - Java garbage collection may have better cache coherence
> - Run-time compilation can potentially use additional information available at run-time to optimise code more effectively
Nach hieb- und stichfesten Fakten hört sich das für mich nicht an. Aber es wird noch besser:
> Static compilers can be given hints, using command-line switches or pragmas, ..., but these choices may be wrong for where and when the code is actually run.
Java ist also deswegen besser weil C++-Programmierer nicht mit dem Compiler umgehen können ...
> JIT ... allows optimization using current run-time measurements. This adds an additional runtime overhead as code is optimised, but is theoretically capable of increasing performance in processes that run for a very long time.
Sows ähnliches gibts für C++ auch, nennt sich Profile-Guided Optimization und verschwendet nicht die Zeit der Endkunden.
> Java often outperforms C++ in operations such as heap allocation and file I/O while C++ often outperforms Java in arithmetic and trigonometric operations.
Die erste konkrete Aussage; wäre die doch bloß von dir gekommen ...
Der Grund für den Performanceunterschied? Im C++ Benchmarkcode wurden weder Memory-mapped File I/O noch Allocaters für die Heap-Objekte verwenden.
> ... when C++ code is tweaked to be algorithmically comparable, overall C++ runs about twice as fast as Java.
Die nummerische Überlegenheit dürfte wohl keiner mehr abstreiten können.
> C++ allows passing objects by value to functions, which can cause significant overhead in the case that much memory must be copied or inefficient copy constructors must be called.
ByValue ist eine Option (die es bei Java für Objekte erst gar nicht gibt) und keine Pflicht. Auch hier liegt es also nicht an der Sprach sondern am Programmierer, wie performant das Programm am Schluss ist.
> >Doch: eine VM verbraucht zusätzliche Ressourcen.
> en.wikipedia.org#Resource_management
Der Overhead einer VM ist also - wie ich erwähnte - nicht vernachlässigbar.
> Ach, du bist mein held.
Das hab ich nicht nötig =)
> Java nimmt dir durch sein pointer management (u.a.gb zeugs) sehr viel ab.
Hättest die Links wohl erst mal selber lesen sollen :P
> The C++ standard permits garbage collection, but does not require it.
Ein GC muss nicht immer ein Segen sein:
http://en.wikipedia.org/wiki/Garbage_collection_%28computer_science%29#Disadvantages
> Ziel in der software entwicklung sollte es
> sein, schnell zu entwickeln, überall laufen, sicher und performant.
Off Topic; hier geht es nicht um den Prozess der Softwareentwicklung sondern um Java/C++ bzw. deren VM/Compiler.
> Und weil deine 3d games in c++ sind...
Ich werde meine Treiber, Firmwares und Anwendungen (und eventuell mal wieder ein Spiel :P) weiterhin in C++ schreiben.
> ach, ich hab keinen bock
Trotzdem danke für die Herausforderung =)
"The idea behind C++ is not to prevent bad programmers from writing bad code, but to make it possible for the reasonable ones to write superior code."
Kommentare: 170 | letzter Beitrag 15:54 Uhr
Kommentare: 94 | letzter Beitrag 26.05. 19:45
Kommentare: 74 | letzter Beitrag 18:52 Uhr
Kommentare: 70 | letzter Beitrag 18:56 Uhr
Kommentare: 58 | letzter Beitrag 18:36 Uhr
E-Mail an news@golem.de
Nach der Urteilsverkündung im Rechtsstreit zwischen Youtube und Gema fühlten sich beide Seiten als Gewinner. In Wahrheit gibt es aber nur einen Verlierer, bloggt Medienrechtsexperte Thomas Hoeren: die Gema.
Ein soziales Netzwerk für Pornografie muss seine Marke nicht an Facebook übergeben. Faceporn, ein norwegisches Unternehmen, freut sich über den Sieg vor einem kalifornischen Gericht.
Diablo 3 ist toll, sagen viele Spieler - Diablo 3 ist eine Stimulus-Response-Maschine, sagt Rainer Sigl. Der Blogger und leidenschaftliche Gamer erklärt, warum er sich Blizzards jüngstem Werk verweigert.
Renesas ist nach Elpida der zweite schwer angeschlagene japanische Chiphersteller. Renesas, das Hitachi, Mitsubishi Electric und NEC gehört, macht Verlust und will seine größte Fabrik verkaufen.
RIM soll in den kommenden Tagen erneut einen massiven Stellenabbau ankündigen. "Ich habe herausgefunden, welche Teile ich in meinem Puzzle nicht mehr benötige", sagte Firmenchef Thorsten Heins.
Ein britisches Blog will erfahren haben, dass Facebook den norwegischen Browserhersteller Opera Software kaufen will. Beide Unternehmen wollen sich dazu nicht äußern.