Сразу говорю: это не тема Delphi vs c. Я не спрашиваю, что лучше. Мой вопрос только по поводу компиятора Delphi и про оптимизацию, которую он проводит. Я слышал мнение, что Delphi генерирует довольно медленный код, медленнее, чем, например c++. Так ли это, и если да, то с чем именно это связано? Есть ли какие либо недостатки у Delphi по сравнению с C++ в этом отношении, насколько они критичны и можно ли их обойти? Я знаю один недостаток: в Delphi нет макросов, а это полезная штука. Но с c++ я только слегка знаком, поэтому спрашиваю мнение людей, которые знакомы с обоими языками.

Заявления такого рода не только безосновательны, но и не корректны. Какой компилятор Delphi имеется в виду (for Win32 или for .NET)? А какой компилятор С++? 


Если бы были серьезные недостатки, то на Delphi никто бы не писал. Взгляни хотя бы на кол-во тем в соотв. разделах форума.

Добавлено через 8 минут и 33 секунды

Да ладно уж недостаток. 3 года пишу на Delphi и ни разу потребности в макросах не испытывал. Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса?

я знаю одно могучее приемущество Delphi перед многими другими языками - компиллер всё необходимое запихивает в exe файл, поэтому программы дельфи не требуют ничего дополнительного и прекрасно идут на ВСЕХ компах.   

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

Это сообщение отредактировал(а) CompWorm - 23.3.2008, 00:20

Delphi под Win32 ( я на нём пишу), а с++ - любой 


Я имею ввиду именно недостатки в отношении скорости выполнения получаемого кода. Речь идёт о реал-тайм приложениях (конкретно об играх).


скоростью


А можно поподробнее? А программы на C++ могут не идти на всех компах?

программы, идущие с .NET КАК МИНИМУМ требуют установить на компе Вашего клиента .NET фреймворк, занимающий ой сколько места... 
если взять , к примеру бейсик тот же (молчу про скорость работы программ   ) то он требует море всяких библиотек с собой тоскать... за С++ не скажу, ибо не знаю.

Имхо, при современных производительностях компьютеров скорость выполнения кода на 99% зависит от радиуса кривизны рук программиста. Хотя чисто по привычке все системные приложения, не требующие GUI, пишу на С++ - но ради интереса один раз попробовал одно из них перевести на дельфи - никакой потери скорости (субъективно, конечно) не заметил, только размер исполняемого файла больше на порядок...
Если активно юзать CRT, например, то на компе без установленной библиотеки CRT - не пойдет...

Все зависит от кода.
Если, например, использовать тип string и функции pos, insert, copy, delete для парсинга большого текстового заковыристого файла, то можно заметить, что чтение и разбор занимает больше времени,  чем  при использовании PChar и функций Str*().
Хотя тип string и pchar для Delphi обна родные...

Крайне неадыкватное представление о скорости исполнения MSIL-кода. Взгляните, например, сюда:
http://shootout.alioth.debian.org/gp4/benc...mp;lang2=csharp
Как видите, C# (Mono) проигрывает С++ (GNU G++) в среднем в 2-2,5 раза. Такая разница некритична. И это реализация Mono, а не .NET. Мне кажется (утверждать не могу) C# (.NET) проиграет еще меньше. 

  Скорость зависит от используемых средств. Delphi for win32 генерит машинный код напрямую, более того часть функций оптимизирована на асме, можно встретить и сторонние разработки с оптимизацией под MMX и SSE. 
  Классы работают действительно несколько медленнее из-за более высокого уровня безопасности. 

я так скажу... .NET это виртуальная машина негрософт которая исполняет байт-код, обычно у байт-кода 1 команда = 1-2 командам асм... скорость выполнения .NET очень высокая для интерпретации... я бы сказал очень высокая относительно виртуальных машин, вообщем в висте уже встроен фрейм ворк 2.0, и в следующих версиях будет встроен, постепенно .NET внедрится в ОС и никаких библиотек не нужно будет, он станет куском ядра система... VB NET, Delphi NET, C# все они компилируют в один байт код, я вижу в этом множество удобных вещей:

 - 1. Огромная и богатая информация RTII
 - 2. Обсолютно полная совместимость DLL .net написанных на разных языках... (поддержка классов например)
 - 3. Как говорится майкрософт хочет сказать - "скажите машине что ей надо сделать, а .NET это сделает наиболее безопасно и без глюков", я не первый повторяю эти слова....

Добавлено через 1 минуту и 57 секунд
еще хочу добавить, что разработка сайтов на .NET намного легче чем на PHP, стоит задуматься... хотя хостинги PHP стоят в несколько раз дешевле... 

  Не это не виртуальная машина, а компилятор времени исполнения, т.е. код компилируется при исполнении. 
Вообще тема ушла в холивар, потому ее туда и переношу.

если вы не имеете в виду управляемую ОС, то вы несете полную чушь

MAKCim, 

я имел ввиду не в прямом смысле... просто фрейм ворк будет по стандарту поставляться с ОС... 

MAKCim, Ну драйвера, и ядро по-любому будут нативными, а все остальное, прикладной интерфейс  API, сервисы всякие, оболочка, сопроводительный софт, утилиты... очень даже может быть, но вот только сам Microsoft не торопиться это делать  . Вижуалки вот от 2003й по 2008ю сплошь нативные, виста тоже, да и офис 2007й только частично что-то там сделали под .NET. 

Zmiy, давайте для теста математический алгоритм. Реализуем его на вижуалке или делфях, а затем сравним.

lukas, 
ок

я имел в виду не это

Есть такой алгоритм 
Предлагаю реализовать игру жизнь.

ну, мы говорим не о строках, я имею ввиду оптимизацию, в основном, математических расчётов. С++ использует sse, inline функции, макросы. Вот я хотел бы понять, как на Делфи писать быстрый код без этого



Отличная мысль! Сейчас подумаю над алгоритмом

Нафиг макросы, когда inline есть?

Игры на Delphi действительно не пишут в частности из-за оптимизации, откуда там всяким SSE взяться, когда в VCL полно ассемблера. Уж не знаю насколько там SSE позволяет ускорить простейшую математику (посчитать новые координаты объекта, например) с 32-хбитными вещественными. Насчет скорости самого языка, для теоретического случая, что имеем C++ и Pascal компиляторы с одинаковой оптимизацией не скажу. Логично предположить, что разница будет в пределах 2-3%.
Всякие языковые сишные отимизации типа a+=b (упаси от них бог Delphi) вместо a:=a+b, критичные во времена "286 терпимо, 386SX хорошо, а 386DX-40 MHz круто" сейчас роли не играют, и компиляторы могут сами это оптимизировать.



Просто посчитать с начальной конфигурации координаты всех "животных" в поколении X?

неоспоримое приемущество
программы на Delphi настолько суровы, что работают на Linux, Mac OS и даже Plan9   


как всегда забавно читать о недостатках какого-то инструмента, то, что написано человеком, не владеющим этим инструментом )))


Не один компилятор сам не будет использовать SIMD расширения процессора, это всегда ложится на плечи программиста...
а уж использовать SSE в коде GUI библиотеки (VCL) это нонсенс   

Приемущество С++ в гибкости. Язык шаблонов в С++ Тьюринг полный, соответственно во время компиляции можно выполнить любые вычисления, например преобразовать число из бинарного представления можно с помощью этого шаблона

константа i будет вычислена во время компиляции, а не во время выполнения. Delphi так не умеет 

Lazin, это не холивар о возможностях, а о скорости!


  Какие условия? Какое начальное состояние? Сколько ячеек? Какое графическое отображение? Сколько кадров в / сек? Чего можно юзать чего нет?

ну правильно, намного быстрее расчитать что-то в compile-time один раз, чем считать каждый раз в run-time   

В таких случаях можно и в run-time одним разом обойтись.

Lazin, к твоему сведению считать умеют не только шаблоны, а еще и калькулятор  . Константу можно любую забить и руками. Мне например хватает записи в HEXе. Для этого ничего не нужно преобразовывать. Факториал я могу и на калькуляторе вычислить и забить константу, в крайнем случае создать таблицу значений при старте программы. Ни как и ни на что это не влияет по скорости, а твой любимый билдер 90% бинарного кода реально код скомпилированный из делфийских сорцов делфийским компилятором слинкованный с билдеровским проектом. Так что когда хвалишь скорость билдера не забывай чьи 90% заслуги там   .

Ни слова о недостатках макросов я не произнес. Я действительно человек в C++ несведующий и посему задал конкретный вопрос: Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса? Я жду ответа...

Шаблоны могут успешно inline'ится. это влиет на скорость в коде  наподобие


Если в дельфи понадобится отсортировать что-либо, она способна заинлайнить компаратор? 
Или будет палить такты процессора на вызов ф-ций?
Как в современном дельфи с этим дело обстоит?

Добавлено @ 12:21

Вызов функции занимает >0 тактов. Расчёт ф-ции занимает >0 тактов.  В отличие от расчетов с помощью шаблонов. Которых во время run-time'а вообще нет.

Хотя может оптимизатор дельфи и способен заменить вызов простых ф-ций на константы.

Это сообщение отредактировал(а) Mayk - 24.3.2008, 12:23

Да.


Графики нет. Просто прочитать начальную конфигурацию из файла, просчитать 1 000 000 циклов, и записать конечное состояние в другой файл. Начальная комбинация скажем планерное ружье (чтобы было постоянное изменение). Размер скажем 100х100. 
Начет того что можно использовать - о чем идет речь?

обычно макросы не используют для того что-бы  что-то считать, для этого используют функции (компилятор С++ там где надо заинлайнит, а где не надо вызовет эту функцию). Макросы кроме как для условной компиляции использовать не стоит.


Давно уже не пишу GUI приложения, так что   


а лучше пускай компилятор сам за меня считает, а если я где накосячил даст по рукам (пошлет на йух нескончаемой чередой сообщений об ошибках)   

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

если тип переменной P - не мощность, то код просто не скомпилируется.   
это всего лишь одно простейшее применение шаблонов

если заглянуть в реализацию стандартной библиотеки, то можно много чего интересного увидеть 

В современном Delphi не хватает только шаблонов и не полностью реализована перегрузка операторов для Delphi 4 Win32.
Inline, статич. члены класса появились скорее всего в D 2005.



Макрос в Си++ это замена в исходнике одного текста другим, что исключает вызов ф-ии. Inline - подстановка в код тела ф-ии с той же целью. Тоже жду комментов, что лучше. Я не пишу на Си++, но примеры, "оптимизации" макросом после которой ошибку ищешь больше времени, чем этот макрос за все время эксплуатации софтины сэкономил, есть в любой книжке по плюсам.



Я сам как-то не интересовался, но мой знакомый пишущий на Builder'е, и для которого в Паскале тоже букофф много, говорил, что Билдер даже медленнее Delphi.  



Насчет графики я как-то не понимаю, как ее строить и не съест-ли она 99% ресурсов. Что тогда мерить? Да и интересует в первую очередь вывод конечной позиции, которая после нескольких десятков тысяч поколений м/б 3756x5667 клеток, или считаем, что поле ограничено?



Правда? И что же это при работе с API все охотно пишут:


  

и HelloWorld на билдере больше весит чем на Delphi))

Я плакал со смеху, когда Microsoft Visual C++ в VS 2003 говорил мне, что Internal compile error и пошли вы к Билли, когда на самом деле был type mismatch.  



PS Блин, не могу понять кайфа от расстановки этих фигурных скобок. Это же неудобно. Что бы наСИльники не говорили.

Добавлено через 11 минут и 14 секунд


Сорри пока писал свой ответ, ваш появился.
Планерное ружье просто генерит бесконечно планеры, которые, если я правильно понял, будут просто разбиваться о стенку. Можно взять, что-нить поинтереснее. Графику можно начальную фигуру мышкой по сетке набирать. В принципе при 100х100 можно попробовать вывести и конец.

Mayk, вот нашел:

Возможность определения констант была в Delphi всегда, а директива inline - начиная с Delphi 2005. Выходит, можно обойтись без макросов?

В .NET их просто нет.  MS сказала: "Макросы - зло" 

ты наверное windows.h не видел   

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

Ф-яя очевидно м/б с пользой заинлайнена если:
1) вызывается всего в одном месте.
2) Вызывается в цикле.   
Или Си-приграммисты глупее своего компилятора.  
Программист на Delphi решает имеет-ли смысл заинлайнить, а компилятор решает можно ли это сделать. Инлайнить же или нет какой-нить sin(x) из библиотеки, который вызывается в данной конкретной программе в 65826844 местах уже другой вопрос.



Не видел, (или видел, но было пофиг) но я не про него, а про .NET и в первую очередь C#.

Это сообщение отредактировал(а) Beltar - 24.3.2008, 14:58

так ведь в С# есть препроцессор, очень похожий на Си-шный)))

Все теперь только Copy/Paste   

А я то наивный думал что именно программист и решает 

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

так я не понял, относительно только дельфей:
1) лучше программировать под .NET или просто D7
2) чьи проги из них быстрее (если считать с GUI)
3) чьи проги из них быстрее (если считать без GUI)

?   ?    ?


Это сообщение отредактировал(а) CompWorm - 25.3.2008, 21:19

а что значит быстрее, и зачем тебе вообще нужна "скорость"

вообще Delphi какой-то несексуальный, так что ну его в баню   

ух ты! а пруфлинк можно?

CompWorm, ты что, до сих пор хочешь однозначный ответ? Типа там "Delphi круче С++, C# круче Delphi"?  

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

Есть входной текстовый файл с начальным раскладом. Пробел - свободное место, конец строки в стиле DOS, все остальные символы - клетки. Размер поля определяется количеством строк и длиной самой длинной строки. Требуется написать нативную консольную прогу, которая должна спросить в консольном окошке количество поколений, вывести конечную ситуацию в выходной файл, и время которое занял ращет (без работы с файлами) в консольное окно. Максимальный размер поля 1000х1000, но ничего не мешает прогонять это потом на файлах меньшего размера (100х100 как вы хотели). 

Если такое условие устраивает то давайте определимся как отмерять время - чтобы у всех были одинаковые погрешности. имхо для большого количества поколений разность двух GetTickCount вполне покатит.

JackYF, Герб Саттер, Новые сложные задачи..   

Э нет. Мне в стандарте, пожалуйста 

Ради смеха сделал простую реализацию life на паскале для  поля 10 на 10 (извинте, на большее не хватило). На неё поместилл две "вертушки". и сделал 1 000 000 поколоений.  И оттранслировал её в си. а потом замерил время выполнения программ скомпилированных паскалевскими компиляторами с временем выполнения си-шной программы которую транслятор получил из паскалевской программы.

В забеге принимали участие:
fpc [версия free pascal compiler 2.0.4]
gpc [версия gpc 20060325, based on gcc-3.4.6 (Ubuntu 3.4.6-6ubuntu2)]

и гвоздь программы: транслятор с паскаля на си
p2c [версия 1.21alpha-07.Dec.93]

Результаты. Время указано в секундах для выполнения всей программы. 
FPC:


GPC:


а теперь внимание --- результат оттранслированного кода из паскаля в си


вывод: писать в юнихе на паскале -- не комильфо.

проект полностью в аттаче вместе с бинарниками [правда бинарники там для amd64]


зы. правдо замечу что сишный файл компилировался более свежим компилятором: 
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2). 


Это сообщение отредактировал(а) Mayk - 28.3.2008, 21:53

Присоединённый файл ( Кол-во скачиваний: 9 )
 life.tar.bz2 146,89 Kb

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

Mayk, что и требовалось доказать   , правда FPC это не совсем Delphi, но думаю(хоть у меня на это и нет особых оснований) особой разницы не будет   

  Зря думаешь!

Доработал чуток проекты, чтобы они запускались под борландном, в результате на моем проце Sempron 2500+ под виндой

Delphi 2007           ~19c
Turbo C++ Builder ~20c

Все скомпилено под релизом со всеми оптимизациями.

на счет 3х секунд, я думаю там какой-то глюк, не может быть разница в 6 раз.

Проект в атаче, проверяйте.



Присоединённый файл ( Кол-во скачиваний: 8 )
 Life_test_2008.03.31_10.09.zip 6,76 Kb

на самом деле Си-шный исходник можно еще оптимизировать   , как минимум, перейти с индексов, на арифметику указателей

скомпилил и запустил на своем компе сишный исходник:

builder - 10969 (думаю(Alexis извини, я опять думаю  ), результат Delphi не будет сильно отличаться от этого)

msvc - 3937

Добавлено через 1 минуту и 29 секунд
"проблема" скорости Delphi - на самом деле - проблема компилятора, который уже очень давно не развивается

ну если кто-нибудь сделает большую карту, то мы можем проверить результаты. учитывая разницу в два раза у Lazin'а

выглядит возможным.

Кстати. Alexeis, Lazin,  а можно выложить в дополнение скомпилированные бинарники?




Это сообщение отредактировал(а) Mayk - 31.3.2008, 11:45

  билдер синенький, делфи без иконки

Присоединённый файл ( Кол-во скачиваний: 8 )
 life_2008.03.31_12.07.zip 28,28 Kb

life_game.zip

Это сообщение отредактировал(а) Lazin - 31.3.2008, 13:13

  Да, ребята вижуалка отожгла, хз что там за оптимизации, но скорость в 3 раза выше. При отключении оптимизации 22 секунды.
Возможно, там оптимизация SSE или еще что, но явно алгоритм был не оптимальным и компилятор его переделал.

это за тебя компилятор сделает   

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

Я про устаревание inline 

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

другое дело, что тот-же Саттер не рекомендует использовать inline в своих программах, так как эта директива не несет никакой смысловой нагрузки. inline функция с точки зрения языка - такая-же как и не inline, в своем коде ты не можешь узнать как она объявлена, либо запретить получать ее адрес.
к тому-же директива inline применяется при объявлении функции, а компилятор встраивает ее в точке вызова, то-есть в одном месте он может ее встроить, а в другом сделать вызов. 

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

я такой эксперимент поставить не могу, поэтому спросил. это повод для насмешек?

Давно уже. Это был ответ на один из постов в твоей теме, посмотри.

  

DelphiLife.rar

Это сообщение отредактировал(а) bems - 31.3.2008, 23:17

bems, че это такое?

Эта жисть на дельпхи!

bems, т.е. заоптимизировал все вручную  безо всяких крутых компиляторов? Или не обошлось без супер компьютера? Какой результат по времени приведенных мною экзешников? Время разнится на разных машинах.

P4 1.8 GHz 256M

Они не запустились - нехватает каких-то библиотек. Время работы 
этого на той же машине около 17 секунд

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

Раунд 2!  С картинками   
Из кода bemsа были выкинуты в основном обработка исключений(так как gpc с ней не дружит), 
замер времени (так как искать аналог сишных [стандартных кстати] clock() мне лень ), финальный readln и DWORD'ы были заменены в случае gpc на integer, в случае fpc и p2c на int64 [чтоб указатель внутрь влез]. Сишный код привён к виду без использованя libp2c. Оригинальные в аттаче тоже есть.

На сей раз результаты уже не столь разительные если исключить fpc   , но...


...Сишный код получаемый в рез-те трансляции опять быстрее оригинального паскалевского  (хотя для трансляторов это вроде как редкость   )
За графики спасибо gnuplot'у.





Это сообщение отредактировал(а) Mayk - 1.4.2008, 19:06

Присоединённый файл ( Кол-во скачиваний: 2 )
 life_round2.tar.bz2 146,24 Kb

не понял

ты на 64?

А какое ко всей этой информации имеет дельфи?

И вообще на поле 10х10 письками меряться не интересно. Давайте увеличим сложность задачи и откажемся от всяких трансляторов (потому что программист и его компилятор едины ) По времени будем сравнивать то что написал пасквилянт на дельфи с тем что написал насильник на си.

ага. и на линухе. поэтому gettickcount'ы выкинуты.


угу. давай чё-нить зубодробидельнее. что предлагаешь?


А вот тут нет. мы не откажемся от трансляторов даже если будем писать задачу целиком. 
Потому что в этом то вся соль --- сейчас оттранслированный код на си получается не медленнее оригинального кода, написанного для паскаля  .  Причём именно код, оттранслированный ТУПОЙ машиной, а не человеком-насильником, машиной которая не способна на особо большее чем замена a := a+5 на a+=5 и эмуляцию вложенных ф-ций.  


Это сообщение отредактировал(а) Mayk - 1.4.2008, 20:48

еще раз: мы говорили о дельфи. А ты сравниваешь фронтэнд к компилятору Си с транслятором на Си. Ну ладно, если ты настаиваеш. 


поле 800х600 с анимацией (одна клетка-один аиксель). В ходе анимации суму времени расщета и отображения каждого кадра в текстовом виде пишем в файл. Потом сторонними средствами строим график по числам из файла и меряемся общей длительностью и графиком в целом.

подойдет?

я не пойму, вы компиляторы сравниваете или библиотеки? тогда можно рендеринг на DX сделать, победа у нас в кармане   

огранирчимся win32api (если речь именно о дельфи, то это логично). 

Maykу придется ставить вайн 

Йа бы предпочел чисто численные задачки. В них шума меньше. 


дельфи так сильно не дружит с opengl?   

хорошо. Тогда точный подщет количества простых чисел между n и m, когда они не влазят в типы данных, поддерживаемые процессором.

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