Platform Independency Vs Architecture Neutrality [closed]

3

È vero che l'indipendenza dalla piattaforma è più un mito oggi? Perché i programmatori cercano efficienza e potere sulla portabilità, che devono essere in qualche misura compromessi quando si ottiene l'indipendenza dalla piattaforma.

D'altra parte la neutralità dell'architettura è benvenuta perché fornisce un modo molto potente per creare un software che può dominare una particolare famiglia di sistemi operativi.

La mia domanda è:

Consideriamo una situazione ipotetica in cui dobbiamo scegliere uno di essi. Cosa dovrebbe essere compromesso? Portabilità o potenza?

So che questa domanda è un po 'soggettiva, ma sto cercando le tue opinioni in generale.

Grazie.

EDIT:

È giusto accettare una risposta particolare solo per il gusto di farlo, specialmente per una domanda a cui risponderebbero in base alle singole prospettive?

    
posta Pavitar 04.05.2011 - 11:35
fonte

2 risposte

7

Mi affido alla portabilità della piattaforma a scapito della potenza ogni giorno

Scrivo il mio codice su un computer Mac o Windows e lo vedo eseguito su una macchina Linux. Se non avessi la vera portabilità della piattaforma questo sarebbe un incubo.

A mio parere, l'alimentazione è meno compromettente perché l'hardware è così economico rispetto al tempo di sviluppo. Se hai bisogno di più throughput, getti più hardware su di esso. Se veramente richiede un grande throughput, inizia ad ottimizzare i colli di bottiglia (la maggior parte dei quali sarà probabilmente una comunicazione tra processi piuttosto che un codice di astrazione del sistema operativo).

    
risposta data 04.05.2011 - 14:26
fonte
2

A seconda dell'applicazione, tra l'80% e il 100% del codice non avrà alcun impatto sulle prestazioni, a patto che non sia gravemente inefficiente. Per questo codice, correttezza, manutenibilità e portabilità dovrebbero essere le tue priorità; non è necessario sacrificare nessuno di questi per miglioramenti marginali delle prestazioni.

Del codice più critico, da qualche parte tra l'80% e il 100% può essere fatto abbastanza velocemente senza sacrificare altre qualità. Considera solo la possibilità di sacrificare la portabilità quando non è possibile soddisfare in modo ragionevole i tuoi obiettivi di rendimento.

Dopo aver identificato i colli di bottiglia veramente critici, prova a isolare le piccole operazioni che possono trarre il massimo vantaggio dalle ottimizzazioni non portatili. Questo potrebbe includere loop interni scritti in assembly; utilizzo delle funzionalità del sistema operativo per modificare le priorità dei thread, il codice di blocco e i dati nella RAM o controllare l'utilizzo della cache; o utilizzando l'accelerazione hardware non standard. Separando questo dal corpo principale del codice, rimane ragionevolmente semplice sostituire questo codice con una versione portatile più lenta (per test su una piattaforma diversa dall'obiettivo), o con altre versioni ottimizzate per piattaforme diverse (come richiesto dai requisiti futuri più piattaforme supportate).

    
risposta data 04.05.2011 - 14:57
fonte

Leggi altre domande sui tag