Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
chess писал(а): Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической. Неудивительно Ведь работа со динамически выделяемой памятью требует хоть одну команду потратить на получение указателя, а дальше--всё как со статической. Динамическое выделение может быть эффективнее статичекого только тогда, когда объект создается в одном месте программы на время, а потом он не нужен, зато нужен другой объект в другом месте. Тогда может быть экономия от уменьшения рабочего набора, от повторных обращений к закешированной памяти и т.п. Ели эта экономия амортизирует затраты на динамическое управление--тогда да.
[quote="chess"]Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической.[/quote] Неудивительно :D Ведь работа со динамически выделяемой памятью требует хоть одну команду потратить на получение указателя, а дальше--всё как со статической. :arrow: :arrow: :arrow: Динамическое выделение может быть эффективнее статичекого только тогда, когда объект создается в одном месте программы на время, а потом он не нужен, зато нужен другой объект в другом месте. Тогда может быть экономия от уменьшения рабочего набора, от повторных обращений к закешированной памяти и т.п. Ели эта экономия амортизирует затраты на динамическое управление--тогда да.
|
|
|
|
Добавлено: Сб мар 05, 2011 19:28 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
Хищник писал(а): Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая. Это сокращения и только. Конечно есть ОЗУ и память только в этом ОЗУ и нигде более, но есть ОС, которая, да, работает с памятью по своим правилам, которые не перепрыгнуть в рамках приложения этой ОС, которым и является Форт. Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической.
[quote="Хищник"]Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая.[/quote] Это сокращения и только.
Конечно есть ОЗУ и память только в этом ОЗУ и нигде более, но есть ОС, которая, да, работает с памятью по своим правилам, которые не перепрыгнуть в рамках приложения этой ОС, которым и является Форт. Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической.
|
|
|
|
Добавлено: Сб мар 05, 2011 17:29 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
chess писал(а): Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти. Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая. chess писал(а): Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Кварк выделяет 256 Мб статически. В диспетчере задач виден существенно меньший размер занимаемой этим процессом памяти, который увеличивается блоками, в процессе действительного доступа к каким-то адресам. Память выделяется не в физическом адресном пространстве, а в логическом, а дальше работает механизм трансляции страниц.
[quote="chess"]Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти.[/quote] Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая. [quote="chess"]Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки.[/quote] Кварк выделяет 256 Мб статически. В диспетчере задач виден существенно меньший размер занимаемой этим процессом памяти, который увеличивается блоками, в процессе действительного доступа к каким-то адресам. Память выделяется не в физическом адресном пространстве, а в логическом, а дальше работает механизм трансляции страниц.
|
|
|
|
Добавлено: Пт мар 04, 2011 23:13 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
mOleg писал(а): вряд ли. Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти. Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Собственно процедуры работы с такой памятью аналогичные только по смыслу процедурам работы с динамической памятью, которые и поддерживает ОС абсолютно отличаются по реализации и сводятся только к переписыванию значения указателя на первый свободный байт стат. памяти(ну может быть еще можно ввести обнуление ячеек).
[quote="mOleg"]вряд ли.[/quote] Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти. Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Собственно процедуры работы с такой памятью [b]аналогичные только по смыслу [/b]процедурам работы с динамической памятью, которые и поддерживает ОС абсолютно отличаются по реализации и сводятся только к переписыванию значения указателя на первый свободный байт стат. памяти(ну может быть еще можно ввести обнуление ячеек).
|
|
|
|
Добавлено: Пт мар 04, 2011 21:53 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
chess писал(а): Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро. вряд ли. Дело ведь еще и в том, что память РЕАЛЬНО выделяется только в момент записи в нее, причем, происходит это постранично (на сколько я знаю). Кроме того, перед этим память может освобождаться(выкидываться содержимое в своп) и кроме того обнуляться (борьба за конфиденциальность). Зачем делать работу за операционную систему, если ее всеравно будет выполнять ОС? Для ускорения процесса выделения можно уже использованную память связывать хоть в односвязный, хоть в хешированный, хоть в бинарный список (сортируя, так сказать по объему блока) и потому при необходимости быстро отдавать адрес из этого списка. Хотя и это не гарантирует от того, что эта память не окажется в свопе...
[quote="chess"]Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро.[/quote] вряд ли. Дело ведь еще и в том, что память РЕАЛЬНО выделяется только в момент записи в нее, причем, происходит это постранично (на сколько я знаю). Кроме того, перед этим память может освобождаться(выкидываться содержимое в своп) и кроме того обнуляться (борьба за конфиденциальность). Зачем делать работу за операционную систему, если ее всеравно будет выполнять ОС? Для ускорения процесса выделения можно уже использованную память связывать хоть в односвязный, хоть в хешированный, хоть в бинарный список (сортируя, так сказать по объему блока) и потому при необходимости быстро отдавать адрес из этого списка. Хотя и это не гарантирует от того, что эта память не окажется в свопе...
|
|
|
|
Добавлено: Пт мар 04, 2011 17:56 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
chess писал(а): На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти. Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро.
[quote="chess"]На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти.[/quote] Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро.
|
|
|
|
Добавлено: Пт мар 04, 2011 17:25 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
mOleg писал(а): HeapAlloc из kernel32.dllне знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее. Все относительно. На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти. При больших объемах памяти разницы между быстродействием, например, операций FREE и RESIZE нет.
[quote="mOleg"]HeapAlloc из kernel32.dllне знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее.[/quote] Все относительно. На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти. При больших объемах памяти разницы между быстродействием, например, операций FREE и RESIZE нет.
|
|
|
|
Добавлено: Чт мар 03, 2011 17:38 |
|
|
|
|
|
Заголовок сообщения: |
Re: вариант реализации watchdog механизма |
|
|
dynamic-wind писал(а): А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь? HeapAlloc из kernel32.dll не знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее. dynamic-wind писал(а): Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW? есть механизм ON-ERROR - EXIT-ERROR, который позволяет решать аналогичные задачи.
[quote="dynamic-wind"]А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь?[/quote] HeapAlloc из kernel32.dll не знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее.
[quote="dynamic-wind"]Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW?[/quote] есть механизм ON-ERROR - EXIT-ERROR, который позволяет решать аналогичные задачи.
|
|
|
|
Добавлено: Ср мар 02, 2011 19:03 |
|
|
|
|
|
Заголовок сообщения: |
о использовании памяти |
|
|
Это плата за возможность гибкого использования обоих стеков. А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь? Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW?
Это плата за возможность гибкого использования обоих стеков. :twisted: А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь? Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW?
|
|
|
|
Добавлено: Ср мар 02, 2011 18:40 |
|
|
|
|