самое простое - реализовать примитивный менеджер вирт. памяти. - резервируем буфер в 16 гигов с помощью VirtualAlloc (PAGE_RESERVE). - обрабатываем исключение при доступе к незагруженной части буфера. - в обработчике подгружаем требуемые страницы. - потом передаем управление обратно на код вызвавший исключение. когда количество commited страниц достигнет максимума, освобождаем все страницы ))). или по какому нить критерию. Естественно, вместо VirtualAlloc логичнее сделать маппинг файла. а потом нужные страницы подгружать с MapVIewOfFIle. Но ни то ни другое я на практике не проверял, так что мне самому интересно решение данной задачи. )
Вопрос - какого *** не подходит обычынй мапинг? ОС _НИКОГДА_ не проецирует файл полностью без надобности. Будут созданы только элементы таблицы страниц с невалидными пте. И только по фактическому обращению будут подкачаны с диска страницы. Причем механизм выгрузки страниц обратно сделан весьма эффективно (не уверен, что ваша реализация будет лучше). l_inc +1. Зачем изобретать велосипед? Готов поспорить - это будет эффективнее, чем вручную подгружать страницы. Наоборот будет лишь _только_ в том случае, если вы реализуете лучшую стратегию выгрузки (по таймауту, по счетчику обращений, ...). Это возможно только в том случае, если вы хорошо знаете, когда, как и как часто будут обращения к каким кускам буффера. В противном случае берите встроенный в ОС маппинг - не пожалеете
Great Дело в том, что алгоритм уже реализован, поэтому суть вопроса: как без изменения алгоритма можно организовать доступ к такому объему.
а я не предлагал менять алгоритм. я говорил про алгоритм подкачки, который собирались писать самостоятельно на экцепшонах
Great Никто, кроме грита и не собирался писать свой на эксепшенах. Ну еще была идея организовать "окно" ну это скорее чтобы не расходовать зазря память. А так мапировани проканало, пока правда появилась еще одна проблема "бэд аллок" где-то внутри программы, это может быть из-за недостаток оперативной памяти? на всякий случай файл подкачки у меня в 30 Гб.
