Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 12:17

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Ответить
Имя пользователя:
Заголовок:
Текст сообщения:
Введите текст вашего сообщения. Длина сообщения в символах не более: 60000

Размер шрифта:
Цвет шрифта
Настройки:
BBCode ВКЛЮЧЕН
[img] ВЫКЛЮЧЕН
[flash] ВЫКЛЮЧЕН
[url] ВКЛЮЧЕН
Смайлики ВЫКЛЮЧЕНЫ
Отключить в этом сообщении BBCode
Не преобразовывать адреса URL в ссылки
Вопрос
Теперь гостю придется вводить здесь пароль. Не от своей учетной записи, а ПАРОЛЬ ДЛЯ ГОСТЯ, получить который можно после регистрации на форуме через ЛС.:
Этот вопрос предназначен для выявления и предотвращения автоматических регистраций.
   

Обзор темы - о использовании памяти
Автор Сообщение
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
chess писал(а):
Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической.

Неудивительно :D Ведь работа со динамически выделяемой памятью требует хоть одну команду потратить на получение указателя, а дальше--всё как со статической. :arrow: :arrow: :arrow:
Динамическое выделение может быть эффективнее статичекого только тогда, когда объект создается в одном месте программы на время, а потом он не нужен, зато нужен другой объект в другом месте. Тогда может быть экономия от уменьшения рабочего набора, от повторных обращений к закешированной памяти и т.п. Ели эта экономия амортизирует затраты на динамическое управление--тогда да.
Сообщение Добавлено: Сб мар 05, 2011 19:28
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
Хищник писал(а):
Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая.

Это сокращения и только.

Конечно есть ОЗУ и память только в этом ОЗУ и нигде более, но есть ОС, которая, да, работает
с памятью по своим правилам, которые не перепрыгнуть в рамках приложения этой ОС, которым и является Форт. Но тем не менее работа со стат. памятью гораздо шустрее чем с динамической.
Сообщение Добавлено: Сб мар 05, 2011 17:29
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
chess писал(а):
Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти.

Только не динамическая и статическая (это разновидности микросхем), а динамически выделяемая и статически выделяемая.
chess писал(а):
Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки.

Кварк выделяет 256 Мб статически. В диспетчере задач виден существенно меньший размер занимаемой этим процессом памяти, который увеличивается блоками, в процессе действительного доступа к каким-то адресам. Память выделяется не в физическом адресном пространстве, а в логическом, а дальше работает механизм трансляции страниц.
Сообщение Добавлено: Пт мар 04, 2011 23:13
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
mOleg писал(а):
вряд ли.

Все что вы здесь написали относится к динамической памяти, я же писал о статической памяти.
Статическая память выделяется еще до начала работы программы, на стадии компиляции и сборки. Собственно процедуры работы с такой памятью аналогичные только по смыслу процедурам работы с динамической памятью, которые и поддерживает ОС абсолютно отличаются по реализации и сводятся только к переписыванию значения указателя на первый свободный байт стат. памяти(ну может быть еще можно ввести обнуление ячеек).
Сообщение Добавлено: Пт мар 04, 2011 21:53
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
chess писал(а):
Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро.

вряд ли.
Дело ведь еще и в том, что память РЕАЛЬНО выделяется только в момент записи в нее, причем, происходит это постранично (на сколько я знаю). Кроме того, перед этим память может освобождаться(выкидываться содержимое в своп) и кроме того обнуляться (борьба за конфиденциальность). Зачем делать работу за операционную систему, если ее всеравно будет выполнять ОС?
Для ускорения процесса выделения можно уже использованную память связывать хоть в односвязный, хоть в хешированный, хоть в бинарный список (сортируя, так сказать по объему блока) и потому при необходимости быстро отдавать адрес из этого списка. Хотя и это не гарантирует от того, что эта память не окажется в свопе...
Сообщение Добавлено: Пт мар 04, 2011 17:56
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
chess писал(а):
На самом деле аллокирование медленная вещь(тысячи тиков Timer Stamp Counter) и сильно зависит от объема выделяемой памяти.

Подумалось по этому поводу следующее. Для очень большого количества задач, в которых нужно выделять память под единственный массив (потом она будет не нужна) можно написать свой набор быстрых процедур работы с памятью, аналогичных ALLOCATE, FREE, RESIZE только не в хипе, а в стат. области( для этого нужно увеличить размер образа форт-системы и выделить область для памяти данных). В этом случае все будет очень быстро.
Сообщение Добавлено: Пт мар 04, 2011 17:25
  Заголовок сообщения:  Re: вариант реализации watchdog механизма  Ответить с цитатой
mOleg писал(а):
HeapAlloc из kernel32.dllне знаю на сколько быстро, вроде не слишком медленно, к тому же основные тормоза не с выделением памяти, а с ресайзом ее.

Все относительно. На самом деле аллокирование медленная вещь(тысячи тиков 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, который позволяет решать аналогичные задачи.
Сообщение Добавлено: Ср мар 02, 2011 19:03
  Заголовок сообщения:  о использовании памяти  Ответить с цитатой
Это плата за возможность гибкого использования обоих стеков. :twisted:
А ALLOCATE в форке делает вызов RtlAllocateHeap, и это очень медленно, так ведь?
Кстати, есть ли в SPF или форке удобный механизм финализации (освобождать выделенную память, закрывать файлы) на случай нелокального выхода по THROW?
Сообщение Добавлено: Ср мар 02, 2011 18:40

Часовой пояс: UTC + 3 часа [ Летнее время ]


cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB