Geschwindigkeitstest: Java, dann VB und dann C++

Atlan

@dot
Mit Durchlauf meinte ich hier ein mal "von Klammer zu Klammer" und nicht bis zum Verlassen des Blocks.
Unsortierte Werte versuche ich nachher nochmal.

kurze_frage

wie wäre es mit etwas mehr Praxis relevanten vergleichen,
die Ints einfach mal in Klassen stecken und dann damit arbeiten.
weil ints sind in Java keine Klassen und daher in der Regel auch nicht das was die Performance eines Programms ausmacht und der Unterschied in diversen Sprachen sollte beim Int sortieren Null oder fast Null sein.

die Ints einfach mal in Klassen stecken und dann damit arbeiten.

und was soll dann das für die Analyse des Laufzeitunterschieds zwischen C++ und Java bringen?

hustbaer

Gast3 schrieb:

die Ints einfach mal in Klassen stecken und dann damit arbeiten.

und was soll dann das für die Analyse des Laufzeitunterschieds zwischen C++ und Java bringen?

Java wird haushoch verlieren? Weil es keine Value-Types kann?

kurze_frage

hustbaer schrieb:

Gast3 schrieb:

die Ints einfach mal in Klassen stecken und dann damit arbeiten.

und was soll dann das für die Analyse des Laufzeitunterschieds zwischen C++ und Java bringen?

Java wird haushoch verlieren? Weil es keine Value-Types kann?

ob es so wäre oder nicht könnte durch einen Praxis relevanten Test der nicht nur Ints vergleicht sondern sich an der Realität orientiert und mit Objekten arbeitet festgestellt werden.

Das Durchlaufen der Schleife in entgegengesetzter Richtung läuft bei mir deutlich schneller (8.5s zu 5.3s)

do 
	{
		swapped = false;    //wahrheitsgemäß. Es wurde noch nicht getauscht
		for (int i = observedElems-1; i > 0; --i) 
		{  
			if (array[i-1] < array[i])
			{ 
				aid = array[i - 1];
				array[i - 1] = array[i]; 
				array[i] = aid; 
				swapped = true;
			}
		}
		--observedElems;
	} while (swapped);//Bediungung der do-while-Schleife

Vielleicht ist es ja das, was der JIT macht.

asdfasdf schrieb:

Das Durchlaufen der Schleife in entgegengesetzter Richtung läuft bei mir deutlich schneller (8.5s zu 5.3s)
do 
	{
		swapped = false;    //wahrheitsgemäß. Es wurde noch nicht getauscht
		for (int i = observedElems-1; i > 0; --i) 
		{  
			if (array[i-1] < array[i])
			{ 
				aid = array[i - 1];
				array[i - 1] = array[i]; 
				array[i] = aid; 
				swapped = true;
			}
		}
		--observedElems;
	} while (swapped);//Bediungung der do-while-Schleife
Vielleicht ist es ja das, was der JIT macht.

Hast du mal probiert, ob das überhaupt noch sortiert?

javadoof schrieb:

Hast du mal probiert, ob das überhaupt noch sortiert?

Ja und Ja

asdfasdf schrieb:

javadoof schrieb:

Hast du mal probiert, ob das überhaupt noch sortiert?

Ja und Ja

Lustig, bei mir wird die Eingabe 0,1,2 (verkehrt vorsortiert) zu 2,0,1 "sortiert".

Stimmt, war quatsch. Sorry for the inconvenience. Hätte nicht nur einen Lauf kontrollieren sollen

hustbaer schrieb:

Gast3 schrieb:

die Ints einfach mal in Klassen stecken und dann damit arbeiten.

und was soll dann das für die Analyse des Laufzeitunterschieds zwischen C++ und Java bringen?

Java wird haushoch verlieren? Weil es keine Value-Types kann?

Und auch noch std::string in std::vector sortieren mit RAII (weil Raw-Pointer keiner mehr macht), damit C++ haushoch verliert. Oder vielleicht einen smartpointer der den std::string hält, damit C++ wieder eine Chance haben könnte. Aber baut hier wirklich einer sowas vector< unique_ptr <string > > >?

Techel

Eher std::list<std::shared_ptrstd::string> damit java überhaupt ne chance hat

hallo123test schrieb:

Und auch noch std::string in std::vector sortieren mit RAII (weil Raw-Pointer keiner mehr macht), damit C++ haushoch verliert.

Wie was? Was soll string in vector mit RAII sein? String verwaltet doch schon seine Resourcen selbst und einen std::vector<std::string> zu sortieren dürfte dank move auch schön schnell sein.

sebi707 schrieb:

hallo123test schrieb:

Und auch noch std::string in std::vector sortieren mit RAII (weil Raw-Pointer keiner mehr macht), damit C++ haushoch verliert.

Wie was? Was soll string in vector mit RAII sein? String verwaltet doch schon seine Resourcen selbst und einen std::vector<std::string> zu sortieren dürfte dank move auch schön schnell sein.

Vergleich mal.

kurze_frage

hallo123test schrieb:

sebi707 schrieb:

hallo123test schrieb:

Und auch noch std::string in std::vector sortieren mit RAII (weil Raw-Pointer keiner mehr macht), damit C++ haushoch verliert.

Wie was? Was soll string in vector mit RAII sein? String verwaltet doch schon seine Resourcen selbst und einen std::vector<std::string> zu sortieren dürfte dank move auch schön schnell sein.

Vergleich mal.

sowieso, irgendwelche Kunst Konstrukte wie das vorgeschlagene vector<uniquer_ptr<T>> sind nicht notwendig
und selbst in alten C++ gcc hat eine, nicht ganz dem Standard entsprechende, copy on write Implementierung von std::string.die ist sicher recht flott

ich denke das, wenn man wirklich messen möchte wie sich diverse Sprachen austesten, sollte ungefähr so etwas genommen werden,

class A
{
public:
  int i ;
  float f;
};

class B {
public:
 A a ;
 string s;
};

erzeuge listen, sortiere , such , member zugriff, ....

man kann dann noch immer noch Integers und Floats vergleichen dividieren und seine Überraschungen erleben.

Wollte nur mal anmerken, dass C++ bei den meisten Benchmark-Games gegen Java gewinnt. Eben nicht bei allen, aber bei den meisten:

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

Interessant finde ich auch, dass rust in 5 von 11 Benchmarks schneller als C++ ist:

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

rust ist noch recht jung und da ist sicherlich noch einiges rauszuholen. Bin da wirklich optimistisch. rust kann wohl als einzig wahrer C++ Nachfolger betrachtet werden.

Mechanics

Aber wenn man sich die Tabelle anschaut, gibts öfter mal mehrere Implementierungen. z.B. bei dem fasta Test ist Rust #2 ganz oben, es gibt aber auch eine Rust Implementierung, die langsamer ist als C++. Ist also nicht gesagt, dass der C++ Code wirklich optimal ist.

Da man immer wieder optimierten Code einreichen kann, konvergieren die Benchmarks wohl langsam aber sicher gegen das Optimum, das mit der Sprache möglich ist.
C++ ist schon lange dabei...

hustbaer

Ich wollte gerade probieren ob ich die C++ Version des "k-nucleotide" Tests etwas schneller bekomme (kann mMn. kein Problem sein)...

Bloss sieht es so aus als ob das Test Output-File nicht zum angegebenen Test Input-File passt.

Denn sogar der aktuelle C++ Code von der Webseite wirft da andere Ergebnisse aus.

Tjoah. Doof.

EDIT: Findet jemand ne Email Adresse wo man da mal hinschreiben könnte?

Atlan

@Benchmark
Was ist mit D? D sieht auch recht vielversprechend aus, da es die starke Objektorientierung von Java mit Zeigern, Referenzen und dem schnellen Code von C++ verbindet.

@Hustbaer
Ich habe es mit mehreren Onlinediensten versucht, jedoch habe ich die Seite nur anpingen können.

Ich habe denselben Test nun nocheinmal mit den passenden API-Funktionen in Java und C++ laufen gelassen.
Java hat beim ersten Durchlauf 95.000 Mikrosekunden gebraucht, es wird jedoch mit jedem Durchlauf weniger und das Geringste, was es bei 300 Durchläufen gebraucht hat, sind ca. 7.500 Mikrosekunden.
C++ kann mit weniger, als 2.000 Mikrosekunden locker dagegenhalten.
Java benutzt den Quicksort, C++ einen unbekannten Algorithmus mit O(n log n) im Worst Case, während der Quicksort O(n2) im Worstcase hat.
Es ist aber fast sicher, dass C++ nicht den Quicksort verwendet, da O(n log n) als Worstcase gefordert wird und nicht als Durchschnitt. Vielleicht verwendet C++ Introsort.