Производительность программ на fpc

[Юра]

Да, прошу прощения, повёлся на слухи в форуме.
Кстати, а если оптимизированное дерево сохранить в файл, то на целевой машине можно будет докомпилировать его под целевой процессор? Или потребуются дополнительные данные?
Или просто размер такого файла будет неприемлем?

Можно все Но целесообразности в этом нет. Лучше уж тогда генерить некий Р-код, специально оптимизированный под быстрый перевод в машинный код на конечной платформе.

При желании можно сделать, чтобы компилятор генерил Р-код для .NET или для Java или еще для чего-то...

Поэтому в FPC и сделана 2х фазная компиляция:
1. Исходник представляется в виде дерева элементарных функциональных блоков (nodes).
2. Затем генерится код при помощи подключаемых модулей для каждого процессора.
В качестве подключаемого модуля может быть все что угодно. Генератор машинного кода, Р-кода, итд...

[ZerstoreN]

я вот тут пытался юзать fixedpoint 64 бит (на 32 битном процессоре правда) и работает в 2 раза медленнее чем с double....

[alexs]

Никакой промежуточный код в FPC не создается. Из pascal исходника создается дерево структурных элементов, над которым можно проводить действия (например, общую оптимизацию), независимые от целевого процессора. Потом на основе этого дерева генерится целевой процессорный код. После этого проводится оптимизация кода для целевого процессора.

Никакого Р-кода, естественно, нет.

1. Приведённая тобой цитата - не моя
2. Когда я говорил про p-код - я говорил про машину Вирта, а не про FPC -моя мысль была в том что MS NET - это полностью содранная у Вирта технология паскаль машины
3. Кстати - мне кажется несколько проблемотичным будет вопрос правильной оптимизации под любой процессор - пока все программы пишутся слишком с привязкой к конкретной архитектуре (это не упрёк команде FPC - это упрёк всем программерам-прикладникам) - очень часто мы завязываемся на всякие условности (int - 32 бита) и т.д. - тут нужна ломка стереотипов и принципов работы с данными.

[ZerstoreN]

тут нужна ломка стереотипов и принципов работы с данными

понимаете, например, с числом single время в сэмплах для аудиоданных с разрешением 192000 можно точно посчитать в пределах +-320 секунд, а с даблом можно больше но то же, точность разная в зависимости от близости числа к 0 (собственно это основной недостаток и приимущество экспоненциального формата). а с помощью длинного fixed point можно посчитать много, но не очень быстро. так в результате ломки стереотипов получится убогие по возможностям, но красивые по архитектуре программы.
ps: а можно хранить числа в строках и делить столбиком (не смейтесь, за этим будущее)

[Replicator]

(это не упрёк команде FPC - это упрёк всем программерам-прикладникам) - очень часто мы завязываемся на всякие условности (int - 32 бита) и т.д. - тут нужна ломка стереотипов и принципов работы с данными.

Когда я работаю с IP-адресами (например, писал прогу рассчета диапазонов), то мне удобно хранить IP в cardinal, при этом точно зная, что он именно 4 байта, одновременно ассоциировав переменную с массивом из 4 чисел типа byte, которые, соответственно, занимают 1 байт.

Да, на 64-битных процессорах программа будет работать уже неверно, так как cardianl там, вероятно, 8 байт. Однако пример показывает, что переменные фиксированного размера иногда очень удобно использовать.

Другой пример, структуры, которые напрямую записываются в файлы, имеющие строгий формат. Например, при работе с форматом WAVE (столкнулся, когда писал программу звукозаписи), приходится отправлять в файл т.н. чанки - записи, содержащие частоты и др. параметры звука. Если такая запись окажется не того размера, то вместо разговора, мы услышим хз что.

С другой стороны, если мы хотим настоящей кросс-компиляции, то либо мы должны смириться с тем, что мы не знаем, какой размер занимает та или иная переменная, либо разработчики компилятора должны фиксировать размеры переменных раз и навсегда (как это сделано в Java). А при изменении разрядности процессоров, во втором варианте можно просто вводить новые типы данных (например, integer -> int64 -> int128 и т.д.).

Так что еще неизвестно, кому это упрек.

[Matich]

А как же типы данных:

byte, word, dword и qword ?

Они вроде одинаковы на всех платформах, или я чего-то не догоняю?

[Sergei I. Gorelkin]

Есть типы данных, одинаковые всегда и везде, а есть зависящие от платформы. Тот же Integer, например, даже на одной и той же платформе в режиме TP 16-битный, а в режиме OBJFPC становится 32-битным.

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

[Replicator]

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

Что касается, скажем, Borland Pascal и даже Delphi, то в любом учебнике сказано, что "этот тип занимает столько-то, а вот этот тип - вот столько". Так что какая тут переносимость... И в этом плане alexs абсолютно прав.

Лично мне бы показалось логичным введение типов данных двух разновидностей:

• с фиксированным размером, например byte, word, dword, qword;
• с "плавающим" размером, например integer, cardinal, real.

[SovNarKom]

Ну так... эээ... они введены давно=)

[alexs]

мне в плане объявления типов данных нравится ADA - по моему вот такой стиль можно было бы ввсти и в fpc

[SovNarKom]

из оф. доков.

Table 3.2: Predefined integer types

Type Range Size in bytes
Byte 0 .. 255 1
Shortint -128 .. 127 1
Smallint -32768 .. 32767 2
Word 0 .. 65535 2
Integer either smallint, longint or int64 size 2,4 or 8
Cardinal either word, longword or qword size 2,4 or 8
Longint -2147483648 .. 2147483647 4
Longword 0..4294967295 4
Int64 -9223372036854775808 .. 9223372036854775807 8
QWord 0 .. 18446744073709551615 8