Free Pascal быстрее Си

[Seenkao]

SSerge, ответ мой вполне конструктивен!
Да было бы неплохо, произвести на каждом отдельном компиляторе тесты, но я этим заниматься не буду. Меня вполне устраивает, то как можно уходить от ненужных библиотек или брать нужный из них код, в крайнем случае можно просто вставить ассемблерный код.

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

большинству просто наплевать...

[iskander]

Да было бы неплохо, произвести на каждом отдельном компиляторе тесты, но я этим заниматься не буду.

Да базара нет, пацан сказал, пацан сделал.
А за каким тогда топик захламлял? Для жалоб на несовершенство мироздания есть раздел "Потрепаться".

[Seenkao]

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

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

Хочешь проверить компиляторы?! Вперёд! Дерзай! Я не буду тратить на это время, но этого, видимо, кто-то не понимает.

[iskander]

Ну да, совсем забыл что тролля кормить не следует.

[iskander]

Просто оставлю это здесь.

[Seenkao]

Перечитал... Как же вы любите перевирать чужие слова.

Бестолково на разных компиляторах под разными IDE сравнивать какой код быстрее, если вызываются внутренние библиотеки.

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

Seenkao
>> не используют ни каких библиотек
>> В противном случае, любая вызванная библиотека может утащить на себя тонну времени.

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

Не хотите мне объяснить, куда вы слово ВНУТРЕННИЕ подевали? Не вырывайте цитату из контекста, пожалуйста, а указывайте полностью фразу, тогда вам самим будет понятно о чём ведётся речь.

[Kopa]

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

В тестах не тестируется printf а только используется для вывода результата теста (т.е. время его выполнения в нормальном тесте пренебрежимо мало, по сравнению с основным телом теста)

Вы серьёзно? Вы не умеете всё делать вручную? Я бы вам посоветовал изучать ассемблер и сделать на нём банальное окно, без библиотек.

В Fasm вроде не особо сложно и даже на нём сделана целая ОС в размере дискетки - KolibiOS.

P.S. На Forth (Форт) особенно интересно выглядит программирование для ОС и различного железа,

[runewalsh]

Тред не читал, по теме, вынесенной в заголовок:

Я недавно пробовал «в лоб», полностью дословно, перевести библиотеку LodePNG на Free Pascal (1-я картинка). Декодирование PNG работало до 20% быстрее C-версии, правда, кодирование — до тех же 20% же медленнее. Так что, думаю, можно считать, что у Си и Паскаля плюс-минус (правда, в широких пределах) паритет. Надо отметить, что использованным мной MSVC занимается целая корпорация, а Free Pascal — три калеки.

Результат очень странный, т. к., по моим наблюдениям, Free Pascal всё-таки жутко тупой в плане генерируемого кода. Например, если 5 раз подряд читается поле объекта, без вызовов функций между ними и без записей по другим указателям — он не моргнув глазом сгенерирует 5 обращений к памяти. C-компиляторы такое легко оптимизируют.

Впрочем, позже я внёс собственные оптимизации (2-я картинка), т. к. у автора полно глупостей, и, как закономерный итог, понял, что библиотека в принципе ужасная с точки зрения производительности (она и во всех бенчмарках в интернете стабильно плохо себя показывает) и механизма работы (требует загрузки всего файла в память), проще руками сделать человеческий аналог libpng поверх настоящей zlib. Так что, может, вместо неё как-нибудь на досуге переведу и сравню zlib или Zstandard. :)

w65vkeccW-w.jpg

KKvK_QxHJCk.jpg

[скалогрыз]

и сравню zlib

paszlib это как раз перевод zlib-а версии 1.1.7 или как-то так... ну что-то очень древнее и бородатое.

[runewalsh]

ну что-то очень древнее и бородатое

Вот-вот. Для той же zlib кто-то чё-то делает на тему zlib-ng. (Но она мне нужна только для совместимости с тем, что её использует, в частности, для PNG. Если не принципиально использование zlib, Zstandard ГОРАЗДО круче.)

Ну и, если не «дословно для сравнений», мне нравится переделывать дословный вариант на его аналог на записях с методами (не классах), т. е.

Код: Выделить всё

procedure cpk_init(var cp: chupakabra);
procedure cpk_do_something(var cp: chupakabra; param: cint);

↓

Код: Выделить всё

type
   Chupakabra = record
      procedure Init;
      procedure DoSomething(param: cint);
   end;

Это должно быть во всём, кроме удобства использования, эквивалентно оригиналу. Кроме того, используя record'ы как пространства имён с class static-функциями, можно упихнуть всё в один файл, оставив некофликтующим друг с другом, читаемым и поддерживаемым :).

[скалогрыз]

Это должно быть во всём, кроме удобства использования, эквивалентно оригиналу

и цитата выше:

Free Pascal всё-таки жутко тупой в плане генерируемого кода.

держим кулачки, чтобы компилятор не начал тупить с advanced record-ами.

Кроме того, используя record'ы как пространства имён с class static-функциями, можно упихнуть всё в один файл, оставив некофликтующим друг с другом, читаемым и поддерживаемым .

а с обычными процедурами разве есть конфликты?
на сколько я понимаю, "классическая разбивка на inflate/deflate" связана с просто с разделением задач: упаковка отдельно, распаковка отдельно.
Тогда утилита, которая занимается только распаковкой данных, не будет обременена лишним кодом.

[runewalsh]

держим кулачки, чтобы компилятор не начал тупить с advanced record-ами.

Конкретно с этим он не тупит, бинарной разницы между методом объекта и обычной процедурой с первым параметром «var self» нет. Я сейчас попробовал сделать две процедуры, статическую с var-параметром и метод без параметра —

Код: Выделить всё

type
   MyRec = record
      msg: string;
      class procedure PrintMsgStatic(var t: MyRec); static;
      procedure PrintMsg;
   end;

   class procedure MyRec.PrintMsgStatic(var t: MyRec);
   begin
      t.PrintMsg;
   end;

   procedure MyRec.PrintMsg;
   begin
      writeln(msg);
   end;

— и работа PrintMsgStatic сводится к немедленной передаче управления PrintMsg, даже без перекладывания регистров. То есть они буквально во всём, кроме внешности, скорее всего, полностью эквивалентны. Кроме того, с какой-то (~3.0) версии компилятора class static-процедуры совместимы с обычными (не «of object») процедурными указателями по присваиванию. (Но они и до этого были совместимы бинарно, поэтому можно было привести насильно.)

а с обычными процедурами разве есть конфликты?

Ну тип в Си static-процедуры локальны для .c-файла. Вряд ли прям конфликты будут часто встречаться (т. е. даже локальные функции в разных файлах редко называют одинаково... хотя именно что «редко», а не «никогда»), но как тематическое разделение механизмом, альтернативным механизму модулей, удобно: процедуры внутри одного record'а могут вызывать друг друга без префиксов, внутри record'а можно, совсем как в модуле, объявить вложенные type/const/etc., опять же, доступные методам record'а без префикса, и всё такое.

на сколько я понимаю, "классическая разбивка на inflate/deflate" связана с просто с разделением задач: упаковка отдельно, распаковка отдельно.
Тогда утилита, которая занимается только распаковкой данных, не будет обременена лишним кодом.

Не только, там отдельные модули для подзадач inflate/deflate (генерации деревьев и т. д.). Это удобно разработчику самой библиотеки, но вообще-то не очень удобно для её пользователя — в том числе по этой причине финальный результат иногда склеивают в один файл, как SQLite amalgamation.

Неиспользуемый код будет полностью выброшен, вот прям будто его и не было, так что весь оверхед в скорости компиляции частей, которые заведомо не понадобятся. Правда, не знаю, этим занимается компилятор сразу, увидев, что не было обращений к членам типа — идеальный вариант, или линковщик — тогда это не очень приятно, но какая разница. Для LCL-классов, например, этого не делается только потому, что они скомпилированы с RTTI ({$M+} / {$TYPEINFO ON}), которая предполагает, что методы могут, например, быть вызваны по имени, поэтому их, а за ними и всё, что они используют, выбросить низзя.