Java vs. C#
-
Original erstellt von thomas80d:
**
Die Ausgabe ist ganz normal Stunden:Minuten:Sekunden.Millisekunden.**Ja! Schon! ...nur steht dahinter dann nochmal "ms".
...aber das ist egal.OK! Was lernen wir aus dem Benchmark :
Mit C# kann man schneller Zufallszahlen erzeugen.
Mit Java kann man schneller sortieren.
Mit Java kann man schneller Strings aneinanderhängen.
Beim Speichern hängt der Unterschied von der Geschwindigkeit des Prozessors ab.
-
Die von C# erzeugte Textdatei ist übrigens etwas kleiner. Die Java-Datei hat etwa 54,9MB, die C#-Datei hat etwa 52,4MB. Ich weiß nicht, woran das liegt. Es ist aber reproduzierbar, somit liegt es nicht an einer zufälligen Abweichung, die auchmal beim anderen Programm passieren könnte.
EDIT : ...mit "MB" sind oben nicht "MegaByte", sondern "Millionen Byte" gemeint. ...ich hatte keine Lust, das umzurechnen!
EDIT 2 : Der Unterschied ist, dass der Zufallsgenerator bei C# nur positive Zahlen erzeugt, während bei Java auch negative erzeugt werden. Bei Java gibt es also etwa 2500000 mal noch ein "-".
[ Dieser Beitrag wurde am 04.10.2002 um 03:15 Uhr von Gregor editiert. ]
-
Original erstellt von CengizS:
**Für solche, die keine Programme kennen, die in Java geschrieben wurden.- Webgain StructureBuilder
- Headway reView
- Together Control Center
- NetBeans (SunONE formerly Forté for Java)
- TOPlink (mittlerweile von Oracle)
- Borland JBuilder
- Merant PVCS
- und weitere viele kleine GUI-Clients für Kazaa, Esel, CVS etc. pp
Nachtrag: Dass der Netscape Communicator in Java entwickelt wurde wäre mir neu.
[ Dieser Beitrag wurde am 25.09.2002 um 16:40 Uhr von [qb]CengizS** editiert. ][/QB]
Borland JBuilder!
-
@ Lars : Öhm... Ich glaube, du hast den Beitrag von CengizS nicht so ganz gelesen!
Kann das sein?Wenn hier noch einer C++-Code zu dem Programm oben schreibt, hier postet und mir eine ausführbare Datei schickt, dann würde ich die Ergebnisse oben entsprechend erweitern.
-
wir sollten das Java Programm auch mal mit dem gcj compilieren und testen (natürlich nicht als Konkurent zum Java Programm, sondern nur aus interesse, da es ja unfair ist ein kompiliertes gegen ein zujitterndes Programm laufen zu lassen)
Also wir brauchen folgende Tests:
C#:
Mono
dotGNU
Rotor (und Rotor Port für Linux)Java:
JDK 1.4
gcjC++:
g++ 3
i++ (wenn möglich)ich portier dann mal das Programm zu C++, kann aber bis morgen dauern, da ich heute viel zu tun habe
-
BTW.
wir sollten auch die gesammt Laufzeit der Programme messen, da wir sonst nicht die Zeit beachten, die die Programme zum Jitten brauchen.Ich habe mal angefangen mit der C++ Version (schreibe einmal eine, die mehr C mäßig ist und eine die so stark wie möglich die libstdc++ benutzt)
-
Original erstellt von kingruedi:
**
wir sollten auch die gesammt Laufzeit der Programme messen, da wir sonst nicht die Zeit beachten, die die Programme zum Jitten brauchen.
**Wie kann man das eigentlich unter WinXP machen?
-
ka.
Vielleicht Zeitmessen, Programmaufrufen, Zeitmessen oder so
darf man jetzt eigentlich Performance Tests von der MS dotNET Implementierung machen? Ich hab gehört, dass dürfte man nicht laut Lizenz Bedingung.
-
Original erstellt von kingruedi:
**
darf man jetzt eigentlich Performance Tests von der MS dotNET Implementierung machen? Ich hab gehört, dass dürfte man nicht laut Lizenz Bedingung.**Keine Ahnung. Ich habe mir die Lizenzbedingungen nicht durchgelesen. Aber ich denke mal, soetwas entbehrt jeder Rechtsgrundlage. ...soweit kommt das noch, dass man etwas nicht mit etwas anderem vergleichen darf, damit man eine Entscheidungshilfe hat, was man einsetzen sollte. Ich glaube, so eine Bedingung würde vom Gesetz her glatt unter den Begriff "Sittenwidrig" fallen!
-
hast du Linux auf deinem Rechner? Wir bräuchten am besten die gleiche Maschine mit Linux und Windows, damit wir die ganzen Dinge testen können.
-
Nein! Habe ich leidre nicht. ...ich habe nen anderen (älteren) Rechner mit viel zu wenig RAM, auf dem Win98 und Linux drauf sind. Da kann ich das auch noch testen. Da ist aber kein .Net-Framework drauf! Es wäre besser, wenn sich da jemand anderes findet. (...wenn das mit dem RAM knapp wird, dann wird Java wahrscheinlich stark gegenüber den anderen abfallen, bin mal gespannt, wie stark)
-
Original erstellt von kingruedi:
hast du Linux auf deinem Rechner? Wir bräuchten am besten die gleiche Maschine mit Linux und Windows, damit wir die ganzen Dinge testen können.Gibts denn das .NET-Framework schon für Linux?
-
Original erstellt von thomas80d:
Gibts denn das .NET-Framework schon für Linux?Für Linux gibt es doch Mono. ..Kingruedi hat glaube ich noch mehr aufgezählt. Guck einfach mal auf der vorherigen Seite.
-
es gibt neben Mono noch dotGNU und eine Portierung des Rotor Codes.
@Gregor
das ist schlecht, wir brauchen also jemand mit einem aktuellen Linux und einem aktuellen Windows, auf dem gleichen Computer.
-
Wir können die Linuxtests auch seperat von den Windowstests machen. Wir können uns dann ja an der Geschwindigkeit des C++-Referenzprogramms orientieren. Wenn ein Programm, was auf Windows doppelt so viel Zeit benötigt hat, wie das C++-Programm, auf Linux das vierfache der Zeit des C++-Programms benötigt, dann weiß man doch eigentlich genug.
-
Original erstellt von Gregor:
Für Linux gibt es doch Mono. ..Kingruedi hat glaube ich noch mehr aufgezählt. Guck einfach mal auf der vorherigen Seite.Die Begriffe haben mir nix gesagt. Ich kenn mich mit Linux null aus.
-
Mono ist eine Open-Source implementierung des .Net-Frameworks. (mehr oder weniger)
-
Ich hab mal kurz einen Test mit C++ gemacht, wegen des Aneinanderhängens der ganzen Zahlen in einen String. Stingstreams scheien nicht geeignet zu sein. Während die ersten 50000 Zahlen noch blitzartig angehängt waren, dauetre es mit zunehmender Zahl immer länger. Bei 100000 Zahlen Wurde es dann schon merkbar langsam und bei noch mher unerträglich lahm. Woran das genau liegt weiß ich nicht. vielleicht an dem gigantischen Feld, das ja zusammenhängend im speicher leigen muss. Vielliecht sollte der, der das Portiert den String als deque<char> anlegn. Wie man dann allerdings aus Zahlen einen String macht ist eine andere Frage.
-
@Helium
ich habe eine Version mit stringstreams und eine Version mit sprintf und strcat, mal schauen welche schneller ist.Habe aber noch ein Problem beim Zeitmessen
-
Oha! Das Portieren scheint ja schwieriger zu sein, als ich gedacht hatte.
Wer es nicht weiß : Beim String-aneinanderhängen wird in dem Java-Programm letztendlich zuerst ein riesiges char-Array erstellt, von dem man weiß, dass es groß genug für den String ist. Wenn das char-Array gefüllt ist, dann wird daraus ein String gemacht.
Wenn man die ganze Zeit mit Strings arbeitet, dann muss man immer etwas umkopieren, wenn man etwas neues anhängen möchte. Das sollte also recht lahm sein. Ein Deque wird wohl auch lahm sein. Ich denke, bei einem Deque wird zu viel Overhead erzeugt. ...allerdings weiß ich garnicht, wie das in C++ implementiert ist.
[ Dieser Beitrag wurde am 06.10.2002 um 15:23 Uhr von Gregor editiert. ]