freepascal.ru

Для примера.
Я делаю код:

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

var
  n, m: integer;

  procedure MyProc(zzz: longword);
  begin
  ...
  inc(n);
  inc(m);
  end;

begin
  ...
  n := 1;
  m := 4;
  MyProc(5);
  MyProc(67);
  MyProc(55);
  MyProc(66);
  MyProc(45);
  ...
  MyProc(33);
  ...
end;

Решил его оптимизировать:

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

var
  n, m: integer;
  iArr: array[1..40] of byte = (5, 67, 55, 66, 45, 64, ..., 33);

  procedure MyProc(zzz: longword);
  begin
  ...
  inc(m);
  end;

begin
  ...
  m := 4;
  for n := 1 to 40 do
    MyProc(iArr[n]);
  ...
end;

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

Добавлено спустя 4 минуты 51 секунду:
Мне теперь что, все данные делать внешними, чтоб точно знать, что они места занимать не будут?

Добавлено спустя 36 минут 5 секунд:
инициализировал массив вручную... размер программы стал меньше... Причём без разницы как инициализирую, массив байт или массив LongWord.
что за бред творится?

Добавлено спустя 3 минуты 15 секунд:
Делаю проверки на Linux.

Возможно, при добавлении массива в исполняемом файле создаётся секция с данными, которая сразу занимает минимум 1 страницу вне зависимости от размера самих данных.

Возможно. Но при попытке вынести даже в уже готовый блок, положение ещё больше усугубляется.

Добавлено спустя 6 часов 20 минут 41 секунду:
На Windows оптимизация работает. Очередная проблема в Linux. С чем она связана?

Скомпилял в линуксе твои примеры в рабочем виде:

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

    var
      n, m: integer;

      procedure MyProc(zzz: longword);
      begin
    //  ...
      inc(n);
      inc(m);
      end;

    begin
  //    ...
      n := 1;
      m := 4;
      MyProc(5);
      MyProc(67);
      MyProc(55);
      MyProc(66);
      MyProc(45);
   //   ...
      MyProc(33);
   //   ...
    end.


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

var
  n, m: integer;
  iArr: array[1..6] of byte = (5, 67, 55, 66, 45, 33);

  procedure MyProc(zzz: longword);
  begin
  //...
  inc(m);
  end;

begin
// ...
  m := 4;
  for n := 1 to 40 do
    MyProc(iArr[n]);
// ...
end.


Второй пример на несколько байтов даже короче. А после компиляции с оптимизацией:

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

fpc 1.pp -XX -CX

на 12 байт длиннее. Компилятор 3.0.4, пересобранный для древнего линукса.

Добавлено спустя 20 минут 36 секунд:
Но в файловом менеджере показ длины второго нептимизированного бинаря подглючивал, пока несколько раз не обновил каталог. Но это не проблема паскаля, тут так работа с ФС подглючивает, в винде у NTFS глюки другие.

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

RRYTY писал(а):надо оптимизацию отключать

надеюсь ты прикалываешься?! Оптимизация для того и служит, чтоб оптимизировать код.
Да, известно, что зачастую оптимизация не даёт уменьшение кода, потому что она может разворачивать циклы и что-нибудь подобное. Но здесь речь о массиве. О последовательности байт, которые занимают определённое пространство. Чтоб загрузить данную последовательность, достаточно указать кусок памяти и записать туда данные из загружаемого файла. Причём загрузка с уверенностью на 99% уже реализована лет двести назад. )))

Я проверил программу, и когда в массиве будет больше (примерно) 90 элементов, то программа будет меньших размеров. Не очень радостная новость... потому что мне надо меньше 50-ти... Объявлять для этого массив на 90 байт? ))) Прикольно.
Исходник скидываю, количество элементов можно подправить.

Seenkao
Свои рассуждения оставь до момента когда напишешь свой компилятор.
А пока ты пишешь на языке высокого уровня, тут байты считает компилятор - он в этом умнее тебя. Не нравится - учи на ассемблер

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

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

{.$Define TEST_OPTIMIZED}         // optimized off

и

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

{$Define TEST_OPTIMIZED}         // optimized off

составляет 0.8КиБ а с умной линковкой - 0.1КиБ Это вообще мелочи на грани статистической погрешности. Лазарусу для своих нужд нужна куча хрени при компиляции, а без неё прирост мизерный - 80 байт при умной линковке Бинарь на 26 кило без внутренней оптимизации подрастает на 80 байт...

Добавлено спустя 11 минут 14 секунд:

Seenkao писал(а):Я проверил программу, и когда в массиве будет больше (примерно) 90 элементов, то программа будет меньших размеров. Не очень радостная новость... потому что мне надо меньше 50-ти... Объявлять для этого массив на 90 байт? ))) Прикольно.
Исходник скидываю, количество элементов можно подправить.

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

zub, с такими высказываниями, мне проще тебя послать куда подальше. Я наверно тебя удивлю, но ассемблер я начал изучать раньше чем паскаль. Но ты видимо уже забыл те времена. Пользуйся тем, что дают, раз тебя всё устаивает. Когда оптимизация для Windows работает, а на другие ОС может вообще не распространяться.

Если я пишу про Linux, это не означает, что на Android, iOS и другие ОС (исключая Windows) оптимизация будет работать.

Сквозняк писал(а):В большой программе всё равно будет куча массивов и хз чего

Сквозняк писал(а):А ты на такую языковую фичу 90 байт пожалел...

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

Результат? )))

Сквозняк писал(а):составляет 0.8КиБ а с умной линковкой - 0.1КиБ

на ассемблерный код взгляни и попробуй массив увеличить. У меня в 4 КБ разница, при 100 элементах и когда код оптимизирован через массив (в пользу программы с массивом). Версия FPC у тебя какая? 3.0.4? Попробую, может там этой оптимизации нет ещё.

Seenkao писал(а):теперь прочитай свои слова под таким углом. ))) Сотни массивов, тысячи данных, которые ни сколько не оптимизированы.

Результат? )))

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

Seenkao писал(а):Версия FPC у тебя какая? 3.0.4? Попробую, может там этой оптимизации нет ещё.

У меня не просто 3.0.4 а собранная на старом линуксе (скачанная с соурцефорге собранная версия в том линуксе конечно же не работает, потому что в ней другой тип бинарей), что автоматически затачивает паскаль на делание бинарей старого типа, которые были до третьей версии fpc. В новых версиях fpc тип создаваемых бинарей зависит от того, где собран компилятор, если в старых линуксах, то там автоматически врубается совместимость со старым типом бинарей.

Сквозняк писал(а):Тут не всё так однозначно. Массивы бывают разных типов, а ещё есть непрерывность блоков в памяти и работа с несколькими менеджерами памяти... Задолбаешься всё это оптимизировать чтобы несколько десятков байт сэкономить. Возможно следовало из всех типов массивов вычленить самый простой тип с небольшим размером и персонально его оптимизировать - улучшить один частный случай, который часто случается. До самой такой постановки задачи могли просто не додуматься, или её не записать и забыть.

я как раз об этом речь и веду, что оптимизации на маленькие массивы не работает. А это не малая часть программы, особенно для больших программ. И такие вещи могут "засирать" программу пустым местом.

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

У тебя же создаётся промежуточный ассемблерный файл, расширение .a, на нём посмотри, что с кодом.

Tango писал(а):.a

только с расширением .o )))
эта проблема пока появлялась только когда один массив и маленький. Дальше проблема "исчезает" при нескольких массивах или масиве достаточно большом. Видимо компилятор что-то там себе сам решает.

Если встретиться проблема с множеством массивов, то надо будет смотреть что происходит.

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