Sovraccarico delle prestazioni dei contenitori standard e boost [chiuso]

Question

Sovraccarico delle prestazioni dei contenitori standard e boost [chiuso]

#1 da (3 voti)

1

Adap.TV ha scelto C ++ per sviluppare il suo software. Tuttavia, hanno deciso di non utilizzare i contenitori standard ¹ e di aumentare le prestazioni per motivi di prestazioni, poiché ne hanno scritto blog nel seguente articolo:

Perché usiamo C ++ (senza usando STL o boost)

Dice (sottolineatura mia),

There are several rules that we are obeying in order to keep the performance high;
Avoid malloc(), calloc() or new
No free() or delete (and no need for tcmalloc)
No STL, boost etc.
Avoid locking as much as possible
# threads = # CPU cores (hyperthread is a trade-off between latency and throughput)

Come sappiamo, i contenitori standard usano allocatori che usano new e delete internamente che sono costose operazioni. Quindi, per evitarli, AdapTv ha evitato l'uso di contenitori standard. Invece di usare new e delete (ripetutamente), essi riutilizzano la memoria (il che implica che usano un pool di memoria).

Mi chiedo cosa impedisca loro di utilizzare gli allocatori personalizzati per i contenitori standard! L'allocatore personalizzato potrebbe utilizzare internamente un pool di memoria che significa riutilizzo della memoria . Quindi non vedo come i contenitori standard danneggerebbero le prestazioni.

O mi manchi qualcosa? Non possiamo evitare di usare new e delete con i contenitori standard? C'è qualche altra ragione per cui qualcuno dovrebbe evitare l'uso di contenitori standard? O è semplicemente una mancanza di conoscenza da parte loro che ha portato a questa decisione?

E che ne dici di boost?

^{1) Suppongo che STL intendessero contenitori standard C ++ , non STL di SGI .}

c++ performance standard-library boost

posta Nawaz 01.04.2013 - 20:03

fonte

1 risposta

Leggi altre domande sui tag c++ performance standard-library boost

Gestione delle eccezioni nell'applicazione Web Java Implementazione della divisione in virgola mobile in base 10

score 3 · Answer 1

Ovviamente malloc() e free() riutilizzano la memoria, dal "pool" della RAM disponibile più lo swap. Tuttavia, al fine di fare un uso efficiente delle risorse, fanno una serie di compromessi per l'informatica generica. fonte glibc e questo articolo fanno riferimento a discutere i trade off in modo abbastanza dettagliato.

Il compromesso più importante è lo spazio-tempo. In sostanza, se vuoi che il tuo allocatore sia più veloce, finirai per sprecare spazio. La pre-allocazione di un pool di memoria è un esempio di spreco di spazio, poiché è necessario allocare la quantità di memoria che si ritiene sarà necessaria. In un computer monouso come un server, tale scambio è accettabile. Non vorrai quella memoria per un'altra applicazione.

Se si utilizzano gli allocatori personalizzati STL, si ottiene il controllo su da dove proviene la memoria, ma non è ancora possibile controllare quando e con quale frequenza viene chiamato l'allocatore. Ogni tanto, inevitabilmente fai un grande successo, come se avessi bisogno di deframmentare. Di solito hai anche bisogno di essere bloccato. Stanno evitando del tutto quel problema, a scapito dello spreco di memoria. Sprecare è probabilmente la parola sbagliata, poiché è una scelta deliberata. investi la memoria per guadagnare velocità.

Come nota a margine, aumenta anche l'affidabilità. Lavoravo da qualche parte con un divieto di memoria allocata dinamicamente, ma non per ragioni di prestazioni. Se tutta la memoria è allocata all'inizio, puoi facilmente determinare i tuoi requisiti massimi di memoria e sapere che un'esplosione non ti farà superare il limite fisico.