Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Религиозные войны > "Скорость" Delphi

Автор: Zmiy 22.3.2008, 22:28

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

Автор: kemiisto 22.3.2008, 23:22

Цитата(Zmiy @  22.3.2008,  22:28 )  Я слышал мнение, что Delphi генерирует довольно медленный код, медленнее, чем, например c++. Заявления такого рода не только безосновательны, но и не корректны. Какой компилятор Delphi имеется в виду (for Win32 или for .NET)? А какой компилятор С++?  Цитата(Zmiy @  22.3.2008,  22:28 ) Есть ли какие либо недостатки у Delphi по сравнению с C++ в этом отношении, насколько они критичны и можно ли их обойти? Если бы были серьезные недостатки, то на Delphi никто бы не писал. Взгляни хотя бы на кол-во тем в соотв. разделах форума. Добавлено через 8 минут и 33 секунды Цитата(Zmiy @  22.3.2008,  22:28 ) Я знаю один недостаток: в Delphi нет макросов, а это полезная штука. Да ладно уж недостаток. 3 года пишу на Delphi и ни разу потребности в макросах не испытывал. Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса?

Автор: CompWorm 23.3.2008, 00:15

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

Автор: Zmiy 23.3.2008, 00:27

Цитата(kemiisto @  22.3.2008,  23:22 ) Какой компилятор Delphi имеется в виду (for Win32 или for .NET)? А какой компилятор С++? Delphi под Win32 ( я на нём пишу), а с++ - любой  Цитата(kemiisto @  22.3.2008,  23:22 ) Если бы были серьезные недостатки, то на Delphi никто бы не писал. Взгляни хотя бы на кол-во тем в соотв. разделах форума. Я имею ввиду именно недостатки в отношении скорости выполнения получаемого кода. Речь идёт о реал-тайм приложениях (конкретно об играх). Цитата(kemiisto @  22.3.2008,  23:22 ) Чем она будет отличаться от макроса? скоростью Цитата(CompWorm @  23.3.2008,  00:15 ) поэтому программы дельфи не требуют ничего дополнительного и прекрасно идут на ВСЕХ компах.  А можно поподробнее? А программы на C++ могут не идти на всех компах?

Автор: CompWorm 23.3.2008, 01:25

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

Автор: ama_kid 23.3.2008, 07:57

Цитата(Zmiy @  22.3.2008,  22:28 ) Я слышал мнение, что Delphi генерирует довольно медленный код, медленнее, чем, например c++. Имхо, при современных производительностях компьютеров скорость выполнения кода на 99% зависит от радиуса кривизны рук программиста. Хотя чисто по привычке все системные приложения, не требующие GUI, пишу на С++ - но ради интереса один раз попробовал одно из них перевести на дельфи - никакой потери скорости (субъективно, конечно) не заметил, только размер исполняемого файла больше на порядок... Цитата(Zmiy @  23.3.2008,  00:27 ) А программы на C++ могут не идти на всех компах?  Если активно юзать CRT, например, то на компе без установленной библиотеки CRT - не пойдет...

Автор: Coder 23.3.2008, 08:49

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

Автор: kemiisto 23.3.2008, 10:42

Цитата(CompWorm @  23.3.2008,  00:15 ) на сколько я знаю, все языки в .NET стали неким единым болотом - нет разницы, программируешь ли на бейсике, си или дельфи в том числе (на NET имеется в виду) - все проги одинаково медленно работают. по идее, NET должна только тормозить работу программ.так ли это? Крайне неадыкватное представление о скорости исполнения MSIL-кода. Взгляните, например, сюда: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=gpp&lang2=csharp Как видите, C# (Mono) проигрывает С++ (GNU G++) в среднем в 2-2,5 раза. Такая разница некритична. И это реализация Mono, а не .NET. Мне кажется (утверждать не могу) C# (.NET) проиграет еще меньше.

Автор: Alexeis 23.3.2008, 12:34

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

Автор: lukas 23.3.2008, 16:23

я так скажу... .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 стоят в несколько раз дешевле...

Автор: Alexeis 23.3.2008, 17:08

Цитата(lukas @  23.3.2008,  15:23 ) я так скажу... .NET это виртуальная машина негрософт которая исполняет байт-код, обычно у байт-кода 1 команда = 1-2 командам асм... скорость выполнения .NET очень высокая для интерпретации... я бы сказал очень высокая   Не это не виртуальная машина, а компилятор времени исполнения, т.е. код компилируется при исполнении.  Вообще тема ушла в холивар, потому ее туда и переношу.

Автор: MAKCim 23.3.2008, 17:41

Цитата(lukas @  23.3.2008,  16:23 ) постепенно .NET внедрится в ОС и никаких библиотек не нужно будет, он станет куском ядра система...  если вы не имеете в виду управляемую ОС, то вы несете полную чушь

Автор: lukas 23.3.2008, 18:06

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

Автор: Alexeis 23.3.2008, 18:08

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

Автор: MAKCim 23.3.2008, 18:57

lukas,  ок Цитата(Alexeis @  23.3.2008,  18:08 ) Ну драйвера, и ядро по-любому будут нативными, а все остальное, прикладной интерфейс  API, сервисы всякие, оболочка, сопроводительный софт, утилиты... очень даже может быть я имел в виду не это

Автор: LSD 23.3.2008, 21:29

Цитата(Alexeis @  23.3.2008,  18:08 ) давайте для теста математический алгоритм. Реализуем его на вижуалке или делфях, а затем сравним. Есть такой алгоритм  Предлагаю реализовать игру жизнь.

Автор: Zmiy 24.3.2008, 01:21

Цитата(Coder @  23.3.2008,  08:49 ) Если, например, использовать тип string и функции pos, insert, copy, delete для парсинга большого текстового заковыристого файла ну, мы говорим не о строках, я имею ввиду оптимизацию, в основном, математических расчётов. С++ использует sse, inline функции, макросы. Вот я хотел бы понять, как на Делфи писать быстрый код без этого Цитата(Alexeis @  23.3.2008,  18:08 ) Zmiy, давайте для теста математический алгоритм. Реализуем его на вижуалке или делфях, а затем сравним. Отличная мысль! Сейчас подумаю над алгоритмом

Автор: Beltar 24.3.2008, 09:01

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

Автор: Lazin 24.3.2008, 09:35

Цитата(CompWorm @  23.3.2008,  00:15 ) я знаю одно могучее приемущество Delphi перед многими другими языками - компиллер всё необходимое запихивает в exe файл, поэтому программы дельфи не требуют ничего дополнительного и прекрасно идут на ВСЕХ компах.  неоспоримое приемущество программы на Delphi настолько суровы, что работают на Linux, Mac OS и даже Plan9    Цитата(kemiisto @  22.3.2008,  23:22 ) Да ладно уж недостаток. 3 года пишу на Delphi и ни разу потребности в макросах не испытывал. Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса? как всегда забавно читать о недостатках какого-то инструмента, то, что написано человеком, не владеющим этим инструментом ))) Цитата(Beltar @  24.3.2008,  09:01 ) Игры на Delphi действительно не пишут в частности из-за оптимизации, откуда там всяким SSE взяться, когда в VCL полно ассемблера. Не один компилятор сам не будет использовать SIMD расширения процессора, это всегда ложится на плечи программиста... а уж использовать SSE в коде GUI библиотеки (VCL) это нонсенс    Приемущество С++ в гибкости. Язык шаблонов в С++ Тьюринг полный, соответственно во время компиляции можно выполнить любые вычисления, например преобразовать число из бинарного представления можно с помощью этого шаблона Код     template <unsigned long N>     struct binary {         static const unsigned int value = (binary<N/10>::value << 1) | N%10;     };     template<>     struct binary<0> {         static const unsigned int value = 0;     }; const unsigned i = binary<00001111>::value; assert( i == 0x0f ); константа i будет вычислена во время компиляции, а не во время выполнения. Delphi так не умеет

Автор: Alexeis 24.3.2008, 10:18

Lazin, это не холивар о возможностях, а о скорости! Цитата(LSD @  23.3.2008,  20:29 ) Предлагаю реализовать игру жизнь.   Какие условия? Какое начальное состояние? Сколько ячеек? Какое графическое отображение? Сколько кадров в / сек? Чего можно юзать чего нет?

Автор: Lazin 24.3.2008, 10:44

Цитата(Alexeis @  24.3.2008,  10:18 ) это не холивар о возможностях, а о скорости! ну правильно, намного быстрее расчитать что-то в compile-time один раз, чем считать каждый раз в run-time

Автор: Coder 24.3.2008, 11:20

Цитата(Lazin @  24.3.2008,  18:44 ) ну правильно, намного быстрее расчитать что-то в compile-time один раз, чем считать каждый раз в run-time В таких случаях можно и в run-time одним разом обойтись.

Автор: Alexeis 24.3.2008, 11:43

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

Автор: kemiisto 24.3.2008, 11:55

Цитата(Lazin @  24.3.2008,  09:35 ) как всегда забавно читать о недостатках какого-то инструмента, то, что написано человеком, не владеющим этим инструментом ))) Ни слова о недостатках макросов я не произнес. Я действительно человек в C++ несведующий и посему задал конкретный вопрос: Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса? Я жду ответа...

Автор: Mayk 24.3.2008, 12:18

Цитата(Alexeis @  24.3.2008,  15:43 ) Ни как и ни на что это не влияет по скорости Шаблоны могут успешно inline'ится. это влиет на скорость в коде  наподобие Код std::sort( arr, arr+arrLength, Comparator() ); Если в дельфи понадобится отсортировать что-либо, она способна заинлайнить компаратор?  Или будет палить такты процессора на вызов ф-ций? Как в современном дельфи с этим дело обстоит? Добавлено @ 12:21 Цитата(kemiisto @  24.3.2008,  15:55 ) Ни слова о недостатках макросов я не произнес. Я действительно человек в C++ несведующий и посему задал конкретный вопрос: Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса? Я жду ответа... Вызов функции занимает >0 тактов. Расчёт ф-ции занимает >0 тактов.  В отличие от расчетов с помощью шаблонов. Которых во время run-time'а вообще нет. Хотя может оптимизатор дельфи и способен заменить вызов простых ф-ций на константы.

Автор: LSD 24.3.2008, 12:33

Цитата(Beltar @  24.3.2008,  09:01 ) Просто посчитать с начальной конфигурации координаты всех "животных" в поколении X? Да. Цитата(Alexeis @  24.3.2008,  10:18 ) Какие условия? Какое начальное состояние? Сколько ячеек? Какое графическое отображение? Сколько кадров в / сек? Чего можно юзать чего нет? Графики нет. Просто прочитать начальную конфигурацию из файла, просчитать 1 000 000 циклов, и записать конечное состояние в другой файл. Начальная комбинация скажем планерное ружье (чтобы было постоянное изменение). Размер скажем 100х100.  Начет того что можно использовать - о чем идет речь?

Автор: Lazin 24.3.2008, 12:38

Цитата(kemiisto @  24.3.2008,  11:55 ) Всегда можно написать функцию с нужным результатом действия обычно макросы не используют для того что-бы  что-то считать, для этого используют функции (компилятор С++ там где надо заинлайнит, а где не надо вызовет эту функцию). Макросы кроме как для условной компиляции использовать не стоит. Цитата(Alexeis @  24.3.2008,  11:43 ) Так что когда хвалишь скорость билдера не забывай чьи 90% заслуги там  smile .  Давно уже не пишу GUI приложения, так что    Цитата(Alexeis @  24.3.2008,  11:43 ) Константу можно любую забить и руками. а лучше пускай компилятор сам за меня считает, а если я где накосячил даст по рукам (пошлет на йух нескончаемой чередой сообщений об ошибках)    На С++ можно реализовать к примеру анализ размерностей, это когда у тебя есть переменная I значение которой выражено в амперах, и еще переменная U значение которой исчисляется в вольтах. И при вычислении выражения Код P = U*I; если тип переменной P - не мощность, то код просто не скомпилируется.    это всего лишь одно простейшее применение шаблонов если заглянуть в реализацию стандартной библиотеки, то можно много чего интересного увидеть

Автор: Beltar 24.3.2008, 12:51

В современном Delphi не хватает только шаблонов и не полностью реализована перегрузка операторов для Delphi 4 Win32. Inline, статич. члены класса появились скорее всего в D 2005. Цитата Всегда можно написать функцию с нужным результатом действия. Чем она будет отличаться от макроса? Макрос в Си++ это замена в исходнике одного текста другим, что исключает вызов ф-ии. Inline - подстановка в код тела ф-ии с той же целью. Тоже жду комментов, что лучше. Я не пишу на Си++, но примеры, "оптимизации" макросом после которой ошибку ищешь больше времени, чем этот макрос за все время эксплуатации софтины сэкономил, есть в любой книжке по плюсам. Цитата ак что когда хвалишь скорость билдера не забывай чьи 90% заслуги там Я сам как-то не интересовался, но мой знакомый пишущий на Builder'е, и для которого в Паскале тоже букофф много, говорил, что Билдер даже медленнее Delphi.   Цитата   Какие условия? Какое начальное состояние? Сколько ячеек? Какое графическое отображение? Сколько кадров в / сек? Чего можно юзать чего нет? Насчет графики я как-то не понимаю, как ее строить и не съест-ли она 99% ресурсов. Что тогда мерить? Да и интересует в первую очередь вывод конечной позиции, которая после нескольких десятков тысяч поколений м/б 3756x5667 клеток, или считаем, что поле ограничено? Цитата константа i будет вычислена во время компиляции, а не во время выполнения. Delphi так не умеет  Правда? И что же это при работе с API все охотно пишут: Код const   WM_MYMESSAGE=WM_USER+1;

Автор: Lazin 24.3.2008, 12:55

Цитата(Beltar @  24.3.2008,  12:51 ) Я сам как-то не интересовался, но мой знакомый пишущий на Builder'е, и для которого в Паскале тоже букофф много, говорил, что Билдер даже медленнее Delphi и HelloWorld на билдере больше весит чем на Delphi))

Автор: Beltar 24.3.2008, 12:58

Цитата пошлет на йух нескончаемой чередой сообщений об ошибках Я плакал со смеху, когда Microsoft Visual C++ в VS 2003 говорил мне, что Internal compile error и пошли вы к Билли, когда на самом деле был type mismatch.   Код var i:Integer       f:Float; begin i:=f;{В 99% случаев явно бредовый и неоднозначный (можно округлить, а можно просто отсечь дробную часть) код, который C++ считает вполне нормальным} end; PS Блин, не могу понять кайфа от расстановки этих фигурных скобок. Это же неудобно. Что бы наСИльники не говорили. Добавлено через 11 минут и 14 секунд Цитата Начальная комбинация скажем планерное ружье (чтобы было постоянное изменение). Размер скажем 100х100.  Сорри пока писал свой ответ, ваш появился. Планерное ружье просто генерит бесконечно планеры, которые, если я правильно понял, будут просто разбиваться о стенку. Можно взять, что-нить поинтереснее. Графику можно начальную фигуру мышкой по сетке набирать. В принципе при 100х100 можно попробовать вывести и конец.

Автор: kemiisto 24.3.2008, 13:10

Mayk, вот нашел: Цитата(Бьярн Страустрап. Введение в язык Си++) Следует заметить, что в C++ макросы гораздо менее полезны, чем в C, поскольку C++ имеет такие языковые конструкции, как const для определения констант и inline для исключения расходов на вызов функции. Возможность определения констант была в Delphi всегда, а директива inline - начиная с Delphi 2005. Выходит, можно обойтись без макросов?

Автор: Beltar 24.3.2008, 13:27

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

Автор: Lazin 24.3.2008, 13:57

Цитата(Beltar @  24.3.2008,  13:27 ) MS сказала: "Макросы - зло" ты наверное windows.h не видел    Цитата(kemiisto @  24.3.2008,  13:10 ) Возможность определения констант была в Delphi всегда, а директива inline - начиная с Delphi 2005. Не нужно путать С и С++, возможность определения констант в С++ то-же была всегда, а директива inline считается устаревший, так как решать что должно быть inline а что нет должен компилятор а не программист(хотя возможно Delphi программисты настолько могучи, что сами могут определить что должно быть inline а что нет  ). И вообще одна и та-же функция в одном месте может быть заинлайнена, а в другом нет, так что смысла в этой директиве нет))

Автор: Beltar 24.3.2008, 14:57

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

Автор: Lazin 24.3.2008, 16:02

Цитата(Beltar @  24.3.2008,  14:57 ) Не видел, (или видел, но было пофиг) но я не про него, а про .NET и в первую очередь C#. так ведь в С# есть препроцессор, очень похожий на Си-шный)))

Автор: AlexxxM 24.3.2008, 19:09

Цитата(Lazin @ 24.3.2008,  13:57) директива inline считается устаревший, так как решать что должно быть inline а что нет должен компилятор а не программист(хотя возможно Delphi программисты настолько могучи, что сами могут определить что должно быть inline а что нет  ). Все теперь только Copy/Paste    А я то наивный думал что именно программист и решает  Цитата что должно быть inline а что нет

Автор: MAKCim 24.3.2008, 19:18

Цитата(AlexxxM @  24.3.2008,  19:09 ) А я то наивный думал что именно программист и решает  пишите на ассемблере и решайте а если не хотите писАть на ассемблере, тогда не надо отбирать хлеб у компилятора подсказать ему можно, но конечное решение все равно остается за ним, т. к он в курсе контекста использования inline, а вы нет

Автор: CompWorm 25.3.2008, 21:17

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

Автор: Lazin 26.3.2008, 08:47

а что значит быстрее, и зачем тебе вообще нужна "скорость" вообще Delphi какой-то несексуальный, так что ну его в баню

Автор: JackYF 26.3.2008, 17:51

Цитата(Lazin @  24.3.2008,  12:57 ) а директива inline считается устаревший ух ты! а пруфлинк можно? CompWorm, ты что, до сих пор хочешь однозначный ответ? Типа там "Delphi круче С++, C# круче Delphi"?

Автор: bems 26.3.2008, 20:11

Цитата(Beltar @  24.3.2008,  12:58 ) Графику можно начальную фигуру мышкой по сетке набирать. В принципе при 100х100 можно попробовать вывести и конец тут нужно ждать мышку, а значит к скорости не имеет отношения. Фтопку графику. Давайте лучше так: Есть входной текстовый файл с начальным раскладом. Пробел - свободное место, конец строки в стиле DOS, все остальные символы - клетки. Размер поля определяется количеством строк и длиной самой длинной строки. Требуется написать нативную консольную прогу, которая должна спросить в консольном окошке количество поколений, вывести конечную ситуацию в выходной файл, и время которое занял ращет (без работы с файлами) в консольное окно. Максимальный размер поля 1000х1000, но ничего не мешает прогонять это потом на файлах меньшего размера (100х100 как вы хотели).  Если такое условие устраивает то давайте определимся как отмерять время - чтобы у всех были одинаковые погрешности. имхо для большого количества поколений разность двух GetTickCount вполне покатит.

Автор: Lazin 28.3.2008, 08:54

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

Автор: JackYF 28.3.2008, 13:54

Цитата(Lazin @  28.3.2008,  07:54 ) Герб Саттер, Новые сложные задачи.. Э нет. Мне в стандарте, пожалуйста

Автор: Mayk 28.3.2008, 21:39

Ради смеха сделал простую реализацию 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: Цитата(выдержка из life.fpc.bench) real 27.85 real 27.71 real 27.53 real 27.49 GPC: Цитата(выдержка из life.gpc.bench) real 19.94 real 19.29 real 18.76 real 18.72 а теперь внимание --- результат оттранслированного кода из паскаля в си Цитата(выдержка из life.p2c.bench) real 3.28 real 3.36 real 3.29 real 3.48 вывод: писать в юнихе на паскале -- не комильфо. проект полностью в аттаче вместе с бинарниками [правда бинарники там для amd64] зы. правдо замечу что сишный файл компилировался более свежим компилятором:  gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2).

Автор: Lazin 31.3.2008, 08:03

Цитата(JackYF @  28.3.2008,  13:54 ) Э нет. Мне в стандарте, пожалуйста Стандартом предусмотрено, что компилятор может применять любые оптимизации, которые не нарушают логику работы программы,.. собственно вот и все    Mayk, что и требовалось доказать   , правда FPC это не совсем Delphi, но думаю(хоть у меня на это и нет особых оснований) особой разницы не будет

Автор: Alexeis 31.3.2008, 10:12

Цитата(Lazin @  31.3.2008,  07:03 ) правда FPC это не совсем Delphi, но думаю(хоть у меня на это и нет особых оснований) особой разницы не будет    Зря думаешь! Доработал чуток проекты, чтобы они запускались под борландном, в результате на моем проце Sempron 2500+ под виндой Delphi 2007           ~19c Turbo C++ Builder ~20c Все скомпилено под релизом со всеми оптимизациями. на счет 3х секунд, я думаю там какой-то глюк, не может быть разница в 6 раз. Проект в атаче, проверяйте.

Автор: Lazin 31.3.2008, 11:37

на самом деле Си-шный исходник можно еще оптимизировать   , как минимум, перейти с индексов, на арифметику указателей скомпилил и запустил на своем компе сишный исходник: builder - 10969 (думаю(Alexis извини, я опять думаю  ), результат Delphi не будет сильно отличаться от этого) msvc - 3937 Добавлено через 1 минуту и 29 секунд "проблема" скорости Delphi - на самом деле - проблема компилятора, который уже очень давно не развивается

Автор: Mayk 31.3.2008, 11:43

Цитата(Alexeis @  31.3.2008,  14:12 ) на счет 3х секунд, я думаю там какой-то глюк, не может быть разница в 6 раз. ну если кто-нибудь сделает большую карту, то мы можем проверить результаты. учитывая разницу в два раза у Lazin'а Цитата(Lazin @  31.3.2008,  15:37 ) builder - 10969 ... msvc - 3937   выглядит возможным. Кстати. Alexeis, Lazin,  а можно выложить в дополнение скомпилированные бинарники?

Автор: Alexeis 31.3.2008, 12:07

Цитата(Mayk @  31.3.2008,  10:43 ) Кстати. Alexeis, Lazin,  а можно выложить в дополнение скомпилированные бинарники?   билдер синенький, делфи без иконки

Автор: Lazin 31.3.2008, 13:12

http://www.filefactory.com/file/7555a6

Автор: Alexeis 31.3.2008, 13:47

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

Автор: MAKCim 31.3.2008, 14:00

Цитата(Lazin @  31.3.2008,  11:37 ) как минимум, перейти с индексов, на арифметику указателей это за тебя компилятор сделает

Автор: Lazin 31.3.2008, 14:39

Цитата(MAKCim @  31.3.2008,  14:00 ) это за тебя компилятор сделает вот гад.. я что зря указатели в своих программах вместо индексов юзаю

Автор: JackYF 31.3.2008, 15:20

Цитата(Lazin @  31.3.2008,  07:03 ) Стандартом предусмотрено, что компилятор может применять любые оптимизации, которые не нарушают логику работы программы,.. собственно вот и все  smile Я про устаревание inline

Автор: Lazin 31.3.2008, 16:23

Цитата(Working Draft @  Standard for Programming Language C++ 7.1.2) The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be respected. ключевое слово здесь preferred    то есть в точке вызова компилятор возможно учтет твои пожелания, но не больше. другое дело, что тот-же Саттер не рекомендует использовать inline в своих программах, так как эта директива не несет никакой смысловой нагрузки. inline функция с точки зрения языка - такая-же как и не inline, в своем коде ты не можешь узнать как она объявлена, либо запретить получать ее адрес. к тому-же директива inline применяется при объявлении функции, а компилятор встраивает ее в точке вызова, то-есть в одном месте он может ее встроить, а в другом сделать вызов.

Автор: CompWorm 31.3.2008, 16:31

Цитата CompWorm, ты что, до сих пор хочешь однозначный ответ? Типа там "Delphi круче С++, C# круче Delphi"? smile JackYF, прочти внимательно мой вопрос.    я не сравниваю дельфи с другими языками - я конкретно довольно спросил ТОЛЬКО относительно дельфей. думаю, что люди, использующие дельфи на NET и без него хоть раз ставили эксперимент производительности.  я такой эксперимент поставить не могу, поэтому спросил. это повод для насмешек?

Автор: JackYF 31.3.2008, 19:02

Цитата(CompWorm @  31.3.2008,  15:31 ) JackYF, прочти внимательно мой вопрос. Давно уже. Это был ответ на один из постов в твоей теме, посмотри.

Автор: bems 31.3.2008, 23:07

Код 2.359 2.688 2.532 2.547 http://rapidshare.de/files/38984472/DelphiLife.rar.html

Автор: Alexeis 31.3.2008, 23:17

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

Автор: bems 31.3.2008, 23:18

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

Автор: Alexeis 31.3.2008, 23:42

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

Автор: bems 1.4.2008, 16:48

Цитата(Alexeis @  31.3.2008,  23:42 ) Или не обошлось без супер компьютера? P4 1.8 GHz 256M Цитата(Alexeis @  31.3.2008,  23:42 ) Какой результат по времени приведенных мною экзешников? Они не запустились - нехватает каких-то библиотек. Время работы  http://forum.vingrad.ru/index.php?showtopic=202042&view=findpost&p=1461595 на той же машине около 17 секунд Добавлено через 3 минуты и 57 секунд Цитата(Alexeis @  31.3.2008,  23:42 ) т.е. заоптимизировал все вручную  бОльшая часть эффекта, это оказ от процедур. Вероятно вижуалка действительно многое инлайнит, о чем насильники тут и говорили. И еще они были правы, когда утверждали, что дельфи-программеры умнее своего компилятора

Автор: Mayk 1.4.2008, 19:05

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

Автор: bems 1.4.2008, 20:12

Цитата(Mayk @  1.4.2008,  19:05 ) так как искать аналог сишных [стандартных кстати] clock() мне лень  не понял Цитата(Mayk @  1.4.2008,  19:05 ) DWORD'ы были заменены в случае gpc на integer, в случае fpc и p2c на int64 [чтоб указатель внутрь влез]. ты на 64? А какое ко всей этой информации имеет дельфи? И вообще на поле 10х10 письками меряться не интересно. Давайте увеличим сложность задачи и откажемся от всяких трансляторов (потому что программист и его компилятор едины ) По времени будем сравнивать то что написал пасквилянт на дельфи с тем что написал насильник на си.

Автор: Mayk 1.4.2008, 20:35

Цитата(bems @  2.4.2008,  00:12 ) ты на 64? ага. и на линухе. поэтому gettickcount'ы выкинуты. Цитата(bems @  2.4.2008,  00:12 ) И вообще на поле 10х10 письками меряться не интересно.  угу. давай чё-нить зубодробидельнее. что предлагаешь? Цитата(bems @  2.4.2008,  00:12 ) о. Давайте увеличим сложность задачи и откажемся от всяких трансляторов (потому что программист и его компилятор едины smile) По времени будем сравнивать то что написал пасквилянт на дельфи с тем что написал насильник на си. А вот тут нет. мы не откажемся от трансляторов даже если будем писать задачу целиком.  Потому что в этом то вся соль --- сейчас оттранслированный код на си получается не медленнее оригинального кода, написанного для паскаля  .  Причём именно код, оттранслированный ТУПОЙ машиной, а не человеком-насильником, машиной которая не способна на особо большее чем замена a := a+5 на a+=5 и эмуляцию вложенных ф-ций.

Автор: bems 1.4.2008, 21:05

Цитата(Mayk @  1.4.2008,  20:35 ) сейчас оттранслированный код на си получается не медленнее оригинального кода, написанного для паскаля еще раз: мы говорили о дельфи. А ты сравниваешь фронтэнд к компилятору Си с транслятором на Си. Ну ладно, если ты настаиваеш.  Цитата(Mayk @  1.4.2008,  20:35 ) давай чё-нить зубодробидельнее. что предлагаешь? поле 800х600 с анимацией (одна клетка-один аиксель). В ходе анимации суму времени расщета и отображения каждого кадра в текстовом виде пишем в файл. Потом сторонними средствами строим график по числам из файла и меряемся общей длительностью и графиком в целом. подойдет?

Автор: Lazin 2.4.2008, 08:07

Цитата(bems @  1.4.2008,  21:05 ) В ходе анимации суму времени расщета и отображения каждого кадра в текстовом виде пишем в файл. Потом сторонними средствами строим график по числам из файла и меряемся общей длительностью и графиком в целом. подойдет?  я не пойму, вы компиляторы сравниваете или библиотеки? тогда можно рендеринг на DX сделать, победа у нас в кармане

Автор: bems 2.4.2008, 16:42

Цитата(Lazin @  2.4.2008,  08:07 ) я не пойму, вы компиляторы сравниваете или библиотеки? тогда можно рендеринг на DX сделать, огранирчимся win32api (если речь именно о дельфи, то это логично).  Maykу придется ставить вайн

Автор: Mayk 2.4.2008, 17:15

Цитата(bems @  2.4.2008,  01:05 ) поле 800х600 с анимацией (одна клетка-один аиксель). В ходе анимации суму времени расщета и отображения каждого кадра в текстовом виде пишем в файл. Потом сторонними средствами строим график по числам из файла и меряемся общей длительностью и графиком в целом. подойдет?  Йа бы предпочел чисто численные задачки. В них шума меньше.  Цитата(bems @  2.4.2008,  20:42 ) огранирчимся win32api (если речь именно о дельфи, то это логично).  дельфи так сильно не дружит с opengl?

Автор: bems 2.4.2008, 17:36

Цитата(Mayk @  2.4.2008,  17:15 ) Йа бы предпочел чисто численные задачки. В них шума меньше. хорошо. Тогда точный подщет количества простых чисел между n и m, когда они не влазят в типы данных, поддерживаемые процессором. Цитата(Mayk @  2.4.2008,  17:15 ) дельфи так сильно не дружит с opengl? Дружит. Я имел в виду что поскольку дельфи есть только под виндой, то логично пользоваться родными виндовыми средствами.

Автор: Mayk 2.4.2008, 18:05

Цитата(bems @  2.4.2008,  21:36 ) хорошо. Тогда точный подщет количества простых чисел между n и m, когда они не влазят в типы данных, поддерживаемые процессором. При наличии http://gmplib.org/ это заведомый разгром дельфи.  Тем более что зная [примерное] кол-во простых чисел до n, это считается за 5 действий: m/ln m - n / ln n. точный же ответ  не расчитается и до обеда.

Автор: bems 2.4.2008, 18:35

Цитата(Mayk @  2.4.2008,  18:05 ) Тем более что зная [примерное] кол-во простых чисел до n, это считается за 5 действий: Ты его не знаешь, если сам не пощитаешь. А это та же задача но в меньших масштабах. И я говорил о точном значении. Цитата(Mayk @  2.4.2008,  18:05 ) точный же ответ  не расчитается и до обеда.  Ну дык вот где и будет что сравнивать. Цитата(Mayk @  2.4.2008,  18:05 ) При наличии gmp это заведомый разгром дельфи.  Ну или договоримся делать руками или предлагай другой тест.

Автор: Mayk 3.4.2008, 09:09

Цитата(bems @  2.4.2008,  22:35 ) Ну или договоримся делать руками или предлагай другой тест. Для того чтобы договорится делать руками надо договорится как это делать.  GMP ведь не из воздуха взялся   Цитата(bems @  2.4.2008,  22:35 ) Ну дык вот где и будет что сравнивать. Кстати, ты знаешь формулу для выявления простых чисел? А то боюсь памяти для решета Эратосфена может не хватить.  А использовать всяких Миллеров-Рабинов нельзя --- они вероятностные, что абсолютно недопустимо для точного решения.  http://mathworld.wolfram.com/AKSPrimalityTest.html Цитата(bems @  2.4.2008,  22:35 ) или предлагай другой тест. ну например расчитать $\int_a^b \frac{sin(x)}{x} dx$ методом нуу пусть трапеций, разделив участок на n частей. a,b,n задаются  во входном файле использовать ну пусть двойную точность. достаточно легко реализовывается.

Автор: bems 3.4.2008, 18:03

Цитата(Mayk @  3.4.2008,  09:09 ) $\int_a^b \frac{sin(x)}{x} dx$ не понял выражения. Можно это перефразировать в виде формулы, как ее пишут в третьем классе на доске? Цитата(Mayk @  3.4.2008,  09:09 ) во входном файле использовать ну пусть двойную точность хм... боюсь выглядеть совсем дураком, но на Си и 64 это что именно? в целом согласен

Автор: Void 3.4.2008, 19:44

Цитата(bems @  3.4.2008,  20:03 ) не понял выражения. Можно это перефразировать в виде формулы, как ее пишут в третьем классе на доске? Увы и ах, форумный движок не поддерживает формулы, но TeX все равно знать не помешает  Это интеграл от a до b sin(x)/x по dx.

Автор: Alexeis 3.4.2008, 20:00

Цитата(bems @  3.4.2008,  17:03 ) хм... боюсь выглядеть совсем дураком, но на Си и 64 это что именно?   Думаю имеет ввиду 8ми байтовый double

Автор: Zmiy 3.4.2008, 20:59

В общем, я понял, что Delphi оптимизирует код хуже, чем msvc. В частности, вычисления с плавающей точкой. Теперь меня больше интересует сравнение компиляторов Delphi и fpc. Так что теперь предлагаю сравнивать компиляторы c++, Delphi 2006 и FPC 2.2 Я тут придумал небольшой примерчик, он тупой, но содержит довольно много разнообразных вычислений. В тесте по 3м углам строится кватернион, из него вычисляется матрица, и её определитель. Скачать можно http://www.gamedev.ru/download/file.php?id=7087. Просьба потестировать на разных машинах. Можно перевести на с++, чтобы сравнить результаты. Мои результаты при значениях 1, 2, 3:  Core 2Duo 6700  delphi 2006 - 439 ms, Det = 1,00000023841858  fpc 2.2 - 391 ms, Det = 1,000000238  Pentium M 1.6 Ghz  delphi - 850-950 ms (странно, почему такой разброс?)  fpc - 660-850 ms

Автор: Isaev 27.8.2021, 23:51

У меня есть программка на си, которая выполняется за 15 мин, но если её собираешь с оптимизацией -O3 она выполняется 5 мин Перевёл её практически дословно на Делфи, она выполняется так же 15 мин Как добиться на дельфи результата 5 мин? Тут нет такого продвинутого оптимизатора)

Автор: _zorn_ 28.8.2021, 16:03

Цитата(Isaev @  28.8.2021,  06:51 ) Как добиться на дельфи результата 5 мин? Перестать писать на делфи ? ) ЗЫ. Аватарка знакомая, с кряклаба ?

Автор: Isaev 30.8.2021, 10:16

Цитата(_zorn_ @ 28.8.2021,  16:03) Цитата(Isaev @  28.8.2021,  06:51 ) Как добиться на дельфи результата 5 мин? Перестать писать на делфи ? ) ЗЫ. Аватарка знакомая, с кряклаба ?   ну это не профессиональный подход. то же самое, что посоветовать текст набирать не в notepad, а в notepad++ главное грамотно построить алгоритм, а среда не влияет, звязывайте холиварить уже ) //Я имею ввиду, если в си оптимизировать до состояния, что -O3 сильнее оптимизировать практически не сможет, то при переводе на дельфи будет примерно та же скорость. Но оптимизатор там классный, снимаю шляпу. Такого в дельфи нет, тут надо самому думать об оптимизации, т.к. встроенный почти ничего не даёт. зы: да, салют

Автор: irinazanuda 31.8.2021, 14:30

Что до сих пор выбираете?

Автор: LSD 1.9.2021, 01:26

Цитата(irinazanuda @  31.8.2021,  15:30 ) Что до сих пор выбираете? Ты намекаешь, что пора на ражавого перейти?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)