Laden...

Live Review mit dem .NET Team

Erstellt von Abt vor 6 Jahren Letzter Beitrag vor 6 Jahren 4.097 Views
Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren
Live Review mit dem .NET Team

Ein Mitarbeiter von Intel hat ein Issue an das .NET Repository geschickt: API Proposal: Add Intel hardware intrinsic functions and namespace

Mit Hilfe dieser API ist es möglich - respekt, wer es beherrscht - direkt die CPU anzusprechen; und zwar direkt mit C# Code!

Jedenfalls hat sich das .NET Team dazu entschieden sich etwas über die Schulter schauen zu lassen und den Review Prozess Live auf YouTube zu übertragen.
Stattfindet wird das Spektakel am Dienstag, 8 August um 19 Uhr deutscher Zeit.

Wer also die Zeit und Lust hat - auch wenn es ein wirklich sehr tiefes Thema sein wird - sollte die Gelegenheit unbedingt nutzen!

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Edit gfoidl: iFrame-Inhalt nicht mehr möglich

148 Beiträge seit 2013
vor 6 Jahren

Danke für die interessante Nachricht!

Ein Mitarbeiter von Intel hat einen sehr mächtigen und eindrucksvollen Pull Request an das .NET Repository geschickt:

Hört sich an als wäre es schon implementiert 😃
Also nur zur kurzen Klarstellung: Es wurde ein API Vorschlag veröffentlicht. Sollte man sich für diesen Vorschlag aussprechen, würde die eigentliche Implemetierung beginnen. Und wie Fei Peng, der Ersteller des Vorschlags, richtig schreibt:

Implementing all the intrinsics in JIT is a large-scale and long-term project, so the current plan is to initially implement a subset of them with unit tests, code quality test, and benchmarks.

Grüße
Geaz

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Hört sich an als wäre es schon implementiert 😃

Ein Pull Request ist ein Vorschlag. Und mächtig ist etwas nicht nur anhand der Menge, sondern auch anhand der Funktion und des Mehrwerts.
Und in meinen Augen ist das allein durch die Investition des API Vorschlags durch Intel gegeben. Daher meine Ausdruckweise.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Abt,

Ein Pull Request ist ein Vorschlag.

So wie ich es sehe ist es keine Pull Request, sondern eine **Issue **mit dem Vorschlag.

Ein Pull Request wäre dann eine Codeänderung (in einem Feature-Branch) mit der Bitte um Review und Merge zu master 😉

Aber der Vorschlag ist sehr interessant!

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!"

3.170 Beiträge seit 2006
vor 6 Jahren

Hallo zusammen,

also viellecht habe ich da was grundsätzlich missverstanden - aber ich kann mich mit dem Gedanken überhaupt nicht anfreunden, dass spezielle Prozessorfeatures eines speziellen Herstellers sich bis auf die Sprache C# durchdrücken.

Warum sollte man für Intel hier eine Extrawurst braten? Solche Dinge gehören meiner Ansicht nach ausschließlich in den Jitter, und sonst nirgendwohin. Und bis es soweit ist, dass es im Jitter integriert werden kann, sollte man IMO da die Finger davon lassen.

Als Sprache sollte C# jedenfalls in meinen Augen von solch proprietärem Zeugs verschont bleiben.
Naja, mal schauen was sie draus machen...

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Performance spielt für die .NET Core Welt eine viel höhere Rolle als für das .NET Framework.
Dahingehend passt der direkte Zugriff auf Hardware-Ressourcen durchaus rein. Gibt genug die deswegen noch C++ Bibliotheken schreiben, die sie dann via C# callen.

Die Instruction Sets, so stehts auch im PR, sollten so gestaltet sein, dass sie sowohl Intel wie auch AMD verstehen (die sind ja großteils gleich im Syntax) und bei einer potentiellen Nicht-Unterstützung es ein Software-Fallback geben soll.
Es ist also nicht Hersteller-spezifisch.

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo MarsStein,

mit deiner Aussage, dass keine propriertären Features in die Sprache sollten, stimm ich dir zu.
Ich denke aber du hast den Vorschlag missverstanden, wie Abt auch geschrieben hat.

Beim aktuellen Vorschlag gefällt mir nur die Syntax nicht ganz, denn die passt nicht zu C#. Es muss ja nicht 1:1 den C/C++ Intrinsics gleichen. Es könnte eine schönere Variante gewählt werden.

Noch besser würde ich es finden, wenn System.Numerics.Vector<T> um dies erweitert werden würde. Dann kann in OOP ausgedrückt werden was ich will und der JITer übernimmt das wie es geht.
Außerdem könnte so bestehender Vector<T>-Code von diesem Vorschlag profitieren.
Gut es lassen sich nicht alle SSE*, AVX*, etc. mit Vector<T> abbilden, dafür könnten aber neue analoge Typen erstellt werden.

Edit: siehe nächste Antwort von mir.

Hallo Abt,

Performance spielt für die .NET Core Welt eine viel höhere Rolle als für das .NET Framework.

Das würde ich so nicht unterschreiben. Nur beim .net Framework war es eine "Friss od. Stirb" Alternative, bei .net Core ist es offen und "jeder" kann sich der Performance widmen, das in Teilen auch passiert. Beim .net Full hat sich MS oft leider nicht um die Performance gekümmert und oft wäre es relativ einfach gewesen das besser hinzubekommen, wie viele PRs in .net Core zeigen.

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!"

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Wenn Du einen Verbesserungsvorschlag zum Proposal hast: schreibs auf GitHub 😉

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Abt,

klar 😃 Hier ist es zwar nett, aber nicht zielführend.
Ich muss das erst ordentlich selbst einordnen wie es Sinn macht bzw. machen würde.

Edit: ich hab jetzt das Proposal nochmal genauer gelesen und mein Vorschlag ist da eh schon abgedeckt. Das hatte ich beim Überfliegen falsch in Erinnerung gehabt.

  
        // __m128i _mm_add_epi8 (__m128i a,  __m128i b)  
        // __m128i _mm_add_epi16 (__m128i a,  __m128i b)  
        // __m128i _mm_add_epi32 (__m128i a,  __m128i b)  
        // __m128i _mm_add_epi64 (__m128i a,  __m128i b)  
        // __m128 _mm_add_ps (__m128 a,  __m128 b)  
        // __m128d _mm_add_pd (__m128d a,  __m128d b)  
        [Intrinsic]  
        public static Vector128<T> Add<T>(Vector128<T> left,  Vector128<T> right) where T : struct { throw new NotImplementedException(); }  
  

Ist eh eine "schöne" .net-Methode 😃

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!"

148 Beiträge seit 2013
vor 6 Jahren

Genau darauf wollte ich hinaus. Ein Pull Request schließt, in Github, eine Codeänderung ein. Deswegen fand ich es nicht glücklich gewählt. Und das der Vorschlag mächtig ist sehe ich genauso. Habe ja auch nichts Gegenteiliges geschrieben. 😃){grey};

Abt Themenstarter:in
16.806 Beiträge seit 2008
vor 6 Jahren

Wurde offensichtlich auf den 15. August verschoben.