Path: csiph.com!weretis.net!feeder4.news.weretis.net!news.unit0.net!news.nask.pl!news.nask.org.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail From: Borneq Newsgroups: pl.comp.programming Subject: =?UTF-8?B?UmU6IEphayBzdHdpZXJkemnEhyB3aWVsa2/Fm8SHIHXFvHl0ZWN6bmVq?= =?UTF-8?Q?_wolnej_pami=c4=99ci=3f?= Date: Fri, 3 Feb 2017 19:35:37 +0100 Organization: ATMAN - ATM S.A. Lines: 16 Message-ID: References: <6c1ebc56-b965-455c-b1f0-f818c821fff1@googlegroups.com> NNTP-Posting-Host: 91.239.205.105 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: node1.news.atman.pl 1486146938 18789 91.239.205.105 (3 Feb 2017 18:35:38 GMT) X-Complaints-To: usenet@atman.pl NNTP-Posting-Date: Fri, 3 Feb 2017 18:35:38 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: Xref: csiph.com pl.comp.programming:29392 W dniu 03.02.2017 o 18:59, bartekltg pisze: > 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 ;-) A tego nie znałem. Stosowałem http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/ALG/Algusm5_1.pdf http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/ALG/Algusm5_2.pdf http://zofia.kruczkiewicz.staff.iiar.pwr.wroc.pl/wyklady/ALG/Algusm5_3.pdf pliki o rozmiarach wynikających z ciągu Fibonacciego któregoś rzędu. Przy czym te pliki zachowywały się jak kolejka, nie można było usunąć z początku (przydałyby się dziury plikowe) to wzrastały do co najmiej wielkości sortowanego pliku. Więc metoda 3 plikowa wymaga 3 krotnie więcej dysku niż ten plik, 5 - plikowa mniej przebiegów ale więcej dysku. Co zrobić aby te 256 plików nie zajmowało 256*65 TB = 17 Petabajtów dysku?