Geschwindigkeitstest: Java, dann VB und dann C++

tntnet

sebi707 schrieb:

tntnet schrieb:

Ein wesentlicher Unterschied ist, dass ein int in C++ auf einer 64-Bit-Plattform 64 Bit groß ist.

Irgendwie nicht. Außer du benutzt irgendwas sehr merkwürdiges (https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models).

Oh man. Man sollte so spät nicht mehr im Forum schreiben. Eigentlich hätte ich es wissen müssen. Ihr habt ja so recht. Int ist immer 32 Bit.

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?