Под капотом — магия реализации RuntimeHelpers.OffsetToStringData
спойлер
add rcx, 12
, немножко наблюдений за JIT в естественной среде обитания и совсем чуть-чуть о неприятных последствиях для GC. Как обычно, кому недостаточно — больше матчасти прячется по ссылкам в самой статье.
И чтоб два раза не вставать, про борьбу с неприятными последствиями для gc — раз, два, три.
и всё в таком духе. S>Сегодня — How does the 'fixed' keyword work от Matt Warren. S>Под капотом — магия реализации RuntimeHelpers.OffsetToStringData S>
спойлер
S>
add rcx, 12
В чем магия? Почему должно быть как-то иначе или сложнее?
VD>А много ли народ вообще fixed и тем более GCHandle в своем коде используют?
interop же. И в особенности с async io. Решается разнообразно, с вводом Memory<T> (массивы поверх любой памяти, от unmanaged и mem-mapped files и до stackalloc) вопрос полуокончательно закроется. Общую повестку на сегодня (неполную) можно глянуть тут.
Здравствуйте, Sinix, Вы писали:
S>interop же. И в особенности с async io. Решается разнообразно, с вводом Memory<T> (массивы поверх любой памяти, от unmanaged и mem-mapped files и до stackalloc) вопрос полуокончательно закроется.
В интерпопе тебе не нужно самому пины ставить. Просто опиши маршилинг и спи спокойно. Плюс там пин делается на короткое время. Так что это никого не напрягает.
S>Общую повестку на сегодня (неполную) можно глянуть тут.
S>И вот тут подробней про проблему.
Это все "хотелки" или у МС серьезные намерения?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В интерпопе тебе не нужно самому пины ставить. Просто опиши маршилинг и спи спокойно. Плюс там пин делается на короткое время. Так что это никого не напрягает.
Напрягает, если код абы как написан и куча async IO — соседние объекты очень быстро в gen2 переезжают. Приходится следить.
VD>Это все "хотелки" или у МС серьезные намерения?
А кто ж их знает. По CLR вообще только начали что-то делать, до этого в основном аврально портировали и чинили поломанное при портировании.
Так-то простор для оптимизаций неимоверный, особенно с native-компиляцией, но по факту даже слухов нет на тему "мы серьёзно занялись перфомансом".
Здравствуйте, Sinix, Вы писали:
S>Напрягает, если код абы как написан и куча async IO — соседние объекты очень быстро в gen2 переезжают. Приходится следить.
Тут оно как? Если код написан абы как, то помочь может только смена команды и полное переписывание.
S>А кто ж их знает. По CLR вообще только начали что-то делать, до этого в основном аврально портировали и чинили поломанное при портировании.
А начали? Дык этому радоваться надо. А то 16 лет пресс-релизов.
S>Так-то простор для оптимизаций неимоверный, особенно с native-компиляцией, но по факту даже слухов нет на тему "мы серьёзно занялись перфомансом".
Так начали или не начали?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Так начали или не начали?
Официально ничего нет, текущая задача — наконец завести полноценный дотнет на основных платформах, неофициально — в тикетах всё-таки попадаются исправления, связанные с производительностью. Как пример — недавнее
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>А полноценный это значит с поддержкой ГУЯ? Или имеется в виду только ядро? S>Ядро.
S>Про гуй ходят два упорных слуха — про попытку сделать portable wpf и второй, не менее упорный, про "в итоге купили xamarin".
S>Что интересно, никаких первоисточников, максимум чего попадалось — видео с упоминанием про WPFLocal.
ОС Mac, Windows, Linux
При создании приложений для Silverlight вы фактически создаете приложение, которое будет одинаково выполняться в Internet Explorer, Firefox и Safari в операционных системах Windows, Mac и Linux. Silverlight в разных платформах и браузерах содержит абсолютно одинаковые функции, обеспечивающие одинаковый результат для всех ваших пользователей.
Корпорация Microsoft сотрудничает с компанией Novell, в целях обеспечения поддержки Silverlight для платформы Linux. Mono – проект по созданию программного обеспечения с открытым исходным кодом, размещенный по адресу http://www.mono-project.com/Moonlight. Он доступен для всех основных дистрибутивов Linux. Moonlight 2.0 поддерживает C# и другие динамические языки и содержит элементы управления, схему размещения и мультимедиа.
Помимо этого можно перенаправлять приложение в графическую подсистему Windows Presentation Foundation (WPF). Это обеспечивает полный доверительный доступ к машине с предоставлением усовершенствованного аппаратного ускорения, полной трехмерной графикой, возможностью записи в файловую систему и поддержкой устройств. Silverlight и WPF используют одни и те же API, XAML, элементы управления и инструменты.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Что интересно, никаких первоисточников, максимум чего попадалось — видео с упоминанием про WPFLocal.
S> Кстати, а что там с silverlight?
А всё с silverlight. RIP в смысле.
Опс, про wpf local забыл дописать. Саму идею забросили, т.к. требовалось поставлять библиотеки для взрослого фреймворка, распространять их через ClickOnce и ещё и ngen-ить их для сохранения совместимости, вот тут подробней. Каким боком из этой затеи появились слухи про кроссплатформенный wpf — науке неизвестно, других первоисточников не попадалось.
Здравствуйте, VladD2, Вы писали:
VD>Так начали или не начали?
Судя по комитам в coreclr, там не так много человек занимаются тюнингом джита. Но подвижки все же есть. Сразу все и не вспомнить. В основном это касается инлайнинга. Как я понял, эту часть чуть ли не полностью переписали. Теперь он более агрессивный с рядом дополнительных эвристик, чтобы не ухудшать характеристики, как например вот здесь: https://github.com/dotnet/coreclr/issues/7569. Также идет работа над тем, чтобы джит мог инлайнить методы с fixed переменными. Возможно включат поддержку cmove для x != null ? 1 : 0, а не использовать генерацию 2 условных переходов как сейчас. Более качественный VALUE NUMBERING и CONSTANT PROPOGATION. Включают поддержку Span на уровне джита, и вот собираются делать что-то со стейт-машиной для асинхронного кода, который генерирует C# для async методов.
В общем, понемногу улучшают качество генерируемого кода, не так как хотелось бы конечно, но все же.
Здравствуйте, rameel, Вы писали:
R>В общем, понемногу улучшают качество генерируемого кода, не так как хотелось бы конечно, но все же.
Хорошо, конечно, что хоть что-то делают. Но действительно не так как хотелось бы. Основные проблемы с производительностью все же проистекают из поддержки ЖЦ. Под нее генерируется куча кода, который далек от "сишного" идеала. Ну, и сам ЖЦ конечно накладывает ограничения.
Дотнету нужны качественный эскейп-анализ с перекладкой локальных объектов на стек или в отдельную кучу. Возможность использования отдельных куч в том числе привязанных к потоку.
Хотя если инлайнинг сделать действительно куртым, то можно инлайнить/переписывать linq-код, что было бы очень полезно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
и всё в таком духе. S>Сегодня — How does the 'fixed' keyword work от Matt Warren. S>Под капотом — магия реализации RuntimeHelpers.OffsetToStringData S>
спойлер
S>
add rcx, 12
S>, немножко наблюдений за JIT в естественной среде обитания и совсем чуть-чуть о неприятных последствиях для GC. Как обычно, кому недостаточно — больше матчасти прячется по ссылкам в самой статье. S>И чтоб два раза не вставать, про борьбу с неприятными последствиями для gc — раз, два, три.
на x64 насколько я понимаю фрагментация памяти долгоживушими pinned "объектами" то не проблема жеж
главное что бы время таких pinned было ограничено таймаутами
Здравствуйте, VladCore, Вы писали:
VC>на x64 насколько я понимаю фрагментация памяти долгоживушими pinned "объектами" то не проблема жеж VC>главное что бы время таких pinned было ограничено таймаутами
Сам по себе pinned проблем не создаёт. Проблема в соседних объектах, которые уезжают в старшие поколения и вызывают mid-life crisis.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, VladCore, Вы писали:
VC>>на x64 насколько я понимаю фрагментация памяти долгоживушими pinned "объектами" то не проблема жеж VC>>главное что бы время таких pinned было ограничено таймаутами
S>Сам по себе pinned проблем не создаёт. Проблема в соседних объектах, которые уезжают в старшие поколения и вызывают mid-life crisis.
если из за них GC процессор жрёт, то асинхронный IO не нужен
но с другой стороны набрать одновременно хотя бы миллион асинхронных IO это надо постараться. Тут вверху правильно написали что долгоживущих pinned мало кто пишут. при всем уважении тема похоже экзотическая и в природе не встречается.
Здравствуйте, VladCore, Вы писали:
VC>если из за них GC процессор жрёт, то асинхронный IO не нужен
Ну, это из серии "если зуб болит — то и фиг с ней, с головой".
Решается всё. Обычно — использованием buffer pool / object pool, в clr vNext обещают [url=https://github.com/dotnet/coreclr/issues/5851]Span<T>/Memory<T>[url] — аналог массивов, но поверх любой памяти, unmanaged — тоже. С поддержкой interop, разумеется. Т.е. проблема с pinned уйдёт окончательно для большинства вещей, как насчёт делегатов — пока не известно.
забыл.
