Lohnt es sich noch C++ zu lernen?

Gregor

MaSTaH schrieb:

Du redest grade so, als könntest du jeden Code in Java implementieren, so dass er schneller als C++ ist. Soll ich jetzt lachen weil es so hirnrissig ist oder lachen weil du so rumprollst?

Ich sehe es als Experiment an. Eigentlich bin ich selbst gespannt, wieviel schneller ihr ein nicht ganz kleines C++-Programm hinkriegt. Wenn RHBaum nicht will, dann kannst du mir auch gerne ein 1000-2000 Zeilen langes C++-Programm zeigen, von dem du überzeugt bist, dass äquivalentes in Java deutlich unterlegen ist, was die Performance betrifft.

kartoffelsack

Hab keine Lust selber nachzumessen aber ich vertrau Dir und gehe fast jede Wette ein, dass Du das mit Java nicht so schnell hinkriegst wie mit C++

#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}

PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

Wann wird dieses Manko im Standard endlich ausgemerzt?

Walli

Gregor schrieb:

Wenn RHBaum nicht will, dann kannst du mir auch gerne ein 1000-2000 Zeilen langes C++-Programm zeigen, von dem du überzeugt bist, dass äquivalentes in Java deutlich unterlegen ist, was die Performance betrifft.

Wenn ich die Zeit dazu hätte würde ich den Wettbewerb antreten. Aber 1000-2000 Zeilen nur um zu zeigen das Java langsamer ist bedarf es nicht, da es doch auf der Hand liegt, dass eine Interpretersprache langsamer ist als Maschinencode.

Walli

.. schrieb:

Wann wird dieses Manko im Standard endlich ausgemerzt?

Der Standard kümmert sich nicht um das GUI und von daher ist es kein Manko. Die plattformunabhänige GUI-Erstellung ist imho der einzige Vorteil von Java. Ansonsten kann man auch sehr guten plattformunabhängigen C++-Code schreiben.

kartoffelsack

Solang man weder Netzwerkfunktionalität benötigt oder Threads oder direkt auf ne Tastatureingabe reagieren muss oder ein Verzeichnis durchsuchen will oder ...
Ich muss sagen, dass ich das schon als Manko sehe.

groovemaster

@Gregor
Ich habe auch nicht behauptet, dass es keine Programme gibt, die ausschliesslich in Java programmiert wurden. Allerdings bestärkt mich deine Liste in meinem Glauben. Bis auf den JBuilder und Eclipse sagen mir die anderen Sachen alle nix (aber wer kennt schon jedes Programm ). Und diese beiden sind IDE's in Java für Java. Da werf ich keinen Stein. Oder hast du schon mal Intel für einen AMD Prozessor werben sehen?
Fakt ist aber, dass man mit einer Interpretersprache niemals Programme schreiben kann, die schneller sind, als wenn man sie in einer Compilersprache geschrieben hätte. Wenn dann höchstens gleichschnell, aber selbst dass ist unrealistisch.
Trotzdem will ich Java nicht schlecht machen. Vielleicht gehören ja Interpretersprachen die Zukunft, irgendwann einmal wenn die Rechner so schnell sind, dass Geschwindigkeit für den Heimanwender keine Rolle mehr spielt.

@kartoffelsack
Dass der Standard nichts zu deinen aufgeführten Beispielen sagt, sehe ich ebenfalls als Manko. Trotzdem kann man solche Sachen benutzen und dabei portablen Code schreiben, indem man eigene Klassen dafür einsetzt oder auf frei verfügbare zurückgreift.

Walli

kartoffelsack schrieb:

Solang man weder Netzwerkfunktionalität benötigt oder Threads oder direkt auf ne Tastatureingabe reagieren muss oder ein Verzeichnis durchsuchen will oder ...

Wenn man mal davon absieht, dass Tastatureingaben auch zu einem UI gehören und demnach garnicht zur Debatte stehen sind die Sachen alle plattformabhängig. Ein Taschenrechner kennt kein Netzwerk oder Verzeichnisse...

*aleph_0

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Gregor

kartoffelsack schrieb:

Hab keine Lust selber nachzumessen aber ich vertrau Dir und gehe fast jede Wette ein, dass Du das mit Java nicht so schnell hinkriegst wie mit C++
#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}
PS: außerdem ist es unfair, wenn man Bibs von drittanbietern weglassen muss, weil Du genau weißt, dass es keine C++-Standard-GUI-Bib gibt. So kann man dann schwer ein C++-GUI-Prog mit der Java-Swing-GUI vergleichen.

1. Bibliotheken, wie Qt oder GTK habe ich explizit erlaubt. OpenGL ist ein anderes Kaliber.
2.

Otaku@linux:~/TestProjects> cat TestIO.cpp
#include <iostream>

int main()
{
  for( int i(0); i < 100000; ++i)
  {
    std::cout << "Das ist der "<<i<<"te Schleifendurchlauf";
  }
}

Otaku@linux:~/TestProjects> cat TestIO.java
import java.io.*;

public class TestIO
{
   public static void main (String [] args)
   {
      blah();
   }

   public static void blah ()
   {
      PrintWriter out = new PrintWriter (new BufferedOutputStream (System.out));
      for (int i = 0 ; i < 100000 ; ++i)
      {
         out.print ("Das ist der ");
         out.print (i);
         out.print ("te Schleifendurchlauf");
      }
      out.close();
   }
}
Otaku@linux:~/TestProjects> g++ -o TestIO TestIO.cpp -O3
Otaku@linux:~/TestProjects> javac TestIO.java
Otaku@linux:~/TestProjects> time ./TestIO
[...]
real    0m7.306s
user    0m1.900s
sys     0m0.090s
Otaku@linux:~/TestProjects> time java TestIO
[...]
real    0m5.827s
user    0m0.640s
sys     0m0.090s

EDIT: Bevor ich es vergesse:

Otaku@linux:~/TestProjects> g++ --version
g++ (GCC) 3.3 20030226 (prerelease) (SuSE Linux)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Otaku@linux:~/TestProjects> java -version
java version "1.4.1_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_02-b06)
Java HotSpot(TM) Client VM (build 1.4.1_02-b06, mixed mode)

Gregor

MaSTaH schrieb:

Wenn ich die Zeit dazu hätte würde ich den Wettbewerb antreten. Aber 1000-2000 Zeilen nur um zu zeigen das Java langsamer ist bedarf es nicht, da es doch auf der Hand liegt, dass eine Interpretersprache langsamer ist als Maschinencode.

Wenn du Java immernoch als reine Interpretesprache bezeichnest, dann hast du das Prinzip von Java offensichtlich nicht verstanden.

Gregor

\aleph_0 schrieb:

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Ja, wenn es nicht zu sehr aus dem Rahmen 1000-2000 Zeilen fällt.

*aleph_0

Gregor schrieb:

\aleph_0 schrieb:

Gregor: Ich habe da ein Programm, bei dem ich wirklich überzeugt bin, dass Java schlechter abschneiden würde. Es ist reines Standard-C++, plattformunabhängig und ich habe es erfolgreich unter Linux und Windows kompiliert. Interesse?

Ja, wenn es nicht zu sehr aus dem Rahmen 1000-2000 Zeilen fällt.

3000? Es profitiert übrigens sehr von Templates und Operatorenüberladung...

Gregor

\aleph_0 schrieb:

3000? Es profitiert übrigens sehr von Templates und Operatorenüberladung...

Hmmm... in welche Richtung geht es denn? Prinzipiell würde ich das machen, das kann aber ne ganze Zeit dauern, zumal ich demnächst eine Prüfung habe und deshalb momentan nicht soviel Zeit habe.

kartoffelsack

Otaku@linux:~/TestProjects> g++ -o TestIO TestIO.cpp -O3 
Otaku@linux:~/TestProjects> javac TestIO.java 
Otaku@linux:~/TestProjects> time ./TestIO 
[...] 
real    0m7.306s 
user    0m1.900s 
sys     0m0.090s 
Otaku@linux:~/TestProjects> time java TestIO 
[...] 
real    0m5.827s 
user    0m0.640s 
sys     0m0.090s

Tja. Jetzt steh ich da Helft mir Jungs!

Gregor

Naja, solche Mikrobenchmarks haben ja bekanntlicherweise keine Aussagekraft. Da kann man eigentlich nur rausfinden, dass man eine bestimmte Sache mit einer bestimmten Sprache lieber anders lösen sollte, weil die "Standardmethode" einfach nicht performant ist. Ich bin davon überzeugt, dass das mit C++ auch schneller geht.

Mich interessiert eher ein größerer Benchmark. Von diesen Mikrobenchmarks haben wir hier schon genug gemacht. ...und wenn du etwas im Forum gesucht hättest, hättest du glatt feststellen können, dass das hier das absolute Negativbeispiel für C++-Performance ist.

*aleph_0

Gregor schrieb:

Hmmm... in welche Richtung geht es denn?

Es besteht
a) aus einer Bibliothek wie der GMP für natürliche, ganze und rationale Zahlen (automatische dynamische Speicherallozierung) + einige einfache Funktionen wie ggT... (da kommen noch mehr hinzu)
b) einem einfachen Parser als Benutzerschnittstelle
c) Testfunktionen

Beispiel:

546656/58656
        17083/1833
7 mod 3
        1
a = 6896745
        a = 6896745
b = 58966895
        b = 58966895
a = b + 1589758945
        a = 1648725840
(a div b)*b + (a mod b)
        ')' erwartet: "mod b)"
r = a mod b
        r = 56619675
(a div b)*b + r
        1648725840
1/5 mod 7
        3
1/5 mod 10
        Arithmos::InversionNotPossible
1/(a/a - 1)
        Arithmos::DivisionByZero
8^8096
        260[...]056
ggt(384, 72)
        24
ggtx(384,72)
384 = 5*72 + 24
72 = 3*24 + 0
ggT(384, 72) = 24
        24
xggt(384,72)
384 = 5*72 + 24
        t1 = 1 - 5*0 = 1        u = 0 v1 = 1
72 = 3*24 + 0
        t1 = 0 - 3*1 = -3       u = 1 v1 = -3
1*384 + -5*72 = 24
        24
p=8947467598679584; q=8767589678596794;
        p = 8947467598679584
        q = 8767589678596794
46854895*859768956 mod (p*q)
        40284384157639620

EDIT: c) und vielleicht auch b) kann man ja weglassen und einen Benchmark für 10000!, einige Divisionen und Potenzieren in Z/nZ durchführen.

Gregor

Das sieht sehr interessant aus. Schick doch mal den Quellcode und eine lauffähige Linux-Variante an @.*. Wird aber, wie schon gesagt, ne ganze Zeit dauern. Meine Prüfung ist am 13.10. und ich werde vermutlich erst danach dazu kommen, mich intensiver damit zu beschäftigen.

EDIT: Adresse wegeditiert.

*aleph_0

Ich schicke es dir morgen Abend. Bis zum 13.10. kann ich vielleicht noch ein paar mehr Funktionen einbauen; aber wenn man um 17:30 von der Schule heimkommt, hat man auch nicht so viel Zeit...

Gregor

\aleph_0 schrieb:

Ich schicke es dir morgen Abend. Bis zum 13.10. kann ich vielleicht noch ein paar mehr Funktionen einbauen; aber wenn man um 17:30 von der Schule heimkommt, hat man auch nicht so viel Zeit...

Lass dir ruhig Zeit. Reicht auch, wenn du es erst am 13. schickst.