Java vs. C#



  • OK! Hier kommen die Ergebnisse : (getestet wurde auf einem P4M mit 1,2/1,6GHz, 384MB RAM)

    1,2 GHz :

    C#            Java
    Array erzeugen         :   200             200
    Zufallszahlen erzeugen :  1202            4527
    Sortieren              :  4667            2784
    String anhängen        :  6790            4366
    Speichern              :  5728            3114
    Wurzeln berechnen      :   170             211
    

    1,6 GHz :

    C#            Java
    Array erzeugen         :   140             170
    Zufallszahlen erzeugen :   861            3405
    Sortieren              :  3375            2073
    String anhängen        :  4987            3305
    Speichern              :  1843            2253
    Wurzeln berechnen      :   130             130
    

    Alle Angaben sind Millisekunden. ...allerdings sah der Output bei C# etwas komisch aus! 🙂

    [ Dieser Beitrag wurde am 04.10.2002 um 01:25 Uhr von Gregor editiert. ]



  • Bei der Ausgabe hatte ich das Milliseconds rausgenommen, da bei meinem Prozessor einigen Sachen schon Sekunden gedauert haben. 😉

    Die Ausgabe ist ganz normal Stunden:Minuten:Sekunden.Millisekunden.



  • 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
    gcj

    C++:
    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.


Anmelden zum Antworten