|
|
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
user_aа под 64 бит же тоже может не оказаться непрерывного куска в несколько ГБ? тогда в чём разница, именно в этой части? т.е., всё равно придётся создавать массив "по частям". а ещё в delphi переменная не может быть более 2 гб. так что "одним куском" и так бы не получилось. Вы хотите странного. Зачем вам непрерывный кусок памяти более 2-х гб да еще "в одной переменной" (даже не знаю что бы это значило)? P.S. Поставьте на сервер 512 Гб оперативки. Все шансы на то что 4 гига непрерывным куском вы найдете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 20:42:25 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Код: pascal 1. 2. 3. 4. Выделился массив на 5 гигов. Что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 21:06:00 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
ну, тот же динамический массив - одна переменная. а если задавать тип как одномерный массив, а другой тип, как одномерный массив элементов первого типа, то переменная 2-го типа будет хранить указатели на переменные 1-го типа, каждые из которых не могут превышать 2 гб, но в целом "массив" может превышать 2 гб. а если задать сразу двухмерный массив в одном типе данных, то весь массив не сможет превышать 2 гб. это в delphi 32-бит, в смысле. и в каком виде предлагается хранить линейную последовательность данных большого объёма, чтобы по-правильному? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 21:32:40 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
rgreat, попробуй, к слову, в него залить 5 гиг. получится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:15:20 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
user_a, ну,тот же динамический массив - одна переменная.да, одна переменная - глобальная или на стеке, размер которой SizeOf(Pointer). И в эту переменную, после удачного вызова GetMem или SetLength, будет записан адрес (начало) виртуального адресного куска нужной длины. и в каком виде предлагается хранить линейную последовательность данных большого объёма,на диске в файле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:23:39 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
makhaonrgreat, попробуй, к слову, в него залить 5 гиг. получится? Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ';245;246;247;248;249;250;251;252;253;254;255' ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:34:22 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
i : Int64; конечно-же. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:35:58 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
В памяти - 5 с лишним гигов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:36:38 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
user_aи в каком виде предлагается хранить линейную последовательность данных большого объёма, чтобы по-правильному?В том, который нужен по условию задачи. Если это не мешает быстродействию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:39:15 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
На очень больших объемах я бы посоветовал рекорды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:40:17 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
user_aэффективность занимаемого пространства - сильно уменьшилась. https://kent.dl.sourceforge.net/project/freepascal/Win32/3.0.2/fpc-3.0.2.i386-win32.cross.x86_64-win64.exe Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 22:59:03 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
user_aа под 64 бит же тоже может не оказаться непрерывного куска в несколько ГБ? Крайне маловероятно. Там теоретические 16 эксабайт, с практическим пределом в 8 Тб для user mode (надо проверить, может в последних версиях Windows уже подняли). user_aа ещё в delphi переменная не может быть более 2 гб Смотря какая переменная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.06.2017, 23:50:04 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
В этом вопросе главное не путать физическую память с виртуальной памятью процесса. Под х64 нет проблем выделить большой непрерывный кусок. Размер будет ограничиваться только размером подкачки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 13:13:02 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Barmaley57, у некоторых программ с этим проблемы. Я столкнулся с таким, когда эмулятору андроида (во времена ХЕ5) задал устройство с 512мб памяти, и он при старте псевдо-устройства не мог выделить кусок памяти. Хотя на 16 гиг RAM было свободно больше половины. Помогала только перезагрузка ОС и сразу запуск эмулятора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 15:13:44 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Barmaley57В этом вопросе главное не путать физическую память с виртуальной памятью процесса. Под х64 нет проблем выделить большой непрерывный кусок. Размер будет ограничиваться только размером подкачки. В ряде случаев, на Windows, нифига ничего не выделяется. Почему и в чем у кого проблемы, фиг его знает. Сталкивался на Windows 7, комп с RAM 32 Gb, при попытке запускать много приложений иногда около 6-8 Gb под Java JVM одним куском Windows выделить не мог. Хотя и виртуальной и даже просто free памяти (32 Gb - использованное место) было достаточно. На компе запускалась пара виртуалок в VmWare Player'е + JDeveloper + пара инстанцев WebLogic + Oracle Database. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:13:10 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevВ ряде случаев, на Windows, нифига ничего не выделяется. Почему и в чем у кого проблемы, фиг его знает. Подкачка,проецируемые в память файлы, кэш... Где-то должен быть затык. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:26:19 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Мешала фрагментация скорей всего. Нужен-то непрерывный кусок в 6-8 гб. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:26:57 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
rgreatМешала фрагментация скорей всего. Нужен-то непрерывный кусок в 6-8 гб.Не помню точно, но есть флаги для выделения памяти сверху/снизу. Может снизу был облом из-за фрагментации. Но сверху никто не мешает замапить кусок. В х64 сколько адресного пространства - попой ешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:29:28 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Я к тому, что утверждение В этом вопросе главное не путать физическую память с виртуальной памятью процесса. Под х64 нет проблем выделить большой непрерывный кусок. Размер будет ограничиваться только размером подкачки. не совсем истинное. Проблемы могут быть. В чем и у кого... ОС, кривые руки разработчиков, что-то еще... не столь важно. В общем, не стал бы относить решение "выделить дофига ГигаБайт одним куском" к бест практикс. IMHO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 20:33:44 |
|
||
|
работа с большими объёмами памяти
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev, ну дык авторРазмер будет ограничиваться только размером подкачки А так-то да. Какой-нить орацл забабахает mmf, выжрав всю подкачку и привет. А теоретически - проблем нет. Для х86 нельзя выделить 5 гигов даже теоретически, а для х64 - можно. Вот я о чем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2017, 21:01:34 |
|
||
|
|

start [/forum/topic.php?fid=58&gotonew=1&tid=2042104]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
63ms |
get topic data: |
7ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
42ms |
get tp. blocked users: |
2ms |
| others: | 228ms |
| total: | 372ms |

| 0 / 0 |
