Здравствуйте, c-smile, Вы писали:

CS>Двойной это еще хорошо. На практике это отношение даже еще больше.
CS>Вот пример отсюда:
CS>http://www.petefreitag.com/articles/gctuning/

Ключевое слово — JVM, это всемирно известный поедатель памяти. Больше него никто не ест, судя по шутауту. Я все же рекомендую посмотреть на GC в CLR и, например, Окамле.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, c-smile, Вы писали:

CS>>Двойной это еще хорошо. На практике это отношение даже еще больше.
CS>>Вот пример отсюда:
CS>>http://www.petefreitag.com/articles/gctuning/

DM>Ключевое слово — JVM, это всемирно известный поедатель памяти. Больше него никто не ест, судя по шутауту. Я все же рекомендую посмотреть на GC в CLR и, например, Окамле.

Давай про OCaml поговорим. В OCaml heap устроен из двух несимметричных половин — minor и major heaps.
minor heap это блок памяти (128Kb by default on 32bit). Память выделяется просто инкрементом указателя caml_young_ptr и проверкой оного на предмет caml_young_limit. При переполнении minor heap происходит GC который копирует все reachable объекты из minor heap в major heap.
Т.е. принцип — всё тот же Cheney's algorithm. Отсюда естественный вывод: Ocaml heap в любой конкретный момент времени (после первого GC) должен иметь major heap равный по размеру minor heap'у. Т.е. имеем превышение как минимум в два раза. Что и требовалось доказать.

В CLR та же история.

В такие вот они индейские национальные лодки.

Здравствуйте, c-smile, Вы писали:

CS>Давай про OCaml поговорим. В OCaml heap устроен из двух несимметричных половин — minor и major heaps.
CS>minor heap это блок памяти (128Kb by default on 32bit). Память выделяется просто инкрементом указателя caml_young_ptr и проверкой оного на предмет caml_young_limit. При переполнении minor heap происходит GC который копирует все reachable объекты из minor heap в major heap.
CS>Т.е. принцип — всё тот же Cheney's algorithm. Отсюда естественный вывод: Ocaml heap в любой конкретный момент времени (после первого GC) должен иметь major heap равный по размеру minor heap'у. Т.е. имеем превышение как минимум в два раза. Что и требовалось доказать.

Интересная у тебя арифметика. Если данных у программы 50 мегов, и она держит на 128 кб больше, то это превышение в 2 раза?

И это совсем не Cheney, там "the heap is divided into two equal halves, only one of which is in use at any one time".
В Окамле и CLR это совсем не equal parts.

А про любой момент времени откуда следует? Размер куч/поколений динамически меняется при сборках.

CS>В CLR та же история.

Копируются данные из 0 и 1 поколения во второе, там уже сидят неподвижно. Размер 0 и 1 поколения невелик и при заметном объеме реальных данных мало влияет на картину. На реальном приложении я наблюдаю 20-50% разницы, отнюдь не 2-5 раз.

Здравствуйте, c-smile, Вы писали:

CS>Давай про OCaml поговорим. В OCaml heap устроен из двух несимметричных половин — minor и major heaps.
CS>minor heap это блок памяти (128Kb by default on 32bit). Память выделяется просто инкрементом указателя caml_young_ptr и проверкой оного на предмет caml_young_limit. При переполнении minor heap происходит GC который копирует все reachable объекты из minor heap в major heap.

CS>Т.е. принцип — всё тот же Cheney's algorithm. Отсюда естественный вывод: Ocaml heap в любой конкретный момент времени (после первого GC) должен иметь major heap равный по размеру minor heap'у. Т.е. имеем превышение как минимум в два раза. Что и требовалось доказать.

Вы ужасную ерунду написали

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, c-smile, Вы писали:

CS>>Давай про OCaml поговорим. В OCaml heap устроен из двух несимметричных половин — minor и major heaps.
CS>>minor heap это блок памяти (128Kb by default on 32bit). Память выделяется просто инкрементом указателя caml_young_ptr и проверкой оного на предмет caml_young_limit. При переполнении minor heap происходит GC который копирует все reachable объекты из minor heap в major heap.
CS>>Т.е. принцип — всё тот же Cheney's algorithm. Отсюда естественный вывод: Ocaml heap в любой конкретный момент времени (после первого GC) должен иметь major heap равный по размеру minor heap'у. Т.е. имеем превышение как минимум в два раза. Что и требовалось доказать.

DM>Интересная у тебя арифметика. Если данных у программы 50 мегов, и она держит на 128 кб больше, то это превышение в 2 раза?

Ну давай уже про арифметику тогда.
По определению если у программы 50mb навыделялось то все это произошло порциями по 128kb за 390 GC циклов.
Если скажем эти 50mb выделились в момент запуска приложения то 390 раз GC это много (если вежливо).
Скажем каждый GC цикл это 100ms (оптимистично так). Т.е. наше приложение будет запускаться как минимум 39 секунд.

Такая арифметика тебе нравится? Я думаю что нет ибо ...
Скажем 50mb это голый Firefox в памяти. 39 секунд на загрузку это смэрть.

Для того чтобы это все как-то шевелилось объем minor heap должен быть соизмерим с major heap. Т.е. всё то же 2:1 соотношение.

Теперь ты упомянул про shootout, я так понимаю ты имелл ввиду это вот:
http://shootout.alioth.debian.org/u64q/ocaml.php

Обрати внимание на FASTA тест (структуры данных DNA). Ocaml'у нужно в 137 раз больше памяти чтобы посчитать это дело с приемлемой скоростью (в 2 раза медленнее чем C++).

DM>И это совсем не Cheney, там "the heap is divided into two equal halves, only one of which is in use at any one time".
DM>В Окамле и CLR это совсем не equal parts.

Еще раз: минимальная память требуемая managed системе в два раза больше чем в non-managed (C heap). By design.
Если говорить про комфортно-рабочую память то см. арифметику выше. На практике managed система требует в 3 раза больше памяти чем не managed.

DM>А про любой момент времени откуда следует? Размер куч/поколений динамически меняется при сборках.

Допустим он меняется и что? Кто-то отдает память в систему при этом? А смысл?

CS>>В CLR та же история.

DM>Копируются данные из 0 и 1 поколения во второе, там уже сидят неподвижно. Размер 0 и 1 поколения невелик и при заметном объеме реальных данных мало влияет на картину. На реальном приложении я наблюдаю 20-50% разницы, отнюдь не 2-5 раз.

Ну вот твой shootout опять C# Mono vs GNU C:
http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=csharp&lang2=gcc

Здравствуйте, z00n, Вы писали:

Z>Здравствуйте, c-smile, Вы писали:

CS>>Давай про OCaml поговорим. В OCaml heap устроен из двух несимметричных половин — minor и major heaps.
CS>>minor heap это блок памяти (128Kb by default on 32bit). Память выделяется просто инкрементом указателя caml_young_ptr и проверкой оного на предмет caml_young_limit. При переполнении minor heap происходит GC который копирует все reachable объекты из minor heap в major heap.

CS>>Т.е. принцип — всё тот же Cheney's algorithm. Отсюда естественный вывод: Ocaml heap в любой конкретный момент времени (после первого GC) должен иметь major heap равный по размеру minor heap'у. Т.е. имеем превышение как минимум в два раза. Что и требовалось доказать.

Z>Вы ужасную ерунду написали

Где конкретно?

Здравствуйте, c-smile, Вы писали:

CS>Ну давай уже про арифметику тогда.
CS>По определению если у программы 50mb навыделялось то все это произошло порциями по 128kb за 390 GC циклов.
CS>Если скажем эти 50mb выделились в момент запуска приложения то 390 раз GC это много (если вежливо).
CS>Скажем каждый GC цикл это 100ms (оптимистично так). Т.е. наше приложение будет запускаться как минимум 39 секунд.
CS>Такая арифметика тебе нравится? Я думаю что нет ибо ...
CS>Скажем 50mb это голый Firefox в памяти. 39 секунд на загрузку это смэрть.

Очень плохая арифметика у тебя, в сто раз ошибся.
Вот программа, создающая миллион строк по 50 символов:

let a = Array.init 1000000 (fun i -> String.make 50 'x') in
Printf.printf "%c %c %c\n" a.(0).[49] a.(999999).[9] a.(123456).[12];
Gc.print_stat stdout

Работает 0.35 с. Памяти ест 63 мега. Т.е. больше 50, но не в 2-3 раза отнюдь.
431 minor collections, 10 major collections.

CS>Для того чтобы это все как-то шевелилось объем minor heap должен быть соизмерим с major heap. Т.е. всё то же 2:1 соотношение.

Опять мимо.

let c = Gc.get () in
Printf.printf "minor heap = %d words\n" c.Gc.minor_heap_size

minor heap = 32768 words
(пользуюсь версией 3.10.2, Win32).

CS>Теперь ты упомянул про shootout, я так понимаю ты имелл ввиду это вот:
CS>http://shootout.alioth.debian.org/u64q/ocaml.php

CS>Обрати внимание на FASTA тест (структуры данных DNA). Ocaml'у нужно в 137 раз больше памяти чтобы посчитать это дело с приемлемой скоростью (в 2 раза медленнее чем C++).

Это решение конкретного программиста — выделить сразу сотни буферов по мегабайту. Не показательно.
А вот то, что в 5 из 10 примеров Окамл съел меньше памяти, чем Си, это показательно.


DM>>И это совсем не Cheney, там "the heap is divided into two equal halves, only one of which is in use at any one time".
DM>>В Окамле и CLR это совсем не equal parts.

CS>Еще раз: минимальная память требуемая managed системе в два раза больше чем в non-managed (C heap). By design.

Define минимальная память.

CS>Если говорить про комфортно-рабочую память то см. арифметику выше. На практике managed система требует в 3 раза больше памяти чем не managed.

Какая именно? Java может быть. CLR и Окамл — мой опыт говорит о другом.

DM>>А про любой момент времени откуда следует? Размер куч/поколений динамически меняется при сборках.

CS>Допустим он меняется и что? Кто-то отдает память в систему при этом? А смысл?

Да, отдает. Тот же CLR оперирует сегментами по 16 мегов. Освободился сегмент — отдал память.

CS>>>В CLR та же история.

DM>>Копируются данные из 0 и 1 поколения во второе, там уже сидят неподвижно. Размер 0 и 1 поколения невелик и при заметном объеме реальных данных мало влияет на картину. На реальном приложении я наблюдаю 20-50% разницы, отнюдь не 2-5 раз.

CS>Ну вот твой shootout опять C# Mono vs GNU C:

В моно совсем другой GC чем в CLR, он там вообще консервативный до сих пор.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, c-smile, Вы писали:

CS>>Ну давай уже про арифметику тогда.
CS>>По определению если у программы 50mb навыделялось то все это произошло порциями по 128kb за 390 GC циклов.
CS>>Если скажем эти 50mb выделились в момент запуска приложения то 390 раз GC это много (если вежливо).
CS>>Скажем каждый GC цикл это 100ms (оптимистично так). Т.е. наше приложение будет запускаться как минимум 39 секунд.
CS>>Такая арифметика тебе нравится? Я думаю что нет ибо ...
CS>>Скажем 50mb это голый Firefox в памяти. 39 секунд на загрузку это смэрть.

DM>Очень плохая арифметика у тебя, в сто раз ошибся.

Арифметика у меня нормальная — время на GC в OCaml есть величина неизвестная — зависит от количества аллокаций.

DM>Вот программа, создающая миллион строк по 50 символов:
DM>

DM>let a = Array.init 1000000 (fun i -> String.make 50 'x') in
DM>Printf.printf "%c %c %c\n" a.(0).[49] a.(999999).[9] a.(123456).[12];
DM>Gc.print_stat stdout
DM>

DM>Работает 0.35 с. Памяти ест 63 мега. Т.е. больше 50, но не в 2-3 раза отнюдь.
DM>431 minor collections, 10 major collections.

Не совсем жизненый пример. Array.init 1000000 у тебя попадает сразу в major heap (в OCaml).
В реальности количество строк неизвестно — скажем читаем текстовый файл. Т.е. тебе нужно
делать динамический массив. А вот с ним уже будет грустно ибо когда он перестанет помещаться в minor heap
начент забиваться major heap неиспользованными фрагментами.

Ладно, вот тебе то же самое на С

#include "string.h"
#include "conio.h"
#include "windows.h"

struct perf_counter
{
  LARGE_INTEGER start;
  LARGE_INTEGER freq;

  perf_counter()
  {
    ::QueryPerformanceCounter(&start);
    ::QueryPerformanceFrequency(&freq);
  }
  double elapsed()
  {
    LARGE_INTEGER stop;
    ::QueryPerformanceCounter(&stop);
    return double(stop.QuadPart - start.QuadPart) * 1000.0 / double(freq.QuadPart);
  }
};

inline char* makestr(int size, char init)
{
   char* s = new char[size];
   memset(s,init,size);
   return s;
}

int main(int argc, char* argv[])
{
  perf_counter _pc;
  char** m = new char*[1000000];
  for(int n = 0; n < 1000000; ++n)
    m[n] = makestr(50,'x');
  printf( "%c %c %c\n", m[0][49], m[999999][9], m[123456][12]);
  printf( "elapsed %f ms\n", _pc.elapsed());
  getch();
  return 0;
}

Можешь попробовать у себя и сообщить результат.

У меня на машине например elapsed = 0.15 секунды. Против твоих 0.35.

Как я уже сказал тут наличествует trade-off:
Чем более компактный managed heap тем более ты платишь за это CPU циклами (431 GCs у тебя это много).
Т.е. если оптимизировать GC для этого конкретного случая то нужно увеличивать размер minor heap в разы.
В этом случае ты приблизишься по скорости к С версии но требуемая память возрастет.

CS>>Для того чтобы это все как-то шевелилось объем minor heap должен быть соизмерим с major heap. Т.е. всё то же 2:1 соотношение.

DM>Опять мимо.

Ох ё мое. Ну давай скомпилируй С версию и запусти на своей машине.
Теперь запусти свою OCaml версию и попробуй отрихтовать размер minor heap так чтобы оно приблизилось по скорости к C. За для просветления.

CS>>Теперь ты упомянул про shootout, я так понимаю ты имелл ввиду это вот:
CS>>http://shootout.alioth.debian.org/u64q/ocaml.php

CS>>Обрати внимание на FASTA тест (структуры данных DNA). Ocaml'у нужно в 137 раз больше памяти чтобы посчитать это дело с приемлемой скоростью (в 2 раза медленнее чем C++).

DM>Это решение конкретного программиста — выделить сразу сотни буферов по мегабайту. Не показательно.

Это как раз имеенно то что ты и сделал в своем примере.

DM>А вот то, что в 5 из 10 примеров Окамл съел меньше памяти, чем Си, это показательно.

Как я уже сказал выше — за память платим CPU.
Во всех этих пяти примерах мы имеем пропорциональное ухудшение времени исполнения.
Чудес не бывает к сожалению.

Здравствуйте, D. Mon, Вы писали:

DM>Копируются данные из 0 и 1 поколения во второе, там уже сидят неподвижно.

А когда второе поколение заполнится?

Здравствуйте, Трурль, Вы писали:

DM>>Копируются данные из 0 и 1 поколения во второе, там уже сидят неподвижно.

Т>А когда второе поколение заполнится?

Там при сборке мусор превращается в свободное пространство, но без компактификации — как в Си. Свободное место по возможности переиспользуется, но фрагментация все равно есть.
http://vineetgupta.spaces.live.com/blog/cns!8DE4BDC896BEE1AD!1104.entry?sa=973116136

Здравствуйте, c-smile, Вы писали:

DM>>let a = Array.init 1000000 (fun i -> String.make 50 'x') in

CS>Не совсем жизненый пример. Array.init 1000000 у тебя попадает сразу в major heap (в OCaml).

Это массив указателей. Он сам — да, минует minor heap. Но каждая из миллиона строк создается именно в minor heap и потом переносится оттуда в major, как ты и говорил. Поэтому пример полностью нормальный.


CS>Можешь попробовать у себя и сообщить результат.
CS>У меня на машине например elapsed = 0.15 секунды. Против твоих 0.35.

Да, у меня похожее соотношение получается. На домашнем ноуте 0.23 и 0.55.

CS>Как я уже сказал тут наличествует trade-off:
CS>Чем более компактный managed heap тем более ты платишь за это CPU циклами (431 GCs у тебя это много).
CS>Т.е. если оптимизировать GC для этого конкретного случая то нужно увеличивать размер minor heap в разы.
CS>В этом случае ты приблизишься по скорости к С версии но требуемая память возрастет.

В данном случае да, согласен. Но ведь им все не исчерпывается. А ты распространяешь такие выводы на общий случай.

CS>Ох ё мое. Ну давай скомпилируй С версию и запусти на своей машине.
CS>Теперь запусти свою OCaml версию и попробуй отрихтовать размер minor heap так чтобы оно приблизилось по скорости к C. За для просветления.

Попробовал. Добавил в начале

let c = Gc.get () in
c.Gc.minor_heap_size <- 20000000;
Gc.set c;

Время работы стало 0.16 с, т.е. в полтора раза быстрее С. Working set практически не изменился. Commit вырос в полтора раза.


CS>>>Обрати внимание на FASTA тест (структуры данных DNA). Ocaml'у нужно в 137 раз больше памяти чтобы посчитать это дело с приемлемой скоростью (в 2 раза медленнее чем C++).

DM>>Это решение конкретного программиста — выделить сразу сотни буферов по мегабайту. Не показательно.

CS>Это как раз имеенно то что ты и сделал в своем примере.

Не вижу связи. Что именно ты хотел этим сказать?

DM>>А вот то, что в 5 из 10 примеров Окамл съел меньше памяти, чем Си, это показательно.

CS>Как я уже сказал выше — за память платим CPU.
CS>Во всех этих пяти примерах мы имеем пропорциональное ухудшение времени исполнения.
CS>Чудес не бывает к сожалению.

Согласен. Да и кодеген у окамла все же не дотягивает до gcc, там же в шутауте далеко не только с памятью работа идет.

В общем, мое резюме такое:
1. На вопрос "всегда ли GC требует вдвое и более больше памяти чем C heap" правильный ответ — нет, далеко не всегда (примеры показаны).
2. На вопрос "во сколько раз больше памяти нужно managed системе, чтобы догнать по скорости Си" правильный ответ — зависит от задачи, но для многих языков/ВМ это все равно недостижимая цель, поэтому ставить такую задачу нет смысла.

Здравствуйте, D. Mon, Вы писали:

DM>В общем, мое резюме такое:
DM>1. На вопрос "всегда ли GC требует вдвое и более больше памяти чем C heap" правильный ответ — нет, далеко не всегда (примеры показаны).
DM>2. На вопрос "во сколько раз больше памяти нужно managed системе, чтобы догнать по скорости Си" правильный ответ — зависит от задачи, но для многих языков/ВМ это все равно недостижимая цель, поэтому ставить такую задачу нет смысла.

На самом деле для класса задач где работа с памятью является основной вопрос
"во сколько раз больше памяти нужно managed системе, чтобы догнать по скорости Си" является правомочным.
Скорость выделения памяти в managed heap конечно же выше чем в C heap. Но частые GC съедают все преимущество.
Т.е. для некоторого allocation pattern существует некий размер minor heap (в OCaml) при котором скорость аллокации (типа нашего примера) становится равной аналогичной в C heap.
При этом как мы с тобой согласились мы платим расходом памяти. Вопрос лишь на сколько / во сколько раз.

Очевидно что в данной задаче которую мы рассматриваем первый же GC в minor heap создаст major heap размером в minor heap.
Т.е. начальное соотношение использованная/полезная память есть 2:1. С ростом аллоцированной памяти это соотношение может меняться.
Но тут как карты лягут. Как я уже говорил если имплементировать чтение в память текстового файла в миллион строк по 50 байт каждая
и динамическом массиве этих строк OCaml'у потребуется что-то типа 2:1 или даже больше (зависит от policy Full-GC).
Non-managed heap в данном случае будет демонстрировать лучшее поведение. Но тоже с определенным overhead (80%-90% полезного использования).

Real-life задачи, например загрузка VS2010 в память, как раз и демонстрируют данную проблему — начальная генерация всего и вся — занимает 4-12 секунд.
После запуска уже не так интенсивно память выделяется — много удаляется на начальной фазе — еще в minor heap GC. Или чего там у них.

Здравствуйте, D. Mon, Вы писали:

DM>Здравствуйте, c-smile, Вы писали:

DM>>>let a = Array.init 1000000 (fun i -> String.make 50 'x') in

CS>>Не совсем жизненый пример. Array.init 1000000 у тебя попадает сразу в major heap (в OCaml).

DM>Это массив указателей. Он сам — да, минует minor heap. Но каждая из миллиона строк создается именно в minor heap и потом переносится оттуда в major, как ты и говорил. Поэтому пример полностью нормальный.

Жизненный пример это когда ты заранее не знаешь сколько будет строк. Я это имел ввиду.
Т.е. тебе придется делать realloc этого массива. Если например использовать удвоение capacity вектора то без Full GC тебе потребуется major heap в два раза больше чем нужно т.е. как минмум 2000000 + собственно 50 мб для строк. На практике же это число будет именно 2:1 (аллоцированная:полезная).
Это если ставить перед собой задачу достижения приемлемого быстродействия.

CS>>Можешь попробовать у себя и сообщить результат.
CS>>У меня на машине например elapsed = 0.15 секунды. Против твоих 0.35.

DM>Да, у меня похожее соотношение получается. На домашнем ноуте 0.23 и 0.55.

Это еще хорошо если честно.

CS>>Как я уже сказал тут наличествует trade-off:
CS>>Чем более компактный managed heap тем более ты платишь за это CPU циклами (431 GCs у тебя это много).
CS>>Т.е. если оптимизировать GC для этого конкретного случая то нужно увеличивать размер minor heap в разы.
CS>>В этом случае ты приблизишься по скорости к С версии но требуемая память возрастет.

DM>В данном случае да, согласен. Но ведь им все не исчерпывается. А ты распространяешь такие выводы на общий случай.

2:1 это не строгое соотношение — будем считать его неким практически-комфортным показателем при котором быстродействие
является приемлемым.

CS>>Ох ё мое. Ну давай скомпилируй С версию и запусти на своей машине.
CS>>Теперь запусти свою OCaml версию и попробуй отрихтовать размер minor heap так чтобы оно приблизилось по скорости к C. За для просветления.

DM>Попробовал. Добавил в начале
DM>

DM>let c = Gc.get () in
DM>c.Gc.minor_heap_size <- 20000000;
DM>Gc.set c;
DM>

DM>Время работы стало 0.16 с, т.е. в полтора раза быстрее С. Working set практически не изменился. Commit вырос в полтора раза.

Т.е. сумарно имеем 50 + 20 = 70. А если еще сбросить в major heap тот хвост что остался под конец в minor heap то имеем
70 + 20 = 90 mb. Т.е. асимптотически приближаемся к комфортным 2:1.

Здравствуйте, D. Mon, Вы писали:

DM>В общем, мое резюме такое:
DM>1. На вопрос "всегда ли GC требует вдвое и более больше памяти чем C heap" правильный ответ — нет, далеко не всегда (примеры показаны).

Это правильный ответ не на тот вопрос. Правильный вопрос: "всегда ли менеджер памяти, гарантирующий отсутствие фрагментации, требует вдвое и более больше памяти чем без оной гарантии"? И на этот вопрос ответ — да, почти всегда (если исключить некоторый класс языков).

Здравствуйте, c-smile, Вы писали:

CS>На самом деле для класса задач где работа с памятью является основной вопрос
CS>"во сколько раз больше памяти нужно managed системе, чтобы догнать по скорости Си" является правомочным.

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

Здравствуйте, Трурль, Вы писали:

Т>Это правильный ответ не на тот вопрос. Правильный вопрос: "всегда ли менеджер памяти, гарантирующий отсутствие фрагментации, требует вдвое и более больше памяти чем без оной гарантии"?

Ну вот окамловский сборщик компактифицирует и major heap периодически. И памяти ест мало по-умолчанию, как мы видим.

Т> И на этот вопрос ответ — да, почти всегда (если исключить некоторый класс языков).

Предлагаю исключить все, кроме окамла.

Здравствуйте, c-smile, Вы писали:

CS>Жизненный пример это когда ты заранее не знаешь сколько будет строк. Я это имел ввиду.
CS>Т.е. тебе придется делать realloc этого массива. Если например использовать удвоение capacity вектора то без Full GC тебе потребуется major heap в два раза больше чем нужно т.е. как минмум 2000000 + собственно 50 мб для строк. На практике же это число будет именно 2:1 (аллоцированная:полезная).

Рост массива указателей может прибавить несколько мегов, но никак не удвоить потребление (ибо размер массива указателей на фоне размера данных незначителен).

CS>Это если ставить перед собой задачу достижения приемлемого быстродействия.

Оно и без изменения настроек GC приемлемое. Т.е. оверхеда 30-50% обычно вполне достаточно, и даже для обгона Си 100% не потребовалось.

CS>2:1 это не строгое соотношение — будем считать его неким практически-комфортным показателем при котором быстродействие
CS>является приемлемым.

Мне все же кажется, что ты просто специально под это 2:1 подгоняешь, добавляя условий, чтобы оправдать свое использование Cheney.

Здравствуйте, D. Mon, Вы писали:

DM>Ну вот окамловский сборщик компактифицирует и major heap периодически. И памяти ест мало по-умолчанию, как мы видим.

Какая схема используется для компактификации? Как физически это происходит, т.е. сколько памяти надо на эту операцию?

Т>> И на этот вопрос ответ — да, почти всегда (если исключить некоторый класс языков).

DM>Предлагаю исключить все, кроме окамла.

Предлагаю объявить OCaml святым. Тогда можно в него просто верить. Т.е доказательства уже будут не нужны.

Здравствуйте, D. Mon, Вы писали:

DM>Предлагаю исключить все, кроме окамла.

Только предварительно из окамла исключить ref Если в языке нет присваиваний указателей, то все ссылки направлены в одну сторону и можно копировать в ту же кучу.