В языках с норм jit'ом скорость выше, чем у компилируемых языков.

RomasAlmighty любой jit наголову быстрее любых двоичных компиляторов. Разве что JVM тормознутое Г, но это проблема самого языка. В языках с норм jit'ом скорость выше, чем у компилируемых языков.

jit наголову быстрее любых двоичных компиляторов

JVM тормознутое Г

скорость выполнения - не намного, скорость разработки - быстрее, если всё есть во фреймворке, память - пысэц сколько нужно

А то что,
Цитата:
JVM тормознутое Г
- так вот она, правда жизни. А не реклама

Полезно также знать, что JITкомпилятор CLR оптимизирует машинный код
аналогично компилятору неуправляемого кода C++. И опять же: создание опти
мизированного кода занимает больше времени, но производительность его бу
дет гораздо выше, чем неоптимизированного.
Примечание Есть два параметра компилятора C#, влияющих на опти
мизацию кода — /optimize и /debug. В приведенной ниже таблице пока
зано их влияние на качество ILкода, созданного компилятором C#, и ма
шинного кода, сгенерированного JITкомпилятором.
Разработчики с опытом программирования на неуправляемых C/C++ наверняка
заинтересуются, как это сказывается на производительности. В конце концов,
неуправляемый код компилируется для конкретного процессора и при вызове
просто исполняется. В управляемой же среде компиляция производится в два этапа.
Сначала компилятор проходит исходный код и переводит его в IL. Но для испол
нения сам ILкод нужно перевести в машинные команды в период выполнения,
что требует дополнительной памяти и процессорного времени.
Поверьте: я сам из тех, кто программирует на C/C++, и, переходя на CLR, я до
статочно скептически рассматривал все эти дополнительные издержки. Вторая
стадия компиляции, имеющая место в период выполнения, снижает скорость и
требует дополнительной динамической памяти — с этим не поспоришь. Однако
Microsoft проделала большую работу, чтобы свести эти издержки к минимуму.
Примечание При создании неоптимизированного ILкода компилятор
C# создает в коде команды NOP (nooperation — «пустая команда») — они
нужны для поддержки функции «редактирование и продолжение выпол
нения» в процессе отладки. Также команды NOP облегчают отладку кода
за счет расстановки точек останова на управляющих командах, таких как
for, while, do, if, else, а также блоках try, catch и finally. Предполагают, что
это дополнительная возможность платформы, но лично меня эти коман
дыпустышки часто раздражали, когда при пошаговой отладке кода при
ходилось выполнять их по одной. Создавая оптимизированный код, ком
пилятор C# удаляет команды NOP.
При создании нового проекта на C# в Visual Studio отладочная вер
сия (Debug) собирается с параметрами /optimize и /debug:full, а версия
Release — с параметрами /optimize+ и /debug:pdbonly.
Впрочем, независимо от этих параметров при подключении отлад
чика кпроцессу, поддерживающему CLR, для облегчения отладки JIT
компилятор всегда создает неоптимизированный машинный код. Ясно,
что производительность такого кода ниже.
14 Часть I Основы 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компилятором. Подробнее об
NGen.exe я расскажу далее.

мы говорим про промышленность или про единичных энтузиастов?

качестве примера - реализация бинарного дерева обычным "ученическим" подходом (элемент и два указателя на листья-потомки) в 10 раз медленнее, чем реализация того же дерева при помощи динамического (или статического, но с избытком по размеру) массива

Динамический массив - это обычный линейный список.

мы говорим про промышленность или про единичных энтузиастов? Если последнее, то я и сам на С пописываю иногда, а если о первом, то оптимизировать команды, переводя с высокоуровневых ЯП на асм никто не будет, т.к. а) геморрой, б) потеря совместимости (куча разных процессоров, синтаксис Intel, AT&T) и переносимости в) трудности в отладке.

скорость разработки - особенно гуи - быстрее на порядки,

с применением ASP.Net, WPF

Что касается памяти: неприятно, но серьезной проблемой это я не считаю, учитывая, что плашка на 8гб стоит 700 рублей

jit может компилировать учитывая такую информацию, которую в статическом компиляторе получить заранее невозможно

например, точная марка процессора и точное знание, какие инструкции он поддерживает

если пишем ядро ОС то нечего и думать о С#

я дельфист

есть оси и на C#, но основа всё равно нативная (линуксовый загрузчик)

скорость разработки - особенно гуи - быстрее на порядки,
я дельфист Мне не надо сравнивать C и C#. Кстати, игру буду писать на нативной Делфи именно из-за количества памяти.

ниасилил. аспнет на простых задачах, но под высокой нагрузкой хуже пыха, а впф пытался изучать, но, имхо, пока что недостатки перевешивают достоинства.

не у всех есть больше 4Г. К тому же, 4Г не подходит ни к х32 (всё не видит), ни к х64 (жрёт столько, что выгоднее поставить ос х32).
3dsmax, maya, zbrush и прочие. Тут много памяти не бывает и не только нужно ставить оси х64 и наращивать озу, но и, имхо, хоть немного оптимизировать программы, чтобы озу не требовалось терабайтами. Это в районе пожелания, не знаю как вышеперечисленное написано на самом деле
Фотошоп. Недавно нужно было увеличить пару картинок для печати, на 16Г озу потребовалось 20Г свопа. Обрабатывал по одной пикче.

Наконец-то подошли к играм. Если известный вам "чайник" *поднимает правую лапу* будет писать свою игру "в лоб", то 50-70% игрового пространства нагнёт квартет топовых видюх и не меньше 64Г озу. Дотнет хорош, но большие объёмы занимаемой памяти практически убивают игру. Как и отсутствие оптимизации на уровне алгоритмов.

это в теории и рекламе. А на практике из плюсов на текущий момент лишь уменьшается количество ошибок человеком. Верю, что допилят до желаемого, но только если Сами-Знаете-Кто не забросит недавно активно продвигаемое Сами-Знаете-Что (как прогнозируют АНАЛитики) Сами-Знаете-Куда А пока - дотнет для бизнеса да и то не всегда (бывают глюки).

ответ неверный.
Линейный список редко располагает элементы друг за другом. Они могут быть в любом месте кучи и обращаться к ним по индексу чаще всего нет возможности.
Динамический массив гарантировано располагает элементы как в обычном массиве один за другим. Выбор размера на который массив "растёт" или "худеет" весьма нетривиальная задача и неверный выбор этого размера может крайне плачевно сказаться на производительности.

Динамический массив - это обычный линейный список. В некоторых языках он упаковывается в соседние ячейки, что позволяет обращаться по индексу. Однако при изменении размеров при таком развитии событий очень быстро растет фрагментация кучи.