Java ist schneller als C++!
-
1. Bei Programmen, die nur eine Sekunde oder so laufen, ist die Performance eh wenig relevant.
Na ja, wenn's ein CGI-Programm ist ...
-
einfach mal eclipse und visual studio starten und vergleichen
-
Scheppertreiber schrieb:
1. Bei Programmen, die nur eine Sekunde oder so laufen, ist die Performance eh wenig relevant.
Na ja, wenn's ein CGI-Programm ist ...
deshalb verwendet man kein cgi... weil es einfach verdammt lahm ist. das liegt aber nicht an java oder c++ sondern daran, dass cgi einfach nicht skaliert.
-
ach.... schrieb:
Gregor schrieb:
2. Also ich habe 8 GB RAM im Rechner. Was sind da schon 20 MB?
Deswegen hat das ja noch lange nicht jeder.
Das war ja auch nur beispielhaft. Heutige Rechner haben derart viel RAM, dass der Speicheroverhead einer JVM praktisch keine wirkliche Relevanz mehr hat. Auch wenn nur 2 GB im Rechner stecken.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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 ?
-
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.