Здравствуйте, <Аноним>, Вы писали:

А>На кой черт здесь вообще потоки нужны? Операции с диском съедят выигрыш в производительности, если только функция сравнения двух элементов (а тут всего лишь сравнение чисел) не требует длительных вычислений.

А>По коду. Очень много букв. Можно было написать короче. Зачем-то классы притянуты за уши, хотя задача довольно процедурная.

А>По поводу алгоритма. Куски по 256 Мб можно отсортировать в памяти любым понравившися алгоритмом. Далее сортировкой слиянием в каждом проходе по файлу объединять 2 соседних куска данных.
А>Примерно получится log2(16 Гб / 256 Мб) + 1 = 7 проходов по файлу на диске.

Приводили решение с 2мя доступами к данным.

Здравствуйте, Аноним, Вы писали:

А>По поводу алгоритма. Куски по 256 Мб можно отсортировать в памяти любым понравившися алгоритмом. Далее сортировкой слиянием в каждом проходе по файлу объединять 2 соседних куска данных.

сливать можно все куски разом.

Здравствуйте, VEAPUK, Вы писали:

VEA>Здравствуйте, Аноним, Вы писали:

А>>По поводу алгоритма. Куски по 256 Мб можно отсортировать в памяти любым понравившися алгоритмом. Далее сортировкой слиянием в каждом проходе по файлу объединять 2 соседних куска данных.

VEA>сливать можно все куски разом.

Ааа... Об этом я не подумал)
Можно было бы heap держать, с минимальным элементом в каждом куске. Хотя бы.

У Кормена было где-то такое упражнение на сливание множества отсортированных массивов.