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

Теперь покажите, пожалуйста, этот же трюк на C#.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[31]: плохой язык C++ :)
От: igna Россия  
Дата: 10.03.06 10:32
Оценка:
Здравствуйте, Дарней, Вы писали:

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


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



Аллокатор не читает весь контейнер из файла, он читает только то, что нужно.
Re[34]: плохой язык C++ :)
От: Дарней Россия  
Дата: 10.03.06 10:38
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

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

C>поддерживает. А вот локальные закэшированые копии можно хранить в
C>оптимальном формате.

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

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


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

C>Или как вариант — я использую shared-memory для эффективного общения

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

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

C>А откуда MS берет свою траву? Из компилятора C# получается байт код для

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

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

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


и что же ты пишешь, если не секрет? Ядра ОС? серверы БД? компиляторы?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[33]: плохой язык C++ :)
От: igna Россия  
Дата: 10.03.06 10:39
Оценка:
Здравствуйте, Дарней, Вы писали:

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



Его можно использовать с Hashtable из .NET? Чтобы Hashtable оставалась в основном на диске и в память загружались только используемые ее части?
Re[32]: плохой язык C++ :)
От: Дарней Россия  
Дата: 10.03.06 10:43
Оценка:
Здравствуйте, igna, Вы писали:

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


"то, что нужно" — это будет как минимум физический сектор диска, то бишь 512 байт
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[34]: плохой язык C++ :)
От: Дарней Россия  
Дата: 10.03.06 10:43
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Вы не поняли... Именно благодаря этому механизму это чтение и будет

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

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

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


я предпочитаю не пытаться забивать гвозди ноутбуком, а финансы считать на счетах с костяшками.
Каждой задаче — свой инструмент.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[28]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.06 10:44
Оценка:
Здравствуйте, Cyberax, Вы писали:

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

C>менее неэффективно, чем VB3.

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

>> Причем для доступа к данным применяются абстракции вроде потоков. А то

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

Похоже ты перетрудился.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: плохой язык C++ :)
От: igna Россия  
Дата: 10.03.06 10:51
Оценка:
Здравствуйте, Дарней, Вы писали:

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


Да, и что? Если в контейнере десятки мегабайт данных...
Re[34]: плохой язык C++ :)
От: Дарней Россия  
Дата: 10.03.06 10:52
Оценка: :)
Здравствуйте, igna, Вы писали:

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


ты удивишься — поведение по умолчанию именно таково. Если не забывать про гранулярность, конечно.
А ты что, думаешь, что отображенный на диск std::map будет работать эффективно? Святая простота.
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[33]: плохой язык C++ :)
От: Cyberax Марс  
Дата: 10.03.06 10:56
Оценка:
Дарней wrote:
> I>Аллокатор не читает весь контейнер из файла, он читает только то, что
> нужно.
> "то, что нужно" — это будет как минимум физический сектор диска, то бишь
> 512 байт
Меньше прочитать аппаратно не получится.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[34]: плохой язык C++ :)
От: Дарней Россия  
Дата: 10.03.06 10:58
Оценка: +1 :))
Здравствуйте, igna, Вы писали:

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


для таких случаев умные волосатые дядьки уже придумали базы данных
или тебе хочется во что бы то ни стало изобрести свой велосипед?
... << RSDN@Home 1.1.4 stable rev. 510>>
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[28]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.06 11:05
Оценка:
Здравствуйте, igna, Вы писали:

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


В потках есть метод Seek().
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[33]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.06 11:05
Оценка:
Здравствуйте, Дарней, Вы писали:

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


Кстати, забвно, но факт. Промышленные СУБД не используют виртуальную память ОС. Они предпочитают читать с диска сами учитывая размер кластера и т.п. А страницы реализуют тоже сами.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: плохой язык C++ :)
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.03.06 11:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


Будешь трахаться с Линукса и Моно.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[35]: плохой язык C++ :)
От: Cyberax Марс  
Дата: 10.03.06 11:05
Оценка:
Дарней 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'е.
Posted via RSDN NNTP Server 2.0
Sapienti sat!
Re[35]: плохой язык C++ :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.03.06 11:06
Оценка:
Здравствуйте, Дарней, Вы писали:

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

Д>или тебе хочется во что бы то ни стало изобрести свой велосипед?

Насколько мне известно, умные волосатые дядьки (с ними еще и тетька была) из SleepyCat Software используют разделяемую память для организации доступа к БД из нескольких процессов. И file mapping для увеличения скорости работы с БД.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[32]: плохой язык C++ :)
От: dshe  
Дата: 10.03.06 11:09
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Дарней wrote:

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

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

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

C>диска нужных страниц.

Насколько я понимаю, указатели на персистентные объекты такие же как и указатели на обычные объекты (перегруженный оператор new возвращает (void *), который должен быть валидным указателем, поскольку далее к нему применяется конструктор). Далее, страницы с диска не просто загружаются, они загружаются вместо старых страниц, т.е. на их место. Следовательно, физические адреса персистентных объектов могут иногда совпадать и даже для одного и того же объекта меняться в процессе работы программы (т.е. нужно обновлять ссылки на персистентные объекты, если их физический адрес поменялся). Кроме того, нужно как-то отслеживать можно ли выгружать определенную страницу или нет. Все это, наверное, вполне решаемые задачи, но на мой взгляд их весьма трудно решить "прозрачно".
--
Дмитро
Re[35]: плохой язык C++ :)
От: igna Россия  
Дата: 10.03.06 11:09
Оценка: +1
Здравствуйте, Дарней, Вы писали:

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



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

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

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


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



Вот оно!
Re[36]: плохой язык C++ :)
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 10.03.06 11:10
Оценка:
Здравствуйте, 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.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[25]: плохой язык C++ :)
От: vdimas Россия  
Дата: 10.03.06 11:11
Оценка:
Здравствуйте, VladD2, Вы писали:

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


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


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


Вот не надо эту мысль озвучивать без уточнений, а то черезчур неграмотно выглядит. GC "рвет" не все аллокаторы и далеко не во всех сценариях использования. Кстати, даже в С++ юзают аллокаторы, построенные по принципу GC. И некоторые так и делают, особенно в тех сценариях, где GC действительно является наиболее подходящим.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.