Есть такой LittleCMS, не так давно вышла вторая версия, которая поддерживает плавающую точку при обработке (в отличие от коммерческих CMS, гы-гы).
Щупаю ея за вымя, сначала на тему перформанса (про точность будет отдельный пост в отдельной теме).
Собираю просто (./configure && make && make install) - некий файл обрабатывает 8.5 секунд в плавучке и 4 секунды в целых. Медленно.
Берем и ускоряем в 4 раза:
./configure CC=gcc44 CXX=gcc44 CFLAGS="-O3 -march=core2" CXXFLAGS="-O3 -march=core2"Для справки:
$ gcc44 -v
Using built-in specs. Target: x86_64-portbld-freebsd8.1 gcc version 4.4.5 20100706 (prerelease) (GCC)Прогресс неостановим.
Update: clang еще несколько быстрее в плавучке и *гораздо* быстрее в целых.
Comments
clang... CMS...
меня давно грызёт идея написать компилятор профиля прямо в нативный код через CMS. Т.е. не строить последовательность вызовов функций, написанных на C, по профилю -- а вот генерить нативный код, с MMX/SSE/AltiVect'ом/NEON'ом, который делает трансофрмацию провно по данному набору профилей. По идее, должно быть гораздо быстрее без потери точности, если хорошо написать.
А почему ты думаешь, что
А почему ты думаешь, что загнать таблицу в код (в виде гигантского набора if-ов, очевидно) будет быстрее, чем иметь ее же отдельно?
Надо мерять. Но, во-первых,
Надо мерять. Но, во-первых, какой-нибудь sRGB/AdobeRGB, как я понимаю, не табличный. Во-вторых -- оптимизации глобальные. Я не уверен на 100% что это заработает. Но попробовать руки чешутся.
Вообще чешутся руки написать на базе LLVM язык для обработки графики -- что бы после построения набора эффектов-слоёв (где конверсия в Lab и обратно через профили -- только одна из возможных операций) оно компилировалось как ЕДИНАЯ программа со всеми возможными оптимизациями.
С матричными профилями вообще
С матричными профилями вообще проблем нет, там же код один и тот же независимо от коэффициентов
Впечатляет. А вот интересно, ядро на 8.* уже можно с оптимиз
Впечатляет. А вот интересно, ядро на 8.* уже можно с оптимизацией собирать?
Ну мне наши девелоперы, увидев в другом проекте -O3, замахал
Ну мне наши девелоперы, увидев в другом проекте -O3, замахали руками и заругались, поэтому надо осторожно с этим.
Хотя вот лично я проблем с -O3 пока не встречал
а под архитектуру? ох боюсь что вряд ли...
а под архитектуру? ох боюсь что вряд ли...
Под архитектуру скорее всего можно. У меня march=... в /etc/
Под архитектуру скорее всего можно. У меня march=... в /etc/make.conf уже очень давно.
Здорово. Надо будет попробовать на следующем аппарате, котор
Здорово. Надо будет попробовать на следующем аппарате, который для развлекухи ставить собрался. Спасибо!
Не наследство ли это сурового прошлого? В 2003-2004 с -O3 бы
Не наследство ли это сурового прошлого? В 2003-2004 с -O3 было что-то такое, что жертвы запомнили очень надолго - может из-за этого?
Не исключено. Хотя вот в чуть поздние годы (эдак в 2005) я
Не исключено.
Хотя вот в чуть поздние годы (эдак в 2005) я в одном нашем коде допустил багу, которую до сих пор вспоминаю именно в связи с компилятором (но это gcc 3.x).
Код с -O2 работал правильно, а без оптимизации - нет.
Фишка была в том, что я значение для изменения передавал в функцию по значению, а не по ссылке/референсу. С -O2 компилятор инлайнил и все начинало работать - но это означает именно что грубую ошибку в компиляторе.
[facepalm.jpg] да-да-да, именно в 3.Х было что-то очень гру
[facepalm.jpg]
да-да-да, именно в 3.Х было что-то очень грустное
Ха-ха-ха: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392
Ха-ха-ха: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13392
Слушай, ты же неленивый: а под clang, что получается? Он же,
Слушай, ты же неленивый: а под clang, что получается? Он же, как я понимаю, для фри тоже есть
Я, к стыду моему, не знаю, где у clang руль, а где - сцеплен
Я, к стыду моему, не знаю, где у clang руль, а где - сцепление.
То бишь я его даже собрал как-то, а как пользоваться - не понял.
а с clang, кстати, еще заметно побыстрее - процентов на 15
а с clang, кстати, еще заметно побыстрее
- процентов на 15 (от меньшего) в плавучке
- раза в полтора в целых.
И это с -O3. С -O4 ругается на неизвестном мне пока языке:
$ clang -O4 a.c
clang: error: 'x86_64-portbld-freebsd8.1': unable to pass LLVM bit-code files to linker
Но правда я на результат не очень смотрел, а то "печатаю 30000 знаков в минуту, но такая фигня получается...."
Впрочем, результат побитно идентичен тому, что gcc наделало.
Впрочем, результат побитно идентичен тому, что gcc наделало. md5 рулит
смешно а ты вот прямо clang-clang использовал, не брата его
смешно а ты вот прямо clang-clang использовал, не брата его LLVM-gcc?
А с -O4 они смешное пишут:
On supported platforms, -O4 enables link-time
optimization; object files are stored in the LLVM bitcode file
format and whole program optimization is done at link time.
Прямо clang. Пошел в ports/devel/clang, сказал там make inst
Прямо clang.
Пошел в ports/devel/clang, сказал там make install оно все и случилось.
Врут, что clang с gcc по свитчам совместим.
А про биткод и генерацию кода линкером - это я понимаю, но что за линкер нужен - не понимаю.
Подозреваю, что llvm-link: http://llvm.org/releases/1.3/docs
Подозреваю, что llvm-link:
http://llvm.org/releases/1.3/docs/CommandGuide/html/llvm-link.html
Или http://llvm.org/releases/1.3/docs/CommandGuide/html/gccl
Или http://llvm.org/releases/1.3/docs/CommandGuide/html/gccld.html
(развели цирк, понимаешь)
Я начал это место гуглить и испортился окончательно. llvm-l
Я начал это место гуглить и испортился окончательно.
llvm-link есть, но как сделать так, чтобы clang позвал его, а не ld - не понял (и, кажется, уже не хочу)
gold, пока только gold. Вместе с lto плагином.
gold, пока только gold. Вместе с lto плагином.
Можно, правда, собрать ручками. Poor-man LTO выглядит как-то
Можно, правда, собрать ручками. Poor-man LTO выглядит как-то так:
{llvm-gcc, clang} -O4 -c *.c
llvm-link *.o | opt -std-link-opts | llc -o foo.s
Дальше уже с foo.s можно делать все, что угодно.
если такая простая штука ускоряет в 4 раза, значит с оптимиз
если такая простая штука ускоряет в 4 раза, значит с оптимизацией там конь не валялся и легко можно ускорить ещё в 4 :-)
Да, естественно. Если там с точностью все хорошо, то я буду
Да, естественно. Если там с точностью все хорошо, то я буду SSE туда приделывать, заодно научусь.
Тольво "еще в 4" мне мало, надо больше.
Post new comment