Entwickler-Ecke

Algorithmen, Optimierung und Assembler - Laufzeit unterschied Java / C++ (C)


thepaine91 - Di 03.11.15 21:18
Titel: Laufzeit unterschied Java / C++ (C)
Hi,

ich habe das selbe Problem einmal mit Java und einmal mit C++ gelöst. Die Laufzeit bei Java mit dem selben Input = 0.218 bei C++ < 0.000.
Das Java grundsätzlich langsamer ist macht Sinn das es so viel langsamer ist i-wie nicht. Kennt sich jemand mit Java gut genug aus um den Unterschied zu erklären?
Ich vermute persönlich das es am Scanner liegt und es vielleicht eine effizientere Funktion zum ein-/auslesen gibt.
Es würde mich freuen wenn jemand etwas dazu sagen kann.

MFG
Nicolas


Java
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
public static void main(String[] args) {
    
  Scanner inputScanner = new Scanner(System.in);
    
  int amount = inputScanner.nextInt();
  for (Integer i = 1; amount >= 0; i++) {
    Integer pasteReq;
    int check = 1;
    for (pasteReq = 0; amount > check; pasteReq++)  
      check = check << 1; // * 2
        
    System.out.println("Case " + i.toString() + ": " + pasteReq.toString());
    amount = inputScanner.nextInt();
  }
    
  inputScanner.close();
  }



C++
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
int main()
{    
  int amount;
  scanf("%d", &amount);
  for (int i = 1; amount >= 0; i++) {
    int check = 1;
    int pasteReq;
    for (pasteReq = 0; amount > check; pasteReq++)  
        check = check << 1; // * 2
        
    printf("Case %d: %d\n", i, pasteReq);
    scanf("%d", &amount);
  }
}


jfheins - Di 03.11.15 22:26

Ein- und Ausgabe ist eh immer schnarchlahm, das ist hier vermutlich der Flaschenhals. Alternativ der Startup der JRE, ich sehe da leider keine Zeitmessung im Code. :nixweiss:


thepaine91 - Di 03.11.15 22:45

Das stimmt allerdings, jedoch möchte ich die Hoffnung nicht aufgeben, dass man es dennoch verbessern kann. Java dürfte sowieso in der Hinsicht niemals C/C++ gleichkommen.

Das ganze wird automatisch bewertet und gemessen. Ich weiß weder input noch output, lediglich ob es erfolgreich war und ggf. die Laufzeit.


C# - Mi 04.11.15 02:58

Das Java immer langsamer als C++ ist stimmt mittlerweile nicht mehr. Auch wenn es manche nicht glauben hat auch Java sich weiterentwickelt (obwohl ich zugegebenermaße kein großer Fan von Java bin). Durch Compileroptimierung und vor allem dem Hotspot-Compiler kann Java in vielen Dingen mit C++ gleich ziehen. Im Bereich Speicherperformance glaube ich allerdings das C++ Java abhängt ganz einfach weil C++ unmanaged Code ist und sich da einiges an overhead spart (z.B. den Garbage Collector).

Aber wie jfheins schon gesagt hat ist die EA meistens der Klotz auf der Bremse. Kommentiere einfach mal alle EA Befehle aus und übergib ein paar bekannte Werte (z.B. aus einem Vordefinierten Array). Dann kannste sehen ob die EA bei den beiden Sprachen ein unterschied im Tempo macht.
Was den Start der JVM angeht versuche einfach mal das Programm mit sehr vielen Daten zu füttern, sprich die Schleife ein paar Millionen mal laufen lassen. Dann relativiert sich auch der Start der JVM.


Delete - Mi 04.11.15 18:23

Vergleich INTERPRETER - COMPILER [https://www.google.de/search?q=vergleich+interpreter+compiler&ie=utf-8&oe=utf-8&gws_rd=cr&ei=QzA6VrH3LoHTygPpiqnQBw]


Ralf Jansen - Mi 04.11.15 18:24

Wo ist hier ein Interpreter beteiligt :gruebel:


Delete - Mi 04.11.15 18:40

JIT-Compiler (JIT = Just in time)

Es gibt auch Programmiersprachen, wie zum Beispiel C# und Java, die Compiler und Interpreter kombinieren. Wie beim Interpreter wird der Quelltext in Hardware-unabhängige VM-Anweisungen (Bytecode) übersetzt. Bei der Ausführung dieser Anweisungen durch den JIT-Compiler werden die Anweisungen in Maschinencode übersetzt. Der JIT-Compiler berücksichtigt dabei die verschiedenen Eigenheiten des Prozessors.


Ralf Jansen - Mi 04.11.15 18:48

Zitat:
Es gibt auch Programmiersprachen, wie zum Beispiel C# und Java, die Compiler und Interpreter kombinieren.


Ok. Ich würde der Ansicht wiedersprechen das ein JIT-Compiler eine Compiler-Interpreter-Kombination ist. Aber da landen wir letztlich wohl bei Wortklauberei die (insbesondere) hier nicht hilfreich wäre.