Soso .net war also schuld

[hroessler]

Ich habe schon viele, auch sehr komplexe Oberflächen mit C#/.net erstellt. Wer es heute nicht schafft eine schnelle Oberfläche mit .net zu erstellen, der hat einfach keine Ahnung. Mit der WPF ist die GUI sogar DirectX beschleunigt.

Was die Startzeiten angeht (davon kann ich auch ein Liedchen trällern) hätte man sich bei AMD aber mal sich den Microsoft eigenen .net Tools "ngen" bemühen können. Hierbei wird ein vorkompiliertes Image des Programmes erstellt. Vorkompiliert bedeutet, dass insbesondere das Just-in-time compiling während des Startvorgangs (weitestgehend) entfällt. Bei komplexen Programmen macht das richtig was aus.

Und ich glaube nicht, dass die UI bzw. dessen Ladezeiten das große Problem bei AMD ist. Primär ist es doch seit Jahren der Treiber selbst. Nvidia war hier lange Zeit "besser". Seit Windows 10 allerdings, scheint aber auch Nvidia seine Treiber nicht mehr ganz im Griff zu haben...

Greetz
hroessler

[Mithrandir]

*signed.

Mit .Net kann man ziemlich performante Oberflächen bauen. Ich hoffe einfach mal, dass der Stuss aus der Pressemitteilung von AMD stammt und nicht aus Golems eigener Feder. Das wäre erbärmlich.

[DerVorhangZuUndAlleFragenOffen]

Volle Zustimmung auch von mir. In meiner Firma haben teilweise das komplette Frontend für Operator-Arbeitsplätze in Industrieanlagen in .NET gebaut. Das kann man sehr schnell haben. Man muss es halt wollen und können. An einem oder beidem scheint es hier gemangelt zu haben.

"Entwickeln Sie ein positives Verhältnis zu Daten und freuen sie sich wenn wir mehr wissen!" ~Angela Merkel (12.06.2015)

[Kaiser Ming]

hroessler schrieb:
--------------------------------------------------------------------------------
> Ich habe schon viele, auch sehr komplexe Oberflächen mit C#/.net erstellt.
> Wer es heute nicht schafft eine schnelle Oberfläche mit .net zu erstellen,
> der hat einfach keine Ahnung. Mit der WPF ist die GUI sogar DirectX
> beschleunigt.

generelles DX ist eigentlich unsinnig
es sei denn die komplette Windowsoberfläche ist per se DX
wieso ist das eigentlich noch nicht der Fall könnte man mal kritisch fragen??


> Was die Startzeiten angeht (davon kann ich auch ein Liedchen trällern)
> hätte man sich bei AMD aber mal sich den Microsoft eigenen .net Tools
> "ngen" bemühen können. Hierbei wird ein vorkompiliertes Image des
> Programmes erstellt. Vorkompiliert bedeutet, dass insbesondere das
> Just-in-time compiling während des Startvorgangs (weitestgehend) entfällt.
> Bei komplexen Programmen macht das richtig was aus.

Ist eigentlich nicht Aufgabe des Programmierers sondern sollte transparent die Plattform erledigen. Aber selbst damit schleppt man natürlich den ganzen Wust der Umgebung mit. Bei .net hat Windows dabei noch ein Vorteil im Gegensatz zu Java weil das meiste schon preloaded ist.

Für irgendwelche Geschäftsanwendungen hab ich kein Problem mit, aber für simple Optionsdialoge und tägliche Programme ist mir native lieber. Das sollte einfach auf klick da sein.

gruss

[Dhakra]

Mithrandir schrieb:
--------------------------------------------------------------------------------
> *signed.
>
> Mit .Net kann man ziemlich performante Oberflächen bauen. Ich hoffe einfach
> mal, dass der Stuss aus der Pressemitteilung von AMD stammt und nicht aus
> Golems eigener Feder. Das wäre erbärmlich.

Es wurde nur bestätigt, dass die neue Software nicht mehr auf .NET basiert... das wurde von AMD aber nicht als Argument für einen besseren/schnelleren Start verwendet. Der kommt auch eher durch die Neuprogrammierung, ob das in NET passiert wäre oder nun in C++/C# spielt dabei eher eine untergeordnete Rolle.

[Kaiser Ming]

Dhakra schrieb:
> Neuprogrammierung, ob das in NET passiert wäre oder nun in C++/C# spielt
> dabei eher eine untergeordnete Rolle.

C# gibts nur in .NET
deine Aussage macht nur begrenzt Sinn
so ein Fehler passiert eigentlich nicht wenn man weiss wovon man redet?

[a user]

hroessler schrieb:
--------------------------------------------------------------------------------

> Und ich glaube nicht, dass die UI bzw. dessen Ladezeiten das große Problem
> bei AMD ist. Primär ist es doch seit Jahren der Treiber selbst.
also ich hatte jahre lang probleme mit den amd treibern, aber nie wegen dem treiber selbst, sondern weil er sich oft nicht installieren ließ. es kam immer eine fehlermeldung from .net framework das installieren irgend einer versionierten datei schlug fehl.

oft half da nur händisches entpackend es treibers und dessen installation.

will hierzu amd nicht in schutz nehmen, da andere es ja auch selbst mit .net gebacken bekommen. aber die gefühl 2000 .net installationsversionen, die man mitlerweile immer mitschleppt machen auch nciht selten probleme.

[PiranhA]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------
> C# gibts nur in .NET
Nicht ganz. Zum einen gibts ja Mono, die quelloffene Alternative zu .net. Zum anderen kann man mit Xamarin zB Android oder iOS Anwendungen in C# programmieren. Unity verwendet zB auch Mono als Skript-Engine, wo man dann eben mit C# Skripts schreibt.
Daher sollte man schon zwischen C# als Sprache und .net als Runtime unterscheiden.

[PiranhA]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------
> generelles DX ist eigentlich unsinnig
> es sei denn die komplette Windowsoberfläche ist per se DX
> wieso ist das eigentlich noch nicht der Fall könnte man mal kritisch
> fragen??

Also bei WPF wird alles mit Direct3D gerendert. Das ist nicht eine komplizierte Alternative, sondern der Default. Das hat halt eben den Vorteil, dass man die CPU entlastet. Allerdings benötigt man natürlich mindestens eine Dx9 fähige Grafikkarte mit passenden Treibern.

> Für irgendwelche Geschäftsanwendungen hab ich kein Problem mit, aber für
> simple Optionsdialoge und tägliche Programme ist mir native lieber. Das
> sollte einfach auf klick da sein.

Alle .net Dialoge die ich so kenne, sind eigentlich immer sofort da. Klar laden native Anwendungen 50ms schneller, aber das kriegt man mit Ngen und einer gescheiten Architektur auch in den Griff. Dafür arbeitet man bei managed Code in der Regel sehr viel effektiver. Die Performance Nachteile stehen in keinem Verhältnis zu der gewonnen Produktivität. Auch weil andere Tools zur Code-Analyse oder zum Profiling sehr viel besser mit Managed-Code funktionieren.
Native macht imho nur Echtzeitanforderungen und begrenzten Ressourcen Sinn (Treiber, Embedded Systems, Mobile, etc.) und bei High-Performance Geschichten, wo es auf jedes Promille Leistungssteigerung wertvoll ist.

[Kaiser Ming]

PiranhA schrieb:
--------------------------------------------------------------------------------
> Kaiser Ming schrieb:
> ---------------------------------------------------------------------------
> -----
> > C# gibts nur in .NET
> Nicht ganz. Zum einen gibts ja Mono, die quelloffene Alternative zu .net.

omg ich habs schon vermutet das das gleich kommt
ich denke das meinst du nicht wirklich ernst

> Zum anderen kann man mit Xamarin zB Android oder iOS Anwendungen in C#
> programmieren. Unity verwendet zB auch Mono als Skript-Engine, wo man dann
> eben mit C# Skripts schreibt.
> Daher sollte man schon zwischen C# als Sprache und .net als Runtime
> unterscheiden.

ok, doch du meinst das ernst
mono ist .net nachprogrammiert
xamarin ist mono
c# als beliebige Sprache ohne net (und mono) wirds nie geben
dazu ist das zu eng verwoben

[Kaiser Ming]

PiranhA schrieb:
--------------------------------------------------------------------------------
> Kaiser Ming schrieb:
> ---------------------------------------------------------------------------
> -----
> > generelles DX ist eigentlich unsinnig
> > es sei denn die komplette Windowsoberfläche ist per se DX
> > wieso ist das eigentlich noch nicht der Fall könnte man mal kritisch
> > fragen??
>
> Also bei WPF wird alles mit Direct3D gerendert. Das ist nicht eine
> komplizierte Alternative, sondern der Default. Das hat halt eben den

das ist schon klar
du hast mich missverstanden
naja nicht so wichtig


>
> > Für irgendwelche Geschäftsanwendungen hab ich kein Problem mit, aber für
> > simple Optionsdialoge und tägliche Programme ist mir native lieber. Das
> > sollte einfach auf klick da sein.
>
> Alle .net Dialoge die ich so kenne, sind eigentlich immer sofort da. Klar

Ich meinte die Programme die nur aus Optionsdialogen bestehen,
also sowas wie Grafikeinstellungen mit Catalyst, was grad das Thema ist.
Wenn Catalyst erstmal gestartet ist dann sind die Inhalte auch auf klick da.


> laden native Anwendungen 50ms schneller, aber das kriegt man mit Ngen und
> einer gescheiten Architektur auch in den Griff. Dafür arbeitet man bei

stell dir mal vor du hattest grad eine Riesenprogramm auf, Photoshop mit einer dicken Zeichnung, machst das Programm zu und startest dann mal ein .NET Programm. Was passiert? Windows muss sich den ganzen Wust erstmal wieder von der Platte reinziehen. Startzeit mehrere sek, Startzeit native 0.1sek.

Natürlich ist native nicht gleich native. Gibt auch native Programme die langsamer sind als solche mit managed Code. Manche Programme sind auch so lahm da ist egal womit sie programmiert sind, die werden im Zweifel solange erweitert bis sie lahm werden.


> managed Code in der Regel sehr viel effektiver. Die Performance Nachteile
> stehen in keinem Verhältnis zu der gewonnen Produktivität. Auch weil andere

Bestreitet keiner. Trotzdem haben sich die Performance Unterschiede bis heute nicht nivelliert. Anwender greifen wenn sie die Wahl haben zur native Anwendung.

Hier mal ein LeseTip
https://de.wikipedia.org/wiki/Vala_(Programmiersprache)
ähnlich C# kommt aber ohne Laufzeitlib aus


> Tools zur Code-Analyse oder zum Profiling sehr viel besser mit Managed-Code
> funktionieren.
> Native macht imho nur Echtzeitanforderungen und begrenzten Ressourcen Sinn
> (Treiber, Embedded Systems, Mobile, etc.) und bei High-Performance
> Geschichten, wo es auf jedes Promille Leistungssteigerung wertvoll ist.

Schnelle Programmierung ist nachwievor ein Thema, trotz Multiprozessoren, im normalen Endkundenbereich. Wie gesagt im Geschäftskundenbereich ist das ein anderes Thema, da gehts um Kosteneffizienz und Anpassbarkeit.

Ein native Chrome ist um einiges schneller als ein auf XUL aufsetzender Mozilla (ich weiss ist nicht .NET - mir fällt aber kein guter Vergleich bei nem .NET ein).

[hroessler]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------
> c# als beliebige Sprache ohne net (und mono) wirds nie geben
> dazu ist das zu eng verwoben.
Naja, ganz so stimmt das nicht. Microsoft entwickelt gerade einen native Compiler für C#. Das Kompilat soll ohne .net Runtime lauffähig sein.

Greetz
hroessler

[Rulf]

treiberprobleme gabs bei mir mit amd eigentlich nie nur seit die die einstellungen auf .net oberfläche umgestellt haben schon mehrfach probleme mit den einstellungen(div .net bugs)...aber die nimmt man am besten sowieso direkt im game/app vor...

[spiderbit]

Kaiser Ming schrieb:
--------------------------------------------------------------------------------

> Schnelle Programmierung ist nachwievor ein Thema, trotz Multiprozessoren,
> im normalen Endkundenbereich. Wie gesagt im Geschäftskundenbereich ist das
> ein anderes Thema, da gehts um Kosteneffizienz und Anpassbarkeit.

Ja zurecht ist das so, git hat gezeigt das geschwindigkeit sehr wichtig ist, sicher gits hauptfeature ist nicht speed sondern das es distributed ist und forks billig sind (wieder schnelll)

Nehmen wir mal nen einfaches Beispiel ein Texteditor, wenn ich ne todo.txt oeffne dort ein Punkt mit 1 2 woertern hinzufuegen will und dann wieeder schliesen, geht bei ner Java-app 80% der Zeit mit laden der App drauf, selbst wenns nur 50% sind ists zu viel.

Es kommt dann noch ein Aspekt dazu, mit .net und windows mag das ganze jeh nach windowsversion nativ aus sehen, aber gerne wird ja auch solche bytecompiler genutzt um Programme auf verschiedenen Plattformen zu laden, dort fuehlen sie sich oft wie ein Alien an, da sie nicht zum Desktop passen.

Nehmen wir dann mal python, das in fast allen Tests als Grottenlahm dargestellt. Aber die Startzeit ist fast wie bei nativen apps, warum weil nicht erstmal standartmaesig 5TB API geladen werden sondern nur kleine minimale module die man eben braucht, daher kann man das auch Konsumern an tun. Selbst Spiele sind damit kein problem, da man dort die Engine selbst eh meist in C geschrieben hat und nur noch die Logik damit macht.

Daher passt Java eben nicht auf nen Desktop der hin und wieden ganz flott ein bisschne load und nen kaltstart von irgendwas braucht, waerend python (mal die normale implementation) nicht in Umfelder passt, wo man tausende berechnungen pro sekunde staendig laufen laesst.

Soll jetzt keine Sprache X vs Sprache Y flamewar werden, aber aufm Consumer Desktop hat Java und .Net meist Nachteile.

Java und .Net hauptvorteil scheint mir neben Speed in manchen Szenarien die man aber auch mit anderen Frameworks/Sprachen jeh nach implementation bekommen kann, ist wohl die fixe Typisierung gegenueber z.B. Python. Da Java und .net anwendungen meist Monsterprojekte sind wo viele Entwickler zusammen arbeiten ist dies wohl recht gut um klar zu stellen wie ein bestimmten source gemeint ist. Es verhindert Missverstaendnisse.

Mag mich wer korrigieeren, aber das war fuer mich bisher das schluessigste Argument fuer Java/.NET vs Ruby/Python und Co.

[PeetaKirk]

AMD möchte eine einheitliche Oberfläche auf allen Plattformen, von Performanceverbesserungen DURCH den Umstieg weg von .net war nie die Rede. Eine einheitliche Oberfläche erfordert Bibliotheken, welche auf allen Zielplattformen (Windows, Linux) zur Verfügung steht, dies ist bei .net (anders als beim wohl jetzt eingesetzten QT) weniger der Fall.

[DerVorhangZuUndAlleFragenOffen]

PeetaKirk schrieb:
--------------------------------------------------------------------------------
> AMD möchte eine einheitliche Oberfläche auf allen Plattformen, von
> Performanceverbesserungen DURCH den Umstieg weg von .net war nie die Rede.
> Eine einheitliche Oberfläche erfordert Bibliotheken, welche auf allen
> Zielplattformen (Windows, Linux) zur Verfügung steht, dies ist bei .net
> (anders als beim wohl jetzt eingesetzten QT) weniger der Fall.

Microsoft versucht das gerade mit seinen Universal Apps in den Griff zu bekommen.

"Entwickeln Sie ein positives Verhältnis zu Daten und freuen sie sich wenn wir mehr wissen!" ~Angela Merkel (12.06.2015)

[Kaiser Ming]

hroessler schrieb:
--------------------------------------------------------------------------------
> Kaiser Ming schrieb:
> ---------------------------------------------------------------------------
> -----
> > c# als beliebige Sprache ohne net (und mono) wirds nie geben
> > dazu ist das zu eng verwoben.
> Naja, ganz so stimmt das nicht. Microsoft entwickelt gerade einen native
> Compiler für C#. Das Kompilat soll ohne .net Runtime lauffähig sein.
>
> Greetz
> hroessler


ok das ist mir tatsächlich neu

> Compiler für C#. Das Kompilat soll ohne .net Runtime lauffähig sein.

also auch nicht reinkompiliert?