Performance: C vs C#(mono) vs Java vs gcj
Performance: C vs C#(mono) vs Java vs gcj
Hallo,
Nachtrag: erste Ergebnisse stehen im nächsten Post von mir.
ich habe ein Programm geschrieben, welches rekursiv eine Aufgabenstellung bearbeitet... und zwar einmal in C und einmal in C#.
Die Ausführdauer beträgt bei beiden < 1s, aber man merkt dass es bei C# länger dauert.
Gibt es eine Möglichkeit zu messen wie lange die beiden Programme jeweils laufen.. also vom Aufruf bis es fertig ist? Mich würde der Performanceunterschied interessieren...
... und mit einer Stoppuhr zu messen wird nicht klappen, außer ich finde heraus wie ich meine CPU auf ein paar MHz takten kann #[/b]
Nachtrag: erste Ergebnisse stehen im nächsten Post von mir.
ich habe ein Programm geschrieben, welches rekursiv eine Aufgabenstellung bearbeitet... und zwar einmal in C und einmal in C#.
Die Ausführdauer beträgt bei beiden < 1s, aber man merkt dass es bei C# länger dauert.
Gibt es eine Möglichkeit zu messen wie lange die beiden Programme jeweils laufen.. also vom Aufruf bis es fertig ist? Mich würde der Performanceunterschied interessieren...
... und mit einer Stoppuhr zu messen wird nicht klappen, außer ich finde heraus wie ich meine CPU auf ein paar MHz takten kann #[/b]
Zuletzt geändert von padarasa am 07.03.2005 00:10:26, insgesamt 2-mal geändert.
danke soweit... falls jemanden meine Ergebnisse interessieren:
Das C-Programm hab ich mit gcc (ohne irgendwelche Besonderheiten) kompiliert und das C# mit der letzten stable von mono.
1. Durchgang:
C: 0,281s
C#: 0,756s
=> C# braucht 2,7 mal so lange wie C.
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
=> C# braucht 2,3 mal so lange wie C.
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
=> C# braucht 2,3 mal so lange wie C.
Nun, die Initialisierung von C# scheint deutlich länger zu dauern als bei C. Optimierungen hab ich weder von Seite des Compiler noch vom Code her vorgenommen. Das Programm stammt aus der Praxis... war einmal eine BWINF-Aufgabe.
Ich denke man kann sagen, dass C etwa doppelt so schnell ist wie C# .
Das C-Programm hab ich mit gcc (ohne irgendwelche Besonderheiten) kompiliert und das C# mit der letzten stable von mono.
1. Durchgang:
C: 0,281s
C#: 0,756s
=> C# braucht 2,7 mal so lange wie C.
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
=> C# braucht 2,3 mal so lange wie C.
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
=> C# braucht 2,3 mal so lange wie C.
Nun, die Initialisierung von C# scheint deutlich länger zu dauern als bei C. Optimierungen hab ich weder von Seite des Compiler noch vom Code her vorgenommen. Das Programm stammt aus der Praxis... war einmal eine BWINF-Aufgabe.
Ich denke man kann sagen, dass C etwa doppelt so schnell ist wie C# .
Der C#-Code ist unter http://nopaste.debianforum.de/138 zu erreichen.peschmae hat geschrieben:Kannst du den Code mal posten?
Also jetzt nicht hier mit Codetags sondern eher bei npaste oder so
MfG Peschmä
Die versch. Versionen habe ich erreicht, indem ich in der Zeile 82 verschiedene Zahlen addiert habe. Folgende wäre demnach die Orignalversion:
if(LaengeWegTemp > LaengeWeg).
Sofern der Wunsch besteht, gibts auch die C-Variante... ist nur ein wenig aufwendiger, weil ichs damals in versch. Headerdateien gesplitet hatte.
Übrigens würde mich mal die Performance einer Java-Variante interessiern.. also falls jemand Java kann (und Lust hat) könnte er ja mal mir eine Variante in Java schicken. Da C# sehr sehr viele Gemeinsamkeiten mit Java hat, sollte das nicht so viel Aufwand sein... ich kenn mich nur eben nicht mit Java aus .
- peschmae
- Beiträge: 4844
- Registriert: 07.01.2003 12:50:33
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: nirgendwo im irgendwo
Hier mal für Java http://nopaste.debianforum.de/140 - kompiliert, läuft aber wird irgendwie nicht fertig.
Muss ich mal evtl. noch genauer angucken was das macht. [Edit]Doch, geht, hat nur lange [/Edit]
[Edit2]
Bei mir hatte das jeweils 2 Minuten und mehr, aber ich hab auch einen lahmen Rechner.
Interessant ist dass sich Sun JVM und GCJ praktisch nichts nehmen.
Für Sun muss das Ding mit
java -Xmx200m Test
aufgerufen werden weil das Programm viel zu viel Speicher braucht. Der Normale Limit für den Heap ist nämlich bei Java per Default auf 64 MB
GCJ 4.0 Pre: 2:16
Sun Java 1.5: 2:09
Sablevm: 19:10
JamVM: 18:24
Kaffe: 7:34
GIJ: >20 Minuten aber der ist eh nur zum Klassen dynamisch nachladen für GCJ
Wobei nur Kaffe und Sun Java einen JIT haben, GCJ vorkompiliert und der Rest das Zeugs interpretiert.
[/Edit2]
MfG Peschmä
Muss ich mal evtl. noch genauer angucken was das macht. [Edit]Doch, geht, hat nur lange [/Edit]
[Edit2]
Bei mir hatte das jeweils 2 Minuten und mehr, aber ich hab auch einen lahmen Rechner.
Interessant ist dass sich Sun JVM und GCJ praktisch nichts nehmen.
Für Sun muss das Ding mit
java -Xmx200m Test
aufgerufen werden weil das Programm viel zu viel Speicher braucht. Der Normale Limit für den Heap ist nämlich bei Java per Default auf 64 MB
GCJ 4.0 Pre: 2:16
Sun Java 1.5: 2:09
Sablevm: 19:10
JamVM: 18:24
Kaffe: 7:34
GIJ: >20 Minuten aber der ist eh nur zum Klassen dynamisch nachladen für GCJ
Wobei nur Kaffe und Sun Java einen JIT haben, GCJ vorkompiliert und der Rest das Zeugs interpretiert.
[/Edit2]
MfG Peschmä
Zuletzt geändert von peschmae am 06.03.2005 23:06:02, insgesamt 7-mal geändert.
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy
- BeS
- Moderator
- Beiträge: 3236
- Registriert: 17.04.2002 18:30:21
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: Stuttgart
-
Kontaktdaten:
ich denke das ist keine Überraschung. Man wird kaum eine Sprache finden die schneller wie C ist, mal abgesehen von Assambler.padarasa hat geschrieben: Ich denke man kann sagen, dass C etwa doppelt so schnell ist wie C# .
Aber ich denke, dass das auch oft überschätzt wird, sonst müsste man ja alles in C oder noch besser Assambler schreiben. Ich denke in 90% aller Fälle ist heute Entwicklungszeit, Lesbarkeit, Wartung und Weiterentwicklung viel wichtiger als 1-2 sec in der Geschwindigkeit des Programms.
Bei einem Programm kannst du ja wirklich große Berechnungen in C machen und dann in dein C# Programm einbinden.
Interessant wäre dein Test auch noch mit Mono 1.1.4. Seit dieser Version wird offiziell empfohlen diese einzusetzen, da sie deutlich besser wie die 1.0 Reihe ist und man auch kurz vor Mono 1.2 steht.
Deine Unterstützung für Freie Software kostet dich nur wenige Minuten: www.fsfe.org/support
Ich spreche von Freier Software!
Ich spreche von Freier Software!
super.. dann die Ergebnisse mit Java:
1. Durchgang:
C: 0,281s
C#: 0,756s
Java: 7.312s (0,812s)
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
Java: 16.245s (9.745s)
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
Java: 32.469s (25,969s)
Zur Erklärung: Der erste Javawert ist der reale Wert, sprich den ich von time gemessen habe. Insbesondere beim 1. Durchgang ist der sehr hoch... was ich dabei festgestellt habe:
Das erste was das Programm wirklich macht ist: Eine Ausgabe. Zwischen Programmaufruf und der ersten Aufgabe vergehen etwa 6,5s! Das einzige was dazwischen liegt ist das Initialisieren von "ein paar" Variablen (z.T. recht große). Keine Ahnung, wieso Java dafür so lange braucht?? In C und C# erscheint die Ausgabe "sofort",
Ich hab diese Zeit nochmal abgezogen und damit ergeben sich die Werte in den Klammern...
Kann mir jemand erklären, warum Java an der Stelle so lange "hängt"? Ohne diese mir unerklärliche Dauer wäre Java _deutlich_ schneller als C#...
1. Durchgang:
C: 0,281s
C#: 0,756s
Java: 7.312s (0,812s)
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
Java: 16.245s (9.745s)
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
Java: 32.469s (25,969s)
Zur Erklärung: Der erste Javawert ist der reale Wert, sprich den ich von time gemessen habe. Insbesondere beim 1. Durchgang ist der sehr hoch... was ich dabei festgestellt habe:
Das erste was das Programm wirklich macht ist: Eine Ausgabe. Zwischen Programmaufruf und der ersten Aufgabe vergehen etwa 6,5s! Das einzige was dazwischen liegt ist das Initialisieren von "ein paar" Variablen (z.T. recht große). Keine Ahnung, wieso Java dafür so lange braucht?? In C und C# erscheint die Ausgabe "sofort",
Ich hab diese Zeit nochmal abgezogen und damit ergeben sich die Werte in den Klammern...
Kann mir jemand erklären, warum Java an der Stelle so lange "hängt"? Ohne diese mir unerklärliche Dauer wäre Java _deutlich_ schneller als C#...
-
- Beiträge: 644
- Registriert: 16.12.2003 15:44:51
Aus Sicht der Programmierer mit Sicherheit, doch aus Anwendersicht würde ich sagen, dass Geschwindigkeit extrem wichtig ist. Da können 1-2 Sekunden durchaus darüber entscheiden ob ein Programm verwendet wird oder doch das etwas schnellere Konkurrenzprodukt. Ich persönlich verwende z.B. keine Javaprogramme auf meinem Rechner (AMD XP 1900), weil die mir einfach zu lahmarschig sind. Und bei von der Funktionalität und Stabilität gleichwertigen Proggis nutze ich das schnellere. Teilweise verzichte ich sogar auf nützliche Features der langsameren Variante und nehme das schnellere Programm. Als Beispiel fällt mir JBidwatcher ein, welches von der Funktionalität und den Möglichkeiten sehr gut ist. Da es aber in Java geschrieben ist, benutze ich Bidwatcher, weil es einfach schneller ist.BeS hat geschrieben: Aber ich denke, dass das auch oft überschätzt wird, sonst müsste man ja alles in C oder noch besser Assambler schreiben. Ich denke in 90% aller Fälle ist heute Entwicklungszeit, Lesbarkeit, Wartung und Weiterentwicklung viel wichtiger als 1-2 sec in der Geschwindigkeit des Programms.
greetz
mastermind
Schon klar.. mir ging es eher darum zu sehen um welche Verhältnisse es sich handelt.BeS hat geschrieben: ich denke das ist keine Überraschung. Man wird kaum eine Sprache finden die schneller wie C ist, mal abgesehen von Assambler.
Also ich habe die Version 1.0.6 eingesetzt (müsste die letzte stable sein). Ich werde nachher nochmal versuchen das ganze mit der neuen Version zu versuchen... wusste bisher nicht, dass das einen Unterschied machen soll bzw. das empfohlen wird die neue einzusetzen.Interessant wäre dein Test auch noch mit Mono 1.1.4. Seit dieser Version wird offiziell empfohlen diese einzusetzen, da sie deutlich besser wie die 1.0 Reihe ist und man auch kurz vor Mono 1.2 steht.
Ich finde einen Test ab Start releativ unaussagekräftig.
Bei den meisten Programmen ist nunmal der Startup zu vernachlässigen und dieser sagt auch rein gar nichts über die Geschwindigkeit der Codeausführung aus.
Interessanter fände ich daher einen Vergleich der Sprachen mit den Grenzen Einstieg in und Austieg aus der Schleife.
Ich glaube aber, ich weiss, warum die Grenzen gerne anders gesteckt werden.
Bei den meisten Programmen ist nunmal der Startup zu vernachlässigen und dieser sagt auch rein gar nichts über die Geschwindigkeit der Codeausführung aus.
Interessanter fände ich daher einen Vergleich der Sprachen mit den Grenzen Einstieg in und Austieg aus der Schleife.
Ich glaube aber, ich weiss, warum die Grenzen gerne anders gesteckt werden.
Ich finde Java-Programme auch äußert lahm.. allerdings bezieht sich das meistens auf die GUI, welche in Java einfach äußerst träge reagiert.mastermind_the_real_one hat geschrieben:Ich persönlich verwende z.B. keine Javaprogramme auf meinem Rechner (AMD XP 1900), weil die mir einfach zu lahmarschig sind.
Bei C# unter Verwendung von Gtk# ist das Verhalten der GUI aber normal... genauso wie alle anderen Gtk-Programme. Und darin sehe ich eigentlich die Chance von mono:
Programme die schnell erscheinen (die GUI ist flink) kombiniert mit einer fehlerresinstenteren und leicht wartbaren Sprache. Und ob dann das Programm für manche Anwendungen ein paar % (ok... bisher sinds bei mono/c# noch deutlich mehr) länger braucht, wird man nicht merken. Java hat halt das Problem einer viel zu lahmen Oberfläche.
- peschmae
- Beiträge: 4844
- Registriert: 07.01.2003 12:50:33
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: nirgendwo im irgendwo
@padarasa könntest du auch mal GCJ versuchen? Nur so zum Vergleich, würde mich interessieren. Falls du den installiert hast:
gcj-3.4 --main=Test Test.java -o test
Ich trage oben mal noch die Vergleichsdaten der anderen Freien JVMs auf meinem Rechner nach.
Zu Java gibts zu sagen:
1) Ja, die Startzeit ist lahm. Keine Ahnung woran das genau liegt, ist mir aber auch schon aufgefallen. Auch wenn einige sagen das sei egal: Mich stört es enorm wenn ich auf ein Programm warten muss. Das Beispiel JBidwatcher - hatte ich anfangs - Bidwatcher - habe ich jetzt ist wohl schon fast klassisch.
Auch möglich dass Java bei der Speicherallokierung mit new langsam ist. Das wurde wohl auch nicht für so grosse Sachen "gedacht" - sonst wäre wohl auch der Default-Maximale-VM-Grösse Wert etwas grösser.
2) Dass Java aufholt je länger das Programm läuft liegt nicht nur am Startuptempoproblem von Java sondern auch daran, dass die ersten paar Durchläufe einer Codestelle Interpretiert werden. Der JIT tritt erst in Aktion wenn es sich "lohnt" die Stelle zu optimieren - ich glaube sogar dass er später noch besser optimiert, wenn der Code _wirklich_ viel benutzt wird.
MfG Peschmä
gcj-3.4 --main=Test Test.java -o test
Ich trage oben mal noch die Vergleichsdaten der anderen Freien JVMs auf meinem Rechner nach.
Zu Java gibts zu sagen:
1) Ja, die Startzeit ist lahm. Keine Ahnung woran das genau liegt, ist mir aber auch schon aufgefallen. Auch wenn einige sagen das sei egal: Mich stört es enorm wenn ich auf ein Programm warten muss. Das Beispiel JBidwatcher - hatte ich anfangs - Bidwatcher - habe ich jetzt ist wohl schon fast klassisch.
Auch möglich dass Java bei der Speicherallokierung mit new langsam ist. Das wurde wohl auch nicht für so grosse Sachen "gedacht" - sonst wäre wohl auch der Default-Maximale-VM-Grösse Wert etwas grösser.
2) Dass Java aufholt je länger das Programm läuft liegt nicht nur am Startuptempoproblem von Java sondern auch daran, dass die ersten paar Durchläufe einer Codestelle Interpretiert werden. Der JIT tritt erst in Aktion wenn es sich "lohnt" die Stelle zu optimieren - ich glaube sogar dass er später noch besser optimiert, wenn der Code _wirklich_ viel benutzt wird.
MfG Peschmä
"er hätte nicht in die usa ziehen dürfen - die versauen alles" -- Snoopy
hatte den gcj bisher nicht installiert... wollt dir den Gefallen aber machen:
1. Durchgang:
C: 0,281s
C#: 0,756s
Java: 7.312s
gcj: 1.982s
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
Java: 16.245s
gcj: 14.836s
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
Java: 32.469s
gcj: 38.187s
Tja... nein, ich hab die Testergebnisse nicht manipuliert und auch brav den selben Quellcode genommen. Anscheinend starten gci kompilierte Programme deutlich schneller (übrigens ist dieser "Hänger" am Anfang auch deutlich kürzer). Allerdings fällt der gcj dann später wieder zurück... fühl mich langsam wie bei einem Formel1-Rennen:
Schumacher (SUNs Java) bekommt den Gang nicht rein, hängt am Start fest und die McLaren (gcj) ziehen davon... aber dann: der Weltmeister hat das Gaspedal endlich gefunden. Während McLaren mit BMW (monos C#) kämpft zieht der Weltmeister rechts vorbei. Während diesem spannenden Kampf ist der Düsenjet (C) bereits am Ziel angekommen....
Übrigens mich interessiert jetzt auch wie sich das neue mono schlägt. Ich kann das Programm leider nicht kompilieren... habe folgendes Problem:
http://www.mail-archive.com/mono-list@l ... 13532.html
Gibt es irgend eine Lösung dafür? Oder Workaround oder irgendetwas... (setze Sarge ein)
1. Durchgang:
C: 0,281s
C#: 0,756s
Java: 7.312s
gcj: 1.982s
2. Durchgang (incl. Codeänderungen):
C: 6,190s
C#: 14,194s
Java: 16.245s
gcj: 14.836s
3. Durchgang (incl. Codeänderungen):
C: 16,542s
C#: 37,811s
Java: 32.469s
gcj: 38.187s
Tja... nein, ich hab die Testergebnisse nicht manipuliert und auch brav den selben Quellcode genommen. Anscheinend starten gci kompilierte Programme deutlich schneller (übrigens ist dieser "Hänger" am Anfang auch deutlich kürzer). Allerdings fällt der gcj dann später wieder zurück... fühl mich langsam wie bei einem Formel1-Rennen:
Schumacher (SUNs Java) bekommt den Gang nicht rein, hängt am Start fest und die McLaren (gcj) ziehen davon... aber dann: der Weltmeister hat das Gaspedal endlich gefunden. Während McLaren mit BMW (monos C#) kämpft zieht der Weltmeister rechts vorbei. Während diesem spannenden Kampf ist der Düsenjet (C) bereits am Ziel angekommen....
Übrigens mich interessiert jetzt auch wie sich das neue mono schlägt. Ich kann das Programm leider nicht kompilieren... habe folgendes Problem:
http://www.mail-archive.com/mono-list@l ... 13532.html
Gibt es irgend eine Lösung dafür? Oder Workaround oder irgendetwas... (setze Sarge ein)