Java vs. C++

Zeus

Tobiking2 schrieb:

HansKlaus schrieb:

grundsätzlich gilt, dass die javavm einen interpreter darstellt und dass dieser interpreter naturgemäß einfach mehr rechenzeit beansprucht, als opcodes.

Die JVM hat auch einen JIT Compiler aus dem Opcodes rauspurzeln. Die Begründung passt also nicht.

class jvm
{
stack<call_frame> callStack;
stream<byte_code> byteCode;
mapped_file<native_code> nativeCode;
map<byte_code*, native_code*> codeCache;
}

Ach wieso nicht? Nur weil Opcodes generiert wird?

Kritischer Geist schrieb:

Kritischer Geist schrieb:

Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

*push*

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp

benchm schrieb:

Kritischer Geist schrieb:

Kritischer Geist schrieb:

Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

*push*

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp

Danke! Da schneidet ja C++ immer deutlich besser als Java ab.

Gregor

Kritischer Geist schrieb:

benchm schrieb:

Kritischer Geist schrieb:

Kritischer Geist schrieb:

Gibt es irgendwo *gute* Benchmarks für Java vs. C++, also bei denen das Programm in der jeweiligen Sprache immer bestmöglichst die Sprachfeatures ausnutzt (nicht so wie der olle c't-Test, wo Strings in C++ per value (!) übergeben wurden)?

*push*

https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=gpp

Danke! Da schneidet ja C++ immer deutlich besser als Java ab.

Es ist durchaus bekannt, dass C++ Programme etwas schneller als Javaprogramme laufen. Man nutzt Java aber auch nicht, wenn es einem darum geht, das performanteste Programm zu schreiben. Java nutzt man aus anderen Gründen, zum Beispiel könnte die Infrastruktur im Umfeld der Sprache relevant sein und das verfügbare Know-How diesbezüglich. In Sachen Performance reicht es für Java völlig aus, halbwegs in der gleichen Liga wie C++ zu spielen. Wenn Javaprogramme grundsätzlich >10 mal langsamer als C++ Programme wären, dann wäre das für Java wohl ein Problem. So ist es aber nicht.

Kritischer Geist schrieb:

Danke! Da schneidet ja C++ immer deutlich besser als Java ab.

das ist jetzt nichts besonderes und eigentlich habe ich dir das ja auch so gesagt. prinzipiell schneidet C sogar noch ein bisschen besser ab, aber jeder, der mal eine grafische oberfläche mit der winapi erstellt hat, weiß diese vereinfachungen, wie java sie mit sich bringt, zu schätzen.

prinzipiell schneidet C sogar noch ein bisschen besser

Das stimmt so leider gar nicht - wird aber gerne immer und immer und immer wieder angeführt

C++ erlaubt viel besseres inlining (z.B. mit templates) - selbst mit C Macros kommt man nicht auf das Niveau
und auch der schlimme Code-Bloat von denen viele erzählen ist Seemannsgarn das gerne und vielfach von unerfahrenen Entwicklern einfach weiter gesponnen wird

Naja es gibt schon Dinge, für die c besser geeignet ist, als c++,einfach weil c schneller ist.
Also ein c-programm ist natürlich ein c++-programm, wenn auch kein gutes, aber warum den c++-compiler mit c-code füttern, statt gleich den richtigen compiler zu nehmen?

dot

HansKlaus schrieb:

Naja es gibt schon Dinge, für die c besser geeignet ist, als c++,einfach weil c schneller ist.

Nope. Du kannst in C++ oft wesentlich schneller sein als in C, langsamer zu sein geht aber nur mit schlechtem Code...

für die c besser geeignet ist, als c++,einfach weil c schneller ist.

das ist aber eben definitiv falsch - C ist in keinem Fall schneller als C++ - an was denkst du denn bei solchen Aussagen? die Inline-Fähigkeit von C++ kann man in C nicht oder nur mit sehr viel Aufwand erreichen - du verbreitest schon wieder Geschwindigkeits-Mythen im Internet (das 1. mal hier https://www.c-plusplus.net/forum/p2507658)

Gast3 schrieb:

an was denkst du denn bei solchen Aussagen?

hmmm ablaufsteuerungen z.b.?

Ablaufsteuerungen? Was soll den der Käse?

Im Gegensatz zu C kennt C++ so einige Sprachelemente, die sich zur Kompilierzeit auflösen lassen und womit enorm viel Laufzeit gespart werden kann. Templates, constexpr... machts möglich.

So ist der C++ STL Quicksort sehr viel schneller als der der C Standard Bibliothek. Beides generische Varianten. Der Unterschied ist, dass der C++ Kompiler den Vergleich zweier Elemente einfach inlinen kann und sich pro Vergleich einen Funktionsaufruf spart.

http://www.geeksforgeeks.org/c-qsort-vs-c-sort/

STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function.

STL’s sort runs 20% to 50% faster than the hand-coded quicksort and 250% to 1000% faster than the C qsort library function.

Ein anderes Beispiel ist das Durchsuchen von Lookup Tabellen oder Berechnungen die zur Kompilierzeit ausgeführt werden können, wenn die Eingangsdaten zur Kompilierzeit bekannt sind.

constexpr int factorial(int n)
{
    return n <= 1? 1 : (n * factorial(n - 1));
}

Das hier rechnet dir der Kompiler zur Kompilierzeit aus, wenn n bekannt ist. Oder eben zur Laufzeit, wenn nicht. Kein extra code.

Und das hier ist nur die Spitze des Eisbergs. C++ ist wesentlich mächtiger als C und trotzdem genauso performant.

Zeus

QSort schrieb:

http://www.geeksforgeeks.org/c-qsort-vs-c-sort/

STL’s sort ran faster than C’s qsort, because C++’s templates generate optimized code for a particular data type and a particular comparison function.

STL’s sort runs 20% to 50% faster than the hand-coded quicksort and 250% to 1000% faster than the C qsort library function.

Irgendwelche ein Idiot in Internet postet Sache die mir gefallen.

Theoretisch gibst es kein Unterschied zu Optimierung von einfachen C-Funktionen oder C++ Template Funktion.

Praktisch liegt es an dem Implementierung(Compiler) und/oder am der Person, die die Implementierung benutzt.

Code aus URL (angepasst):
- include eingefügt
- N 100000

Visual Studio 2015
Einstellung Standard

C:\Users\zeus\Desktop\Project1\Debug>Project1.exe
Time taken by C qsort() - 0.052
Time taken by C++ sort() - 0.175

C:\Users\zeus\Desktop\Project1\Release>Project1.exe
Time taken by C qsort() - 0.015
Time taken by C++ sort() - 0.006

Ops C war einmal schneller

Th69

Naja, im Debug-Mode zu vergleichen ist ja auch völliger Käse - ist als ob du 2 Autos vergleichst, welche mit angezogener Handbremse fahren

also ich hab mir das jetzt eben mal kurz angesehen. wenn ich das richtig verstanden habe, werden da zwei verschiedene sortierverfahren (namentlich quicksort und introsort) gegenüber gestellt.

außerdem hab ich mir hier mal sagen lassen, dass es nicht gut ist, wenn ich c-funktionen durch den c++-compiler schicke.

Zeus schrieb:

Irgendwelche ein Idiot in Internet postet Sache die mir gefallen.

Theoretisch gibst es kein Unterschied zu Optimierung von einfachen C-Funktionen oder C++ Template Funktion.

Für generischen Code eben schon.

Zeus schrieb:

C:\Users\zeus\Desktop\Project1\Debug>Project1.exe
Time taken by C qsort() - 0.052
Time taken by C++ sort() - 0.175

C:\Users\zeus\Desktop\Project1\Release>Project1.exe
Time taken by C qsort() - 0.015
Time taken by C++ sort() - 0.006

Ops C war einmal schneller

Dazu wurde ja alles gesagt.

HansKlaus schrieb:

also ich hab mir das jetzt eben mal kurz angesehen. wenn ich das richtig verstanden habe, werden da zwei verschiedene sortierverfahren (namentlich quicksort und introsort) gegenüber gestellt.

Nunja introsort ist quicksort, aber da hast du recht. Trotzdem kann die C++ den Vergleich inlinen, C nicht.

Das Einzige was C++ nicht kann aber C, sind restricted pointer. Hab ich aber noch nirgendwo gesehen. C++ hat dafür aber move semantics, (const) references und was mir gerade noch so nicht einfällt. Damit kann man sicher auch Laufzeit sparen.

Zeus

C:\Users\zeus\Desktop\Project2\Win64\Release>Project1.exe
Time taken by C++ sort() - 0.016
Time taken by C qsort() - 0.031

C:\Users\zeus\Desktop\Project2\Win64\Release>Project1.exe
Time taken by C qsort() - 0.016

Ohne weitere Worte

Echt toll, dass du die Zeit der C++ Version weglässt. Absicht?

Du weißt schon, dass bei jedem Programmdurchlauf andere Werte vorliegen und du deshalb Äpfel mit Birnen vergleichst?

$ g++ qsort.cpp -O2 -o qsort
$ ./qsort 
Time taken by C qsort() - 0.167546
Time taken by C++ sort() - 0.063008

Zeus

Ich vergleiche nix, genau du vergleichst Äpfel mit Birnen

Propo sind die Test die ich hier poste nur ein Teil was ich wirklichh poste... es ist nur idotisch von solche Microbrench überhaupt eine Aussage zu treffen.

Oder erkläre mir wieso die C Version auf einmal doppelt/dreimal so schnell wird, wenn man die C++ Version weglässt.

Unter der Prämisse das die Programme unter N mal beobachtet wurden.

Zeus schrieb:

Ich vergleiche nix, genau du vergleichst Äpfel mit Birnen

Tipp: Wenn du ernst genommen werden willst, lasse andere nicht rätselraten.

Propo sind die Test die ich hier poste nur ein Teil was ich wirklichh poste... es ist nur idotisch von solche Microbrench überhaupt eine Aussage zu treffen.

Oder erkläre mir wieso die C Version auf einmal doppelt/dreimal so schnell wird, wenn man die C++ Version weglässt.

Unter der Prämisse das die Programme unter N mal beobachtet wurden.

Sicher dass du den richtigen Code gelöscht hast? Das Verhalten kann ich nicht nachvollziehen, bei mir bleiben die Laufzeiten stabil und die C Version langsamer (Visual Studio 2015 Release und ebenso mit GCC). Auch seltsam, bei dir dass die C Version auch noch exakt so lang braucht wie C++.

C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort.exe
Time taken by C qsort() - 0.193
Time taken by C++ sort() - 0.096

C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort.exe
Time taken by C qsort() - 0.195

C:\Users\X\Documents\Visual Studio 2015\Projects\QSort\Release>QSort
Time taken by C++ sort() - 0.094

C Version

// C++ program to demonstrate performance of
// C qsort and C++ sort() algorithm
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <ctime>

using namespace std;

// Number of elements to be sorted
#define N 1000000

// A comparator function used by qsort
int compare(const void * a, const void * b)
{
	return (*(int*)a - *(int*)b);
}

// Driver program to test above functions
int main()
{
	int arr[N], dupArr[N];

	// seed for random input
	srand(time(NULL));

	// to measure time taken by qsort and sort
	clock_t begin, end;
	double time_spent;

	// generate random input
	for (int i = 0; i < N; i++)
		dupArr[i] = arr[i] = rand() % 100000;

	begin = clock();
	qsort(arr, N, sizeof(int), compare);
	end = clock();

	// calculate time taken by C qsort function
	time_spent = (double)(end - begin) / CLOCKS_PER_SEC;

	cout << "Time taken by C qsort() - "
		<< time_spent << endl;

	return 0;
}

Warum die C Version ohne den unteren C++ Code plötzlich schneller sein soll, ist sowieso absolut unlogisch. Also keine Ahnung was du da kompiliert hast...

Zeus

Sorry, wer diesen Artikel postet, ist nicht ernst zu nehmen!

Code:

#include <algorithm> 
#include <cstdlib> 
#include <iostream> 
#include <ctime>

using namespace std;

// Number of elements to be sorted
#define N 100000

// A comparator function used by qsort
int compare(const void * a, const void * b)
{
	return (*(int*)a - *(int*)b);
}

// Driver program to test above functions
int main()
{
	int arr[N], dupArr[N];

	// seed for random input
	srand(time(NULL));

	// to measure time taken by qsort and sort
	clock_t begin, end;
	double time_spent;

	// generate random input
	for (int i = 0; i < N; i++)
		dupArr[i] = arr[i] = rand() % 100000;

	begin = clock();
	qsort(arr, N, sizeof(int), compare);
	end = clock();

	// calculate time taken by C qsort function
	time_spent = (double)(end - begin) / CLOCKS_PER_SEC;

	cout << "Time taken by C qsort() - "
		<< time_spent << endl;

	time_spent = 0.0;

	begin = clock();
	sort(dupArr, dupArr + N);
	end = clock();

	// calculate time taken by C++ sort
	time_spent = (double)(end - begin) / CLOCKS_PER_SEC;

	cout << "Time taken by C++ sort() - "
		<< time_spent << endl;

	return 0;
}

Projectsettings:
Dynamic
- General/Whole Program Optimiziation = Use Link Time Code Generation
- C/C++/Optimization/Optimization = Maximize Speed (/O2)
- C/C++/Optimization/Inline Function Expansion = Default
- C/C++/Code Generation/Runtime Library = Multi-threaded DLL (/MD)
- Linker/Optimization/Link TIme Code Generation = Use Link Time Code Generation (/LTCG)

Static
- General/Whole Program Optimiziation = Use Link Time Code Generation
- C/C++/Optimization = Maximize Speed (/O2)
- C/C++/Optimization/Inline Function Expansion = Any Suitable (/Ob2)
- C/C++/Code Generation/Runtime Library = Multi-threaded (/MT)
- Linker/Optimization/Link TIme Code Generation = Use Link Time Code Generation (/LTCG)

Inline Function Expansion für Dynamic wurde so gewählt, dass es zu sehen ist, dass Compare aufgerufen wird - ein Nachteil war nicht festzustellen!

Runtime Output

C:\Users\patri_000\Desktop\Project1\x64\Release>Project1_static.exe
Time taken by C qsort() - 0.012
Time taken by C++ sort() - 0.007

C:\Users\patri_000\Desktop\Project1\x64\Release>Project1_dynamic.exe
Time taken by C qsort() - 0.013
Time taken by C++ sort() - 0.006

Profiler Result - Call Tree
Dynamic
1. Project1.exe (100%)
1.1. main (81.82%)
1.1.1. [external code] (59.09%)
1.1.1.1. compare (18.18%)
1.1.2. std::_Sort (22.73%)

Static
1. Project1.exe (100%)
1.1. main (84.21%)
1.1.1. qsort (47.37%)
1.1.2. std::_Sort (21.05%)
1.1.3. std::op < (5.26%)
1.1.4. rand (5.26%)

Conclusion:
- Ohne den Assemblercode zu untersuchen ist eine korrekte Aussage schwer zu treffen.
- der CallTree zeigt, dass die Inline der Compare-Funktion ein Speedup von ≈ 12% -+x beträgt
- die C++ Variante braucht aber knapp die Hälfte der Zeit zum Sortieren
=> die Sortierverfahren waren sowieso nicht vergleichbar um ein Inline-Speedup zu zeigen:

https://de.wikipedia.org/wiki/Introsort schrieb:

Introsort ist ein Sortieralgorithmus. Der Begriff ist eine Kurzform für „introspektives Sortieren“. Der Algorithmus ist eine Variation von Quicksort, welche in entarteten Fällen auf ein anderes Sortierverfahren mit Worst-Case-Laufzeit {\displaystyle {\mathcal {O}}(n\log n)} {\mathcal {O}}(n\log n) (zum Beispiel Heapsort) zurückfällt. Dazu wird zu Beginn jedes Rekursionsschrittes anhand einer Bewertungsfunktion entschieden, ob ein anderer Algorithmus für die Sortierung der Teilliste verwendet werden soll (zum Beispiel bei Erreichen einer bestimmten Rekursionstiefe).