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

[VEG]

Athlon XP 3200+ (2.2GHz), SSE
Lancer 20060616 - 37.85x
Lancer 20060805 - 38.56x
На 1.9% быстрее. Думаю, на процессорах Intel прирост будет еще больше.

Если вы использовали промежуточные версии из лаборатории, то обновится стоит обязательно, т.к. было исправленно множество мелких ошибок.

Появилась идея. А что если написать софтину, которая будет автоматически искать новые версии кодеров и сама будет качать версию конкретно под свой процессор? :) Заодно можно будет показывать сообщение - теперь кодирование будет на X% быстрее!

[VEG]

Новые релизы идут почти каждый день!

2006/08/11 Lancer 20060811

Correcting the SSE optimization of mdct_backward

2006/08/10 Lancer 20060810 (bit rate abnormal problem, for multithread operation problem evaluation)

Correcting the problem of the SSE optimization of _ve_amp
Correcting the problem where the pattern which each time differs in multithread operation edition is output

2006/08/09 Lancer 20060809 (for bit rate abnormal problem evaluation)

Because problem is discovered to the portion of the SSE optimization of _ve_amp, deletion

[VEG]

Еще пачка релизов.

2006/09/03 Lancer 20060903

Efficiency of the inline assembler cord/code for ICL detailed survey, deleting the slow part
Efficiency of cash control-related cord/code detailed survey, deleting the slow part
Efficiency of memory transfer type cord/code detailed survey and SSE optimization cord/code part revival
Improving the SSE optimization of bark_noise_hybridmp
Knocking down the renewal frequency of the lapse indication of oggenc2.

2006/08/24 Lancer 20060824

Based cord/code modification to aotuv-r1_20051117
Adding SSE optimization to _vp_couple
Adding the cord/code for multi channel processing divisions to xmmlib.h
At the time of OpenMP use the single thread _vp_quantize_couple_memo and _vp_quantize_couple_sort which are operational modification to multithread operation operation

2006/08/18 Lancer 20060816

It improves the multithread operation processing of mapping0_forward, increases the parallel processing section and accelerates
In order with coodbook.* to make the parallel processing of floor1_encode possible, mounting the delay collective entry function of the Ogg stream
Way floor1_encode can be executed while parallel processing, modification
_vp_couple it corresponds to parallel processing
At the time of profile measurement way it does not enter into the infinite loop, modification
Reviving the profile build for MT

2006/08/15 Lancer 20060815 (for multithread operation problem evaluation)

Separating the OpenMP use part with mapping0_forward
Way OpenMP by all means uses multithread operation in the multithread operation section, correction
For accelerating controlling the use of critical session in the multithread operation section

[VEG]

Еще одно обновление

2006/09/15 Lancer 20060915

Because binary for multithread operation from profile edition usually modification (the profile optimization effect at the time of MT is low in edition,)
Correcting the description mistake of the cord/code for MT of mapping0_forward
Executing loop unrolling with mdct_forward, mdct_backward and mdct_butterfly_generic under multithread operation environment

[Captain Harris]

Довольно занятное дело получается.

При сравнении скорости сжатия oggenc283_sse_lancer20060903 и oggenc283_sse2_lancer20060903 большую скорость показывает то один то другой кодек.

Интересно чем это можно объяснить?
Хотя тут выше постом писали, что даже один и тотже кодек показывает разные результаты, хотя у меня они вроде стабильные.

Тестировал на процессоре AMD athlon 64 3000+

[VEG]

Возможно конкретно на данном процессоре прироста от использования SSE2 нет. Тем более, что все SSE — это разработка Intel, которую AMD реализует только для сохранения совместимости.

[moozooh]

Интересно чем это можно объяснить?

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

Тем более, что все SSE — это разработка Intel, которую AMD реализует только для сохранения совместимости.

…И конечно не из-за прироста скорости.

[iGold]

Кстати, в 64-х битной PC архитектуре вообще стараются не использовать FPU и все вычисления в дробных числах ведутся только с помощью SSE инструкций (как минимум, так поступает GCC по-умолчанию). Так что SSE/SSE2 - обязательная и стандартная вещь для x86_64 (хотя, возможно, изначально AMD и поддерживали SSE инструкции только из соображений совместимости, предлагая свои расширения типа 3DNow!, которые так и не прижились).

Since SSE and SSE2 are generally faster than, and duplicate most of the features of, the traditional x87 instructions, MMX, and 3DNow!, the latter are redundant under AMD64.

http://en.wikipedia.org/wiki/X86_64

[Captain Harris]

Я вот подумал, а кодек оптимизированный под 64 битные процессоры они не планируют? Интерес чисто академический. Но теоретически ведь должен быть прирост производительности.

[moozooh]

Это имеет смысл только в 64-битных операционных системах… Со временем все на них перейдут, и кодеки никуда не денутся. :)
А пока ими почти никто не пользуется, что вполне объяснимо.

[Captain Harris]

Это имеет смысл только в 64-битных операционных системах… Со временем все на них перейдут, и кодеки никуда не денутся. :)
А пока ими почти никто не пользуется, что вполне объяснимо.

Тут с вами не поспоришь.

[VEG]

Очередное обновление:

2006/10/05 Lancer 20061005

ICL in 9.1.030 version upgrade
Improving the cord/code for MT of mapping0_forward.
Modifying compiling optimization option
Part removal of compile-time warning
The support abolition of GCC

С этой версии потеряна совместимость исходных кодов с компилятором GCC. Теперь программа собирается только в среде Visual Studio 2003 на Intel С++ компиляторе.

[SyCraft]

С этой версии потеряна совместимость исходных кодов с компилятором GCC. Теперь программа собирается только в среде Visual Studio 2003 на Intel С++ компиляторе

Это плохо?

[VEG]

Это плохо?

Для пользователей Windows это ничего не меняет (или даже хорошо из-за использования Intel'овского компилятора). Для пользователей Linux это значит, что они не смогут пользоваться прелестями Lancer.
Возможно в будущем совместимость будет восстановлена.

[Captain Harris]

[quote]С этой версии потеряна совместимость исходных кодов с компилятором GCC. Теперь программа собирается только в среде Visual Studio 2003 на Intel С++ компиляторе

Это плохо?[/quote]

Для пользователей *nix систем чрезвычайно плохо.