LINUX.ORG.RU

История изменений

Исправление wandrien, (текущая версия) :

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код.

Просто до меня уже кто-то тут докапывался с этими jump-таблицами и достал. Не помню, кто это был.

Если таблиц много и они в горячем пути, то повлияет.

У меня 16-19 процентов времени программа проводит в функции поиска имени в пространстве имён. Потому что там используется линейный список вместо бинарного дерева или хэш-таблицы. Это самый горячий кусок программы сейчас.

В генераторе кода больше всего программа времени проводит тупо засовывая байты в буфер. Потому что компиляция 12 тысяч строк исходника самого компилятора порождает ассемблерный листинг на 1.6 мегабайта.

Видимо, нужная какая-то другая программа, написанная на Qod, которая бы меня мотивировала заняться оптимизацией switch-а =)

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

сворачивание лишних jmp

Просто оно уже и раньше было, но оказалось недоделанным.

while a != b loop
   if bla_bla(a) then
      a = foo1(b);
      // здесь переход не на "после if", а как если бы стояло continue -- сразу на условие цикла
   else
      a = foo2(b);
      // здесь аналогично
   end:if
   // здесь не генерируется jmp обратно, потому что управление этой точки никогда не достигает
end:while

Вот такие кейсы работали. А если внутри был еще один if, то уже нет. Доделал рекурсивную передачу информации о целевой метке перехода.

Исправление wandrien, :

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код.

Просто до меня уже кто-то тут докапывался с этими jump-таблицами и достал. Не помню, кто это был.

Если таблиц много и они в горячем пути, то повлияет.

У меня 16-19 процентов времени программа проводит в функции поиска имени в пространстве имён. Потому что там используется линейный список вместо бинарного дерева или хэш-таблицы. Это самый горячий кусок программы сейчас.

В генераторе кода больше всего программа времени проводит тупо засовывая байты в буфер. Потому что компиляция 12 тысяч строк исходника самого компилятора порождает ассемблерный листинг на 1.6 мегабайта.

Видимо, нужная какая-то другая программа, написанная на Qod, которая бы меня мотивировала заняться оптимизацией switch-а =)

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

сворачивание лишних jmp

Просто оно уже и раньше было, но оказалось недоделанным.

while a != b loop
   if bla_bla(a) then
      a = foo1(b);
      // здесь переход не на "после if", а как если бы стояло continue -- сразу на условие цикла
   else
      a = foo2(b);
      // здесь аналогично
   end:if
end:while

Вот такие кейсы работали. А если внутри был еще один if, то уже нет. Доделал рекурсивную передачу информации о целевой метке перехода.

Исходная версия wandrien, :

Я лишь поинтересовался, у тебя какие то языковые комплексы неполноценности. У GCC/Clang на удивление плохая генерация для такой распространенной конструкции, что сразу выделяется, на фоне того как они оптимизируют и довольно сложный код.

Просто до меня уже кто-то тут докапывался с этими jump-таблицами и достал. Не помню, кто это был.

Если таблиц много и они в горячем пути, то повлияет.

У меня 16-19 процентов времени программа проводит в функции поиска имени в пространстве имён. Потому что там используется линейный список вместо бинарного дерева или хэш-таблицы. Это самый горячий кусок программы сейчас.

В генераторе кода больше всего программа времени проводит тупо засовывая байты в буфер. Потому что компиляция 12 тысяч строк исходника самого компилятора порождает ассемблерный листинг на 1.6 мегабайта.

Видимо, нужная какая-то другая программа, написанная на Qod, которая бы меня мотивировала заняться оптимизацией switch-а =)

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

сворачивание лишних jmp

Просто оно уже и раньше было, но оказалось недоделанным.

while a != b loop
   if bla_bla(a) then
      a = foo1(b);
      // здесь переход не на "после if", а как если бы стояло continue -- сразу на условие цикла
   else
      a = foo2(b);
      // здесь аналогично
   end:if
end:while

Вот такие кейсы работали. А если внутри был еще один if, то уже нет. Доделал рекурсивную передачу информации о целевой метке перехода.