Привет, Alex Mizrahi!
Ты вроде писал(а) в эху RU.COMPUTER.LIFE следуюшее:
SM>> запас мегабайт, не вызовет переполнения оперативной памяти? С
SM>> теперешними компами, скорее надо математически обосновывать
SM>> необходимость экономить память.
U> а если не мегабайт нужно будет хапнуть, а гигабайт? в общем случае это
Тогда не применимость данного варианта, будет ясна и без математических
выкладок.
U> сложная задача.
U>>> ты знаешь наперёд сколько у тебя объектов будет? (если
SM>> Я знаю их максимальное число.
U> LOL. что ж ты оптимизируешь-то тогда? сперва нагородил объекты, а потом
Скорость выделения памяти.
[...]
U>>> знаешь, то связный список -- излишество, нужно пользоваться массивом)
SM>> В массиве заняты элементы с 0 по 99. Запрошено удаление 55 элемента.
SM>> Что делать будем?
U> битмап. один бит на элемент. у тебя же, с длинными указателями -- как
Битмап по умолчанию тормоз, пока я не увижу примера с битмапом, обгоняющего
приведенные мной три строчки.
U> минимум 64 бита на элемент. иди учи матчасть, оптимизатор.
Приведенный мной вариант направлен не на экономию памяти, а на ускорение
программы. Кстати, какие еще длинные указатели, в плоской модели памяти?
U> молодец, продемонстрировал пример, когда люди пишут не думая, а применяя
U> заученные паттерны.
U>>> хотя конкретно эта вообще не понятно как работает -- в каком месте
U>>> выделяются объекты?
SM>> А не все ли равно? Hу можно выделять так: #define Max_Heap 100
U> определи структуру и сделай массив структур -- будет тот же эффект, но
U> куда прямее.
Там и так массив. А class от struct отличается только приватными по умолчанию
полями.
U> если нужна аллокация/деаллокация -- приделать битмап. кстати,
Скорость не та.
U> ещё не мешало бы приделать мутекс для обеспечения доступа из разных
U> потоков.
Тогда уж критическую секцию. Hо что-то мне подсказывает что это добавит жуткие
тормоза. Дешевле для каждого процессора, завести по хипу.
U>>> а в некоторых ситуациях это будет анти-оптимизацией -- т.к. это
SM>> А я где-то писал, что это универсальное решение?
U> хех, ну значит в общем случае нужен анализ -- стоит ли данную
U> "оптимизацию" применять или нет. ты показал самый примитивный случай --
U> ясен пень, что в простейшей ситуации ты сможешь провести анализ чисто на
U> пальцах, но в чуть более сложном случае прийдётся использовать математику.
Придется. Я лишь возражал против "Любая оптимизация имеет математическое
обоснование", примером оптимизации, в математическом обосновании не
нуждающейся.
U> случаи когда известо что будет сто объектов -- очень редки. и те, кто
Hу то что ровно сто - может и редки. А дать оценку сверху для расходов
памяти - врят ли особо сложно.
U> вклеивает подобные ограничения в программы потом об этом жалеют. к
Чего там жалеть? Hепонравилось - убираешь operator new, и начинает работать
стандартный хип.
[...]
SM>> Думаю, шансов потерять часть данных в кеше, от слишком умного
SM>> стандартного алгоритма выделения памяти - немножко больше чем шансов
SM>> что закончится гигабайт оперативки.
U> о, молодец, думаешь, сравниваешь шансы, приводишь цифры. вот для анализа и
U> нужна математика, сам уже понял, да? если понадобится миллион объектов --
Я отрицал квантор всеобщности, а не отрицал необходимость математики вообще.
Понял, да?
U> в кэш они всё равно не влезет, а вот в память могут и влезть.
Так кеш посыпится не от выделения миллиона объектов, а от того что слишком
умный алгоритм будет скакать по своим внутренним структурам в поисках
свободного блока и каждое чтение будет вышибать еще один кеш-ряд.
U>>> на порядки медленнее операций с память. я уж не говорю что от подобной
SM>> Угу, только начало цепочки свободных блоков будет в оперативной памяти,
SM>> а не на диске. По этому, ты врят ли попадешь на память скинутую на
SM>> диск, раньше чем приведенный мной вариант распределит всю физическую
SM>> память.
U> всё равно -- твоя цепочка может вытеснить из памяти что-то.
Так надо в начале инициализировать цепочку, а уж потом грузить "что-то" в
память. Если мне не изменяет память - сами по себе данные exeшника, в память
по умолчанию вообще не грузятся, а просто отображаются в память. Будут их
читать - загрузятся. Hе будут - ну и фиг с ними.
U>>> оптимизации приложение может вообще не влезть в оперативную память.
SM>> Может. Так не ставь в Max_Heap больше чем тебе нужно - авось программа
SM>> и влезет.
U> а если мне надо в одних случаях миллион объектов A, а в других -- миллион
U> объектов B? или ты до таких сложных программ пока не дошёл?
Дешево и сердито:
#define Max_Heap 1000000
class My_Class
{
union
{
A a;
B b;
};
...
};
void*A::operator new(size_t size)
{
return My_Class::operator new(0);
}
void a::operator delete(void*p)
{
My_Class::operator delete(p);
}
U>>> так что если действительно важна скорость -- нужно тщательно
U>>> анализировать. если это однозначно круто, почему этого не сделано в
U>>> стандарте языка? потому что это круто далеко не всегда.
SM>> Потому что указанная мной оптимизация, работает только для конкретного
SM>> класса. И потому что компилятор не знает заранее, каково максимальное
SM>> число объектов данного класса.
U> было бы это дело повсеместно нужно -- добавили бы фичу в компилятор. типа
U> hint кол-ва объектов. а так вообще для этих целей придумали массивы.
Hу LIBCTINY.LIB же вроде не добавили. А так - перегрузка new как я понимаю на
то и придумана, что бы можно было переключится на свой вариант хипа, если не
устраивает стандартный.