C++ langsamer als Java ?

Seiten: 1
mijuprog
Verfasst am: 15.06.2015 um: 20:18 Uhr
 
Cw Guru
King
Beiträge: 708
SPAM:
0% Spam
Ich fange grad ein bisschen mit C++ an.
Um ein bisschen reinzukommen hab ich ein bisschen mit Rekursionen (Fibonacci, fiktiven, binären baum abschreiten ...)

Anschließend verwendete ich den selben code bei java, um die performance zu vergleichen.

Ich erhielt ein überaschendes Ergebnis:Java war um einiges schneller.

Jetzt die Frage: wieso dieses unerwartete Ergebnis?

verwendet wurden Oracle Java 8 und gcc auf Debian 8.


Meine Vermutung geht in diese Richtung: Otimierungen bei java, die bei normaler c++ kompilierung nicht gemacht werden

<code>Mein projekt :




 



markush
Verfasst am: 15.06.2015 um: 20:37 Uhr
 
Dr. CwCity.de
Community God
Beiträge: 3832
SPAM:
0% Spam
Was sagen die Zeit, wenn du das Programm mit
$ time programmname
startest?

Der Link zu meinem Github Profil

Weitere Links:
--> ratgeber---forum.de (Danke für die Unterstützung) <--
 

mijuprog
Verfasst am: 16.06.2015 um: 16:33 Uhr
 
Cw Guru
King
Beiträge: 708
SPAM:
0% Spam


C++





real    0m2.251s
user    0m2.256s
sys    0m0.000s


Java



real    0m1.591s
user    0m1.580s
sys    0m0.016s

Edit:
Ich hatte Recht mit meiner Vermutung.
Mir ist gerade wieder eingefallen, dass man gcc ja zur Optimierung mit -O[x] zwingen muss
Jetzt ist die Welt wieder in ordnung.
C++ mit -O3:

real    0m0.781s
user    0m0.780s
sys    0m0.000s





<code>Mein projekt :






Letzte Änderung am: 16.06.2015 um: 18:42 Uhr durch: mijuprog
 

peter-sulzer
Verfasst am: 23.06.2015 um: 02:53 Uhr
 
Cw Aufsteiger
Aufsteiger
Beiträge: 59
SPAM:
0% Spam
Assembler langsamer als C (C++) ?

Könnte ich genau so fragen, und sogar mit JA beantworten.

Ist natürlich Bullshit.

Ich kann nur einen Assembler auf einem Betriebssytem wirklich gut: 68000er auf QDOS. QDOS ist das preemptive 32-Bit-Multitaskingbetriebssystem des Sinclair QL von 1984.

Assembler bringt (außer für spezielle Anwendungen, die man weitgehend ohne Betriebssystemberücksichtigung programmieren kann) nur was, wenn auch das BS selbst in Assembler geschrieben ist. Ansonsten verwendet man besser den Compiler, mit dem auch das BS selbst geschrieben ist (also Visual Studio C/C++ für Windows z. B.).

Also ich hatte damals in C ein Programm geschrieben, welches 2 Dateien vergleicht und ausgibt, ob sie gleich sind (bzw. verschieden).

Der Grund-Algorithmus war ungefähr:

#define DIFFERENT 0 // Dateien sind unterschiedlich
#define MATCH 1 // Dateien sind gleich
file *sp, *dp;
int c;

while (c=getc(sp) != EOF) {
if (c == getc(dp))
continue;
else
return DIFFERENT;
}

Entscheidend ist die getc()-Funktion: Die liest ein Byte (ein Character, 8 Bit), liefert aber einen Integer-Wert 16 Bit). Die oberen 8 Bit ignoriert es mit der Ausnahme, das alle 16 Bit 1 sind (-1), das ist (normalerweise unter C nämlich EOF - End Of File).

In QDOS gibt es einen Betriebssystemaufruf, der was ähnliches macht, wie die Standard-C-Funktion getc():

IO.FBYTE (die genauere Beschreibung, in welchen Prozessorregistern man welche Parameter übergeben muss, spare ich mir, ist für das Verständnis, warum C schneller sein kann als Assembler nicht relevant).

Schreibt man jetzt ein Assemblerprogramm, das das gleiche macht, wie obiges C-Programm, ist das C-Programm wesentlich schneller (schätze mindestens Faktor 10).

???

Ganz einfach: IO.FBYTE ist ein BS-Aufruf, der ein Byte von einem Kanal (einem Stream, ...) holt (über die entsprechende BS-Funktion).

getc() holt auch ein Byte (bzw. ein int). Der große Unterschied: getc() ist gepuffert (man kann eine einfache Implementierung von getc im "Kernighan Ritchie" nachlesen). Gepuffert heißt: Die zu <stdio.h> zugehörige Library liest bei getc (printf, ...) nicht nur ein Byte ein, in dem es (unter QDOS) IO.FBYTE aufruft. Sondern es liest (so ist es in meinem uralten K&R) auf einmal gleich 256 Bytes ein (geht unter QDOS IMO mit IO.FSTR - weiß nicht genau).

Damit ist natürlich klar, dass C wesentlich schneller ist, als Assembler. Assembler ruft für 256 Zeichen jedes mal (256 mal) eine BS-Funktion auf (da müssen - BS-Aufruf - alle Register gesichert werden - stimmt bei QDOS nicht ganz, bei jedem BS-Aufruf ist festgelegt, welche Register durch den Aufruf geändert worden sein können). C ruft für 256 Zeichen dagegen ein einziges mal eine BS-Funktion auf und speichert die 256 Zeichen in einem Puffer im RAM. Danach holt es die nächsten 256 Zeichen aus dem Puffer (RAM) und erst dann muss es wieder Zeichen aus dem Kanal (Stream) lesen.

Selbstverständlich kann man in Assembler auch einer Library schreiben, die genau das gleiche macht, wie die C-Funktion, und schon ist Assembler wieder ein bischen schneller als C. Wirklich nur ein bischen, da der größte Teil der Zeit im Lesen verbracht wird, was eine BS-Funktion ist, die sowohl C als auch Assembler aufrufen müssen und in diesem "Prozess" keinen Einfluss auf die Ausführungszeit haben.

Edit: Eine schließende Klammer versetzt, damit der Satz einen Sinn ergibt.

http://peter-sulzer.cwsurf.de

Letzte Änderung am: 24.06.2015 um: 01:53 Uhr durch: peter-sulzer
 

mikespeier
Verfasst am: 23.06.2015 um: 10:22 Uhr
 
Cw's Alleinunterhalter
Alleinunterhalter
Beiträge: 356
SPAM:
0% Spam
  
Zitat von mijuprog
Jetzt die Frage: wieso dieses unerwartete Ergebnis?


Wie wäre es mit fehlerhaften Quellcode? Ich kann dir auch ein Programm in Basic und Assembler schreiben, welches in Basic aber auf jeden Fall schneller ist!

Es kommt immer darauf an, wie man programmiert. Meine Zeit als Programmierer ist zwar lange vorbei, ich bin mir allerdings sicher, daß ich auf meinem alten ATARI 800 XL in Turbo-Basic ein Programm schreiben kann, welches mit Assembler auf einem modernen Rechner wesentlich langsamer ist! ;-)

*** TmoWizard ***


TmoWizard's IRC-Room (Geht nicht mit Opera, siehe >hier<!)


Little things I do directly, miracles take a somewhat longer and after Midnight will be conjured! Zaubersmilie
 

consider
Verfasst am: 23.06.2015 um: 16:08 Uhr
 
Dr. CwCity.de
Community God
Beiträge: 7217
SPAM:
0% Spam
Wenn du die Hardware änderst, nimmst du aber auch jede Vergleichbarkeit.

 

 
Seiten: 1

Folgende User sind hier gerade aktiv:
-

ANZEIGE