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

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

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

Это просто недавний случай, вот он сразу и вспомнился.
А вообще "типичная задача" — понятие относительное.
Например, т.к. я переодически "пишу компиляторы" , мне может срочно понадобиться сделать md-файл для нового backend-а.
Но ассемблеры "капризны": у одних destination register слева, у других справа.
И что, мне несколько сотен шаблонов ручками править?
А в vi это не проблема: найти и переставить подстроки по шаблону. Раз — и все!
Потом использование abbr.
Например, тут высказывались в том духе, что в Обероне набирать ключевые слова заглавными буквами "рука устанет".
Мол, Shift держать трудно, надо обладать большой физической силой...
А оно надо?
Настраиваю abbr, у меня вместо while не только WHILE напечатается, но и WHILE DO END, и курсор встанет в нужную позицию.

Конечно, многие "фичи" могут быть и в других редакторах.
Но, как правило, не все.
К тому же, они везде реализованы по разному...
А vi (или vim) практически везде одинаков (и везде доступен).

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

AVC>А вообще "типичная задача" — понятие относительное.

вполне даже абсолютное... хочешь, опрос проведем?
я не думаю, что найдется хотя бы 0.1% людей, для которых возможность вставки заданного количества одинаковых строк в код является определяющей при выборе IDE

AVC>Но ассемблеры "капризны": у одних destination register слева, у других справа.
AVC>И что, мне несколько сотен шаблонов ручками править?
AVC>А в vi это не проблема: найти и переставить подстроки по шаблону. Раз — и все!

поиск и замена по регэксу есть практически в любой современной IDE

AVC>Потом использование abbr.
AVC>Например, тут высказывались в том духе, что в Обероне набирать ключевые слова заглавными буквами "рука устанет".
AVC>Мол, Shift держать трудно, надо обладать большой физической силой...
AVC>А оно надо?
AVC>Настраиваю abbr, у меня вместо while не только WHILE напечатается, но и WHILE DO END, и курсор встанет в нужную позицию.

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

AVC>А vi (или vim) практически везде одинаков (и везде доступен).

Только пользоваться этим допотопным чудом мало кто хочет.

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

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

В любой Windows используются точно такие же алгоритмы для сокрытия реального адреса объекта и выдачей пользователю некоторого handle.
Вопрос сколько времени требуется для поиска объекта по какому-то primary key, например по имени.

shuklin wrote:

> _>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
> Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве
> всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в
> нем объектов близко к
>
> p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С
> учетом накладных расходов, в текущей версии это до 80000 завершенных
> операций поиска в секунду на машине с которой я это ща пишу. Тоесть от
> запроса объекта по его ID до получения ссылки на c# экземпляр.

Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за константное время, значит у тебя известные ограничения
этого подхода — вставка/удаление работает линейное время, либо объекты должны быть фиксированного размера, при этом
иногда нужно делать дефрагментацию (точнее упаковку). А вообще говоря 10000 _вставок_ в секунду не слишком далеко от
некоторых промышленных бд, выборка по индексу (но не за линейное время, а за логарифмическое) быстрее (без хранения всей
базы в памяти, из кэша ещё быстрее).

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

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

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

MS>В любой Windows используются точно такие же алгоритмы для сокрытия реального адреса объекта и выдачей пользователю некоторого handle.
Это алгоритм не столько для скрытия, сколько для обеспечения "мягкости" handle — независимости логического адреса объекта от способа его хранения диск/память и независимости от сессии работы ОБД и возможности дефрагментации — перемещения блоков с данными.

MS>Вопрос сколько времени требуется для поиска объекта по какому-то primary key, например по имени.


уточнение. в ОБД primary key объекта это его ID. В ОБД используются только суррогатные primary key == object ID.

Поиск объектов по вторичным ключам действительно требует времени. Требует построения дополнительных индексов и всего прочего.
В этом моменте ОБД настолько же эффективны либо хуже РБД. ИМХО. Ну совсем все сразу не получишь. За все остальные достоинства приходится расплачиваться. В том числе этим. Еще в ОБД есть трудности с VIEW. не то чтоб VIEW в ОБД небыло вовсе, но они не столь "красивы" концептуально. Вплоть до того что ODMG вообще согласился с тем, что поддержка VIEW в ОБД есть фича необязательная. ИМХО проблемы VIEW в ОБД гораздо важнее этих едениц процентов по скорости. При наличии прямой навигации как целостная система, приложение на ОБД в 90% будет все равно уделывать приложение на РБД по скорости. А вот VIEW — это вопрос не оптимизации а функциональности.

В ОБД моей разработке для решения трудностей с VIEW применяются объектные JOIN и агрегаты. Индексы для поиска объектов по вторичным ключам в моей ОБД не реализованы. При их необходимости программеру придется реализовать персистент хэш таблицы. В будущем поддержку индексов планирую. В других ОБД поддержка вторичных индексов есть.

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



_>Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за константное время, значит у тебя известные ограничения
_>этого подхода — вставка/удаление работает линейное время,
Да. Причем для вставки/удаления С гораздо хуже чем для выборок. Сейчас это еще связанно с ограниченостью моих рессурсов как разработчика. Что и как оптимизировать ясно. А время на это нет

_>либо объекты должны быть фиксированного размера, при этом
_>иногда нужно делать дефрагментацию (точнее упаковку).
Этого нет. Объекты могут иметь любой размер и дефрагментация не предусмотрена. В будущем возможно, но не в ближайшем. Да, доп потери. Опять же я не про вымышленную систему говорю, а про рельную, доступную для свободного довнлоада.


_> А вообще говоря 10000 _вставок_ в секунду не слишком далеко от
_>некоторых промышленных бд, выборка по индексу (но не за линейное время, а за логарифмическое) быстрее (без хранения всей
_>базы в памяти, из кэша ещё быстрее).

Ну Рим не за один день строился

shuklin wrote:

> _>Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за
> константное время, значит у тебя известные ограничения
> _>этого подхода — вставка/удаление работает линейное время,
> Да. Причем для вставки/удаления С гораздо хуже чем для выборок. Сейчас
> это еще связанно с ограниченостью моих рессурсов как разработчика. Что и
> как оптимизировать ясно. А время на это нет
Что-то такое ощущение, что для тебя все алгоритмы имеют сложность С, где это С может быть каким угодно.

> _>либо объекты должны быть фиксированного размера, при этом
> _>иногда нужно делать дефрагментацию (точнее упаковку).
> Этого нет. Объекты могут иметь любой размер и дефрагментация не
> предусмотрена. В будущем возможно, но не в ближайшем. Да, доп потери.
Если из 5-и гигового файла удалить объекты, которые находятся в 1-м гигабайте — тебе как-то придётся сдвигать оставшиеся
4 гига, меняя положение/индексы (а не дай бог если они идентификаторы) объектов.

> Опять же я не про вымышленную систему говорю, а про рельную, доступную
> для свободного довнлоада.
Да я понимаю, просто отношусь скептически. Не понимаю, за счёт чего (а не чем) эта система "лучше всех существующих"?

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

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

Это как?

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

AVC>Здравствуйте, Ranger_XL, Вы писали:
R_X>>Важна не скорость одной операции, а скорость выполнения задачи в целом

[...]

AVC>Все ли ресурсы мы используем для повышения своей производительности труда?
AVC>Я думаю, что и к теме топика надо подходить с этой точки зрения.
AVC>Эта "будущая ОС" повысит нашу производительность или нет?
AVC>Технические вопросы здесь вторичны. Сначала нало выяснить, а хороша ли основная идея?


С тех пор как появилась задача о программировании автоматически появилась и вторая задача об оптимизации программирования.

Всё, что мы тут обсуждаем это задача об оптимизации программирования.
Нас ждут такие технологии, которые позволят сварганить операционку за час, среду разработки за пол дня.
Дадим каждому пользователю по операционке и рабочей среде под заказ!
Эта мечта о могуществе на кончиках пальцев.

Всё это незримо начинается с установления обратных связей. Где появляется обратная связь — жди повышения эффективности.

Тут возник спор. Одни говорят (утрирую): — файл это всё. Другие говорят: — всё это объект.
1) если нет ничего проще файла. Однако у файла есть свойства и атрибуты. Методы файла — это приложения которые "понимают" такой файл. Тогда коммунизм наступит при достаточном количестве приложений.
2) если нет ничего проще объекта (Sysyem::Object). Тогда нас ждут братья servlet, plugin и addin.

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


А серьёзный скачёк будет тогда, когда компьютер в свободное от пользователя время начнёт заниматься поиском и установлением новых обратных связей. Но пока что, это задача слишком нетривиальная.
По-этому, я бы поставил вопрос по другому: "При какой архитектуре ОС проще искать и устанавливать обратные связи?". Вот где собака не рылась!

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

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

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

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

Согласен. Весь вопрос упирается в создании надёжного и эффективного ассоциативного хранилища мгновенного доступа.

WoldemaR wrote:

> Всё, что мы тут обсуждаем это задача об оптимизации программирования.
> Нас ждут такие технологии, которые позволят сварганить операционку за
> час, среду разработки за пол дня.
> Дадим каждому пользователю по операционке и рабочей среде под заказ!
> Эта мечта о могуществе на кончиках пальцев.
Как в старом анекдоте:

Как выглядит программа на языке высокого уровня 10 поколения?
"Хочу программу с БД и красивым интерфейсом".
Как выглядит отладка программы на языке высокого уровня 10 поколения?
"Хочу программу с БД и красивым интерфесом. И чтоб работало!!!"

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


_>Если из 5-и гигового файла удалить объекты, которые находятся в 1-м гигабайте — тебе как-то придётся сдвигать оставшиеся
_>4 гига, меняя положение/индексы (а не дай бог если они идентификаторы) объектов.

В текущей версии: Нет, не придется. В начале файла образуется дыра с мусором. Этот мусор будет заполнятся по мере создания новых объектов. Если такого создания не будет — дыра в файле так и останется на всегда дырой.

shuklin wrote:
> В текущей версии: Нет, не придется. В начале файла образуется дыра с
> мусором. Этот мусор будет заполнятся по мере создания новых объектов.
> Если такого создания не будет — дыра в файле так и останется на всегда
> дырой.
То есть имеем классическую схему с каталогом страниц?

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

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

СГ>Это как?

Ага, это одно из отличительных свойств моей СУБД — в ODMG вовсе не так.

если коротко

один и тот же персистент экземпляр класса может в разных контекстах идентифицироваться разными Handle. С другой стороны в разных контекстах один и тот же Handle может адресовать разные объекты. В пределах каждого персистент экземпляра контекст свой, отличный от любого другого персистент объекта. В пределах одного экземпляра один handle всегда адресует только один связанный объект. В пределах одного экземпляра несколько разных handle могут адресовать один и тот же связанный объект.

shuklin wrote:
> один и тот же персистент экземпляр класса может в разных контекстах
> идентифицироваться разными Handle.
И что? Ну добавили level of indirection? Что это фундаментально меняет?

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

C>То есть имеем классическую схему с каталогом страниц?

На уровне хранилища — гдето так. Скорее ближе к старому досовкому FAT.

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

>> один и тот же персистент экземпляр класса может в разных контекстах
>> идентифицироваться разными Handle.
C>И что? Ну добавили level of indirection? Что это фундаментально меняет?

Появляетс возможность строить объектные JOINs & aggregates.

типа WHERE ИД_ОБЪЕКТА(объект1)==ИД_СВЯЗИ(связь3)

shuklin wrote:
>> > один и тот же персистент экземпляр класса может в разных контекстах
>> > идентифицироваться разными Handle.
> C>И что? Ну добавили level of indirection? Что это фундаментально меняет?
> Появляетс возможность строить объектные JOINs & aggregates.
> типа WHERE ИД_ОБЪЕКТА(объект1)==ИД_СВЯЗИ(связь3)
Тогда теряем возможность O(1) изменений объектов и скатываемся к случаю
с РБД

Рукомендую почитать про CODASYL — там на это все уже в 70-х годах
натыкались.

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

C>Тогда теряем возможность O(1) изменений объектов и скатываемся к случаю
C>с РБД

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

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

AVC>Вот самый простой пример.
AVC>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.
AVC>И что?
AVC>А в vi все просто: yy999p

Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
А в достаточно популярном донельзя гуевом MS Word достаточно: ALT-F11, двойной клик на This Document и выполнить (F5) следующее:

Sub test()

    For i = 0 To 1000
       Call ActiveDocument.Range.InsertParagraphBefore
       Call ActiveDocument.Range.InsertBefore("Этот текст появится очень много раз")
    Next
  
End Sub

Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.

З.Ы. По роду занятий я не VB программист и никогда им не был