Codec audio che non sfruttano la potenza della CPU

[Lotharius]

Come da titolo, ho notato che, in fase di compressione, i codec audio LAME 3.99 e OGG in versione Oggenc2.87 aoTuVb6.03, non viene affatto usata la potenza del processore. Mi spiego meglio: aprendo il task manager di Windows Vista X64 si nota chiaramente che tutti e 8 i core (4 fisici e 4 logici) del Core i7 2600K rimangono praticamente allo 0%. La compressione del disco richiede però circa 5 minuti. Questo comportamento avviene sia con CDEx che con Exact Audio Copy, entrambe all'ultima versione disponibile.
Ora mi chiedo: perchè la conversione richiede 5 minuti con gli 8 core allo 0%, invece che 5 secondi con gli 8 core al 100%?

Mi è successo anche con altri programmi (come Adobe Lightroom in fase di rendering delle anteprime, cosa che su un PC meno potente richiedeva il 100% delle risorse computazionali); l'operazione viene svolta abbastanza velocemente, ma senza richiedere il massimo alla CPU.

Se qualcuno potesse darmi una delucidazione gliene sarei grato

[AleLinuxBSD]

I casi possono essere diversi:
il compito è delegato a periferiche esterne alla Cpu;
in queste nuove Cpu con Gpu integrata gli algoritmi riescono ad utilizzarla;
oppure, al contrario, gli algoritmi sono così inefficienti da non riuscire ad usare al meglio le risorse disponibili nel sistema.
Quindi, nei primi due casi, significherebbe che ci stà si 5 minuti, ma tutto è ok, e potresti tentare di fare una prova usando solo la Cpu, per capire se l'operazione verrebbe fatta più velocemente.
Nel primo caso, disabilitando il driver della scheda audio esterna (se c'è l'hai).
Nel secondo caso vedendo se tra le opzioni disponibili del programma è possibile disabilitare opzioni di ottimizzazioni lato Gpu oppure ricompilando il programma senza le ottimizzazioni.
Nel terzo caso, invece non ci sarebbe niente da fare, a parte attendere che una nuova release fissi il problema.

[Lotharius]

Allora, la scheda audio è integrata e non incide sulla compressione. I due programmi che ho usato (CDEx e EAC ultime versioni) non hanno ottimizzazioni per uso di GPU o cose simili, però dovrebbero comunque supportare le istruzioni della CPU.
Probabile che a questo punto sia colpa dei codec non ottimizzati per processori potenti, però mi sembra una gran vaccata. Possibile che io sia il primo ad essersi accorto che non serve a niente avere una CPU potente, oppure non frega niente a nessuno?
Di seguito linko uno screen direi abbastanza eslicativo sulla situazione: conversione di 101 brani da FLAC a Mp3 (LAME 3.99 ultima versione), consumo CPU 1%, tempo rimanente circa 23 minuti... boh, basterebbero 20 secondi con CPU al 100%

[mentalrey]

Originariamente inviato da Lotharius

...
Mi è successo anche con altri programmi (come Adobe Lightroom in fase di rendering delle anteprime, cosa che su un PC meno potente richiedeva il 100% delle risorse computazionali); l'operazione viene svolta abbastanza velocemente, ma senza richiedere il massimo alla CPU...

Per i programmi grafici come quelli di adobe e' presto detto,
recentemente sono state aggiunte righe di codice che permettono
di scaricare parte del lavoro computazionale direttamente sulla GPU,
piu' performante per questo genere di calcoli, invece che sulla CPU.
Per l'audio la cosa sembra un po' strana, anche perche' parliamo di compressione
e non di un ricampionamento, che di solito e' effettuato direttamente all'interno
del chip audio.
Bisognerebbe leggersi le specifiche del programma, per vedere se per caso
stanno sfruttando qualche libreria DirectX che scrarica direttamente su hardware
o direttamente il chip audio, se disponibile, per effettuare quelle conversioni.
Oltre a quello c'e' da verificare se il calcolo e' programmato bene a livello di parallelismo,
oppure se e' ancora ancorato al processo singolo, perche' in quel caso di cpu
ne potresti avere anche 200, senza cambiare le tempistiche piu' di tanto.

[Lotharius]

Allora, a quanto pare il punto critico di questo problema riguarda esclusivamente il codec, mentre il programma che ne fa uso, la scheda grafica e altre librerie non c'entrano niente. Secondo quanto segnalatomi dall'utente blackshard, i codec in questione sono scritti senza tenere in considerazione la possibilità d'uso del' multithreading, quindi all'atto pratico non fa la benchèminima differenza l'uso di una CPU single core o octo core.
Pare che esistano delle versioni del codec ricompilate per l'uso ad hoc su CPU multicore, scaricabili al seguente indirizzo: OGG Vorbis Blacksword.
Il problema è che il codec ricompilato in questione è stravecchio, basandosi sulla libreria aotuv beta 5 risalente a ottobre 2006. Non sembra che esista una versione basata sulla più recente aotuv beta 6.03 di maggio 2011 (cazzarola 5 anni di differenza credo siano piuttosto rilevanti...). Quindi il punto sarebbe scegliere la velocità di encoding a costo della qualità o il contrario (visto che due release del codec distanti 5 anni avranno differenze qualitative sensibili, nei file prodotti).

Inoltre c'è sempre un "dettaglio" che non mi va giù: se il codec è scritto per funzionare in single thread, perchè il task manager visualizza tutti e 8 i core in stato di quasi-idle? A rigor di logica 1 degli 8 core dovrebbe essere sotto carico... e invece nemmeno quello.

...la cosa mi urta non poco.

[mentalrey]

per l'ultima parte non e' detto,
anche Win XP riesce a suddividere un processo single,
sui core della CPU che ha a disposizione,
ma chiaramente partendo dal presupposto che
il thread e' singolo, semplicemente non vedrai mai i core
lavorare a pieno regime, ma solo a meta' (nel caso di un dual)

nel tuo caso e' lo stesso, il processo splittato
fa' solo il solletico alla tua cpu e la tempistica
rimane quella di una cpu single core.
(certo che all'alba del 2012, potevano pure programmarlo con supporto SMP
quel codec)

[Lotharius]

Sono piuttosto seccato dal fatto che vari programmi e, nel mio caso, i codec audio non sfruttino a dovere l'hardware. Nel caso dei codec video si sono dati molto da fare per quanto riguarda la parallelizzazione (anche perchè i flussi video HD sono dei mattoni immani da codificare), mentre l'ottimizzazione dei codec audio è rimasta ferma a 5 anni fa (che è un'era geologica in informatica...).
Alla fine sono sempre più convinto che spendere soldi per una piattaforma hardware di fascia alta sia uno spreco: non solo la CPU viene messa sotto carico per lassi di tempo ridottissimi rispetto al tempo che passa in idle, ma quando serve il 100% della potenza nemmeno si riesce a spremere a dovere...

Peccato che abbia fatto il cambio generazionale di PC (che faccio ogni 7 anni ) prima dell'uscita di Trinity, alla luce di quello che sto sperimentando attualmente credo che avrei preferito la piattaforma AMD. Certo, un sistema con i7 2600k, 16Gb di RAM, SSD e chi più ne ha più ne metta, mi durerà sicuramente un sacco di tempo, però chissà quanto ancora ne passerà prima di poter sfruttare davvero appieno tutto questo ben di dio