Free Pascal via Delphi

← →
Jeer © (2005-05-18 18:54) [0]

Вчера качнул fpc v.2.0 - солидный проект вырос.
И захотелось вновь вернуться к сравнению с Дельфи.
Несколько лет назад такое сравнение (с точки зрения оптимизации генерируемых приложений по быстродействию) было совсем не в пользу FP - он занял последнее место в ряду (Intel C, Watcom C, Borland C, Delphi 5, MSVC, FP).
Выложил первые результат на http://hlab.newmail.ru.
Эпизодически буду продолжать.
Почему Delphi 5 ?
Лицензионная и привык, устраивает.
Кто захочет может сгенерить на иных версиях и проверить.

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

← →
VMcL © (2005-05-18 19:00) [1]

>Free Pascal via Delphi

ФриПаскаль через Делфи? :o)

← →
Jeer © (2005-05-18 19:01) [2]

Ага :))

← →
pasha_golub © (2005-05-18 19:02) [3]

Я если честно не совсем понял результаты тестов. Чего меряем? Время али кол-во операций за еденицу времени... А тема интересна. Спасибо.

← →
uny © (2005-05-18 19:02) [4]

имхо 64 битные процессоры выйдут, fp на них подстроится, а дельфи нет, никакого через не получится

← →
Jeer © (2005-05-18 19:10) [5]

Измеряем время работы тестового алгоритма.
С целью исключения выбросов по времени делаются замеры из 11 главных циклов.
Внутри каждого главного идет рабочий цикл, число итераций подбирается по времени тестового цикла около 1 с
(снижается погрешность от квантованности (10-30 мс) на платформе Win до приемлимой величины).

Замеры из 11 циклов собираются в массив и определяется медина (сортировка и выбор среднего индекса) - этим значительно снижается влияние выбросов по времени.

Собственно, там исходники - все прозрачно.
Сейчас выложу dll - sysinfo.dll (сбор системной информации о платформе)
Забыл :)

← →
Jeer © (2005-05-18 19:11) [6]

uny © (18.05.05 19:02) [4]

мысль была - fp пророс сквозь delphi и значительно вырос.
Так вроде хотел сказать.

← →
VMcL © (2005-05-18 20:04) [7]

>>uny © (18.05.05 19:02) [4]

>имхо 64 битные процессоры выйдут

Почему выйдут? Уже вышли :-)

← →
uny © (2005-05-18 20:09) [8]

[7] VMcL © (18.05.05 20:04)
я всё жду когда будут регистры 64 бит(eax=32 бита, а например "super" eax=64 бита), может это называется иначе чем 64 битный процессор...

← →
VMcL © (2005-05-18 20:14) [9]

>>uny © (18.05.05 20:09) [8]

Уже есть. Athlon 64, например.

← →
Kerk © (2005-05-18 20:15) [10]

uny © (18.05.05 20:09) [8]

Насколько я понимаю, там архитектура и набор команд другие.. придется учить новый асм :)

← →
VMcL © (2005-05-18 20:17) [11]

>>Kerk © (18.05.05 20:15) [10]

У Athlon 64 - нет. Только расширили регистры (до 64 бит) плюс ввели 8 новых РОН. Я бегло мануал читал.

← →
DrPass © (2005-05-18 21:36) [12]

)
> Kerk © (18.05.05 20:15) [10]

У Пней - тоже. Intel взяла на вооружение 64-битную архитектуру AMD (для x86, конечно. Itanium не в счет

← →
Kerk © (2005-05-18 21:41) [13]

DrPass © (18.05.05 21:36) [12]
Itanium

Вот я как раз его имел ввиду :)
А АМД радует.. пасиб им :)

← →
Eraser © (2005-05-18 21:51) [14]

uny ©
имхо 64 битные процессоры выйдут, fp на них подстроится, а дельфи нет, никакого через не получится

Не беспокойся. Всё заменит .NET.

Я сам поначалу думал, что это очередная рекламная акция + красивые слова + большой пшик )...
а вот не так давно внимательно изучил, что нам готовит Longhorn... оптимизма поубавилось... там ВСЁ на .net завязано.

← →
AlterEgo of WondeRu © (2005-05-18 22:20) [15]

А когда будет компилятор делфовый для 64? или под .NET писать лучше, там вроде уже есть поддержка!

← →
Иван Шихалев © (2005-05-18 22:37) [16]

Какие ключи оптимизации использовались для FPC? А то ее можно и вовсе отключить...

← →
DrPass © (2005-05-18 22:56) [17]

> А когда будет компилятор делфовый для 64? или под .NET писать
> лучше, там вроде уже есть поддержка

Это виртуальная машина. Теоретически, виртуальная машина на 64-битном компьютере-носителе будет работать быстрее :) Но все равно, если речь идет о 64-битности как средстве увеличения производительности, любая виртуальная машина явно не к месту.

> вот не так давно внимательно изучил, что нам готовит Longhorn...
> оптимизма поубавилось... там ВСЁ на .net завязано

К счастью, не все идеи Microsoft оказываются принятыми рынком. Просчеты маркетологов и у них бывают. Нечасто, правда... но будем надеяться. Я бы не хотел такого будущего для индустрии

← →
AlterEgo of WondeRu © (2005-05-18 23:07) [18]

DrPass © (18.05.05 22:56) [17]
Но все равно, если речь идет о 64-битности как средстве увеличения производительности, любая виртуальная машина явно не к месту.

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

← →
DrPass © (2005-05-18 23:30) [19]

> С такой конструкцией особой разницы не почувствуешь!

А ты попробуй. Не по рекламным лозунгам, а на практике. В Java, кстати, уже давно есть такая же JIT-компиляция. Конечно, с ней быстрее, чем без нее :)

← →
AlterEgo of WondeRu © (2005-05-18 23:52) [20]

DrPass © (18.05.05 23:30) [19]
А ты попробуй. Не по рекламным лозунгам, а на практике. В Java, кстати, уже давно есть такая же JIT-компиляция. Конечно, с ней быстрее, чем без нее :)

делал на Делфи и на VS 2003 C#, рендеринг больших (оочень) файлов AutoCAD через OpenGL. Во втором случае, естественно, через Interop, так на .NET больше ФПС выдавала одна и та же картинка... Почему правда так и не понял: рендериг в основном состоял из команд OpenGL, но все же... результат есть результат! :)

Хотя, не спорю: компилятор, заточенный под конкретную версию процессора, будет быстрее работать, чем "универсальный" .NET

← →
DrPass © (2005-05-19 00:00) [21]

> Почему правда так и не понял: рендериг в основном состоял
> из команд OpenGL, но все же... результат есть результат!
> :)

Нууу... тут все-таки спасибо надо говорить неуправляемому коду ;-)

← →
VMcL © (2005-05-19 00:02) [22]

>>DrPass © (18.05.05 23:30) [19]

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

← →
Eraser © (2005-05-19 00:06) [23]

DrPass ©
К счастью, не все идеи Microsoft оказываются принятыми рынком. Просчеты маркетологов и у них бывают. Нечасто, правда... но будем надеяться. Я бы не хотел такого будущего для индустрии

Будем надеятся.
Это ж вообще хаос начнётся. Итак мы имеем по-существу два вида исполняемых модулей -- режима ядра и пользоваательского режима... и они эти режимы никуда не денутся, а появится ещё интерпритатор!

Получится такая схема:
основная часть ПО (прикладные задачи) - .NET
программы с необычными "недокументированными" возможностями - user mode.
волшебные программы - Kernel mode.

Эт конечно утрировано... но имхо так и будет... разрастаемся вширь.

← →
AlterEgo of WondeRu © (2005-05-19 00:12) [24]

DrPass © (19.05.05 0:00) [21]
Нууу... тут все-таки спасибо надо говорить неуправляемому коду ;-)

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

← →
AlterEgo of WondeRu © (2005-05-19 00:26) [25]

Eraser © (19.05.05 0:06) [23]
основная часть ПО (прикладные задачи) - .NET
программы с необычными "недокументированными" возможностями - user mode.
волшебные программы - Kernel mode.

а мне нравица такая схема!

← →
Eraser © (2005-05-19 00:28) [26]

AlterEgo of WondeRu ©

Если хорошенько про штудировать .net то имхо ничего страшного конечно нету...
но ИМХО сильно этот .NET пованивает лишней тратой ОЗУ и ресурсов проца... а смысл?

← →
AlterEgo of WondeRu © (2005-05-19 00:33) [27]

Eraser © (19.05.05 0:28) [26]
а смысл?

а нам смысл и не нужен :)))

Просто больно уж удобная технология! :) Я даже теперь VB.NET за гадость не считаю, все-равно тот же IL-код делает что и С# :)

← →
Agent13 © (2005-05-19 00:33) [28]

> но ИМХО сильно этот .NET пованивает лишней тратой ОЗУ и
> ресурсов проца... а смысл?

Заставить юзеров апгрейдить компы разумеется.

> VMcL © (19.05.05 00:02) [22]
> Насчет Java у меня сложилось впечатление, что полученный
> при компиляции байт-код интерпретируется Java-машиной. Поправьте,
> если неправ.

В Java 1.x так и было. Собственно говоря, байт-код и IL по сути одно и то же. В Java 2 байт-код компилируется JIT-компилятором в машинный код, так же, как это делает машина ДотНЕТ.

Итог
------------
Короче, все дружно читаем Рихтера (то что про дотНЕТ), забиваем на FreePascal и ложимся спать!)))

Всем, спокойной ночи!

> ИМХО сильно этот .NET пованивает лишней тратой ОЗУ и ресурсов
> проца... а смысл?

Смысл есть - сократить время выпуска программных продуктов. Не бесплатно, конечно, а за счет "некритичных" ресурсов - мощности ЭВМ. Не секрет, что ДотНЕТ предъявляет меньше требований к проффесиональным качествам программистов и упрощает сам процесс разработки. Другое дело - какой ценой...

VMcL © (19.05.05 00:02) [22]
>>DrPass © (18.05.05 23:30) [19]
Я не знаю точно, как Java, а в .NET IL-код компилируется в реальные команды процессора при первом обращении к методу (при последующих обращениях используется уже готовый машинный код). Насчет Java у меня сложилось впечатление, что полученный при компиляции байт-код интерпретируется Java-машиной. Поправьте, если неправ.

Уже сказали - Нормальные JavaVM давно умеют компилировать байт-код в машинный код на лету. Кстати, компилятор java в проекте GNU CC умел компилировать и в байт-код, и в машинный код, но я давно не смотрел на этот проект, не знаю, какая там сейчас ситуация.

> проффесиональным

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

> Всем, спокойной ночи!

Хорошая мысль ;-)

DrPass © (19.05.05 00:43) [31]
Не секрет, что ДотНЕТ предъявляет меньше требований к проффесиональным качествам программистов

Что-то незаметно.

и упрощает сам процесс разработки.

Ага! Кроме WinAPI (который вызывать стало очень гемморно) появилась куча разных надстроек над этим winAPI, хотя сам WinApi является надстройкой над NativeAPI... короче жирный и толстый стал виндовоз.

У кого ночь, а у кого и день.
Я требую продолжения банкета!

>>AlterEgo of WondeRu © (19.05.05 00:42) [30]

>Короче, все дружно читаем Рихтера (то что про дотНЕТ), забиваем на FreePascal и ложимся спать!)))

Не-е-е, хватит с меня ДотНета и на работе. Я уж лучше про ФриПаскакаль почитаю...

Alex Konshin ©
Я требую продолжения банкета!

Эт точно... надо пивка выпить )
http://delphimaster.net/view/14-1116391973/

> [35] Alex Konshin © (19.05.05 00:57)
> У кого ночь, а у кого и день.
> Я требую продолжения банкета!

Пиво в студию!

Всем хорош Сишарп, но верните народу деструкторы! 8-()

По сабжу: имелось в виду versus?

А какие опции оптимизации выставлялись у FP?

Вот на этом алгоритме FreePascal2.0.0 одназначно проигрывает по сравнению с Delphi7.
{$ifdef fpc} {$mode delphi} {$else} {$apptype console} {$endif} program FPTest; uses SysUtils, Classes, DateUtils; var T, _T: TDateTime; A: array [0..1000000] of integer; i: integer; function Get (Pos: integer): integer; function GetInt (S, E: integer): integer; var i, j, m, t: integer; begin i:=S; j:=E; repeat m:=(i + j) shr 1; while A[i] < A[m] do inc (i); while A[j] > A[m] do dec (j); if A[i] > A[j] then begin t:=A[i]; A[i]:=A[j]; A[j]:=t; end; until i >= j; if i > Pos then result:=GetInt(S,i) else if i = Pos then result:=A[i] else {i < Pos, and so j < Pos} result:=GetInt(j,E); end; begin result:=GetInt(low(A),high(A)); end; begin T:=now; _T:=now; Randomize; for i:=low(A) to high(A) do A[i]:=random(high(A)); writeln ("Array done for "+inttostr(MilliSecondsBetween(_T,now))+" msec"); _T:=now; writeln ("50000 element is "+inttostr(Get(50000))); writeln ("50000 element found for "+inttostr(MilliSecondsBetween(_T,now))+" msec"); writeln; writeln ("Total time is "+inttostr(MilliSecondsBetween(T,now))+" msec");; end.

PS. Мне хотелось протестировать рекурсивные алгоритмы, по результатам - Delphi быстрее раза в 2. А заполнение массива на FP вообще очень медленное - из-за функции Random.

Free Pascal via Delphi Найти похожие ветки