Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, grapes, Вы писали:
G>>пере-х стек перепелнила — такого еще не случалось (на моем веку) V>Счастливый! (Или молодой? ) V>Переполнение стека — серезная проблема, она существует с самого начала вычислительной техники, ибо стек — это базовая форма хранения данных. Используется кроме всего прочего, из-за огромной скорочти выделения памяти (фактически, она уже выделена, просто указатель сдвигается). Естественно, она виртуальная, других и не бывает на самом деле, просто ее явно обычно не выделяют, поэтому так говорить не принято.
На платформах IBM PC обычно (т.е. в Win) весь стек нити сразу оказывается в виртуальном адресном пространстве процесса. Причем старшая по адресу незаполненная страница памяти имеет флаг PAGE_GUARD, а все остальные незаполненные страницы так вообще процессу не доступны (Access violation), физическая память для них еще не выделена. Когда происходит первое обращение к этой старшей странице, вызывается обработчик, который делает эту страницу доступной, выделяет следующую страницу с младшим адресом и на нее ставит флаг PAGE_GUARD. Этот обработчик можно даже перепрограммировать, но я не пробовал.
Интересно поисследовать, каковы потери в быстродействии из-за этого обработчика.
Интересно, что memcpy заполняет память от младших адресов к старшим. Но вот при использовании ее в конструкторе копирования больших (в несколько страниц) объектов на стеке все работает без Access violation. То есть, прежде чем такой конструктор вызовется, все необходимые страницы памяти под локальные переменные уже будут созданы! Это тоже потеря быстродействия?
Здравствуйте, Валерий Б., Вы писали:
В>>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб ВБ>И что? Не умею я смотреть, неохота вникать в ассемблер.
А там как раз цикл организуется, который последовательно по 4кб от стэка отъедает.
Здравствуйте, Валерий Б., Вы писали:
В>>А там как раз цикл организуется, который последовательно по 4кб от стэка отъедает. ВБ>Мат-перемат. А разве APIшными функциями ему не быстрее их всех сразу отъесть?
Быстрее. Именно это _chkstk и делает.
Если программа использует RTL из ntdll.dll (у меня многие это делают) и описывается локальная структура больше 4K — эта функция вызывается, именно она все за раз и отъедает, без циклов.
Когда компилер с++ вызывает ф-цию, он резервирует ей стек:
sub esp, 0x44
после вызова он возвращает указатель обратно.
Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
Здравствуйте, Валерий Б., Вы писали:
ВБ>Мат-перемат. А разве APIшными функциями ему не быстрее их всех сразу отъесть?
Я тоже задавался этим вопросом Было это давно, и человек с которым я дискутировал как-то это обосновал (а может просто запарил Цикл с отъеданием по 4кб организует борландовский компилятор. С микрософтовским все хитрее. Как уже здесь говорилось он вызывает свою функцию, и кроме того, там в опциях компиляции можно указать размер этих "блоков".
ВБ>А потом вызываются конструкторы в которых уже можно обращаться к любым членам объекта, т.к. они уже в доступной памяти. ВБ>А в С тоже всегда цикл вызывается? Там ведь уже и компилятору необязательно предварительно странички отъедать, если он сообразит, когда какой объект потребуется, то может соптимизирует это дело.
Здравствуйте, grapes, Вы писали:
G>Когда компилер с++ вызывает ф-цию, он резервирует ей стек: G>sub esp, 0x44 G>после вызова он возвращает указатель обратно. G>Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
Здравствуйте, mik1, Вы писали:
G>>Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
M>ИМХО, объем передаваемых переменных + объем локальных переменных.
То есть он считает число локальных переменных в вызываемой ф-ции? Зачем? Они же не в стеке будут размещаться!
M>>>ИМХО, объем передаваемых переменных + объем локальных переменных.
G>>То есть он считает число локальных переменных в вызываемой ф-ции? Зачем? Они же не в стеке будут размещаться!
M>А где?
Здравствуйте, grapes, Вы писали:
G>>>То есть он считает число локальных переменных в вызываемой ф-ции? Зачем? Они же не в стеке будут размещаться!
M>>А где?
G>Разве не в обычной памяти?
Здравствуйте, grapes, Вы писали:
G>Когда компилер с++ вызывает ф-цию, он резервирует ей стек: G>sub esp, 0x44 G>после вызова он возвращает указатель обратно. G>Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
И еще — если бы каждая вызываемая ф-ция размещала бы свои локальные переменные в стеке, то он бы просто лопнул — вот когда происходит глубокая рекурсия (ф-я сама себя вызывает) — это и происходит, а чтобы просто ф-ция с большим к-вом лок. пере-х стек перепелнила — такого еще не случалось (на моем веку)
Здравствуйте, grapes, Вы писали:
G>пере-х стек перепелнила — такого еще не случалось (на моем веку)
Счастливый! (Или молодой? )
Переполнение стека — серезная проблема, она существует с самого начала вычислительной техники, ибо стек — это базовая форма хранения данных. Используется кроме всего прочего, из-за огромной скорочти выделения памяти (фактически, она уже выделена, просто указатель сдвигается). Естественно, она виртуальная, других и не бывает на самом деле, просто ее явно обычно не выделяют, поэтому так говорить не принято.
Здравствуйте, grapes, Вы писали:
G>И еще — если бы каждая вызываемая ф-ция размещала бы свои локальные переменные в стеке, то он бы просто лопнул — вот когда происходит глубокая рекурсия (ф-я сама себя вызывает) — это и происходит, а чтобы просто ф-ция с большим к-вом лок. пере-х стек перепелнила — такого еще не случалось (на моем веку)
А попробуй поставить стек 4kb и создать локальный массив элементов так из 8000.
Здравствуйте, grapes, Вы писали:
G>>>Разве не в обычной памяти? MAG>>А что такое "обычная память"? MAG>>Типа "обычного" стирального порошка?
G>Динамически выделяемая
А какого GUI там переменные должны размещаться? Попробуй каждый раз при вызове функции для всех переменных выделять память используя new, а в конце прибивать delete'ом и посмотри быстродействие.
Здравствуйте, grapes, Вы писали:
G>Когда компилер с++ вызывает ф-цию, он резервирует ей стек: G>sub esp, 0x44 G>после вызова он возвращает указатель обратно. G>Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
Здравствуйте, grapes, Вы писали:
G>Когда компилер с++ вызывает ф-цию, он резервирует ей стек: G>sub esp, 0x44 G>после вызова он возвращает указатель обратно. G>Вопрос: как он определяет то, на сколько надо сдвинуть стек (почему именно 44?)
если я не ошибабсь, компилятор оставляет специальное пространство для проверки, нет ли нарушей границ стека, причем инициализирует специальными символами.
Здравствуйте, ilnar, Вы писали:
I>если я не ошибабсь, компилятор оставляет специальное пространство для проверки, нет ли нарушей границ стека, причем инициализирует специальными символами.
Абсолютно верно.
Стек он забивает 0xCC, а после вызова ф-ции смещает указатель стека назад и смотрит, равен ли он тому, что было до вызова
Здравствуйте, Валерий Б., Вы писали:
ВБ>а все остальные незаполненные страницы так вообще процессу не доступны (Access violation), физическая память для них еще не выделена.
Здесь обычно используется термин "передача", а не "выделение".
ВБ>Этот обработчик можно даже перепрограммировать, но я не пробовал.
Примеры этого есть.
ВБ>Интересно поисследовать, каковы потери в быстродействии из-за этого обработчика.
Никто не запрещает сразу "закоммитить" весь стек.
В этом случае, кстати, последняя страница сторожевой не будет.
Здравствуйте, Валерий Б., Вы писали:
>использовании ее в конструкторе копирования больших (в несколько страниц) объектов на стеке все работает без Access violation. То есть, прежде чем такой конструктор вызовется, все необходимые страницы памяти под локальные переменные уже будут созданы! Это тоже потеря быстродействия?
А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб
А после этого можно будет поспорить по поводу того, что всегда ли "динамическое" выделение памяти будет медленне "стэкового"
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, grapes, Вы писали:
G>>Стек он забивает 0xCC V>В Debug-версии.
И проверки тоже в Debug версии.
Причем MSVC++ 6 в Дебаг-версии всегда восстанавливает стек при выходе из функции, поэтому если ты где-то напортачил внутри — то этого можешь даже и не заметить, а в релизе обязательно вылетит — у меня так было.
Здравствуйте, grapes, Вы писали:
G>И еще — если бы каждая вызываемая ф-ция размещала бы свои локальные переменные в стеке, то он бы просто лопнул — вот когда происходит глубокая рекурсия (ф-я сама себя вызывает) — это и происходит, а чтобы просто ф-ция с большим к-вом лок. пере-х стек перепелнила — такого еще не случалось (на моем веку)
Тебе вопрос, если бы даже место под локальные переменные выделялось в динамической памяти, где должны храниться указатели на эти пременные?
Здравствуйте, Владик, Вы писали:
В>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб
И что? Не умею я смотреть, неохота вникать в ассемблер. В>А после этого можно будет поспорить по поводу того, что всегда ли "динамическое" выделение памяти будет медленне "стэкового"
Так я и не спорю. Хотелось бы выяснить велики ли эти потери, да никак руки не доходят.
Здравствуйте, Валерий Б., Вы писали:
В>>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб ВБ>И что? Не умею я смотреть, неохота вникать в ассемблер.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Валерий Б., Вы писали:
В>>>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб ВБ>>И что? Не умею я смотреть, неохота вникать в ассемблер.
V>Может использоваться _chkstk.
Здравствуйте, Владик, Вы писали:
В>Здравствуйте, Валерий Б., Вы писали:
В>>>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб ВБ>>И что? Не умею я смотреть, неохота вникать в ассемблер.
В>А там как раз цикл организуется, который последовательно по 4кб от стэка отъедает.
Мат-перемат. А разве APIшными функциями ему не быстрее их всех сразу отъесть?
А потом вызываются конструкторы в которых уже можно обращаться к любым членам объекта, т.к. они уже в доступной памяти.
А в С тоже всегда цикл вызывается? Там ведь уже и компилятору необязательно предварительно странички отъедать, если он сообразит, когда какой объект потребуется, то может соптимизирует это дело.
Здравствуйте, Валерий Б., Вы писали:
ВБ>Здравствуйте, Владик, Вы писали:
В>>Здравствуйте, Валерий Б., Вы писали:
В>>А там как раз цикл организуется, который последовательно по 4кб от стэка отъедает. ВБ>Мат-перемат. А разве APIшными функциями ему не быстрее их всех сразу отъесть?
При размере стека потока в 1 Мб такое передвижение "шажками" за время его жизни произойдет не более, чем 256 раз. Не страшно.
Здравствуйте, Znow, Вы писали:
Z>При размере стека потока в 1 Мб такое передвижение "шажками" за время его жизни произойдет не более, чем 256 раз.
Да? А обосновать?
Или по вашему стек только расти может?
Здравствуйте, vasketsov, Вы писали:
Z>>При размере стека потока в 1 Мб такое передвижение "шажками" за время его жизни произойдет не более чем 256 раз. V>Да? А обосновать? V>Или по вашему стек только расти может?
Даже если вообразить себе тупой компилятор, в котором генерируется код, отъедающий от стека не более чем по одной странице за присест с тем, чтобы не проскочить охранную страницу и обеспечить корректную передачу страничной памяти в зарезервированное под стек виртуальное адресное пространство, — даже тогда трудно вообразить такой идиотизм как возврат системе этой самой страничной памяти ранее конца жизни потока. Если же и такое бывает (хотя до такого терроризма додуматься трудно), то, конечно, приведенное выше мое утверждение неверно.
Т. к. обычный размер зарезервированного под стек ВАП в 1 МБ на Интеловской архитектуре равен 256 страницам, то такая передача произойдет не более чем 256 раз. Если она произойдет в 257 раз, то это уже будет переполнение стека.
Здравствуйте, Znow, Вы писали:
Z>Если же и такое бывает (хотя до такого терроризма додуматься трудно), то, конечно, приведенное выше мое утверждение неверно.
Хорошо, пусть есть функция, в которой выделяется в стеке 100-килобайтная структура.
Я могу эту функцию вызвать 10 раз — и все, приплыли?
Здравствуйте, vasketsov, Вы писали:
Z>>Если же и такое бывает (хотя до такого терроризма додуматься трудно), то, конечно, приведенное выше мое утверждение неверно.
V>Хорошо, пусть есть функция, в которой выделяется в стеке 100-килобайтная структура. V>Я могу эту функцию вызвать 10 раз — и все, приплыли?
Если там 10 уровней рекурсии, — то да, приплыли.
Если 10 раз последовательно, то, ясное дело, передача страничной памяти, если и будет выполняться, то лишь в первый раз. В остальное время охранная страница будет уже отодвинута достаточно далеко, чтобы не быть достигнутой. Соответственно, указатель вершины стека будет бугать туда-сюда в рамках пространства стека, под которое страничная память уже передана.
Здравствуйте, Znow, Вы писали:
Z>Взаимное недопонимание устранено или я в чем-то заблуждаюсь?
Да нет, видимо, о разных вещах говорим.
Я утверждал, что текущее положение в стеке откатывается, ты — что вершина не откатывается.
И то и другое одновременно, очевидно, может реализовываться.
Правда, то что память не освобождается — ничуть не очевидно.
Зато дизассемблирование _chkstk дает много поучительной имформации.
Здравствуйте, Znow, Вы писали:
Z>Я такое говорил? Где?
Пара постов вверх.
Опять же, под вершиной РАЗНОЕ может быть понято, видишь как легко флейм провоцировать?
Большинство считает, что вершина стека — это его текущее положение, исторически так принято.
В данном случае реально вершина болтается где-то посредине между вершиной в смысле переданой памяти и базового адреса стека.
Вот и все, а ты испугался.
Здравствуйте, Владик, Вы писали:
В>Здравствуйте, Валерий Б., Вы писали:
>>использовании ее в конструкторе копирования больших (в несколько страниц) объектов на стеке все работает без Access violation. То есть, прежде чем такой конструктор вызовется, все необходимые страницы памяти под локальные переменные уже будут созданы! Это тоже потеря быстродействия?
В>А ты (ради интереса) посмотри, что компилятор делает, когда размер локальных переменных переваливает через 4кб В>А после этого можно будет поспорить по поводу того, что всегда ли "динамическое" выделение памяти будет медленне "стэкового"
Это верно, при больщой глубине появляются тормоза.
Я это встретил при разработке парсеров. Избавился от рекурсии и получил свои ~ 20 метров в сек.
Нужно стараться решать проблему рекурсии переработкой алгоритма, и держать по меньше
больших обьектов в стэке.
Здравствуйте, Stanislav Kondratiev, Вы писали:
SK>Здравствуйте, vasketsov, Вы писали:
V>>Здравствуйте, grapes, Вы писали:
G>>>Стек он забивает 0xCC V>>В Debug-версии. SK>И проверки тоже в Debug версии. SK>Причем MSVC++ 6 в Дебаг-версии всегда восстанавливает стек при выходе из функции, поэтому если ты где-то напортачил внутри — то этого можешь даже и не заметить, а в релизе обязательно вылетит — у меня так было.
У теня тоже. Это легко достигнуть подсовывая в MESSAGE MAP MFC функцию не правильного прототипа.
в дебаге работает, в релизе ...
)
Было это давно, и человек с которым я дискутировал как-то это обосновал (а может просто запарил 
Если не сложно, поясните.
