Forth http://www.fforum.winglion.ru/ |
|
о использовании памяти http://www.fforum.winglion.ru/viewtopic.php?f=25&t=2714 |
Страница 1 из 1 |
Автор: | dynamic-wind [ Ср мар 02, 2011 18:40 ] |
Заголовок сообщения: | о использовании памяти |
Это плата за возможность гибкого использования обоих стеков. А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь? Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW? |
Автор: | mOleg [ Ср мар 02, 2011 19:03 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
dynamic-wind писал(а): А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь? HeapAlloc из kernel32.dll не знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее. dynamic-wind писал(а): Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW? есть механизм ON-ERROR - EXIT-ERROR, который позволяет решать аналогичные задачи. |
Автор: | chess [ Чт мар 03, 2011 17:38 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
mOleg писал(а): HeapAlloc из kernel32.dllне знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее. Все относительно. На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти. При больших объемах памяти разницы между быстродействием, например, операций FREE и RESIZE нет. |
Автор: | chess [ Пт мар 04, 2011 17:25 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
chess писал(а): На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти. Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро. |
Автор: | mOleg [ Пт мар 04, 2011 17:56 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
chess писал(а): Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро. вряд ли. Дело ведь еще и в том, что память РЕАЛЬНО выделяется только в момент записи в нее, причем, происходит это постранично (на сколько я знаю). Кроме того, перед этим память может освобождаться(выкидываться содержимое в своп) и кроме того обнуляться (борьба за конфиденциальность). Зачем делать работу за операционную систему, если ее всеравно будет выполнять ОС? Для ускорения процесса выделения можно уже использованную память связывать хоть в односвязный, хоть в хешированный, хоть в бинарный список (сортируя, так сказать по объему блока) и потому при необходимости быстро отдавать адрес из этого списка. Хотя и это не гарантирует от того, что эта память не окажется в свопе... |
Автор: | chess [ Пт мар 04, 2011 21:53 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
mOleg писал(а): вряд ли. Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти. Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Собственно процедуры работы с такой памятью аналогичные только по смыслу процедурам работы с динамической памятью, которые и поддерживает ОС абсолютно отличаются по реализации и сводятся только к переписыванию значения указателя на первый свободный байт стат. памяти(ну может быть еще можно ввести обнуление ячеек). |
Автор: | Hishnik [ Пт мар 04, 2011 23:13 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
chess писал(а): Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти. Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая. chess писал(а): Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Кварк выделяет 256 Мб статически. В диспетчере задач виден существенно меньший размер занимаемой этим процессом памяти, который увеличивается блоками, в процессе действительного доступа к каким-то адресам. Память выделяется не в физическом адресном пространстве, а в логическом, а дальше работает механизм трансляции страниц. |
Автор: | chess [ Сб мар 05, 2011 17:29 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
Хищник писал(а): Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая. Это сокращения и только. Конечно есть ОЗУ и память только в этом ОЗУ и нигде более, но есть ОС, которая, да, работает с памятью по своим правилам, которые не перепрыгнуть в рамках приложения этой ОС, которым и является Форт. Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической. |
Автор: | dynamic-wind [ Сб мар 05, 2011 19:28 ] |
Заголовок сообщения: | Re: вариант реализации watchdog механизма |
chess писал(а): Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической. Неудивительно Ведь работа со динамически выделяемой памятью требует хоть одну команду потратить на получение указателя, а дальше--всё как со статической. Динамическое выделение может быть эффективнее статичекого только тогда, когда объект создается в одном месте программы на время, а потом он не нужен, зато нужен другой объект в другом месте. Тогда может быть экономия от уменьшения рабочего набора, от повторных обращений к закешированной памяти и т.п. Ели эта экономия амортизирует затраты на динамическое управление--тогда да. |
Страница 1 из 1 | Часовой пояс: UTC + 3 часа [ Летнее время ] |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |