Тема рантайма платформы .NET освещена весьма подробно. Однако работа самого JIT, результирующий код и взаимодействие со средой исполнения – не очень.
Ну что ж, исправим это!
Узнаем причины отсутствия наследования у структур, природу unbound delegates.
А еще… вызов любых методов у любых объектов без reflection.
Читать полностью »
Добрый день, уважаемые разработчики (просто не знал, с чего начать пост). Предлагаю перед тем как начнется трудовая неделя немного подразмять мозги (совсем немного) и построить свой Small Objects Heap для .Net. Вернее даже не Small Objects Heap, а Custom Objects Heap. Это — один из примеров прошлогодней конференции CLRium, новая итерация которой состоится 
в Апреле — в Москве и в Мае — в Питере
Как все мы знаем, в .Net существует две группы куч: для больших и малых объектов. Как выяснить, во сколько нам обойдется объект можно при помощи кода из этой статьи (он нам пригодится): 
Ручное клонирование потока, а получить указатель на объект и по указателю получить сам объект можно научиться, прочтя эту статью: 
Получение указателя на объект .Net. Также нам понадобится статья корейского (южно-) программиста по перенаправлению указателя на скомпилированную часть метода на другой метод: 실행 시에 메서드 가로채기 — CLR Injection: Runtime Method Replacer 개선
Так что давайте поэкспериментируем и напишем библиотеку, которая позволит:
Привет!
Этот небольшой пост родился после того, как я решил узнать, как можно запускать скрипты Lua совместно с игрой на C# (либо на другом .NET-языке). с использованием библиотеки LuaInterface. Я был впечатлен легкостью этого интерфейса по сравнению с lua.h на C++
C# на приличном уровне, иметь понятие об основах программирования, а также о подключении ссылок в проекте на Visual Studio
С выходом Windows 8 разработчикам стала доступна новая библиотека классов — Windows Runtime. Компоненты WinRT могут использоваться в приложениях Windows Store и настольных приложениях; в неуправляемом коде C/C++, в JavaScript, а также в C# и Visual Basic.
На внутреннем уровне компоненты WinRT представляют собой компоненты COM (Component Object Model), для описания API которых теперь используются метаданные. Эти метаданные хранятся в файлах с расширением *.winmd и представляют собой обновленную версию метаданных .NET, которые кодируются в соответствие с правилами раздела №2 (Metadata Definition and Semantics) стандарта ECMA-335. Поскольку обычные сборки .NET Framework кодируются с помощью этого же стандарта, это говорит о том, что вы можете использовать знакомые средства (такие как ildasm.exe, Object Browser) для просмотра содержимого этих файлов.
По большей части, просмотр WinMD файла с помощью утилиты ildasm.exe очень похож на просмотр стандартной управляемой сборки. Есть несколько различий, которые могут быть видны — в первую очередь то, что WinMD файлы, в общем, не содержат никаких Intermediate Language (IL) инструкций. Вместо этого, эти файлы описывают API, предоставляемые Windows Runtime. Реализация этих интерфейсов может быть полностью отделена от их определения, и по сути, может быть записана в машинном коде. Тем не менее, для разработчиков управляемых приложений, детали реализации WinRT API не имеют значения, потому что управляемый код должен видеть только определения API, которые он вызывает. За кулисами, Common Language Runtime (CLR) и операционная система Windows соединяют для вас определения API и их реализации.
Читать полностью »
Привет! Я хотел бы рассказать о новой криптовалюте Copperlark — это пиринговая электронная платежная система. Cоздателей вдохновил, конечно, Bitcoin, но они поставили амбициозную цель сделать сервис более простым в использовании. Монета системы — Lark, сокращенно CLR. Основным элементом является программа-клиент с открытым кодом, позволяющая управлять кошельком и добывать виртуальную валюту. Компьютеры и мобильные устройства, использующие Copperlark, объединяются с помощью защищенного сетевого протокола в устойчивую одноранговую p2p-сеть, позволяющую им обмениваться информацией.
За пол года существования Copperlark превратился из обычного форка Bitcoin в единственную на постсоветстком пространстве криптовалюту со всей необходимой для работы и развития инфраструктурой. Курс вырос с 0.5 рубля до 11 рублей. Рекорд курса – 21 рубль. Ежедневно на бирже продается около 70 000 CLR. По поводу инфраструктуры, проекты системы:
Copperlark.com – официальный сайт
upbit.org — биржа для торгов CLR/BTC/LTC/USD/RUB/EUR
blockchain.copperlark.com – эксплорер
Copperlark.com/forum/ — форум
Читать полностью »
Мир движется к 64-битным вычислениям, несмотря на то, что в результате программы не всегда работают быстрее или производительнее по сравнению с 32-битными. Многие 32-битные программы, по разным причинам, могут работать быстрее 64-битных. Одним из таких примеров является 64-битный JIT-компилятор .NET-фреймворка. Он выполняет большую работу для того, чтобы ваша программа работала очень быстро, но сам он, увы, не настолько быстр, как хотелось бы. Это мы и собираемся исправить. Представляем x64 JIT-компилятор нового поколения, который способен компилировать 64-битный .NET код в 2 раза быстрее.
Читать полностью »
Мы рады сообщить, что только что поступил из типографии тираж нового издания книги «CLR via C» Джеффри Рихтера!
Четвертое издание книги охватывает версии .NET Framework 4.5, а также Visual Studio 2012 и C# 5.0.
Нет, это просто подмножество JavaScript. Программа на asm.js одинаково поведёт себя и в существующих движках JavaScript, и в движке с предварительной (ahead-of-time, AOT) компиляцией, способном распознавать и оптимизировать asm.js; различаться будет её скорость, разумеется!
Сейчас ещё рано утверждать. Однако наши предварительные измерения производительности программ, скомпилированных из Си в asm.js, показывают не более чем двукратное замедление по сравнению с компилированными в машинный код посредством clang. Мы опубликуем дальнейшие измерения, когда насобираем их.
Мозилла работает над первой реализацией оптимизирующего компилятора asm.js для SpiderMonkey. В вики Фонда Мозиллы также опубликован план разработки дальнейших выпусков и оптимизаций. Если авторы других движков JavaScript опубликуют собственные планы реализации компиляторов asm.js, мы их здесь упомянем.
Для компиляторов наподобие Emscripten или Mandreel синтаксис байткодового языка попросту не особенно значим. Притом большинство байткодов и вообще машинных языков имеют двоичный формат, не читаемый людьми. Однако мы можем создать на уровне asm.js более человеко-читаемый синтаксис, который будет и удобным в дизассемблировании, и пригодным для чтения и записи людьми.
Предварительная (ahead-of-time, AOT) компиляция asm.js может генерировать код, выполнение которого весьма предсказуемо, потому что валидный код asm.js ограничен крайне небольшим подмножеством JavaScript, состоящим только из строго типизированных целых чисел, чисел с плавающей точкою, арифметических операций, вызовов функций и обращения к куче.
Принципиальным достоинством asm.js по сравнению с новыми технологиями вроде NaCl и PNaCl является то, что asm.js работает сегодня: существующие движки JavaScript ужé неплохо оптимизируют код, написанный в таком стиле. Что означает, что разработчики могут выпускать код на asm.js сегодня, а со временем его работа будет ускоряться. Другою важною пользою является заметно бóльшая простота реализации, для которой потребуется совсем немного дополнительных механизмов поверх существующих движков JavaScript — и не понадобится слой совместимости API.
Изменение .NET метода MSIL кода во время выполнения приложения – это очень круто. Это настолько круто, что можно перехватывать вызовы функций (hooking), сделать защиту своего ПО и другие удивительные вещи. Именно поэтому мне уже давно хотелось это осуществить, но была одна проблема – MSIL код компилируется в машинный код с помощью JIT перед тем, как мы сможем что-либо с этим кодом сделать. А так как .NET CLR не документирована и изменяется от версии к версии, то мы и будем искать стабильный и надёжный путь, независимый от точного расположения адресов в памяти.
Читать полностью »
Alexandre Mutel — создатель самой быстрой и самой полной .NET обертки для DirectX, единственной, поддерживающей Windows 8 Metro, работает R&D разработчиком игрового движка в SiliconStudio, участник французской демо-группы FRequency.
В последнее время мы слышим много шума о возвращении идеи «Going Native» после эры управляемых языков, таких как Java и .NET. В прошлом году, когда WinRT был только представлен, начали появляться недалекие комментарии, которые утверждали, что что .NET умер, а С++ возвращается во всей своей красе — истинный и единственно верный способ для разработки приложений, в то время, как JIT начинает все чаще появляться в мире скриптовых языков (JavaScript активнее всех использует преимущества JIT). Любой код так или иначе станет нативным перед выполнением — разница лишь в длине пути, по которому он пройдет, чтобы стать нативным, и насколько оптимизированным он будет. Значение слова «native» немного изменилось и стало неразрывно связано со словом «производительность». Даже будучи сильным пропагандистом управляемого языка [C#], его производительность на самом деле ниже хорошо написанного С++ приложения. Получается, мы должны просто принять этот факт и вернуться к C++, когда такие штуки как WinRT будут для нас основой межязыкового взаимодействия? По правде говоря, я бы хотел, чтобы .NET умер, и этот пост о том, почему и зачем.
Читать полностью »
