Java ist schneller als C++!

Simon2

IT-Titan schrieb:

...Re: Java ist schneller als C++!...

und nachts ist es kälter als draußen.

Sprachen haben keine Geschwindigkeit ... weswegen auch niemals eine "schneller" als eine andere sein kann.
Was bleibt ist ein "Mein Papa ist aber stärker als Deiner" ... das hatten meine Töchter bereits mit Eintritt in die 1. Klasse abgelegt.

Gruß,

Simon2.

Scheppertreiber

Sorry Simon der allerzweite,

mach mal Laufzeitmessungen, vorzugsweise mit C und irgendsoeinem Java, Basic oder
sonst so einem Schwindel. Dann reden wir nochmal über so einen Unfug.

Simon2

Scheppertreiber schrieb:

Sorry Simon der allerzweite,

mach mal Laufzeitmessungen, ...

Wovon soll ich Laufzeitmessungen machen ?

Gruß,

Simon2.

zzZz schrieb:

solange ich als anwender eine gefühlte halbe stunde warten muss bis die vm endlich mal gestartet ist, geht mir die ablaufgeschwindigkeit am allerwertesten vorbei.

witzigerweise scheint sich so'n java-vm selbst zu justieren. ich hab letztens eine grosse java anwendung ein paar mal auf 'nem schlappen rechner (800Mhz, 512MB RAM), laufen lassen. die ersten paar mal war's echt scheusslich. alles superlahm und wenn z.b. der GC zuschlug, war erstmal eine minute pause angesagt. aber nach dem 5ten, 6ten start wurden die pausen immer kürzer und die anwendung schien immer flüssiger zu laufen. jetzt kann man richtig damit arbeiten und wenn jetzt der GC mal alles aufräumen muss, sinds vielleicht nur 3 sekunden, die man warten muss. bilde ich mir das nur ein, oder ist java wirklich so intelligent geworden?

Scheppertreiber

Komplexe Programme mal in diversen Programmiersprachen bauen und halt mal die
Laufzeiten messen. Nett ist bei CGI-Programmen mal die Response-Zeiten zwischen
C und PHP oder Java mal zu messen.

Bei reinen GUI-Programmen macht es nicht viel.

Shade Of Mine

Scheppertreiber schrieb:

Nett ist bei CGI-Programmen mal die Response-Zeiten zwischen
C und PHP oder Java mal zu messen.

Nett vielleicht, aber ziemlich unsinnig.

Wenn dann muss man wohl sowas wie tntnet mit java server pages oder servlets vergleichen. aus dem .net bereich asp.net dazu und vielleicht ne c++ anwendung mit fast-cgi noch aus spass auch noch dazu.

aber cgi ist eine technologie die einfach nicht skaliert. sie irgendwo einzusetzen wo geschwindigkeit relevant ist, ist einfach nur doof.

Scheppertreiber

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 ?

Shade Of Mine

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...

long long double

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 ...

http://www.spoj.pl/

Gregor

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.

Knuddlbaer

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?

ghorst

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.

ghorst

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.

Shade Of Mine

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.).