Ottimizzazione come ramo: è una cosa?

È raro che il costo dell'ottimizzazione (estrema) sia più economico del costo dell'hardware. Se nel 2007 avevi una funzione annunciata (5 anni fa), secondo la legge di Moores, l'hardware del computer è ora almeno 10 volte più potente di quando è stata annunciata la funzione. Suggerisco di guardare attentamente i motivi per cui questa ottimizzazione estrema è stata eseguita, e garantire che sia per validi motivi piuttosto che "perché dobbiamo". In alternativa, (più probabilmente?) "Ottimizzazione" viene utilizzato come scusa per scrivere codice non controllabile e non gestibile.

Ciò che hai ancora, tuttavia, è mantenere il codice di base, quindi anche se decidi di abbandonare tutti i problemi relativi alle prestazioni, esiste ancora un problema ... Tuttavia, la manutenzione di basi di codice legacy grandi e brutte è un campo con tecniche conosciute.

Cosa ti manca? La maggior parte delle basi di codice legacy non sono state scritte pensando ai test, e il costo per l'ammodernamento è estremo. Ci sono alcune buone (recenti) domande su questo argomento che dovresti leggere - alla fine della giornata il tuo problema è lo stesso di tutti quelli che lavorano con il codice legacy.

L'idea di "ramificare" una base di codice ottimizzata è eccellente. Quando il tuo capo vede quanto piccoli miglioramenti di velocità costano nel tempo (e quindi denaro), o comprerà hardware più veloce, o ti rimprovererà per farlo più veloce ed economico con meno programmatori (perché il miglioramento della velocità è più economico rispetto al più veloce hardware).

tl; dr risposta

Le ottimizzazioni non dovrebbero essere mantenute a lungo termine branch

Possono essere sviluppati in una succursale e poi riuniti nel ramo di rilascio una volta completati, ma dovrebbe essere sempre possibile testare entrambe le versioni affiancate e dovrebbe essere possibile passare facilmente tra ottimizzato e versioni non ottimizzate di qualsiasi algoritmo, idealmente in fase di esecuzione.

Risposta completa

Ricorda che esiste più di una forma di ottimizzazione.

L'ottimizzazione algoritmica (sostituendo un algoritmo O (n ^ 2) con un algoritmo O (n log n) per esempio) ha quasi sempre il potenziale di fornire risparmi più significativi rispetto all'ottimizzazione dell'implementazione (srotolando a mano un loop o assicurando i loop interni i dati si adattano a un determinato livello di cache).

Sfortunatamente, quando le persone pensano all'ottimizzazione, tendono a pensare di più sull'ottimizzazione dell'implementazione, che riguarda il software specializzato in modo tale da funzionare in modo più efficiente su un'architettura, probabilmente a spese di velocità di esecuzione su un'altra architettura.

Ho già risposto a molti altri aspetti relativi alla tua domanda in la mia risposta alla domanda Come documentare e insegnare agli altri codice di ottimizzazione computazionale ottimizzato oltre il riconoscimento?

Essenzialmente, si riduce alle regole d'oro dell'ottimizzazione:

The First Rule of Program Optimisation: Don't do it.

The Second Rule of Program Optimisation (for experts only!): Don't do it yet."

— Michael A. Jackson

Per sapere se ora è il momento di ottimizzare richiede benchmark e test. Devi sapere dove il tuo codice è inefficiente, in modo che tu possa indirizzare le tue ottimizzazioni.

Per determinare se la versione ottimizzata del codice è effettivamente migliore dell'implementazione ingenua in un dato momento, è necessario confrontarli fianco a fianco con gli stessi dati.

Inoltre, ricorda che solo perché una determinata implementazione è più efficiente nell'attuale generazione di CPU, non significa che sempre sia così. La mia risposta alla domanda La micro-ottimizzazione è importante per la codifica? fornisce un esempio dell'esperienza personale in cui un'ottimizzazione obsoleta ha comportato un rallentamento dell'ordine di grandezza.

My company has highly optimized scientific application which has become so big and complicated that new versions are literally taking t = infinity to produce.

Difficile da mantenere e difficile da introdurre nuova funzione = una definizione di codice legacy .

this application is branched for optimization a.k.a. a release or production version

Cattiva idea. I tuoi ingegneri devono mantenere due versioni. Poiché il tuo software è correlato alla scienza (molti calcoli e algoritmi presumo), dovresti implementare i tuoi algoritmi in due lingue:

• un tipo di linguaggio scientifico, come ad esempio matlab o R. Questa versione dovrebbe essere il più chiara possibile
• un qualche tipo di linguaggio di programmazione, come c, c ++, java, ecc. Questa versione dovrebbe essere il più ottimizzata possibile. Solo i posti che il profiler mostra che sono il collo della bottiglia dovrebbero essere ottimizzati. Le altre parti dovrebbero essere molto pulite. Ovviamente, il codice deve essere testato unitamente (con una copertura del codice più alta possibile).

Potresti dare un'occhiata a come Microsoft rilascia le cose. Cambiano il loro focus su ogni release. Caratteristiche, prestazioni, caratteristiche, prestazioni, ecc ... Ovviamente non è l'unica cosa che loro fanno, ma forse potresti prenderlo come base.