22.07.2006 - Новый Ogg Vorbis Lancer, теперь и OggDec!

[VEG]

Вышла обновленная версия оптимизированного кодeка Ogg Vorbis Lancer. Сейчас проект включает в себя и оптимизированную версию декодера OggDec.
В новой версии произошли следующие изменения (на английском):

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

* inline assembly replaces as much as possible to intrinsic
* abolish original memory transfer code in block.c
* bitreverse use looking up table
* fix speed down vorbis_book_decodevv_add's regression in lancer
  20060529
* remove optimization prevention code in vorbis_book_decodevv_add
* pre-calculate tables for triggers in mdct
* simplifying a code in which high frequency removed by mdct_backward
* add decode only funcs: mdct_butterflies_backward,
  dct_butterfly_first_backward
* improve SSE optimization: bark_noise_hybridmp
* add SSE optimization: render_line, vorbis_noise_normalize,
  _vp_noise_normalize
* add SSE3 optimization: mdct_bitreverse
* add pre-calculation code: seed_loop, max_seeds
* optimize: seed_chase
* add SORT16 to psy.c
* auto loop unrolling: SORT8, SORT32 in psy.c
* use lddqu in non SSE environment for unaligned memory load
* improve loop condiution code in inline assembly code
* add t option for oggdec benchmarks (without outputting file)

Цените время — пользуйтесь Lancer! :)
Все варианты этого кодировщика можно найти на официальной страничке.

[CMEPTb]

Сегодня впервые решил скачать версию с SSE для своего sempron. Не думал что разница в скорости больше чем в 2 раза. 11 секунд против 24, 8 против 19 и тд. Круто. 8)

[Артём]

Руль, кодирует на скорости 15-16x

[Synth]

Воистину, новый лансер резкий как диаррея

[VEG]

Прошу провести простой тест: закодируйте 5 минут любого звука при помощи стандартного aoTuV и при помощи Lancer. Укажите в посте ваш процессор и скорость кодирования в обоих случаях.

[moozooh]

Тест провёл. Понял, что с «пятью минутами любого звука» Вы явно погорячились. ;)
Вот, например, я использовал четыре в корне разных сэмпла, каждый ровно пять минут длиной (параметры 44100/16-bit/stereo, сжимал в -q5). Один из них был очень сложным для сжатия набором шумовых эффектов, где оба канала различались на 100% (взято с музыкального CD!), ещё один был чистым килогерцовым синусом с нулевым различием между каналами. Сжимал каждым кодировщиком три раза, потом считал среднее арифметическое для каждого сэмпла. Результаты следующие:

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

encoder:            sample1  sample2  sample3  sample4  average

Lancer SSE3 22.07   27.57x   20.29x   29.67x   36.77x   28.58x
Oggenc v2.83 (P4)   17.72x   11.10x   17.28x   21.29x   16.85x

Система: Athlon 64 3400+ (ядро Venice, 90нм), 768 МБ DDR400 (single channel).

Как видно, в зависимости от материала, разница в скорости работы одного и того же кодировщика (в среднем ~1.87x) может превосходить разницу в скорости между двумя различными кодировщиками (и причин тому может быть много, даже смысла особо не имеет перечислять). Думаю, для получения внятных результатов следует сжимать не «пять минут», а набор разных звуков (т.е. тестовый корпус).

А теперь загадка для дотошных: угадайте, где среди сэмплов моносинус, и где стереошум. :)

[moozooh]

К слову, чисто ради любопытства готов провести второй тест без записи сжатых файлов на жёсткий диск, если кто-нибудь скажет мне, как сконфигурировать кодировщик для вывода данных в /null на WinXP.

[VEG]

К слову, чисто ради любопытства готов провести второй тест без записи сжатых файлов на жёсткий диск, если кто-нибудь скажет мне, как сконфигурировать кодировщик для вывода данных в /null на WinXP.

По идее надо перенаправить поток в stdout параметром "-o -" и никуда его не направлять... Но могу с уверенностью сказать, что это не скажется на работе кодера... узкое место может быть при считывании wav файла, т.к. там значительно больший поток данных. В идеале можно написать программу, которая будет загружать весь исходный файл в оперативку и направлять его в stdin кодировщика...

[VEG]

В этом релизе были обнаружены утечки памяти, сейчас ведутся работы по поиску ошибки. Релиз с исправлением проблемы можно найти на странице лаборатории.

[-=@L!=-]

Утечки памяти?
А...это отражается на файлах закодированных?
Если да..то...что ж мне делать!? :o

[VEG]

Утечки памяти?
А...это отражается на файлах закодированных?
Если да..то...что ж мне делать!? :o

Нет, просто после работы программы в памяти компьютера остается немного мусора (до первой перезагрузки системы), из-за чего другие программы могут начать тормозить. Временное (еще не окончательное) исправление проблемы находится на сайте программы в лаборатории (сейчас там версия от 2006-08-06). Можете так же использовать старую версию Lancer, т.к. ошибка была обнаружена в коде из новой версии.

[arcman]

VEG

Нет, просто после работы программы в памяти компьютера остается немного мусора (до первой перезагрузки системы), из-за чего другие программы могут начать тормозить.

Почемуто мне казалось что в нормальной операционной системе после завершения программы все связанные с ней ресурсы освобождаются ;)
Как раз для того что бы "другие программы не начали тормозить" :D
Утечки памяти наблюдаются лишь во время работы программы, если они остаются и после её завершения - это уже баг в ОС.
Как таковые, утечки опасны лишь в системных сервисах и программах, которые должны быть запущенны длительное время.
Раслабляться правда тоже не стоит - утечка памяти это баг в программе - а там где есть один баг, найдутся и другие ;)

[moozooh]

Почемуто мне казалось что в нормальной операционной системе после завершения программы все связанные с ней ресурсы освобождаются ;)
Как раз для того что бы "другие программы не начали тормозить" :D
Утечки памяти наблюдаются лишь во время работы программы, если они остаются и после её завершения - это уже баг в ОС.

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

[VEG]

Теперь на официальной странице доступна нормальная версия кодера. Список изменений солидный. Обновляемся:)

2006/08/07 Lancer 20060807

Correcting the SSE optimization of mdct_forward and mdct_backward
Only static edition reviving vorbis_oggpack_write
Correcting the problem of local_book_besterror_dim1x4

2006/08/06 Lancer 20060807 (for memory problem evaluation)

Because heap memory access error occurs with vorbis_oggpack_write, it moves the abolition and optimization module to oggpack_write
Optimizing oggpack_look
Modifying the SSE optimization of _ve_amp
Correcting cash control processing of accumulate_fit
Correcting the fact that it is imperfect with MDCT-related cash control
Deleting unnecessary zero data exception processing with inspect_error
Rearranging the SSE optimization description section of _encodepart

2006/08/02 Lancer 20060802 (for memory problem evaluation)

Correcting the memory leak with _vp_psy_clear
Measurement of elapsed time modification to timeGetTime whose precision is higher than GetTickCount
Increase the elapsed time indicatory beam of oggenc2
With oggdec controlling decoding progress indication at the time of t option use, way it measures accurate processing time, modification
Increasing advance calculation with mdct_butterfly_first_backward, lightening processing
Correcting the SSE3 optimization of mdct_butterfly_generic
Transferring the inline conversion judgment of couple_lossless_ps, couple_lossless and precomputed_couple_point to the compiler
The to table converting factor with FFT-related processing, lightening processing
Adding SSE optimization to _ve_amp
Way at optimization module all the second look at cash control (non [tenporaruakusesu] it does the table whose part reference frequency is low, modification)
Way the SSE optimization of _encodepart local_book_besterror is not used, modification

[CMEPTb]

Кто нибудь на скорость его протестировал? Разница есть?