Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2005.06.06;
Скачать: CL | DM;

Вниз

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 пованивает лишней тратой ОЗУ и
> ресурсов проца... а смысл?

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


 
DrPass ©   (2005-05-19 00:39) [29]


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

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


 
AlterEgo of WondeRu ©   (2005-05-19 00:42) [30]

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

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


 
DrPass ©   (2005-05-19 00:43) [31]


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

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


 
Alex Konshin ©   (2005-05-19 00:44) [32]

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

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


 
DrPass ©   (2005-05-19 00:46) [33]


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

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

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

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


 
Eraser ©   (2005-05-19 00:57) [34]

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


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

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

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


 
Alex Konshin ©   (2005-05-19 00:57) [35]

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


 
VMcL ©   (2005-05-19 00:59) [36]

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

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

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


 
Eraser ©   (2005-05-19 00:59) [37]

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


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


 
Просто Джо ©   (2005-05-19 01:51) [38]


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


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

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

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


 
TUser ©   (2005-05-19 08:04) [39]

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


 
TUser ©   (2005-05-19 08:32) [40]

Вот на этом алгоритме 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.



Страницы: 1 2 вся ветка

Текущий архив: 2005.06.06;
Скачать: CL | DM;

Наверх




Память: 0.58 MB
Время: 0.057 c
1-1116870063
Masta Hookah
2005-05-23 21:41
2005.06.06
Извлечение 2-ух CD-приводов...


1-1116501791
Shredder
2005-05-19 15:23
2005.06.06
Преобразование: строка -> число


9-1110490520
SergeyR
2005-03-11 00:35
2005.06.06
User Interface


14-1116348987
___Nikolay
2005-05-17 20:56
2005.06.06
Для тех, кто разрабатывает сайты


3-1114444902
Jungle Forever!
2005-04-25 20:01
2005.06.06
DBGrid и unixtime