VirtualAlloc must die ?????

сам виндос.

Использует глобальную таблицу объектов GDI которая находится по фиксированному адресу.

Есстественно, S_T_A_S_.

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

Изучайте С с плюсами, наконец! Язык не всем нужный, но полезный для понимания многих вещей.



поток №1 оспользует первый метр, поток №2 использует 2й метр и т.д.

Тока не забудь, что тебе придется придумать схему, по которой поток догадается, что он - скажем, №4, да так чтоб второй не решил в этот момент то же самое.

Опять получается картошка с сахаром.



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

А вот если брать твой "простейший случай", то там на мой взгляд глубоко параллельно, какую память использовать.

 

_Juicy >

Вот и я о том же: вполне есстественно организовать в глобальном статическом "массиве" хранилеще динамических данных. Только требуется ещё и менеджер реализовать.



>

Изучаю потихоньку ISO/IEC 14882.

Занятная штука:

Там ни слова нет не то что о VirtualAlloc, виндосе и x86, но и размер байта даже не оговаривается .



А вот тоже интересно:

Получается, что программа DEN была криво написана и я исправил возможную ошибку, применив статичесую память вместо new



>

вообще-то про "мегабайт - каждому потоку" я обобщил, реально каждому требуется различный объём данных, но это не меняет подход:

Код (Text):

1.  
2. static unsigned long __stdcall thread1(void * parameter)
3. {
4.     static char data[1024*1024*1024];
5. //
6. }
7.  
8. static unsigned long __stdcall thread2(void * parameter)
9. {
10.     static char data[1024*1024*1024];
11. //
12. }
13.  
14. /////
15. static unsigned long __stdcall thread4(void * parameter)
16. {
17.     static char data[1024*1024*1024];
18. //
19. }

>

Просто я проанализировал некоторое количестово кода, и обнаружил, что во многих случаях VirtualAlloc можно убрать. Можно, конечно, и использовать, как и GetModuleHandle для экзешников без релоков



Для динамических данных, вместо VirtualAlloc часто хорошо подходит стэк, только если нужно много памяти, то свои тонкости - seh ставить или каждую 4Kb страницу "активировать" в цикле. Зато освобождается эта память просто.

 

S_T_A_S_

Да ты готов доказывать, что земля плоская, приводя как аргумент то, что она стоит на трех китах.

 

Разве я что-то даказывал?

Да я вообще не спорю никогда

 

S_T_A_S_

Все нормально конечно и твой способ имеет парво на жизнь. Тока что делает обычный неразрастающийся хип? Да тоже самое. А разрастающийся просто коммитит доп страницы помере надобности. Если не нравится виндовая реализация - сделай свою. К тому же в твоем случае, если бага в программе - ты можешь запросто ошибочно закомитить всю системную память, а в случае разрастающегося хипа вылетит эксепшн. Тока ты ведь еще не делал свою реализацию хипа, и не сравнивал с виндовой по скорости. Так вот сделай, мне например тоже интересно.

 

В моей статье всё будет сравнено.

 

AsmGuru62

А с какой и чьей реализацией?

PS: надуюсь там не будет утверждаться, что виндовые хипы тока мультитредные - я проверял, мультитред отключается.

 

semen



реализовать менеджер более быстрый чем стандартный можно и без "картошки с сахаром", например сверхбыстрый operator new

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

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

 

semen

Как было замечено выше, на моём сайте будет статья о менеджере памяти (Heap Memory Management). Также будет приложена реализация на С++ (мой код). Хочу сделать на FASM также, но не знаю будет ли время. Также будет исследование (замеры времени) на разные статистические модели аллокации: выделение, например 10000 блоков со случайным размером 4..1024 байт, их освобождение, а также аллокация и освобождение чередующиеся случайным образом, ну, в общем, разные модели.



Кстати, HeapAlloc() принимает параметр (NEAP_NO_SERIALIZE) - как-то он должен проверяться? Кроме того, аллокация 'продирается' через различные функции KERNEL32, интересно будет проверить, что быстрее...

 

AsmGuru62

Интересно будет посмотреть, я кроме "тупого" хипа ничего сам не делал.

NEAP_NO_SERIALIZE проверяется очень просто - в 2х нитках делаем выделение и освобождение из одного хипа - с этим флагом прикладуха вылетит, а без - нет. Насчет скорости ускорение я не проверял.

Еще можно изменить алгоритм аллокации (для маленьких кусочков):

HeapSetInformation(hHeap, HeapCompatibilityInformation, 2);

Вроде больше ничего путного с виндовым хипом больше не сделаешь...

 

> "выделение, например 10000 блоков со случайным размером 4..1024 байт"



Не знаю как в винде, а у борланда и в C++ и в Delphi хранится таблица свободных блоков для всех размеров до 4Кб (адреса кратны 4 или 8). Поэтому аллокация блоков до 4Кб происходит сравнительно быстро. Большее время может занять поиск свободного блока "среднего" размера от 4КБ до 64Кб (или 1Мб), т.к. они хранятся в едином списке типа стек (или rover) с последовательным перебором. Блоки более 64 Кб (1Мб) выделяются и освобождаются непосредственно через VirtualAlloc\VirtualFree.