Mi piacerebbe costruire la mia libreria di elaborazione del segnale, e possibilmente un altro sull'algoritmo dei grafici. Trovo C# molto utile e robusto per quanto riguarda i possibili errori associati con allocazione di memoria, puntatori, threading ecc ...: C++ vs C#
Ma mi stavo chiedendo quanto ho intenzione di perdere in termini di prestazioni. Sarà qualcosa di accettabile?
Grazie
Quando ho iniziato il mio corso DSIP ero uno sviluppatore C# puro. Dopo aver cercato un po 'di tempo, ho finito con l'usare le librerie C++ e l'apprendimento del C++ che alla fine era a mio beneficio poiché stavo facendo l'elaborazione delle immagini in tempo reale e non c'è modo in cui C# possa eguagliare le prestazioni.
In effetti, è possibile eseguire un test rapido ed eseguire un'equazione matematica costituita da alcune moltiplicazioni in C# e C++ un milione di volte e vedere l'enorme differenza che si stanno facendo calcoli con numeri in virgola mobile.
Se siete fortunati, otterrete wrapper in C# che è il migliore di entrambi i mondi, calcolo veloce in C++ e facile da usare in C#. C'è un wrapper C# per OpenCV e sembra essere abbastanza buono (http://www.emgu.com/wiki/index.php/Main_Page).
Consiglio vivamente OpenCV soprattutto per l'elaborazione del segnale 2D. È eccezionale per le prestazioni e ha reso possibile il mio progetto. Dai un'occhiata alla demo qui: http://www.youtube.com/watch?v=NeQvcdRPxoI e http://www.youtube.com/watch?v=NqYPJELHkhA
Con l'hardware giusto, non dovrebbero avere un problema.
Qualcosa a cui pensare però: non ho alcun problema a cercare una libreria per l'elaborazione del segnale in C++. Tuttavia, non riesco a trovare facilmente molte informazioni relative all'elaborazione del segnale per C#.
Se riesci a trovare un modo per farlo funzionare, potresti aver appena trovato un modo per entrare in un'area di sviluppo di nicchia di cui molte altre persone possono beneficiare.
Solo qualcosa a cui pensare. A meno che tu non stia facendo questo su un sistema mission-critical, probabilmente non importa in alcun modo. Vorrei solo andare con quello che pensi ti trarrà più beneficio a lungo termine.
+1. buona risposta – Aliostad
+1 per considerare l'aspetto "C# -niche". – Frank
Spesso vedo il commento che "con l'hardware giusto non dovresti avere problemi", che equivale a qualcosa del tipo "con l'hardware giusto non ci dovrebbe essere una penalità per le prestazioni. Non sono d'accordo con questo semplicemente perché costa denaro acquistare PC, mantenerli, fornire memoria sufficiente ecc. Quindi da questo punto di vista molto reale: costa denaro lavorare con linguaggi e/o librerie inefficienti. Perché qualcuno vorrebbe dire che "hardware migliore" risolve il problema non sta guardando il lato algoritmico della questione, ed è quello che la maggior parte delle persone chiede quando fanno domande sulle prestazioni. –
Non si tratta tanto di perdita di prestazioni in C#, ma l'imprevedibilità di quando viene eseguita la raccolta dei rifiuti. Durante il GC tutti i thread gestiti vengono congelati fino al completamento del GC. Durante questo periodo non è possibile eseguire alcuna elaborazione, che per il 99% delle applicazioni non è rilevante, ma l'elaborazione del segnale è fondamentale. Questo è il motivo per cui non si vede una versione gestita sanzionata da Microsoft di DirectShow o altre applicazioni di elaborazione del segnale "in tempo reale".
Simile a un Garbage Collector, non è possibile prevedere quando malloc o new passeranno la catena libera e consolideranno la memoria. Puoi controllare quando viene eseguito il GC, se è assolutamente necessario. –
Il GC impiega normalmente solo 20-30 ms. Quindi non dovrebbe essere un problema. – Aliostad
Ankur: Questo è uno dei motivi per cui dovresti usare un'arena di memoria/preallocazione invece di usare malloc regolare, in modo che non contino nella mia mente. – BrokenGlass
+1 bel pensiero sui wrapper ... È passato così tanto tempo da quando ne ho usato uno che tendo a dimenticare che esistono. –
esiste uno standard "de facto" per l'elaborazione del segnale in C++? – Bob