You must log in or # to comment.
To porównanie jest nie do końca uczciwe.
Rozwiązanie oparte na mmap jest jednowątkowe, więc wszystkie pagefaulty potrzebne do załadowania danych spowalniają program.
W przykładzie z kolejką IO koleś ma 6 dodatkowych workerów.Mogę się założyć o czekoladę z okienkiem, że dodanie kilku workerów prefaultujących z wyprzedzeniem strony z mmapowanymi danymi, przyspieszyłoby znacząco odczyt. Oczywiście io_uring będzie nadal szybszy, ale przewaga nie będzie tak znacząca.
Mnie wyszło, że to nie pamięć jest wolna tylko abstrakcje systemu operacyjnego. Właśnie dlatego mamy nowy interfejs. Ciekawe jaki interfejs jest w konsolach, które rzeczywiście mają ładowanie danych do cache.
Możliwe, że dorównałbyś autorowi, ale w rzeczywistości marnowałbyś moc obliczeniową na niwelowanie opóźnienia. Prawdopodobnie zablokowałbyś wszystkie procesy. Jądro by je kolejno odblokowywało w trakcie napływu danych.
Nie wzięto pod uwagę, że dzisiaj jeden rdzeń i jeden wskaźnik nie wysyca pasma RAM.
Mnie wyszło, że to nie pamięć jest wolna tylko abstrakcje systemu operacyjnego.
To prawda, szczególnie, że koszt przełączenia kontekstu jest coraz wyższy (chociażby ze względu na meltdown/spectre itp.).
Możliwe, że dorównałbyś autorowi, ale w rzeczywistości marnowałbyś moc obliczeniową na niwelowanie opóźnienia. Prawdopodobnie zablokowałbyś wszystkie procesy. Jądro by je kolejno odblokowywało w trakcie napływu danych.
Tak, zablokowałbym więcej procesów, ale N czekających jednocześnie procesów otrzyma więcej danych niż jeden.
Żeby nie być gołosłownym, odczyt 13 GB ze zmapowanego pliku z zimnym cachem dysku:- 1 wątek - 25.9s,
- 2 wątki - 15,4
- 4 wątki - 9,0s
Spodziewam się, że io_uring byłby znacznie efektywniejszy, ale wypadałoby porównać oba przypadki z tą samą liczbą wątków zamiast sztucznie ograniczać mmapa.
[tu miał być złośliwy komentarza o wysiłku włożonym w pisanie wielowątkowego menadżera io_uring]
