Scegliere la versione di piattaforma più semplice di una fonte quando si esegue il porting su un'altra piattaforma

Question

Scegliere la versione di piattaforma più semplice di una fonte quando si esegue il porting su un'altra piattaforma

#1 da (5 voti)

1

La domanda sembrerà strana perché non ho molta esperienza in C, C ++ e ASM.

Diciamo che ho difficoltà a trovare una soluzione gestita in C # e sicura solo per risolvere un problema. Poi ho scoperto che nel 1998, alcuni codici per (ad es.) Un codec sono stati scritti in C per PPC, x86, arm, ecc. Questo codice può avere più di 20000 linee e ho bisogno di portarlo.

Poi proverò una piattaforma e noterò un sacco di chiamate API, roba CUDA, assemblatore in linea nella maggior parte del codice. Ecc.

Esiste una preferenza, per quanto riguarda la portabilità, tra PPC, PS2, x86, arm, sparc, ecc. quando si effettua il porting su un'altra piattaforma che aiuta a ridurre il numero di occorrenze di codice specifiche della piattaforma? So che tutte queste build esistono soprattutto perché ci sono caratteristiche specifiche su ciascun processore, ma mi chiedo se alcuni processori hanno meno antenne, terzo occhio e quattro gambe, e sono meno semplici (o "limitati") di altri.

Ho trascorso l'ultima settimana a eseguire il porting di codici e ho avuto l'intuizione che concentrarsi su determinati aspetti aiuta a trovare più codice multipiattaforma. Potrei sbagliarmi, e so che dipende molto dall'abilità. Ma ciò non cambia nulla al fatto che, ad esempio, un codice Java da 20000 linee può essere più facile da portare a .Net per Windows Phone che un codice xm asm.

Più specificamente, la mia domanda riguarda un buon approccio quando si esegue il porting di Orange a Peach e si evita di passare attraverso diverse implementazioni specifiche della piattaforma.

porting

posta Léon Pelletier 16.08.2013 - 22:36

fonte

1 risposta

Leggi altre domande sui tag porting

OSS doppia licenza / segregazione del mercato Codifica di uno script di bash da utilizzare in Python

score 5 · Accepted Answer

Se ho capito bene, ciò che sembra descrivere è che hai un'implementazione C ottimizzata di alcuni codec che devi portare in un ambiente gestito agnostico come .NET.

Ci sono alcuni problemi con questo.

Un codec che è stato ottimizzato per diverse architetture di CPU include un sacco di codice specifico per piattaforma, perché è l'unico modo realistico per ottenere un livello di prestazioni che consenta operazioni relativamente in tempo reale. Questo è il motivo per cui C e l'assemblatore sono stati scelti su un linguaggio gestito. (Mettendo da parte il fatto che sembra che sia in anticipo rispetto alle più moderne piattaforme gestite - i codec moderni come x264 e Vorbis sono ancora scritti in C per questo motivo.) Quando si eseguono trasformazioni complesse su grandi set di dati in un'impostazione in tempo reale, vengono fatte accurate ottimizzazioni non solo per le caratteristiche della CPU, ma per i comportamenti della CPU. Il codec fa alcune ipotesi sulle cache e gli intervalli di tempo della CPU per sfruttare al meglio ogni singola operazione.

Questo tipo di ottimizzazioni non è possibile in un ambiente gestito. Non vale né il tuo tempo né il tuo sforzo per portare questo tipo di cose in un linguaggio gestito.

Invece di eseguire il porting di questo codice complesso (e probabilmente fragile!), dovresti invece utilizzare la capacità della piattaforma scelta per interagire con il codice non gestito . In .NET, probabilmente vorrai usare P / invoke per accedere al codec e spedire semplicemente una copia pre-costruita del codec per ogni piattaforma su cui verrà distribuito.