[Gfoss] libjpeg sucks

[a.furieri a lqt.it]

oggi tocca abbassare la cresta (e chiedere umilmente scusa):
anche nel mondo FLOSS ogni tanto si scopre qualche "cappella"

ho appena scoperto che libjpeg [la libreria open source
che gestisce *tutte* le immagini JPEG] è lenta da morire.

Ancor peggio: libjpeg quasi sicuramente è il codec JPEG
più inefficiente e lento oggi disponibile sul mercato: 
qualsiasi equivalente proprietario gli bagna il naso,
quanto meno su piattaforme x86 / amd64

la causa: 
=========
fin dal tempo dei primi Pentium Intel ha introdotto in 
hardware il set di istruzioni MMX/SSE con lo scopo di 
supportare i codecs multimediali.
Con i Core 2, i7, i5 etc è stato introdotto SSE2 che
è ancora più potente.
Ma libjpeg ignora del tutto queste istruzioni, mentre
invece i codes proprietari le sfruttano al meglio.

la cura:
========
fortunatamente esiste il progetto libjpeg-turbo.
in pratica è un clone esattamanente identico a libjpeg (stesse
identiche API/ABI), che però gestisce (da assembler) le estensioni 
MMX/SSE2 - in questo modo praticamente di dimezzano i tempi di coding
e decoding. risultati misurati personalmente sul campo (su i5):

coding: 2.5secs -> 1.1secs
decoding: 1.7secs -> 0.9secs

licenza: wxWidgets [LGPL, ma consente static linkage]

riferimenti:
============
http://libjpeg-turbo.virtualgl.org/
http://sourceforge.net/projects/libjpeg-turbo/

commento:
=========
probabilmente una "sega mentale" per qualsiasi uso ordinario.
ma in alcuni ambiti applicativi (penso in particolare ai
server WMS) potrebbe anche segnare una differenza significativa.
ovviamente il beneficio si estende anche ai Tiff/Jpeg

ad ogni modo libjpeg-turbo mi pare assolutamente stabile
ed affidabile.
- fare la build è un piacere (anche su WinOZ MSYS+MinGW)
- occorre preinstallare l'assembler NASM
- dopo di che basta copiare la "nuova" libjpeg al posto
  di quella "di sistema" ... voila, il gioco è fatto :-)

ciao Sandro

P.S. (per Frankie) 
fare un pensierino per debianizzare libjpeg-turbo: perchè no ???