Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?

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

H_C>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?

Если такое пришло в голову, то проблема, скорее всего, не в размере стека.

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

H_C>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?

Можно.

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

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

H_C>>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?
I>Можно.
это как? или вы по умолчанию подразумеваете, что либо компилятор, либо программист заюзают стек и выюзают его? к программисту у меня вопросов нет -- заменить malloc на локальные переменные (не факт, что будет быстрее, т.к. при выделении массива на стеке компилятор "пробегается" по всем страницам, т.к. стек растет постранично по мере использования, а при выделении страниц происходит их зачистка и на уровне оси выделение стека занимает даже больше операций, чем выделение в куче, ибо стек это часть системной кучи со сторожевой страницей).

если сравнивать локальные переменные с кучей времени исполнения, то стек выигрывает за счет быстрого выдления/освобождения. если сравнивать стек с самопальным аллокатором, реализующим автоматические переменные через указатель на вершину выделенной памяти, то свой аллокатор выигрывает за счет того, что ему не нужно перемещать сторежевую страницу. так же свой аллокатор упрощает проверки успешности выделения памяти. а как узнать сколько стека осталось? только через винапи, да и то с оговорками. исключение об исчерпании стека бросается раньше исчерпания, ибо в противном случае было бы невозможно использовать стек в обработчике. так же неизвестно сколько памяти выделяет компилятор на стеке при вызове функции. это можно только оценить. с увеличением числа вызовов погрешность будет неуклонно нарастать и в какой-то момент расчеты потеряют смысл.

вы уверены, что использование стека с оверхидом сторожевой страницы и черт знает какими проверками доступности памяти обгонит кучу? кроме того, ошибку выделения памяти под первичный стек вообще никак не обработать. следовательно, нам нужно создать хотя бы один дополнительный поток, что резко все усложняет и запутывает. а многопоточный RTL уж точно не быстрее однопоточного.

при этом данные рассуждения относятся исключительно к низкому уровню (си).

Что такое сторожевая страница?

Т.е. страницы стека разных приложений организованы как фрагменты памяти на куче, и ОС переодически делает их дефрагментацию?

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

H_C>Что такое сторожевая страница?
page guard. находится на вершине стека. при обращении к ней генерируется исключение. ось его ловит, выделяет память и перемещает страницу наверх. если выделить на стеке больше 4х кб и обратится к той ячейке массива, что лежит за сторожевой страницей -- будет исключение доступа. если вы посмотрите в код функции, то увидите, что компилятор вставил туда специальную процедуру, которая последовательно обращается ко всем страницам, занимаемы локальными переменными, при каждом входе в функцию. после выхода из функции указатель стека опускается вниз, но сторожевая страница _не_ опускается. при повторном вызове "пробегать" по встем страницам уже нет необходимости, но компилятор об этом не знает. в результате мы имеем оверхид. не то, чтобы сильно существенный, но все-таки оверхид. при условии, конечно, что мы изобретем и тут же запатентуем способ как узнать сколько осталось памяти на стеке. стека у нас порядка мегабайт (зависит от оси, но непринципиально). кучи у нас порядка полутора гигабайт (завист от оси, но _сильно_ больше, чем стека). стек выюзать легко, кучу -- трудно (разве, что у нас утечки или фрагментация). только отсутствие проверки успешности выделения памяти на куче -- плохая практика программирования, а проверка успешности выделения на стеке -- и кто это делает?

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

H_C>Т.е. страницы стека разных приложений организованы как фрагменты памяти на куче, и ОС переодически делает их дефрагментацию?
нет. под стек потока ось резервирует адресное пространство, а память выделяет по мере надобности. стек принадлежит системной куче и вы даже можете узнать атрибуты блока, включая его размер. конечно, через АПИ, т.е. системно-зависимо. и размер оставшегося стека вам ничего не даст, т.к. исключение будет сгенерировано до его исчерпания. ось оставит сколько-то килобайт для обработчика, но сколько точно -- она вам не скажет (конечно, можно установить это значение экспериментально, но оно не документрировано и не факт, что не изменится в любой момент). да и компилятор накидывает на каждый стековый фрейм свои служебные расходы, о которых он молчит и выяснить их можно только заглянув в ассемблерный листинг, но это ненадежно, т.к. зависит и от версии компилятора и от ключей компиляции.

по этой причине рекурсия -- зло и рулетка.

> указатель стека опускается вниз, но сторожевая страница _не_ опускается.

Что-то не ясно. Если с помощью этой страницы ОС проверяет фактически заюзаные страницы стэка, то как она увеличивая их количество не будет менять адресное пространство сторожевой страницы?

Компилятор сам вставляет логику навигации между стэковыми фреймами?

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

>> указатель стека опускается вниз, но сторожевая страница _не_ опускается.

H_C>Что-то не ясно. Если с помощью этой страницы ОС проверяет фактически заюзаные страницы стэка, то как она увеличивая их количество не будет менять адресное пространство сторожевой страницы?

в msdn на эту тему есть статьи. я не пойму, что именно вам не ясно. при создании потока размер стека задется сразу и резервируется в адресном пространстве, которого на 32 битах 4 гб из них половину занимает ось, а половину -- длл, стеки потоков и куча (собственно, и длл, и стеки потоков -- все это куча). зарезервированная память еще не означает выделенная. это видно отладчиком. а выделяется она при обращении к сторожевой странице. сторожевая страница двигается в одном направлении. выделенная под стек память обратно никогда не освобождается. она так и остается закоммиченной, даже если указатель на вершину стека опустился вниз. вообще, это сложный механизм, но у мс он описан.

H_C>Компилятор сам вставляет логику навигации между стэковыми фреймами?
что такое навигация между стековыми фреймами я не знаю. компилятор лишь гарантирует возможность неупорядоченного доступа ко всем локальным переменным. для этого он читает все странцы, вынуждая сторожевную страницу перемещаться вверх, а если она уже наверху, то компилятор отработает этот цикл вхолостую. в зависимости от ключей компиляции это может быть рантаймовый вызов или заинлайненный код. оптимизатор даже может его выбросить, если увидит, что он не нужен, но без гарантий.

Здравствуйте, Hard_Club, Вы писали:
>> указатель стека опускается вниз, но сторожевая страница _не_ опускается.
H_C>Что-то не ясно. Если с помощью этой страницы ОС проверяет фактически заюзаные страницы стэка, то как она увеличивая их количество не будет менять адресное пространство сторожевой страницы?
Мыщъх загрузил вас тех. деталями Но для начала, ИМХО, вам стоит ознакомится с базовыми концепциями: Адресное пространство, Виртуальная память, Страничная память

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

>> указатель стека опускается вниз, но сторожевая страница _не_ опускается.

H_C>Что-то не ясно. Если с помощью этой страницы ОС проверяет фактически заюзаные страницы стэка, то как она увеличивая их количество не будет менять адресное пространство сторожевой страницы?

Сторожевая страница двигается когда стек растёт, собтсвенно, для того она и нужна, что бы узнать момент, когда нужно подкоммитить еще страницу. И стоит на месте когда стект сокращается, это значит что страницы стек не отдаёт.

Здравствуйте, мыщъх, Вы писали:

H_C>>>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?
I>>Можно.
М>это как?

Если, скажем, стека дать целый вагон, то во многих рекурсивных алгоритмах получится просто адский перформанс, т.к. динамическая память сосёт не практически нагибаясь.

М>вы уверены, что использование стека с оверхидом сторожевой страницы и черт знает какими проверками доступности памяти обгонит кучу?

Оверхед можно пофиксить, например вынудив при старте закомитать весь объём стека.

I>Оверхед можно пофиксить, например вынудив при старте закомитать весь объём стека.

Так он и так по идее небольшой: одно прерывание на каждую новую страницу.

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

H_C>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?
В Java можно. Правда именно на "перфонанс" оно влияет скорее косвенно, чем напрямую.

B>В Java можно

Каким образом?

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

B>>В Java можно
H_C>Каким образом?
На каждый поток выделяется фиксированое количество памяти под стэк. В многопоточных системах, размер этого стэка существенно влияет на потребление памяти.

B>На каждый поток выделяется фиксированое количество памяти под стэк. В многопоточных системах, размер этого стэка существенно влияет на потребление памяти.

Тогда возникает вопрос как найти оптимальный размер стека?

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

H_C>Тогда возникает вопрос как найти оптимальный размер стека?
Проанализировать потребление памяти и количество потоков в системе.

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

I>Здравствуйте, мыщъх, Вы писали:

H_C>>>>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?
I>>>Можно.
М>>это как?
I>Если, скажем, стека дать целый вагон, то во многих рекурсивных алгоритмах получится просто адский перформанс, т.к. динамическая память сосёт не практически нагибаясь.
Отличное игнорирование всех распинаний мыщьха
Что-то мне подсказывает, что вопрос был о возможности тюнинга без переписываения приложения.

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

I>>Если, скажем, стека дать целый вагон, то во многих рекурсивных алгоритмах получится просто адский перформанс, т.к. динамическая память сосёт не практически нагибаясь.
SK>Отличное игнорирование всех распинаний мыщьха
SK>Что-то мне подсказывает, что вопрос был о возможности тюнинга без переписываения приложения.

Ну я не телепат

H_C>>>>>Можно ли тюнить перфонанс приложения с помощью изменения размера стэка?
I>>>>Можно.
М>>>это как?
I>>Если, скажем, стека дать целый вагон, то во многих рекурсивных алгоритмах получится просто адский перформанс, т.к. динамическая память сосёт не практически нагибаясь.
SK>Отличное игнорирование всех распинаний мыщьха
SK>Что-то мне подсказывает, что вопрос был о возможности тюнинга без переписываения приложения.

I>>Если, скажем, стека дать целый вагон, то во многих рекурсивных алгоритмах получится просто адский перформанс, т.к. динамическая память сосёт не практически нагибаясь.
Помоему это размышления из серии: Пистолет можно чистить заряженным, главно резких движений не делать.