Newsgroup: it.comp.macintosh
Titolo: ancora sulle prestazioni intel/PPC

...per un'applicazione "reale": una libreria C per il gioco delle mani
di bridge "a doppio morto" ("double dummy"), di cui ho avuto i sorgenti
per accordo con l'autore per farne il porting a MacOSX (originale
solo-Windows, comunque distribuito gratuitamente ma solo come DLL, i
sorgenti l'autore vuole tenerli segreti).
Come porting ne ho fatto un'extension module per Python, quindi
automaticamente Universal senza fatica.  Il mio primo e principale uso
e` per le mie solite ricerche statistiche sul bridge: devo far "giocare"
al programma migliaia e decine di migliaia di smazzate per verificare la
distribuzione statistica dei risultati in certe condizioni.  Le
prestazioni sono dunque molto importanti; se ogni analisi prende anche
solo 1 minuto (quello che ci metteva circa il miglior programma che ho
usato sinora per questo scopo), 10,000 smazzate sono 160+ ore, quindi
molti giorni di lavoro "batch".
Questa nuova libreria e` fantastica (usa algoritmi non pubblicati che
faccio persino fatica a seguire, pur essendo ben ferrato su questa
specialistica materia!): tempo medio di analisi 0.64 secondi sul Macbook
Pro 2.0 GHz; sul Powerbook G5 1.8 GHz (dual, ma sto usando comunque un
solo processor/core visto che non ho [ancora] nessun multithreading nei
sorgenti), per le stesse identiche smazzate il tempo medio di analisi e`
0.80.  (Incidentalmente: sull'iBook G4, il tempo e` 1.12).
Questo programma macina solo ed esclusivamente CPU, non trae nessun
beneficio dai 64 bit, usa abbastanza poca memoria, ecc ecc.  Mi
aspettavo rapporti ben diversi e piu` estremi, sia fra MBP e G5, sia fra
G5 e G4 (cavolo, il G4 e` a 1.2 GHz: anche il solo rapporto fra i clock
suggerisce che, se il G5 ci mette 0.80, il G4 dovrebbe metterci
1.20...!).
Comunque, io mi limito a riportare i numeri (che per i miei scopi vanno
benissimo: posso dividere il lavoro fra le varie macchine e fare 10,000
smazzate ogni ora circa...!-).
Alex

Sono ot ma il bridge è un gran bel gioco...
Menomale che esiste 

 Menomale che esiste 
Dillo a me!  Elenco i miei due articoli su "Bridge World" come il
risultato di cui piu` sono orgoglioso (in una vita ricca di trionfi piu`
strettamente professionali), e sospetto che la lettera dell'Editor della
prestigiosa rivista in questione (un PhD in matematica di un certo peso)
che spiegava diffusamente perche` e percome i miei risultati erano di
eccezionale importanza storica abbia avuto il suo peso sul conferimento
del mio visto O1 "alien of exceptional skills".  Tempo di giocare, poco,
ma ogni tanto Adam Wildawski (giocatore a livello campionati del mondo,
assunto in Google, ahime` a NY, piu` o meno assieme a me) visita
Mountain View e qualche partitina ce la facciamo;-).
Tornando in-topic: OKBridge gira bene su tutti i Mac (ma costicchia).
Bridgebase Online, solo-Windows, gira bene sui Mac-Intel con Parallels
Workstation, ma ogni tanto si pianta (occorre reboot virtuale della
macchina virtuale, sigh).  Se sei attivo su OKB o BBO mandami una mail
(l'indirizzo 
mac.com
 del From e` valido) che ci si mette d'accordo per
una partitina...
Perche` e percome ho finito per mac.com-izzarmi e` un'altra storia,
legata a un tizio che ha dato un passaggio a me e a mia moglie nel
lunghetto viaggio da Oakland a Freemont (risparmiandoci non pochi
dollari e parecchio tempo di BART), magari la racconto un'altra
volta;-).
Alex
 

 sul Powerbook G5 1.8 GHz (dual, 
[cut]
Ma allora li avevano fatti i pb g5! ;-)
-- 
"I can accept failure, everyone fails at something. 
But I can't accept not trying." (M. Jordan)

sorgenti l'autore vuole tenerli segreti).
Stai parlando di Deep Finesse? Per me NUMERO UNO , come direbbe Dan
Peterson :-)) Lo usano anche i commentatori sul vugraph di BBO .
Purtroppo non gira suMac, ma io ho anche il PC:-))
gummo


Chiedo scusa a tutti per l'OT ..
A parte il costicchiare che, tutto sommato e' il meno (l'associazione
a un circolo costa molto di piu' e spesso, se non abiti in una grande
citta',  fai fatica a creare un tavolo decente ...) , trovo OK bridge
molto piu' snob e frequentato da gente (americani soprattutto)
maleducata e con la puzza sotto il naso e che si credono grandi
campioni. BBO oltre a essere gratuito, offre un'infinita' di
possibilita' di gioco: tornei a coppie gratuiti o a pagamento (1 $ di
iscrizione!) a qaulsiasi ora del giorno e della notte, partite libere
anche per soldi, duplicati, lezioni on line, training rooms di licita,
ecc...Trovi tutte le piu' importanti manifestazioni in diretta
commentate da grandi campioni e molto spesso trovi on line gente tipo
Benito Garozzo che gioca con sconosciuti tipo Versace, Lauria, Bocchi
o Duboin :-)) o Omar sharif, Dano De Falco, ecc..
Peccato solo che Fred Gitelman , piu' volte sollecitato da molti, non
voglia svilupparlo anche per Mac :-((
Mentre ti sto scrivendo sto "kibitzando"  in diretta la finale
dell'hungarian cup commentata da Roland Wald e Bill Jacobs :-)
Ti mando in mail i miei nick, se hai voglai di fare qualche volta 2
mani.-)
gummo

 Ma allora li avevano fatti i pb g5! ;-)
Ooops, typo per Powermac!
Alex

 wrote:

Sono in contatto anche con l'autore di Deep Finesse, che sarebbe piu`
comodo perche` abita a due passi da me qui a Palo Alto (oggi fa il Chief
Architect per la Netsuite a San Mateo, il che spiega perche` non ha
proprio tempo per Deep Finesse;-), e senza dubbio riusciro` prima o poi
a portarlo a pranzo a Google (gia` Google e Netsuite collaborano nel
settore enterprise...) e forse a convincerlo a darmi i sorgenti per il
porting a Mac e Linux, vedremo.  Comunque, Deep Finesse e` un prodotto
commerciale.
Ma per ora lavoro con Bo Haglund, lo svedese autore di DDS, che e`
distribuita gratuitamente (ma non e` open-source).
Alex

 mani.-)
Li attendo volentieri (per ora non ricevuti, a meno che non sia 
mac.com
a giocarmi scherzetti...).
Alex


hai il link da dove scaricare il programma?
ciao
Gummo

 0.80.  (Incidentalmente: sull'iBook G4, il tempo e` 1.12).
quindi rapportando al gigahertz
avremmo 
1,28 per un core del duo
1,44 per un g5
e un sorprendente
1,344 per il g4 
mambol mambol :-)

 e da li` puoi
scaricare la DLL per Windows e trovi link anche alla semplice
documentazione (RTF) e al sito di Bob Richardson (l'autore di
BridgeMate, offre anche il gratuito Double Dummy Solver che e`
praticamente una veste GUI sulla DLL di Bo, solo Windows).
Le versioni per MacOSX (e anche in futuro quella per Linux, ho avuto il
permesso da Bo!) saranno scaricabili da 
www.aleax.it
 quando le avro`
messe bene a posto e avro` scritto un minimo di documentazione.
Quello che ho costruito e` un modulo Universal di estensione per Python,
basato sul release Universal di Python 10.4.3; al momento "espongo" solo
la possibilita` di giocare N prese "complete" (cioe` non ho ancora
aggiunto la funzionalita` di forzare la prima delle N prese a _iniziare_
in un dato modo, per verificare gli effetti della scelta di un attacco
piuttosto che di un altro, ma ho intenzione di farlo in futuro). Non so
bene quali altri tipi di "DLL" potrebbero servire su MacOSX (dynlib?
bundle? framework? onestamente le differenze non mi sono chiarissime, so
che per Python serve specificamente un bundle ma non ho mai approfondito
oltre il tema), chiedero` feedback (qui e su rec.games.bridge) quando
rendero` disponibile la prima versione.
Alex

 wrote:

In effetti non so bene come interpretare i numeri.  Adesso, con un
numero enorme di smazzate, i tempi in secondi per smazzata sono 0.65 per
MBP 2.0 GHz, 0.90 per Powermac 1.8 GHz, 1.26 per l'iBook G4 12" 1.33
GHz; MBP e PM possono essere lievemente svantaggiati dal fatto che su di
essi sto usando due copie indipendenti del programma (cosi` da tenere al
100% entrambi i processori/core), c'e` un minimo di overhead di
commutazione ecc, ma come accennavo il programma e` praticamente pura
CPU -- pochissimo disco, poca memoria, pochissimo display.
Moltiplicando secondi e GHz per ottenere una figura di merito
adimensionale ("migliore se bassa", poiche` una FDM piu` bassa implica
tempi di calcolo minori, o tempi di calcolo pari ottenuti con meno
GHz!), detta FDM e` ora 1.30 per l'MBP, 1.62 per il G5, 1.68 per il G4;
questo suggerisce che (per un programma che non usa comunque i 64 bit)
G4 e G5 sono assai paragonabili (a parita` di clock), mentre il Core Duo
e` (sempre a parita` di clock) un pochino migliore per questo compito,
ma a livello di un 20-30% (secondo cosa prendi come denominatore;-), non
le "4-5 volte" decantate nelle pubblicita`.
Alex

 le "4-5 volte" decantate nelle pubblicita`.
Giusto per curiosità, con quali cflags hai compilato (soprattutto su
PPC)?
-- 
In a minute there is time for decisions and revisions which a minute
will reverse
T.S. Eliot

 le "4-5 volte" decantate nelle pubblicita`.
Ok ma la pubblicità non dice che è 4-5x rispetto al G4 a parità di
clock, ma che è 4-5x rispetto alla precedente generazione, quindi G4
1,33 VS Core Duo 2,00 Ghz...e penso che in condizioni ideali, quindi con
sfruttati entrambi i core, sia vero.

 wrote:

Mah, puo` darsi; ma non mi pare che i Powerbook di ultima generazione
fossero solo a 1.33, io ricordavo 1.67.  Quindi, con un fattore 1.2 per
il clock, idem per l'architettura (facciamo 1.25, media ragionevole), e
due per il dual core, 1.2 * 1.25 * 2 == 3.  Bah, immagino che
trasformare un fattore 3 (reale) in un fattore 4-5 (ipotetico) non conti
neppure come pubblicita` ingannevole;-).
Alex

 PPC)?
Quelli che usa automaticamente "python setup.py build_ext":
brain:~/Documents/dds alex$ python setup.py build_ext -i
running build_ext
building 'dds' extension
creating build/temp.macosx-10.4-fat-2.4
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-fno-common -dynamic -DNDEBUG -g -O3
-I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c
dds.c -o build/temp.macosx-10.4-fat-2.4/dds.o
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-fno-common -dynamic -DNDEBUG -g -O3
-I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c
Unit1.cpp -o build/temp.macosx-10.4-fat-2.4/Unit1.o
c++ -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -g
-bundle -undefined dynamic_lookup build/temp.macosx-10.4-fat-2.4/dds.o
build/temp.macosx-10.4-fat-2.4/Unit1.o -o dds.so
Alex

 sfruttati entrambi i core, 
e in favore di vento
-- 
questa non e' una tag

 le "4-5 volte" decantate nelle pubblicita`.
l'anima dello smercio (termine piu' adatto alle sostanze stupefacenti,
jobs infatti vende *separate realities*) ;)

 neppure come pubblicita` ingannevole;-).
Si hai ragione tu, stavo pensando agli iBook io :)
Cmq ovviamente loro parlano di 4-5x solo per alcune app, ce ne sono
alcune che (probabilmente perchč meglio ottimizzate per x86) vanno
davvero mooolto + veloci, mi vengono in mente tutte quelle basate su
java, che su intel ora schizzano, su g4 erano un pianto, e probabilmente
č a causa dell'architettura differente (quindi della VM meglio
ottimizzata)
Poi č ovvio che sono valori teorici di picco con vento a favore, perň in
alcuni casi secondo me ci si avvicina piů a questi che non al 20-30% in
+ che dicevi tu :)  

P.S. Io perņ al contrario tuo non ho fatto alcun test, sono solo
senzazioni a pelle, quindi magari dico scemenze eh :)

P.P.S. Ad esempio, nel campo dell'encoding DivX/H.264, secondo me siamo
molto vicini al 4-5x rispetto ai PB precedenti, tieni conto che
addirituttura un MBP 2.16 va più veloce del QUAD 2.5...
I core duo sono davvero ottime CPU :) 

 le "4-5 volte" decantate nelle pubblicita`.
Da ignorante: le 4-5 volte non sono relative a questa "figura di merito
adimensionale", bensì alla macchina intesa nella sua totalità, quindi alla
prestazione della macchina (e non del processore) "a clock pieno", con
processi che sfruttano entrambi i core, e magari con sw ottimizzato.
Qualcosa di simile vale anche per il confronto G4-G5, soprattutto in virtù
dei 64 bit (che ci sono, ma se non sono sfruttati e come se non ci
fossero...)
ciao
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 due per il dual core,
Domanda ingenua: il fatto che la cache di secondo livello sia condivisa
incide poco su quel 2 o no?


 le "4-5 volte" decantate nelle pubblicita`.
Sono MESI che dico che gli Intel brillano nei test ma in real life, i 
G4 erano a fine vita ma non pezzi da museo! Un 20-30% è realistico.

 le "4-5 volte" decantate nelle pubblicita`.
*sospiro*
-- 
I've always been more concerned with users. )\._.,--....,'``.
Programmers do their work but once, while  /,   _.. \   _\  (`._._,
users are saddled with it ever thereafter. `_.-(,_..'--(,_..'`-.;.'

 incide poco su quel 2 o no?
Nell'applicazione che stavo girando (simulazioni di gioco di bridge a
doppio morto), apparentemente poco -- il tempo medio per smazzata per
processo non varia in modo misurabile (grosso modo fra 0.64 e 0.65
secondi) sia che ci sia un solo processo in esecuzione, o due.
Alex

 wrote:

ma ce la dici che impronta in memoria ha questo processo?
tanto per capire se misuriamo le praestazioni delle integer unit+ cache
o anche + bus e memoria

 wrote:

Bus e memoria giocano un pochino, secondo me.  Cmq:
questa e` la linea di `top` relativa al processo in questione:
9549 Python     100.0%  0:44.53   1    14    41  12.1M  4.31M  13.2M
172M 
 
("Python" e` il nome del processo, ma quel 100% di CPU/core va tutto
all'extension module che fa le analisi a doppio morto).
Altra visualizzazione, stesso processo:
brain:~/Documents/dds alex$ ps -v -p 9549
  PID STAT      TIME  SL  RE PAGEIN      VSZ    RSS   LIM     TSIZ %CPU
%MEM COMMAND
 9549 R+     3:19.00   0 1236      0   176996  16084     -        0
99.1  0.8 /L
Se ci sono altri comandi per mostrare quella che tu chiami "l'impronta
in memoria" dimmeli pure e li eseguiro` volentieri.  In particolare, non
so come farmi mostrare l'uso di cache da parte di un processo.
Cmq, in una macchina con 2GB poco carichi, anche i 172MB di vsize di
questo processo dubito che importino.
Alex

 questo processo dubito che importino.
se importassero l'ibuc col disco a 4200 dovrebbe uscirne morto ...

 se importassero l'ibuc col disco a 4200 dovrebbe uscirne morto ...
Perche`?  Ho 2GB su tutte le macchine, il disco NON e` in gioco.
Alex

 Perche`?  Ho 2GB su tutte le macchine, il disco NON e` in gioco.
Oops, sorry, sull'iB "solo" 1.5 GB, ma tanto, che cambia?!
Alex

 Perche`?  Ho 2GB su tutte le macchine, il disco NON e` in gioco.
se la vsize e' diversa dalla size non significa che ci sono pagine
swappate out? 
in tale caso se il programma accedesse a tali pagine il disco ne
pagherebbe le conseguenze, e' probabile invece che siano buffer di
qualcosa che mentre stai tritando non vengono accessi
il mio pbuc ha 1.5 giga ma la somma delle vsize e' sempre maggiore, non
ho mai capirto che sarcazzo si allocano sti processi...

 G4 erano a fine vita ma non pezzi da museo! Un 20-30% è realistico.
Quoto.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 ho mai capirto che sarcazzo si allocano sti processi...
Spero che questi brevi cenni a vmmap e alle strutture di malloc possano
aiutare.  Su wikipedia e altri testi trovi varie trattazioni sulle
implementazioni di malloc, ma di solito non entrano a fondo nei dettagli
che puoi esaminare studiando i sorgenti di varie librerie opensource.
Piu` specifico per Apple (ma solo in parte) un lungo thread di qualche
anno fa su darwin-development, titolato in parte "VM implementation
questions" e in parte "faster malloc implementation"; il primo dei post
con questo secondo titolo e` a
<
http://lists.apple.com/archives/Darwin-development/2003/Apr/msg00227.ht
ml> -- buona lettura!
Alex

 non ha usato. 
rimane da spiegare la crescita dello/gli swapfiles 
probabilmente si riserva spazio pure li', oppure una volta che l'ha
usato e non ne ha piu' bisogno non li riduce a dimensioni piu' piccole
ma *prevede* di doversi riallargare

 ma *prevede* di doversi riallargare
si, mi pare proprio che mac os non riduca mai gli swapfile, salvo al riavvio
della macchina.
o sbaglio?

 ma *prevede* di doversi riallargare
Non credo che "stringa" mai lo swapfile nel corso di una sessione.  E
(non so, tiro a indovinare) puo` comunque riservare swapfile al momento
della mmap (o equivalente) per evitare strani crash "avanti nel tempo" a
disco pieno (AIX una dozzina+ d'anni fa mi faceva impazzire, con quel
viziaccio dell'"overbooking" della VM...).
Alex

 0.80.  (Incidentalmente: sull'iBook G4, il tempo e` 1.12).
...e, tanto per riferimento, su un Pentium 4 a 3.20 GHz (con Linux):
0.88.  (E` un altro release di gcc, 3.qualcosa e non 4.qualcosa, non so
che frazione delle differenze possa essere spiegata da migliorie di gcc
4).  Sempre piu` curioso, disse Alice...
Alex

 Quoto.
Nella codifica di file divx il mio MBP 2 Ghz va piu` veloce del mio powermac 
dual 2 Ghz. entrabe le macchine hanno 2 giga di ram.
sempre per fare un paragone il mio portatile precedente un powerbook AL 1.67 
Ghz con 1.5 giga di ram codificava lo stesso file con le stesse impostazione 
in circa il doppio del tempo che ci metteva il powermac, ed ha volte anche 
piu` lento.
Senza contare che il MBP pur codificando il file rimane molto piu` reattivo 
rispetto al powerbook AL.
-- 
Riccardo Saettone
Per rispondere togliere Alfa e Beta dall'indirizzo

 rispetto al powerbook AL.
Su questo ho i miei dubbi.


 dual 2 Ghz. entrabe le macchine hanno 2 giga di ram.
Considera anche che il tuo è un PM che monta un G4 pompato. Un dual G4
1,5Ghz con L3 va molto meglio. Quanto alal codifica perché non provi ad
esportare in MPEG4?
Giusto per renderti conto di quanto i codec DivX siano poco ottimizzati
per Mac (sia in codifica che in decodifica).
-- 
"Imagination is more important than knowledge"
Albert Einstein 
1879-1955 

 4).  Sempre piu` curioso, disse Alice...
Sarebbe da vedere un AMD Sburlon[0] di nuova generazione.
------
[0] Nome fittizio "puntatore" per indicare appunto l'ultima serie di
processori high-end di AMD, che si riposiziona quando ne escono di
nuovi.


 Su questo ho i miei dubbi.
Beh se la codifica occupa un solo core ne resta un altro libero.
-- 
In a minute there is time for decisions and revisions which a minute
will reverse
T.S. Eliot

 Su questo ho i miei dubbi.
Questo e` un tuo problema :)


 per Mac (sia in codifica che in decodifica).
I codec divx sono un po' schifosi da questo punto di vista ma quelli di 
ffmpegX no.





 Beh se la codifica occupa un solo core ne resta un altro libero.
Non è scontato. Potrebbe benissimo lavorare con entrambi i core.
Ad ogni modo siccome il mio G4 anche a pieno carico è fluido, dubito che
possa essere "più fluido".


 su cui si basa e` dato da mencoder e ffmpeg.
Appunto. Le versioni per x86 sono *tremendamente* più ottimizzate. Si è
sempre saputo.


 possa essere "piů fluido".
Ho avuto sia il powerbook G4 sia il MBP e la differenza tra l'uno e l'altro 
con ffmpegx che codifica e` avvertibile.
Ovviamente se ti limiti ad usare il finder la noti poco ma se 
contemporanemante fai altre cose, word o photoshop o Graphic Converter la 
differenza la senti. 


 dirlo.
Ecco questo è già parecchio differente... pensavo usassi QT con i codec
DivX® (chetra l'altro fanno schifo pure sui Mac con Intel rispetto alla
versione per Windows).


 sempre saputo.
Ma i sorgenti sono gli stessi ?
Cioe` il sorgete da cui si parte per compilare ffmpeg per Mac/intel e` 
assolutamente lo stesso da cui si parte per compilare con ffmpeg per 
win/intel ? perche` da quello che avevo capito io leggendo il forum di 
ffmpegx le differenze c'erono.
Comunque anche se lo fosse sarebbero diversi i compilatori ed questo puo` 
fare una verta differenza.
 
Infine ffmpegx per G5/G4 non e` certo una ciofeca visto che tra l'altro che 
e` comunque piu` veloce dei codec quicktime mp4.
e sul mio G5 codifico ad una velocita` piu` che doppia rispetto al powerbook 
G4 ci sono degli scarti in piu` o meno a seconda del tipo di codifica 
utilizzata.
comunque alla fine il risultato ultimo e` che lo stesso filmato con gli 
stessi parametri codificato dalla stessa versione di ffmpegx viene codificato 
in minor tempo dal MBP 2 Ghz rispetto al G5 dual 2 Ghz.


 dual 2 Ghz. entrabe le macchine hanno 2 giga di ram.
Potresti provare per piacere a fare encodare sia al MBP che al powermac
due file divx contemporaneamente e  vedere chi la spunta? Con il mio
dual 2 ghz ottengo con ffmpegx risultati ottimi codificando più file
simultaneamente, così sfrutto appieno i due core, con un solo file i due
core non vanno oltre il 60/65%.
Pippo

 in minor tempo dal MBP 2 Ghz rispetto al G5 dual 2 Ghz.
Ottimo: ma questo è si funzione del processore, ma anche e soprattutto
funzione del codice.


 versione per Windows).
Dalle prove che ho fatto io vanno meglio, rispetto a quelli PPC, ma sono 
comunque molto inferiori rispetto a quelli win ed infatti il forum e` pieno 
di utenti scontenti di questa cosa.


 core non vanno oltre il 60/65%.
Una cosa del genere l'ho fatta perche` volevo vedere come si comportava il 
core duo con due task simultanei, il risultato e che ci impiega un po` piu` 
del doppio del tempo, un risultato simile lo ebbi quando feci la stessa prova 
sul G5.
In pratica non conviene mandare due task contemporaneamente, almeno con le 
prove che ho fatto io, c'e` da dire che i binari di ffmpeg vengono aggiornati 
spesso quindi magari questo specifico test andrebbe rifatto.
Non ho pero` cronometrato le due prove quindi non ti posso dire se si 
mantiene la differenza di tempo rispetto al task singolo.
Tieni pero presente una cosa, quando io do due codifiche contemporanee a 
ffmpegx questi non utilizza un processore per ogni codifica ma suddivide i le 
due codifiche tra i due processori.
Comunque mi sembra che sul forum di ffmpegx a suo tempo ci fu chi ne parlo` 
ampiamente.


 funzione del codice.
Sarebbe interessante sapere quanto incide l'uno e quanto incide l'altro.
Magari l'autore di Graphic Converter potrebbe saperlo visto che ha portato la 
sua applicazione da PPC a intel.


 di utenti scontenti di questa cosa.
Confermo.


 Confermo.
Anche perche` gli ultimi algoritmi che hanno implementato per PC sono 
spettacolari in pratica hanno raddopiato il framerate di codifica, ed in 
alcuni casi sono andati anche oltre.
