Java vs. C#



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



  • @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. ]



  • Was gibt es eigentlich für ein Zeitmessproblem? Ist das mit C++ so schwierig? ...es gibt doch von c her eine "Time.h" (inzwischen wahrscheinlich ohne h), oder? Geht das damit nicht?

    [ Dieser Beitrag wurde am 07.10.2002 um 00:02 Uhr von Gregor editiert. ]



  • Original erstellt von Helium:
    [QB]Ich hab mal kurz einen Test mit C++ gemacht,
    ...
    Vielliecht sollte der, der das Portiert den String als
    ...

    Ja. Ich tue mich immer wieder schwer damit, den Leuten zu verklickern, daß andere Sprachen andere Vorgehensweisen erfordern. Ein Sprachunabhängiges Struktogramm ist, angenommen, man programmiert auf Speed, wie z.B. in den Computerspielen immer als Randforderung dabei ist, ein Produkt, das besser ungelesen in den Papierkorb wandert. "Dont do the C++-Hack in Java!". Und andersrum soll mans natürlich auch nicht machen.
    Man mag C# gegen Java in den Bereichen, wo sie fast gleich sind, gut gegeneinander messen können. Aber anderereseits, 1000000 Wurzeln zu ziehen? Das ist nicht gerade die Aufgabe für Java oder C#! Es ist Wurstegal, opb die Auf Wurzeln optimiert sind. Harte mathematische Berechnungen macht man immernoch in Fortran.
    Falls woanders tatsächlich ein signifikanter Unterschied besteht, dann war das auch nur ein "Feature", das in der nächsten Version weg ist. Technische Sachen von Bedeutung können hier gar nicht gefunden werden. Schließlich ist es innendrin einmal Java mit außenrum zwei Markennamen. An der Sprache kanns nix geben, was der andere nicht leicht nachrüsten könnte.
    In Sachen IDE und Bibliotheken eher. Noch dürfen wir unter Windows per WIN32-API alles. Aber wie lange? Nach WinXP läßt sich MS vielleicht zwei neue Buchstaben einfallen, z.B. WinAJ und ab dann kann man jedes neue Feature (Programmgesteuerte Administration des eingebauten Routers, Terminalserver und die ganzen anderen Sachen, die in anderen MS-BSen bereits da waren, aber mit Win2K sterben werden, in der WinXP-Mega-Teuer kurz auftauchen werden, in der WinAJ als neu erscheinen werden) nur noch durch .net anfassen. Und dann die Treiber, DirectX12 ist nur durch .net anfassbar und insbesondere natürlich auch noch durch C++, wenn es C++.net mit netten MS-Erweiterungen ist, und dann ist Schicht im Schacht.
    Die Frage laute eigentlich allein, obs die freie Entwicklergemeinde (wozu ich auch Emporkömmlinge wie Sun zähle) schaffen kann, gegen MS auf Dauer feine Software zu basteln, die man nicht so schnell in die Ecke knallen muß, wie die aktuellen Unices. Ich habe da meine Bedenken.
    Insofern kann ich bereits das Hauptthema "Java vs. C#" kaum ernst nehmen. Das sind nur zwei Namen des selben Produkts. Was mich ankotzt ist, daß dieser Merketingkrieg so großen Anklang findet. Nicht wenige Professoren lehren zum Beispiel ihren Erstsemestern Jave, weil Jave "echt objektorientiert ist".

    Die Richtung halte ich übrigens für gut, und wären die Kumpels von Sun mir nicht zuvorgekommen, hätte ich das selber erfinden müssen. Es ist reichlich Prozessorpower da. Und Ram ist lahm. Das spricht für mich irgendwie ne Sprache, die sich immer wieder wie "Stackmachines müssen her!" anhört. Bytecode. Ich höre auch ein permanentes "Forth" rumoren. Zunächst interpretiert, und später zunehmend in den Prozessor angesetzt. Man mag sich noch keine benutzerdefinierten Routinen im Hauptprozessor vorstellen. (Gerade hat's mir "Forth" und "ein Forth-Kernel lebt in 8k ganz glücklich" und "8k, ach scheiß auf 8k, wir nehmen 16k auf dem Prozessor" wieder volle pulle angebrüllt.) Aber auf dem Grafik-Ding setzen wie Pixel-Shader und so schon ab. Bestimmt nur, weil die Spieleprogrammierer eh keine Struktogramme malen (Oh, sagte ich bereits, daß UML-Diagramme den selben Effekt haben?).

    Naja, zappelt mal weiter um C# oder Java. Ich guck Euch gerne zu und verwende auch gerne die Errungenschaften, die dabei rauskommen.


Anmelden zum Antworten