Adobe pensa al grid-computing

Adobe pensa al grid-computing

Adobe sta sviluppando un update per il proprio software After Effects, tale aggiornamento consentirà di sfruttare le teniche di grid-computing

di Fabio Boneschi pubblicata il , alle 14:46 nel canale Programmi
Adobe
 

Adobe sta sviluppando un update per il proprio software After Effects, tale aggiornamento consentirà di sfruttare le tecniche di grid-computing, ovvero di elaborazione distribuita.

Per far fronte alle crescenti esigenze di risorse, causate dalle pesanti elaborazioni e dai rendering, sarà possibile sfruttare le potenzialità di varie macchine e non più del singolo desktop.

Adobe ha fatto sapere che in futuro il grid-computing sarà una feature standard dei propri software.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

8 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Wonder10 Febbraio 2004, 14:55 #1
Strano, credevo che Premiere (addirittura) ce lo avesse già e che quindi After effects, ben più putente, fosse già dotato di tale caratteristica. COn After Effects Pro ci hanno fatto le esplosioni particellari di Indipendance Day
ninoo10 Febbraio 2004, 21:11 #2

con After Effects 6 bundle non c'è gia

pensavo di si ....

nessuno fa il rendering con piu' pc con adobe after effcts 6 bundle ?

Se si come si fa ?
danidak11 Febbraio 2004, 10:55 #3

Speranze vane

Invoco il supremo spirito della Sacra Informatica –Oh! Master C=ommodore!- …Assisti le nostre pene e Assolvere le nostre preghiere.

…Che sia la volta buona che rilasciano anche versioni per Linux?
..visto che il calcolo distribuito è una capacità implementata ormai da + di un decennio! ..a livello di kernel.

Mi sa che la realtà sarà ben + amara…. :
Tanti PC, ognuno col suo SistemoneMonolitico-spreca-risorse (Win o Mac), su cui giace copia completa e completamente-licenziata del sopra citato software.

Mi accontenterei se rendessero disponibile “il solo client” per i singoli “nodi” della render-farm… …ma qui lo dico e qui mi rassegno.
-Neppure con 3D Studio Max esiste questa possibilità- ..supporta il rendering distribuito (anche se in modo stupido: un frame completo per nodo…e se dovessi renderizzare un solo frame gigantesco? –come al solito mi attacco ..se uso Win..-)
Come dicevo, anche la Deescret ti licenzia una piattaforma completa anche se ti serve per far andare solo un nodo di calcolo. ..per fortuna esistono valide soluzioni (pluginS e client) di terze parti …anche Open!
Speriamo che alla Adobe si rendano conto delle reali necessità di chi sfrutterebbe in modo concreto queste BELLE-COSINE.

…anche perché, soprattutto per il fotoritocco, la soluzione è già pronta: The Gimp!
Ottimo prodotto free che lavora egregiamente! ..e per di più carica la stragrande maggioranza dei filtri e plugins fatte per Photoshop. …e che volendo ricompilarlo sfrutta in modo magistrale le capacità (su linux e unix) di distribuire i compitini a una renderfarm ..o ad un cluster ..o IN un cluster!

Avete idea cosa vuol dire poter sfoltire su 5 o 10 nodi un pesante passaggio di filtraggio su una immagine da 250Mb?
Beh… significa VOLARE! ..soprattutto se i PC in questione sono lì solo per quello, e non gli si fa pesare (e pure parecchio) il compito di reggere un’intero O.S. per l’anima del CaxxO.
…poi pensare al risparmio ($ € £ nel demandare il lavoro a Nodi (PC) senza dischi o lettori o Sistemi e software proprietari!!!

-comcludendo : sia mai che vendano anche il solo client? ..e magari pure per Linux…

Ciao. Daniele.
Fan-of-fanZ11 Febbraio 2004, 12:14 #4
Finalmente! Era ora!
Una soluzione che permette di usare tutte le risorse è sempre la benvenuta. Spero solo che il supporto flash (grafico non di programmazione) di imageready a questo punto venga completato con la prox versione (o magari con un aggiornamento).

Per danidak: hai provato a caricare su gimp (sia sotto win che sotto linux) una immagine della Nasa, tipo da 400mb (jpeg o tiff compressa...)???
Solo Photoshop ce la fa.
Inoltre Gimp ha una disposizione delle palette caotica perchè non è stato dotato di una propria finestra, e si vedono le icone del desktop sotto, e ciò per molti e fuorviante (potresti tranquillamente per sbaglio lanciare un programma...).
Ah, Gimp va spesso in crash...

Per quel che riguarda il porting delle soluzioni Adobe su Linux sono d'accordo con te: speriamo lo facciano al più presto!
danidak16 Febbraio 2004, 19:50 #5

Replica a Fan-of-fanZ

Ma 6 sicuro di aver usato il Gimp e non il Paint?
Guarda che se lo usi sotto Linux non ti costa proprio nulla dedicargli un SUO esclusivo desktop! (e pure sotto Win non è difficile), poi se intendi caricare immaginette da 400Mb vedi di dotarti di più RAM. ...a me non si inchioda MAI! ..e arrivo a fargli swappare anche 4-6Gb di dati!
...certo se mi dici che i prodotti Photoshop sono più ottimizzati per ambiente Win del GIMP..beh..è vero!
Ma comunque il rapporto prestazioni/costo non regge proprio il confronto!
...questa sparata del GRID-COMPUTING secondo me è solo una rivendita di abiti usati, chiunque abbia mai provato una configurazione BeoWulf o Mosix "con il gimp, con il COREL9 o perfino con lo Shake" vedrà di cosa è capace un sistema distribuito.
Il resto è solo propaganda publicitaria.
Sono invece d'accordo se mi dite che le interfaccia Adobe sono più evolute... tanto io preferisco i prodotti Corel!
N.B. - Il Gimp non mi ha mai (MAI) krasciato -
Sarà anche solo fortuna..? ..ma è così.
Il Photoshop invece Sì!
Poi è da vedere se sia solo tutta colpa di Win...(ma è da vedere..).
cdimauro20 Febbraio 2004, 23:11 #6
Scusa, ma cosa offre il kernel di Linux per supportare attivamente il calcolo distribuito?
Secondo me ben poco, altrimenti buona parte delle applicazioni intensive lo utilizzerebbero nativamente e semplicemente.
In realtà già sviluppare applicazioni multi-threaded, in modo da suddividere parte del carico computazionale su eventuali altre CPU, richiede già uno sforzo non indifferente, perché si deve pensare di sviluppare il codice diversamente rispetto ai canoni tradizionali.
Se pensiamo al software distribuito, i problemi diventano anche maggiori.
Io sviluppo applicazioni che fanno parte del calcolo distribuito su varie macchine, e utilizzo TPC/IP o UDP/IP quale protocolli per lo scambio d'informazioni fra i nodi, con un minimo di routine che provvedono al locking delle informazioni critiche e altre per lo scambio d'informazioni, e francamente questo mi basta per realizzare questi progetti.
Non vedo cosa potrebbe offrire in più un s.o. per gestire la distribuzione del lavoro su più macchine collegate in rete: comunque l'applicazione deve prevedere questo tipo di elaborazioni, altrimenti non c'è s.o. "distribuito" che tenga...
danidak26 Febbraio 2004, 12:05 #7

Re: alle perplessità di CDIMAURO

Allora, …vantaggi?...
Credo di non rubare tempo inutilmente a nessuno indicando queste letture.

http://openmosix.sourceforge.net/
http://www.beowulf.org
http://www.lam-mpi.org
http://www.ram.org/computing/linux/linux_cluster.html

…tanto per citarne alcune delle più famose..e dirette.

I vantaggi sono PALESI (dopo una veloce lettura delle fonti indicate lo saranno sicuramente).
In pratica è sufficiente programmare in modo “decente” strutture threadDABILI e il resto lo farà il sistema!!! ..è il kernel (ovviamente patchiato a dovere) a fare tutto il lavoro di distribuzione/migrazione dei processi!
L’applicativo (anche qualunque applicativo si possa trovare in distribuzione!) potrà anche non essere assolutamente ottimizzato per “forkare” ad ogni opportunità, ma addirittura potrebbe esse del tutto mono-thread! ..il sistema (in questo caso sfigato.. ma non remoto) demanderà “in piena autonomia” lo svolgimento del suddetto ad un solo nodo “dedicandoglielo”, così da non appesantire per nulla lo svolgimento degli altri processi –compresi quelli del sys. stesso- ..che ingombreranno altri nodi!
-…soprattutto ciò lascia la workstation sempre libera e responsiva!!!-
Esiste poi la possibilità (abbastanza semplice) di poter ricompilare con compilatori-dedicati (e open!) che ottimizzeranno per l’esecuzione distribuita.

In pratica l’orgasmo sta nel dover installare un solo sistema, a cui poi si “iscrivono i nodi” (sui quali non c’è nulla! ..se volete manco l’hdd!) …
..una volta installati gli applicativi (come si farebbe su un normalissimo sistema liunx!)..
….e si utilizza (da una sessione aperta sul nodo del Cluster –che è un PC virtuale-) come si farebbe da un normale PC…
COME PER MAGIA CI SI ACCORGERà CHE TUTTO “VOLA”!
…ovviamente si accuseranno le latenze dovute al collo di bottiglia della rete attraverso cui chiacchierano i nodi!
Ma PER L’UTENTE è TUTTO TRASPARETE!

Le preoccupazioni che citava Cidimauro sono quindi vane! …per fortuna! ..altrimenti, il tutto, sarebbe veramente inapplicabile! (si dovrebbe riscrivere ogni applicativo…e tutto il sistema!)

Purtroppo, per questo genere di applicazioni (sistema-distribuito e non greed-comuting), la situazione è veramente tragica in casa M$!!!
..in quanto le patch al sistema “non esistono” e mai esisteranno ..perché non è nelle Loro convenienze produrre strumenti che non prevedano di piazzare sistemi in rapporto 1 a 1 ai PC installati! (leggi licenze).
La cosa è comprensibile, ma grazie a Dio (per chi ci crede) esiste un’alternativa/scappatoia: -LINUX-

UN PARADOSSO:
Se fate girare un applicativo per Windows (o addirittura tutto il sistema) su un cluster-linux ..pure questi godranno dell’esecuzione distribuita! ..ovvio che è da verificare l’efficienza…ma è fattibile! (e Win non se ne renderebbe neppure conto!).

Nota:
Saranno almeno 3 o 4 anni che i moduli MPI e PVM vengono regolarmente inclusi nei kernel pre-compliati per la distribuzione di massa. …è di quest’ anno l’aggiunta la “quasi puntuale” del fantastico “OpenMOSIX”.

Saluti, Daniele.
cdimauro27 Febbraio 2004, 07:00 #8
Di quei link quello di OpenMOSIX è molto interessante. In effetti l'idea di calcolo distribuito implementato in siffatta maniera è certamente elegante e funzionale: realizzare applicazioni distribuite è molto semplice.
Come hai detto, bisogna sviluppare applicazioni multithreaded, è questo è comunque un prerequisito per chi vuol "parallelizzare" il calcolo, sia esso in locale che su più macchine.
Unico difetto, ma è questo è ovvio, è che c'è un overhead e la resa complessiva del sistema non è paragonabile a quella di una soluzione custom. Ma questo è ovvio, come ho già detto. Le applicazioni che scrivo infatti, hanno un overhead minimo e una resa massima, proprio per questo motivo.
E' chiaro che Windows non può essere pensato per realizzare cluster-computing paragonabile a OpenMOSIX, quanto a semplicità e duttilità: bisognerebbe riadattare il s.o. in accordo, ma non essendoci i sorgenti (insomma ) ed essendo MS l'unica a portelo fare, sarà difficile vedere realizzata qualcosa di simile.
Ciò non toglie che sia possibile comunque implementare l'elaborazione distribuita. Tra l'altro non è che neppure difficile da realizzare, anche se certamente richiede un po' di lavoro in più (alcune routine di sincronizzazione/locking e un protocollo di comunicazione). Niente di particolamente complicato, dal mio punto di vista.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^