Делает ли Delphi XE более быстрый код, чем Delphi 2007?

Ответ 1

Две точки за два цента:

1. Для нашей рамки ORM с открытым исходным кодом

При запуске наших модульных тестов с компиляторами Delphi 7, Delphi 2007 и Delphi 2010 я обнаружил некоторое улучшение скорости между Delphi 7 и Delphi 2007, но не заметно между Delphi 2007 и 2010. Разработанный код Delphi 2010 оказался немного медленнее. У меня нет компилятора Delphi XE под рукой, но я думаю, что он такой же, как Delphi 2010 - в основном исправление ошибок в отношении генериков, AFAIR.

Я потратил много времени на просмотр asm (Alt-F2), когда пишу низкоуровневый паскаль и использую профилировщик. Поэтому я обычно замечаю разницу между версиями компилятора Delphi.

IMHO основным улучшением было действительно ключевое слово inline для методов и функций/процедур, доступных в Delphi 2007, а не в Delphi 7. Еще одним улучшением было более агрессивное повторное использование регистра.

Сгенерированный с плавающей точкой код все еще медленный, а иногда и awfull (FWAIT все еще производится, даже если это не требуется больше, а встроенный код с плавающей запятой может быть даже хуже, чем без вложения!

Что интересного в нашей структуре, и все эти тесты состоят в том, что он обрабатывает множество данных, используя свои низкоуровневые модули, закодированные в очень настроенном паскале для лучшей производительности. И модульные тесты (более 5 400 000 отдельных тестов) работают над реальными данными (цифровое преобразование или текстовая обработка UTF-8), с множеством различных процессов, включая конверсии низкого уровня, синтаксический анализ текста, распределение объектов, многопоточность и Ориентация клиента/сервера. Таким образом, генерация кода компилятором имеет значение.

Код в основном находится внутри нашей структуры. Мы используем собственный тип строки RawUTF8, а не общую строку. Таким образом, узким местом является не VCL или Windows API, а только чистый скомпилированный код Delphi. Фактически, мы избегаем большинства вызовов API, даже для кодирования UTF-8 или числовых преобразований.

Конечно, я пробовал этот тест с условным набором PUREPASCAL, т.е. не выполнял оптимизированную часть в asm, но полагался только на код "чистый паскаль".

2. Для блока сжатия SynLZ

Еще один хороший эксперимент по скорости заключался в написании и профилировании блока сжатия SynLZ. Благодаря этой оптимизированной реализации алгоритма сжатия LZ сжатие в 20 раз быстрее, чем zip, декомпрессия в 3 раза быстрее. Фактически, он конкурирует с LZO за коэффициент сжатия и скорость декомпрессии, но намного быстрее, чем LZO для сжатия: SynLZ способен сжимать данные с той же скоростью, что и при распаковке. Такая симметричная реализация очень редка в мире сжатия.

Он включает только целочисленную арифметику и битовую логику, заполнение и поиск в хэш-таблицах и копию памяти.

Мы написали очень настроенный код паскаля, а затем скомпилировали его с Delphi 7 и Delphi 2009.

Сгенерированный код Delphi 2009 был быстрее, чем Delphi 7, заметно. Сгенерированный код был действительно лучше, с лучшим повторным использованием регистра.

Благодаря ручной настройке ассемблера мы добились еще большей производительности. Например, XML файл размером 6 КБ сжимается со скоростью 14 Мбайт/с с использованием zip, 185 Мбайт/с с использованием LZO, 184 МБ/с с использованием параболической версии Delphi 2009 SynLZ и 256 МБ/с с нашей последней настроенной версией asm SynLZ.

Вывод:

Для генерации кода, включающего целочисленный процесс, разбор текста или память, я думаю, что Delphi XE быстрее, чем Delphi 7, но должен быть более или менее на том же уровне, что и Delphi 2007. Вложение было основной новой функцией, которая могла бы значительно ускорьте код.

Но для реального приложения увеличение скорости не будет заметным. Около 10 или 20% в некоторых конкретных случаях, не более. Алгоритмы всегда являются ключом к повышению производительности. Delphi 7 уже был хорошим компилятором.

Для арифметики с плавающей запятой компилятор Delphi в настоящее время устарел. Я надеюсь, что код SSE в 64-битном компиляторе изменит результаты здесь.

Чтобы ответить прямо на ваш вопрос, в Delphi 2010 или XE, нет автоматической установки или автоматической петли-разворачивания AFAIK. И накладные расходы в многопоточном коде не являются частью компилятора, а в библиотеке (FastMM4, подсчет ссылок и т.д.). Поэтому я не думаю, что Delphi XE создает более быстрый код, чем Delphi 2007.

Ответ 2

Мое неофициальное тестирование компилятора Delphi XE показывает, что во многих случаях генерация кода значительно правильнее, чем использование Generics, и что некоторые внутренние сбои компилятора (ошибки), которые преследовали компилятор в эпоху Delphi 2009, 2010, теперь фиксированы. Во многих случаях код Delphi 2010 с использованием дженериков, связанных с пакетами, при повторной перестройке в среде IDE приводит к повреждению DCP файла или таинственным внутренним ошибкам компилятора во время компиляции и ссылки.

Я бы написал в примечаниях к выпуску, если бы это был я, "мы исправили ошибки". (я отвлекаю фразу "Лучшее время", потому что кажется, что люди думают, что я имею в виду рекламу моего тогдашнего работодателя, я раньше работал в Embarcadero). Я полагаю, что все это было сглажено в слово "производительность", где производительность понимается как "правильность" и "выполняющая свою работу надежно и без сбоев".

Что касается скорости, я не заметил сколько-нибудь статистически значимой разницы в профилировании кода из Delphi 2009, 2010 или XE, что касается скорости выполнения на скорости выполнения или производительности компилятора, с точки зрения "он строит проекты" быстрее".

Поскольку вы спросили о Delphi 2007, вы должны знать, что существует огромное изменение типа (String = AnsiString, для String = UnicodeString). Для одного и того же кода некоторые вещи будут медленнее, а некоторые будут быстрее, и на 100% невозможно сказать, что произойдет, если вы перекомпилируете свой код 2007 в 2010 году, не зная много о своем коде. Если раньше вы полагались на WideString, и теперь вы можете использовать UnicodeString, ваш код будет намного быстрее, поскольку производительность UnicodeString намного лучше, чем производительность WideString. Некоторые программы delphi проводят много времени в вашем коде спокойно (и почти незаметно), преобразуя данные ansi в данные unicode, внутри win32, например, когда вы используете общий элемент Memo. С другой стороны, некоторые вещи, которые использовали для использования строк в байтах, теперь будут использовать строки размера слова, поэтому использование памяти в некоторых местах будет увеличиваться, а некоторые операции могут замедляться. Скорее всего, чистый результат для правильно портированного кода (вы должны внести некоторые изменения в большинство приложений, чтобы заставить их строить в XE, если вы написали их в 2007 году), является чем-то небольшим чистым уменьшением "сырой производительности".

Однако Delphi XE строит проекты и, что еще важнее, перестраивает и перестраивает, снова и снова, в среде IDE, без инцидентов и никогда не сбивает меня. Delphi 2007 рухнул на меня все время. В Delphi 2007 также есть сотни раздражающих ошибок компилятора, которые сбивают меня с ума. Скомпилированная скорость кода даже не является основной причиной обновления, надежность.

Часто в больших проектах, которые я использовал, Delphi 2007, 2009 и 2010 года будут разбиваться на вторую или третью перестройку некоторого сложного набора пакетов. В 2009 и 2010 годах пакеты, в которых широко использовались дженерики, были особенно вероятны сбой среды IDE. XE стабилен, даже когда я использую его с кодом тяжелых дженериков, и это своего рода улучшение производительности, о котором могут говорить в примечаниях к выпуску. Я называю это "исправления ошибок". Давайте называть лопату лопатой.

(Удалено последний абзац, потому что люди думали, что это реклама)

Ответ 3

Я не вижу каких-либо существенных улучшений в генерации кода. Я не знаю, что было что-то очень важное в плане улучшения генерации кода с Delphi 5. На самом деле я никогда не обнаружил, что мой код работает быстрее после обновления и что он возвращается к Delphi 2.

Ответ 4

Компилятор Delphi сегодня очень устарел и переписывается. Улучшения до XE выглядят маргинальными, и компилятор действительно не в состоянии использовать новейшие возможности процессора и наборы инструкций (он в основном застрял в эпоху 80386, но для некоторого RTL-кода, который использует ручной ассемблер, чтобы воспользоваться преимуществами более современные возможности). Компилятор XE может быть более надежным в предыдущих версиях (поскольку качество D7 стало очень переменным), но для улучшения производительности в целом потребуется полный пересмотр компилятора, чтобы довести его до XXI века. Это было сделано, но неизвестно, будет ли в следующем выпуске только более новый 64-битный компилятор, и все еще старый 32-битный, или если 32-битный компилятор тоже имеет новую базу кода.

Ответ 5

Вот ссылка на embaracadero

http://www.embarcadero.com/products/delphi/whats-new

Короткий путь вниз по странице в

"Язык, компилятор и библиотека Улучшения"

они упоминают улучшения компилятора. Здесь не много, но то, что они не говорят, - это ваш ответ. То есть, если бы у них было что-то важное, они, вероятно, хвастались бы этим.