Дарней wrote: > C>обращение по индексу в векторе может вызывать _прозрачное_ чтение с > C>диска нужных страниц. > для этого есть специально разработанный механизм виртуальной памяти. Чем > он то тебя не устраивает?
Вы не поняли... Именно благодаря этому механизму это чтение и будет
происходить. То есть физические С++-ные объекты в памяти отображаются
напрямую на диск, как раз с помощью механизма VM.
Здравствуйте, Дарней, Вы писали:
I>>Речь не о сериализации. Это просто уточнение (чтобы проходящие мимо чего не так не поняли).
Д>хоть как назови, суть от этого не изменится.
Аллокатор не читает весь контейнер из файла, он читает только то, что нужно.
Здравствуйте, Cyberax, Вы писали:
C>Переносимые документы можно хоть в XML делать — тот же Boost.S11N это C>поддерживает. А вот локальные закэшированые копии можно хранить в C>оптимальном формате.
зачем? что это даст пользователю?
C>Ну и документы — это нестандартный случай.
речь шла именно про этот "нестандартный случай", а не про что-то иное
C>Или как вариант — я использую shared-memory для эффективного общения C>клиента и сервера в разных процессах на одной машине. Скорость в десятки C>раз больше, чем при работе с пайпами/сокетами, так как объекты не C>сериализуются, а просто помещаются (или сразу же там и создаются — C>зависит от ситуации) в разделяемую память (обычным копиктором).
Ага. Теперь ваши программы будут глючить в десять раз быстрее.
C>А откуда MS берет свою траву? Из компилятора C# получается байт код для C>стековой машины, который потом JITом обратно переводится в SSA-дерево, C>которое потом компилируется. И зачем такой изврат?
вероятно, слова "бинарная соместимость" и "за все надо платить" тебе ничего не говорят
C>А я не пишу "среднестатистические" проги
и что же ты пишешь, если не секрет? Ядра ОС? серверы БД? компиляторы?
Здравствуйте, Cyberax, Вы писали:
C>Вы не поняли... Именно благодаря этому механизму это чтение и будет C>происходить. То есть физические С++-ные объекты в памяти отображаются C>напрямую на диск, как раз с помощью механизма VM.
чтобы мендежер памяти сбросил страницу с объектом внутри на диск, вообще не нужен никакой трах с аллокаторами. Я тебя и действительно не понимаю
C>Теперь покажите, пожалуйста, этот же трюк на C#.
я предпочитаю не пытаться забивать гвозди ноутбуком, а финансы считать на счетах с костяшками.
Каждой задаче — свой инструмент.
Здравствуйте, Cyberax, Вы писали:
C>.NET дает возможность писать кривые и уродские приложения. Причем не C>менее неэффективно, чем VB3.
Понимаш ли в чем дело. Твое злопыхательство ни на грам не повредит .NET-у, но вот тебя подобные слова выставляют в не очень хорошем свете.
>> Причем для доступа к данным применяются абстракции вроде потоков. А то >> как эти абстрации лезут к физическим аднным (через файл-маппинг или еще >> как) определяется реализациями абстракций. C>А для вызова методов у String надо _обязательно_ использовать SOAP через C>прокси-сервер в Африке. В конце концов, вы ведь не можете знать заранее C>откуда пришла строка?
Похоже ты перетрудился.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Его можно использовать с Hashtable из .NET? Чтобы Hashtable оставалась в основном на диске и в память загружались только используемые ее части?
ты удивишься — поведение по умолчанию именно таково. Если не забывать про гранулярность, конечно.
А ты что, думаешь, что отображенный на диск std::map будет работать эффективно? Святая простота.
Дарней wrote: > I>Аллокатор не читает весь контейнер из файла, он читает только то, что > нужно. > "то, что нужно" — это будет как минимум физический сектор диска, то бишь > 512 байт
Меньше прочитать аппаратно не получится.
Здравствуйте, Дарней, Вы писали:
Д>"то, что нужно" — это будет как минимум физический сектор диска, то бишь 512 байт
Кстати, забвно, но факт. Промышленные СУБД не используют виртуальную память ОС. Они предпочитают читать с диска сами учитывая размер кластера и т.п. А страницы реализуют тоже сами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Дарней wrote: > C>Вы не поняли... Именно благодаря этому механизму это чтение и будет > C>происходить. То есть физические С++-ные объекты в памяти отображаются > C>напрямую на диск, как раз с помощью механизма VM. > чтобы мендежер памяти сбросил страницу с объектом внутри на диск, вообще > не нужен никакой трах с аллокаторами. Я тебя и действительно не понимаю
Объясняю.
1. Имеем массив int'ов. Как расположить его в shared memory/file
mapping'е понятно без вопросов.
2. Имеем массив таких объектов:
struct B
{
int a;
std::string b,c;
};
Как его расположить в мэпинге? Если тупо записать std::string на диск,
то будет плохо (объяснить?).
3. Делаем так:
struct B
{
int a;
std::basic_string<char,shmem_allocator<char> > b,c;
};
Теперь внутренний буффер std::string будет распологаться в shared
memory/file mapping'е.
Здравствуйте, Дарней, Вы писали:
Д>для таких случаев умные волосатые дядьки уже придумали базы данных Д>или тебе хочется во что бы то ни стало изобрести свой велосипед?
Насколько мне известно, умные волосатые дядьки (с ними еще и тетька была) из SleepyCat Software используют разделяемую память для организации доступа к БД из нескольких процессов. И file mapping для увеличения скорости работы с БД.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Дарней wrote: >> I>Речь не о сериализации. Это просто уточнение (чтобы проходящие мимо >> чего не так не поняли). >> хоть как назови, суть от этого не изменится. C>Меняется. File mapping и использование custom-allocator'ов позволяет C>работать с объектами на диске так, как будто они прямо в памяти лежат.
Идея, использовать allocator'ы для прозрачного обращения в объектам на диске, меня тоже когда-то прельщала. Однако я столкнулся с определенными сложностями. Интересно было бы взглянуть на работющую реализацию этой идеи.
C>обращение по индексу в векторе может вызывать _прозрачное_ чтение с C>диска нужных страниц.
Насколько я понимаю, указатели на персистентные объекты такие же как и указатели на обычные объекты (перегруженный оператор new возвращает (void *), который должен быть валидным указателем, поскольку далее к нему применяется конструктор). Далее, страницы с диска не просто загружаются, они загружаются вместо старых страниц, т.е. на их место. Следовательно, физические адреса персистентных объектов могут иногда совпадать и даже для одного и того же объекта меняться в процессе работы программы (т.е. нужно обновлять ссылки на персистентные объекты, если их физический адрес поменялся). Кроме того, нужно как-то отслеживать можно ли выгружать определенную страницу или нет. Все это, наверное, вполне решаемые задачи, но на мой взгляд их весьма трудно решить "прозрачно".
Здравствуйте, Дарней, Вы писали:
Д>чтобы мендежер памяти сбросил страницу с объектом внутри на диск, вообще не нужен никакой трах с аллокаторами.
Сценарий может быть такой:
Данные на диске. Программа стартует, данные все еще на диске. Пользователь ищет кое-что в file-mapped STL-контейнере, это кое-что (плюс кое-что еще, да, но далеко не весь контейнер) подгружается в память. 99% данных все еще на диске. Пользователь завершает программу и эти 99% так и останутся на этот раз на диске.
Что существенно, программа использует обычный стандартный контейнер.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, igna, Вы писали:
I>>Это да. Зато если в C# аллокаторы не предусмотрены, то определить их не получится ни через задний, ни через какой. Или unsafe дает какую-нибудь возможность?
VD>На фиг не упали никакие "аллокаторы" в языках с ЖЦ. ЖЦ порвет все "аллокаторы" как Тузик грелку.
Вот не надо эту мысль озвучивать без уточнений, а то черезчур неграмотно выглядит. GC "рвет" не все аллокаторы и далеко не во всех сценариях использования. Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И некоторые так и делают, особенно в тех сценариях, где GC действительно является наиболее подходящим.