Дарней wrote:
> C>обращение по индексу в векторе может вызывать _прозрачное_ чтение с
> C>диска нужных страниц.
> для этого есть специально разработанный механизм виртуальной памяти. Чем
> он то тебя не устраивает?
Вы не поняли... Именно благодаря этому механизму это чтение и будет
происходить. То есть физические С++-ные объекты в памяти отображаются
напрямую на диск, как раз с помощью механизма VM.

Теперь покажите, пожалуйста, этот же трюк на C#.

Здравствуйте, Дарней, Вы писали:

I>>Речь не о сериализации. Это просто уточнение (чтобы проходящие мимо чего не так не поняли).

Д>хоть как назови, суть от этого не изменится.


Аллокатор не читает весь контейнер из файла, он читает только то, что нужно.

Здравствуйте, Cyberax, Вы писали:

C>Переносимые документы можно хоть в XML делать — тот же Boost.S11N это
C>поддерживает. А вот локальные закэшированые копии можно хранить в
C>оптимальном формате.

зачем? что это даст пользователю?

C>Ну и документы — это нестандартный случай.

речь шла именно про этот "нестандартный случай", а не про что-то иное

C>Или как вариант — я использую shared-memory для эффективного общения
C>клиента и сервера в разных процессах на одной машине. Скорость в десятки
C>раз больше, чем при работе с пайпами/сокетами, так как объекты не
C>сериализуются, а просто помещаются (или сразу же там и создаются —
C>зависит от ситуации) в разделяемую память (обычным копиктором).

Ага. Теперь ваши программы будут глючить в десять раз быстрее.

C>А откуда MS берет свою траву? Из компилятора C# получается байт код для
C>стековой машины, который потом JITом обратно переводится в SSA-дерево,
C>которое потом компилируется. И зачем такой изврат?

вероятно, слова "бинарная соместимость" и "за все надо платить" тебе ничего не говорят

C>А я не пишу "среднестатистические" проги

и что же ты пишешь, если не секрет? Ядра ОС? серверы БД? компиляторы?

Здравствуйте, Дарней, Вы писали:

Д>для этого есть специально разработанный механизм виртуальной памяти.


Его можно использовать с Hashtable из .NET? Чтобы Hashtable оставалась в основном на диске и в память загружались только используемые ее части?

Здравствуйте, igna, Вы писали:

I>Аллокатор не читает весь контейнер из файла, он читает только то, что нужно.

"то, что нужно" — это будет как минимум физический сектор диска, то бишь 512 байт

Здравствуйте, Cyberax, Вы писали:

C>Вы не поняли... Именно благодаря этому механизму это чтение и будет
C>происходить. То есть физические С++-ные объекты в памяти отображаются
C>напрямую на диск, как раз с помощью механизма VM.

чтобы мендежер памяти сбросил страницу с объектом внутри на диск, вообще не нужен никакой трах с аллокаторами. Я тебя и действительно не понимаю

C>Теперь покажите, пожалуйста, этот же трюк на C#.

я предпочитаю не пытаться забивать гвозди ноутбуком, а финансы считать на счетах с костяшками.
Каждой задаче — свой инструмент.

Здравствуйте, Cyberax, Вы писали:

C>.NET дает возможность писать кривые и уродские приложения. Причем не
C>менее неэффективно, чем VB3.

Понимаш ли в чем дело. Твое злопыхательство ни на грам не повредит .NET-у, но вот тебя подобные слова выставляют в не очень хорошем свете.

>> Причем для доступа к данным применяются абстракции вроде потоков. А то
>> как эти абстрации лезут к физическим аднным (через файл-маппинг или еще
>> как) определяется реализациями абстракций.
C>А для вызова методов у String надо _обязательно_ использовать SOAP через
C>прокси-сервер в Африке. В конце концов, вы ведь не можете знать заранее
C>откуда пришла строка?

Похоже ты перетрудился.

Здравствуйте, Дарней, Вы писали:

Д>"то, что нужно" — это будет как минимум физический сектор диска, то бишь 512 байт

Да, и что? Если в контейнере десятки мегабайт данных...

Здравствуйте, igna, Вы писали:

I>Его можно использовать с Hashtable из .NET? Чтобы Hashtable оставалась в основном на диске и в память загружались только используемые ее части?

ты удивишься — поведение по умолчанию именно таково. Если не забывать про гранулярность, конечно.
А ты что, думаешь, что отображенный на диск std::map будет работать эффективно? Святая простота.

Дарней wrote:
> I>Аллокатор не читает весь контейнер из файла, он читает только то, что
> нужно.
> "то, что нужно" — это будет как минимум физический сектор диска, то бишь
> 512 байт
Меньше прочитать аппаратно не получится.

Здравствуйте, igna, Вы писали:

I>Да, и что? Если в контейнере десятки мегабайт данных...

для таких случаев умные волосатые дядьки уже придумали базы данных
или тебе хочется во что бы то ни стало изобрести свой велосипед?

Здравствуйте, igna, Вы писали:

I>Это как? Последовательно прочитать ассоциативный контейнер размером в 50 мегабайт?

В потках есть метод Seek().

Здравствуйте, Дарней, Вы писали:

Д>"то, что нужно" — это будет как минимум физический сектор диска, то бишь 512 байт

Кстати, забвно, но факт. Промышленные СУБД не используют виртуальную память ОС. Они предпочитают читать с диска сами учитывая размер кластера и т.п. А страницы реализуют тоже сами.

Здравствуйте, Cyberax, Вы писали:

C>Вы не поняли... Что будет, если я захочу сайт на aspx захостить на Линуксе?

Будешь трахаться с Линукса и Моно.

Дарней 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 для увеличения скорости работы с БД.

Здравствуйте, Cyberax, Вы писали:

C>Дарней wrote:
>> I>Речь не о сериализации. Это просто уточнение (чтобы проходящие мимо
>> чего не так не поняли).
>> хоть как назови, суть от этого не изменится.
C>Меняется. File mapping и использование custom-allocator'ов позволяет
C>работать с объектами на диске так, как будто они прямо в памяти лежат.

Идея, использовать allocator'ы для прозрачного обращения в объектам на диске, меня тоже когда-то прельщала. Однако я столкнулся с определенными сложностями. Интересно было бы взглянуть на работющую реализацию этой идеи.

C>обращение по индексу в векторе может вызывать _прозрачное_ чтение с
C>диска нужных страниц.

Насколько я понимаю, указатели на персистентные объекты такие же как и указатели на обычные объекты (перегруженный оператор new возвращает (void *), который должен быть валидным указателем, поскольку далее к нему применяется конструктор). Далее, страницы с диска не просто загружаются, они загружаются вместо старых страниц, т.е. на их место. Следовательно, физические адреса персистентных объектов могут иногда совпадать и даже для одного и того же объекта меняться в процессе работы программы (т.е. нужно обновлять ссылки на персистентные объекты, если их физический адрес поменялся). Кроме того, нужно как-то отслеживать можно ли выгружать определенную страницу или нет. Все это, наверное, вполне решаемые задачи, но на мой взгляд их весьма трудно решить "прозрачно".

Здравствуйте, Дарней, Вы писали:

Д>чтобы мендежер памяти сбросил страницу с объектом внутри на диск, вообще не нужен никакой трах с аллокаторами.


Сценарий может быть такой:

Данные на диске. Программа стартует, данные все еще на диске. Пользователь ищет кое-что в file-mapped STL-контейнере, это кое-что (плюс кое-что еще, да, но далеко не весь контейнер) подгружается в память. 99% данных все еще на диске. Пользователь завершает программу и эти 99% так и останутся на этот раз на диске.

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


Д>Каждой задаче — свой инструмент.


Вот оно!

Здравствуйте, Cyberax, Вы писали:

C>3. Делаем так:
C>

C>struct B
C>{
C>    int a;
C>    std::basic_string<char,shmem_allocator<char> > b,c;
C>};
C>

А мы не поимеем трах с std::basic_string<char,shmem_allocator<char>> в программе? Он ведь не совместим с std::string.

Может лучше было бы иметь:

std::vector< B, shmem_allocator<B> > ...

и специализацию shmem_allocator для типа B, который должным образом сериализует b и c, имеющие обычный тип std::string.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, igna, Вы писали:

I>>Это да. Зато если в C# аллокаторы не предусмотрены, то определить их не получится ни через задний, ни через какой. Или unsafe дает какую-нибудь возможность?

VD>На фиг не упали никакие "аллокаторы" в языках с ЖЦ. ЖЦ порвет все "аллокаторы" как Тузик грелку.

Вот не надо эту мысль озвучивать без уточнений, а то черезчур неграмотно выглядит. GC "рвет" не все аллокаторы и далеко не во всех сценариях использования. Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И некоторые так и делают, особенно в тех сценариях, где GC действительно является наиболее подходящим.