стоит ли использовать freepascal в приложениях требующих большой производительности? или стоит бросить эту затею и писать на сях?

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

Нормально там всё, для особой производительности используй встроенный ассамблер. Прожорливости памяти не наблюдал.

Приложения, требующие большой производительности, можно прекрасно писать и на Delphi и на FreePascal. Просто для этого надо обладать определенным запасом знаний о языке. Не думаю, что новичек в C++ качественно напишет высокопроизводительное приложение :)
Поэтому можно смело брать FPC и приниматься за дело.

поясню свои опасения, а вы скажите наскольно я прав (и почему) :)

размер EXE файла значительно превосходит Delphi'вый, а значит
1. он загрузится в память, а значит займет больше места в памяти (т.е. прожорливый)
2. больше кода - больше машинных кодов - больше тактов для вополнения этого кода (т.е. медленный)

> [3] ev   (19.01.05 09:39)
> размер EXE файла значительно превосходит Delphi'вый,

Значительно это как?

Глянь пример с мухами, там скомпилено (пример мухи) в Дельфи и во Фрипаскале, разница 12 килобайт, скорость одна и та же.

CyborgEngine2D
http://www.cyborghome.ru/index.php?&id=sources

> больше кода - больше машинных кодов - больше тактов для
> вополнения этого кода

Это не всегда верно ;)

2. больше кода - больше машинных кодов - больше тактов для вополнения этого кода (т.е. медленный)

Во-первых, вспомним, что exe содержит не только исполняемый код, но и ресурсы.
Во-вторых, не весь исполняемый код обязательно исполниться при запуске программы :)
В-третьих, FPC как и Delphi впихивает в код много лишнего.

Т.е. размер exe при сравнении C++ и FreePascal врядли можно связывать с производительностью.

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

А если разница в размере исполняемого файла стоит того, чтоб на нее обращать внимание, значит более серьезных требований (таких как производительность) нетути :)

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

всем спасибо за ответы...

у меня есть .ехе который весит чуть больше 600 мг. (на Visual FoxPro скомпилирован) работает мгновенно, так что нет смысла говорить о том что чем больше .ехе, тем больше памяти он требует и ресурсов процессора соответственно

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

> У тебя неверное представление о загрузке программ в Виндуос,
> они вообще не загружаются в память, а только мапируются.
> В память загружаются только нужные страницы и то временно.

Вот он большой фрипаскалевский экзешник ASPack'ом посжимает, и тю-тю маппинг

Хех, поставил себе лазарус 0.9.24 и сделал тестовый примерчик, одновременно и под делфи11 (2007). Ну на размере я останавливаться не стану, видел уже даже графики сферических коней в вакууме с пририсованными названиями про то, как в "настоящих больших приложениях лазарь обгоняет кайликс из-за меньшей скорости роста экзешника", демонстрирующие очередной раз, как силы добра (религиозных убеждений) побеждают силы разума.

Я создал пустую форму и поместил на неё кнопку, а в обработчик записал следующий код:
=== begin clipboard ===
procedure TForm1.Button1Click(Sender: TObject);
var
 i : integer;
 st, et : DWORD;
begin
 st := GetTickCount;

 for I := 0 to MAXINT do;

 et := GetTickCount;
 ShowMessage(IntToStr(et - st));
end;
=== end clipboard ===

Экзешник от Лазаря, что оригинальный 4-х метровый, что обстрипленный работает примерно в 9 раз медленнее делфёвого. Установка в делфях галочки "optimization" не помогла - всё равно она работает в 9 раз быстрее. Что я делаю неправильно и как мне тормознуть делфи?...)

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

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

Проверил ваш код по сравнению с delphi 6, результаты весьма близкие
Lazarus 48840
Delphi 46587
Так что по производительности вполне сопоставимо с delphi

Delphi стоит баснословно дорого(потому что у меня денег нет вообще), а lazarus(точнее отладчик GDB) в висте не работает. Всё никак не могу сделать так, чтобы работали одновременно бесплатные отладчики и виста(на данный момент дешевле из виндов ничего не шашел, тем более нужен DX10). А делать проги под висту на линуксе по мне так излишне, проще подождать новый GDB.
Как я понял, лишний размер берётся от того, что FPC ещё бесконечно сырой, и в целях упрощения себе жизни его разработчики пока этой проблемой не занимаются. Всё что можно сделать - strip и upx.
Разница в скорости вполне может быть и в 9 раз - всё зависит от конкретных настроек, лазарь в этм деле спец. может выдать код любой степени тормознутости, надо только пару флажков убрать/поставить :)

Nil  (28.11.07 02:50) [14]
Delphi стоит баснословно дорого

А что, разве Turbo Delphi (урезанный BDS2006) перестал быть бесплатным?