На РСДН идет мегабитва, за 550 ответов в посте "Почему Delphi не умер" http://rsdn.ru/forum/flame.comp/3998416.1.aspx

cemick, по твоей ссылке вижу только 1, где остальное

Ха, кто-то там написал что Делфи медленней NET 4.0))) Ох посмешили, я точно знаю, что скорость делфи на уровне gcc, потому что пишу интерпретатор языка, который по скорости не уступает известным интерпретаторам.

Скорее человек что-то такое тупое написал, что NET произвел умную и агрессивную оптимизацию и уже орет о том, что NET 4.0 быстрее компилированного языка. Хоть он и JIT, но все равно.

Во многих случаях .NET действительно быстрее Delphi. 

Во первых, их скорость не может значимо различается. Т.к. в обоих случаях выполняются ассемблерные команды. А когда код преобразуется в процессорные инструкции - на этапе компиляции или во время запуска на скорость не влияет. Другой вопрос, что программа писанная на Delphi использует инструкции ТОЛЬКО самого древнего процессора, на котором она должна работать. В свою очередь .NET программа может использовать фичи того процессора на котором она запускается и засчет этого быть быстрее.

Во вторых, программа Delphi во время работы какомо-нибудь кода постоянно выполняет операции выделения-удаления участков памяти. В .NET во время работы выполняются только выделяется память, а её удаление, как правило происходит во время простоя программы (т.к. большинство программ большую часть времени проводят в режиме ожидания действий пользователя)

А я читал, что немного наоборот. Программа на дельфи будет занимать меньше памяти и работать шустрее.


мне кажется, что это не так

А здравая логика говорит об обратном  


В некоторых случаях - да, т.к. программа компилируется в меньшее количество этапов, то возможна более аггресивная оптимизация и работать будет быстрее. А по поводу памяти Integer как в .NET занимает 4 байта, так и в Delphi. Чудес не бывает. Большинство типов данных
будут занимать одинаковый объем в обоих системах. Или на ВАШ взгляд Delphi умудряется архивировать на лету сегменты данных и стека   

Данные хранятся не только в Integer. Данных в памяти храниться вообще много и разных. И может быть одна переменная Integer, а может быть их пару сотен. Не забывай об этом.

Насколько я знаю, в случае с .NET компиляция происходит при первом запуске. Откомпилированный вариант программы сохраняется Windows-ом для дальнейших запусков. 
Оптимизация при компиляции идет с учетом конкретного набора инструкций процессора, конкретной разрядности (системы), конкретного количества ядер... 


Проигрыш .NET в производительности и потреблении памяти во многом обусловлен иным подходом к обработке исключительных ситуаций и иной работе с памятью.

Однако реальная производительность сложных приложений на .NET (и Java) зачастую оказывается выше нативных, при гораздо более высокой скорости разработки и гораздо меньшем количестве "странных" багов, и утечек памяти. 

п.с. речь не идет о графических интерфейсах - WPF или Swing тормозят не потому что они на .NET или Java (соответственно), а из-за архитектурных особенностей. 

Если обобщить Delphi и .NET на натив и VM, то примерами преимущества VM над нативом могут служить интерпретаторы скриптовых языков. Большинство интерпретаторов написанных на Java работают быстрее написанных на c/c++ (классический пример - Ruby и JRuby). Памяти жрут, правда, поболее...





А как иначе? Конечно компилятор может кое где сделать разные куски кода для процессоров с разными наборами инструкций. Но не знаю умеет ли делать это компилятор делфи. Да и в любом случае все многообразие процессоров не учтешь. 





Это как-то меняет смысл утверждения:




?

У Delphi действительно фиговый оптимизатор кода и часто он не использует новые возможности процессоров.

Другое дело, в частично в неё всё же тащут новое - это FastMM и FastCode. Но надо понимать, что это просто куски кода, а не навороты компилятора, которые применяются к любому коду.

С учётом того, что .NET компилируется действительно один раз, то он вполне может быть немного быстрее Delphi при последующих запусках. Но уж никак не в разы.

Обычно тот, кто кричит про неэффективность платформы, просто не разобрался в ней. И пробует решать задачу методами другой платформы.

Мне это напомнило споры что Java быстрее С++.

Поверьте, C# не может быть быстрее Delphi, JIT это все равно не полноценная компиляция, все такие некоторые абстракции присутствуют. А те кто кричат, про обратное, не умеют делать правильные и справедливые тесты.

Это сообщение отредактировал(а) lukas - 24.10.2010, 17:34

Почему это?

.NET - это обычный нативный код (когда он уже скомпилирован). Это не интерпретатор и не виртуальная машина. Не говоря уже про то, что .NET может быть pre-compiled в целевую платформу (с помощью NGen.exe), полностью исключая фазу IL байт-кода.

Добавлено через 1 минуту и 49 секунд
P.S. Ява - это виртуальная машина. Поэтому Java при прочих равных должна быть медленнее native. И то для неё в последнее время развивается JIT компиляция в native.

Jit в Java присутствует давно. Причем существуют различные варианты его работ. На хабре был интересный подкаст - послушайте, там рассказывается как работает JIT в режиме сервера:

http://habrahabr.ru/blogs/hpodcasts/100253/

Я так и не понимаю, что ж тогда такое .NET, это и не JIT и не байт код. Неужели прямо код сохраняется практически в dll или exe (утрирую)? Код .NET может быстрее выполнятся за счет использования быстрых и хорошо оптимизированных решений этой платформы, а там их куча. 

На мой взгляд все просто, IL это байт код, который во время выполнения компилируется в машинный код, но в этом машинном коде, все равно остаются некоторые вызовы функций из платформы .NET, это некоторая абстракция. А отсюда следствие, зависимость от платформы .NET и ее версии.


На мой взгляд, то что вы описали это просто JIT с кешированием, и java делает скорее тоже самое, просто там отсутствую скалярные типы, из-за чего некоторые алгоритмы могут работать медленней, объекты никогда не будут работать быстрее скалярных типов. С этим очень много проблем, например недолго живущие объекты + мусоросборщик дают такое замедление, что мало не покажется. (если делать так как в языках со скалярным типами)




Она вообще его начала раньше всех применять на практике.


P.S.  Кстати говоря, для языка LUA тоже есть JIT, вот было бы интересно сравнить скорости LuaJIT и c#. Ни у кого не такой возможности?

Это сообщение отредактировал(а) lukas - 24.10.2010, 21:57

В языке Java 8 скалярных типов: boolean, byte, char, short, int, long, float, double.

Да ошибся, что-то мода на ruby и python меня сбила с толку. Спутал я еще с Integer, в Java это объект.