К сожалению, -mlzma:1g:h1g у меня не работает - винды-то 32-битные. Тут дело в не всегда оптимальном выделении памяти. Скажем, у меня с ней такая ситуация:
Allocated 1777 mb, addr=028A0000
Allocated 751 mb, addr=7FFF0000
Allocated 86 mb, addr=71AC0000
Allocated 72 mb, addr=78000000
Allocated 25 mb, addr=7C9C0000
Allocated 19 mb, addr=7E3F0000
Allocated 7 mb, addr=7F7F0000
Allocated 4 mb, addr=77610000
Allocated 2 mb, addr=01CA0000
Allocated 1 mb, addr=77250000
Allocated 1 mb, addr=77C60000
В результате вот что выходит с максимальным размером хеша (дальше пишет can't allocate):
для bt4 (в mb)
<словарь> <макс.хэш> <всего выделено памяти>
64 1259 1867
96 1003 1915
120 811 1951
127 755 1962
128 751 1967
160 751 2271
186 751 2518
192 461 2285
221 418 2518
то есть, судя по всему, тут сначала выделяется dict*8, потом hash, ну а затем несколько небольших кусков размером в общей сложности dict*1.5. В принципе, самый разумный вариант (разве что можно его чуть улучшить, а именно в экзотическом случае если hash>dict*8, выделив сначала память под хэш ).
для ht4:
(1024 1 1281)
- хеш не максимально возможный - просто проверияю, что ht4 выделяет dictsize*1.25+hashsize
1024 490 1770
601 1018 1770
600 1771 2521
400 1771 2271
А вот тут всё не так здорово - сначала выделяется хэш, а уж затем dict*1.25. В принципе, если dict*1.25 можно выделить лишь одним блоком, то единственное улушение для случаев подобных моим - возможность выделить 751 mb хэша для случая dict>815mb (т.е. для 1 Гб - используемая память вырастет с 1770 до 2031). А вот если можно было бы выделить dict и dict*0.25 отдельными кусками, то появляется больше возможностей для улушения - вместо ограничения hash+1.25*dict<1771 (если hash либо 1.25*dict больше 751 Мб) - получится hash+dict<1771, т.е. для 1 Гб dict можно было бы выделить те же 751 Мб, а вот для 1000 Мб - уже 771, не говоря уж о словаре 750 Мб, к которому можно выделить аж 1770 Мб хеша вместо 832 Мб.
Короче, можно сначала выделять самый большой кусок, потом следующий по размеру и т.д. и для ht4 (с учётом соотношения hashsize и dictsize)? И можно ли кусок 1.25*dict разбить на два?
Allocated 1777 mb, addr=028A0000
Allocated 751 mb, addr=7FFF0000
Allocated 86 mb, addr=71AC0000
Allocated 72 mb, addr=78000000
Allocated 25 mb, addr=7C9C0000
Allocated 19 mb, addr=7E3F0000
Allocated 7 mb, addr=7F7F0000
Allocated 4 mb, addr=77610000
Allocated 2 mb, addr=01CA0000
Allocated 1 mb, addr=77250000
Allocated 1 mb, addr=77C60000
В результате вот что выходит с максимальным размером хеша (дальше пишет can't allocate):
для bt4 (в mb)
<словарь> <макс.хэш> <всего выделено памяти>
64 1259 1867
96 1003 1915
120 811 1951
127 755 1962
128 751 1967
160 751 2271
186 751 2518
192 461 2285
221 418 2518
то есть, судя по всему, тут сначала выделяется dict*8, потом hash, ну а затем несколько небольших кусков размером в общей сложности dict*1.5. В принципе, самый разумный вариант (разве что можно его чуть улучшить, а именно в экзотическом случае если hash>dict*8, выделив сначала память под хэш ).
для ht4:
(1024 1 1281)
- хеш не максимально возможный - просто проверияю, что ht4 выделяет dictsize*1.25+hashsize
1024 490 1770
601 1018 1770
600 1771 2521
400 1771 2271
А вот тут всё не так здорово - сначала выделяется хэш, а уж затем dict*1.25. В принципе, если dict*1.25 можно выделить лишь одним блоком, то единственное улушение для случаев подобных моим - возможность выделить 751 mb хэша для случая dict>815mb (т.е. для 1 Гб - используемая память вырастет с 1770 до 2031). А вот если можно было бы выделить dict и dict*0.25 отдельными кусками, то появляется больше возможностей для улушения - вместо ограничения hash+1.25*dict<1771 (если hash либо 1.25*dict больше 751 Мб) - получится hash+dict<1771, т.е. для 1 Гб dict можно было бы выделить те же 751 Мб, а вот для 1000 Мб - уже 771, не говоря уж о словаре 750 Мб, к которому можно выделить аж 1770 Мб хеша вместо 832 Мб.
Короче, можно сначала выделять самый большой кусок, потом следующий по размеру и т.д. и для ht4 (с учётом соотношения hashsize и dictsize)? И можно ли кусок 1.25*dict разбить на два?