?

Log in

No account? Create an account

Программистский вопрос залу - Ваши рубидии уже у кобальта во ртути

Nov. 16th, 2010

12:37 pm - Программистский вопрос залу

Previous Entry Share Next Entry

Comments:

[User Picture]
From:motto
Date:November 16th, 2010 10:25 pm (UTC)
(Link)
Теоретически кланг умеет что-то дожимать своим линкером на -о4, практически, конечно, мало шансов

С другой стороны Тутубалин в свое время на реальном проекте получил довольно впечатляющие результаты против gcc
(Reply) (Parent) (Thread)
[User Picture]
From:spamsink
Date:November 16th, 2010 11:02 pm (UTC)
(Link)
Конечно, если вызовов foo мало, и все с константами в качестве en, то можно и при линковке соптимизировать, но меня интересует исключительно преобразование дерева: есть ли какие-нибудь наработки, как собирать инварианты из листьев или отдельных "веток", а не из поддеревьев, как обычно.
Оптимизация получается, если неинвариантные куски ветвей по разные стороны условия оказываются идентичными; выходит, что нужно делать распознавание инвариантов цикла; поиск общих (взаимоисключенных управлением! в отличие от обычного CSE) подвыражений, игнорируя инварианты в них; и схлопывание подвыражений с вынесением выбора инвариантов из цикла.

Мешки ворочать недобродетельно, потому сначала и спрашиваю - может, кто где сделал уже.


Edited at 2010-11-16 11:02 pm (UTC)
(Reply) (Parent) (Thread)
[User Picture]
From:alextutubalin
Date:November 17th, 2010 06:58 am (UTC)
(Link)
поиск фамилии по блогам - работает!

Надо понимать, что за код мне оптимизировал clang. То есть там все упиралось в pow() и если просто был подставлен хороший библиотечный (встроенный,точнее) аналог, а не из libm и не из вызова сопроцессора, то в данной конкретной строчке (которая зовется на все пиксели изображения) мог быть выигрыш просто в разы.

Но я не разбирался в деталях, там в этой lcms такой овер-инжиниринг, что она мне накуй не упала, это место будет аккуратно сделано руками когда до него дойдет.
(Reply) (Parent) (Thread)
[User Picture]
From:spamsink
Date:November 17th, 2010 07:05 am (UTC)
(Link)
там все упиралось в pow()

Это случайно был не индусский код? А то я видал много любителей писать pow(2, i) для i в пределах 32 или 64.
(Reply) (Parent) (Thread)
[User Picture]
From:alextutubalin
Date:November 17th, 2010 07:23 am (UTC)
(Link)
Не, Marti Maria вроде не индийское имя :)

Конкретно в этом месте - гамма-коррекция (-преобразование) картинки - pow() по смыслу очень даже. И степень дробная (как правило) и возводимое - float.

Другой вопрос, что библиотечное pow() - это ужас нах, особенно если для 25-мегапиксельной картинки его позвать 75 миллионов раз (потому что RGB).

И если в llvm есть свой хороший builtin, то выигрыш мог быть ровно по этой причине.
Хотя в данной задаче нужен не "хороший", а "приближенный" и диапазон входных значений 0..1, что дает еще выигрыш в разы, если не на порядок (для конкретной строчки).
(Reply) (Parent) (Thread)
[User Picture]
From:motto
Date:November 17th, 2010 09:06 am (UTC)
(Link)
Не похоже. То есть там есть какой-то libstdc++ но он так же сбоку, как и отладчик с линкером:

-rwxr-xr-x 1 motto staff 8,5K 17 ноя 11:43 pclng.out
-rwxr-xr-x 1 motto staff 8,5K 17 ноя 11:42 pgcc.out
-rw-r--r--@ 1 motto staff 74B 17 ноя 11:42 ppc.c

otool -L pclng.out
pclng.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)
tmp motto$ otool -L pgcc.out
pgcc.out:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

Ну и:

Ltmp1:
subq $32, %rsp
Ltmp2:
movl $0, -4(%rbp)
movsd LCPI1_0(%rip), %xmm0
movsd LCPI1_1(%rip), %xmm1
movsd %xmm0, -24(%rbp)
movapd %xmm1, %xmm0
movsd -24(%rbp), %xmm1
callq _pow
(Reply) (Parent) (Thread)
[User Picture]
From:alextutubalin
Date:November 17th, 2010 09:19 am (UTC)
(Link)
Ну значит нет.

В любом случае, компилятор соптимизировал место, от которого лично меня просто стошнило. Может быть gcc - тоже, а llvm менее брезгливый?

Т.е. там (lcms2 которую я и щупал) хороший код в смысле следования всяким ICC-стандартам на обращение с цветом, но в смысле перформанса и вообще каких-то оптимизаций сплошной ужас.

И, соответственно, оптимизировать ужас бессмысленно, его надо переделывать, толку будет больше.
(Reply) (Parent) (Thread)