Il MIT ottimizza le app fotografiche per smartphone
Dal MIT un nuovo linguaggio che aiuterà a migliorare le routine di trattamento delle immagini, in particolar modo sui dispositivi portatili. Test preliminari hammo mostrato incrementi di velocità fino al 600% rispetto al software attuale.
Dal MIT (con la collaborazione di Adobe) arriva una nuova idea per ottimizzare il codice di trattamento delle immagini; la soluzione è particolarmente indicata per dispositivi mobili con limiti in termini di consumi massimi e potenza di calcolo, ma è utilizzabile anche per PC desktop.
La chiave, secondo il MIT, è un nuovo linguaggio che crei un livello di astrazione aggiuntivo, liberando gli sviluppatori dalle compelssità dell'ottimizzazione del codice specifica per il singolo processore in uso.
I ricercatori hanno testato il nuovo linguaggio, battezzato Halide (forse in omaggio al silver halide, l'alogenuro di argento utilizzato dalle pellicole fotografiche) per riscrivere alcune diffuse routine di elaborazione delle imamgini, ottenendo incrementi di velocità dal 200 al 600%.
La maggior parte del beneficio arriva dal miglior sfruttamento dei processori multicore che il nuovo livello di astrazione consente di fare quasi automaticamente, e che di norma richiede invece un lungo e difficoltoso lavoro di programmazione. Fondamentale, in questo senso, la capacità del compilatore di schedulare in modo semplice quando e dove deve essere eseguita ogni routine. I programmatori potranno così sperimentare facilmente diverse soluzioni, senza timore di trovarsi al temine del lavoro con un codice pieno di bug e non funzionante.
Il linguaggio è un'estensione del C++ e compilatori sono già disponibili per hardware x86, processori mobile ARM e per GPU Nvidia Cuda. In programa anche una versione per librerie OpenGL.
La chiave del successo di questa iniziativa sarà comunque il modo in cui i produttori di complilatori commerciali recepiranno le idee partorite al MIT. La presenza di Adobe lascia ben sperare in questo senso.
Epic Fail: Il porno online è un problema quotidiano
GeForce GTX Titan sta andando a ruba in Italia e nel mondo
Carte di Magic: videointervista all'illustratore Greg Staples
Router FRITZ!Box 6840 LTE e 6810 LTE: a prova di futuro
G Data AntiVirus 2014 e non solo: guerra a malware e truffe
PS4: controllo vocale e ogni gioco funzionerà su PS Vita?
Ekoore Python S3: tablet con Android, Ubuntu e Windows
Pacific Rim: robot giganti contro alieni ancora più grandi
Firefox 22 è già in versione Beta, ecco che cosa ci attende
40 milioni di licenze Windows 8 impolverate sugli scaffali
Da Infor una piattaforma di Enterprise Collaboration
Extensis Portfolio Server 11 per il Digital Asset Management
Scoprire virus o problemi: dieci strumenti diagnostici gratis online
FileZilla: guida all'uso del client FTP gratuito
Facebook e Trend Micro rafforzano la partnership
I Power Ranger progettati con PTC Creo
Adobe Lightroom 5 in beta gratuita fino a giugno
Applicazioni "real time" e FTP: i più amati dal malware
AppGratis: petizione per convincere Apple a cambiare idea
Ecco l'applicazione Android per dirottare gli aerei
App per iPhone beccate a spiare, s'indaga su Android
Quindici giochi di flipper per dispositivi Android
Chiamate gratis su Windows Phone 8 grazie anche a Viber
L'app di PlayBoy sbarca su iPhone con ragazze quasi vestite
A 17 anni vende un'applicazione iPhone per 30 milioni
Falla in Ruzzle scoperta da italiani, chiusa a tempo di record
Quattordici giochi di combattimento per Android
Tom's Hardware - News più lette
Tom's Hardware - Articoli più letti
Copyright ©2013 Bestofmedia. Tutti i diritti riservati
P.Iva 04146420965
Commenti dei lettori (11)
lo so ci vuole piu tempo a scrivere codice ottimizzato , il tempo è denaro pero quante cose in piu si potrebbero fare con quello che abbiamo gia a disposizione ora.
AMEN
Che bel commento, molto significativo
Scherzi a parte, si potrebbe sì far molto di più già con quello che abbiamo ora -.-
Ma il compilatore non dovrebbe compilare (trasformare i sorgenti in file comprensibili per il runtime environment) e basta? Cosa c'entra con lo schedulare?
Bha.
Inoltre il fatto che il compilatore gestisca autonomamente alcune caratteristiche di alto livello, permette allo stesso di ottimizzare il codice maggiormente, infatti non accaso per le espressioni labda, se si usa un paroccio nativo al linguaggi si avranno sicuramente prestazioni migliori, visto che il compilatore per quel tipo di struttura avrà a disposizioni metodi per generare un codice più prestante...
E quindi si cade sempre nel problema del multipiattaforma vs prestazioni...
allora se si parla di cpu si lo scheduling viene fatto tramite hardware con delle unita dedicate nel processore stesso (almeno nei più moderni) per quanto riguarda le schede grafiche (openGL) il compilatore li invece esegue anche lo scheduling dato che le gpu con architettura VLIW (al momento tutte) non sono in grado di farlo hardware anche se la cosa sta cambiando (almeno per quanto riguarda AMD-ATI che con l'architettura sea islands toglierà di mezzo la VLIW MIMD per una più convenzionale architettura RISC SIMD proprio perché sarà possibile usare lo scheduling hardware e quindi si avrà una marcia in più nel GPGPU grazie alla esecuzione out of order che ora non è possibile)
EDIT: già soutern Islands ha tolto di mezzo VLIW
uee parli come i politici non si capisce un lazzo come se avessi detto tutto e niente ahhah! .
scherzo è che di programmazione ho giusto le basi , so fare qualcosa con c++ , pascal , basic e una volta pure assembler .
Vero a metà, perché nvidia usa da tempo un appropccio SIMD e non VLIW e ha implementato uno scheduller HW per Fermi. Con Kepler e la semplificazione delle istruzioni, ora tutte eseguite in un ciclo di clock, e delle ALU, che ora girano alla stessa frequenza del core, nvidia ha decido si rimuovere lo scheduler HW in favore di uno SW vista (secondo loro) la maggior semplicità con cui si può fare lo scheduling statico tramite compilatore.
Quindi nel settore delle GPU uno arriva dove l'altro è già stato e ha deciso che è meglio tornare come prima (o ha fatto in modo che tornare indietro fosse egualmente efficiente).
Ovviamente la questione "nuovo livello di astrazione = maggiori performance" è da meglio indagare, dato che la cosa non è mai vera e presuppone lo sfruttamento di altre risorse per poter essere più veloci del codice nativo. Là dove queste risorse ulteriori non ci sono l'esecuzione è più lenta.
Quindi se sento che il compilatore schedula delle attività, mi sa tanto di baggianata.
Ripeto, il compilatore trasforma i file sorgente (es. Classe.java) in file comprensibili all'ambiente di esecuzione (es. Classe.class). Tutto qui.
Il resto viene gestito da altri moduli (es. Container nell'ambiente di esecuzione), che di certo non è il compilatore.
Non credo intenda schedulare come lo fa un sistema operativo bensì vede le istruzioni del codice e decide nel momento della compilazione se può scambiarne l'ordine, spostarle su un altro core per parallelizzarle,...
Cose del genere sono già effettuate da tempo dai vari compilatori.