Java ist schneller als C++!
-
Scheppertreiber schrieb:
Ok, dann bin ich halt doof *blöök* *pfarzzz*
Macht mir nix, der Kram läuft und die Performance ist auch ok.
Wenn ich mal so richtig Zeit habe stricke ich alles in Apache-Module um.
Mit Sicherheit schneller. Aber woher die Zeit nehmen ?alles was ich sage ist, dass bei cgi die performance egal ist, da CGI die bremse ist.
fast-cgi hilft hier zB schon einmal enorm. wenn man aber c++ code hat, ist tntnet einfach der richtige weg. wenn man java code hat sind server pages, etc. der richtige weg.
programme per cgi aufzurufen ist einfach nur lahm. ein benchmark wuerde da keinen sinn machen. wenn man aber asp.net gegen java server pages gegen tntnet benchmarked, waere das uU schon interessanter.
und fuer cgi - was fuer anwendungen hast du denn als cgi laufen? wenn sie script sprachen geschrieben sind, gibt es sicher server module fuer die interpreter. wenn es in c/c++ geschrieben ist -> fast cgi oder tntnet
idealerweise macht man sowas natuerlich von anfang an richtig...
-
Vergleicht hier mal C/C++ mit Java: Die Geschwindigkeit bzw. Ausführungszeit ist *relativ* gleich, aber der RAM-Verbrauch ... ist meistens bei Java um das 80 bis 100fache höher ...
-
long long double schrieb:
aber der RAM-Verbrauch ... ist meistens bei Java um das 80 bis 100fache höher ...
Das ist nur bei den Programmen so, die sowieso kaum RAM benötigen: Hello-World und so. Sobald Du Programme schreibst, die wirklich einiges an Daten verarbeiten müssen, fällt der JVM-Overhead weit weniger ins Gewicht.
Du kannst ja mal ein Programm schreiben, das ein 50MB großes Bild einliest und um 90° gedreht wieder abspeichert. Da wirst Du weit weniger Unterschiede im Speicherverbrauch feststellen.
-
Gregor schrieb:
Du kannst ja mal ein Programm schreiben, das ein 50MB großes Bild einliest und um 90° gedreht wieder abspeichert. Da wirst Du weit weniger Unterschiede im Speicherverbrauch feststellen.
Die JVM wird den Speicher aber lange behalten, während das C++ Programm ihn gleich wieder ans OS zurück gibt.
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. Java macht auch mehr Sicherheitskram (Arrayzugriffchecks, alles mit Defaultwerten initialisieren) der auch noch bremst.
-
Das mit dem Bilddrehen wäre mal ein guter Test um die Geschwindigkeit zu vergleichen.
-
Sind Apachemodule und Fast-CGI denn überhaupt hinnehmbar ? Wenn denn das speichern von Daten im Programmordner Tabu ist und man nur mit eingeschränkten Rechten arbeiten soll auf einer Maschine wirkt Apachemodul und Fast-CGI wie ein extremes gegenteil davon. (Oder wird einfach nur das geprabbelt was grad irgendwie passt ?!)
Bei den vielen "x ist schneller / besser als y" sollte man vllt. die Wirtschaftlichkeit nicht vergessen. Ein Programm das nen 1/4 weniger Speicherplatz verbraucht und 20% schneller startet bringt mir nix, wenn die Kosten dafür 5 mal so hoch sind. Die Berücksichtigung von sowas vermisse ich bei den Flamewars recht häufig.
-
YourEyes schrieb:
Was Java Progs noch langsamer als C++ macht ist, dass Java keine ordentlichen Templates hat.
und C programme sind sauschnell, weil sie ordentliche makros haben?
-
YourEyes schrieb:
[...],während das C++ Programm ihn gleich wieder ans OS zurück gibt.
dann hättest du aber ein richtig schön langsames c++. usepace-kernelspace roundtrips, um eine variabel zu erzeugen. holla die waldfee.
c++ verhält sich da normalerweise anders. bei der dynamischen speicherverwaltunge wird normalerweise nur blockweise speicher vom system alloziert und je nach implementierung zwischen vllt und nie an das system zurückgegeben.
viele moderne speicherverwaltungssysteme halten es so, dass sie einzeln allozierte speicherbereiche, nach der freigabe dem system zurückgeben bzw. eine gewisse menge an allozierten bereichen auf "reserve" zurückhalten. die sammelbereiche für die kleinen speicherbereiche werden üblicherweise nie zurückgegeben. der aufwand wäre zu groß...
java macht das intern nicht viel anders, nur das hier üblicherweise poolallokatoren für spezielle objekte behalten werden und keine für rohen speicher. die vm kann sich dementsprechend auch genauso verhalten wie ein c++-programm. in welchen vms das wie implementiert ist, weiß ich aber nicht.zu dem benchmark: es hängt vom design des benchmarks ab, welches der systeme schneller ist... ist ein bisschen wie der vergleich zwischen c und c++. wenn man die gleichen anforderungen stellt, spielen die beiden in ähnlichen geschwindigkeitskategorien. bei java und c++ kommt dann noch hinzu, dass man die programme grundsätzlich anders designen müsste. das zeigt dir jeder benchmark, der nur einen kleinen teil des funktionsumfangs abdeckt.
-
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.
ghorst schrieb:
YourEyes schrieb:
[...],während das C++ Programm ihn gleich wieder ans OS zurück gibt.
dann hättest du aber ein richtig schön langsames c++. usepace-kernelspace roundtrips, um eine variabel zu erzeugen. holla die waldfee.
c++ verhält sich da normalerweise anders. bei der dynamischen speicherverwaltunge wird normalerweise nur blockweise speicher vom system alloziert und je nach implementierung zwischen vllt und nie an das system zurückgegeben.
viele moderne speicherverwaltungssysteme halten es so, dass sie einzeln allozierte speicherbereiche, nach der freigabe dem system zurückgeben bzw. eine gewisse menge an allozierten bereichen auf "reserve" zurückhalten. die sammelbereiche für die kleinen speicherbereiche werden üblicherweise nie zurückgegeben. der aufwand wäre zu groß...
java macht das intern nicht viel anders, nur das hier üblicherweise poolallokatoren für spezielle objekte behalten werden und keine für rohen speicher. die vm kann sich dementsprechend auch genauso verhalten wie ein c++-programm. in welchen vms das wie implementiert ist, weiß ich aber nicht.Die kleinen Bereiche interessieren auch nicht. Wenn du in C++ dir 100MB besorgst und sie wieder frei gibst, dann sieht man das gleich im Taskmanager. Wenn du das in Java machst, dann musst du erst mal warten bis der GC sich entscheidet was freizugeben.
-
die kleinen mengen machen auch gerne mal ein paar mehr mb aus und wie ich auch schrieb: zurückgeben ist keine pflicht. bspw. tcmalloc (google...) schreibt so nett in der doku:
TCMalloc currently does not return any memory to the system.
http://goog-perftools.sourceforge.net/doc/tcmalloc.html
ansonsten kannst du dir da auch mal die funktionsweise von einer halbwegs modernen version durchlesen und bitte nicht stutzen, dass die von auch garbagecollection reden. andere, die tatsächlich seiten zurückgeben, machen es ähnlich und sammeln erst ein paar seiten bevor sie dem system wiederzurückgeben.wenn du 100mb auf einen schlag mit c++ freigibst, ist die wahrscheinlichkeit, dass das mehr oder weniger vollständig zurück an das system geht, relativ hoch, aber mal davon abgesehen, dass man das im laufenbetrieb eher selten macht, könnte man an der stelle auch einfach den gc einmal zwingen und du hast den gleichen effekt. ist aber meist völlig egal, weil der gc zwar nicht sofort reagiert aber doch recht flink ist. meist so flink, dass das keinen größeren einfluss hat.
-
Knuddlbaer schrieb:
Sind Apachemodule und Fast-CGI denn überhaupt hinnehmbar ? Wenn denn das speichern von Daten im Programmordner Tabu ist und man nur mit eingeschränkten Rechten arbeiten soll auf einer Maschine wirkt Apachemodul und Fast-CGI wie ein extremes gegenteil davon. (Oder wird einfach nur das geprabbelt was grad irgendwie passt ?!)
Nein ich habe keine Ahnung wovon ich rede...
Aber bevor noch mehr bloedsinn kommt:
Wenn du eine C++ Anwendung mit CGI ansprichst - wie kann man da dann von Sicherheit reden? Ich kann dank der Anwendung ja beliebigen Code ausfuehren, ich kann also alle lokalen exploits nutzen - ich kann zB ganz einfach ein while(1) fork(); machen... Oder aehnliches.
Wenn man den Anwendungen nicht traut, muss man sie in einer kompletten sandbox laufen lassen und dann ists idr sinnvoller den apachen in der sandbox laufen zu lassen und jeder user auf dem server hat eben einen eigenen apachen in einer sandbox.
Aber dennoch wuerde ich nie binaeren code ausfuehren lassen auf meinem server wenn ich dem code nicht traue...
und wenn man keine panik hat, reicht es die anwendungen als www laufen zu lassen - aber es hat schon seinen grund warum keine shared hoster dir erlauben c++ programme auszufuehren...
und ich glaube ihr wisst nicht was CGI ist. eine c++ anwendung mit CGI anzusteuern ist einfach nur schwachsinn wenn es um performance geht - es sei denn die anwendung laeuft dann ein paar Minuten - aber welcher client will so lange warten? mit persistenten sachen wie eben tntnet/java server pages/... hat man eine startup time von nahezu 0. das muss die c++ anwendung erst einmal aufholen koennen. dazu eben shared memory zwischen den einzelnen instanzen - das kann CGI auch nicht.
aber nein, ich weiss nicht wovon ich rede. ist ok. benchmarken wir c++ mit cgi gegen java mit cgi. das macht sinn...
-
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.
-
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.
-
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...
-
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.
-
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...
-
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.