Ответ на »сообщение 2470« (Сергей Губанов)
___________________________
Подсчитайте, например, такое число: в Москве каждые сутки совершается примерно 100'000'000 записей (CDR) о телефонных звонках. Какова примерно будет структура данных хранящая CDR-ы за последние 3 месяца?
Дело не в объёмах а в проектировании архитектуры их обработки. Для биллинга ваши числа и на фиг не нужны после учёта в центральной БД соответствующих полей из CDR-ов и истечения отчётного периода (при условии его закрытия). А само внесение (копирование) нужных фрагментв из CDR-ов ну никак не требует скачки всех их из всех узлов сети единовременно и "единоместно". Даже взаимопроверка (на полноту и непротиворечивость) может быть проведена уже силами самой СУБД. Да и сам процесс внесения новых данных в БД биллинговой системы ОЧЕНЬ ресурсо- и вычеслительно - ёмкий и всегда и везде для его выполнения выделяется несколько дней непрерывной обработки CDR-ов... (без отвлечения на "прочие мелочи") И занимаются этим далеко не "стандартные писюки"...

Ответ на »сообщение 2464« (Сергей Губанов)
___________________________

Ответ на »сообщение 2463« (AVC)
Вобщем, подробности такие:
2) Отдельной проблемой является невозвращение освободившейся памяти BlackBox-ом обратно в операционную систему. Правда это проблема не для BlackBox-а, а для остальных программ Windows. BlackBox-су-то это как раз хорошо.

Замечу, что ядро поддерживает два режима - с VirtualAlloc без возвращения и c AllocHeap с возвращением. Текущая версия ядра выбирает первый режим, если работает в составе EXE-файла, и второй режим, если обнаруживает, что загружена как DLL, что, в общем-то, вполне логично. Однако второй режим работает медленнее.
В принципе, при необходимости можно легко переделать соотв. блок ядра под любой другой сценарий - там все прекрасно разнесено по процедурам, изменение логики захвата страниц никак не повлияет ни на непосредственно диспетчер кучи, ни на сборщик.
В ActiveBlackBox я не стал ничего переделывать, т.к. не был уверен, какой сценарий лучше - здесь та же история, что и со сборщиком мусора с поколениями и без.
Замечу, что введение в сборщик мусора поколений требует поддержки на этапе компиляции - при каждом присваивании указателей необходимо выполнять определенные проверки (подробнее см. Рихтера "Программирование под .NET").
Есть идея, альтернативная поколениям: http://forum.oberoncore.ru/viewtopic.php?p=2751#2751, однако насколько она будет эффективной, судить трудно, надо вводить и пробовать.

Ответ на »сообщение 2464« (Сергей Губанов)
___________________________

Сергей, спасибо!
Теперь я лучше вспомнил ту дискуссию и чувствую себя несколько увереннее.
Мысль в целом такая: если есть такие "скользкие" места, то с ними надо что-то делать.
А что именно, можно обсудить здесь или (в случае специфичности для КП) -- на орловском форуме.
Можно модифицировать Kernel, можно иметь разные Kernel "на выбор", можно сделать сборщик мусора инсталлируемым (наподобие ББ-директорий), можно просто написать в документации: ты туда не ходи, ты сюда ходи...
Вариантов много, не стоит только оставлять так, как есть.

Ответ на »сообщение 2470« (Сергей Губанов)
___________________________
Подсчитайте, например, такое число: в Москве каждые сутки совершается примерно 100'000'000 записей (CDR) о телефонных звонках. Какова примерно будет структура данных хранящая CDR-ы за последние 3 месяца?
Так, вы что, Сергей, все CDR-ы сначала в "одну кучу сваливаете" со всех узлов, где их регистрация производилась? Орррригинально!

Ответ на »сообщение 2469« (Сергей Губанов)
___________________________
...может отличаться...
По-моему, вы ошибаетесь. Откорректированный фрагмент должен выглядеть так:
...не должно отличаться...

Ответ на »сообщение 2465« (info21)
___________________________

Спасибо за статью!
Для меня floating-point по прежнему "больная" тема, хотя и не относящаяся напрямую к Оберону.

Ответ на »сообщение 2468« ()

Хорошая шутка!
То мы всю дорогу мусолим мысль, что нужно освободить прикладника от необходимости помнить о низкоуровневых механизмах обеспечени и поддержки выполнения, а то - фдрук - "назад в пещеры!"?

Анонимы не знают о существовании задач требующих обработки мультигигабайтных структур?
Кстати, файл подкачки не может быть больше размера виртуального пространства (4 гигабайта).

Подсчитайте, например, такое число: в Москве каждые сутки совершается примерно 100'000'000 записей (CDR) о телефонных звонках. Какова примерно будет структура данных хранящая CDR-ы за последние 3 месяца?

Ответ на »сообщение 2466« (Jack Of Shadows)

И обратно к ручному управлению памяти ?

Да не в том смысле ручное управление...

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

Ответ на »сообщение 2464« (Сергей Губанов)
___________________________
надо установить в Windows размер файла подкачки = 0, вот тогда самостоятельно будешь скидывать на диск временно не нужные структуры данных (Stores).
Хорошая шутка!
То мы всю дорогу мусолим мысль, что нужно освободить прикладника от необходимости помнить о низкоуровневых механизмах обеспечени и поддержки выполнения, а то - фдрук - "назад в пещеры!"?

Ответ на »сообщение 2463« (AVC)
___________________________

На мой взгляд, нам нужен этот форум как нейтральная территория, на которой могут общаться люди с разными представлениями об Обероне.

Возможно, многие проблемы с общением в этой ветке связаны с некоторой размазанностью темы. Центром внимания является Оберон и то, что с ним прямо или косвенно связано. Как я понимаю, существуют, как минимум, два взгляда на Обероны (безотносительно квалификации и опыта): исследователя и практика.

Исследователя скорее интересует, что могут дать для познания программирования не совсем привычные подходы, принятые в Оберонах. Стремление же практика -- разобраться в плюсах и минусах Оберонов, осознать их применимость в конкретных задачах и возможно использовать в своей практической работе.

Путем многочисленных дискуссий, думаю, уже более-менее выяснили, что для подавляющего большинства практиков среди всех Оберонов наибольшую ценность представляет КП/BlackBox. Это отправная точка для практиков и мне представляется, что все вопросы и обсуждения из данной плоскости имеет смысл переносить в форум проекта OberonCore.ru (ранее blackbox.metasystems.ru). Вполне разумно, на мой взгляд, было бы там обсуждать и другие практические вопросы по Oberon System, Bluebottle, Active Oberon, Zonnon.

В среде программистов существует достаточно традиционное деление на системщиков и прикладников: системных и прикладных программистов. Исследователи и практики есть в каждой из этих групп. При этом доминируют наверное все же прикладники-практики. А что же остальные? Как и где учесть их интересы?

Наверное, имеет смысл, выделяя магистральное направление среди Оберонов в лице КП, не забывать о том, что есть такие исследователи и системщики-практики, для кого связка КП/BlackBox много менее интересна. Значит, нужна площадка для обсуждений, где все Обероны были бы равноправны и где основной уклон шел бы в сторону исследований (эдакая публичная исследовательская лаборатория). При этом, разумеется, КП/BlackBox в этом отношении вполне интересный полигон для таких исследований (равно как и КП/Eclipse).

Оберон относится к так называемым языкам-ОС, т.е. языкам, которые плавно перетекают в ОС (а не просто являются языками реализации ОС). Это справедливо и по отношению к его потомкам: Оберон-2, КП, Active Oberon, Zonnon.

Здесь есть два полюса: Оберон как язык-"микроядро" (Си, Forth, Occam) и Zonnon как язык-"монстр" разряда Algol-68, PL/I, C++. Этот феномен уже сам по себе достоин изучения и обсуждения.

Если говорить об особенности Оберонов, их ключевых отличиях от других языков, то все Обероны роднит одно: европейские традиции программирования, принятие модуля в качестве основной строительной единицы (в противовес классам) и расширяющее программирование (как главная стратегическая линия). Все остальное, в общем-то, детали.

Оберон (классический) не фиксирует объектную модель, позволяя реализовывать самые разные "очень ОО" и "не очень ОО" схемы. КП "морозит" объектную модель (конкретизирует микроядро Оберона), что позволяет получать более практичный инструмент для прикладников-практиков. Но платит за это усложнением языка и потерей гибкости микроядра.

Оберон-2 тоже не стоит забывать: как бы давно ни была сделана система XDS, она остается сильным инструментом для системщиков: там реализована практичная связка Modula-2/Oberon-2 и органичная миграция в Си. Да и для тех, кто хочет тесно интегрировать Обероны с остальным мэйнстрим-миром "большой политики", XDS-среда достаточно интересна.

Active Oberon остается наиболее активной точкой роста в исследованиях, которые проводятся в ETH (даже по сравнению с Zonnon). Замечательно, что эти решения с творческим переосмыслением переносятся на почву других Оберонов. Есть, что обсуждать и что пробовать.

Если такое сужение необъятного поля "Дум об Обероне" представляет интерес для высокого собрания и будет принято, то это существенно облегчит работу модераторам и возможно снизит процент брака дискуссий.