Java ist schneller als C++!
-
Bashar schrieb:
Solange man nicht weiß was genau das für Stellen sind solche Zahlen absolut nichtssagend. Java wird zum Beispiel ganz gerne für betriebswirtschaftliche Anwendungen benutzt (Buchhaltung etc.), für die man früher COBOL oder Papierakten benutzt hat. Mein Interesse an sowas geht gegen Null.
Die Statistik ist Deiner Meinung nach also nichtssagend, weil sie nicht auf Deine persönlichen Präferenzen zugeschnitten ist?
-
fricky schrieb:
Perl FTW schrieb:
Interessant, was dieses kleine Spielzeug zum ewigen Skriptsprachen-Krieg sagt:
http://www.indeed.com/jobtrends?q=perl%2C+python%2C+ruby&l=
Von wegen Perl ist tot.
Perl ist und bleibt eben die Nummer Eins!
-
Perl FTW schrieb:
Perl ist und bleibt eben die Nummer Eins!
nö, C --> http://www.indeed.com/jobtrends?q=c%2C+perl
da kommt keiner ran.
-
Also am besten ist immer noch A:
http://www.indeed.com/jobtrends?q=a%2C+c%2C+c%23%2C+perl%2C+c%2B%2B%2C+java&l=
Noch nicht A gelernt? Dann aber los!
-
doch d, schlägt c.
aber ist ja klar, kommt im alphabet auch dahinter.
soviel zur qualität dieser statistik.
-
Nicht wenn mans logisch angeht:
http://www.indeed.com/jobtrends?q=c+and+programmer%2C+d+and+programmer&l=
-
byto schrieb:
Nicht wenn mans logisch angeht:
http://www.indeed.com/jobtrends?q=c+and+programmer%2C+d+and+programmer&l=stimmt: http://www.indeed.com/jobtrends?q=c+and+engineer%2C+c%2B%2B+and+programmer
-
du bist ein wahrer logiker
-
kenner der freakys schrieb:
kenner der freakys
du heißt bestimmt gülcan oder so ne?
-
Java ist schlecht. Deshalb ist es auch nicht sonderlich weit verbreitet.
-
byto schrieb:
Nicht wenn mans logisch angeht:
http://www.indeed.com/jobtrends?q=c+and+programmer%2C+d+and+programmer&l=
... kommt auch nur Müll raus. Oder was wolltest du uns sagen?
-
Hier sieht man sehr schön, dass im Java Bereich mehr einfache Programmierer gesucht werden, wogegen im C++ Bereich mehr anspruchsvolle Angebote vorhanden sind.
http://www.indeed.com/jobtrends?q=java+and+programmer%2C+c%2B%2B+and+programmer%2C+java+and+engineer%2C+c%2B%2B+and+engineer&l=
-
FachmannFürStatistik schrieb:
Hier sieht man sehr schön, dass im Java Bereich mehr einfache Programmierer gesucht werden, wogegen im C++ Bereich mehr anspruchsvolle Angebote vorhanden sind.
http://www.indeed.com/jobtrends?q=java+and+programmer%2C+c%2B%2B+and+programmer%2C+java+and+engineer%2C+c%2B%2B+and+engineer&l=Naja, +/- 2% (grob geschaetzt), das gibt sich aber nicht viel.
-
Bashar schrieb:
Java wird zum Beispiel ganz gerne für betriebswirtschaftliche Anwendungen benutzt (Buchhaltung etc.), für die man früher COBOL oder Papierakten benutzt hat
Java wird auch viel für mathematisch/wissenschaftlichen kram benutzt. z.b. hat ein freund von mir sich letzten entschieden, ein (hobby)projekt in Java zu machen, weil er eine coole library zur visualislierung von gerichteten graphen in Java gefunden hat (http://www.jgraph.com/jgraph.html). für andere sprachen (z.b. C++) gibts irgendwie nix vergleichbares.
-
byto schrieb:
Die Statistik ist Deiner Meinung nach also nichtssagend, weil sie nicht auf Deine persönlichen Präferenzen zugeschnitten ist?
Die Transferleistung, das auf die eigenen Präferenzen abzubilden, traue ich jedem zu.
-
Die Sache liegt wie immer im Detail:
Ich habe C++ Code gesehen, da sage ich ganz klar:
Java ist schneller. Da kann der Compiler noch so gut sein. Der Programmierer gibt ihm keine Chance (persönlich bin ich ja für eine Änderung des Compiliervorgehens). Den umgekehrten Fall gibt es auch. C++ kann Tricks, da kommt kein Java Compiler gegen an ( wie im aktuellen Projekt ).Aber schauen wie uns doch mal den JIT Compiler genauer an:
In einer J2EE Umgebung wird der Code so ca. 600 mal interpretiert ausgeführt. Währenddessen sammelt der JIT ( wieso eingentlich JIT?) Profiler Informationen. In einem separaten Task wird dann der Code hoch optimiert übersetzt. (Interessanterweise wird Byte Code so gut wie gar nicht optimiert)Hat man genügend Prozessoren, fällt das nicht weiter auf. Sind jedoch alle CPUs belegt, fällt das massiv ins Gewicht. Genau wie mit dem RAM. In ner 8 GB Maschine als Desktop kann ein Mini-Java-Programm nicht auffallen. Wenn aber der ganze Desktop in Java geschrieben wurde, fällt das ganz massiv ins Gewicht.
Das ist ja wie die Diskussion mit TCP oder UDP. Oder mit Verschlüsselung. Oder...
Oder...
Wenn ich eh Power im Überfluss habe, kann ich kaum Unterschiede messen.
Interresant wird es erst, wenn die Kiste unter Dampf steht.Theoretisch + Ausblick:
Die Compilerbauer, ob Java oder C oder C++ haben ja grundsätzlich dasselbe Vorgehen, so daß C oder Java Code auf binärer Basis gleich schnell laufen sollte.Java hat grundsätzlich die Nachteile:
- Enormer Speicherverbrauch (Designbedingt, Cache is Speed!),
- Ganz langsamer AufstartC/C++ hat grundsätzlich die Nachteile:
- Es baut und optimiert den Objectcode pro Datei, nicht pro Library. Da geht einem durch ungeschicktes Programmieren schon mal Faktor 10 ( in Worten: zehn ) verloren. Das ist eigentlich nur ein C++ Problem.
- Wesentlich anspruchsvoller ( ich sag ja ungern "schwieriger") in der Codierung
-
In einer J2EE Umgebung wird der Code so ca. 600 mal interpretiert ausgeführt. Währenddessen sammelt der JIT ( wieso eingentlich JIT?) Profiler Informationen. In einem separaten Task wird dann der Code hoch optimiert übersetzt. (Interessanterweise wird Byte Code so gut wie gar nicht optimiert)
Dieses Profiling kannst du aber auch in C++ haben, das ist kein Alleinstellungsmerkmal eines JIT. Es gibt von den bekannten C++-Compilern mittlerweile auch PGO (Profile-Guided Optimization):
http://msdn.microsoft.com/de-de/library/e7k32f4k.aspx
Und seien wir ehrlich, die meisten Programme laufen gleich ab. Die meisten User benutzen eine Software gleich.C/C++ hat grundsätzlich die Nachteile:
- Es baut und optimiert den Objectcode pro Datei, nicht pro Library. Da geht einem durch ungeschicktes Programmieren schon mal Faktor 10 ( in Worten: zehn ) verloren. Das ist eigentlich nur ein C++ Problem.Ehm, naja, das stimmt aber auch nicht mehr. Beim kompilieren und debuggen mag zwar alles auf Objektcode-Dateien stur kompiliert sein, aber was ist (wie bei PGO) mit dem Release-Build? genau, da haben die C++-Compiler heute natürlich auch eine Lösung: WPO (Whole Program Optimization)
http://msdn.microsoft.com/de-de/library/0zza0de8.aspxEinige vergessen immer wieder eines: Auch C++ und vorallem seine Tools entwickeln sich weiter. Es lohnt sich auch mal über die aktuellen Compiler zu informieren.
-
Wie macht man eine wirklich tolle PGO, wenn man das Zielsystem nicht genau kennt? Ein JIT könnte auf den genauen Prozessor, dessen Cache-Größe und sogar auf das aktuell zur Verfügung stehende RAM hin optimieren. Vermutlich kriegt man das aber auch mit C++ hin, einfach 30-40 verschiedene Executables für unterschiedlichste Situationen liefern.
-
Jester schrieb:
Wie macht man eine wirklich tolle PGO, wenn man das Zielsystem nicht genau kennt? Ein JIT könnte auf den genauen Prozessor, dessen Cache-Größe und sogar auf das aktuell zur Verfügung stehende RAM hin optimieren. Vermutlich kriegt man das aber auch mit C++ hin, einfach 30-40 verschiedene Executables für unterschiedlichste Situationen liefern.
indem man genau wie bei java nicht das finale binary, sondern den compiler input mitliefert. Ist bei den meisten dingen unter bsd/*nux eh der fall.
-
Zui schrieb:
...
Java hat grundsätzlich die Nachteile:
...
C/C++ hat grundsätzlich die Nachteile:
...Hmmm also ich sehe weder hier noch dort Nachteile, die in der Sprache begründet seien, sondern lediglich Vergleiche spezieller Vorgehensweisen/Konfiguratioen/Tooleigenschaften im Entwicklungs- und im Laufzeitumfeld.
Ich wüsste nicht, warum die o.g. "C++-Vorteile" nicht genauso mit Java-Programmen und anders herum genutzt werden könnten.
Gruß,
Simon2.