LINUX.ORG.RU
ФорумTalks

[jpg] fedora 14

 


0

0

Внезапно узнал, что в новой Федоре будет нестандартная версия libjpeg (libjpeg-turbo).
Специально для тех, кому уже не хватает скорости открытия картинок с девушками.

инфа тут - http://libjpeg-turbo.virtualgl.org/
и тут - http://fedoranext.wordpress.com/2010/06/09/fedora-14-three-new-features/

★★★★★

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

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

amonymous
()
Ответ на: комментарий от amonymous

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

ZZaiatSS ★★
()

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

fedora 14

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

dogbert ★★★★★
()

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

queen3 ★★★★★
()

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

h8 ★★★
()

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

Zhid
()
Ответ на: комментарий от ist76

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

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

devl547 ★★★★★
() автор топика

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

vkos ★★
()

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

kost-bebix ★★
()

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

vertexua ★★★★★
()

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

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

k0l0b0k ★★
()

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

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

ничего за 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


Sylvia ★★★★★
()
Ответ на: комментарий от devl547

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

k0l0b0k ★★
()
Ответ на: комментарий от Sylvia

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

Sylvia ★★★★★
()
Ответ на: комментарий от ist76

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

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

Relan ★★★★★
()
Ответ на: комментарий от tempuser002

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

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

amonymous
()

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

Это для Pentium Pro!

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

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

Lockywolf ★★★
()
Ответ на: комментарий от Lockywolf

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, т.е. написана на ассемблере

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

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

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

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

Lockywolf ★★★
()
Ответ на: комментарий от Lockywolf

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

Sylvia ★★★★★
()
Ответ на: комментарий от k0l0b0k

... 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 битах

Sylvia ★★★★★
()

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

anon_666
()
Ответ на: комментарий от Lockywolf

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

anon_666
()
Ответ на: комментарий от Zhid

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

Xenius ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

iZEN ★★★★★
()
Ответ на: комментарий от iZEN

тут сложно сказать что будет лучше,
архитектуры 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 лучше все равно указывать, хуже от этого не станет

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

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

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

Sylvia ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.