Cześć, potrzebuję jak najszybszego kopiowania danych z uint8_t buffer do formatu, który później pozwoli mi spisać te dane do pliku.
Obecnie mam taki kod, ten tmpBuffer jest wrzucany do listy którą na koniec spisuje do pliku
std::vector<uint8_t> tmpBuffer(buffer.poczatek, buffer.koniec);
czy znacie może szybsze rozwiązanie? czy to już jest najszybsza wersja?
Ściślejsze by było inne słowo, np konwersja - kopiowanie znaczy co innego.
Dla mnie pytanie jest mało zrozumiałe, a dokładniej to zupełnie pozbawione szczegółów. Kilka braków:
środowisko
plik tekstowy / binarny
FORMAT cóż za tajemnica.
update: rzeczywiste obciążenie w prawdziwych liczbach
i kilka innych
Za mało informacji i pachnie jak problem XY.
Są to dane binarne, przesyłane do klienta, który je odbiera i robi swoją prace, dodatkowo na serwerze, który je wysyła chcę zrobić zapisywanie wszystkiego do pliku, więc potrzebuję najszybciej jak się da skopiować dane z tablicy (te dane [taki std::vector ze skopiowanym bufferem] są następnie wrzucane do std::list na osobnym wątku).
no i poco wrzucasz do std:list a nie od razu wrzucasz do pliku?
gdyby od razu wrzucało do pliku to moja appka miałaby 1000% cpu, a tak dane się zbierają a osobny wątek je zapisuje gdy uzbiera się odpowiednia ilość. To nie jest ważne, pytanie brzmi czy da się te dane kopiować szybciej niż obecnie to robię.
Miang napisał(a):
no i poco wrzucasz do std:list a nie od razu wrzucasz do pliku?
storm. napisał(a):
gdyby od razu wrzucało do pliku to moja appka miałaby 1000% cpu, a tak dane się zbierają a osobny wątek je zapisuje gdy uzbiera się odpowiednia ilość. To nie jest ważne, pytanie brzmi czy da się te dane kopiować szybciej niż obecnie to robię.
@storm.:
Nie podałeś ŻADNYCH szczegółów, które pozwoliły by ci pomóc.
Ale utwierdziłeś mocno moją intuicję, że "optymalizujesz" wg błędnych wydaje-ci-się.
Jest niemal pewne, że coś robisz nie tak, a nie winien jest biedny vector (czy to optymalna struktura, to oddzielny watek)
Po drugie utajnianie kodu kodu zwiększa moje przypuszczenie, że powodem nie ejst komercyjna wartość dla postronnych, ale wstyd
storm. napisał(a):
gdyby od razu wrzucało do pliku to moja appka miałaby 1000% cpu, a tak dane się zbierają a osobny wątek je zapisuje gdy uzbiera się odpowiednia ilość. To nie jest ważne, pytanie brzmi czy da się te dane kopiować szybciej niż obecnie to robię.
Po pierwsze to zależy od systemu operacyjnego. To nie jest tak że dane od razu są zapisywane na dysk. Kiedyś miałem taki problem na jednym linuksowym rozwiązaniu że w mieliśmy problem z qt i zapisywanie na dysk. Doszedłem do tego że manipulując częstotliwością przeglądania cacheu i jego wielkością przez linuksa problem zniknął system zapisywał szybciej dane na dysk(np. nagłe odcięcie zasilania może powodować stratę danych bo one są w cacheu i na dysku dopiero po czasie).
Także już tu przyjąłeś błędne założenie.
Ale jeśli chcesz to sprawdź sobie implementację spdlog i jego zapisu do pliku czy ogólnie przetwarzania. link
storm. napisał(a):
gdyby od razu wrzucało do pliku to moja appka miałaby 1000% cpu, a tak dane się zbierają a osobny wątek je zapisuje gdy uzbiera się odpowiednia ilość. To nie jest ważne, pytanie brzmi czy da się te dane kopiować szybciej niż obecnie to robię.
Nie podajesz żadnych informacji o tym, jak te dane kopiujesz, więc trudno stwierdzić czy da się szybciej.
Najprawdopodobniej da się tych danych po prostu w ogóle nie kopiować, a na listę wkładać tylko do nich wskaźnik.
ZrobieDobrze napisał(a):
Miang napisał(a):
no i poco wrzucasz do std:list a nie od razu wrzucasz do pliku?
storm. napisał(a):
gdyby od razu wrzucało do pliku to moja appka miałaby 1000% cpu, a tak dane się zbierają a osobny wątek je zapisuje gdy uzbiera się odpowiednia ilość. To nie jest ważne, pytanie brzmi czy da się te dane kopiować szybciej niż obecnie to robię.
@storm.:
Nie podałeś ŻADNYCH szczegółów, które pozwoliły by ci pomóc.
Ale utwierdziłeś mocno moją intuicję, że "optymalizujesz" wg błędnych wydaje-ci-się.
Jest niemal pewne, że coś robisz nie tak, a nie winien jest biedny vector (czy to optymalna struktura, to oddzielny watek)Po drugie utajnianie kodu kodu zwiększa moje przypuszczenie, że powodem nie ejst komercyjna wartość dla postronnych, ale wstyd
Wybacz, najwidoczniej źle sformułowałem pytanie ponieważ zamiast pomóc staracie się znaleźć problem w innym miejscu.
Pytanie brzmi: czy wersja kopiowania danych z tablicy do std::vector którą mam jest najszybsza jaka istnieje? Czy może jest inny sposób na kopiowanie tych danych do czegoś innego niż vector tak bym mógł później je spisać do pliku? Cała reszta, według mnie, czy to jest na wątku, czy na liście, czy spisywane od razu lub później, czy muszę je kopiować, czy w innej strukturze jest nie ważna.
Musicie zrozumieć, że jak człowiek pyta o X rzecz to nie zawsze interesuje go Y rzecz którą przy okazji można poprawić. Mam kod, który działa, jestem z niego zadowolony, ale chciałem się dowiedzieć czy da się TE konkretną operacje zrobić lepiej.
Problem jest taki że nie znamy architektury. Ale rozwiązanie już padło np. swapowanie wskaźników. Po prostu miej wskaźnik na dane i przekaż go do wątku(w który nie wiem jest jakiś bufor na te wskaźniki). Żadnego kopiowania danych bo po co?
A jak chcesz już kopiować to masz przecież np. memcpy(na stacku są jeszcze jakies czary mary fastmemcpy oparte o sse4 ale to bym odpuścił link).
storm. napisał(a):
Wybacz, najwidoczniej źle sformułowałem pytanie ponieważ zamiast pomóc staracie się znaleźć problem w innym miejscu.
Bo problem JEST w innym miejscu.
Kopiowanie w prawidłowym przypadku jest z 95% kodu asemblerowego (maszynowego). Chyba że w szerszym kodzie coś psujesz.
Póki co uparcie bronisz jak Rejtan reszty kodu, żeby CIA i Mosad nie ukradł.
Mamy się wypowiadać na podstawie zadeklarowanego konstruktora z nieznanymi argumentami? Ktoś tu się ociera o granicę śmieszności.
A na marginesie, zdradź mily kolego, o jakich ilościach danych / sekundę w ogóle mowa? Ilośc grup / pakietów /ramek oraz bajtów.
Z tak krótkiego opisu problemu wyłuskałem "watek"+"zapis do pliku"
To może być być wyzwanie i bardzo wąskie gardło jak robisz to źle ( 1MB/s może być problemem jak się człowiek bardzo stara)