Zukunft von C#

[Hans (Gast)]

Hallo Experten,
Nach langer Abstienenz muss ich mich wieder mit der Programmierung 
auseinandersetzen. Habe mich daher über die verschiedenen Sprachen 
informiert und habe mich eigentlich für  C# entschieden. Jetzt konnte 
ich auf Heise lesen, dass Microsoft verlautet hat, C# würde auf 
absehbarer Zeit nicht weiter unterstützt.
Meine Frage daher an euch: Habe ich das richtig verstanden und setze ich 
jetzt auf das falsche Pferd, dass sich die Einarbeitung eigentlich nicht 
mehr lohnt?

Was meint ihr?


LG

Hans

[hmmm (Gast)]

?
Link?
Würde mich doch sehr überraschen... ich kann mich erinnern das 
irgendwann mal die meldung kam dass se für Metro für irgendwelche 
grafischen Spielereien was anderes nehmen wollten. Aber sonst ist C# ja 
doch die stärkste Sprache die sie haben, und jetzt nicht ein Fehlschlag, 
den man aufgeben würde.

[Thomas (Gast)]

Wenn du schon vorgibst so einen Quatsch auf Heise gelesen zu haben, 
warum gibst du uns nicht einfach einen Link auf den Artikel?

Komisch, irgendwie habe ich das Gefühl, dass es diesen Artikel gar nicht 
gibt...

[Klaus W. (mfgkw)]

Welcher tolle Standard von MS hat schon mehr als ein paar wenige Jahre 
überlebt?
Außer der Toleranz der Anwender...

[Klaus W. (mfgkw)]

Thomas schrieb:
> so einen Quatsch auf Heise

evtl. im Heise-Forum :-)

[Hans (Gast)]

Hier der gewünschte link:

http://www.heise.de/developer/artikel/Jenseits-von-JavaScript-und-HTML5-Ausblick-auf-NET-4-5-und-Visual-Studio-11-0-1355903.html


Gruß

Hans

[Ulli N. (Gast)]

Hans schrieb:
> Was meint ihr?

Ich meine, du solltest den Artikel noch ein paar mal durchlesen.

[Klaus W. (mfgkw)]

beim Überfliegen fiel mir kein Abgesang auf C# auf.

Aufgefallen ist mir nur, daß der Artikel von Holger Schwichtenberg 
stammt.

[Thomas (Gast)]

Ok, ich habe den Artikel gelesen.

Du solltest dir C# aus dem Kopf schlagen und auf Silverlight setzten!

[Klaus W. (mfgkw)]

genau, das ist die Zukunft.

[Ersa (Gast)]

C# ist doch längst fest etabliert unter den Platzhirschen der 
Programmiersprachen.

C/C++
C#
Java

[Arc N. (arc)]

Klaus Wachtler schrieb:
> beim Überfliegen fiel mir kein Abgesang auf C# auf.
>
> Aufgefallen ist mir nur, daß der Artikel von Holger Schwichtenberg
> stammt.

An den TO: Etwas deutlicher...Vergiss Schwichtenberg (nicht nur diesen 
"Artikel")
Und zu C#
- das ist immer noch ein ISO/ECMA-Standard (ISO/IEC 23270:2006 bzw. 
ECMA-334 
http://www.ecma-international.org/publications/standards/Ecma-334.htm)
- es gibt nicht nur von MS passende Compiler, IDEs etc.
- WinRT (das, was mit Windows 8 kommt) erlaubt auch die Verwendung von 
C#, VB etc. für die Programme, 
http://tirania.org/blog/archive/2011/Sep-15.html (Abschnitt "Is it .NET 
or Not?")
- es gibt viel zu viele Investitionen in .NET (nicht nur C#) als das MS 
das mal eben absägen könnte (gerade jetzt, wo div. andere Systeme den 
Markt(anteil) von MS nicht nur angreifen, wäre eine solche Entscheidung, 
tödlich)

p.s. Silverlight wird noch bis 2021 (nein, kein Schreibfehler) 
unterstützt
http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Silverlight&Filter=FilterNO, 
VS LightSwitch 2011 (das auf SL setzt) bis 1.11.2022 (extended support 
end date)

[Roland (Gast)]

Hans schrieb:
> Was meint ihr?

Nimm Cobol. Oder Fortran.

[Jasch (Gast)]

Hans schrieb:
> Hallo Experten,
> Nach langer Abstienenz muss ich mich wieder mit der Programmierung
> auseinandersetzen. Habe mich daher über die verschiedenen Sprachen
> informiert und habe mich eigentlich für  C# entschieden.

Na gut.

> Jetzt konnte
> ich auf Heise lesen, dass Microsoft verlautet hat, C# würde auf
> absehbarer Zeit nicht weiter unterstützt.

Hehehe, ja, klar. Die Leitsprache von .NET, abgekündigt, sicher.

> Meine Frage daher an euch: Habe ich das richtig verstanden und setze ich
> jetzt auf das falsche Pferd, dass sich die Einarbeitung eigentlich nicht
> mehr lohnt?

Zusätzlich zu dem was die anderen gesagt haben: wer auf nur eine Sprache 
setzt, egal wie kompetent er dann darin ist, ist, ähhh, wie sage ich das 
höflich, extrem schlecht beraten.

Ich beobachte ja zur Zeit fasziniert die Java-Leute. Oracle scheint ja 
dabei zu sein Java langfristig zu killen (oder doch nicht, wer weiss?). 
Ich kenne einige Leute die mehr oder weniger sagen "Java oder Tod(tm)". 
Spannend was die dann tun wenn es zum Schlimmsten kommt.

Mal abgesehen davon dass diese Leute heute schon erschreckend wenig 
Ahnung von der Welt ausserhalb ihres kleinen, total portablen (Bwahaha!) 
Universums haben... :-(

[Dussel (Gast)]

>Mal abgesehen davon dass diese Leute heute schon erschreckend wenig
>Ahnung von der Welt ausserhalb ihres kleinen, total portablen (Bwahaha!)
>Universums haben... :-(
Gezwungenermaßen musste ich mich mit Java beschäftigen und ich muss 
sagen, so schlecht ist es nicht. Wenn man nicht so großen Wert auf 
Leistung legt, kann man damit ganz gut programmieren. Ist halt nicht 
besonders schnell, auch wenn Sun wahrscheinlich nächstes Jahr 'beweist', 
dass es schneller als Assembler ist -.-
Nicht falsch verstehen. Ich bleibe weiter bei C(++).

Zum Thema: Wenn man sich so umsieht, scheint C# doch zumindest 
einigermaßen verbreitet zu sein und Microsoft ist ja kein 
Hobbyprogrammierer, der irgendwann die Lust verliert sein Projekt zu 
pflegen. Wird also wohl noch Zukunft haben.

[Robert L. (lrlr)]

warum schneidet java (und .Net) eigentlich in benchmarks immer so gut 
ab?


aber die Real Live anwendungen, (vorallem GUI sachen) sind immer SOOOO 
extrem ZÄHHH
z.b. "talend"   (das ist ein eclipse based ETL usw..)


sogar jemand der behauptet einen "fairen" benchmark zu haben, sagt dass 
java nur etwas langsamer ist

http://www.irrlicht3d.org/pivot/entry.php?id=446

liegt es daran, dass man in JAVA immer bemüht ist "extrem sauberen" Code 
zu schreiben (zuviele classen, zu tief abgeleitet, zuviele 
schnittstellen, zuviel "lehrbuch" programieren...)

zuviele Integer (mit großem "I") usw.

??

[Dussel (Gast)]

>warum schneidet java (und .Net) eigentlich in benchmarks immer so gut ab?
Bei meinem Test hat Java für die Berechnung (nicht Ein- und Ausgabe) 
viermal so lange gebraucht wie C. Java soll besser sein beim Instanzen 
Erzeugen als C++.
Was man davon hält, muss jeder für sich entscheiden. Ich denke, dass 
Programme, die so viele Instanzen benötigen, dass sich der Vorteil 
bemerkbar macht, auch so viel rechnen müssen, dass der Vorteil der 
schnellen Erzeugung durch die langsame Berechnung wieder aufgehoben 
wird.

[Läubi .. (laeubi)]

Robert L. schrieb:
> warum schneidet java (und .Net) eigentlich in benchmarks
> immer so gut ab?
Wieso nicht? Kommt ja auch auf den Benchmark an... C# und Java haben 
beide einen JIT Compiler welcher den Code (oder die Hotspots) direkt in 
Maschinencode umsetzt.

Robert L. schrieb:
> aber die Real Live anwendungen, (vorallem GUI sachen)
> sind immer SOOOO extrem ZÄHHH
Ich entwickle all meine (GUI) Anwendungen in Java und da ist nix zäh 
wenn man es richtig mache, bei einigen Firmen auch in C++ was auch nicht 
automatisch das no-plus-ultra ist, ob eine Anwendung zäh ist (was auch 
immer das bedeutet) hängt vor allem vom Programmierer und von den 
Anforderungen ab.

Lustig finde ich immer, das behauptet wird Java sei so langsam, dafür 
dan irgendwelche mördermäßig umfangreichen Frameworks/IDEs angeführt 
werden.
In C gibt es sowas nur garnicht als das man vergleichen könnte.

Robert L. schrieb:
> zuviele
Geht in allen Sprachen, und wie in allen Sprachen kann man in Java gut 
als auch schlecht programmieren.

Dussel schrieb:
> Bei meinem Test hat Java für die Berechnung (nicht Ein- und Ausgabe)
> viermal so lange gebraucht wie C
Ja was den für eine Berechnung? 1+1? Wieviele Iterationen und welche 
Datenmengen. Sauber programmiert oder einfach "mal schnell 
hingeschrieben".

Dussel schrieb:
> dass der Vorteil der schnellen Erzeugung durch die
> langsame Berechnung wieder aufgehoben wird.
Man muss vorallem die Entwicklungsgeschwindigkeit und die 
Fehleranfälligkeit betrachten ob das ganze nachher 100ms oder 110ms 
rechnet ist in der Praxis meist völlig egal, und falls nicht kann man 
kritische Routinen immer noch in eine DLL auslagern...

Robert L. schrieb:
> sogar jemand der behauptet einen "fairen" benchmark zu haben
Besonders interessant ist dort der Abschnitt:
>> Knowing a bit about the C++ and Java optimizers, I was also able to
>> revert the results completely. For example although using equivalent
>> Java and C++ code, I was able to make the C++ version take 16 seconds
>> for the nested loops-test while Java only needed 1 second by adding
>> some virtual method calls which I knew Java could optimize.
Und hier zeigt sich, wenn man will kann man überall Mist bauen ;)

[Dussel (Gast)]

Läubi .. schrieb:
> Dussel schrieb:
>> Bei meinem Test hat Java für die Berechnung (nicht Ein- und Ausgabe)
>> viermal so lange gebraucht wie C
> Ja was den für eine Berechnung? 1+1? Wieviele Iterationen und welche
> Datenmengen. Sauber programmiert oder einfach "mal schnell
> hingeschrieben".
Das war Primzahlensuche in einen bestimmten Bereich (z.B. 0-100.000) mit 
dem Sieb des Eratosthenes. Ziemlich primitiv, aber für den 
Laufzeitvergleich brauchbar.

Läubi .. schrieb:
> Dussel schrieb:
>> dass der Vorteil der schnellen Erzeugung durch die
>> langsame Berechnung wieder aufgehoben wird.
> Man muss vorallem die Entwicklungsgeschwindigkeit und die
> Fehleranfälligkeit betrachten ob das ganze nachher 100ms oder 110ms
> rechnet ist in der Praxis meist völlig egal, und falls nicht kann man
> kritische Routinen immer noch in eine DLL auslagern...
 Ja, aber ob es 100ms oder 300ms dauert macht einen Unterschied. Die 
Argumentation "Es ist zwar langsamer, aber dafür schneller entwickelt" 
finde ich ziemlich unpassend. Der Programmierer, der Geld für seine 
Arbeit bekommt, lagert seine Arbeit auf den Rechner oder die Nerven des 
Kunden, der dafür Geld bezahlt, aus.
Das Argument gilt natürlich nicht, wenn das Programm eine 
'Sonderanfertigung' ist. Dann machen sich auch die Entwicklungskosten 
bemerkbar.

[Läubi .. (laeubi)]

Dussel schrieb:
> Der Programmierer, der Geld für seine
> Arbeit bekommt, lagert seine Arbeit auf den Rechner oder die Nerven des
> Kunden, der dafür Geld bezahlt, aus
Dieses Argument ist natürlich besonders gut wenn man dann OpenSource 
Lösungen anprangert ;)

Wie gesagt, es geht auch "flüssig" der Aufwand und die nötige Erfahrung 
ist halt höher.

Dussel schrieb:
> Das war Primzahlensuche in einen bestimmten Bereich (z.B. 0-100.000) mit
> dem Sieb des Eratosthenes. Ziemlich primitiv, aber für den
> Laufzeitvergleich brauchbar.

Naja... nicht gerade die typische Aufgabe aber in welchem Bereich die 
Abweichung lag und ob die Algorithmen gleichwertig waren wissen wir 
immer noch nicht ;)
Gerade bei Arrayzugriffen kann man viel vermurksen, ebenso bei 
Datentypen etc... siehe obiger Link ...

Dussel schrieb:
> "Es ist zwar langsamer, aber dafür schneller entwickelt

Wie gesagt, schneller und wartungsfreundlicher und weniger 
fehleranfällig. Gerade da PCs immer schneller werden ist es sowie müßig 
wegen wenigen Prozenten sich 'nen Kopf zu machen, das Gesamtkonzept muss 
stimmen und wenn die Anwendung ständig mit nem Coredump abraucht dafür 
aber meistens ein paar Sekunden schneller ist, kommt auch keine rechte 
Freude beim Anwender auf.

[Dussel (Gast)]

Läubi .. schrieb:
> Dussel schrieb:
>> Der Programmierer, der Geld für seine
>> Arbeit bekommt, lagert seine Arbeit auf den Rechner oder die Nerven des
>> Kunden, der dafür Geld bezahlt, aus
> Dieses Argument ist natürlich besonders gut wenn man dann OpenSource
> Lösungen anprangert ;)
Ja, vor Allem die. Wenn die nicht perfekt laufen, bin ich sauer. 
Schließlich habe ich mir die Arbeit gemacht das runterzuladen, dann kann 
ich doch wohl erwarten, dass die sich die Arbeit machen, die richtig zu 
programmieren ;-)

Läubi .. schrieb:
> Dussel schrieb:
>> Das war Primzahlensuche in einen bestimmten Bereich (z.B. 0-100.000) mit
>> dem Sieb des Eratosthenes. Ziemlich primitiv, aber für den
>> Laufzeitvergleich brauchbar.
>
> Naja... nicht gerade die typische Aufgabe aber in welchem Bereich die
> Abweichung lag und ob die Algorithmen gleichwertig waren wissen wir
> immer noch nicht ;)
Das war ein Test, weil ich mir selber mal ein Bild machen wollte, ohne 
auf eventuell geschönte Benchmarks zurückgreifen zu müssen. Das Programm 
habe ich in einer Sprache geschrieben und dann kopiert. Nur das Anlegen 
des Arrays und die Ausgabe habe ich auf die Sprache angepasst. Beides 
fließt aber nicht in die Zeitmessung ein.

>aber in welchem Bereich die Abweichung lag[…]
>Gerade da PCs immer schneller werden ist es sowie müßig
>wegen wenigen Prozenten sich 'nen Kopf zu machen,
habe ich beantwortet mit
>Bei meinem Test hat Java für die Berechnung (nicht Ein- und Ausgabe)
> viermal so lange gebraucht wie C
Die Zeiten waren 10s in C mit gcc gegen etwas über 40s in Java mit 
Eclipse. Dabei machte es fast keinen Unterschied, ob die Optimierung 
ein- oder ausgeschaltet war. Mit anderen Suchbereichen habe ich das auch 
probiert und das Verhältnis war genauso, nur weiß ich die Zahlenwerte 
nicht mehr.

>wegen wenigen Prozenten
Wenn es nur ein paar Prozent wären, wäre ja nichts zu sagen, aber die 
Laufzeit des Javaprogramms waren 400% der Laufzeit des C Programms.

Versteh es nicht falsch, ich will Java nicht schlechtreden (das machen 
genug andere ;-), ich schreibe nur meine Erfahrung und meine 
Einschätzung.

[Läubi .. (laeubi)]

Eventuell magst du die beiden Programme falls du es noch findest ja mal 
hier hochladen, interessiert mich gerade mal.

[Dussel (Gast)]

Das sind die beiden Quelltexte. Ich habe es nochmal probiert und dabei 
kam im Bereich von 0-300.000 etwa zehn Sekunden in C gegen etwa 50s in 
Java. Wie gesagt, das habe ich vor längerem mal schnell geschrieben. 
Deshalb wird 1 als Primzahl angezeigt, glaube ich. Vielleicht läuft es 
auf einem anderen System auch anders. Kannst ja mal deine Ergebnisse 
schreiben.

[Läubi .. (laeubi)]

Dussel schrieb:
> Kannst ja mal deine Ergebnisse
> schreiben.

Also folgendes kommt bei mir raus, ich habe beide Programme so 
modifiziert, dass sie die Größe von der Kommandozeile lesen:

time ./a.out 100000
real  0m3.237s
user  0m3.136s
sys  0m0.008s

time java Primzahlen 100000
real  0m2.840s
user  0m2.904s
sys  0m0.032s

-------------------------------------------

time ./a.out 300000
real  0m25.993s
user  0m25.598s
sys  0m0.032s

time java Primzahlen 300000
real  0m21.951s
user  0m21.793s
sys  0m0.080s

Dussel schrieb:
> mit dem Sieb des Eratosthenes
Irgendwie seh' ich gerade nicht wie dein Algorithmus das 
implementiert... aber egal ist auf jedenfall die Ergebnisse von dem von 
dir angehängtem Quellcode, jeweils mit

g++ (Debian 4.4.5-8) 4.4.5

 und

javac 1.6.0_26

 ohne spezielle Aufrufparameter.

In diesem Fall kann die Problemlösung auf jedenfall sehr viel mehr vom 
Algorithmus als von der Programmiersprache profitieren.

[Klaus W. (mfgkw)]

Läubi .. schrieb:
> ohne spezielle Aufrufparameter.

was ja jetzt nicht besonders praxisnah ist...

Magst du es nicht nochmal anwerfen mit Optimierung?

[Läubi .. (laeubi)]

Klaus Wachtler schrieb:
> Magst du es nicht nochmal anwerfen mit Optimierung?

mit -O3

time ./a.out 300000
real  0m21.027s
user  0m20.661s
sys  0m0.028s

[Klaus W. (mfgkw)]

Danke.

Bei der Art von Programm sollte doch -O2 schon einiges bringen?

[Dussel (Gast)]

>Irgendwie seh' ich gerade nicht wie dein Algorithmus das implementiert...
In der for-Schleife in der Main werden alle zahlen durchlaufen und von 
der Funktion auf Primität(?) getestet. Wenn es eine Primzahl ist, wird 
die Zahl im Feld gespeichert.
In der Funktion wird versucht, die Zahl nacheinander durch alle Zahlen 
(außer 1), die kleiner als die Hälfte der Zahl sind zu teilen. Ist die 
Zahl durch eine andere Zahl teilbar, wird false zurückgegeben.

>In diesem Fall kann die Problemlösung auf jedenfall sehr viel mehr vom
>Algorithmus als von der Programmiersprache profitieren.
Natürlich. Es ging mir ja nicht darum, eine effektive Lösung zu finden, 
sondern ich wollte wissen, wie schnell die Sprachen rechnen. Und C 
rechnet halt anscheinend viermal so schnell wie Java.

[(prx) A. K. (prx)]

Dussel schrieb:

> rechnet halt anscheinend viermal so schnell wie Java.

Aber offenbar nur wenn du vor dem Rechner sitzt, nicht Läubi. Wobei da 
natürlich die verwendete Java Engine eine grosse Rolle spielen dürfte.

[Dussel (Gast)]

A. K. schrieb:
> Dussel schrieb:
>
>> rechnet halt anscheinend viermal so schnell wie Java.
>
> Aber offenbar nur wenn du vor dem Rechner sitzt, nicht Läubi.

Ja, wundert mich. Ich kann natürlich jetzt nicht sagen, ob sein C oder 
mein Java langsam ist. Die Zeiten kann man ja leider nicht direkt 
vergleichen.

[(prx) A. K. (prx)]

Aber du könntest mal was über die Versionen von Compiler und Java 
preisgeben.

Der Sieve-Benchmark ist übrigens ein Branchenklassiker. Ich würde mich 
nicht einmal wundern, wenn mancher Kommerzcompiler dafür einen 
Patternmatcher drin hat und ein wenig schummelt. Sowas in der Art ist 
schon gelegentlich nachgewiesen worden.

[Robert L. (lrlr)]

> Gerade da PCs immer schneller werden ist es sowie müßig
>wegen wenigen Prozenten sich 'nen Kopf zu machen, das Gesamtkonzept muss
>stimmen

das ist das was ich meinte
in der theorie (benchmark) ist java von mir aus 1/2 so schnell (egal)
das haben schnellere hardware schon LÄNGST kompensiert...


trotzdem sind "alle" java programme die ich kenne (ok, das  sind nicht 
viele) erst mit der letzten/neuesten hardware (i5 2500k usw.) erst 
halbwegs "flott" uterwegs

z.b. tv-browser, oder eine zeiterfassung die wir in der firma verwenden, 
eclipse  usw.

und (meistens) auch nur dann, wenns nicht mehr ganz "java only" ist (wie 
z.b. SWT usw.)

"früher" erkannte man jede java anwedung SOFORT wenn man nur das fenster 
größer zog (kein repaint während vergrößerung)
das ist inzwischen etwas besser, aber von einer nativ anwendug immer 
noch meilenweit enfernt...

kennt wer gegenbeispiele??

[Dussel (Gast)]

i686-apple-darwin9-gcc-4.0.1
Also anscheinend gcc 4.0.1

JavaSE 1.6.0_29-b11-402
Eclipse Indigo Release 1

[Läubi .. (laeubi)]

Dussel schrieb:
> ich wollte wissen, wie schnell die Sprachen rechnen. Und C
> rechnet halt anscheinend viermal so schnell wie Java

Nach meinen Tests nicht. Habe gerade auch mal ein paar kleinere 
Anpassungen an der Javaversion geändert (unnötige longs raus, 
Abbruchbedingung umgeschrieben):

public class Primzahlen {
    public static boolean Primzahltest(int Zahl) {
        int max = (Zahl / 2) + 1;
        for (int i = 2; i <= max; i++) {
            if (Zahl % i == 0) {
                return false;
            }
        }
        return true;
    }

    public static void main(String[] args) {
        int Eingabe = Integer.parseInt(args[0]);
        int Zaehler = 0;
        int Primzahlen[] = new int[Eingabe];
        for (int i = 0; i < Eingabe; i++) {
            if (Primzahltest(i)) {
                Primzahlen[Zaehler++] = i;
            }
        }
        for (int i = 0; i < Zaehler; i++) {
            System.out.println(Primzahlen[i]);
        }
    }
}

real  0m7.434s
user  0m7.993s
sys  0m2.384s

Die gleichen Optimierungen bei der C++ Variante:

real  0m7.321s
user  0m6.988s
sys  0m0.016s

Man sieht also:
a) der Unterschied ist vernachlässigbar (die Zahlen schwanken so um 
500ms zwischen wiederholten Aufrufen)
b) der Algorithmus und die Implementierung ist sehr viel entscheidender

Klaus Wachtler schrieb:
> Bei der Art von Programm sollte doch -O2 schon einiges bringen?

Keine Ahnung was der default ist aber wie gesagt selbst mit -03 bringt 
es jetzt nicht soooo den Vorteil (der Unterschied zwischen den Aufrufen 
macht das bald mehr aus), der Algoithmus macht da der Sache eher einen 
Strich durch die Rechnung.

Dussel schrieb:
> In der Funktion wird versucht, die Zahl nacheinander durch alle Zahlen
> (außer 1), die kleiner als die Hälfte der Zahl sind zu teilen
Ja der Trick ist doch aber iterativ immer mehr Zahlen auszuschließen:
http://de.wikipedia.org/wiki/Sieb_des_Eratosthenes

Hier mal 1:1 aus Wikipedia übernommen:

public class Primzahl2 {
    public static void main(String[] args) {
        int N = Integer.parseInt(args[0]);
        boolean gestrichen[] = new boolean[N+1];
        for (int i = 2; i <= N; i++) {
            if (!gestrichen[i]) {
                for (int j = i*i; j <= N; j+=i) {
                    gestrichen[i] = true;
                }
            }
        }
        for (int i = 2; i <= N; i++) {
            if (!gestrichen[i]) {
                System.out.println(i);
            }
        }
    }
}

real  0m3.620s
user  0m1.904s
sys  0m0.360s

Ohne system outs

real  0m1.279s
user  0m1.276s
sys  0m0.008s

[Arc N. (arc)]

Etwas komplexere Tests gibt's z.B. unter
http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php
http://shootout.alioth.debian.org/u32/java.php

Bspw. braucht hier auf dem alten Testrechner die C#-Version (Release, 
Any, .NET 4)
http://shootout.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=csharp
zirka 1.2 mal so lange wie die
http://shootout.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=cint
Variante (MSVC 10 /Ox /Ot, /Oy, /GL, /Ob2, /GS-, /fp:fast)
(die handoptimierte SSE-Variante
http://shootout.alioth.debian.org/u32/benchmark.php?test=spectralnorm&lang=gpp 
wurde absichtlich nicht genommen)

[Läubi .. (laeubi)]

Dussel schrieb:
> JavaSE 1.6.0_29-b11-402
> Eclipse Indigo Release 1

Führe die Versionen doch mal auf der Kommandozeile aus. Im Anhang mal 
meine aktuellen Versionen.

Compilieren:

g++ main.cpp -O3
javac Primzahlen.java

Ausführen

time ./a.out 300000
time java Primzahlen 300000

[(prx) A. K. (prx)]

@Robert L. (lrlr):

Der Pferdefuss von Java ist die Startzeit. Ein C Programm kommt fertig 
für die Zielmaschine übersetzt daher und startet daher entsprechend 
schnell. Bei Java hingegen wird in wesentlichem Umfang erst zur Laufzeit 
übersetzt, und das in mehreren Optimierungsstufen je nach Nutzungsgrad 
des Codestücks. Wenn im eigenen Programm oder in Libs genug Code 
dranhängt, dann kann sich das sehr deutlich bemerkbar machen.

Dazu kommt, dass sich die Übersetzungs- und Optimierungstechniken von 
JIT-Compilern und die Architektur von Intels Pentium 4 vermutlich nicht 
immer gut vertragen haben.

[Dussel (Gast)]

C:
real  0m9.510s
user  0m9.383s
sys  0m0.054s

Java:
real  0m10.234s
user  0m10.212s
sys  0m0.200s

Ok, scheint doch nicht so schlecht zu sein :-)
Dann muss ich mal rausfinden, wie ich Eclipse dazu kriege, das so 
schnell zu machen. Aber ich bin jetzt erstmal weg.

[Läubi .. (laeubi)]

Dussel schrieb:
> Dann muss ich mal rausfinden, wie ich Eclipse dazu kriege, das so
> schnell zu machen

In einer SDK ist es nicht das primäre Ziel schnellen Code zu erzeugen, 
es werden ggf. mehr Debugsymbole eincompiliert etc. außerdem ist gerade 
System.out sehr langsam, weil das erst mal abgefangen werden muss dann 
in ein GUI Fenster gebracht wird, ggf. scrollen...

Robert L. schrieb:
> trotzdem sind "alle" java programme die ich kenne
Na dann nenne doch mal die Programme in Java und die "schnelle 
Alternative" in C (bitte keine SDKs...) welche die bessere Performance 
bei gleichem Funktionsumfang bietet. So ist das doch stochern im 
Nebel...

Robert L. schrieb:
> "früher" erkannte man jede java anwedung SOFORT
Puh... gab es damals überhaupt schon C# und .Net? Das ist ja nun schon 
seit Ewigkeiten behoben.

[Arc N. (arc)]

Läubi .. schrieb:
> Robert L. schrieb:
>> "früher" erkannte man jede java anwedung SOFORT
> Puh... gab es damals überhaupt schon C# und .Net? Das ist ja nun schon
> seit Ewigkeiten behoben.

Netbeans und Eclipse kann man immer noch sofort von "normalen" 
Programmen unterscheiden: Andere Controls, u.a. andere Datei-Dialoge, 
Fensterinhalte werden bei einer Größenänderung extrem verzögert neu 
gezeichnet (Netbeans, Eclipse deutlich weniger)...

[Jasch (Gast)]

Arc Net schrieb:
> Läubi .. schrieb:
>> Robert L. schrieb:
>>> "früher" erkannte man jede java anwedung SOFORT
>> Puh... gab es damals überhaupt schon C# und .Net? Das ist ja nun schon
>> seit Ewigkeiten behoben.
>
> Netbeans und Eclipse kann man immer noch sofort von "normalen"
> Programmen unterscheiden: Andere Controls, u.a. andere Datei-Dialoge,
> Fensterinhalte werden bei einer Größenänderung extrem verzögert neu
> gezeichnet (Netbeans, Eclipse deutlich weniger)...

Dass das exakt garnix mit der IDE und alles mit den verwendeten 
Bibliotheken und vielleicht noch den eher widerlichen Code-Generatoren 
der IDEs zu tun hat ist aber schon klar?

Mag man die Bibos/Gens nicht - einfach nicht/andere benutzen.

Programmierer heutzutage, heulen immer rum "aber das war doch per 
Default so eingestellt!1ELF!!!". Einfach mal Cojones wachsen lassen, 
Defaults sind zum Ändern da!

[Markus V. (Gast)]

Interessant wäre es wahrscheinlich auch, eine (halbwegs) aktuelle 
Java-Version zu verwenden. Die 1.6 war schon vor 10 Jahren out und 
tatsächlich in manchen Belangen langsam. Mit der 2er Version von Java 
hat sich die Performance deutlich verbessert. Es wurden damals 
Verbesserungen am JIT-Compiler und am Garbage-Collector vorgenommen.

Gruß
Markus

[Läubi .. (laeubi)]

Markus V. schrieb:
> Die 1.6 war schon vor 10 Jahren out und
> tatsächlich in manchen Belangen langsam

Nix für ungut aber Java 1.6 --> Java 6 in Marketingsprech. Die 1.7 (Java 
7) ist erst vor kurzem zur offizellen Version geworden und das ist 
sicher noch nicht 10 Jahre her ;)

[Markus V. (Gast)]

@Läubi
Sorry, es ist mir entfallen, dass die JVM andere Versionen verwendet. 
Zum meiner (schwachen) Entschuldigung: Meine aktive Java-Zeit ist seit 
einiger Zeit vorbei.

Ich ziehe meinen vorherigen Post also offiziell zurück. ;-)

Markus

[HalfBit (Gast)]

Um C# braucht man keine Angst haben - vielleicht aber um Holger 
Schwichtenberg

- c# bleibt die Sprache schlechthin für´s .net-Framework UND ist eine 
empfohlene Sprache für die neue WinRT. Da C# als einzige Sprache 
asynchrone Aufrufe dann ohne Fußangeln unterstützt, so werden die 
meisten WinRT-Apps in C# geschrieben.

- WinRT ist nur für Apps. Große Anwendungen und erst recht die 
Business-Layer der WinRT-Apps werden natürlich auf Win32 oder net 
basieren.

- MS investiert zur Zeit sehr viel in die Weiterentwicklung von C#, etwa 
das Projekt Roslyn (CaaS-Programmiermodell)
Whitepaper: Roslyn Project Overview
http://www.microsoft.com/download/en/details.aspx?id=27744

- und in der nächsten Version werden schon mal die asyncs unterstützt
Whitepaper: Asynchrony in .NET
http://www.microsoft.com/download/en/details.aspx?id=14058

Zum Thema Silverlight: habs nie gemocht, werds nicht vermissen!