On 03.02.2017 15:15, Stachu 'Dozzie' K. wrote:
> On 2017-02-03, Borneq <b...@a...hidden.pl> wrote:
>> W dniu 03.02.2017 o 13:51, Maciej Sobczak pisze:
>>> Jak chcesz mieć dostęp do fizycznego sprzętu, to pisz programy bezpośrednio na
ten fizyczny sprzęt. W ramach kompromisu, być może funkcje mapujące pamięć mają
jakieś opcje, które pozwalają kontrolować stopień "nieruszalności" jakiegoś bloku
albo zakresu adresów - może się wtedy jednak okazać, że będziesz musiał tam samemu
zorganizować sobie alokację.
>>
>> Chodzi o to: działam na wielkich plikach, lepiej bym używał tyle pamięci
>> ile mogę aby było szybciej.
>> Przykład: sortowanie zewnętrzne 3-plikowe lub większa ilość plików. Aby
>> zmniejszyć zdecydowanie ilość przerzucań tym plikiem, przepuszczam przez
>> stóg, jak największy, tyle ile mam pamięci, Wtedy plik składa się z
>> dużych kawałków posortowanych.
>
> Robisz głupio. Do tego używa się mmap(2), a nie wykrywania ilości wolnej
> pamięci. Wtedy przydzielaniem RAM-u martwi się system operacyjny.

Nie bardzo rozumiem, co mu zmapowanie plików do pamięci pomoże.
Jeśli odpali na tym qsorta najlepszy system operacyjny mu nie
pomoże ;-)

Pewnie chciałby posortować małe porcje, a potem mergesort
na plikach. Ta drugą cześć bez problemu można robić jak
sgerujesz, ale przy pierwszej, wypadałoby wiedzieć, ile się zmieści.
Jeśli zmieści się dwa razy więcej, będzie jeden przebieg mniej.

OK, co prawda mergesort puszczony naiwnie spowoduje pełne
log_2 (N) odczytów z dysku, to mergesort zrobiony w kolejnośćipostorder

sortuj( a,b ){
mid = a+(b-a)/2;
sortuj (a,mid);
sortuj (mid,b);
scal(a,mid,b)
}

przy dobrym automatycznym zarzadzaniu pamięcią (a nawety głupim
'wywalaj wg kolejności użycia') da wynik przyzwoity.

Ale nie idaealny, bo muszę mieć zmapowane w p[amięci wejscie i wyjscie,
trace wiec jeden przebieg.


Z drugiej strony to problem istotny tylko przy słąbych algorytmach.
Jeśli skorzystać z 256 plików, to 65 terabajtów posortuję za pomocą
gigabajta w trzech seriach odczyt/zapis ;-)

pzdr
bartekltg