C# und Linux
-
Stimmt alles was kingruedi sagte.
Compiliere gerade dot-gnu
Comp fertigHabe exe welches mit VS NET erstellt wurde getestet. Dieses läuft nicht.
Exe von Mono läuft nicht (Unter Mono laufen die Exe welche von VS Net erstellt wurde).Exe von Netgnu unter Windows läuft nicht.
Exe von Netgnu unter Netgnu läuft Warum auch nicht.
Exe von Netgnu unter Mono läuft.Compatibler ist somit Mono
[ Dieser Beitrag wurde am 18.06.2002 um 15:15 Uhr von Unix-Tom editiert. ]
[ Dieser Beitrag wurde am 18.06.2002 um 15:17 Uhr von Unix-Tom editiert. ]
-
Ich schlage einfach mal das Sortieren von 10.000.000 int-Werten vor, da ich da zufälligerweise schon fertigen Java-Code habe.
Hier kommen die Klassen :
Die Sort-Klasse :
[java]
public class Sort
{
private Sort()
{
}public static void sort (int [] a)
{
quickSort (a,0,a.length-1);
}public static void quickSort (int [] a, int begin, int end)
{
int i=begin,j=end;
int pivotElement = a[((end + begin) >>> 1)];
int temp = 0;
while (i < j)
{
while (a[i] < pivotElement) ++i;
while (a[j] > pivotElement) --j;
if (a[i] == (temp = a[j]))
{
++i;
continue;
}
a[j] = a[i];
a[i] = temp;
if (a[i] != pivotElement) ++i;
else
{
temp = ((j-i) >>> 1) + i;
a[i] = a[temp];
a[temp] = pivotElement;
}
if (a[j] != pivotElement) --j;
else
{
temp = ((j-i) >>> 1) + i;
a[j] = a[temp];
a[temp] = pivotElement;
}
}
if ((temp = j - begin) > 18) quickSort (a,begin,j-1);
else if (temp > 1) insertionSort (a,begin,j-1);
if ((temp = end - j) > 18) quickSort (a,j+1,end);
else if (temp > 1) insertionSort (a,j+1,end);
}private static void insertionSort (int [] a, int begin, int end)
{
int j, b;
int temp;
int i = begin;
while (i != end)
{
++i;
temp = a[i];
b = i;
j = i - 1;
while (temp < a[j])
{
a[b] = a[j];
b = j;
--j;
if (b == begin) break;
}
a[b] = temp;
}
}
}[/code]...und die entsprechende Testklasse :
[java]
public class TestKlasse
{
public TestKlasse()
{
}
public static void main(String[] args)
{
int size = 10000000;
int [] a = new int [size];
int highest = 0x7fffffff;
long time;
long timeSort = 0;
int durchläufe = 10;
for (int n = 1 ; n <= durchläufe ; ++n)
{
System.out.println(n + ". Durchlauf :");
for (int i = 0 ; i < size ; ++i)
{
a[i] = (int)(Math.random() * (double)highest);
}
time = System.currentTimeMillis();
Sort.sort(a);
time = System.currentTimeMillis() - time;
System.out.println("Zeit zum Sortieren : " + time + " ms");
timeSort += time;System.out.println("Sort Gesamtzeit für " + String.valueOf(n) +
" Durchläufe : " + timeSort + " ms");
System.out.println("Durchschnittliche Zeit zum Sortieren von " +
String.valueOf(size) + " 32-bit Ganzzahlen : " +
String.valueOf((float)timeSort / (float)n) +
" ms");
}
}
}[/code]
-
Ähm, ist der InsertionSort fest vorgegeben oder darf man da auch andere Sortieralgorithmen verwenden?
MfG SideWinder
-
Ich schlage vor, dass du nehmen darfst, was du willst. Ich habe das Insertionsort aber auch nicht ohne Grund eingebaut. Gegenüber der Nur-Quicksort Variante dauert das Sortieren mit dem Insertionsort bei mir zumindest nicht so lang. Vielleicht hat ja auch noch jemand schnelleren Java-Code zu bieten. Mir ist erstmal nichts eingefallen, wie ich das noch beschleunigen könnte.
-
Um die Ergebnisse wirklich vergleichen zu können müssen beide Kandidaten die selben Algorithmen benutzen. Nur dann kann man die Performance testen. Es ist IMHO klar dass eine Implementation gegenüber der anderen Vorteile hat. Das ist allerdings der menschliche Faktor und hat mit C# bzw. Java nichts zu tun. Also das was für Java genutzt wurde, sollte auch für C# genutzt werden.
-
BTW: Wieso vergleichen wir C#, eine Sprache die für das Bauen von Fenstern gemacht ist, mit einem Sortieralgorithmus den es im Internet assembleroptimiert zu holen gibt?
Würde eher noch warten mit voreiligen Test bis überall die Fenster implementiert sind.
Achja: Wir sollten uns zudem im Klaren sein ob wir .NET oder C# testen wollen...
MfG SideWinder
-
OK CengizS! Du hast Recht. Eigentlich könnte man gleich das Sort nehmen, was es in Java schon gibt. In C# wird es ja wahrscheinlich auch eins geben.
@Sidewinder : Wir testen C#-Code und Java-Code, weil uns der Vergleich zwischen C# und Java interessiert. Assembler interessiert uns dabei garnicht. Man kann natürlich auch anderen Code nehmen und nicht das Sortieren testen, sondern halt etwas anderes.
Edit : Ist C# tatsächlich nur zum Fenster-bauen gedacht? Dann lohnt es sich ja garnicht, sich damit auseinanderzusetzen.
[ Dieser Beitrag wurde am 18.06.2002 um 17:33 Uhr von Gregor editiert. ]
-
Okay, ein Algorithmus ist es auch wert einmal getestet zu werden.
Edit : Ist C# tatsächlich nur zum Fenster-bauen gedacht? Dann lohnt es sich ja garnicht, sich damit auseinanderzusetzen.
Das sicherlich nicht.
C# ist die Sprache, die Microsoft gewählt hat um einen Vertreter für ihre .NET-Plattform zu haben. Tja, und auf was werden sie ihre eigene Plattform optimieren? Wohl auf das, was unter Windows am meisten gemacht wird: gemalt. Alle Reaktionen werden unter Windows gemalt. Die häufigste Malerei sind Text und Fenster - also sollte man hier die Geschwindigkeit testen.
Und hier nochmals meine Frage: Will man .NET testen dann sollte man tatsächlich Fenster malen. Will man die Sprache C# testen sollte man auf Konsolenanwendungen und Algrorithmen ausweichen.
MfG SideWinder
-
Es geht ja darum, dass wir die Performance testen wollen, dass ist schwierig, wenn man 100 Fenster lädt! Also ist es besser einen Algorithmus zu nutzen. Dabei sollte man natürlich den gleichen Algorithmus möglichst gleich effizient implementieren! Am besten wenn mehrere (gute) Leute den Code prüfen!
Außerdem sind die WinForms noch nicht portiert und die brauch man ja für die GUI.
P.S.
wir sollten für Java auch noch den gcj einbeziehen, nur so zum vergleich, nicht als Pluspunkt für Java!
-
Hi, ich würde das Projekt so auslegen, dass der GC zum schwitzen kommt. Da beide Platformen diesen ja intensiv nutzen.
Wenn Mono denn C++ Compiler unterstützt sollte man diesen mit testen.
Grund, C++ ist im managed Bereich auch schneller als die anderen Spachen.
-
Wir brauchen nur noch Leute, die den Code schreiben
-
Beeindruckend viel Halbwissen in diesem Thread
C# ist die Sprache, die Microsoft gewählt hat um einen Vertreter für ihre .NET-Plattform zu haben. Tja, und auf was werden sie ihre eigene Plattform optimieren? Wohl auf das, was unter Windows am meisten gemacht wird: gemalt. Alle Reaktionen werden unter Windows gemalt. Die häufigste Malerei sind Text und Fenster - also sollte man hier die Geschwindigkeit testen.
Du könntest so auch gegen Java argumentieren - was allerdings weder Java, noch C# gerecht wird. Der .NET-JITC ist genauso auf "Standard-Aufgaben" wie Algorithmen o.ä. ausgerichtet, wie die Java-VM. Die .NET-Library bietet ebenfalls Soriterungs-Algorithmen etc. an. Warum sollte man also das Fensterbasteln vergleichen?
Dieser Test wäre noch dazu ein völlig unsinniger Test, da ja nicht der Interpreter das Fenster erzeugt, sondern anderweitige Libs (Windows-API, GTK, bla).
BTW: Wieso vergleichen wir C#, eine Sprache die für das Bauen von Fenstern gemacht ist, mit einem Sortieralgorithmus den es im Internet assembleroptimiert zu holen gibt?
Wer will einen solchen Algorithmus denn in Assembler? C#-Code wird im Endeffekt auch zu JIT-optimierten x86-Assembler, wobei .NET-Code den Umweg über MSIL macht. .NET-Applikationen sind nicht interpretiert.
Wenn Mono denn C++ Compiler unterstützt sollte man diesen mit testen.
Grund, C++ ist im managed Bereich auch schneller als die anderen Spachen.MSIl-Backends für den GCC sind in Vorbereitung, es wird also bald losgehen ;)! Trotzdem, die Sache mit dem Geschwindigkeitsvorteil für C++ ist Firlefanz. Sämtliche .NET-Sprachen münden in MSIL, einem speziellen abstrakten Assembler. Dieser MSIL ist plattformunabhängig, und wird von einem JIT-Compiler vor der Ausführung in absolut nativen Assembler umgesetzt und ausgeführt.
Der MS-JIT optimiert bereits hervorragend (was MS ja auch mit dem VC++ beweiset), Mono hinkt noch ein wenig hinterher. Aus diesem Grunde ist C++ auch nicht schneller oder langsamer als C#, COBOL.NET oder VB.NET: Sie werden alle zu MSIL, alle verwenden dieselben Algorithmen, alle sind auf dieselbe Basis gestellt. Darum ist es irrelevant, ob man nun C# mit Java vergleicht, oder C++.NET mit Java.
[BTW: DotGNU ist die GNU-Webservice-Plattform und kein .NET-Port!]
[ Dieser Beitrag wurde am 30.06.2002 um 17:31 Uhr von Nikolaj editiert. ]
-
Original erstellt von Nikolaj:
Der MS-JIT optimiert bereits hervorragend (was MS ja auch mit dem VC++ beweiset), Mono hinkt noch ein wenig hinterher. Aus diesem Grunde ist C++ auch nicht schneller oder langsamer als C#, COBOL.NET oder VB.NET: Sie werden alle zu MSIL, alle verwenden dieselben Algorithmen, alle sind auf dieselbe Basis gestellt. Darum ist es irrelevant, ob man nun C# mit Java vergleicht, oder C++.NET mit Java.Aber man verbraucht Zeit zum precompilen, da die Software für jede Platform ja neu kompiliert wird vor dem ausführen. Außerdem sprachen wir ja nicht von C++.NET, was imho nicht standard konform sein soll, sondern von ISO C++ festcompiliert mit den gängigen Compilern GCC,ICC,MSVC++ um.
[BTW: DotGNU ist die GNU-Webservice-Plattform und kein .NET-Port!]
Aber DotGNU verbindet die verschiedenen Projekte zum ersatz von dotNET und C#
http://www.southern-storm.com.au/portable_net.html zum Beispiel
Außerdem kann man sich Packete direkt von dort ziehen
-
Original erstellt von Nikolaj:
Trotzdem, die Sache mit dem Geschwindigkeitsvorteil für C++ ist Firlefanz.Der Witz ist ganz einfach (mir egal, wieviel Unwissen gezeigt wird), daß man in C++ keine Laufzeitkosten für was bezahlt, was man nicht benutzt. Klares und gutes Konzept. Und die Sprachen, die einem Firlefanz wie nen Garbage-Collector aufzwingen können ganz einfach nicht mitkommen.
-
@Nikolaj:
Einige meiner Kollegen haben Performance-Test zwischen den einzelnen Sprachen gemacht. Dabei habe ich festgestellt( naja traue keinem Test den du nicht selbst gefälscht hast) das trotz einheitlichen MSIL-Code der Code unterschiedlich schnell ist (Compileroptimimerung und damit unterschiedlicher MSIL-Code).
Incl. einiger Test aus dem Internet, hat C# bis jetzt immer VB.NET geschlagen. C# und C++.NET mehmen sich mal nichts und liegen in anderen Bereichen wieder weit auseinander, in beiden Richtungen.
Ebenfalls fließt PInvoke in meine Beurteilung mit ein, da ich dies jeden Tag benutzen muss um Laufzeitprobleme und fehlende .NET Implemetierungen ausgleichen zu können.
Und wenn du andere Post von mir mal lesen würdest, hab ich immer schon gesagt man sollte .NET mit JAVA vergleichen.Dieser Test wäre noch dazu ein völlig unsinniger Test, da ja nicht der Interpreter das Fenster erzeugt, sondern anderweitige Libs (Windows-API, GTK, bla).
Fast richtig!
Der MS-JIT optimiert bereits hervorragend (was MS ja auch mit dem VC++ beweiset),
Man könnte ja fast meinen du arbeitest für MS! :p
Aber man verbraucht Zeit zum precompilen, da die Software für jede Platform ja neu kompiliert wird vor dem ausführen.
Ja, allerdings bitte .NET drei precompilierungs Möglichkeiten an,
eine Normale, economy und bei der Installation. Alle haben sie ihre Vor- und NachteileP.S. Vielen Dank für deine Aufklärung in sachen .NET.
-
Aber DotGNU verbindet die verschiedenen Projekte zum ersatz von dotNET und C#
Ja, aber man kann von DotGNU nicht erwarten dass .NET-Anwendungen auf dieser Plattform laufen. Dafür existiert Mono.
P.S. Vielen Dank für deine Aufklärung in sachen .NET.
Is das ironisch zu verstehen ;)?
-
Ja, aber man kann von DotGNU nicht erwarten dass .NET-Anwendungen auf dieser Plattform laufen. Dafür existiert Mono.
Kann man das überhaupt von einem System erwarten, was nicht von einem unabhängigen und akzeptierten Institut standardisiert wurde, speziell damit meine ich einen gültigen ISO Standard.
Und aus welchem Grund sollte Mono besser funktionieren als dotGNU?
-
Kann man das überhaupt von einem System erwarten, was nicht von einem unabhängigen und akzeptierten Institut standardisiert wurde, speziell damit meine ich einen gültigen ISO Standard.
Ohoh, Halbwissen. Die .NET-Plattform ist zwar nicht von der ISO standardisiert, wohl aber von der ECMA, insofern ein offener Standard. Genaus ist es mit C#.
Und aus welchem Grund sollte Mono besser funktionieren als dotGNU?
Das habe ich nie gesagt. Mono & DotGNU sind nur verschiedene Schuhe - Mono ist ein Linux-Port von (ECMA-334-).NET, wohingegen DotGNU eine Imitierung der .NET-Technologie darstellt. .NET-Applikationen laufen unter DotGNU einfach nicht.
-
Die Idee die Geschwindigkeit mit der Fenster dargestellt werden zu vergleichen erachte ich als blödsinn, da ich bisher bei keinem mir Bekannten System mich darüber aufgeregt habe, dass das Fenster Etwas länger gebraucht hat. Wenn eine Anwendung aber intern etwas sortieren muss und ich Statt 30 Sekunden nur 5 Warten muss, dann finde ich das sehr interessant.
@volkard:
IMHO besitzt C++ with managed extension einen GarbageCollector.
-
wie siehts aus?