Wie kann man in der Systemprogrammierung erfolgreich sein, was muss man wissen und verstehen, insbesondere wenn man das dritte Jahrzehnt gearbeitet hat? C # und Leistung - lohnt es sich, alles, was Sie in C # sehen, neu zu schreiben? Was ist die Zukunft für Low-Level-Compilertechnologien, die auf uns warten?
Heute beantwortet
Alexandre Mutel in unserem virtuellen Studio Fragen.
Alexandre Mutel ist Lead Software Architect bei Unity Technologies. Darüber hinaus ist er ein bekannter Open-Source-Entwickler, der an SharpDX-, Markdig-, Zio- und anderen Projekten beteiligt ist, und seit 2014 MVP in der Kategorie Visual Studio und Entwicklungstechnologien.
Alexandre arbeitet an einer Vielzahl von Problemen auf niedriger und hoher Ebene in den Bereichen Echtzeit-Grafik-Rendering, GPGPU, Klangsynthese, effiziente Verwendung und Architektur verwalteter Sprachen, Codegenerierung und Dokumentation.
Wie immer werden Interviews von Evgeny Trifonov (
phillennium ) und Oleg Chirukhin (
olegchir ) von der JUG.ru Group geführt.
Am Ende des Beitrags gibt es eine Überraschung von Dylan Beatty (einem anderen berühmten Spender) - wir selbst haben es nicht erwartet.
E.: Sie haben eine lange Karriere, drei Jahrzehnte - können Sie zunächst kurz darüber sprechen?Alles begann in der Kindheit - ich bekam Amstrad PC 464. Als ich anfing, auf diesem Computer zu programmieren, war ich entweder 11 oder 12, ich erinnere mich nicht genau. Ich beherrschte schnell die BASIC-Programmierung und kaufte Bücher über Spieleentwicklung. Dann schien es sehr interessant zu sein. Ich habe nur sehr wenige Spiele gespielt, bei denen es interessanter war, Code zu entwickeln und zu schreiben. Dann schrieb ich weiter Assembler-Code für Amstrad.
Mit 16 bekam ich einen Amiga 500. Ich traf Leute, die Demos schrieben - es war überhaupt nicht das, was es jetzt ist. Dies ist WebGL, und dies ist eine völlig andere Demoszene. Ich fing an, viele Demos zu schreiben, die ich nicht immer zeigte, aber ich schrieb einfach gern in Assembler. Und so einfach war das.
Dann besuchte er eine technologische Hochschule, wo er Computertechnik studierte. Dies war bereits etwas völlig anderes als Spiele und Assembler. Ich habe es geliebt, Dinge zu lernen, von denen ich vorher nicht einmal wusste, dass sie existieren: Betriebssysteme, UNIX, Arbeiten mit der C-Sprache (vorher habe ich nur BASIC oder Assembler verwendet, weil ich nicht das Geld hatte, um einen C / C ++ - Compiler zu kaufen).
Nach seinem College-Abschluss begann er in der Devisenmarktbranche zu arbeiten. Dies war ein Job für eine französische Firma in New York. Zwei Jahre später kehrte ich zurück und ging zur Bank. Eigentlich wollte ich nicht in einer Bank arbeiten, ich wollte in der Spieleentwicklung arbeiten. Aber als Ergebnis steckt ein neuer Bereich fest, in dem viele Dinge gelernt werden können. Also habe ich 8-9 Jahre dort verbracht, hauptsächlich mit Java und ein bisschen mit C ++. Viele verteilte Server und SQL-Datenbanken, Kopieren von Datenbanken ... Überhaupt nicht das, was ich jetzt mache.
Dann nahm ich einen kreativen Urlaub und machte eine Touristenreise um die Welt: Ich war in Afrika, in Südamerika, ein ganzes Jahr in Asien. Die Reise hat mich verändert und erschüttert. Als ich zurückkam, konnte ich nicht mehr mit Computern arbeiten, im IT-Bereich konnte ich nicht für die Bank arbeiten. Ich kündigte meinen Job und verbrachte 4 Jahre in Kursen für Sozialarbeiter, um mit Kindern, Obdachlosen, Behinderten und älteren Menschen zu arbeiten. Ich habe das drei Jahre lang studiert und es war sehr interessant, weil ich den größten Teil meines Lebens auf dem Gebiet der exakten Wissenschaften gearbeitet habe: Mathematik, Projekte, Abstraktionen. Und dann nahm er plötzlich und zog in ein sehr humanitäres Gebiet. Ich habe sogar versucht, nach dem Training in diesem Bereich zu arbeiten, aber gerade in dieser Zeit hat ein Freund, mit dem ich als Kind Demos gemacht habe, angedeutet, dass wir das wieder tun können.
Ich fing an, meine ganze Freizeit Demos zu üben, und sehr schnell dauerte es mehr als die Arbeit mit Kindern auf der Straße. Das war schlecht Die Leute sagten: „Wir müssen versuchen, Arbeit in der Spieleentwicklung zu finden, warum nicht? Du kannst es schaffen. “ Aber ich dachte, dass dies unmöglich war, weil ich lange nicht mehr mit Computern gearbeitet hatte und es schwierig war, mit meinem Lebenslauf Arbeit in der IT zu finden.
Ich begann an Open Source-Anwendungen zu arbeiten und veröffentlichte einige Projekte, die Unternehmen zu nutzen begannen. Als sich eines dieser Unternehmen mit mir in Verbindung setzte, nutzte es eines der neuesten Projekte namens SharpDX. Ich ging mit meiner Familie nach Japan - weil ich bereits zwei Kinder hatte. Wir haben 5 Jahre in Japan gelebt. Zu diesem Zeitpunkt arbeitete ich daran, eine Game-Engine in C # von Grund auf neu zu erstellen.
Vor ungefähr zwei Jahren kehrte ich nach Frankreich zurück und begann bei Unity zu arbeiten. Dies störte das, was ich zuvor getan hatte, aber sie boten an, an einer sehr komplexen und interessanten Aufgabe zu arbeiten, einem echten Test: einen nativen Compiler zu erstellen, der nativen Code aus IL .NET-Code generiert. Genau das wollte ich schon immer tun, konnte es aber nicht, weil ich dafür nicht bezahlt worden wäre. Und dann gab es eine Chance, eine großartige Gelegenheit. Ich habe 2 Jahre an diesem Projekt gearbeitet.
Ja, es scheint, dass die Geschichte nicht sehr kurz ist.
E.: Nichts, eine solche Karriere ist eine lange Geschichte wert. Aufgrund Ihrer Erfahrung möchte ich Sie dies fragen. Jetzt sagen einige Leute: "Moores Gesetz funktioniert nicht mehr, Computer werden nicht schneller, wir sind alle zum Scheitern verurteilt." Andere antworten: "Komm schon, obwohl sie nicht im gleichen Tempo beschleunigen, gibt es immer noch Wachstum, also gibt es keinen Grund zur Panik." Was ist Ihre Position, da das Thema Produktivität in Ihrer Nähe liegt und Sie gleichzeitig die Branche schon lange verfolgen?Ich halte mich an diesen goldenen Mittelwert.
(lacht) Ich glaube, dass sich viele, wenn nicht die meisten Anwendungen, die wir entwickeln, von Anfang an an die Leistungsanforderungen anpassen, was zu der bestmöglichen Qualität führt.
Sehen Sie vor unseren Augen, was in der IT-Branche passiert ist. Zum Beispiel, als Windows im Laufe der Jahre etwas langsamer wurde - Windows Vista usw. In der Tat wurde natürliche Arbeit geleistet, um die Leistung zu verbessern, da sie jahrelang nicht besonders besorgt war. Als Windows 8 herauskam, war es schon etwas besser. Dann kam Windows 10 heraus und es wurde ein bisschen besser. Infolgedessen haben wir ein System, das im Vergleich zu früher recht gut funktioniert. Für sie war es wirklich wichtig, diese Optimierungen vorzunehmen, denn sobald die Menschen notwendigerweise „über ihre Verhältnisse leben“ und anfangen würden zu sagen: „Oh! Diese Software funktioniert nicht mehr, wir wechseln zu Linux, weil sie schneller und weniger dumm ist. "
Gleiches gilt für die gesamte Software, die wir entwickeln. Und was überrascht: Es gab immer eine Tendenz, mit nativem Code zu arbeiten. Irgendwann entschieden sie sich sogar unter Windows, zu C ++ zurückzukehren. Sie sagten: „C ++ ist eine Lösung, .NET ist sehr langsam, dann Garbage Collector und bla bla bla ... ". Und wieder wurden Muttersprachen relevant.
Gleichzeitig brachte V8 in Chrome dank JIT JavaScript wieder zum Einsatz. JS ist eine Skriptsprache, nicht superschnell, aber manchmal funktioniert sie doppelt so schnell wie C ++. Das war genug für ihn, um zu überleben und um es jetzt für Dinge wie das Schreiben von Code in Visual Studio Code zu verwenden. Aber wenn Sie genau hinschauen, liegt das alles daran, dass dort von Anfang an Leistungsanforderungen gestellt wurden. Selbst in VSCode, obwohl es im Allgemeinen viel JavaScript und Skriptcode gibt, ist alles andere - V8, Rendering Stack, JIT - in einer Sprache geschrieben, die für maximale Leistung ausgelegt ist, dh in C ++. Alles könnte in einer anderen Sprache geschrieben werden, nicht unbedingt in C ++, aber Tatsache ist, dass all diese Software von Anfang an unter Berücksichtigung der Leistung entwickelt wurde.
Ja, wir können weniger effiziente und produktive Sprachen verwenden, aber nur, weil alle zugrunde liegenden Technologien mit dem Ziel entwickelt wurden, eine fantastische
Benutzererfahrung zu erzielen . Zum Beispiel ist Visual Studio Code eine erstaunliche Software, die für Entwickler sehr gut funktioniert und deren Probleme löst. Viele Leute sagen: „Obwohl wir gerne mehr native Code-Editoren verwenden, wechseln wir derzeit zu Visual Studio Code“ - weil sie dies für sehr effektiv halten. Leistung ist überall, aber manchmal sehen wir sie nicht, weil sie bereits in alles eingebettet ist, was wir verwenden.
Wir denken: Es ist in JavaScript geschrieben, weil es schnell genug ist. Aber JavaScript ist so schnell, nur weil Hunderte von Hunderten von Entwicklungsingenieuren jahrelang daran gearbeitet haben, JIT zu optimieren. Jetzt können wir Skriptsprachen auch zum Schreiben sehr komplexer Anwendungen verwenden. Skriptsprachen, die ohne all diese Vorarbeiten viel langsamer gewesen wären. Wir leben in seltsamen Zeiten. Wir haben die Wahl, aber es gibt immer noch diese Performance-Geschichte, die sich für jede Sprache immer wieder wiederholt.
.NET ist also ein typisches Beispiel. In den letzten drei bis vier Jahren wurde dort große Arbeit geleistet. Wenn Sie sich irgendwann ASP.NET Core ansehen, wenn Sie sich die ganze Arbeit mit CoreCLR ansehen ... Leistung ist eine gute Sache, sie kostet Geld und ermöglicht es Ihnen, mehr zu erreichen. Wenn Sie versuchen, strenge Anforderungen zu erfüllen, können Sie versuchen, produktiver zu werden, Strom sparen und am Monatsende etwas Geld sparen - Leistung wirkt sich auf alles aus. Wenn ich Leute sagen höre: "Alles ist in Ordnung, ich entwickle meine Anwendung, sie hat eine durchschnittliche Leistung, sie reicht aus ...", was denken sie? Sie müssen sich etwas Zeit nehmen, um zu überprüfen, ob Sie Ihre Anwendung etwas produktiver gestalten können. Wenn Sie Ressourcen oder Anwendungszeit um mindestens ein Zehntel sparen können, ist das gut.
E.: Es gibt teilweise eine philosophische Frage. Sie denken, Slack ist nicht der beste Ort für technische Lösungen, aber auf Ihrer Website bieten Sie an, RSS der alten Schule zu abonnieren. Denken Sie, dass die neue Ära des Instant Messaging Entwickler weniger produktiv macht?Nein, das glaube ich nicht. Jetzt arbeite ich aus der Ferne. Bei der Arbeit, bei Unity, können wir remote arbeiten, daher benutze ich Slack ständig, um mit Kollegen zu kommunizieren. Dies ist der beste Weg für mich, in Kontakt zu bleiben und produktiv zu bleiben. Die Arbeit nimmt viel Zeit in Anspruch, da Sie die Kanäle usw. überprüfen müssen, aber ich kann Slack vorübergehend ausschalten und mich auf die Arbeit konzentrieren. Während ich in der Firma im offenen Raum arbeitete, hatte ich keine Wahl: Wenn jemand eine Frage stellen möchte, muss man sie sofort beantworten, es ist viel komplizierter.
Twitter und E-Mails werden nicht so oft überprüft. Ein- oder zweimal am Tag lese ich Twitter, es hängt von verschiedenen Faktoren ab: ob ich an Diskussionen teilnehme und was ich diskutiere. Wenn Sie so etwas wie Slack verwenden, können Sie verschiedenen Kanälen im Unternehmen beitreten. Sie können viele Themen verfolgen, denen Sie nicht folgen könnten, wenn Sie alleine arbeiten würden. Wir müssen einen Mittelweg finden: Wir alle sorgen uns um viele Dinge, die im Unternehmen passieren, aber wir müssen selektiv sein, weil Sie nicht an allen Diskussionen gleichzeitig teilnehmen können. Manche Leute können so viele Kanäle lesen, dass ich einfach erstaunt bin über ihre Fähigkeiten, ich selbst bin nicht so. Heute habe ich ungefähr 30 Kanäle gelesen, das ist nicht so viel.
E.: Danke, Zeit für Olegs Fragen!A.: Meine Karriere ähnelt Ihrer: Ich habe bei einer Bank gearbeitet, jetzt in einem ganz anderen Bereich - ich habe Konferenzen organisiert und gleichzeitig versucht ich herauszufinden, wie man Compiler erstellt. Was können Sie denjenigen raten, die versuchen, von einfachen Unternehmens-Webentwicklern auf Systemprogrammierung umzusteigen? Gibt es Tipps für einen solchen Übergang? Ich bin sicher, dass es hier nicht genug von uns gibt, bis genug.Ich bin mir nicht sicher, ob es einen vorbereiteten Weg für einen solchen Übergang gibt. Wenn Sie an solchen Technologien interessiert sind, machen Sie einige gewöhnliche Hausaufgaben. Zu Hause schreiben Sie Parser und Dinge, die mit Compilern zu tun haben. Es ist nicht erforderlich, den gesamten Compiler von Anfang bis Ende bis zur Generierung des Maschinencodes zu schreiben. Sie interessieren sich für das Schreiben der Compiler-Infrastruktur. Das habe ich in den letzten Jahren bei Unity gemacht. Wenn Sie sich für Dinge auf niedriger Ebene begeistern, dann ist dies einer der Orte, an denen Sie verstehen können, wie das alles in der Realität funktioniert. Wie man die Arbeit verbessert, wo es sich lohnt, die Leistung zu verbessern, und wo dies noch nicht getan wurde. Wenn Sie sich Sorgen um die Leistung machen, ist es sehr wichtig zu wissen, worauf die Anwendung am Ende ausgeführt wird.
Performance ist mein Thema, und all dies ist für mich zu einer großartigen Gelegenheit geworden. Ich möchte die Lösung des Problems im Kern, dh auf Compilerebene, angehen. Hier können wir die Produktivität an den Stellen, an denen dies für unsere Benutzer erforderlich ist, um das Zehnfache steigern. Wenn wir Spiele, Anwendungen, Filme oder ähnliches ausführen, kann es manchmal relativ einfach sein, solche Ergebnisse zu erzielen.
Meine Leidenschaft für Low-Level-Dinge und Compiler-Komponenten führte mich zu meinem aktuellen Job. Aber das wollte ich nicht speziell tun. Wenn Sie viel Erfahrung mit verschiedenen Sprachen haben, schreiben Sie manchmal Anwendungen - Sie möchten sogar Ihre eigene Sprache entwickeln. Ich habe damit angefangen, aber aufgehört, weil es zu viel Arbeit ist und ich sehr wenig Freizeit habe. Aber Sie haben ein unbewusstes Verlangen, "zu den Wurzeln" zurückzukehren und selbst etwas zu tun, um alles zu verstehen. Natürlich habe ich verstanden, wie Compiler funktionieren und all das, aber ich habe die Komplexität der Anforderungen nicht verstanden. Komplexe Kompromisse, die beispielsweise im Bereich der Speicherverwaltung zu bewältigen sind. Es ist sehr schwierig zu entscheiden, was gleichzeitig die Produktivität des Anwendungsentwicklers erhöht und effektiv ist. Dieses Problem ist immer noch nicht bis zum Ende gelöst. Rust oder .NET werden dies niemals lösen. Rust ist wunderschön, erstaunlich, aber es ist schwierig, damit zu arbeiten, besonders wenn Sie mit etwas wie JavaScript darauf umsteigen. Es gibt jedoch Beispiele für Python- oder JavaScript-Entwickler, die nach Rust migrieren, obwohl dies etwas überraschend ist.
A.: Sie haben erwähnt, dass Sie in den letzten 10 Jahren in C # programmiert haben. Was ist also gut in C #? Warum nicht zum Beispiel C ++? C ++ scheint eine systemischere Sprache zu sein.Um ehrlich zu sein, ich hasse C ++, ich hasse C, aber ich arbeite mit ihnen. Ich bin der festen Überzeugung, dass sie zu einer Reihe von Fehlern führen, zu einer enormen Ineffizienz der Entwicklung. Viele Leute denken, dass Sie, da Sie in C programmieren, bereits de facto schnellen Code schreiben, damit Ihr Programm leistungsorientiert ist. Das ist nicht wahr. Wenn Sie Haufen von Malloc und all dem formen, wird es sogar im Vergleich zu dem, was in .NET geschrieben ist, langsam sein. Gute C / C ++ - Entwickler sind gezwungen, Tricks wie den
Regionsspeicherzuweiser zu verwenden . Sie müssen sich in einer Reihe von seltsamen Dingen begraben, von denen niemand gehört hat. Obwohl hier Spieleentwickler normalerweise über solche Dinge Bescheid wissen. Zumindest AAA-Entwickler oder Leute, die Spiele in C / C ++ - Frameworks erstellen. Einige der Probleme ergeben sich aus der Komplexität der Sprache selbst. Vorher habe ich überhaupt keine Bücher über C ++ gelesen und erst vor drei oder vier Jahren habe ich angefangen, Bücher nur über C ++ zu lesen, nur um die Sprache zu fühlen. Ich habe darauf programmiert, aber ich hatte keinen systematischen, formalen Ansatz, und ich war beeindruckt von seiner Komplexität, der Anzahl der Dinge, die Sie ruinieren können, wenn Sie nicht alles richtig schreiben.
Noch vor ein paar Monaten gab es einen Fehler in Unity, jemand hat einen Fehler in einem Teil des C ++ - Codes gemacht, es war im Konstruktor, etwas wurde als Wert übergeben, und als Ergebnis haben wir die Adresse von diesem Wert genommen und im Cache gesucht. Tatsächlich haben wir uns auf einen Wert bezogen, der nicht mehr im Speicher war. Und das alles, weil die Zeiger mit Nichtindikatoren verwechselt wurden und derjenige, der dieses Refactoring durchgeführt hat, nicht alle Verwendungsorte überprüft hat. Ein völlig anderer Code, der perfekt funktionierte, funktionierte plötzlich nicht mehr. Es scheint ein kleiner Fehler zu sein, aber es hat alles kaputt gemacht. In der Tat ist dies ein Fehler bei der Arbeit mit dem Gedächtnis. Also ja, wenn ich solche Dinge sehe, bin ich überzeugt, dass wir den Zugriff auf die Arbeit in C und C ++ einschränken und deren Verwendung minimieren müssen. Im .NET-Teil habe ich ihre Verwendung wirklich nur auf plattformspezifische Dinge beschränkt. Aber alles in C # zu schreiben ist ziemlich trostlos. Um auf die API zugreifen zu können, müssen Sie eine Reihe von dlopen ausführen. Sie können beispielsweise versuchen, all dies in einem Wrapper in C zu kapseln und den Zugriff über nur eine Funktion zu organisieren. Ich würde solche Dinge lieber isolieren und in C und C ++ weiterentwickeln. Aber dies ist ein so enges Thema über Interop, und dann bleiben Sie bei einer normalen kontrollierten Sprache, verwenden sie die meiste Zeit und genießen eine schnellere Kompilierung.
Ich hasse die Fehler des C ++ - Compilers und Linkers, ich hasse die Notwendigkeit, mit verschiedenen Plattformen zu arbeiten, all dies ist sehr, sehr schwierig. Sie beginnen mit dem Kompilieren auf MSVC, dann sollten Sie zu Clang und dann zu GCC wechseln. Unter Linux, Mac, Windows, Android, iOS usw. Die Arbeit mit C ++ ist ein Albtraum!
Ich hasse die Trennung zwischen Dateien im Editor, .h-Dateien und cpp. -Dateien. Die Leute sind völlig verwirrt in der Sprache und beginnen, auf Makros zu programmieren. Ich liebe Metaprogrammierung, aber in modernem C ++ können wir einfach Wahnsinn machen. An sich sind diese Dinge erstaunlich, aber eigentlich ist es schon zu viel.
Zusammenfassend: Ja, ich denke, wir können effektive Software in C # entwickeln. Vielleicht nicht so schnell wie in C ++, aber wir können. Dies ist genau das, was wir in Unity versuchen - zum Beispiel machen wir einen Burst-Compiler, um eine bestimmte Teilmenge von C # zu kompilieren, um maximale Leistung zu erzielen, sogar mehr an Orten als in C ++ - aber in C # zu bleiben. Es ist völlig sicher. Für Zeiger müssen Sie unsicher erklären, keine Ausnahmen auslösen und alles explizit ausführen. Und das ist eine bittere Erfahrung. Trotzdem können Sie Code schreiben, der so schnell ist wie in C ++. Ich denke, das ist genau die Richtung, in die sich .NET lohnt und wohin wir gehen sollten.
A.: Wenn wir zum Beispiel über Open Source Code sprechen, haben wir einen Garbage Collector in .NET Core, einer sehr großen und beängstigenden C-Datei. Zwei Megabyte Müll, der höchstwahrscheinlich aus einer Art Lisp entstanden ist (kaum so viele Briefe waren es wert, manuell geschrieben zu werden). Vielleicht ist es sinnvoll, hier in C # alles neu zu schreiben?Ja! Ich chatte mit Leuten, die sowohl bei Microsoft als auch in der Community an JIT arbeiten. Es gibt etwas, an das ich wirklich glaube. Ich glaube, dass es einen Moment gibt, in dem Ihre Sprache reifer und grundlegender wird und Sie sie dann herausfordern und auf Stärke testen müssen. Sie müssen es als Grundlage verwenden können. Beweisen Sie, dass Sie damit sogar etwas sehr Anspruchsvolles an die Leistung schaffen können. Und das ist die Geschichte von Garbage Collector und JIT. Ein sehr, sehr großer Prozentsatz der .NET-Laufzeitsubsysteme, einschließlich JIT und GC, kann in C # ausgeführt werden. Wenn Sie eine Regel festlegen, nach der Sie in C ++ nur Abstraktionen der Basisplattform beschreiben können, wird der größte Teil der Laufzeitplattform unabhängig. Ich würde mich sehr freuen, wenn dies passieren würde. Aber das ist ein großer Job.
Es gibt einen Grund, warum ich diese Idee besonders mag.
Ich habe bereits darüber gesprochen. Das Refactoring und die Verbesserung der Codebasis in C / C ++ ist so kompliziert, dass Sie dieses Refactoring irgendwann beenden. Es tut so weh, dass du es einfach nicht mehr anfasst. Sie müssen einige Dateien von Hand übertragen und ändern, da das Refactoring in der IDE schlecht funktioniert, z. B. weil zu viele Vorlagen vorhanden sind - und so weiter und so fort. Bei der Entwicklung in C # könnten Sie ehrgeiziger in Bezug auf Ihre Wünsche sein. Das Hinzufügen neuer Optimierungen wäre viel schneller und einfacher möglich, einfach weil sich die Kompilierungszeit verkürzt hat. Reduzierte Iterationszeit zum Testen und so weiter. Es ist schön, dass sie beispielsweise in CoreRT versuchen, die Verwendung von C # anstelle von C ++ zu maximieren. Die Situation ändert sich., .NET GC C#. . , , .NET GC, -. GC, , - GC. Java- Jikes RVM — Java. , Golang C, Golang. Golang-, , . , , , . , . LLVM, .NET JIT.
, , .
.: , . — . , AST- . Golang , . , ? ?, , ! , . : . : -, .
: , , , , . , : « ! !». . , .
LLVM, — , . , , , , , . . , , . , . , , , , ? , , , . , - : «, , , - » — , , , .
, . , , , , , , - . , : , , . , , . , , . , . , — .
— . -. , -, API, . . , SharpDX . . , , , . DirectX C++ API, C++. , . , - , . : , . , SharpDX. , PR, . pull request ( ). - . - , SharpDX - . : « ?» ( , ) , . 90- — . , , .
, , , , : , , .
.: — , ? . , , ?, — , SIMD. , , SIMD , . ( LLVM, , ). , , . , , , . - , . , . . - Intel LLVM. , , LLVM. , , . LLVM — , , , .NET. SIMD, CPU — . , , .NET — SIMD- . , , .
: « ». . . LLVM : -, , . , , Roslyn C#, . , , . , , , . SIMD — . GPU, CPU, — . 6, 8, 16, 42 . - , , .
.: Markdown Markdig, ? , Markdown? , ?, Markdown — , . , , Word - . . ? , , . . , RFC — , , , . , , . , ASCII-art. Word, PDF . Word. - — . , . Markdown, , - — , HTML. , . HTML, Markdown . , Github, Markdown- . . — . , Microsoft Markdown, GitHub, PR — , .
Markdown, CommonMark, , Markdown. , CommonMark — . , , . ,
Github CommonMark . — . . Microsoft CommonMark, Markdig. , Markdig , Markdown-, . , , , CommonMark, Markdig. , . Markdig , , , . , Microsoft .
.: , ? ?, . — , . . , . , , , . , . « , , ». , ? , , , , , - . , Google « X» « ». , — . , , , . , , - — , . « , - ?»
, , . . , , . , - . , , , . — , , ? , ? , .
, . . ? ? , , . , … - , . . , , , .
. . ! , . — . , — - . , , , . , , , . , . , . . , - : « !». -, , , . , . .
, , , , , , , - , .
Am kommenden Freitag wird Alexandra auf der DotNext 2018 in Moskau eine Präsentation mit dem Titel „Hinter dem Burst-Compiler Konvertieren von .NET IL in hochoptimierten nativen Code mithilfe von LLVM“ halten . Die Konferenz findet vom 22. bis 23. November in Moskau statt und wird anscheinend die größte DotNext von allen sein. Wir würden Ihnen sagen, was Sie sonst noch von der Konferenz erwarten können, aber es wurde besser von ihrem anderen Sprecher, Dylan Beatty, für uns gemacht - er hat das ganze Lied aufgenommen: