>>> Да блин, кого эта скорость компиляции волнует?
>> Меня.
> А ты вообще на яве программируешь вроде? :)Уже нет. А что?
>> Для систем с непрерывной интеграцией изменений важна высокая скорость
>> компиляции исходного кода.
> Я вроде просил задротов помешаных на пересборке всей системы с поводом и
> без не беспокоиться.
Дык, сишноориентированные системы до сих пор не развились до уровня бинарной модульности OSGi или хотя бы EJB. Всё у них какие-то "деревянные" зависимости от libjpeg, libpng и icu, что при изменении минорной версии этих библиотек весь десктоп нужно переколбашивать (пересобирать/ждать корректирующих обновлений всех зависимостей), а иначе работать ничего не будет. :))
> С ними и так все понятно - им
> по определению некуда время девать. И mission critical задач у них
> нет.
Так в том-то и дело, что некуда с подводной лодки деваться — у сишноориентированных систем нету тех технологий, что есть в Java, и ABI у ключевых библиотек нестабилен (что удивительно).
> Простите, если я разрабатываю библиотеку, пусть уж остальные сами перекомпиливают свои
> программы где им там надо и сколько надо с новой версией.
> Автор библы лопнет все программы пересобирать. Попробуй пересобрать для начала все
> программы использующие zlib? А зачем бы это тому кто поменял zlib?
> И динамическая линковка конечно же не комильфо?
В динамической линковке нестабильный ABI не отменяется — это к примеру по icu, jpeg, png. :))
>> Clang'у есть куда расти. GCC достиг потолка роста и оптимизаций.
> А подвести научное обоснование всему этому вы сможете? Или это как обычно,
> попытка выдачи желаемого за действительное?
Clang/LLVM УЖЕ интересен. GCC ЕЩЁ интересен. Разница, такая разница. ;)
>> Уж лучше потратить три дня для компиляции ПО с помощью Clang/LLVM,
>> но получить работающий код РАНЬШЕ.
> А еще лучше не страдать этим онанизмом и поставить себе за 20
> минут систему с бинарными пакетами.
Ага. И уповать на то, что мантейнеры всё собрали в лучшем виде, именно так, как тебе нужно. :)
> Сэкономив себе от трех дней до недели геморроя неизвестно зачем.
> А зачем мне пересобирать весь софт самолично?
"Зачем готовить дома на кухне, если можно пойти в ресторан МакДональдса и быстро поесть?"
Чтобы контролировать свои потребности в конкретном софте и его функциональности.
>> Лично я не представляю, какие показатели быстродействия должны приниматься в расчёт.
> В конечном итоге роялит максимальный FPS который можно выжать.
Ты латентный задрот?
Мне хватает того, что MPlayer собирается БЫСТРО и работает нормально.
Самоцель не то, чтобы всё работало максимально быстро, а то, чтобы всё собиралось БЫСТРО, без ненужных зависимостей (я выкинул из MPlayer ненужный мне FFMpeg) и работало ОПТИМАЛЬНО.
> Если он заведомо
> больше нужного - нагрузка на CPU (вой кулера на проце вкалывающем
> на пределе возможностей тоже мало кого радует). В чем прикол мерять
> максимальный FPS? На тяжелых мувиках мы или укладываемся в реалтайм с
> их FPSом, или нет. Лучше уложиться, потому что слайдшоу выглядит как-то,
> гм, не очень. А дропнуть кадр если ну никак не успеваем
> без сильного ущерба для качества картинки можно не всегда и не
> во всех кодеках. Поэтому если в реалтайм не уложиться, тяжелый мувик
> на интенсивной сцене может немало разочаровать.
Пусть разработчики кодеков меряют FPS'ы и тюнят свой код. Моё дело собрать и пользоваться ИХ кодом, либо НЕ собирать и НЕ пользовать им.
> Еще кстати дарю идею: можно качнуть vp8 и x264 и забенчить и
> их. У них есть свои утилитки-энкодеры, относительно простые, консольные. Тоже достаточно
> любопытно в принципе посмотреть на соотношения скоростей. Фороникс какие-то странные и
> не сильно жизненные задачи выбирает.
% pkg_info libvpx-0.9.7
Information for libvpx-0.9.7:
Comment:
VP8 Codec SDK
Required by:
gnome-mplayer-1.0.0_2
mplayer-1.0.r20110329_3
Description:
libvpx is the VP8 Codec SDK.
WWW: http://www.webmproject.org/
% pkg_info x264-0.116.2076
Information for x264-0.116.2076:
Comment:
Library and tool for encoding H.264/AVC video streams
Required by:
libquicktime-1.2.3_1
Description:
x264 is a free library for encoding H.264/AVC (aka MPEG-4 Part 10)
video streams.
Encoder features
* CAVLC/CABAC
* Multi-references
* Intra: all modes (4x4 and 16x16 with all predictions)
* Inter P: all partitions (from 16x16 down to 4x4)
* Inter B: partitions from 16x16 down to 8x8 (including SKIP/DIRECT)
* Ratecontrol: constant quantizer, constant bitrate, or multipass ABR
* Scene cut detection
WWW: http://www.videolan.org/x264.html
Вариант для распечатки
