Java ist schneller als C++!

YourEyes schrieb:

fricky schrieb:

YourEyes schrieb:

Was Java Progs noch langsamer als C++ macht ist, dass Java keine ordentlichen Templates hat. Primitive Variablen (int, double...) in eine Liste oder Set zu stecken ist richtig aufwendig. Oft wird Laufzeit Polymorphie verwendet, obwohl man sie garnicht braucht und das ganze auch mit Templates lösen könnte.

und C programme sind sauschnell, weil sie ordentliche makros haben?

Lies das dahinter, dann verstehst vlt. sogar du es.

was dahinter steht ist doch belanglos. aber um mal drauf einzugehen: wenn man absichtlich ein programm so schreibt, dass es viel rumrödeln muss, dann braucht man sich nicht zu wundern, wenn's nicht klappt mit dem benchmark. das hat mit c++ templates überhaupt nichts zu tun. wenn templates wirklich eine so tolle erfindung wären, glaubst du dann nicht, dass andere sprachen sie nicht schon längst übernommen hätten?

fricky schrieb:

YourEyes schrieb:

fricky schrieb:

YourEyes schrieb:

Was Java Progs noch langsamer als C++ macht ist, dass Java keine ordentlichen Templates hat. Primitive Variablen (int, double...) in eine Liste oder Set zu stecken ist richtig aufwendig. Oft wird Laufzeit Polymorphie verwendet, obwohl man sie garnicht braucht und das ganze auch mit Templates lösen könnte.

und C programme sind sauschnell, weil sie ordentliche makros haben?

Lies das dahinter, dann verstehst vlt. sogar du es.

was dahinter steht ist doch belanglos. aber um mal drauf einzugehen: wenn man absichtlich ein programm so schreibt, dass es viel rumrödeln muss, dann braucht man sich nicht zu wundern, wenn's nicht klappt mit dem benchmark. das hat mit c++ templates überhaupt nichts zu tun. wenn templates wirklich eine so tolle erfindung wären, glaubst du dann nicht, dass andere sprachen sie nicht schon längst übernommen hätten?

Stimmt keine einzige Sprache außer C++ hat sich das von C++ abgeschaut und übernommen

Fast vergessen, bei Trollen muss man ja immer alles explizit schreiben, sonst können die mir ihrer "hirnausschalt-Logik" ja dagegen gehen: andere Sprachen die von C++ abschauen vereinfachen für gewöhnlich (Keine "Zeiger" in Java, keine Operatorüberladung, etc.).

Java hats mit den Generics versucht, aber wollte dann den durchschnitts Javacoder nicht überfordern und hat nur was einfacheres gemacht. Jetzt wird es halt hautsächlich verwendet um Casts zu sparen.

Gregor

YourEyes schrieb:

Java hats mit den Generics versucht, aber wollte dann den durchschnitts Javacoder nicht überfordern und hat nur was einfacheres gemacht. Jetzt wird es halt hautsächlich verwendet um Casts zu sparen.

Naja, die nichtvorhandene statische Typsicherheit war auch das zentrale Problem, was man durch die Generics angehen wollte. Trotzdem stellt die jetzige Realisierung der Generics tatsächlich nur eine wenig zufriedenstellende Lösung dar.

Das Problem dabei ist nicht, dass man den Javaprogrammierer nicht überlasten wollte. Das Problem war die Kompatibilität des Bytecodes. Es gibt eine Menge JVMs in der Industrie und Sun stellt davon nicht gerade die absolute Mehrheit. Man kann Java einfach in sehr vielen Bereichen finden, vom großen Server bis hin zu einer Java-Realisierung in Blu-Ray-Playern oder Mobiltelefonen. Es gibt auch Java-Realisierungen in Hardware als Javaprozessor und so. Zumindest ist es in diesem Umfeld äußerst schwer, wesentliche Änderungen des Bytecodes zu rechtfertigen. Eine wirklich schöne Realisierung von Generics hätte aber eine deutliche Modifikation des Bytecodes benötigt.

Man sollte die Generics ausschließlich als das sehen, wozu sie ursprünglich gedacht waren: Eine Lösung, um mehr statische Typsicherheit zu ermöglichen. Man hätte deutlich mehr mit so einem Mechanismus anfangen können, aber das hat man halt nicht gemacht.

DEvent

Gregor schrieb:

YourEyes schrieb:

Java hats mit den Generics versucht, aber wollte dann den durchschnitts Javacoder nicht überfordern und hat nur was einfacheres gemacht. Jetzt wird es halt hautsächlich verwendet um Casts zu sparen.

Man sollte die Generics ausschließlich als das sehen, wozu sie ursprünglich gedacht waren: Eine Lösung, um mehr statische Typsicherheit zu ermöglichen. Man hätte deutlich mehr mit so einem Mechanismus anfangen können, aber das hat man halt nicht gemacht.

Wozu auch, das was man in Java mit den Generics hat reicht vollkommen aus.

YourEyes schrieb:

Was Java Progs noch langsamer als C++ macht ist, dass Java keine ordentlichen Templates hat. Primitive Variablen (int, double...) in eine Liste oder Set zu stecken ist richtig aufwendig. Oft wird Laufzeit Polymorphie verwendet, obwohl man sie garnicht braucht und das ganze auch mit Templates lösen könnte.

Niemand verwendet Set<?> und List<?> usw. als Container fuer primitive Datentypen, wozu auch. Dafuer gibt es z.B. die PCJ http://pcj.sourceforge.net/

Ich waere eigentlich dafuer gewesen die primitiven Datentypen ganz aus Java zu verbannen und die Entscheidung wie das gehandhabt wird der JVM/Compiler zu ueberlassen. Dies macht man z.B. bei Ruby. Aber dann gaebe es wahrscheinlich noch mehr getrolle...

ghorst

zu ruby: es stimmt nicht ganz. ints werden primitiv behandelt.
aber sonst hast du recht. die generics, wie sie zur zeit sind, passen zu java. (das ist nicht negativ sondern positiv gemeint, also sie passen in das konzept).

was die generics als container angeht: java kennt nur referenzen/pointer (name ist egal, jeder weiß, worum es geht). die container die mittels generics erstellt werden, sind fast identisch mit dem, was eine optimierte stl tun würde. es ist die gleiche lösung wie in c++ nur anders dargestellt.

Ich bin dafür alle Java-vs.-C++-Threads zu löschen. So langsam NERVT das einfach nur noch.

Skym0sh0

also bei mir ist C++ viel shcneller als java

und warum?
weil ich das so will !

dann schriebe ich halt in ein java prog so viel scheisse reind ass 2millionen primzahlen per bruteforce in C++ schneller sind als hello world in java...

asc

Wenn jemand wirklich etwas einigermaßen vergleichbares als Basis nehmen will müsste er eine kleine Aufgabenstellung machen, diese jeweils einen Java- und einen C++-Profi vorlegen und anschließend diese vergleichen. Alles andere ist eh Unsinn da man C++- und Javacode anders schreibt und anders optimiert.

Und je nach Aufgabenstellung kann sich das ganze wieder anders verhalten.

cu André
P.S: Meiner persönlichen Erfahrung nach ist Java aber dennoch immer etwas langsamer als ein entsprechendes C++ Pendant, je nach Aufgabenstellen kann es fast gleich schnell sein oder merklich langsamer. Dennoch sind dies nur subjektive Erfahrungswerte.

Quake ist mit Java 10 FPS schneller als C, siehe Links im OP

dfgfdgdfg schrieb:

Quake ist mit Java 10 FPS schneller als C, siehe Links im OP

Hast du sie denn auch gelesen?

Ansonsten stimme ich GeNERVTer voll zu.

Eure Mütter sind so fett, dass man alle drei Teile von Herr der Ringe verpasst, wenn sie vor dem TV vorbeilaufen!

So jetzt seht ihr mal auf was für einem Niveau ihr euch unterhaltet.

Java vs. C++ Flamewars sind wie Rap - in beidem geht es darum wer die Mutter des anderen besser beleidigt.

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

+++Update+++ schrieb:

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Ich wusste es ja schon immer, unter C++ weiß man wenigstens woran man ist und muss entsprechend aufpassen, aber wenn man als Java-Progger mit seiner Rosa-Brille da sitzt hat man natürlich keinen Plan was da eigentlich abgeht.

+++Update+++ schrieb:

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Jetzt ist mir aber nicht klar geworden, wie denn jetzt ein buffer overflow in Java-Code erzeugt werden kann. Nur, dass verschiedene Schutzmechanismen des OS nicht greifen, falls es doch dazu kommt.

Optimizer schrieb:

+++Update+++ schrieb:

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Jetzt ist mir aber nicht klar geworden, wie denn jetzt ein buffer overflow in Java-Code erzeugt werden kann. Nur, dass verschiedene Schutzmechanismen des OS nicht greifen, falls es doch dazu kommt.

Lol, best Posting ever!

Schuld ist Sun, weil sie aktiv die Schutzmechanismen von Windows umgehen, lies doch mal den Beitrag.

Optimizer schrieb:

+++Update+++ schrieb:

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Jetzt ist mir aber nicht klar geworden, wie denn jetzt ein buffer overflow in Java-Code erzeugt werden kann. Nur, dass verschiedene Schutzmechanismen des OS nicht greifen, falls es doch dazu kommt.

du bist ja auch ein Java-Fan-Boy

Das ist ja richtig erbärmlich, dass man mit diesem lahmen Java jetzt sogar Buffer Overflows erzeugen kann.

Roflcopter schrieb:

Optimizer schrieb:

+++Update+++ schrieb:

Java macht den Computer unsicher! http://www.heise.de/newsticker/Die-Rueckkehr-der-Pufferueberlaeufe--/meldung/114054

Jetzt ist mir aber nicht klar geworden, wie denn jetzt ein buffer overflow in Java-Code erzeugt werden kann. Nur, dass verschiedene Schutzmechanismen des OS nicht greifen, falls es doch dazu kommt.

Lol, best Posting ever!

Schuld ist Sun, weil sie aktiv die Schutzmechanismen von Windows umgehen, lies doch mal den Beitrag.

Ich habe sehr wohl begriffen, wie die Java-VM die Schutzmechanismen umgeht und es sogar mit eigenen Worten wiedergegeben. Die Schutzmechanismen sind aber nur relevant, wenn es zu einem overflow kommt. Um das zu verhindern, bringt die Java-VM eigene Schutzmechanismen mit.

Es ist, wie du vielleicht weißt, deinem Posting nach zu urteilen vielleicht aber auch nicht, nicht völlig einfach, mit Java-Code einen buffer overflow zu erzeugen. Ich sehe deinen copter schon abstürzen...

GeNERVTer schrieb:

Ich bin dafür alle Java-vs.-C++-Threads zu löschen.

ich finde auch doof, dass Java immer als gegenspieler herhalten muss. warum eigentlich? wer sich über c++ informieren will, sollte mal das hier lesen: http://yosefk.com/c++fqa/index.html dann braucht er's auch nicht mehr mit Java zu vergleichen.