Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Was wünscht ihr euch für C# 5?
sth_Weird
myCSharp.de - Member



Dabei seit:
Beiträge: 469
Herkunft: BaWü

beantworten | zitieren | melden

Zitat
Sorry wenn ich das so direkt sage, aber deine Meinung kommt mir irgendwie rüber, als ob du dich mit dem neuen nicht anfreunden willst, es nicht lernen magst und dich deswegen dagegen streubst.
Dass meine Meinung so rüberkommen kann kann ich nachvollziehen, aber es trifft nicht zu. Ich lerne eigentlich immer gerne neues (ich finde z.B. WPF sehr interessant und die Einführung von Generics in C#2 fand ich genial). Was mir in diesem Fall nicht so gut gefällt ist die Tatsache, dass es letztendlich nichts "Neues" ist sondern nur eine alternative Schreibweise, die ich lernen muss wenn ich Code verstehen will der so im Netz rumschwirrt, ohne einen Mehrwert davon zu haben.
Und lesbarer finde ich die "alte" Variante, aber möglicherweise ist das Ansichtssache.
Zitat
Nein, böse Falle. Var ist genauso statisch getyped, wie alles andere auch...
dann hab ich mich hier mangels besseren Wissens geirrt, sorry. Ich habe hier spontan die Gefahr gesehen dass ich Schreiben könnte var bla und var blub und dann var ergebnis = bla * blub und wenn ich bla = "hallo" und blub = "!" setzen würde dann flöge eine Exception zur Laufzeit weil Strings nicht multipliziert werden können...


gruß
sth_Weird
~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
Fluchen ist die einzige Sprache, die jeder Programmierer perfekt beherrscht
* * *
Linux is for free...if your time is worth nothing
~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+~+
private Nachricht | Beiträge des Benutzers
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 2.891

beantworten | zitieren | melden

Zitat von sth_Weird
dann flöge eine Exception zur Laufzeit weil Strings nicht multipliziert werden können...
Nein, der Compiler "wüsste" zur Compilezeit, dass es strings sind, und würde nicht kompilieren.
Zitat von var (C#-Referenz)
Eine implizit typisierte lokale Variable ist stark typisiert, so als hätten Sie den Typ selbst deklariert. In diesem Fall hat jedoch der Compiler den Typ bestimmt.
Zitat von sth_Weird
Was mir in diesem Fall nicht so gut gefällt ist die Tatsache, dass es letztendlich nichts "Neues" ist sondern nur eine alternative Schreibweise, die ich lernen muss wenn ich Code verstehen will der so im Netz rumschwirrt, ohne einen Mehrwert davon zu haben.
Dazu - vor allem auch im Kontext des var-Schlüsselwortes - kommt mir gerade der Artikel 7 Stages of new language keyword grief in den Sinn... :evil:

Gruß,
dN!3L
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

was das var betrifft so würde ich mir für c#5 wünschen, das es abgeschafft wird, da zwar nciht die typsicherheit flöten geht (das hat schon 'dynamic' geschafft), jedoch sieht man nicht den typ sofort im code und das ist etwas was ich enttäuschend finde. es geht ja um die lesbarkeit von code und wenn da steht:


var blubb = Foo();

dann sehe ich nciht den typ unmittelbar. ich muss mir erst den rückgabetyp von Foo() anschauen um zu wissen, was da für ein typ verwendet wird. das war in meinen augen eine verschlimmbesserung.
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo JAck30lena,

das var wurde deshalb eingeführt da es in Verwendung mit LINQ eine Erleichterung ist - sonst würden Ungetüme von Typen angegeben werden müssen.

Sonst braucht es ja nicht verwendet werden ;)


mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Peter Bucher
myCSharp.de - Experte

Avatar #jVxXe7MDBPAimxdX3em3.jpg


Dabei seit:
Beiträge: 5.940
Herkunft: Zentralschweiz

beantworten | zitieren | melden

Hallo zusammen

Meine Meinung dazu steht hier:
- Alles var – oder nicht?
Zitat von gfoidl
das var wurde deshalb eingeführt da es in Verwendung mit LINQ eine Erleichterung ist - sonst würden Ungetüme von Typen angegeben werden müssen.
Nein, dafür kann man sie gut gebrauchen aber "eigentlich" wurden sie für die Anonymen Typen eingeführt.
Dort _brauchst_ du var, sonst kannst du die gar nicht nutzen.


Gruss Peter
--
Microsoft MVP - Visual Developer ASP / ASP.NET, Switzerland 2007 - 2011

- https://peterbucher.ch/ - Meine persönliche Seite
- https://fpvspots.net/ - Spots für FPV Dronenflüge
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo Peter,
Zitat
Nein, dafür kann man sie gut gebrauchen aber "eigentlich" wurden sie für die Anonymen Typen eingeführt.
Da hast du Recht. LINQ ist nur ein Anwendungsfall davon.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

problematisch hierfür sehe ich nur das vergrößerte potenzial für noch mehr "shit"-code. klar, wenn man sich an die richtlinien hält, dann ist alles kein problem. dann könnte ich auch ohne typsicherheit leben aber dummerweise funktioniert es nciht so, wie man es scih auf dem blatt papier ausdenkt.

var ist in meinen augen nur eine weitere möglichkeit für shitcode und daher habe ich auch ein wenig bammel bei c#4 mit den dynamic.
kyoko12
myCSharp.de - Member



Dabei seit:
Beiträge: 36
Herkunft: Wels/Oberösterreich

beantworten | zitieren | melden

Also, meine Wunschliste sieht derzeit so aus:

1.) Mixins/Traits (also quasi Interfaces, mit dem Unterschied, dass ich Standardimplementierungen angeben kann). Daran wird laut einiger Blog-Posts und auch Videos auf Channel9 schon gearbeitet, also hoffe ich mal, dass sowas wirklich bald kommt.

2.) Operatorüberladung in Interfaces - wäre schon einige male praktisch gewesen. Normale statische Methoden will ich aber weiterhin nicht in Interfaces haben.

3.) Indexed Properties oder, wie mans auch nennen könnte, benannte Indexer. Das ist eine Sache, die ich schon oft praktisch gefunden hätte.

4.) Design by Contract wie in Spec#, inklusive eines Theorem Proofers, der die Contracts zur Compilezeit analysiert.

5.) Aufhebung der - meiner Meinung nach recht gekünstelten - Einschränkung, dass Contraints für Generics nicht von den Typen System.Enum, System.Delegate und System.MulticastDelegate sein dürfen.

So, das fällt mir auf die Schnelle ein. Ich weiß, recht viel, das würde sehr wahrscheinlich gar nicht alles in eine Version passen. Aber man wird ja wohl träumen dürfen ;)
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo,

mir sind passen zur beginnenden Vorweihnachtzeit noch zwei Wünsche eingefallen ;)
  1. Optimierungen des C#-Compilers
  2. Unterstützung für Vektorgrafiken


ad 1) der C#-Compiler könnte optimierten IL-Code ausgeben anstatt den Code nur nach IL zu übersetzen. Also zB mehr Inlining, Schleifenmanipulationen, etc.
Vorteil: Das Programm läuft schneller und dem JITer könnte arbeit weggenommen werden.
Nachteil: Im Reflektor ist der Code nicht mehr so gleich wie dem Quellcode (sofern das wichtig ist, bei yield schauts zB auch ganz anders aus)

ad 2) die meisten Methoden der Graphics-Klasse sind Vektoroperationen wie zB DrawLinie, etc. Die unterstützten Ausgabeformate sind alles Rastergrafiken (Pixelgrafik). Super wäre hier wenn SVG, EPS, PDF direkt erstellt werden könnte (oder nur 1 davon, da sich Vektorformate relativ einfach konvertieren lassen).
Hierzu gibt es zwar mit Cairo eine funktionierende Alternative, aber dies könnte doch direkt dabei sein und somit würden die üblichen Graphics-Befehle weiter verwendet werden können.
Vorteil: Man hat eine Vektorgrafik ;)
Nachteil: Fällt mir keiner ein.


mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

Ist zwar schon älter, aber: Typisierte Integers!

Was soll das sein: Wir verwenden für die Implementierung diskreter Algorithmen C#. Da kommen häufig indizierte Objekte vor. Die dann auch noch Redundant gespeichert werden müssen.


Also habe ich z.B:


class Person{
    int id;
    int department;
}

class Department{
    int id;
    int[] persons;
    int[] boss;
}


class Specification{
    Person[] persons;
    Department[] departments;
}

Aus performancegründen führt an Arrays kein weg Vorbei, Dictionaries sind keine Alternative.

Nun ist das Problem, das ich z.B. mit der Department-ID auf eine Person zugreifen kann. Also departments[person.id]. Das bekommt man i.d.R. noch gut hin. Ekelhaft ist eher die Verwechselung lokaler und globaler IDs (ist z.B. boss in Department der Index der Person im Department oder global?)

Mit typesicheren Arrays und IDs ginge das ganze viel einfacher:

Ist zwar schon älter, aber: Typisierte Integers!

Was soll das sein: Wir verwenden für die Implementierung diskreter Algorithmen C#. Da kommen häufig indizierte Objekte vor. Die dann auch noch Redundant gespeichert werden müssen.


Also habe ich z.B:


define PersonId:int;
define DepartmentId:int;

class Person{
    PersonId id;
    DepartmentId department;
}

class Department{
    define LocalPersonId:int;
    DepartmentId id;
    PersonId[<LocalPersonId>] persons;
    LocalPersonId[<LocalPersonId>] boss;
}


class Specification{
    Person[<PersonId>] persons;
    Department[<DepartmentId>] departments;
}

Dabei stellt ein Array Person[<PersonId>] sicher, dass als Index nur eine PersonId übergeben werden kann.


In C++ kann man sich das mit Structs und nachbauen, das wird alles wegoptimiert. In C# geht das leider nicht, da kostet sowas zu viel Performance. Obiges Konstrukt hingegen würde zur Copilezeit geprüft werden können und kostet zur Laufzeit keine Performance.


Ähnlich sind die Units in F#.

Viele Grüße,
Uwe
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Uwe81 am .
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

nichts für ungut aber warum übergibst du die id eines objektes und nicht gleich das objekt selbst? dann hast du es gleich typisiert und die id ist die referenz?
Uwe81
myCSharp.de - Member



Dabei seit:
Beiträge: 282
Herkunft: Ludwigshafen

beantworten | zitieren | melden

ist nun off-topic
Zitat
nichts für ungut aber warum übergibst du die id eines objektes und nicht gleich das objekt selbst? dann hast du es gleich typisiert und die id ist die referenz

Zum einen erwarten mathematische Algorithmen sehr oft nummerierte Elemente. Fast alle Graphenalgorithmen sind wesentliche einfacher, wenn die Knoten 0...n-1 und die Kanten 0...m-1 sind, die Indizierung ist also notwendig. Mixed Integer Programme sind sonst völlig unmöglich. Insbesondere ist die lokale Indizierung der Personen in einem Department notwendig, wenn ich einen Algorithmus nur auf diese Teilmenge anwenden möchte.
Das alles immer neu zu indizieren oder zwischen Objekten und IDs hin und herzuwechseln is teuer und fehleranfällig.


Zum anderen trat bei uns das Problem auf (das kann aber auch eine softwarearchitektonische Schwäche bei mir sein), dass der Code dann untestbar wurde. Die Objekte im realen Beispiel enthielten viele verschiedene technische Eigenschaften, von denen ein Algorithmus ich i.d.R. nur wenige brauche. Oder wissen muss, ob objekte unterscheidbar sind.

Oftmals reicht es in unseren Algorithmen zu wissen, dass ich wohl unterscheidbare Objekte habe. Ich muss nur wissen, ob Personen gleich sind oder nicht. Die ID reicht. Solche Testdaten lassen sich leicht aufsetzen. Habe ich hingegen nicht eine ID sondern eine Referenz, dann müssen die Personen initialisiert sein. Ihnen muss also ein Alter, Vorname, Nachname, Besoldungsstufe, ... zugewiesen worden sein.
private Nachricht | Beiträge des Benutzers
Florian Reischl
myCSharp.de - Experte

Avatar #avatar-2880.jpg


Dabei seit:
Beiträge: 1.564
Herkunft: München

beantworten | zitieren | melden

Die Möglichkeit in einem Interface einen Constructor zu definieren. Mit ISerializable zeigt .NET recht schön, dass das Feature manchmal nicht schlecht wäre.
Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.
private Nachricht | Beiträge des Benutzers
Corpsegrinder
myCSharp.de - Member



Dabei seit:
Beiträge: 401

beantworten | zitieren | melden

Zitat von Florian Reischl
Die Möglichkeit in einem Interface einen Constructor zu definieren. Mit ISerializable zeigt .NET recht schön, dass das Feature manchmal nicht schlecht wäre.

Ich würde sogar so weit gehen und sagen, dass man ganze Methoden in Interfaces implementieren können sollte. Das ganze funktioniert in Scala mit Traits wunderbar! Bin ein echter Fan davon geworden.
private Nachricht | Beiträge des Benutzers
0815Coder
myCSharp.de - Member



Dabei seit:
Beiträge: 767

beantworten | zitieren | melden

Zitat von gfoidl
Optimierungen des C#-Compilers

ad 1) der C#-Compiler könnte optimierten IL-Code ausgeben anstatt den Code nur nach IL zu übersetzen. Also zB mehr Inlining, Schleifenmanipulationen, etc.
Vorteil: Das Programm läuft schneller und dem JITer könnte arbeit weggenommen werden.
Nachteil: Im Reflektor ist der Code nicht mehr so gleich wie dem Quellcode (sofern das wichtig ist, bei yield schauts zB auch ganz anders aus)

Dass das nicht der C# Kompiler "voroptimiert" liegt daran, das dieser nicht weiss, auf welchem Prozessor der Code laufen wird (abgesehen von 32/64 bit). So kann der JITer nämlich noch intensiver optimieren. ZB wenn er die Größe der L1 und L2 Caches kennt...
loop:
btst #6,$bfe001
bne.s loop
rts
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

Zitat
So kann der JITer nämlich noch intensiver optimieren.

ich würde eher etwas begrüßen, das beim start der anwendung automatisch eine ngen compilierung anwendet. so muss man sich dann nicht im setup anstrengen.
Tobias_H
myCSharp.de - Member



Dabei seit:
Beiträge: 15
Herkunft: München

beantworten | zitieren | melden

Zitat von gfoidl
Unterstützung für Vektorgrafiken
Servus Gü,

auch wenn Dein Wunsch schon älter ist:

zu deinem Vektorgrafikwunsch kann ich Dir einen Tipp geben: SVG2XAML.

Grüße

Tobi
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo Tobias_H,

danke für den Tipp, aber ich bin mit Cairo ganz zurfrieden ;-)



Hallo 0815Coder,

deine Antwort hab ich erst jetzt gesehen ;-)
Zitat
Dass das nicht der C# Kompiler "voroptimiert" liegt daran, das dieser nicht weiss, auf welchem Prozessor der Code laufen wird (abgesehen von 32/64 bit). So kann der JITer nämlich noch intensiver optimieren. ZB wenn er die Größe der L1 und L2 Caches kennt...
Waraum sollte das dem C#-Kompiler beim Inlining, Schleifentauschen, etc. hindern? Das ist weitestgehend unabhängig vom tatschächlichen Prozessor. Eine geinlinete Methode wird überall schneller sein.
Der JITer könnte zwar "intensiver optimieren" - das macht er aber nicht denn es musste ein Kompromiss zwischen Laufzeitverzögerung und Optimierung gefunden werden. Von daher könnte ruhig der C#-Kompiler einen Teil der Arbeit abnehmen und den JITer entlasten.

Wird allerdings Jacks Vorschlag berücksichtigt könnte man sich das alles sparen und den NGEN optimieren lassen was das Zeug hält ;-)


mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

in .net 4.0 wurde im übrigen der JITTER verbessert. interessant zu wissen ist, das der x64 JIT mehr optimiert als der x86.

das ist zwar immernoch nciht so gut wie eine ngen compilierung aber es geht in die richtige richtung.

ngen aht dafür den nachteil das er im schnitt eine sekunde für je 6 mb il-code benötigt.
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 9.957

beantworten | zitieren | melden

@gfoil:
Zitat
Eine geinlinete Methode wird überall schneller sein.
Das war schon ein weit verbreiterter Irrglaube, als die ersten C/C++ Compiler damit angefangen haben.

Auch bei einem JIT gilt "premature optimisation is evil"!
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo FZelle,
Zitat
Das war schon ein weit verbreiterter Irrglaube, als die ersten C/C++ Compiler damit angefangen haben.
Ich kenn mich bei C/C++ Compilern nicht aus und kann daher nicht nachvollziehen warum das so sein soll - vielleicht haben die 1. C/C++ Compiler das einfach nicht richtig gemacht ;-). Bei Fortran ist inlining auf jeden Fall schneller. Warum das in .net anders sein soll weiß ich nicht - es entfällt der Methodenaufruf und somit wird Zeit gespart (wenn auch nur wenig - aber je größer die Anzahl der Aufrufe je größer die Ersparnis).
Der einzige Nachteil ist dass das Kompilat größer wird. Das sollte heutzutage allerdings keine Nachteil mit Gewichtung sein.

Es sei denn du meinst die Möglichkeit eines Inline-Schlüsselworts o.ä. Das habe ich jedoch nicht gemeint. Nur das Inlining das der Compiler durchführt und via Buildeinstellungen (wie zB in Fortan kann die maximale Größe einer Methode angegeben werden die geinlined werden soll) möglich ist habe ich gemeint. Die derzeitige 32 B Größe von Methoden mit einer maximalen zirkulären Komplexität von 1 ist nicht gerade viel - zusätzlich hindern noch div. andere "Dinge" den JITer daran eine Methode zu inlinen auch wenn diese dafür predistiniert wäre (siehe auch To Inline or not to Inline: That is the question).

BTW: Knuth meinte mit "premature optimization is the root of all evil" dass während des Software-Entwurfs nicht vorzeitige Optimierungen durchgeführt werden sollen bzw. dass Code erstellt werden soll um die Funktionalität zu bewerkstelligen und diesen nicht so zu verbiegen dass er "optimiert" da steht.


mfG Gü


Edit: Gem. Jacks Antwort die Maximalgröße der Methode für Inlining korrigiert.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von gfoidl am .

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

Zitat
Die derzeitige 32 kB (?)

enferne das "k" und füge " + maximale zirkuläre komplexität von 1" hinzu. dann passts. außer beim neuen .net 4.0 x64 compiler der inlined deutlich mehr.

inlining bringt vorteile. sogar ziemlich spürbare. jedoch erkauft man sich dadurch auch den bereits erwähnten nachteil, das die assemblies deutlich größer werden. zwar klingt das erstmal nciht schlimm (heutzutage) aber wenn man noch das .net "feature" hinzuzieht, das man keine einzelnen dll´s aus einer appdomain entladen kann, dann kann das recht schnell unbedachte konsequenzen haben.

f# z.b. betreibt massives inlining... vermutlich von fortran abgekupfert und weil es in funktionalen sprachen deutlich einfacher ist.
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

@Jack: Danke für die Berichtigung - dann ist es ja noch weniger....


mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
dN!3L
myCSharp.de - Experte

Avatar #avatar-2985.png


Dabei seit:
Beiträge: 2.891

beantworten | zitieren | melden

Zitat von JAck30lena
jedoch erkauft man sich [durch inlining] auch den bereits erwähnten nachteil, das die assemblies deutlich größer werden.
Durch Inlining werden doch aber die Assemblies an sich nicht größer. Das ist ja erstmal Intermediate Code, wo noch gar nicht geinlined wird. Oder?
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo dN!3L,

daher habe ich von Kompilat geschrieben ;-). Wenn jedoch der C#-Compiler inlined - was mein Vorschlag ist - dann ist auch die Assembly größer.


mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 9.957

beantworten | zitieren | melden

Als ich damals Knuth getroffen habe, sass er gerade an Minix.
Ich weiss wovon er gesprochen hat.

Wenn du dem C# compiler die Erlaubnis gibst u.a. das Inlining zu machen, verhinderst Du damit das der JIT/NGen den IL Code auf den Prozessor anpassen kann.

Es gibt jetzt bereits mit den Defaultparametern in C# das Problem das es Version Misssmatch gibt, das würde sich dann noch erweitern und zu Problemen gigantischen Aussmasses führen.
private Nachricht | Beiträge des Benutzers
gfoidl
myCSharp.de - Team

Avatar #avatar-2894.jpg


Dabei seit:
Beiträge: 6.779
Herkunft: Waidring

beantworten | zitieren | melden

Hallo FZelle,

vorab: Mein Wunsch resultiert daher dass der JITer aus "Zeitmangel" nur begrenzt inlinen kann und daher könnte der C# Compiler dem JIT etwas an Arbeit abnehmen.

was hat Inlining mit den Defaultparametern zu tun? Dass diese *schlecht* sehe ich auch so wie du. Version Missmatch durch Inlining kann sich auch nur darin äußern dass irgendwo die erhofften Leistungsvorteile durch Inlining nicht eintreffen - aber das ist (für mich) kein gigantischer Ausmaß.
Oder meinst du dass eine Methode mit Defaultparametern geinlined werden sollte? Das ginge allerdings nicht - das wäre ein GAU - und darauf zielt mein Wunsch auch nicht ab.


Die Aussage dass eine geinlinte Methode überall schneller relativiere ich ein wenig denn es kommt auch Instruction-Pipelining, Cache-Size, etc. hinzu und somit ist überall nicht ganz korrekt, denn in seltenen Fällen kann es sogar "langsamer" werden. Daher auch kein generelles und allgemeines Inlining ;-)
Dennoch ist die Heuristik die der JITer verwendet ziemlich starr und durch eine zusätzliche Compileroption oder eine weitere Option in MethodImpl (also das Gegenstück zu NoInlining) könnte der C# Compiler oder auch der JITer angewiesen werden diese Methode zu inlinen. In diesem Fall kann das aber gleich der C# Compiler durchführen.

Den Vorteil den ich darin sehe ist dass ich nicht auf die (nicht offiziell von MS dokumentierte) Heuristik des JITer angewiesen bin. So können auch Methoden geinlined werden die der JITer nicht dafür in Betracht ziehen würde. Ob sich das für die betroffene Methode ausgezahlt hat zeigt ein Performance-Vergleich. Ich gehe aber davon aus dass sich das meistens auszahlen wird.

Der MS C++ Compiler für .net kann auch Methoden inlinen (gemeint sind nicht Inline-Functions sondern Inline-Expansion). Warum sollte es also der C# Compiler nicht können?

Wie bereits erwähnt ist die Heuristik mit welcher der JITer entscheidet was mit einer Methode passiert ziemlich starr und mir ist nichts bekannt dass der JITer auf die Prozessorarchitektur eingeht. Also kann ich dein Argument in Bezug auf JIT nicht nachvollziehen, wobei du recht hättest wenn der JITer das so machen würde. Macht er aber nicht (außer x86 und x64, aber keine Cache-Berücksichtigung udgl.).

Ich verstehe also nicht warum dieses Feature nicht unterstützt werden sollte. Wenn es wirklich unnötig sein sollte dann erklär mir das bitte detailierter.


Zitat
Als ich damals Knuth getroffen habe
Ich habe ihn (leider) noch nicht getroffen ;-)



mfG Gü


PS: Es sei noch angemerkt dass ich mir keine Gedanken über die Art und Weise wie dem Compiler mitgeteilt wird dass er eine Methode inlines soll, etc. gemacht habe. Das obige sind nur spontane Gedanken wie es umgesetzt werde könnte.

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
private Nachricht | Beiträge des Benutzers
FZelle
myCSharp.de - Experte



Dabei seit:
Beiträge: 9.957

beantworten | zitieren | melden

Wie mit allem was mit Optimieren zu tun hat, kommt es auf den Kontext an.

Wenn du beim Compilieren meinst, das deine Funktion/Property/wasAuchImmer Inlined werden soll, dann mag das ja für diesen einen Augenblick richtig sein, aber jeder Inline Algorithmus muss entscheiden wann er damit aufhört, sonst haben wir irgendwann alles in Main stehen und kombiniert mit Loop Unrolling dann 100GB an Maschinencode.

Gerade bei .NET Assemblies, die ja als Ganzes oder in Teilen ausserhalb deines Kontextes wiederverwendet werden können, kann deine Sichtweise komplett falsch gewesen sein, aber sie ist dann nicht mehr korrigierbar.

Beispiel PropertyInlining:
Du hast jetzt 5 Zeilen in dem getter um dein Property zu lesen.
Ist ja ein guter Kandidat für soetwas.
Jetzt Machst du das in einer schleife, weil das ist eine Liste.
Jetzt will der C# compiler das Inlinen, weil ist ja besser.
Was macht aber jetzt der alg. für das Loopunrolling?
Wäre es bei x "Runden" besser zu Inlinen oder zu unrollen?
Und es gibt hunderte von verschiedenen Algs. die je nach Kontext benutzt werden können, um die Laufzeit oder den Speicherverbrauch zu optimieren.

Und deshalb ist der c# Compiler die falsche stelle.

Wenn du beispielsweise die GNU Compiler nimmst, vorne weg Gcc.
Die erzeugen auch nicht hoch optimierten Maschinencode, sondern einen Assembler code, den dann der Optimizer wirklich durcharbeitet, und dann erst den optimierten Code rauswirft.

Genauso ist es auch in .NET.
NGen oder JIT machen die Optimierung, und an der Stelle an der die Entscheidung für oder gegen einen der vielen Algs. getroffen werden kann/muss, da machen sie es.
Das hat auch beim JITer nichts mit Zeitmangel zu tun, ob er inlined oder einen Funktionsaufruf macht fällt beim Jitten nicht wirklich auf.

Deshalb auch hier die sache mit der Premature Optimisation.
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

bevor hier weiter über den jitter gemutmaßt wird...
--> CLR Optimizations In .NET Framework 3.5 SP1
(ich lese gerade, das auch mein wissen über den jitter bereits veraltet ist.... alles was ich bislang geschrieben habe, betrifft eher den .net 2.0 jit. --< (.NET 2.0 jit + method inlining

ich werde weitersuchen und hoffentlich etwas schönes für den .net 4.0 jit finden.
hier was zum .net 4.0 x64 JIT --> Tail Call Improvements in .NET Framework 4
Corpsegrinder
myCSharp.de - Member



Dabei seit:
Beiträge: 401

beantworten | zitieren | melden

Zitat von FZelle
Als ich damals Knuth getroffen habe, sass er gerade an Minix.
Ich weiss wovon er gesprochen hat.


Sorry für OT, aber was hat Knuth mit Minix zu tun?
private Nachricht | Beiträge des Benutzers