Заюзать >10G памяти под GMP integer

перейти на 64 бита

запустить 4 виртуальных машины, в каждой по 2.8 простарнства
итого >10

это полушутка :))

To Reset: а что, мысль! To anonymous: А как я ОДНО число буду на четырех VM крутить?

> Как бы мне это сделать

курить второй том кнута.

делаем абстракцию - есть набор абстрактных ф-й/методов класса: сложение, деление, умножение, etc. есть вектор байтов, который представляет число произвольной размерности. соответсвенно все математические операции имплементятся побитово.

btw: просто уверен, что есть библиотеки для c и c++ реализующие данный функционал.

тебе нуже AMD64 и не изобретай костыли

Собственно GMP из сабжа этим и занимается. Тут вопрос в другом.

Откуда у тебя такое???

Пытаешся поставить рекодр по наидлиннейшему найденному простому числу? :)

вопрос: зачем вам такое большое число? 10^(1e10) это больше чем 10^100(гугл), т.е больше чем количество частиц во всей вселенной...

даже если вам удастся его загнать в память оперировать вы им не сможете, оно там займет по самым скромным прикидкам 30Гб(??), или я что-то плохо считаю...

гугл съел мой мозг...

s/10^100(гугл)/10^100(гугол)/

> гугл съел мой мозг...

google по английски это и есть гугол ;)

> google по английски это и есть гугол ;)

Мой тоже съел, но вообще название google произошло именно от математического googol

всетаки: google -> гугл, а googol -> гугол

сделать свой страничный менеджер памяти с возможностью выгрузки разлоченных страниц на диск
далее написать paged container который будет по интерфейсу как какой нить std::vector но при этом будет работать с страницами

ну вот еще покури
http://gmplib.org/manual/Custom-Allocation.html#Custom-Allocation

> Как бы мне это сделать

Используй математику.

Мне жутко интересно, зачем понадобилось такое число?

1. Кто-то там про простые числа говорил - почти прав. Это часть большого проекта по обнаружению больших простых чисел.

2. На AMD64 не пробовал, хотя в принципе, если там size_t 8 байт, то все должно получиться. Сегодня попробую и расскажу.

3. Крутиться все это дело будет на Beowulf кластере. И я знаю что очень долго будет крутиться.

4. Товарища dave прошу пояснить ответ "используй математику". Математика может уговорить ядро отдать >2.8 G памяти? Или математика может подсказать мне как реализовать операции с таким числом по частям? Если да, то очень прошу кинуть в меня ссылкой на то КАК.

5. Число займет ориентировочно 10G, математика тут такая: 4 байта ~ 9,5 цифр (log10(2^32)).

6. Товарища acefcm прошу пояснить как сделать свой страничный менеджер памяти с возможностью выгрузки разлоченных страниц на диск далее написать paged container который будет по интерфейсу как какой нить std::vector но при этом будет работать с страницами. Просто я даже не знаю как начать. Можно ссылку на курево?

7. http://gmplib.org/manual/Custom-Allocation.html#Custom-Allocation читал, но не понял, как мне это поможет. Ну напишу я свой аллокатор, а к нему что, ядро будет добрее и даст больше памяти?

8. Отчетливо вижу вариант, от которого очень хотелось бы уйти: выкинуть GMP, написать свой класс для работы со сверхдлинными цифрами и использовать в качестве хранилища байтов, составляющих число, файл. Но ИМХО это будет ДИКО тормозить, поэтому это так сказать last resort.

> Или математика может подсказать мне как реализовать операции с таким числом по частям?

Искать другое представление для чисел. Например, дроби простые или цепные. В зависимости от того, что больше подходит для задачи. Назовем это условно "математическим" подходом.

Если все таки есть желание считать "в лоб", то самое простое - использовать [объектные] базы данных, что-нибудь вроде Berkeley. Разбить число на чанки (цифр штук по 1024 или 2^N), а потом в базе хранить односвязный список из этих чанков - вот и огромное число в базе. Потом самостоятельно определить основные арифметические операции. Требует минимум вмешательств в работу системы. Пусть это будет "программисткий" подход.

При желании можно сочетать оба подхода.

Пробовал под AMD64

Вот такая простенькая программулька:

#include <stdio.h> #include <stdlib.h>

int main(){ size_t siz = 100 * 1024 * 1024 ; size_t idx = 1 ; void *ptr;

for (;;){ ptr = malloc ( siz * idx ); if(!ptr) break ; free(ptr); idx++; } printf ("Max malloc %d * 100 MB \n", idx - 1 ); return (0); }

дает следующий результат

$ ./allocate Max malloc 26 * 100 MB 2.6G. Черт, меньше чем на x86!

Ты ДОЛЖЕН пользовать 64-битное ядро и перекомпилить свою прогу в 64-битный код.

на текущий момент ни ядро ни прога даже не подозревают что твоя железка умеет 64 бита

Linux ???????.homeunix.com 2.6.22-gentoo-r2 #2 PREEMPT Fri Aug 17 03:00:18 MSD 2007 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

Ядро 64. Насчет проги не понял - а как ей объяснить? Хотя... пока это писал подумал, что возможно надо это объяснить не ей, а gcc? С другой стороны, если у меня все собрано под 64 - надо ли ему об этом объяснять? Поясните пожалуйста, предыдущий оратор.

И еще вопрос: а mmap мне не поможет здесь? Не могу ли я случайно mmapнуть 10G файлик и наслаждаться треском винчестера?

>Linux ???????.homeunix.com 2.6.22-gentoo-r2 #2 PREEMPT Fri Aug 17 03:00:18 MSD 2007 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux

>Ядро 64.

возможно. ты явно пускал 32-битную прогу и посему я предположил что ты пользуеш такоеже ядро

Насчет проги не понял - а как ей объяснить? Хотя... пока это писал подумал, что возможно надо это объяснить не ей, а gcc? С другой стороны, если у меня все собрано под 64 - надо ли ему об этом объяснять? Поясните пожалуйста, предыдущий оратор.

ты должен указать gcc ключики типа -m64 -mcpu=k8 -mtune=k8 -march=k8

И еще вопрос: а mmap мне не поможет здесь? Не могу ли я случайно mmapнуть 10G файлик и наслаждаться треском винчестера?

после использования ключиков приведённых выше - иначе будет тоже что и malloc()

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

\\wbr cvv