Цитата:
Сообщение от
otkudao
1. Совместное использование нескольких языков программирования (те, что managed) насколько реально востребовано и используется?
Если Вы будете вести расчет какого-нибудь атомного реактора, и найдется "managed" язык более выразительный или удобный для ведения таких расчетов, чем C#, то почему бы этим языком не пользоваться. Тогда как GUI писать на C#.
Цитата:
Сообщение от
otkudao
2. Везде в тексте указания, что нужно активно плыть в сторону оптимизации, сам компилятор мышей не ловит. Вплоть до того, что рекомендуется строить леса перегруженных методов.
В связи с этим вопрос: насколько удобство использования нескольких языков перевешивает тормознутость разработки и исполнения?
Про тормознутость разработки не понял, что имеется ввиду. А про исполнение...Что-то Вы не то читаете, начните с Рихтера которого Вам тут уже неоднократно советовали. Вот что он пишет про "тормознутость" :
Цитата:
Разработчики с опытом программирования на неуправляемых C/C++ наверняка
заинтересуются, как это сказывается на производительности. В конце концов,
неуправляемый код компилируется для конкретного процессора и при вызове
просто исполняется. В управляемой же среде компиляция производится в два этапа.
Сначала компилятор проходит исходный код и переводит его в IL. Но для испол
нения сам IL код нужно перевести в машинные команды в период выполнения,
что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я до
статочно скептически рассматривал все эти дополнительные издержки. Вторая
стадия компиляции, имеющая место в период выполнения, снижает скорость и
требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую работу, чтобы свести эти издержки к минимуму
Трудно поверить, но многие (включая меня) считают, что управляемые при
ложения могут работать производительнее неуправляемых, и тому есть масса
причин. Взять хотя бы тот факт, что превращая IL код в команды процессора в
период выполнения, JIT компилятор располагает более полными сведениями о
среде выполнения, чем компилятор неуправляемого кода. Вот особенности, ко
торые позволяют управляемому коду «опередить» неуправляемый.
JIT компилятор может обнаружить факт выполнения приложения на Pentium 4
и сгенерировать машинный код, полностью использующий все преимущества
особых команд этого процессора. Неуправляемые приложения обычно ком
пилируют в расчете на среднестатистический процессор, избегая специ
фических команд, которые заметно повышают производительность приложе
ния на новейших процессорах.
JIT компилятор может обнаружить, что определенное выражение на конкрет
ной машине всегда равно false. Например, посмотрим на метод с таким кодом:
if (numberOfCPUs > 1) {
...
}
Здесь numberOfCPUs — число процессоров. Код указывает JIT компилято
ру, что для машины с одним процессором не нужно генерировать никаких
машинных команд. В этом случае машинный код оптимизирован для конкрет
ной машины: он короче и выполняется быстрее.
CLR может проанализировать выполнение кода и перекомпилировать IL код в
команды процессора во время выполнения приложения. Перекомпилирован
ный код может реорганизовываться с учетом обнаруженных некорректных
прогнозов ветвления.
Это лишь малая часть аргументов в пользу того, что управляемый код будуще
го будет исполняться лучше сегодняшнего неуправляемого. Как я сказал, произ
водительность и сейчас очень неплохая для большинства приложений, а со вре
менем ситуация только улучшится.
Если ваши эксперименты покажут, что JIT компилятор CLR не обеспечивает
нужную производительность, рекомендую воспользоваться утилитой NGen.exe,
поставляемой с .NET Framework SDK. NGen.exe компилирует весь IL код выбран
ной сборки в машинный и сохраняет его в дисковом файле. При загрузке сборки
в период выполнения среда CLR автоматически проверяет наличие предварительно
скомпилированной версии сборки и, если она есть, загружает скомпилированный
код, так что компиляция в период выполнения не производится. Заметьте, что
NGen.exe не ориентируется на конкретную среду выполнения и генерирует код
для среднестатистической машины; по этой причине созданный утилитой код не
столь оптимизирован, как произведенный JIT компилятором.