Народ подскажите была ли такая инфа:
— как лучше записывать функцию получения какого-нибудь значения: через проперти get или через простой метод?
понимаю что слегка глупо звучит, просто очень инетересно может проперти компилятором чаще выбираються как инлайны или нет?!
вообще кто-нибудь может просвитить в плане что будет 100% выбрано как инлайн, а что нет...
а то вот смотрю рефлектором код и не вижу никакого инлайне в релиз билде... такое чувство что опять реклама от макрософта... или может инлайн пашет только на компайле в нейтив код?!
Здравствуйте, alku, Вы писали:
A>а то вот смотрю рефлектором код и не вижу никакого инлайне в релиз билде... такое чувство что опять реклама от макрософта... или может инлайн пашет только на компайле в нейтив код?!
Инлайном будет заниматься JIT компилятор (т.е в момент компиляции IL кода в Native код). Решение о том производить inline или нет, обычно, принимается на основе количества инструкций в этом методе. В остальном-же свойство это тот-же метод, только специальным образом декорированный.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, alku, Вы писали: A>вообще кто-нибудь может просвитить в плане что будет 100% выбрано как инлайн, а что нет... A>а то вот смотрю рефлектором код и не вижу никакого инлайне в релиз билде... такое чувство что опять реклама от макрософта... или может инлайн пашет только на компайле в нейтив код?!
Нет разницы — свойства это только языковые расширения, при компиляции в IL попадает только вызов функции accesor`а.
Компилятор вообще ничего не инлайнит (хотя мог-бы). Это дело JIT а ему уже по барабану — он ориентируется только на размер кода функции и на тип объекта у которого вызывается метод.
Здравствуйте, TK, Вы писали:
TK>Здравствуйте, alku, Вы писали:
A>>а то вот смотрю рефлектором код и не вижу никакого инлайне в релиз билде... такое чувство что опять реклама от макрософта... или может инлайн пашет только на компайле в нейтив код?!
TK>Инлайном будет заниматься JIT компилятор (т.е в момент компиляции IL кода в Native код). Решение о том производить inline или нет, обычно, принимается на основе количества инструкций в этом методе. В остальном-же свойство это тот-же метод, только специальным образом декорированный.
вообще-то старанно эту работу на себя мог взять и CSC компайлер... а в момент компиляции IL кода в Native код было бы намного проще отрабатывать в лоб без дополнительных оптимизаций... процес оптимизации может быть и не очень бытсрым — следовательно это аля искуственное затягивание старта?! надеюсь что в следуйщей версии поправят
Здравствуйте, alku, Вы писали:
A>вообще-то старанно эту работу на себя мог взять и CSC компайлер... а в момент компиляции IL кода в Native код было бы намного проще отрабатывать в лоб без дополнительных оптимизаций... процес оптимизации может быть и не очень бытсрым — следовательно это аля искуственное затягивание старта?! надеюсь что в следуйщей версии поправят
Понятно, что пока все классы находятся в одной сборки — можно инлайнить все как угодно. Но, стоит разнести их на несколько сборок, то все — приплыли, об оптимизации в csc.exe можно забыть. т.е. от оптимизации на этапе jit все равно никуда не уйти. Хотя, если очень хочется пооптимизировать — есть mc++ который, может генерировать оптимизированный код.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, alku, Вы писали:
A>вообще-то старанно эту работу на себя мог взять и CSC компайлер...
Ты забываешь одну из главных фич дотнета — многоязыковость. Соотв. вместо единственной реализации в JIT пришлось бы отдельно реализовывать во всех компиляторах. Наконец пришлось бы явно задавать стратегию оптимизации при компиляции, ведь например в CF инлайнинг нужно применять куда как реже. Поэтому компиляторы в дотнете производят минимум оптимизаций.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>вообще-то старанно эту работу на себя мог взять и CSC компайлер...
AVK>Ты забываешь одну из главных фич дотнета — многоязыковость. Соотв. вместо единственной реализации в JIT пришлось бы отдельно реализовывать во всех компиляторах. Наконец пришлось бы явно задавать стратегию оптимизации при компиляции, ведь например в CF инлайнинг нужно применять куда как реже. Поэтому компиляторы в дотнете производят минимум оптимизаций.
много-языковость не обязывает писать "плохие" "пре-компайлеры"....
тем более что мона было бы только отконвертить в IL, а потом пройтись общим для всех оптимизатором...
короче область оптимизации для NET осталась не тронутой... вот блин... теперь ясно почему обещают в Longhorn поднятие производительности NET приложений
очень захотелось пойти и посмотреть сорсы Quake.NET — у него же перформанс критичным должен быть?!. может они чего-то знают чего я не вижу... может мета-атрибуты какие-то выставлять надо?!
Здравствуйте, alku, Вы писали:
A>много-языковость не обязывает писать "плохие" "пре-компайлеры"....
А кто говорил что обязывает? Просто оптимизация на этапе компиляции требует задания условий заранее. Я же пример приводил — увлечение инлайнингом для CF может в итоге привести к тормозам, а не ускорению.
A>короче область оптимизации для NET осталась не тронутой...
A>короче область оптимизации для NET осталась не тронутой...
Ещё бы . На сколько я знаю JIT не проводит планировку потока команд в зависимости от текущей архитектуры в целях увеличения скорости компиляции. А это может выжать процентов 20 и больши производительности в плотных вычислениях. Интересно, а как они выкрутятся в Джите под Itanium? Там-же без планировки команд вообще стоп-кран
Ещё естественно не делается векторизация циклов и некоторые другие дорогостоящие оптимизации.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, alku, Вы писали:
A>>много-языковость не обязывает писать "плохие" "пре-компайлеры"....
AVK>А кто говорил что обязывает? Просто оптимизация на этапе компиляции требует задания условий заранее. Я же пример приводил — увлечение инлайнингом для CF может в итоге привести к тормозам, а не ускорению.
A>>короче область оптимизации для NET осталась не тронутой...
AVK>Как это не тронутой? А JIT на что?
это рантайм и критично по скорости...
следовательно на него много не навешаеш оптимизаций — иначе тормозить начнет...
+ оптимизации которые будет делать JIT будут не очень качественными и будут проигрывать оптимизации с++ компайлера... думаю порядками меряться разницы в скорости будут.
ждем-с следуйщего витка развития NET компайлеров...
Здравствуйте, alku, Вы писали:
A>это рантайм и критично по скорости...
Не обязательно. ngen никто не отменял. Да и потом — это не чистый рантайм, поскольку JIT работает только поначалу. Отсюда не столько замедление работы в целом, сколько задержка запуска. Для серверного софта некритично, для настольного не фонтан конечно, но и не смертельно.
A>+ оптимизации которые будет делать JIT будут не очень качественными и будут проигрывать оптимизации с++ компайлера...
Опять же смотря какие. Джиту к примеру доступна оптимизация под конкретное окружение, т.е например на КПК будет одна оптимизация, на х86 другая, на х86-64 третья, на ia64 четвертая.
A> думаю порядками меряться разницы в скорости будут.
Практика показывает что ни о каких порядках речи не идет — в худшем случае процентов 20.
A>ждем-с следуйщего витка развития NET компайлеров...
A>много-языковость не обязывает писать "плохие" "пре-компайлеры".... A>тем более что мона было бы только отконвертить в IL, а потом пройтись общим для всех оптимизатором...
Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
A>короче область оптимизации для NET осталась не тронутой...
Тронутой, просто ты не там где нужно искал. Оптимизировать IL в общем-то не очень то важно. Понаставь там NOP-ы через одну инструкцию, да везде только дальние переходы — оно всё равно никак не отразится в машкоде. Идеология другая.
A>вот блин... теперь ясно почему обещают в Longhorn поднятие производительности NET приложений
JIT — такая область, где оптимизировать можно многое. Особенно с поддержкой этого дела на уровне ОС.
Здравствуйте, mihailik, Вы писали:
A>>много-языковость не обязывает писать "плохие" "пре-компайлеры".... A>>тем более что мона было бы только отконвертить в IL, а потом пройтись общим для всех оптимизатором...
M>Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
теоретически только... никто между сборками глобальных оптимизаций делать не будет...
секурити и другие прибамбасы начнут сильно логику путать... потому никто это делать не будет.
A>>короче область оптимизации для NET осталась не тронутой...
M>Тронутой, просто ты не там где нужно искал. Оптимизировать IL в общем-то не очень то важно. Понаставь там NOP-ы через одну инструкцию, да везде только дальние переходы — оно всё равно никак не отразится в машкоде. Идеология другая.
A>>вот блин... теперь ясно почему обещают в Longhorn поднятие производительности NET приложений
M>JIT — такая область, где оптимизировать можно многое. Особенно с поддержкой этого дела на уровне ОС.
а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее...
что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
Здравствуйте, mihailik, Вы писали:
A>>много-языковость не обязывает писать "плохие" "пре-компайлеры".... A>>тем более что мона было бы только отконвертить в IL, а потом пройтись общим для всех оптимизатором...
M>Как уже сказал AVK, такие оптимизации работают только внутри одной сборки. А на уровне JIT можно производить намного более крутые оптимизации, так как информации куда как больше.
К сожалению не всегда. Те же дженерики, например компараторы могут (и должны) инлайнится, тогда их скорость достигнет шаблонных, пусть и с ограничениями.
А вот раскрыть проинлайнить методы возможно и в IL. Хотя не особо то это и нужно, но если писать драйвера то ....
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alku, Вы писали:
A>вообще-то старанно эту работу на себя мог взять и CSC компайлер... а в момент компиляции IL кода в Native код было бы намного проще отрабатывать в лоб без дополнительных оптимизаций... процес оптимизации может быть и не очень бытсрым — следовательно это аля искуственное затягивание старта?! надеюсь что в следуйщей версии поправят
МС++ так и делает. Просто выигрыш от этого мизерный. А затраты на разработку оптимизатора очень высокие.
Да и не все оптимизации можно сделать в компайлтайме. Например джит может инлайнить метод из библиотеки. Ни один компилятор это не умеет (если конечто сама библиотека не содержит промежуточный код).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Просто не все сразу.
A>короче область оптимизации для NET осталась не тронутой... вот блин... теперь ясно почему обещают в Longhorn поднятие производительности NET приложений
Они в каждом новом фрэймворке это делают. Но за это время и обычные компиляторы уровень оптимизации поднимают.
A>очень захотелось пойти и посмотреть сорсы Quake.NET — у него же перформанс критичным должен быть?!. может они чего-то знают чего я не вижу... может мета-атрибуты какие-то выставлять надо?!
Обычный С-шный код. Ссылка есть на МС и даже в этом форуме. Поиск тебе поможет.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>теоретически только... никто между сборками глобальных оптимизаций делать не будет...
Уже делают. Джиту нет разницы другая это сборка или нет. Именно по этому в дотнете нет разницы где лежит используемый код, а для С++ очень даже важно.
A>секурити и другие прибамбасы начнут сильно логику путать... потому никто это делать не будет.
Нет. Все вопросы защиты отрабатываются на статическом анализе. А оптимизации не имют права изменять семантику кода.
A>а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее...
А тогда что вопросы задешь? Как грится... хавай как есть.
A>что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
Ну, я тебе тут рядом ссылку дал... Погляди там есть презентаха. В ней как раз рассказывается об оптимизации при инсталляции. Вот там можно и крутые оптимизации применить. Иначе тормоза будут из-за самого оптимизатора.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, alku, Вы писали:
A>+ оптимизации которые будет делать JIT будут не очень качественными и будут проигрывать оптимизации с++ компайлера...
А они и проигрывают.
A>думаю порядками меряться разницы в скорости будут.
Процентами. Причем иногда даже долями. Намного больше тормозов из-за того, что чаще приходится использовать виртуальные вызовы, больше данных в хипе размещать и т.п.
A>ждем-с следуйщего витка развития NET компайлеров...
Здравствуйте, AndrewVK, Вы писали:
AVK>Практика показывает что ни о каких порядках речи не идет — в худшем случае процентов 20.
Пример из жизни. Распаковщик 7z, написанный на c#, работает на 30-50% медленне, чем откомпилированный с++. Причём я изучал самые работающие c# функции в профайлере, жирок срезать никак не получается. .
Здравствуйте, alku, Вы писали: M>>JIT — такая область, где оптимизировать можно многое. Особенно с поддержкой этого дела на уровне ОС.
A>а смысл?!. все это будет из разряда отмазок — поставьте себе памяти побольше и процессор помощнее... A>что-то конечно поправят, но в основном массового пересмотра и доработки не будет. им надо технологию вперед двигать, а не вылизывать код... потому забъют они на оптимизации крутые...
Я программист, но хочу выразит несогласие как пользователь: пользователи очень не любят, когда программисты ленятся писать нормально работающий не тормозящий продукт и вместо этого говорят пользователям: "проапгрейдетесь-ка лучше за свои деньги". Я против такого подхода.
Процентами. Причем иногда даже долями. Намного больше тормозов из-за того, что чаще приходится использовать виртуальные вызовы, больше данных в хипе размещать и т.п.