Здравствуйте, srggal, Вы писали:
G>>Только Win32, причем только 32 битные платформы (!) с адресным пространством 2Гб на процесс. И только для своих продуктов — оно не продается. Сделано в рамках работ по улучшению работы legacy клиента и сервера. Результат предельно практический — время старта системы сокращено в несколько раз .
S>Нюансы адресации памяти для выделения места в адресе блока под признак кучи
Как минимум используется один бит адреса (старший, но может быть и сдвинут — следует из ограничения 2Гб). Вероятно, и несколько младших тоже, поскольку никто не выделяет на куче по байту. Даже у Рихтера было пара строчек о таком хаке (негативных, что ИМХО спорно).
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, srggal, Вы писали:
G>>>Только Win32, причем только 32 битные платформы (!) с адресным пространством 2Гб на процесс. И только для своих продуктов — оно не продается. Сделано в рамках работ по улучшению работы legacy клиента и сервера. Результат предельно практический — время старта системы сокращено в несколько раз .
S>>Нюансы адресации памяти для выделения места в адресе блока под признак кучи
GN>Как минимум используется один бит адреса (старший, но может быть и сдвинут — следует из ограничения 2Гб). Вероятно, и несколько младших тоже, поскольку никто не выделяет на куче по байту. Даже у Рихтера было пара строчек о таком хаке (негативных, что ИМХО спорно).
Но вот можно ли много хипов закодировать 3мя битами
Здравствуйте, srggal,
GN>>Как минимум используется один бит адреса (старший, но может быть и сдвинут — следует из ограничения 2Гб). Вероятно, и несколько младших тоже, поскольку никто не выделяет на куче по байту. Даже у Рихтера было пара строчек о таком хаке (негативных, что ИМХО спорно).
S>Но вот можно ли много хипов закодировать 3мя битами
S>Усложнять надо однако/
Если выделяется блоками по 16 байт — уже 5 битов, ну и так далее. Знаковый бит видимо используется как какой-то специальный маркер.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Здравствуйте, Gaperton, Вы писали:
S>>>И решение от CQG — платформонезависимое, или портабельное ?
S>>В догонку — а для двухядерных CPU кол-во интсрукций — вырастает ?
G>Этот аллокатор однопоточный. Насколько я понимаю.
Чего-то я не понимаю:
а в какая связь двухядерного CPU с кол-вом потоков в ПО, которое на нем крутится ?
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
S>>>>И решение от CQG — платформонезависимое, или портабельное ?
S>>>В догонку — а для двухядерных CPU кол-во интсрукций — вырастает ?
G>>Этот аллокатор однопоточный. Насколько я понимаю. S>Чего-то я не понимаю: S> а в какая связь двухядерного CPU с кол-вом потоков в ПО, которое на нем крутится ?
Если вы настаиваете на отсутствии связи — то я не понимаю к чему вы задаете этот вопрос вообще. Как количество ядер может повлиять на количество инструкций аллокатора, если может быть не более чем один аллокатор на поток (выполняющийся, естественно, на одном ядре — по другому никак)? С какой стати количество инструкций аллокатора однопоточного приложения должно вырасти, исполняйся он хоть на двадцатиядерном кристалле? Странный вопрос.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, srggal, Вы писали:
S>>Здравствуйте, Gaperton, Вы писали:
S>>>>>И решение от CQG — платформонезависимое, или портабельное ?
S>>>>В догонку — а для двухядерных CPU кол-во интсрукций — вырастает ?
G>>>Этот аллокатор однопоточный. Насколько я понимаю. S>>Чего-то я не понимаю: S>> а в какая связь двухядерного CPU с кол-вом потоков в ПО, которое на нем крутится ?
G>Если вы настаиваете на отсутствии связи — то я не понимаю к чему вы задаете этот вопрос вообще. Как количество ядер может повлиять на количество инструкций аллокатора, если может быть не более чем один аллокатор на поток (выполняющийся, естественно, на одном ядре — по другому никак)? С какой стати количество инструкций аллокатора однопоточного приложения должно вырасти, исполняйся он хоть на двадцатиядерном кристалле? Странный вопрос.
Здравствуйте, gear nuke, Вы писали:
GN>Пример, можно сказать, неудачный в моём контексте, но он показывает, что можно подумать один раз при дизайне классса, а можно — каждый раз при создании экземпляра.
Если использовать везде один и тот же класс — да, наверно можно. Другой вопрос, что одним методом освобождения памяти все равно не обойдешься (если этот метод — не автоматическая сборка мусора ). А когда таких классов становится несколько, то для каждого объекта тебе все равно придется выбирать
Здравствуйте, Gaperton, Вы писали:
G>Только при ее реализации придется решить ряд интересных инженерных проблем, для того, чтобы действительно получилось O(1). Дьявол в деталях — вы должны экономно подходить к расходованию адресного пространства у вас будет много хипов — надо разработать эффективную схему управления ими. Например — интересна проблема быстрого (за O(1)) определения адреса хипа по указателю на выделенный блок .
Я сейчас над этой идеей размышляю, и у меня пока нет уверенности, что мне вообще адрес хипа нужен. Более того, не уверен, что у него вообще должен быть адрес — в смысле , что он должен лежать непрерывным куском.
А я мечтаю о 64-битах. О резервировании для каждого вектора по гигабайту памяти. И о коммите, только когда надо. То есть, получаем невозможное — отсуствие переаллокаций при переполнении (при переполнении просто коммитим следующую страничку) и одновременно линейный кусок памяти...
Правильно работающая программа — просто частный случай Undefined Behavior
Здравствуйте, _Winnie, Вы писали:
_W>Здравствуйте, Cyberax, Вы писали:
_W>А я мечтаю о 64-битах. О резервировании для каждого вектора по гигабайту памяти. И о коммите, только когда надо. То есть, получаем невозможное — отсуствие переаллокаций при переполнении (при переполнении просто коммитим следующую страничку) и одновременно линейный кусок памяти...
Ну... гранулярность страниц все же присутствует Т. е. для каждого вектора будет выделяться минимум 4 Кб памяти, (Какой размер страницы на AMD64 я не знаю ) Основная потребность в realloc присутвует у разработчиков библиотек, когда у тебя нет ни малейшего понятия ни о том, сколько элементов будет располагаться в твоей структуре данных, ни о том, каков размер каждого элемента. Плюс работа со строками.
Здравствуйте, srggal, Вы писали:
S>Но вот можно ли много хипов закодировать 3мя битами
В менеджере памяти Delphi как раз три бита используется для:
-- для указания того, используется ли данный блок
-- для указания того, свободен ли предыдущий блок
-- для указания специального блока "щель"
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gaperton, Вы писали:
G>>Только при ее реализации придется решить ряд интересных инженерных проблем, для того, чтобы действительно получилось O(1). Дьявол в деталях — вы должны экономно подходить к расходованию адресного пространства у вас будет много хипов — надо разработать эффективную схему управления ими. Например — интересна проблема быстрого (за O(1)) определения адреса хипа по указателю на выделенный блок .
PD>Я сейчас над этой идеей размышляю, и у меня пока нет уверенности, что мне вообще адрес хипа нужен. Более того, не уверен, что у него вообще должен быть адрес — в смысле , что он должен лежать непрерывным куском.
ГМ, я лично, воспринял "адресс хипа" — как индекс хипа.
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, srggal, Вы писали:
S>>Но вот можно ли много хипов закодировать 3мя битами
M>В менеджере памяти Delphi как раз три бита используется для: M> -- для указания того, используется ли данный блок M> -- для указания того, свободен ли предыдущий блок M> -- для указания специального блока "щель"
ГМ, я вел речь не о блоке памяти, который распределен на куче, а о самой куче, их должно быть несколько.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Gaperton, Вы писали:
G>>Только при ее реализации придется решить ряд интересных инженерных проблем, для того, чтобы действительно получилось O(1). Дьявол в деталях — вы должны экономно подходить к расходованию адресного пространства у вас будет много хипов — надо разработать эффективную схему управления ими. Например — интересна проблема быстрого (за O(1)) определения адреса хипа по указателю на выделенный блок .
PD>Я сейчас над этой идеей размышляю, и у меня пока нет уверенности, что мне вообще адрес хипа нужен. Более того, не уверен, что у него вообще должен быть адрес — в смысле , что он должен лежать непрерывным куском.
Это все ерунда. Главное — экономно обойтись с адредным пространством (оно должно отжираться плавно и пропорционально выделенной памяти), а вот как ты при этом собираешься делать деаллокацию объекта за О(1) — очень любопытный вопрос. Плюс — хипов у тебя должно быть много разных в любом случае — во избежание фрагментации для обеспечения хранения объектов разных длин. Соответственно, ты никуда не денешься без определения адреса хипа по указателю на объект. Еще немного, и у тебя появится в этом уверенность. Хотя, если у тебя появится уверенность в обратном — обязательно пиши, это уже будет что-то оригинальное. Баллов дадим — сам понимаешь .
[] PD>>Я сейчас над этой идеей размышляю, и у меня пока нет уверенности, что мне вообще адрес хипа нужен. Более того, не уверен, что у него вообще должен быть адрес — в смысле , что он должен лежать непрерывным куском.
S>ГМ, я лично, воспринял "адресс хипа" — как индекс хипа.
ГМ, уточню — индекс хипа в таблице адресов хипов -> конструкция чудесно ложится на ассемблерр
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я сейчас над этой идеей размышляю, и у меня пока нет уверенности, что мне вообще адрес хипа нужен. Более того, не уверен, что у него вообще должен быть адрес — в смысле , что он должен лежать непрерывным куском.
Может я туплю, но что Вы вкладываете в понятие ХИП ?
Как примитивный вариант -> это просто голова списка выделенных блоков, и вот его-то адрес и будет в таком случае адресом хипа.
Здравствуйте, buriy, Вы писали:
B>Здравствуйте, Nickolay Ch, Вы писали: NC>>Здравствуйте, Сергей Губанов, Вы писали: СГ>>>P. S. Такие сверхбыстрые операционные системы следующего поколения разрабатываются, например, здесь.
NC>>ЗЫ. Нажал на ссылку интереса ради, и ужаснулся, аж в глазах посинело. Дизайн жуткий, не жмите эту ссылку! B>Мда... Видимо, у тех, кто делает проекты на обероне, нету ни денег, ни мозгов, ни друзей - иначе сделать нормальный дизайн для них проблемы не составило бы...
. 
). А когда таких классов становится несколько, то для каждого объекта тебе все равно придется выбирать 
) Основная потребность в realloc присутвует у разработчиков библиотек, когда у тебя нет ни малейшего понятия ни о том, сколько элементов будет располагаться в твоей структуре данных, ни о том, каков размер каждого элемента. Плюс работа со строками.
