Comments 15
циклы — вообще слабое место элементарных логических преобразований. Тут каждый такт на счету
Мне в .NET иногда не хватает возможности инлайнить методы, как это возможно в С++. Было бы неплохо дать CLR указание на встраивание метода через атрибут. Пример:
[Inline(Priority.Force)]
public int Sum(int a, int b) { return a + b; }
Priority.Force — указание на приоритет встраивания. Три приоритета: IfCan — встраивать, если это возможно, Normal — пусть CLR решает втраивать или нет, Force — обязтельное встраивание, если нет возможности, то выкидывать исключение.
[Inline(Priority.Force)]
public int Sum(int a, int b) { return a + b; }
Priority.Force — указание на приоритет встраивания. Три приоритета: IfCan — встраивать, если это возможно, Normal — пусть CLR решает втраивать или нет, Force — обязтельное встраивание, если нет возможности, то выкидывать исключение.
Если верить тому, что я видел где-то в блогах MSDN, то CLR вообще не умеет инлайнить функции у которых есть аргументы передаваемые по значению (в том числе int).
И еще мои наблюдения за результатами работы JIT показали что оно на данном этапе эволюции разворачивает только статические методы классов. Если с методами классов еще понятно — нужны всякие проверки, то со структурами это выглядит странно.
И еще мои наблюдения за результатами работы JIT показали что оно на данном этапе эволюции разворачивает только статические методы классов. Если с методами классов еще понятно — нужны всякие проверки, то со структурами это выглядит странно.
В Воо, например, можно определять макросы что по сути то же самое что инлайнд код.
Все совершенно естественно.
Но, если решили заняться оптимизацией сортировки — копайте в сторону postman sort.
Но, если решили заняться оптимизацией сортировки — копайте в сторону postman sort.
1. В первом случае проверки на null удаляет JIT поскольку int таковым быть не может.
2. Не совсем понял насчет девиртуализатора, но callvirt генерируется шарповским компилятором всегда, и главная причина — проверка чтоб инстанс не был null (кстати в С++ как правило можно запросто вызывать методы для NULL указателя если они не используют данные инстанса)
3. В CIL информация о типах то есть, только инструкция записи в массив, как оказалось, одна на все ссылочные типы и принимает Object :)
4. Вообще-то писать на C#/.Net нагруженный вычислениями код слегка не логично — не для этого он предназначен. Но если приходится, то как правило все средства хороши, и тут указаны только наименее хардкорные оптимизации :)
2. Не совсем понял насчет девиртуализатора, но callvirt генерируется шарповским компилятором всегда, и главная причина — проверка чтоб инстанс не был null (кстати в С++ как правило можно запросто вызывать методы для NULL указателя если они не используют данные инстанса)
3. В CIL информация о типах то есть, только инструкция записи в массив, как оказалось, одна на все ссылочные типы и принимает Object :)
4. Вообще-то писать на C#/.Net нагруженный вычислениями код слегка не логично — не для этого он предназначен. Но если приходится, то как правило все средства хороши, и тут указаны только наименее хардкорные оптимизации :)
1. да, уверен, проверял, убиралось. Кстати даже у Рихтера написано что все null-проверки удаляются если в генерик приходит value тип )
3. Вариант с протаскиванием типа навеян STL из C++, там это сделано для обеспечения компилятору доступа к информации о типах и последующего разворачивания inline-методов. Как по мне — чем раньше появится доступ к информации, тем проще ее использовать. Насчет хака — да, в идеологии нынешней версии фреймворка — это хак, но ведь всякое может еще случится :)
4. Ну я вообще изначально С-шиник, мне не привыкать ко всяким ужасам. Да и вряд-ли есть смысл писать код требующий такие оптимизации на шарпе — проще и логичней сделать специализированную либу или сервер для ресурсоемких частей :)
3. Вариант с протаскиванием типа навеян STL из C++, там это сделано для обеспечения компилятору доступа к информации о типах и последующего разворачивания inline-методов. Как по мне — чем раньше появится доступ к информации, тем проще ее использовать. Насчет хака — да, в идеологии нынешней версии фреймворка — это хак, но ведь всякое может еще случится :)
4. Ну я вообще изначально С-шиник, мне не привыкать ко всяким ужасам. Да и вряд-ли есть смысл писать код требующий такие оптимизации на шарпе — проще и логичней сделать специализированную либу или сервер для ресурсоемких частей :)
Кстати, пример с девиртуализацией/профайлингом уровня JIT не совсем корректен — у нас есть два случая:
— передаем интерфейс, полчаем один метод сортировки на все случиа компарера и выбираем реализацию сравнения через механизм виртуальных вызовом
— передаем тип в параметры генерика, получаем по одной копии сортировки на каждый вариант компарера, зато избегаем виртуальных вызовов.
Так сказать «закон сохранения бяки» :) Или тип в генериках, или виртуальные вызовы. А разрешать копилятору самому выносить аргументы-интерфейсы в параметры генериков особо смысла нету — всегда хочется иметь выбор :)
— передаем интерфейс, полчаем один метод сортировки на все случиа компарера и выбираем реализацию сравнения через механизм виртуальных вызовом
— передаем тип в параметры генерика, получаем по одной копии сортировки на каждый вариант компарера, зато избегаем виртуальных вызовов.
Так сказать «закон сохранения бяки» :) Или тип в генериках, или виртуальные вызовы. А разрешать копилятору самому выносить аргументы-интерфейсы в параметры генериков особо смысла нету — всегда хочется иметь выбор :)
Спасибо, интересно было почитать.
Мое мнение — с хаками надо быть осторожнее… варианта я вижу всего 3:
1. Супер оптимизация. Код жутко оптимизирован на производительность, но при этом не расширяем, плохо читается и так далее…
2. Другая крайность — излишнее увлечение рефакторингом, при этом получается очень много лишних вызовов, длинные цепочки делегирования и много другое…
3. Разумный баланс, к которому надо стремиться )
Поэтому, я думаю, сильно увлекаться хаками не стоит, но знать о них, конечно, надо!
Мое мнение — с хаками надо быть осторожнее… варианта я вижу всего 3:
1. Супер оптимизация. Код жутко оптимизирован на производительность, но при этом не расширяем, плохо читается и так далее…
2. Другая крайность — излишнее увлечение рефакторингом, при этом получается очень много лишних вызовов, длинные цепочки делегирования и много другое…
3. Разумный баланс, к которому надо стремиться )
Поэтому, я думаю, сильно увлекаться хаками не стоит, но знать о них, конечно, надо!
Sign up to leave a comment.
Цена вызовов