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

EB>Но мне кажется, что такие ОС мы уже вряд ли увидим. Почему — сказать сложно, но эта идея очень старая (тот же Smalltalk начали создавать в начале 70-х), рождалась она неоднократно у разных людей, были даже концепт-версии — но мейнстрим эту идею так и не принял.

Наверное самая изветная тупиковая попытка — ODMG ИМХО она провалилась из за "проблем" с идентичностью объектов. В отличие от ODMG в моей СУБД один и тот же экземпляр может иметь несколько разных ИД, и так же несколько разных экземпляров могут иметь один и тот же ИД. Это сближает мою СУБД с реляционными, так как позволяет мне проводить операции OBJECT JOIN когда из нескольких различных экземпляров возникает новый — композитный — по аналогии с VIEW / SELECT ... FROM ... OUTER JOIN ...

Здравствуйте, GlebZ, Вы писали:
GZ>>>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.
MS>>Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...
GZ>Объекты обладают множеством недостатков, но я не знаю лучше. Поищите по форуму Философии. Объектная модель не столь однозначна. Это обсасывалось множество раз.

К теме объектности. Ссылки старые, но хорошие.

http://www.softcraft.ru/paradigm/process/index.shtml

http://www.softcraft.ru/paradigm/dhp/index.shtml

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

S>Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.

Задача более фундаментальна. Выкиньте слова: "ОС" и "объектная система управления БД" — они лишние.

Более фундаментальная задача: реализация модели бесконечной персистентной памяти. Нужно реализовать среду времени исполнения, которая работает в рамках этой модели. ОС и всякие БД пусть работают поверх этой среды времени исполнения.

ОС, БД, пользовательские модули
            |
            |
           \|/
 среда времени исполнения
            |
            |
           \|/
         железо

Что вообще означает модель бесконечной персистентной памяти? А то и означает, что записав по адресу A данные X сегодня, и обратившись через сто-тыщ-мильёнов лет по адресу A мы сможем считать данные X.

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


Д>идея разумная, я тоже над этим немало задумывался. С некоторыми ограничениями она даже реализуема
Д>(например, не все объекты имеет смысл сохранять персистентно — немалая часть из них являются временными, и живет крайне недолго)
Д>Проблема в том, что в мэйнстриме мы этого не увидим еще лет 10, если не 20. Причина очень проста — инерция разработчиков и большая база унаследованного кода. М$ даже перейти на управляемый код толком не может, а тут такие радикальные изменения

Полностью согласен. Пост как я написал был не точным описанием новой ОС а всего лишь полетом мысли по этому поводу.
Моим хобби на сегодня как раз является создание и развитие собственной ОБД. Действительно все реализуемо. Хотя очень сложно.
Несколько версий своей ОБД я уже даже опубликовал. Там есть более подробные описания архитектуры, которую я бы хотел видеть в будущей ОС — ну разумеется в том виде в котором у меня получилось это все дело реализовать на сегодняшний момент.

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

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


GZ>Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на
GZ>

GZ><commandir>
GZ>   <mycommandir1/>
GZ>   <commandir>
GZ>      <mycommandir2/>
GZ>      <hendehoh/>
GZ>      <commandir/>
GZ>   </commandir>
GZ></commandir>
GZ>

GZ>Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

А знаете, для ОБД это еще меньшая проблема чем для РБД. С "радостью" EAV надеюсь знакомы? Так под моей ОБД такой проблемы нет. Любой экземпляр любого класса может иметь любые аттрибуты. И приведенное здесь дерево — это просто тривиальность. ну чтоб было по интереснее, можно сделать mycommandir1 вторым парентом для mycommandir2, а mycommandir2 сделать парентом для внешнего commandir. Это все штатные средства работы с аттрибутами объектов в СУБЗ Cerebrum

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

GZ>Одно из достоинств реляционной модели то, что ее можно легко трансформировать. То есть, разложить информацию таким образом, чтобы эти миллионы строк обрабатывались со сложностью не превышающей O(logN). Для реляционки модель хранения и предоставления данных независимы. И эта трансформация пока недоступна для OODB.

В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, shuklin, Вы писали:

S>>Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.

СГ>Задача более фундаментальна. Выкиньте слова: "ОС" и "объектная система управления БД" — они лишние.

СГ>Что вообще означает модель бесконечной персистентной памяти? А то и означает, что записав по адресу A данные X сегодня, и обратившись через сто-тыщ-мильёнов лет по адресу A мы сможем считать данные X.
Задача еще более фундаментальна. В моей, уже разработанной ОБД экземпляры могут иметь много различных адресов, и один и тот же адрес в зависимости от контекста может указывать на разные данные. И без этого никак.

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

S>Несколько версий своей ОБД я уже даже опубликовал. Там есть более подробные описания архитектуры, которую я бы хотел видеть в будущей ОС — ну разумеется в том виде в котором у меня получилось это все дело реализовать на сегодняшний момент.

а маппинг на какие языки у нее есть? Как вообще осуществляется доступ, в общих чертах?
ОБД — это конечно хорошо, но попыток было уже много, и практически все не особо удачные

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


S>>Несколько версий своей ОБД я уже даже опубликовал. Там есть более подробные описания архитектуры, которую я бы хотел видеть в будущей ОС — ну разумеется в том виде в котором у меня получилось это все дело реализовать на сегодняшний момент.

Можно скачать последнюю версию под .NET 1.1 по адресу http://www.shuklin.com/ai/ht/ru/cerebrum Там же есть и описание.

Д>а маппинг на какие языки у нее есть?

.NET 1.1 языки. Это в первую очередь C# & VB

Д>Как вообще осуществляется доступ, в общих чертах?
Желательно, но не обязательно унаследовать ваш класс от моего базового. Крайне желательно, но не обязательно — реализовать интерфпйс IComponent. Вобщем и все. Однако, ОБД не станет сама сериализовать поля твоего класса. Если ты хочешь, чтобы у класса были персистент поля можно сделать
— определить эти поля как аттрибуты в метаданных самой ОБД.
— реализовать ISerializable и сериализовать нужные данные самостоятельно.


Разадресация ИД происходит в пределах контекта. Каждый объект обладает собственным контекстом. Он задается объекту через метод SetConnector интерфейса IComponent — собственно для этого и нужно реализовать этот интерфей — чтоб иметь доступ к собственному контексту.

через контекс можно получить доступ к дочерним аттрибутам.
container = this.GetChildComponents();

через коллекцию дочерних аттрибутов можно получать доступ к их контекстам

connector = container.AttachConnector(someHandle);

через коннектор можно получить
— доступ собственно к экземпляру
connector.Component

— доступ к коллекции дочерних аттрибутов дочернего аттрибута
container2 = connecor.GetContainer() as IContainer;

Д>ОБД — это конечно хорошо, но попыток было уже много, и практически все не особо удачные
Я думаю, что создатели заужали свои амбиции. Я не только делаю ОБД, но еще и БЗ и нейронные сети — такой суржик привел к весьма значительным отступлениям от стандартов ODMG.

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

S>В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...
Да она может и 10000 обрабатывать. Но если в алгоритме заложено O(logN) вместо O(N), то он все равно будет быстрее. Их разница обычно измеряется не в разы, а на порядки.

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

S>>В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...
GZ>Да она может и 10000 обрабатывать. Но если в алгоритме заложено O(logN) вместо O(N), то он все равно будет быстрее. Их разница обычно измеряется не в разы, а на порядки.

разницу между O(N), O(logN) и O(C) просто не заметили?

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

S>А знаете, для ОБД это еще меньшая проблема чем для РБД. С "радостью" EAV надеюсь знакомы? Так под моей ОБД такой проблемы нет. Любой экземпляр любого класса может иметь любые аттрибуты. И приведенное здесь дерево — это просто тривиальность. ну чтоб было по интереснее, можно сделать mycommandir1 вторым парентом для mycommandir2, а mycommandir2 сделать парентом для внешнего commandir. Это все штатные средства работы с аттрибутами объектов в СУБЗ Cerebrum
То есть нету типизированности, нету идентификации, и это называется ООДБ?

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

GZ>То есть нету типизированности, нету идентификации, и это называется ООДБ?

Есть. Но ее можно считать мягкой, так как при любой необходимости она нарушается без доп затрат.
Точнее — типизация и прочее вводится как дополнительные рестрикшены. А вот с идентификацией вопрос сложнее.
Она у меня есть, но координально отличается от ODMG. уже писал здесь же. Один объект имеет разные ИД. Одно и тоже ИД адресует разные объекты.

ООДБ означает что в БД храняться экземпляры объектов с поведением. А вот модель данных в ООБД может быть иерархической, сетевой, реляционной, может еще какую придумают ... У меня — сетевая модель.

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

S>разницу между O(N), O(logN) и O(C) просто не заметили?
Нет не заметил, и не понял что значит сложность обработки одного экземпляра.

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

AVC>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.

Только не говори, что это — типичная задача при программировании.

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

S>>разницу между O(N), O(logN) и O(C) просто не заметили?
GZ>Нет не заметил, и не понял что значит сложность обработки одного экземпляра.

O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.

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

S>O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.
O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).

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

S>>O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.
WH>O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).

Не люблю 1, С всетаки показывает весьма существенные затраты на каждый объект. Совсем ведь без затрат никак (((

Текущие характеристики моей СУБД на AMD 1.7

Инстанциирование объекта — хранилище <-> RAM 1000 C# в секунду.
Поиск в кэш — 50000 — 80000 C# в секунду.


Первый показатель можно оптимизировать и приблизить ко второму значительно, просто времени на оптимизацию не хватает, занят разработкой новых фич.

shuklin wrote:

> WH>O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).
>
> Не люблю 1, С всетаки показывает весьма существенные затраты на каждый
> объект. Совсем ведь без затрат никак (((
Любишь/не любишь, но O(C)=O(1) при любом C>0
Или у тебя C=N^N^100?

> Текущие характеристики моей СУБД на AMD 1.7
>
> Инстанциирование объекта — хранилище <-> RAM 1000 C# в секунду.
> Поиск в кэш — 50000 — 80000 C# в секунду.

> Первый показатель можно оптимизировать и приблизить ко второму
> значительно, просто времени на оптимизацию не хватает, занят разработкой
> новых фич.

Т.е. вообще от кол-ва объектов никак не зависит? Что 1 объект в хранилище, что 1000000?
А от чего зависит? А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?

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

_>Т.е. вообще от кол-ва объектов никак не зависит? Что 1 объект в хранилище, что 1000000?
_>А от чего зависит? А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?

Практически вообще не зависит. Конешно есть косвенные факторы. Если БД поместится вся в RAM целиком, мы будем иметь одну C, Если не поместиться — будем иметь другую C. На границе, при которой размер БД вот вот выйдет за границы RAM конечно возникнет нелинейность. Ну так как без этого? И это доли процентов от общего размера С. Тоесть С в зависимости от размера БД меняется скачком в случае выхода БД за пределы RAM, но все еще остается С(тоесть я могу ориентируясь на худший случай говорить о С) — остальное — очень незначительные ее изменения.

СУБД 32 битная. Максимально теоретически возможное колличество объектов в ней — 2млрд (один бит не используется для адресации).

_>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в нем объектов близко к

p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С учетом накладных расходов, в текущей версии это до 80000 завершенных операций поиска в секунду на машине с которой я это ща пишу. Тоесть от запроса объекта по его ID до получения ссылки на c# экземпляр.