Domanda

Sono coinvolto in un'impresa che porterà alcune funzionalità di comunicazione, analisi e gestione dei dati da Win32 a Linux ed entrambi saranno supportati. Il dominio problematico è molto sensibile alla velocità e alle prestazioni.

Ho pochissima esperienza con le caratteristiche prestazionali di boost e ACE. In particolare, vogliamo capire quale libreria offre le migliori prestazioni per il threading.

Qualcuno può fornire alcuni dati - documentati o passaparola o forse alcuni link - sulle prestazioni relative tra i due?

Modifica

Grazie a tutti. Confermato i nostri pensieri iniziali: molto probabilmente sceglieremo boost per le cose multipiattaforma a livello di sistema.

È stato utile?

Soluzione

Nessuna delle due librerie dovrebbe davvero avere un sovraccarico rispetto all'utilizzo delle funzionalità di threading del sistema operativo nativo. Dovresti vedere quale API è più pulita. A mio avviso, l'API del thread boost è significativamente più facile da usare.

ACE tende ad essere più "classico OO", mentre boost tende ad attingere dal design della libreria standard C ++. Ad esempio, l'avvio di un thread in ACE richiede la creazione di una nuova classe derivata da ACE_Task e la sostituzione della funzione svc () virtuale che viene chiamata quando il thread viene eseguito. In boost, crei un thread ed esegui qualsiasi funzione tu voglia, che è significativamente meno invasiva.

Altri suggerimenti

Fatti un favore e stai alla larga da ACE. È una biblioteca orribile, orribile che non avrebbe mai dovuto essere scritta, se me lo chiedi. Ho lavorato (o meglio DEVO lavorare con lui) per 3 anni e ti dico che è un pezzo di spazzatura mal progettato, scarsamente documentato, mal implementato usando il C ++ arcaico e costruito su decisioni progettuali completamente cerebrali ... chiamando ACE "C con classi" sta effettivamente facendo un favore. Se osservi le implementazioni interne di alcuni dei suoi costrutti, avrai spesso difficoltà a sopprimere il riflesso del vomito. Inoltre, non posso sottolineare la "scarsa documentazione" aspetto abbastanza. Di solito, l'idea di ACE di documentare una funzione consiste semplicemente nella stampa della firma della funzione. Per quanto riguarda il significato dei suoi argomenti, il suo valore di ritorno e il suo comportamento generale, di solito sei lasciato a capirlo da solo. Sono stanco di dover indovinare quali eccezioni può generare una funzione, quale valore restituito indica successo, quali argomenti devo passare per fare in modo che la funzione faccia ciò di cui ho bisogno o se una funzione / classe è thread-safe o no.

Boost, d'altra parte, è semplice da usare, C ++ moderno, estremamente ben documentato, e FUNZIONA! Boost è la strada da percorrere, in fondo con ACE!

Non preoccuparti del sovraccarico di un livello di astrazione del sistema operativo su thread e oggetti di sincronizzazione. Il threading overhead letteralmente non ha alcuna importanza (poiché si applica solo alla creazione di thread, che è già enormemente lenta rispetto al sovraccarico di un riferimento indiretto puntatore personalizzato). Se scopri che le operazioni di mutex ti stanno rallentando, è meglio guardare le operazioni atomiche o riorganizzare i tuoi schemi di accesso ai dati per evitare contese.

Per quanto riguarda boost vs. ACE, è una questione di "nuovo stile". vs. "vecchio stile" programmazione. Boost ha molti shenanigans basati su template solo intestazione (che sono belli con cui lavorare, se puoi apprezzarlo). Se, d'altra parte, sei abituato a " C con classi " stile di C ++, ACE sembrerà molto più naturale. Credo che sia principalmente una questione di gusti personali per la tua squadra.

Ho usato ACE per numerosi server di produzione pesanti. Non mi ha mai deluso. È solido come una roccia e fa il lavoro da molti anni ormai. Ho cercato di imparare il framework di rete ASIO di BOOST-Non riuscivo a capire. Mentre BOOST è più "moderno" C ++, è anche più difficile da usare per compiti non banali - e senza un "moderno" Esperienza C ++ e conoscenza approfondita dell'STL è difficile da usare correttamente

Anche se ACE è una specie di C ++ di vecchia scuola, ha ancora molte funzionalità orientate ai thread che boost non fornisce ancora.

Al momento non vedo alcun motivo per non usare entrambi (ma per scopi diversi). Una volta che boost fornirà un mezzo semplice per implementare le code dei messaggi tra le attività, potrei considerare di abbandonare ACE.

Quando si tratta di facilità d'uso, boost è molto meglio di ACE. boost-asio ha un'API più trasparente, le sue astrazioni sono più semplici e possono facilmente fornire elementi costitutivi alla tua applicazione. Il polimorfismo in fase di compilazione viene usato con giudizio in spinta per avvertire / prevenire il codice illegale. L'utilizzo dei modelli da parte di ACE, d'altra parte, è limitato alla generalizzazione ed è quasi mai abbastanza incentrato sull'utente da impedire operazioni illegali. È più probabile che tu rilevi problemi in fase di esecuzione con ACE.

Un semplice esempio a cui riesco a pensare è ACE_Reactor - un'interfaccia abbastanza scalabile e disaccoppiata - ma devi ricordare di chiamarlo "proprio" funzione se stai eseguendo il suo ciclo di eventi in un thread diverso da quello in cui è stato creato. Ho trascorso ore a capirlo per la prima volta e avrei potuto facilmente passare giorni. Per ironia della sorte, il suo modello a oggetti mostra più dettagli di quelli che nasconde: buono per l'apprendimento ma cattivo per l'astrazione.

https://groups.google .com / forum /? fromgroups = #! tema / comp.soft-sys.ace / QvXE7391XKA

Il threading è in realtà solo una piccola parte di ciò che offrono boost e ACE, e i due non sono davvero comparabili nel complesso. Concordo sul fatto che la spinta è più facile da usare, poiché l'ACE è un framework piuttosto pesante.

Non chiamerei ACE " C con classi. " ACE non è intuitivo, ma se prendi il tuo tempo e usi il framework come previsto, non te ne pentirai.

Da quello che posso dire, dopo aver letto i documenti di Boost, vorrei usare il framework ACE e le classi container di Boost.

Usa ACE e aumenta in modo cooperativo. ACE ha una migliore API di comunicazione, basata su modelli di progettazione OO, mentre boost ha come "moderno C ++" progettare e funziona bene con i contenitori per esempio.

Abbiamo iniziato a utilizzare ACE credendo che nascondesse le differenze di piattaforma presenti tra windows e unix nei socket TCP e nella chiamata select. Si scopre, non lo fa. L'opinione di Ace su select, il pattern del reattore, non può mescolare socket e stdin su windows e le differenze semantiche tra le piattaforme relative alle notifiche di scrivibilità dei socket sono ancora presenti a livello di ACE.

Quando ci siamo resi conto che stavamo già utilizzando le funzionalità di thread e di processo di ACE (quest'ultima delle quali di nuovo non nasconde le differenze della piattaforma nella misura in cui avremmo voluto) in modo che il nostro codice sia ora legato a un enorme libreria che impedisce effettivamente il porting del nostro codice a 64 Bit MinGW!

Non posso aspettare il giorno in cui l'ultimo utilizzo di ACE nel nostro codice verrà finalmente sostituito con qualcosa di diverso.

Uso ACE da molti anni (8) ma ho appena iniziato a studiare di nuovo l'uso di boost per il mio prossimo progetto. Sto prendendo in considerazione la spinta perché ha una borsa degli attrezzi più grande (regex, ecc.) E parti di essa vengono assorbite dallo standard C ++, quindi la manutenzione a lungo termine dovrebbe essere più semplice. Detto questo, la spinta richiederà qualche aggiustamento. Sebbene Greg menziona che il supporto per i thread è meno invasivo in quanto può eseguire qualsiasi funzione (C o statica), se sei abituato a utilizzare le classi di thread che sono più simili alle classi di thread Java e C # che è ciò che ACE_Task fornisce, hai usare un po 'di finezza per ottenere lo stesso con boost.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top