Нужен контейнер который может на 32 битной среде хранить памяти как на 64 битной.
Вот примерно так 

не понял вопроса, ибо 32-битные переменные адресуют до 4,294,967,295

Только если этот контейнер будет сбрасывать данные в файл. В 32-битной среде максимальный объём памяти - 4Gb.

понял 
так ведь нет нужды держать в памяти все данные.

bigVector внутри имеет структуру хранящюю 32 битные указатели
типа

Отдельные треды не помогут (разве что если ОС 64 битная, а приложение 32 битное, и то не уверен - но зачем делать 32-битное приложение, которое будет выполняться только 64-битной среде?), нужно сбрасывать данные на диск.

Сбрасывать на диск это тратить время. И получится просто мини-субд.
Да среда 64 бит соответственно в ней может быть установлено 20 гигабайт.
А приложение 32 бит.  Преимущества экономия на размере указателя в 32 бит и если важная для приложения сторонняя библиотека доступна только в 32 битном варианте.
Если 100000 элементов то при размере указателя 64 тратится 6 мб и 3 мб для 32.
Но главное просто интересно.

Вот интересует быстрая ли скорость обмена между потоками? 

acalister, данные, в эти вектора, откуда берутся?

Добавлено @ 12:56
acalister, и вообще, объясни задачу от А до Я. что мы тут, гадать должны?...

Это сообщение отредактировал(а) boostcoder - 7.11.2011, 12:57

Имеется ввиду откуда поступают данные?
vector.push_back( данные? );
Это разве имеет значение?

Допустим с диска файла размером 10 гигабайт или по сети из базы данных.

...
Мне нужно в оперативной памяти держать 10 гигабайт в одном контейнере в 32 битной среде.
Чтобы доступ на чтение vector[индекс]   и вставку в конец(кроме создания нового потока) выполнялся за быстрое константное время.
Я думал что в boost или других библиотеках должны быть подобные контейнеры.

ну вот. это и есть ключевой момент, который говорит о том, что нет смысла загружать весь объем сразу.


это тебе так кажется. не нужно.



а теперь рассказывай, как эти данные используются? что за алгоритм такой?

Интересно, с тех пор, как знаком с потоками, был уверен, что все переменные созданные в одном потоке доступны и во втором. Таким образом, сколько ты потоков не делай, все они будут иметь доступ к общим 2 ГБ ОЗУ на 32-х разрядной ОС (если не выставлены какие-то хитрые флаги, разрешающие выделение памяти более 2 ГБ)

Это сообщение отредактировал(а) bsa - 7.11.2011, 13:05

bsa, про потоки рано думать. тут подход к решению в корне не правильный. нужно с этого начинать, а не лечить последствия кривой архитектуры/логики проекта.

boostcoder, это я для общего развития сказал.   

Смысл в чем. При старте приложение тратит продолжительное время на помещение данных в оперативную память. 
А затем уже быстро раздает их оттуда. 
Обычные субд при выполнении запроса типа посчитать сколько записей где время между 3 месяцами назад и 6 начинают выполнить его очень долго. 
Если общее количество записей составляет несколько милионов.
А если это делать в оперативной памяти то выйдет быстрее.

acalister, ясно. Но в любом случае чуда не произойдет. И найдется такой набор данных, который в ОЗУ конкретного компа не влезет. Поэтому, тебе необходимо делать оптимальный поиск. Я так понял, тебе надо парсить что-то вроде логов. Там записи идут в хронологическом порядке, поэтому зная дату первой записи и дату последней можно найти искомую за Log N попыток (N - число записей), если использовать двоичный поиск. Да, конечно, если весь журнал будет в ОЗУ, то скорость операции будет значительно выше, чем при считывании с диска... Кстати, никто не мешает при запуске приложения проиндексировать лог и хранить в ОЗУ только расположение дат в файле. Таким образом поиск будет осуществляться по данным из ОЗУ.