freepascal.ru

Заглянул внутрь исходников компилятора из git и многое там поисследовал/изменил. Из всего многого пока увидел несколько однозначных моментов.
Только ли на моей машине замена функций преобразования регистра на такие работает быстрее ? Если не только можно на них заменить.
В оригинале там ряд функций в основе ктоторых лежит предзаполненный массив из которого затем выбирается готовое значение.
Для вариантов функций с одним символом выигрышен текущий вариант с предзаполенным массивом, но используются ли эти варианты функций по факту ?
Если нет можно удалить их вообще и переменные/функции предзаполнения.
Однозначнее другое: если не использовать эти функии вообще - совсем быстро. И это там тоже есть.
Несколько массивов можно заранее перевести в верхний регистр и при загрузке компилятора не переводить всякий раз.
Также было использование одного .inc файла даажды в разные пременные первую из которых можно просто удалить.

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

function upper(const s : string) : string;
var
i  : longint;
begin
upper := s;
for i:=1 to length(upper) do
if (byte(upper[i]) > 96) and (byte(upper[i]) < 123) then Dec(upper[i],32);
end;
               
procedure uppervar(var s : string);
var
   i : longint;
begin
for i:=1 to length(s) do
if (byte(s[i]) > 96) and (byte(s[i]) < 123) then Dec(s[i],32);
end;

function lower(const s : string) : string;
var
   i : longint;
begin
lower := s;
for i:=1 to length(lower) do
if (byte(lower[i]) > 64) and (byte(lower[i]) < 91) then Inc(lower[i],32);
end;

Я последнее время люблю таким развлекаться, вот эта штука ускорит компилятор на 50% (ладно, чаще на 0,1%, что тоже неплохо) лет через 15, когда её наконец заметят, вот это должно, помимо ускорения компиляции на 0,5%, заметно сокращать потребление памяти (см. комментарий), а вообще все мои предложения, вместе взятые (ни одно не принято, но много они понимают...) стабильно уменьшают время компиляции моей программы в первой цифре после запятой.

ВО-ПЕРВЫХ, у меня твои функции работают вдвое медленнее табличных.

ВО-ВТОРЫХ, в ходе 5,5-секундной компиляции моего приложения компилятор вызывает upper(shortstring) 250 тысяч раз, суммарно занимающих 2,5 мс (10 нс/вызов), и lower(shortstring) 27 тысяч раз, суммарно занимающих 1,2 мс (45 нс/вызов), остальные ещё меньше. Ускорив их в два раза (это нереально), ты ускоришь всю компиляцию на 0,03%, такой себе потенциал.

runewalsh писал(а):лет через 15, когда её наконец заметят, вот это должно, помимо ускорения компиляции на 0,5%

чё-т я не понял... а почему бы тебе свои дистрибутивы пропатченные fpc не выкладывать?!

Ускорение на пару процентов этого не стоит, и я просто развлекаюсь...

> Я последнее время люблю таким развлекаться, вот эта штука ускорит компилятор на 50%

Это правильная тема. Попробую этот патч.

> Ускорение на пару процентов этого не стоит,

Стоит. Выигрыш - это не проигрыш.

> у меня твои функции работают вдвое медленнее табличных.

Какой процессор ? Я сейчас проверил на Интеле, там медленнее получилось. А на АМД быстрее.
Выигрыш на:

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

first@my:/proc$ cat cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 255 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3100.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
bogomips        : 6227.07
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

processor       : 1
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 6
model name      : AMD Athlon(tm) II X2 255 Processor
stepping        : 3
microcode       : 0x10000c8
cpu MHz         : 3100.000
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate vmmcall npt lbrv svm_lock nrip_save
bugs            : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2
bogomips        : 6227.07
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 10


Alexander писал(а):Я сейчас проверил на Интеле, там медленнее получилось. А на АМД быстрее.

Для комплектности надо бы ещё проверять на каком-нибудь клоне ARM, благо у них разброс в гигагерцах и встроенных кэшах не столь большой как у вышеупомянутых...

> клоне ARM,

ARM не выпускается сейчас на платах в стандарте ATX. Или уже выпустили ? Правда квантовые уже на подходе: https://www.ixbt.com/news/2021/11/15/pr ... agle-.html

Собственно то, о чём я говорил про "резку" ФПЦ. Уменьшенная промежуточная исследовательская версия (не предназначена пока для использования).
Но если
http://soft.self-made-free.ru/mini20220325_188.txz
ещё более-менее компилирует, то
http://soft.self-made-free.ru/mini20220325_483.txz
урезана гораздо больше и с гораздо большими потерями. Зато и размер меньше, что и ставилось одной из целей.
Там есть вышеупомянутые изменения, но и просто может быть почему-нибудь интересно.

Alexander писал(а):ARM не выпускается сейчас на платах в стандарте ATX.

Не могу сказать, но совершенно точно знаю, что их выпускают на своих собственных платах, причём комп совсем даже недорогой. Их ещё и для серваков делают. Но, конечно же, если Вы имели в виду вынуть из своей платы Intel и поставить ARM, то это, как говорилось в одном известном фильме - волюнтаризм...

> вынуть из своей платы Intel и поставить ARM
Ну да, я про это.

Сделал патч ускорения к свежим исходникам и выложил их. Всё работает замечательно, спасибо !

http://soft.self-made-free.ru/source_gi ... hed.tar.xz

Alexander писал(а):Сделал патч ускорения к свежим исходникам и выложил их

Только патченый код не собирается с какими-то дикими ошибками.

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

Ну один такой патч мог бы выглядеть в минимальном виде так:

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

*** cpubase.inc 2023-02-08 15:40:01.500673937 +0300
--- cpubase_edited.inc  2023-02-08 15:50:10.640589037 +0300
***************
*** 53,73 ****
    std_op2str:op2strtable={$i x8664int.inc}

  {*****************************************************************************
-                                GDB Information
- *****************************************************************************}
-
-       {# Register indexes for stabs information, when some
-          parameters or variables are stored in registers.
-
-          Taken from i386.c (dbx_register_map) and i386.h
-           (FIXED_REGISTERS) from GCC 3.x source code
-
-       }
-       stab_regindex : array[tregisterindex] of shortint = (
-         {$i r8664stab.inc}
-       );
-
- {*****************************************************************************
                            Default generic sizes
  *****************************************************************************}

--- 53,58


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

patch -p0 <  cpubase_edited.patch

Однако надо понять почему во втором случае в комментариях дана ссылка на GDB. И сложность представляет не сделать патч, а понять это. А первый случай использования файла r8664stab.inc находится в cpubase.pas : переменная regstabs_table . В итоге получается повторное включение одного файла в две разные переменные. В любом случае напрашивается какое-то сокращение: настолько простое как в патче или сложнее, если завязка stab_regindex с GDB действительно есть.

Добавлено спустя 14 часов 24 минуты 17 секунд:
Второй патч мог бы быть таким: он содержит первый, плюс переведённые один раз в верхний регистр с помощью cat i386int.inc | tr [:lower:] [:upper:] > i386int.inc.u
файлы i8086int.inc z80stdopnames.inc x8664int.inc strinst.inc i386int.inc и исключение их перевода из переменной std_op2str функцией upper всякий раз.
http://soft.self-made-free.ru/p2.patch