Compressor e Leopard in Slow Moton!!


Vla
 Share

Recommended Posts

Bè, dovessero fare un Mac il doppio più veloce del Ns, per vedere che le cose poi sicuramente rimangono così (sfruttamento dell'hardaware legato solo alla velocità della cpu....ndt), rimango dove sono e me ne frego. Le tasche si alleggeriscono sempre e cmq, quindi.....poi dopo che ho scoperto che il chipset X5000 montato sui MP e sui server può indirizzare ben più propriamente "solo" 64GB di RAM FISICI!!!!!! posso solo augurarmi che le prossime versioni dei programmi ne sappiano fare un LARGO uso....tutto a scapito della velocità, visto che il ns Mac è una di quelle Workstation a godere dell'accesso alla memoria a larga banda da 256bit!!! Molte delle attuali macchine vanno dai 64 ai massimi 128bit.........come definito anche dai nuovi chipset X7000...... e allora?

Link to comment
Share on other sites

  • 6 months later...
  • Replies 35
  • Created
  • Last Reply

Top Posters In This Topic

Test fresco di giornata come le uova (più o meno).

Finito un progetto in DV, della durata di 28 minuti, l'ho esportato in MPG2 con compressor scegliendo l'opzione best quality 90 minuti.

Questi i risultati: 21 minuti per convertire il video e 6 minuti per l'audio per compleessivi 27 minuti.

Un minuto in meno della durata del progetto.

Che dire: mai vista tanta velocità!!!!!!

Qualcuno mi spiega perchè con Tiger i tempi di render erano inferiori?

Dimenticavo di dire che ho un MP 8 Core con 8gb di Ram, quindi potenza ne ho a sufficienza.

Grazie.

Link to comment
Share on other sites

L'architettura dei "nuovi MacPro" ) 2008, non differisce molto da quella del 2007, sempre con 8 core. Ottimizzazioni interne ai vari core e la produzione a 45n ha portato a dei benefici; una domanda è lecita: quanti se la differenza tra l'8 core 2007 e l'8 core 2008, entrambi a 3Ghz, è talmente sottile che anche con Compressor è nell'ordine di secondi su 30 minuti di calcolo intensivo?

Per poter spremere le CPU bisogna scrivere codice che le sappia sfruttare a dovere.

Faccio un esempio, che potrebbe sembrare banale ma dà da pensare.

Qualche annetto fà, acquistai la versione 4.2 di Cinema4D per Amiga; all'epoca non era ancora approdato nemmeno sul PC. Nel CD erano presenti 2 versioni, l'eseguibile, del programma; 1 per CPU senza FPU (fino al Motorola 68030 la FPU era una cpu fisica a parte) e 1 per FPU. Quest' ultima richiedeva necessariamente l'unità di calcolo in virgola mobile (FPU) oppure una cpu superscalare (M68040 -M68060) con FPU integrata.

Questi processori erano ben superiori alla controparte Intel poichè interamente a 32bit (dal 68020 in su lo erano completamente, sia internamente che a livello di registri, mentre il 68000 lo era solo internamente) unica pecca per avvantaggiarsi dell'enorme potenza di calcolo, dell'epoca, era di strutturare il codice FPU in modo che si avvantaggiasse della tecnica superscalare che eliminava in parte alcune tecniche hardware presenti sulle FPU esterne.

Amiga aveva dalla sua un sistema operativo flessibile e potente; una cartella di sistema, chiamata LIBS, conteneva appunto dei file "libreria" che servivano ( a mo' di DLL su Winzoz) ai vari programmi per avvantaggiarsi di "pezzi" di codice scritti ad HOC.

Fin dalla sua prima comparsa (OS1.0) era presente una serie di librerie matematica a 32bit che col tempo sono cresciute e ottimizzate col sistema.

In particolare con la relase 2.0 del Workbench era comparsa una libreria chiamata 68040.library che conteneva varie patch e ottimizzazioni per far funzionare meglio il sistema, diversamente era facile che il sistema si bloccasse. LO STESSO PROBLEMA con l'adozione del 68040 lo ebbe anche il MAC dell'epoca, appunto per una questione legata alla cpu.

Dopo questa cucagna, scusate, fu rilasciata una libreria matematica creata ad hoc per le cpu 040/060 che dava la spinta a tutti quei programmi che facevano largo uso della FPU, dimezzando, in certi casi, i tempi di calcolo. Ma il salto, all'epoca, era di molto.

Intel, dalla sua, ha dimostrato come le cpu con SS4 si possono avere salti di potenza pura pari del 50%, sempre che si usi codice con le palle.

Ora mi chiedo e Vi chiedo, se uscisse codice che spinge le ns macchine di così tanto........chi le comprerebbe quelle NUOVE?

Perchè brand come Nvidia spinge l'architettura CUDA, in visone da APPLE da tempo, che permette calcoli matematici sfruttando le GPU....? Solo perchè sono più potenti oppure per spingere su codice altamente ottimizzato che è più facile da ottenere rispetto ad una nuova GPU, che invece richiede almeno 2 anni tra progettazione e test.....

A voi le conclusioni.

E se la pensate come me, forse VI renderete conto, perchè esiste ancora una folta schiera di appassionati di Amiga.........

Link to comment
Share on other sites

Kibiz...

io non capisco, se a volte ci fai o ci sei....nel senso ironico e spiritoso, ovviamente!

Se le SS sono INUTILI, aiuta chi legge a capire il perchè, visto che ti stai confrontando con un nomignolo da poco, Intel.

Sembra, a tuo dire, che non credi ad ottimizzazioni di codice, non credi a software che è in grado di svegliare dell'hardware, ti viene dimostrato che Leopard ha rallentato Compressor, rispetto a Tiger e poi...dici di lasciare le librerie "matematiche" nel cassetto.

Quando si afferma qualcosa, che sia sbagliato o giusto, è bene dare risposta, ma, per rispetto, non una risposta sintetica e poco chiara.

Io non posso dire che tu non mi sembri un programmatore ma se lo affermassi, dovrei anche dire il perchè... non credi?

Non so quanti anni hai, e se mai hai conosciuto, in senso stretto Amiga, e non dico giocando a Super Frog (bellissimo gioco ineguagliato ancor oggi)...ma da programmatore spigliato e "padrone" del proprio mezzo...perchè dire di lasciare una parte di una storia informatica dentro un cassetto sarebbe come insultare mostri sacri che hanno buttato le fondamenta di ciò che usiamo oggi...

Non prendertela, mi raccomando, Kibiz.

Spiega a noi, secondo te, perchè usare le SSE4,non porta a giovamenti, anzi a rallentamenti. Smentisci, non me, ma Intel... ( per chi non lo sa ricordo che è una parte hardware delle CPU dei MacPro, iMac e MacBookPro del 2008, ottimizzata per la gestione e velocizzazione di codice multimediale )

Ciao

Link to comment
Share on other sites

Io riporto solamente quello che alcuni sviluppatori di x264 hanno detto. Poi per esempio gli sviluppatori dei codec divx le hanno usate per la ricerca del moto, ma hanno dovuto riscrivere tutto l'algoritmo per funzionare in un altro modo.

Non dico che le ottimizzazioni usando sse siano inutili, solo che non puoi usare ogni qualunque funzione di sse in ogni situazione… e quelle aggiunte nell'ultima versione non aiutano particolarmente al momento certi codec video.

Comunque sse sui penryn è già più veloce di suo, richiedendo meno cicli per varie istruzioni.

E per tornare a Compressor, i problemi li ha solo lui. HandBrake non ha avuto nessun calo di prestazioni su leopard, anzi.

Se apple non sa far funzionare i suoi programmi sui leopard non è colpa del team di mac os x…

E per rispondere a un tuo messaggio di qualche tempo fa, il kernel di leopard è in gran parte a 32bit,

Un sistema operativo può far funzionare benissimo un programma a 64bit con un kernel a 32bit, opportunamente modificato ( http://macguild.org/wwdc/wwdc06.html#Kernel ).

Link to comment
Share on other sites

Parto dal fatto che NON SONO un programmatore...ma come te leggo in giro qui e là e confrontarmi con chi ne sa qualcosa è una cosa che mi piace...

Non li ha solo Compressor, anche Mpegstreamclip ha calato la palpebra...ma qui la domanda comune: xké su Leopard questo calo?

E' vero che oggi si programma con le scarpe ma invece di migliorare si va indietro...c'è chi ha 8 core seduti a mangiare corrente cavolo !!! Senza parlare delle GPU.

Che un sistema operativo a 32bit può far girare un prg a 64 ne ho già avuto prova (si....sempre sul mitico AMIGA!!); dico solo che ci danno sempre le bricciole... che palle!

Senti, ma tu saresti in grado di sviluppare codice per usare alcune parti delle GPU?

Link to comment
Share on other sites

Ciao ragazzi,

non so se il mio post sia totalmente pertinente perché ho un pò perso di vista la discussione, ma la cosa mi sembra interessante:

da quando ho il mac pro 8 core, nvidia geforce512, e 6gb ram, ho visto, tranne in particolari casi, final cut pro sfruttare solamente il 15/20% dei processori...le prestazioni per carità, rispetto al mio vecchio iMac erano comunque notevoli, ma ciò la diceva lunga sullo sfruttamento dell'hardware...

in questi giorni lavorando ad un progetto ho notato che i processori durante i render erano sempre dal 50 al 60%...nient'altro di significativo aperto...che gli aggiornamenti vari usciti in questi tempi abbiano fatto qualcosa o solamente un caso? il progetto in questione aveva un formato molto particolare "custom", ma non mancherò di controllare le prestazioni nei prossimi giorni durante l'editing di un progetto in dv pal...

bye

Pode

Link to comment
Share on other sites

visto che sono gia andato un po fuori tema concludo in bellezza:

Io ho problemi con le prese firewire e mi pare che questi siano comparsi proprio in coincidenza con l'arrivo di leopard...problemi di stabilita delle firewire, per cui mi si sconnettono i dischi connessi, il sistema non è in grado di riconoscere le periferiche, oppure mi si interrompe l'acquisizione dalla videocamera...

questi fenomeni accadono relativamente di rado, non sono frequenti come puo sembrare dal post, ma accadono su ben 3 mac diversi, un iMac G5, un Macbook Pro SR 2,4 e un Mac Pro 8 core...

Ovviamente anche con diversi cavi, diversi HD, diverse videocamere...

bye

Pode

Link to comment
Share on other sites

Leopard ha portato anche problemi con le chiavette USB, diventate paurosamente lente, mentre sul versante PC (sullo stesso Mac) vanno molto bene.

Snow Leopard non sarà nulla di ultra rivoluzionario ma implementerà quello che non hanno inserito in questa release, per problemi di tempo non credo, ma per sfruttare di + il mercato.....

QT 7.5 a me ha portato problemi di visualizzazione a schermo intero, con vistose blocchettature sulla parte dx dello shermo, all'amico GIUFED incompatibilità col box Matrox...da impazzire.

Non parliamo di SPACES, che mi incasina FC che è un piacere: mi ritrovo le finestre sparse per i vari desktop.

Livetype ha scelto di non renderizzare più gli sfondi...

Motion che per un cavolo di rendering ci mette 10 min MINIMO....

I problemi che hai tu PODE mi sanno di QUICKTIME...

CMQ come ho già postato, gli 8 core sarebbero utili con Compressor, FC ecc ecc, se li sfruttassero a dovere...;come afferma Kibiz, alla Apple dovrebbero PROVARE i software e colmare queste lacune velocistiche e magari poi delle cazzate come quelle di SPACES o iCalc.

Già il solo pensiero che una cpu fisica con 4 core non è altro che una mera coppia di xeon di precedente generazione messe dentro un unico scatolotto...perdendo di efficienza nei calcoli paralleli...per questo vedi le tue 8 cpu grattarsi...non centra il formato del progetto. Per utilizzare bene le nuove CPU, ogni prg dovrebbe essere ricompilato exnovo e anche i tool di compilazione devono essere aggiornati tenendo conto delle nuove caratteristiche hardware. Invece ci si affida quasi sempre e cmq alla nuova spinta che quasi sempre un nuovo hardware di per sè porta. E' un pò come far girare un gioco di 4 anni fà sulle schede di oggi.....

Link to comment
Share on other sites

Mi inserisco in questa discussione,

un po' pepata

aggiungendo il mio bit ;-)

Molti dei programmi che fanno che le codifiche usano in realta' gli stessi codec che sono presenti nel sistema...

questa potrebbe essere la spiegazione del fatto che avete visto rallentamenti in Compressor ed in altri programmi di codifica...

usano tutti lo stesso codec sviluppato da Apple e, credo, inserito in QuickTime...

probabilmente Apple nello sviluppare il codec per Leopard ha fatto un codice meno efficiente di quello per Tiger (potrebbero esserci degli effetti a cascata, visto che il codice Apple tende a riutilizzare le librerie ....).

Altri programmi (come Handbrake) invece utilizzano dei codec esterni (ed indipendenti dal S.O.)

e quindi non hanno avuto lo stesso problema di rallentamento.

Per quanto riguarda il discorso 64bit,

di per se i 64 non portano ad un aumento della prestazione singola,

ma solo ad aumentare lo spazio di indirizzamento della memoria....

poi intel ha "accompagnato" la transizione a 64 con altre ottimizzazioni ai processori che ne hanno migliorato le presazioni ma si parla di miglioramenti dell'ordine di 10-15%.

Per quanto riguarda SSE,

per anni e' stato solo un elemento per il marketing perche' nelle prestazioni reali non dava vantaggi percettibili (il costo di context switch di SSE era tale da vanificare i vantaggi di esecuzione superscalare),

ultimamente sembra che intel abbia deciso di fare sul serio anche con SSE (penryn)

ma non ci crederei troppo ;-)

Discorso MultiCore,

mentre convertire il codice da 32bit a 64bit e' relativamente semplice perche' il lavoro sporco oggi lo fanno i compilatori....

rendere efficiente il codice su processori multicore e' un lavoro difficile,

questa e' la ragione per cui i codec oggi non hanno grandi vantaggi a passare da un 4core ad un 8core...

Apple e NVidia stanno lavorando su questo e, se le cose vanno come dovrebbero,

la grande innovazione di SnowLeopard sara' proprio questa : semplificare la scrittura di codice performante per processori multi-multi-core ;-)

Scusate per il post un po' lungo,

ma la discussione mi ha proprio preso,

ciao

Link to comment
Share on other sites

Forse nell'ambito di un piccolo programma i 64 sono meno utili, ma FC, che deve far uso di memoria per forza di cose "spezzettata" a causa della mole di dati da elaborare, i 64 sarebbero una manna dal cielo.

E non ti affidare ai compilatori.....se anche ESSI non sono aggiornati, le ottimizzazioni (la loro porzione, perchè il resto ce lo deve mettere il programmatore per forza di cose....) servono ben a poco.

Per esempio, la ATI 1900 ha dalla sua un encoder MPG1/2/4 hardware....... praticamente MAI UTILIZZATO; secondo te....serve SnowLeo per usarlo ? O forse serve il tool di sviluppo ?

E' un pò come dire.....ho la ferrari...ma non ho il pilota....però POTREBBE fare i 400Kmh !!!! Si......POTREBBE..!!!!!

Allora forse era meglio aspettare Leopard e averlo già ottimizzato a dovere...

ma ci sono troppi interessi commerciali a riguardo. A "loro" non importa un fico secco di Leopard et simili; interessa trovare il modo di spremerci come dei LIMONI. L'unica maniera per difenderci è tenerci la macchina il più a lungo possibile e spremerla finchè non "batte in testa".

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share