[jpg] fedora 14

>Специально для тех, кому уже не хватает скорости открытия картинок с девушками.

Уже поздно. Интернеты стали нормальные

Much faster porn picture browsing

:-D

Это не только для браузеров, как я понял. Просмотрщики, да и вообще все что юзает жопег будет быстрее

>Специально для тех, кому уже не хватает скорости открытия картинок с девушками.

fedora 14

— Ну же, ещё чуть-чуть…
Продолжение в коммерческой версии RHEL вместе с бонусным порнофильмом «Про Красную Шапочку, ntpdate и датацентр»

Ну и смысл? Медленное открытие картинок с девушками - это же почти как стриптиз, очень эротично. Особенно эротично на диалапе.

Лучше б сделали, чтоб оно всегда и во всех браузерах жпеги открывало снизу вверх, а не как сейчас - не пойми как ;)

Куда быстрее-то?
Или это специально для владельцев 386-ых?

Когда все крупные корпорации оптимизируют просмотр 1080p H.264 видео, линуксоиды заняты тем, что делают нестандартную версию libjpeg.

>для владельцев 386-ых?

если бы. там на mmx и sse все завязано.

По первой ссылке уже ЛОР-эффект.

С нетерпением обновлю свой rawhide.

libjpeg-turbo - очевидно же, порт на Turbo Pascal

кстати, визуальное сравнение показывает, что в ubuntu amd64 большие жопеги (3-5MB) открываются на глаз в разы быстрее, чем на i386 (те же версии ПО, на том же железе).

это на заметку крикунам о ненужности x86_64

оно ж глючное и половину картинок отображает как зеленое поле
к тому же совместимость только с jpeg6b

ничего за 2 месяца не изменилось, как было 6b, так и осталось
в большинстве дистрибутивов уже давно jpeg8b, хотя у кого еще 6b
можете собрать с исходников, подменить системную libjpeg и потестировать

sylvia@allure:/tmp/libjpeg-turbo-0.0.93/.libs$ ls -l libjpeg*
lrwxrwxrwx 1 sylvia sylvia 13 Jun 14 19:27 libjpeg.la -> ../libjpeg.la
-rw-r--r-- 1 sylvia sylvia 779 Jun 14 19:27 libjpeg.lai
lrwxrwxrwx 1 sylvia sylvia 17 Jun 14 19:27 libjpeg.so -> libjpeg.so.62.0.0
lrwxrwxrwx 1 sylvia sylvia 17 Jun 14 19:27 libjpeg.so.62 -> libjpeg.so.62.0.0
-rwxr-xr-x 1 sylvia sylvia 297849 Jun 14 19:27 libjpeg.so.62.0.0

>открываются на глаз в разы быстрее

как-раз из-за большего числа регистров

libjpeg-turbo 0.0.93 в конце апреля портировали.

это понятно. офтоплю конечно, просто вспомнилось.

хотя вообщем-то радует то, что из свободного плавания проект переходит под крыло одного из «больших» дистрибутивов, в 0.9.3 уже исправили «зеленку», во всяком случае я пока ее не вижу (пересобрала gtk image loader), глядишь и API расширят до совместимого с jpeg 8 вида...

0.9.3 -> 0.0.93

Круто.

Федоровцы, как всегда, впереди планеты всей.

> Куда быстрее-то? Или это специально для владельцев 386-ых?

Это для TigerVNC. Надо объяснять зачем VNC клиенту быстрый декодер JPEG?

>Федоровцы, как всегда, впереди планеты всей.

После убунтоводов

>>если бы. там на mmx и sse все завязано.

Это для Pentium Pro!

Кстати, если не секрет, как это сделали?

Добавили кучу intrinsic, и сделали лучше, чем компилятор с -mavx(к примеру) ?

PPro = i686 , mmx,mmxext

SSE присутствует на Pentium 3 и приравненных моделял
SSE2 - Pentium 4


$ analyze-x86 /usr/local/lib/libjpeg.so.62
instructions:
cpuid: 4    nop: 1178    call: 1307    count: 57965
i686:    88
mmx:    8589
sse:    995
sse2:    1744
3dnow!:    194

видно даже что есть оптимизация для AMD

собирается библиотека в основном nasm, т.е. написана на ассемблере

>>собирается библиотека в основном nasm, т.е. написана на ассемблере

Мда... я задумался.

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

Скажи, Сильвия, а сильно обнаглею, если попрошу тебя собрать еще и стандартную libjpeg с -march=barcelona/core2 и сравнить скорость?

ну не верится мне как-то, что ручками действительно можно настолько лучше написать.

core2 , msse4.1
cpuid: 0 nop: 927 call: 1081 count: 34464
i686: 100 mmx: 346 sse: 639 sse2: 475 ssse3: 22 sse4.1: 118

jpegtran: 1m21.982s
djpeg: 43.368s
cjpeg: 43.320s

=================
jpeg-turbo:

jpegtran: 1m23.958s
djpeg: 0m31.120s ( + 39,3% )
cjpeg: 0m29.426s ( + 47,2% )

материал - 200 Mb JPEG файлов, 240 штук, 450 Kb - 10 Mb размер
bmp: 1.2 Gb

http://libjpeg-turbo.virtualgl.org/About/Performance
их тесты тут если что, я не брала их jpgtest и картинки, своих хватает,а скрипт для бенчмарка симпровизировать недолго )

... is 32-bit performance, particularly on Intel processors and even more particularly on legacy Intel processors. This is largely due to the Huffman encoder/decoder running out of registers and having to swap some inner loop variables back and forth from memory ...

не хватает Huffman регистров на 32 битах

Оптимизирующие компиляторы вряд ли сравнятся с ручной оптимизацией, просто потому, что они не способны анализировать оптимизируемый алгоритм. Асм так же в этом деле - ещё один инструмент, не более.

Компиляторы тоже не с неба упали, их кто-то написал?

> Когда все крупные корпорации оптимизируют просмотр 1080p H.264 видео,
H.264 не нужно

Для некоторых ключевый и критичных к скорости исполнения программ есть опции компиляции: «С MMX» и в тоже самое время «С SSE/SSE2». Можно выбрать: 1) оба пункта, 2) можно выбрать что-то одно и 3) можно ничего не выбирать.
Так вот вопрос (понятно, что п.3 отпадает) как отразится на быстродействии программ выбор обеих SIMD-технологий по сравнению с выбором одной из двух «SSE/SSE2» или «MMX»?

Технология «MMX», как известно, устарела и повсеместно заменяется на «SSE». Так значит можно «MMX» не включать и оставить только оптимизации под SSE/SSE2?

тут сложно сказать что будет лучше,
архитектуры x86, x86-64, а уж тем более x86 - архитектуры с маленьким числом регистров, на x86 их всего 8 целочисленных 32 битных,
так что любой способ расширения их числа он важен для производительности
MMX = 8 64-битных целочисленных регистров (разделяемых с FPU 387) с наборами комманд MMX,3DNow!,EMMI
SSE - 16 128-битных регистров, начиная с SSE2 могут быть использованы и для вещественных типов

вот авторы turbo jpeg жалуются что мало им регистров на Huffman )

«Технология „MMX“, как известно, устарела и повсеместно заменяется на „SSE“.»

я бы не стала так категорично утверждать о замене, MMX дополняет основные регистры архитектуры, также как и SSE, причем и то и другое может использоваться для математики (387/MMX или SSE)

Еще стоит учитывать что GCC будет использовать MMX при -march=i686 и выше, так что учитывая тот факт что MMX это регистры FPU, которые могут быть использованы для математики, которые также будут использованы и компилятором, SSE будут более выгодны при выборе между --enable-mmx и --enable-sse, если выбирать обе, то будет выбрана обычно (по результатам cpuid) SSE , так что --enable-mmx лучше все равно указывать, хуже от этого не станет

выбирается обычно так

cpuid -> (нет) -> i486 , 8x32 bit INT register
  |
есть ли SSE регистры?
  |
 SSE2 и выше ? -> доступны 16 128-бит регистров с возможностью использования вещественных типов
  |
 SSE 
  |
SSE нету, попробуем использовать регистры FPU
  |
 3DNow! , EMMI
  |
 MMX

Спасибо.

16 SSE -> 8 , вместе с MMX считала ...