Archiv verlassen und diese Seite im Standarddesign anzeigen : Warum ist Java so langsam, speicherfressend und unflexibel?
Bitte nur sachliche Beiträge!
weil java interprediert wird zur laufzeit.
del_4901
2006-03-11, 13:41:00
also flexibel ist es, das muss man java lassen!
Das mit dem Speicherbedarf liegt wohl am Copygarbagecollector. Außerdem hat jede Referenz auch ein bissel Overhead.
Aber langsam ... naja da spalten sich die Geister, aber das sollen die Java Fetischisten dir erklären.
Weil es in C geschrieben ist.
Omnicron
2006-03-11, 13:47:33
Weil die Windows Version so schlecht ist, bzw. Probleme mit manchen Grafikkarten hat.
Kann bitte mal ein Moderator hier den Müll sofort schließen?
Shink
2006-03-11, 13:57:15
Speicherfressend: Weil es beim Start eine gewisse (einstellbare) Menge an Speicher alloziiert, damit das erzeugen von neuen Objekten dann schneller geht (Heapsize).
Unflexibel: Hmm, was genau meinst du damit?
@Omnicron: Naja, eigentlich ist die Windows-Version noch die schnellste was Grafik betrifft.
Hört doch bitte auf auf so nen Müll zu antworten...
del_4901
2006-03-11, 14:00:04
Hört doch bitte auf auf so nen Müll zu antworten...
ey spam nicht soviel sonnst kriegst du wieder nen Punkt ^^
Ja is doch wahr. Don't feed the Troll. Dass das manche nie lernen...
HajottV
2006-03-11, 14:16:26
Bitte nur sachliche Beiträge!
Nuja, dann sollte man aber den Titel nicht so reißerisch "gestalten".
langsam: Ge-JIT-teter Java-Code ist langsamer als nativer Code eines gut optimierenden Compiler (bei gleichem Algorithmus), das ist schon so. Allerdings sind die Unterschiede sooo riesig nicht.
speicherfressend: Das ist ein Nachteil des Garbage Collectors - der räumt die Objekte halt nicht immer sofort weg, so daß Java-Applikationen durchaus speicherintensiver sind als Sprachen, bei denen man die Objekte selber freigeben muß. Das ist allerdings ein kleiner Preis dafür, daß man (sofern man nicht ganz blöde Sachen macht) keine Memoryleaks mehr hat und auch keine hängenden Pointer (wie in C).
unflexibel: also das stimmt nun mal gar nicht. Ich kenne keine Sprache, die so flexibel einsetzbar ist wie Java.
Gruß
Jörg
unflexibel: weil wichtige features aus c++ fehlen
Das ist allerdings ein kleiner Preis dafür, daß man (sofern man nicht ganz blöde Sachen macht) keine Memoryleaks mehr hat und auch keine hängenden Pointer (wie in C).Also ich hab auch so keine Speicherlecks :tongue:
unflexibel: also das stimmt nun mal gar nicht. Ich kenne keine Sprache, die so flexibel einsetzbar ist wie Java.C++/C#?
Jede Methode der Speicherverwaltung hat seinen Preis, manuelle Speicherverwaltung vor allem beim Programmieraufwand, GC vor allem beim Speicherverbrauch.
minos5000
2006-03-11, 15:33:06
C++/C#?
Aber nur, wenn man beide zusammennimmt.
Man denke nur an J2EE, J2SE, J2ME, JSP, J-Script... hab ich was vergessen?
Also JavaScript hat nichts mit Java zu tun falls du das meintest!!!!1
MeLLe
2006-03-11, 17:43:06
Man denke nur an J2EE, J2SE, J2ME, JSP, J-Script... hab ich was vergessen?
Das sind aber alles nur Ausprägungen, die Sprache selbst ist in allen Fällen einfach immer noch Java. (bis auf J-Script, das ist modernes Batch-Scripting =))
Und dann müssten wir auch CppEE, CppSE, CppME, CppSP gelten lassen ...
Monger
2006-03-11, 20:08:47
Speicherfressend: Weil es beim Start eine gewisse (einstellbare) Menge an Speicher alloziiert, damit das erzeugen von neuen Objekten dann schneller geht (Heapsize).
Richtig. Das ist ja auch nachvollziehbar: lieber etwas freien (!!!) RAM opfern, und dafür mehr Performance bekommen. Ungenutzter RAM Speicher ist nunmal eine verschwendete Ressource.
Man muss sich langfristig abgewöhnen, Programme in festen Speichergrößen messen zu wollen. Jeder gute Garbage Collector sollte idealerweise erst dann aufräumen, wenn wirklich wieder Speicher benötigt wird, und nicht etwa vorher.
SimonX
2006-03-11, 20:45:39
Java ist zur Zeit half so schnell wie C++/C. Wo C 5.5M drystones schaft, da schaft Java 1.9M. Ist ja eigentlich nicht schlecht.
Der Grund warum Java sich fast überall so langsam "anfühlt" ist, das die normalen Java-Programmer nicht eben das programmieren was sie brauchen. Nein sie greifen auf irgenden ein "standard" Framework zurück, das die benötigte Funktionalität zu sagen wir mal 90% abdenkt und noch 2000% andere Sachen bietet, die man aber garnicht braucht.
Auch denke ich, das bei normalen Java-Programmieren extrem Objecttrashing gemacht wird. Es ist ja in Java so einfach.
BTW: Java hat doch Pointer, genauso wie C++/C nur das sie gestripped sind! Man legt ja Objekte mit "new" an. Und die Java-Gemeinde ist so stolz, das es jetzt typesafe Enum gibt. Etwas, das es schon seit Macro-Assembler gibt und seit C++ auch typesafe ist. Java ist schon zum Teil ein Hype, denn die Arbeit und der Code haben sich eigentlich nicht geändert. Guter Java-Code/Java-Class-Design sieht genauso aus wie guter C++ code/C++-Class-Design. Schlechter Java-Code/Java-Class-Design sieht schlechter C++ code/C++-Class-Design oder wie mittelmässiger C-Code/C-API-Design aus. Das tut sich nicht viel.
SimonX
2006-03-11, 20:50:09
BTW: In Java werden immer häufiger Code-Generatoren benutzt, die die Anwendung dann schon sehr unfexibel machen. Z.B. für XML-Class mapping. Nur weil die Standard-XML-Parser so langsam sind. Es scheint fast Keinen zu geben, der die mal optimiert.
Unfug
2006-03-11, 20:57:42
Diese virtuellen Maschinen sind einfach nur lahm, dafür wahrscheinlich aber auch sicherer (ACHTUNG VERMUTUNG!) als C/C++ , falls mal was abstürzt.
Das gleiche Phänomen kann man auch bei .NET 2 beobachten. Das ist ja eigentlich das Java von Microsoft und hat ebenfalls so eine virt. Maschine. Die Programme sind ähnlich langsam.
Zusätzlicher Kommentar:
Ich muss mit Java , wegen Studium, programmieren fand den Einstieg in die Programmierwelt aber deutlich einfacher durch Java als die ersten Gehversuche mit C.
Kenner von der Materie
2006-03-11, 21:08:52
Theoretisch kann Javabytecode schneller ausgeführt werden weil viele Optimierungen zur Laufzeit stattfinden können, im Moment ist es aber noch net so weit.
Seraf
2006-03-11, 21:09:30
Das gleiche Phänomen kann man auch bei .NET 2 beobachten. Das ist ja eigentlich das Java von Microsoft und hat ebenfalls so eine virt. Maschine. Die Programme sind ähnlich langsam.
*lol*
Du vergleichst ein Framework mit einer Programmiersprache.
Man kann sicher auch Programme mit Java Syntax für .Net schreiben wenn es einen Compiler gibt der Java in CIL wandelt.
J# ist praktisch nichts anderes.
Monger
2006-03-11, 22:03:46
Ich bin wirklich mal auf Vista gespannt. Dort soll ja das .NET Framework ziemlich kernelnah eingebettet sein - und dementsprechend schnell sein.
Vielleicht hören sich dann mal die Diskussionen auf, dass eine virtual machine per se langsamer ist als nativer Maschinencode.
Kernelnah? Das klingt ja schon förmlich nach Sicherheitslücke, deshalb wage ich das mal zu bezweifeln.
Expandable
2006-03-11, 22:25:53
Jeder gute Garbage Collector sollte idealerweise erst dann aufräumen, wenn wirklich wieder Speicher benötigt wird, und nicht etwa vorher.
Das hat aber auch massive Nachteile. Denn wenn der GC so lange wie möglich wartet, muss er dann auch extrem viel machen. So ein System wäre für Spiele und jede andere Echtzeitanwendung schlichtweg unbrauchbar. Es darf einfach nicht vorkommen, dass die fps total einbrechen, nur weil der GC jetzt meint, mal aufräumen zu müssen...
Kabelsalat
2006-03-11, 22:51:04
Das gleiche Phänomen kann man auch bei .NET 2 beobachten. Das ist ja eigentlich das Java von Microsoft und hat ebenfalls so eine virt. Maschine. Die Programme sind ähnlich langsam.
.Net verwendet keinen (Laufzeit-)Interpreter, sondern der Zwischencode wird vor der Ausführung in Native-Code kompiliert.
à propos ähnlich langsam: Nenn doch mal bitte ein Beispiel für ein wirklich langsames Java- oder .Net-Programm. In - ich behaupte - 90% der Fälle stört die theoretisch etwas langsamere Ausführung nicht im geringsten und in zu etwa 80% wird man diese nicht einmal bemerken. Obendrein kannst du mit deinem C++ / was weiß ich was- Code auch viel Mist bauen und die Anwendung stark ausbremsen.... wenn man auf einem Framework wie .Net aufbaut, kann man mit Sicherheit davon ausgehen, dass alle Komponenten stark optimiert sind!
Siehe auch: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=4026749&postcount=8
ScottManDeath
2006-03-11, 22:57:38
Jede Methode der Speicherverwaltung hat seinen Preis, manuelle Speicherverwaltung vor allem beim Programmieraufwand, GC vor allem beim Speicherverbrauch.
In der Regel ist ein GC fixer beim allozieren, da er einfach nur den Zeiger auf das Ende des freien Speichers inkrementieren muss. Das erkauft man sich dann eben beim aufräumen. Vorteil eines GC ist aber die damit verbundene Speicherdefragmentation, insbesondere bei Serveranwendungen ist das nicht zu unterschätzen, denn irgendwann gibts halt keine Lücken mehr im Speicher, wo das 3MB Objekt reinpasst ;) Moderne GC sind auch ein bischen smarter, d.h. z.B. der .NET GC hat für "langlebige" Objekte einen eigenen Speicherbereich (vereinfacht gesagt), so dass diese bei weiteren GC Läufen nicht umhergeschubst werden müssen, da die Wahrscheinlichkeint recht groß ist, das diese Objekte weiterhin genutzt werden.
Kernelnah? Das klingt ja schon förmlich nach Sicherheitslücke, deshalb wage ich das mal zu bezweifeln.
Ihr könnt ja mal die Paper lesen, über Microsofts Singularity, einem Forschungsbetriebssystem. Die nutzen einen C# Verschnitt eine Art .NET runtime und, aber im Kernelmodus, wo auch alle anderen Programme laufen. Das funktioniert deswegen, da sie die Programme statisch verifizieren, so das eben bekannt ist, das das Programm "kosher" ist. Darauf aber nun auf Vista zu schließen, halte ich für recht gewagt ;)
Theoretisch kann Javabytecode schneller ausgeführt werden weil viele Optimierungen zur Laufzeit stattfinden können, im Moment ist es aber noch net so weit.
Mhmm, das Compiler Frontend ist immer noch wichtig. Z.B. macht der C++/CLI Compiler fast das "volle Programm" an Optimierungen, die der C# Compilier nicht macht. Dadurch sind C++/CLI Programme in der Regel deutlich schneller als C# Programme, trotz des selben JIT Compilers. Der JIT Compiler kann eben nur eine gewisse Anzahl and Optimierungen ausführen, da er eben die Zeitanforderungen erfüllen muss.
Kabelsalat
2006-03-11, 23:24:13
Mhmm, das Compiler Frontend ist immer noch wichtig. Z.B. macht der C++/CLI Compiler fast das "volle Programm" an Optimierungen, die der C# Compilier nicht macht. Dadurch sind C++/CLI Programme in der Regel deutlich schneller als C# Programme, trotz des selben JIT Compilers. Der JIT Compiler kann eben nur eine gewisse Anzahl and Optimierungen ausführen, da er eben die Zeitanforderungen erfüllen muss.
Der MIL-Code ist der selbe - egal, ob du C#, VB.Net, C++ (nicht native) oder sonst eine .Net-Sprache verwendest!
ScottManDeath
2006-03-12, 00:24:51
Der MIL-Code ist der selbe - egal, ob du C#, VB.Net, C++ (nicht native) oder sonst eine .Net-Sprache verwendest!
Klar, es kommt bei alleb MSIL Code raus, aber mit unterschiedlicher Qualität ;)
SimonX
2006-03-12, 01:25:03
Obendrein kannst du mit deinem C++ / was weiß ich was- Code auch viel Mist bauen und die Anwendung stark ausbremsen.... wenn man auf einem Framework wie .Net aufbaut, kann man mit Sicherheit davon ausgehen, dass alle Komponenten stark optimiert sind!
Tja, du kannst genau so viel Mist in Java machen. Memoryleaks gibts auch in Java (dangling pointer ... referenzen nicht zurück gesetzt) und von schlechten Code ist Java erst recht nicht geschützt. Vielleicht kannst du das Programm nicht zum Absturz bringen aber NULL-Pointer Exceptions sind ja gang und gebe bei schlechtem Java-Code.
Was ich ganz speziell bei Java vermisse sind die Debugmöglichkeiten. Wenn man ein System in Betrieb hat, dann läuft kein Debugger neben her, der anzeigen kann was eigentlich los ist. Der Exception-Trace ist absolut nicht vergleichbar mit einem Core-File von einem normalen C/C++/Fortran/... Programm. Dort kann man sich über die Situation im Core informieren. Über jede lokale Variable in irgendeiner Methode die auf dem Weg zum Core benutzt wurde. Ich muss mal den GNU Java-Compiler ausprobieren. Vielleicht liefert der echte Cores anstatt der nutzlosen Exception-traces.
ScottManDeath
2006-03-12, 03:12:27
Tja, du kannst genau so viel Mist in Java machen. Memoryleaks gibts auch in Java (dangling pointer ... referenzen nicht zurück gesetzt) und von schlechten Code ist Java erst recht nicht geschützt. Vielleicht kannst du das Programm nicht zum Absturz bringen aber NULL-Pointer Exceptions sind ja gang und gebe bei schlechtem Java-Code.
Japs, man muss genauso aufpassen.
Was ich ganz speziell bei Java vermisse sind die Debugmöglichkeiten. Wenn man ein System in Betrieb hat, dann läuft kein Debugger neben her, der anzeigen kann was eigentlich los ist. Der Exception-Trace ist absolut nicht vergleichbar mit einem Core-File von einem normalen C/C++/Fortran/... Programm. Dort kann man sich über die Situation im Core informieren. Über jede lokale Variable in irgendeiner Methode die auf dem Weg zum Core benutzt wurde. Ich muss mal den GNU Java-Compiler ausprobieren. Vielleicht liefert der echte Cores anstatt der nutzlosen Exception-traces.
Mhmm, in .NET steppe ich mit dem Visual Studio ganz normal durch den Code durch, kann mir alles ansehen. Ich kann mir das gar nicht so richtig vorstellen, dass Java das nicht auch kann.
Xanthomryr
2006-03-12, 04:37:07
*lol*
Du vergleichst ein Framework mit einer Programmiersprache.
Was ist denn da der Unterschied bzw was ist eigentlich ein Framework genau?
Das Java-(Negativ-)Beispiel par excellance ist doch Eclipse: Lahm und speicherfressend. Das kann man nicht mal mit einem HighEnd-PC ordentlich benutzen.
Wenn ihr mal sehen wollt, wie man mit C++ sauber designed (sauberer, als es mit Java ginge, wegen templates etc.), seht euch mal OGRE (www.ogre3d.org) an!
Seraf
2006-03-12, 09:33:55
Was ist denn da der Unterschied bzw was ist eigentlich ein Framework genau?
Auf der Java VM kannst du nur Java laufen lassen. Im .Net Framework kannst du durch CLI (Common Language Infrastructure) viele Sprachen benutzen. Du brauchst nur einen Compiler der dir deinen Code in CIL (Common Intermediate Language) übersetzt.
Die .NET-Plattform stellt mit der Common Language Infrastructure (CLI) eine Basis zur Ausführung von Programmen, die mit unterschiedlichen Programmiersprachen erstellt wurden, her. Dies wird durch die Verwendung einer (objektorientierten) virtuellen Maschine und die Framework Class Library (FCL) – einer gemeinsamen Klassenbibliothek – erreicht.
http://de.wikipedia.org/wiki/.NET_Framework
Aqualon
2006-03-12, 09:49:48
Auf der Java VM kannst du nur Java laufen lassen. Im .Net Framework kannst du durch CLI (Common Language Infrastructure) viele Sprachen benutzen. Du brauchst nur einen Compiler der dir deinen Code in CIL (Common Intermediate Language) übersetzt.Das funktioniert bei Java aber genauso, wenn du einen Compiler hast, der dir Java byte code erzeugt (wie z.B. Jython (http://www.jython.org/) für Python).
Aqua
Kabelsalat
2006-03-12, 10:12:22
Klar, es kommt bei alleb MSIL Code raus, aber mit unterschiedlicher Qualität ;)
Wage ich zu bezweifeln (zumindest was die MS-Compiler angeht)... momentan habe ich zwar keine Quellen parat, die meine Meinung belegen, aber drehen wir den Spieß doch um: Beleg du deine These :tongue:
Kabelsalat
2006-03-12, 10:32:01
Ich habe nun eine paar Tests gefunden:
http://www.grimes.demon.co.uk/dotnet/man_unman.htm
Lest den Text und werft dann einen Blick auf die Tabelle: Den Unterschied zwischen den verschiedenen Managed-Code-Compilern kann man vergessen.
PS: Ist auch für die Warum ist ... so langsam, speicherfressend und unflexibel? - Verfechter lesenswert!
Ihr könnt ja mal die Paper lesen, über Microsofts Singularity, einem Forschungsbetriebssystem. Die nutzen einen C# Verschnitt eine Art .NET runtime und, aber im Kernelmodus, wo auch alle anderen Programme laufen. Das funktioniert deswegen, da sie die Programme statisch verifizieren, so das eben bekannt ist, das das Programm "kosher" ist. Darauf aber nun auf Vista zu schließen, halte ich für recht gewagt ;)Ja kenne ich. Das ist trotzdem großer Schwachsinn weil es keinen fehlerfreien Code gibt. Es ist absoluter Wahnsinn Programme im Kernelmode laufen zu lassen.
Außerdem sehe ich keinen großen Grund warum ein JITC im Kernelmode soviel schneller sein sollte.
ScottManDeath
2006-03-12, 12:06:32
Naja, ne FFT ist nun nicht unbedingt das Maß der Dinge als Benchmark, da es nur ein kleiner Code Schnipsel ist, und man da nicht viel optimieren kann, bzw die "trivialen" Optimierungen ausreichen.
Interessanter wird es, wenn man größere Programme vergleicht. Wenn ich mal Zeit habe, bau ich eine C# -> C++/CLI Crosscompiler, dann kann ich meinen Raytracer portieren, der z.Z ca. 4 bis 8 mal langsamer ist, als entsprechende native C++ Raytracer meiner Mitstudenten.
Ich finde den MSDN Artikel gerade nicht :( Aber z.b kann der C++ Compiler Whole Program Optimiziation und er schmeißt gnadenlos Code raus, der nicht aufgerufen wird.
Demirug
2006-03-12, 12:12:23
Ja kenne ich. Das ist trotzdem großer Schwachsinn weil es keinen fehlerfreien Code gibt. Es ist absoluter Wahnsinn Programme im Kernelmode laufen zu lassen.
Fehlerfrei nicht aber Fehlertolerant. Das Projekt hat ja auch ein anderes Ziel. Man will damit untersuchen in wie weit Managed Code für einen OS-Kern taugt und was ich gehört habe sollen einige der Windows Kernel Entwickler schon großeses interesse gezeigt haben. Vorallem aus dem Lager der 3dParty Treiber Unterstützung soll positives Feedback gekommen sein.
Außerdem sehe ich keinen großen Grund warum ein JITC im Kernelmode soviel schneller sein sollte.
Da wird durch gar kein JITC benutzt.
Es ging ja darum, dass in Vista die .NET-Programme auf einmal schneller sein sollen weil das Framework "kernelnaher" ist.
Ich glaube nicht dass da was dran ist, aber du weißt sicher mehr.
Das hat aber auch massive Nachteile. Denn wenn der GC so lange wie möglich wartet, muss er dann auch extrem viel machen. So ein System wäre für Spiele und jede andere Echtzeitanwendung schlichtweg unbrauchbar. Es darf einfach nicht vorkommen, dass die fps total einbrechen, nur weil der GC jetzt meint, mal aufräumen zu müssen...
Das ist Unsinn. Les mal wie ein moderner GC funktioniert: ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps
Die Laufzeit hängt ausschließlich von den lebendigen Objekten ab, wieviel Müll eingesammelt wird ist egal. Es stimmt allerdings, dass man bei interaktiven Anwendungen aufpassen sollte wie man Müll erzeugt, es gibt einige Muster die sind teuer und sollten vermieden werden.
Was macht eigentlich ngen.exe? Die Beschreibung im MSDN klingt so, als ob da ein "Native-Binary" AOT erzeugt und im GAC hinterlegt wird. Kann das generelle Performancevorteile bringen, oder wird dadurch nur der erste Start einer Anwendung beschleunigt?
EgonOlsen
2006-03-12, 16:08:54
Wie wäre es denn, wenn jeder der diese Java-langsam-blah-blah-Behauptungen aufstellt, mal aufzeigt, was er denn bisher so in Java gemacht hat. Dann könnten wir mal gucken, ob es wirklich so schlimm ist und evtl. helfen, es zu verbessern. Naja, und wenn er nichts diesbzgl. vorzuweisen hat, dann ist der ganze Thread sowieso Kappes und hat sich erledigt, bevor er angefangen hat.
grandmasterw
2006-03-12, 16:19:35
Das Java-(Negativ-)Beispiel par excellance ist doch Eclipse: Lahm und speicherfressend. Das kann man nicht mal mit einem HighEnd-PC ordentlich benutzen.
Also ich konnte es ordentlich benutzen, und ich hab noch nen Sockel370 Celi mit 384 MB Ram. Klar, es frisst recht viel Speicher, und auch etwas CPU-Last, aber während man am Code tippst, hat die CPU eh nix zu tun.
Wenn ihr mal sehen wollt, wie man mit C++ sauber designed (sauberer, als es mit Java ginge, wegen templates etc.), seht euch mal OGRE (www.ogre3d.org) an!
Generizität gibts seit Java 1.5.
Seraf
2006-03-12, 16:46:43
Noch ein Beispiel für ein langsames Java Program ist Poseidon:
http://www.gentleware.com/downloadcenter.0.html
Das bremst den ganzen Rechner aus bei mittleren bis großen UML Diagrammen.
Generizität gibts seit Java 1.5.Ja, aber generics != templates!
Kabelsalat
2006-03-12, 17:49:13
... und was bitteschön sind templates dann? Ich konnte bisher zumindest keinen Unterschied zwischen Generics und Templates feststellen...
del_4901
2006-03-12, 18:28:52
... und was bitteschön sind templates dann? Ich konnte bisher zumindest keinen Unterschied zwischen Generics und Templates feststellen...
Templates sind geringfügig mächtiger ... da kann man wenn man will richtig perversen Code schreiben (lassen). Aber das ist nichts was man in Jave durch eien gute Klassenstruktur nicht auch hinbekommen würde. Wobei die C++ templates natürlich sehr gut optimiert werden können, was da dann nicht der Fall ist. Wenn ich mal Zeit finde mach ich ein "perverso" Beispiel mit statischer Polymorphie.
Mit templates kann man sowas machen: http://boost.org/libs/spirit/doc/quick_start.html
Senior Sanchez
2006-03-12, 19:23:23
Was ich ganz speziell bei Java vermisse sind die Debugmöglichkeiten. Wenn man ein System in Betrieb hat, dann läuft kein Debugger neben her, der anzeigen kann was eigentlich los ist. Der Exception-Trace ist absolut nicht vergleichbar mit einem Core-File von einem normalen C/C++/Fortran/... Programm. Dort kann man sich über die Situation im Core informieren. Über jede lokale Variable in irgendeiner Methode die auf dem Weg zum Core benutzt wurde. Ich muss mal den GNU Java-Compiler ausprobieren. Vielleicht liefert der echte Cores anstatt der nutzlosen Exception-traces.
Dann sollteste dir mal Eclipse oder den JBuilder anschauen ;) Da haste dann deinen Debugger und dazu noch richtig gute. Kannst zum Beispiel dir zur Laufzeit von jeder Variablen den Wert anzeigen lassen bzw. verändern, durchsteppen wie de lustig bist, breakpoints setzen und natürlich auch zur Laufzeit Code verändern und ohne neuzustarten ausprobieren (Hot Code Replacement), was aber nicht in allen Situationen funktioniert.
Wie wäre es denn, wenn jeder der diese Java-langsam-blah-blah-Behauptungen aufstellt, mal aufzeigt, was er denn bisher so in Java gemacht hat. Dann könnten wir mal gucken, ob es wirklich so schlimm ist und evtl. helfen, es zu verbessern. Naja, und wenn er nichts diesbzgl. vorzuweisen hat, dann ist der ganze Thread sowieso Kappes und hat sich erledigt, bevor er angefangen hat.
100 % ACK!
Sicher gibts Fälle, bei denen aus Java einfach nicht mehr herauszuholen ist. Aber ich wage mal zu behaupten dass es in 80 % der Fälle möglich ist, das ganze noch zu beschleunigen.
Ich hatte mich vor einiger Zeit mal näher beschäftigt, indem ich mir das Ziel gesetzt hatte, mal soviel zu optimieren wie es nur irgendwie geht.
GUI Applikationen habe ich durch den Einsatz von Multi-Threading und intelligentem Aufbau der GUI dazu gebracht, dass die Applikation dreimal so schnell startet und der Nutzer sonst keinen Unterschied bemerkt.
Nen ganz simples Primzahl-programm dass das Sieb des Eratosthenes nutzt habe ich auch um den Faktor 2.5-3 beschleunigt, indem ich zum Teil auf Bit-Manipulationen umgestiegen bin etc.
Also wenn man will und nen guten Algorithmus voraussetzt, erreicht man mit Java beachtliche Geschwindigkeiten.
Noch zur Sache mit den Echtzeitanwendungen: Für solche Fälle gibts spezielle VMs (z.B. Jamaica) und afaik auch nen Sun JSR. Also Java taugt schon für Echtzeitanwendungen ;)
Templates sind geringfügig mächtiger ... da kann man wenn man will richtig perversen Code schreiben (lassen). Templates bilden eine Metasprache in C++ die turing complete (!) ist. Da sind Generics in Java weit davon entfernt.
Du weißt ja gar nicht was für Unsinn damit anstellen kann wenn man weiß wie ;)
(inkl. Compilerzeiten jenseits von gut und böse allerdings :D)
del_4901
2006-03-12, 19:57:57
Templates bilden eine Metasprache in C++ die turing complete (!) ist. Da sind Generics in Java weit davon entfernt.
Du weißt ja gar nicht was für Unsinn damit anstellen kann wenn man weiß wie ;)
Ich weiß worauf du anspielst! Ich hab mir neulich erst wieder von einem Freak ein solches Beispiel zeigen lassen ... oh mann sehr unschoen das ganze ... dafür auch verdammt schnell.
Gut das es TypeTraits gibt ^^
SimonX
2006-03-12, 22:22:26
Dann sollteste dir mal Eclipse oder den JBuilder anschauen ;)
Tja, aber auf der Produktionsmaschine, dort wo die echten Problem auftauchen, wirst du kein Eclipse oder JBuilder im Hintergrund laufen lassen. Denn du bist 1000 Meilen weit von der Maschine entfernt und kannst dich auch nicht einloggen. Also bleibt dir dann nur der nutzlose Exceptiontrace.
SimonX
2006-03-12, 22:23:10
BTW: Das nächste Java soll ja Templates bekommen, oder wie nennen sie es dort? Und in Java gibt es mittlerweile auch ein "delete". Wie hiess das dort? finialize?
Senior Sanchez
2006-03-12, 22:30:37
Tja, aber auf der Produktionsmaschine, dort wo die echten Problem auftauchen, wirst du kein Eclipse oder JBuilder im Hintergrund laufen lassen. Denn du bist 1000 Meilen weit von der Maschine entfernt und kannst dich auch nicht einloggen. Also bleibt dir dann nur der nutzlose Exceptiontrace.
Deswegen testet man vorher auch Software ausgiebig. Und ich finde den Stacktrace schon sehr nützlich, also oft kann ich mir dann schon zusammenreimen was da schief gelaufen ist.
Außerdem gibt es auch Logging-Mechanismen, bei denen man dann schon schnell korrupte Daten auf bestimmte Stellen eingrenzen kann.
finalize() erfüllt im Grunde eine ähnliche Funktion wie der Destruktor bei C/C++, es ist aber keine Aussage möglich, wann finalize nun aufgerufen wird. Das hängt vom GC ab.
PS: Mich würde mal interessieren wie du an deine Core-files kommen willst, wenn man sich auf dem Rechner eh nicht einloggen kann ;)
BTW: Das nächste Java soll ja Templates bekommen, oder wie nennen sie es dort? Und in Java gibt es mittlerweile auch ein "delete". Wie hiess das dort? finialize?Du meinst Generics, die gibts jetzt auch schon. "Echte" Templates sind in Java eigentlich kaum möglich, weil die immer in der gleichen Übersetzungseinheit sein müssen.
LordDeath
2006-03-12, 23:01:07
also java anwendungen sind auf jeden fall anfälliger dafür, ram zu schlucken als andere...
ich hab z.b. mit azureus kein problem. es ist schnell & stabil. also ich als endanwender sehe da ein gutes java-programm.
dann ist da noch die andere seite: das nokia series 60 themes studio 3.0 ist einer dieser kandidaten. ich hab aus einem vorgespeicherten vorschlag eine 400kb große sis datei fürs handy erstellt. knackpunkt: 400mb rambelegung, aber nur, weil ich keinen weiter speicher mehr frei hatte...
del_4901
2006-03-13, 00:23:39
also java anwendungen sind auf jeden fall anfälliger dafür, ram zu schlucken als andere...
ich hab z.b. mit azureus kein problem. es ist schnell & stabil. also ich als endanwender sehe da ein gutes java-programm.
dann ist da noch die andere seite: das nokia series 60 themes studio 3.0 ist einer dieser kandidaten. ich hab aus einem vorgespeicherten vorschlag eine 400kb große sis datei fürs handy erstellt. knackpunkt: 400mb rambelegung, aber nur, weil ich keinen weiter speicher mehr frei hatte...
:|
Mein <erster> C++ Parser hat auch 500MB gefressen ...
LordDeath
2006-03-13, 00:41:54
:|
Mein <erster> C++ Parser hat auch 500MB gefressen ...
das darf aber nicht ein programm für endbenutzter machen, was schon seit jahren draußen ist und weiterentwickelt wird. es war lahm und bleibt wohl so...
SimonX
2006-03-13, 02:14:15
PS: Mich würde mal interessieren wie du an deine Core-files kommen willst, wenn man sich auf dem Rechner eh nicht einloggen kann ;)
Per e-mail z.B. oder über ftp.
Senior Sanchez
2006-03-13, 16:40:43
Per e-mail z.B. oder über ftp.
Darüber kann man auch stacktraces oder logs austauschen.
SimonX
2006-03-18, 03:03:18
Die aber, wie schon gesagt, nutzlos sind da sie keinen richtigen Context enthalten.
Ich kann zu dem Thema nur meine Erfahrungen der letzten Zeit beisteuern. Über die Jahre hinweg habe ich an einem kleinem 3D-Demo herumgeschraubt - selbstverständlich unter C++, OpenGL und SDL zuerst unter Windows, dann unter Linux.
Vor ca. 4 Monaten bin ich auf Java JDK 1.6 Builds + JOGL umgestiegen, zuerst sehr zögerlich, weil ich immer dachte, dass es einfach langsamer sein muss. Mittlerweile sind ein klassischer Shadow Volume Algorithmus und Cascading Shadow Maps vollständig auf Java migriert - mit dem interessanten Ergebnis, dass der Geschwindigkeitsunterschied im Rahmen der Messtoleranz liegt (210 fps unter C++ und 208 fps unter Java).
Einen ganz großen Unterschied gibt es aber doch noch: Die Weiterentwicklung unter Eclipse geht soviel leichter und schneller von der Hand und macht insgesamt wieder wesentlich mehr Spaß. Hier kurz ein Refactoring, dort etwas neues ausprobieren - in C++ wäre jeder einzelne Schritt abendfüllend, was dann der Codequalität über die Jahre hinweg keine Hilfe war.
Viele Grüße,
Stefan
Kenner von eclipse
2006-03-19, 18:28:50
Einen ganz großen Unterschied gibt es aber doch noch: Die Weiterentwicklung unter Eclipse geht soviel leichter und schneller von der Hand und macht insgesamt wieder wesentlich mehr Spaß. Hier kurz ein Refactoring, dort etwas neues ausprobieren - in C++ wäre jeder einzelne Schritt abendfüllend, was dann der Codequalität über die Jahre hinweg keine Hilfe war.
Falsch, -100 Punkte!
darph
2006-03-19, 19:32:03
Einen ganz großen Unterschied gibt es aber doch noch: Die Weiterentwicklung unter Eclipse geht soviel leichter und schneller von der Hand und macht insgesamt wieder wesentlich mehr Spaß. Hier kurz ein Refactoring, dort etwas neues ausprobieren - in C++ wäre jeder einzelne Schritt abendfüllend, was dann der Codequalität über die Jahre hinweg keine Hilfe war.
Öhm... also. Ich kann ja jetzt nicht behaupten, C++ zu können, aber es würde mich irgendwie schwer wundern, wenn es keine IDEs und Refaktorisierungstools für C++ geben würde...
Vor ca. 4 Monaten bin ich auf Java JDK 1.6 Builds + JOGL umgestiegen, zuerst sehr zögerlich, weil ich immer dachte, dass es einfach langsamer sein muss. Mittlerweile sind ein klassischer Shadow Volume Algorithmus und Cascading Shadow Maps vollständig auf Java migriert - mit dem interessanten Ergebnis, dass der Geschwindigkeitsunterschied im Rahmen der Messtoleranz liegt (210 fps unter C++ und 208 fps unter Java).Logisch. Das dürfte ziemlich GPU-limitiert sein.
SimonX
2006-03-19, 21:43:45
Er sollte man die CPU-Zeit messen, die von dem Java-Programm gebraucht wird und sie direkt mit der CPU-Zeit des C++-Programms vergleichen. Dann würde er den Faktor 2-3 für das C++-Programm sehen.
Senior Sanchez
2006-03-19, 21:49:23
Er sollte man die CPU-Zeit messen, die von dem Java-Programm gebraucht wird und sie direkt mit der CPU-Zeit des C++-Programms vergleichen. Dann würde er den Faktor 2-3 für das C++-Programm sehen.
Nicht eher umgedreht?
Die java-Implementierung sollte ne höhere Last erzeugen, aber das ist doch im Grunde nebensächlich, oder? Okay, wenn man Strom sparen will vllt nicht, aber wir haben soviel Rechenleistung heutzutage zur Verfügung, also sollte man sie doch auch nutzen dürfen ;)
Noch zu dieser Aussage:
Die aber, wie schon gesagt, nutzlos sind da sie keinen richtigen Context enthalten.
Das hängt immer davon ab wie gut man die Log-Files erstellt und eins kann ich dir sagen: Egal wie bescheuert das Problem auch wahr, wir haben auf Arbeit, auch mithilfe der Log-Files und etwas nachdenken IMMER das Problem gefunden und gelöst.
Leute, die speicherfressende und lahme Programme schreiben, schreiben sie heute in Java und Leute, die schnelle und ressourcenschonende Programme schreiben, schreiben sie nicht in Java.
Vor allem deshalb sind Java-Programme lahm und speicherfressend.
Faktor 2-3 zwischen Java und C++? Könnte bei der Client-VM ungefähr hinhauen, aber ich würde die Spanne viel größer angeben, so genau wie die Zahl suggeriert ist sie nicht. Die Server-VM ist auch ab und an mal schneller als C++.
LordDeath
2006-03-20, 19:27:47
hallo? ein azureus verbraucht bei mir genauso viel wie das mit mfc programmierte emule. also SO schlecht ist java nicht, wenn man es beherrscht.
schade ist aber, dass java programme immer quelloffen sind. oder kann man das umgehen?
MadMan2k
2006-03-20, 19:32:08
naja, wenn du bytecode als quelloffen bezeichnest...
aber c++ programme kann man auch in den zustand dekompilieren...
LordDeath
2006-03-20, 19:46:32
naja, wenn du bytecode als quelloffen bezeichnest...
aber c++ programme kann man auch in den zustand dekompilieren...
wenn ich jar dateien entpacke, hab ich nur bytecode??
EgonOlsen
2006-03-20, 19:55:09
wenn ich jar dateien entpacke, hab ich nur bytecode??Ja, außer wenn du die Quellen mit hineingepackt hast.
naja, wenn du bytecode als quelloffen bezeichnest...
aber c++ programme kann man auch in den zustand dekompilieren...
Hä? Für Java gibt es Java-Quellcode erzeugende Dekompiler, für C++ nicht!
mithrandir
2006-03-21, 12:37:44
Deshalb gibt's fuer groessere Projekte gute Obfuscation-Methoden.
Kabelsalat
2006-03-21, 21:39:44
... wobei die negativen Aspekte solcher Obfuscatoren auch nicht unerheblich sind. Ich betrachte immer noch das Urheberrecht als den besten Schutz: Auch wenn sich der Code sehr gut dekompilieren lässt, ist er immer noch "meins" und darf nicht einfach so kopiert werden (ausgenommen die Lizenz lässt es zu). Sicher, die Konkurrenz kann (und wird auch wahrscheinlich) den Code als Anregung nutzen, aber das macht noch kein komplette Programm (sie dürfen den Code schließlich nicht kopieren) und obendrein wird die Produktqualität auch noch durch weitere Aspekte wie Supportqualität und Ähnlichem bestimmt.
Senior Sanchez
2006-03-21, 21:53:20
... wobei die negativen Aspekte solcher Obfuscatoren auch nicht unerheblich sind. Ich betrachte immer noch das Urheberrecht als den besten Schutz: Auch wenn sich der Code sehr gut dekompilieren lässt, ist er immer noch "meins" und darf nicht einfach so kopiert werden (ausgenommen die Lizenz lässt es zu). Sicher, die Konkurrenz kann (und wird auch wahrscheinlich) den Code als Anregung nutzen, aber das macht noch kein komplette Programm (sie dürfen den Code schließlich nicht kopieren) und obendrein wird die Produktqualität auch noch durch weitere Aspekte wie Supportqualität und Ähnlichem bestimmt.
Da ist sicherlich was dran, aber viele Programme zeichnen sich durch einzigartige Funktionen aus und wenn hier dann ein Decompiler angesetzt wird, dann war diese Funktion einmal einzigartig weil sie dann die Konkurrenz ein wenig anders, aber doch ähnlich, implementiert.
Die einzigen Nachteile von Obfuscatorn, die mir einfallen, sind einmal der Nachteil, dass sofern man nicht aufpasst, Reflection nicht mehr richtig funktioniert und halt der zusätzliche Arbeitsaufwand. Sonst haben die aus meiner Sicht aber nur Vorteile.
Godmode
2006-03-21, 22:08:16
Das war vielleicht mit Java 1.0 noch so, da war Java teilweise um den Faktor 10-20 langsamer als zb C. Mit Java 1.5 erreicht man teilweise bessere Geschwindigkeiten als mit C.
Senior Sanchez
2006-03-21, 22:09:38
Das war vielleicht mit Java 1.0 noch so, da war Java teilweise um den Faktor 10-20 langsamer als zb C. Mit Java 1.5 erreicht man teilweise bessere Geschwindigkeiten als mit C.
Ebensowenig wie ich Behauptungen wie java ist 20 mal langsamer mag, mag ich auch nicht diese von wegen es ist schneller.
Bitte mal an alle: Wenn man solche Aussagen trifft, dann bitte Beweise oder Quellen nennen, alles andere ist Mutmaßung.
Godmode
2006-03-21, 22:12:11
Ebensowenig wie ich Behauptungen wie java ist 20 mal langsamer mag, mag ich auch nicht diese von wegen es ist schneller.
Bitte mal an alle: Wenn man solche Aussagen trifft, dann bitte Beweise oder Quellen nennen, alles andere ist Mutmaßung.
Lies bitte genau: ich habe "TEILWEISE" geschrieben.
Zum beweisen, ich frag da mal meinen Prof, ob er mir den Link geben kann, der hat uns eine Folie gezeit, wo zb ein IntArray mit 10^6 Elementen sortiert wurde, ja und Java war da schneller als C.
Lies bitte genau: ich habe "TEILWEISE" geschrieben.
Zum beweisen, ich frag da mal meinen Prof, ob er mir den Link geben kann, der hat uns eine Folie gezeit, wo zb ein IntArray mit 10^6 Elementen sortiert wurde, ja und Java war da schneller als C.
Also bei einem anderen Beispiel würde ich das vielleicht glauben, aber ganz sicher nicht beim Sortieren von Integern.
Godmode
2006-03-21, 22:29:04
Also bei einem anderen Beispiel würde ich das vielleicht glauben, aber ganz sicher nicht beim Sortieren von Integern.
Könnte auch sein dass es Strings und char* waren, aber ich frag jedenfalls nach!
grandmasterw
2006-03-21, 22:44:28
Wahrscheinlich hat er mühsam nen Bubblesort hingeklatscht, und unter Java die mitgelieferte Sort-Routine verwendet, die in n log n arbeitet. ;D
Kabelsalat
2006-03-21, 22:51:25
Die einzigen Nachteile von Obfuscatorn, die mir einfallen, sind einmal der Nachteil, dass sofern man nicht aufpasst, Reflection nicht mehr richtig funktioniert und halt der zusätzliche Arbeitsaufwand. Sonst haben die aus meiner Sicht aber nur Vorteile.
Einer der Nachteile besteht darin, dass praktisch alle Verfahren mit mehr oder weniger viel Aufwand knackbar sind und / oder zusätzlicher Native Code erzeugt wird. In einer der letzten Ausgaben des dot.net Magazins stand ein Artikel zu diesem Thema - ich habe ihn zwar bloß überflogen, aber das war in etwa die Quintessenz dieses Artikels.
Senior Sanchez
2006-03-21, 23:09:33
Einer der Nachteile besteht darin, dass praktisch alle Verfahren mit mehr oder weniger viel Aufwand knackbar sind und / oder zusätzlicher Native Code erzeugt wird. In einer der letzten Ausgaben des dot.net Magazins stand ein Artikel zu diesem Thema - ich habe ihn zwar bloß überflogen, aber das war in etwa die Quintessenz dieses Artikels.
Also das erste Argument ist schonmal irgendwo blödsinnig: Alles ist knackbar, es gibt keine absolute Sicherheit.
Was verstehst du unter zusätzlichem Native Code? Afaik manipulieren viele Obfuscator den Bytecode nachträglich, sodass dieser korrekt bleibt, aber Decompiler ausm Tritt bringt, weil kein gültiger Code mehr erzeugt wird.
@bans3i
Auch wenn du teilweise geschrieben hast, widerlegt das nicht meine Aussage und ich würde weiterhin gerne Beweise sehen, bevor solche Mutmaßungen getroffen werden.
Also bei einem anderen Beispiel würde ich das vielleicht glauben, aber ganz sicher nicht beim Sortieren von Integern.Dito. Wenn er die Library-Routinen verglichen hat ists allerdings noch dämlicher, weil dann ist es eher von der LIBC abhängig X-D
, sodass dieser korrekt bleibt, ..., weil kein gültiger Code mehr erzeugt wird.
Wie kann man das verstehen?
Monger
2006-03-22, 08:56:54
Ebensowenig wie ich Behauptungen wie java ist 20 mal langsamer mag, mag ich auch nicht diese von wegen es ist schneller.
Bitte mal an alle: Wenn man solche Aussagen trifft, dann bitte Beweise oder Quellen nennen, alles andere ist Mutmaßung.
Ich hab irgendwann mal nach Benchmarks gesucht, und hab zu meinem Erschrecken nicht EIN realistisches Szenario gefunden, was mit mehreren Sprachen umgesetzt wurde. Ich glaube, es gibt einfach keine glaubwürdigen Messergebnisse.
Solche künstlichen Geschichten wie Sortieralgorithmen, große Gleitkommarechnungen etc. gehen imho doch alle weit an der Realität vorbei. Ich kann es ja leider nicht beweisen, aber ich bin mir ziemlich sicher dass in einem realen Szenario sich die größten Unterschiede eben NICHT in den Standardalgorithmen niederschlagen.
Ganon
2006-03-22, 11:24:56
Man muss halt das Gesamtprodukt sehen. Und ich denke keiner wird eine große Anwendung in mehreren Sprachen schreiben, nur damit man am Ende vergleichen kann.
Auch muss man das System kennen, auf welchem man testet. Weil unter OS X ist Java z.B. erbärmlich langsam, unter Windows schön schnell und unter Linux ist so der Mittelpunkt zwischen beiden. Gerade desshalb kann man nicht sagen "Java ist schneller als C(++)" oder halt umgekehrt.
Auch sollte man nicht vergessen, das Java viel mehr Sicherheitsfunktionen hat, wie z.B. Bereichsprüfung von Arrays, was bei C++ in den meisten Benchmarks auch fehlt.
a[3] = 10 in Java ist vom Ablauf nunmal nicht das gleiche wie a[3] = 10 in C++.
Kabelsalat
2006-03-22, 13:10:13
Also das erste Argument ist schonmal irgendwo blödsinnig: Alles ist knackbar, es gibt keine absolute Sicherheit.
Was verstehst du unter zusätzlichem Native Code? Afaik manipulieren viele Obfuscator den Bytecode nachträglich, sodass dieser korrekt bleibt, aber Decompiler ausm Tritt bringt, weil kein gültiger Code mehr erzeugt wird.
Ich hoffe es ist nicht verboten das Fazit des erwähnten Artikels zu zitieren (falls doch bitte löschen):
Möchte sich ein Software-Hersteller vor dem Zugriff Anderer auf seinen Sourcecode schützen, muss er einen erheblichen Aufwand mit fragwürdigem Ergebnis betreiben. Es gibt grundsätzlich nichts, was in der .NET-Welt nicht dekompiliert werden kann (gleiches gilt übrigens auch für die Java-Welt). Wer die Lösung in nativem Maschinencoe sieht, kann auf das Tool Ngen.exe der .NET Laufzeit zurückgreifen und sicher sein, dass ein Dekompilieren kaum noch möglich ist, muss jedoch auch alle Nachteile in Kauf nehmen, die mit der Auslieferung von nativem Maschinencode einhergehen: Für jede potenzielle Zielplattform muss ein pre-JIT-Kompilat erstellt werden, während aber die mit .NET einhergehende Hardware-Unabhängigkeit veroren geht. Obfuskatoren verschlüsseln den IL-Code einer Assembly bis zur Unlesbarkeit unerzeugen dabei einen nicht zu vernachlässigenden Performance-Impact, ohne die Software wirksam schützen zu können. [...] Der Wettlauf zwischen Verschlüsselung und Entschlüsselung kostet Zeit und Geld - folglich gibt es nur wenige Anwendungsbereiche, in denen dieser Aufwand betrieben wird und in denen er durchaus gerechtfertigt ist. Nicht ohne Grund implementieren die betroffenen Hersteller ihre Software meist in C/C++.
Microsoft hat sich aus gutem Grund dazu entschieden, die ausgelieferten Assemblies des .NET-Framwork nicht zu obfuskieren. Der Konzern hat dazu beigetragen, dass Software-Hersteller die Funktionsweise des Frameworks und seiner interenen Struktur besser verstehen können. Nicht zuletzt ist daraus z.B. Mono entstanden.
Senior Sanchez
2006-03-22, 16:02:44
Ich hoffe es ist nicht verboten das Fazit des erwähnten Artikels zu zitieren (falls doch bitte löschen):
Hmm, Performance-Nachteile habe ich noch nicht bemerkt, genausowenig wie Vorteile, obwohl der Code ja öfters kleiner wird.
@Gast
Der Bytecode wird so manipuliert, dass der Interpreter bzw. die JVM damit keine Probleme hat. Allerdings hätte der Standard Compiler welche, weil oft im Bytecode so rumgewerkelt wird, das reservierte Namen als Bezeichner verwendet werden, irgendwelche aberwitzigen Konstrukte etc. Der Compiler würde solche Fehler halt rausfangen, da er den Quelltext ja auch auf synt. Korrektheit prüft. Der JVM ist das am Ende egal was da drin steht, hauptsache es lässt sich ausführen.
Und das nutzen viele Obfuscator wie z.B. Retroguard: Es werden Bezeichner entweder in einzelne Buchstaben oder reservierte Schlüsselwörter umgewandelt, was mit Refactoring noch verschmerzt bar wäre. Aber es kommen zum Teil auch sone Geschichten raus, dass der Compiler Syntaxfehler melden würde. Wenn man sonen dekompilierten Source mal sieht, dann hat man in der Regel keine Lust mehr darauf, es sei denn es ist wichtig ;)
Retroguard kann afaik das Archiv auch noch verschlüsseln und ne vorgeschaltete Instanz von Retroguard sorgt beim Ausführen dann immer fürs Entschlüsseln.
Im Endeffekt ist es aber eine Frage des Aufwandes und der Mühe: Wenn man es unbedingt will und hartnäckig genug ist, so bekommt man den Quelltext auch wieder, was sicherlich mit Kabelsalats Aussage einhergeht.
Solange man den Code ausführen kann kann man ihn auch reverse-engineeren. Der Aufwand ändert sich halt, mit javac erzeugter bytecode lässt sich zu sehr gut lesbarem Code decompilieren, wenn ein Obfuscator daraus etwas macht was so (un-)verständlich wie x86-assembler ist reicht das IMO völlig aus.
Senior Sanchez
2006-03-22, 22:20:45
Solange man den Code ausführen kann kann man ihn auch reverse-engineeren. Der Aufwand ändert sich halt, mit javac erzeugter bytecode lässt sich zu sehr gut lesbarem Code decompilieren, wenn ein Obfuscator daraus etwas macht was so (un-)verständlich wie x86-assembler ist reicht das IMO völlig aus.
Ich habe auch nirgendwo was anderes behauptet *g*
Ich habe es sogar gesagt und bemerkt, dass es nur eine Sache des Aufwandes ist.
Meine Aussagen bezogen sich hauptsächlich auf JAD (der wohl beste Java Decompiler) und das der manchmal außer Tritt gebracht wird, durch Obfuscator.
Ich hab irgendwann mal nach Benchmarks gesucht, und hab zu meinem Erschrecken nicht EIN realistisches Szenario gefunden, was mit mehreren Sprachen umgesetzt wurde. Ich glaube, es gibt einfach keine glaubwürdigen Messergebnisse.
Was ist mit dem (http://shootout.alioth.debian.org/) hier?
Monger
2006-03-23, 08:48:23
Was ist mit dem (http://shootout.alioth.debian.org/) hier?
Sehr interessant, aber noch nicht was ich meine. Die dortigen Programme sind selten länger als 100 Zeilen, und viel mehr als nur die Implementierung eines Standard-Algorithmus wird dort auch nicht getestet.
Ich möchte mal eine "echte" Anwendung sehen - mit GUI, mit häufig erzeugten Objekten so dass der Speicher mal richtig voll wird, mit Datenbanken- und Dateizugriffen, mit Zugriff auf Sound- und Videodaten...
Halt all das, was bei einer realen Windows-Applikation auch vorkommen kann. Ich hab mal davon gehört, dass jemand den Renderer von Quake3 mit Java umgesetzt hat (was dann gegenüber der ursprünglichen Variante auch klar langsamer war) - sowas in der Richtung stelle ich mir vor.
Ich weiß dass es utopisch ist, aber es wäre halt mal wirklich eine spannende Frage. Bis jetzt gibt es halt überhaupt keine Hinweise darauf, in welchen Fällen diese oder jene Sprache geeigneter wäre.
Halt all das, was bei einer realen Windows-Applikation auch vorkommen kann. Ich hab mal davon gehört, dass jemand den Renderer von Quake3 mit Java umgesetzt hat (was dann gegenüber der ursprünglichen Variante auch klar langsamer war) - sowas in der Richtung stelle ich mir vor.Q3 rechnet gar nicht viel, deshalb halte ich das für keinen guten Benchmark.
Sinnvolle Programme dauern einfach zu lang zu implementieren. Ich hab mit 2 anderen Leuten ein Programm aus der SPEC CPU2000 suite nachimplementiert (mit leicht veränderten Algorithmen und eingeschränkter Funktionalität), hat etwa 1000 Arbeitsstunden gedauert...
Im Endergebniss ist meins in Java weniger als Faktor 2 langsamer was aber zum größten Teil an nicht implementierten algorithmischen Optimierungen liegt.
Um nochmals mein JOGL-Demo zu erwähnen. Ich hatte einen ähnlichen Algorithmus wie unter http://www.hitlabnz.org/fileman_store/2004-Graphite-ShadowVols-Aldridge.pdf für zur Berechnung der Shadow Volumes eingesetzt. Als Benchmark, ob das mit Java eine gute Idee ist, sollte die Zeit dienen, die für die Bestimmung der Silhouette benötigt wird.
Für zwei Szenen ergab sich folgendes Bild:
1.
C++ 4.73 msec
Java 1.6b server 5.25 msec
Java 1.6b client 6.0 msec
2.
C++ 1.19 msec
Java 1.6b server 1,44 msec
Java 1.6b client 1.71 msec
Insgesamt ist das so nah dran, dass es für mich akzeptabel war (in Assembler wär's wahrscheinlich ohnehin noch schneller gewesen). So bleibt mehr Zeit um geschicktere Algorithmen zu wählen und bekanntlich hilft das mehr als jede Optimierung - und siehe da, wenn man für bestimmte (2-manifold) Objekte eine Abkürzung wählt, dann ergeben sich 4.02 msec für 1.6 server in Szene 1. Diese Optimierung habe ich knapp ein Jahr in C++ vor mich hingeschoben...
Viele Grüße,
Stefan
Irgendwie ist mir der Sinn von Java nach wie vor schleierhaft.
C++ kann viel mehr als Java (Metaprogrammierung mit templates z. B).
Die Standardbibliothek ist bei Java umfangreicher, aber für C++
gibt's ähnlich viele Bibliotheken, die plattformunabhängig laufen
(und zwar *richtig* plattformunabhängig, also nicht nur unter Win,
Solaris, OS X und Linux/x86). Außerdem starten native Anwendungen
schneller, da keine Virtual Machine geladen werden muss, und
Müllabfuhren gibt's auch für C++. OK, C++ hat ein paar alte, von C
mitgeschleppte Macken, aber die hat Java auch (z. B. das archaische
switch-Statement), und irgendwie stören die auch nicht wirklich, wenn
man sich einmal dran gewöhnt hat. Und egal, was die Java-Fans
behaupten: Swing ist nach wie vor lahm, IMO.
Bitte helft mir, ich will endlich mal verstehen, was an Java toll
sein soll, aber irgendwie fällt mir nichts ein, was nicht auch in C++
ginge. Und daß Java keine Operatorüberladung unterstützt ist
irgendwie traurig, da ich dieses Feature in C++ besonders
liebgewonnen habe.
Senior Sanchez
2006-03-28, 17:16:49
Irgendwie ist mir der Sinn von Java nach wie vor schleierhaft.
C++ kann viel mehr als Java (Metaprogrammierung mit templates z. B).
Die Standardbibliothek ist bei Java umfangreicher, aber für C++
gibt's ähnlich viele Bibliotheken, die plattformunabhängig laufen
(und zwar *richtig* plattformunabhängig, also nicht nur unter Win,
Solaris, OS X und Linux/x86). Außerdem starten native Anwendungen
schneller, da keine Virtual Machine geladen werden muss, und
Müllabfuhren gibt's auch für C++. OK, C++ hat ein paar alte, von C
mitgeschleppte Macken, aber die hat Java auch (z. B. das archaische
switch-Statement), und irgendwie stören die auch nicht wirklich, wenn
man sich einmal dran gewöhnt hat. Und egal, was die Java-Fans
behaupten: Swing ist nach wie vor lahm, IMO.
Bitte helft mir, ich will endlich mal verstehen, was an Java toll
sein soll, aber irgendwie fällt mir nichts ein, was nicht auch in C++
ginge. Und daß Java keine Operatorüberladung unterstützt ist
irgendwie traurig, da ich dieses Feature in C++ besonders
liebgewonnen habe.
Naja, die Bibliotheken musste aber auch erstmal nachrüsten, bei Java sind sie dabei.
Java-Anwendungen sind zudem recht stabil und sicher, was nicht umsonst ein Grund ist, warum Java-Anwendungen recht beliebt sind im Enterprise-Sektor.
Was findest du an Java-Anwendungen nicht plattformunabhängig? Gut Swing ist es öfter nicht so ganz, aber sonst klappt das doch wunderbar. Oder hätteste gerne noch ne andere Plattform unterstützt? Welche wäre das denn dann?
Naja, Swing kann lahm sein, wenn man nich richtig damit umgehen kann ;) Mit entsprechenden Kenntnissen ist es doch recht zackig und bisher sind mir da noch nie Klagen gekommen.
Das Java einige Features von C++ nicht hat, liegt einfach daran, dass man die Sprache einfach erlernbar aber doch mächtig gestalten wollte. Deshalb wurden Dinge (für den Anfang) weggelassen, die als nicht soo wichtig angesehen wurden bzw. auch zu Programmierfehlern führen kann.
Reflection und die Möglichkeit, trotz jars/dlls alle Bestandteile der Sprache zu nutzen sind die Vorteile, die mich oft dazu bewegen, Java oder C# statt nativem C++ einzusetzen.
Monger
2006-03-28, 18:16:48
Java ist ziemlich unkaputtbar. Ich habe in Java noch nicht eine einzige Speicherschutzverletzung erlebt, höchstens Exceptions. Über die restlichen Vorteile kann man diskutieren, aber so eine Kleinigkeit macht die Entwicklung soooo viel angenehmer!
Java-Anwendungen sind zudem recht stabil und sicherIch programmier dir in 5min ein Gegenbeispiel :tongue:
DocEW
2006-03-28, 19:25:36
Ich programmier dir in 5min ein Gegenbeispiel :tongue:
Was wäre das dann so ungefähr? Nur aus Interesse.
...
if(password == "login") {
}
...:tongue:
Ist natürlich ein strunzblödes Beispiel, aber ein Java-Programm ist garantiert nicht von allein nur weil es in Java geschrieben wurde sicher X-D
Was man natürlich ausschließen kann sind Buffer-Overflows, aber wenn man in C++ vector::at statt vector::operator[] benützen würde täte man das auch - macht nur kein Schwein ;)
Senior Sanchez
2006-03-29, 16:30:28
...
if(password == "login") {
}
...:tongue:
Ist natürlich ein strunzblödes Beispiel, aber ein Java-Programm ist garantiert nicht von allein nur weil es in Java geschrieben wurde sicher X-D
Was man natürlich ausschließen kann sind Buffer-Overflows, aber wenn man in C++ vector::at statt vector::operator[] benützen würde täte man das auch - macht nur kein Schwein ;)
Ja ok, wenn man mit Absicht scheiße programmiert ist das keine Kunst, dann ist alles unsicher.
Meine Aussage rührte mehr dadurch, dass wenns doch gut programmiert ist, es sehr schwierig ist, das ganze System in Mitleidenschaft zu ziehen (VM sei dank) und durch die Integration der SecurityManager, Sandboxen etc. ist es auch relativ sicher, wie ich finde.
Aber nur zur Info: deine Anweisung lässt das Programm nicht abstürzen ;) Es tut nur nicht was du willst und demzufolge ist es humbug *g*
Aber nur zur Info: deine Anweisung lässt das Programm nicht abstürzen ;) Es tut nur nicht was du willst und demzufolge ist es humbug *g*
Seit wann hat Sicherheit zwangsläufig etwas mit einem Absturz zu tun?
Oder meinst du das C++ Dingens? at schmeißt sehr wohl ne Out-Of-Bound-Exception und wenn man diese nicht fängt schmiert das Program eben ab.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.