OberonCore
https://forum.oberoncore.ru/

Свежий язык программирования :)
https://forum.oberoncore.ru/viewtopic.php?f=21&t=459
Страница 4 из 4

Автор:  Борис Рюмшин [ Пятница, 04 Июль, 2008 22:53 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Сергей Губанов писал(а):
Всё-таки подробности реализации там не разглашаются.

Меня интересует как конкретно устроен их диспетчер процессов, который может работать с 5'010'000 процессами...

Остаётся только одно: читать исходники рантайма.

Автор:  Александр Ильин [ Понедельник, 07 Июль, 2008 21:42 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Идея мне очень нравится. Интересно, если динамической памяти нет вообще, то как устроена работа с текстовыми строками и прочими динамическими массивами?
Думается мне, что вполне можно соорудить надстройку, которая бы компилировала нечто подобное Composita в исходник на Oberon'е, после чего специализированный рантайм был бы не нужен. Естественно, я говорю об однопоточной версии, мне просто нравится идея стыковки компонентов и интерфейсов.

Автор:  Илья Ермаков [ Понедельник, 07 Июль, 2008 22:05 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Динамическое выделение памяти есть. Указателей нет :-)

Ассоциативные разрежённые массивы.
Глобали, как в СУБД Cache (и древнем её предшественнике MUMPS).

Автор:  Сергей Губанов [ Вторник, 08 Июль, 2008 10:11 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Как я понял, там компонентные переменные ссылочные, но их значения нельзя присваивать друг другу как это обычно делается с указателями. Значения переменных можно либо перемещать (MOVE), тогда старая переменная становится "пустой", или же можно делать копию. Таким образом получается, что у любого компонента всегда есть только один владелец. Поэтому сборщик мусора становится не нужен: удаление агрегата = удаление всех его компонентов.

Автор:  Илья Ермаков [ Вторник, 08 Июль, 2008 10:25 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Да, именно так.

А динамические структуры (графы связей) делаются через ассоциативные индексы. Своего рода KEYs, как в реляционных базах. :-)

Автор:  Рэйлвэй Каген [ Воскресенье, 26 Октябрь, 2008 12:46 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Цифирь, которой не было у Блейзера в абстракте( http://www.isp.uni-luebeck.de/kps07/fil ... laeser.pdf ), но в основной работе( http://e-collection.ethbib.ethz.ch/view/eth:30090 с.182) присутствует:

Table 7-1. Zurich simulation, runtimes in minutes, one processor (in minutes)
Zurich traffic simulation-----------Component-C++-----------C#
----------------------------------------system----(sequential)--(concurrent)
1,000 cars------------------------------0.03------140-----------19
10,000 cars-----------------------------0.5-------140-----------out of memory
100,000 cars----------------------------12--------190-----------out of memory
260,000 cars----------------------------67--------210-----------out of memory

Table 7-2. Zurich simulation, runtimes in minutes, six processors (in minutes)
Zurich traffic simulation-----------Component-C++-----------C#
----------------------------------------system----(sequential)--(concurrent)
1,000-cars------------------------------0.04-------140------------33
10,000-cars-----------------------------0.6--------140------------out-of-memory
100,000-cars----------------------------13---------190------------out-of-memory
260,000-cars----------------------------76---------210------------out-of-memory

особо отмечены 3 момента:
1. практически линейная зависимость времени от числа машин для компонентной реализации.
2. классическая реализация сильно зависима от протяжённости маршрута
и максимального времени в пути.
3. потоки в С# реализованы отнюдь не лучшим образом

Но масштабируемость-то у классической реализации(С++) намного лучше - при увеличении количества симулируемых объектов на 2 порядка, время расчёта увеличивается менее чем в 2 раза! В то время как у компонентной системы время расчёта возрастает в 2000 раз. Ежели экстраполировать тенденцию, то для ~600,000 машин получим примерно равное время расчёта. Далее компонентная система начнёт проигрывать классической реализации.
Есть предположение, что такое поведение связано с чрезмерной иерархичностью компонентной модели, имеющей мало общего с моделью вычислителя. Избавившись от сборщика мусора(и потерь времени на него) за счёт жёсткой иерархии объектов, похоже уткнулись в реальную модель вычислителя. В кеш процессора хорошо ложатся повторно используемые объекты, а в реализации на Композите их слишком мало.
Кто, что думает?

Автор:  Илья Ермаков [ Воскресенье, 26 Октябрь, 2008 15:59 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Возможно, просто доработать модель? Может, в ней есть некий кусок, который даёт нелинейный рост? Сомневаюсь сильно, что нелинейность может давать "механика" системы, ибо обычно оверхед выражается неким постоянным множителем....

Автор:  Info21 [ Воскресенье, 26 Октябрь, 2008 17:58 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Рэйлвэй Каген писал(а):
Но масштабируемость-то у классической реализации(С++) намного лучше - при увеличении количества симулируемых объектов на 2 порядка, время расчёта увеличивается менее чем в 2 раза!
В то время как у компонентной системы время расчёта возрастает в 2000 раз.

Видна ведь сильная нелинейность -- так экстраполировать нельзя.

Автор:  Рэйлвэй Каген [ Понедельник, 27 Октябрь, 2008 10:05 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Согласен, оценка до неприличия грубая.
Предлагаю не зацикливаться на ней, а проанализировать темпы прироста времени выполнения в зависимости от числа симулируемых машин.
Судя по упрощенному описанию( http://e-collection.ethbib.ethz.ch/view/eth:30090 с.186),
Вложение:
7-5.png
7-5.png [ 13.62 КБ | Просмотров: 12848 ]
в компонентной системе есть набор маршрутов - компоненты "road link"(фиксированное число), а для каждой машины выполняется "car driving process" и эти сущности обмениваются сообщениями. По идее, все "car driving process" идентичны с точки зрения исполняемого кода, но в концепции Композиты каждый "car driving process" должен иметь единственного владельца(скорее всего это компонент "car"). Вот собственно и предположение, что реализация компонентной системы содержит кучу идентичного кода, который, начиная с некоторого количества экземпляров, перестаёт помещаться в кеше(м.б. 1000 машин уже не помещается). Возможно, это и будет причиной практически линейной зависимости времени от числа симулируемых машин.
Наверное, могут быть и вариации - можно сделать максимально компактным "car driving process" и заставить его общаться с некими "driving calculator"(содержащими наиболее массивную часть кода), которых в системе может быть (хотя бы) по числу процессоров. Может быть и в этом случае возможно "рандеву" с классической реализацией при одинаковом времени расчёта для определённого количества машин?
Думаю да, возможно. В предельном случае посылка сообщения и ожидание результата обработки(тоже в виде сообщения) медленнее синхронного вызова процедуры.
Получается готовое техническое противоречие(для поклонников ТРИЗ) - компонентная модель легче для понимания и проектирования(с некоторыми оговорками - см. p.s.), плюс даёт дополнительные возможности во время исполнения, но некоторые её части желательно иметь в "классическом" понимании(особенно для исключения бестолкового дублирования исполняемого кода). Последнее было бы прямо показано для встроенных систем и систем, масштабируемых в исключительно высокой степени.
Тот же Keil(компилятор С для встроенных систем) легко находит повторяющийся код и выносит его в отдельную подпрограмму при задании соответствующего уровня оптимизации. Но одного этого мало. Такая оптимизация в компонентной среде легко поставит крест на расширяемости системы. Иначе получается, что детали аппаратной реализации(наличие кеша у процессора) опять пролезают в высокоуровневые модели(см.вариации).

Надеюсь на критику.

p.s.: Оговорка пока будет одна - не все системы представимы в виде иерархического набора компонент(вроде как уже обсуждалось на форуме).

Автор:  Info21 [ Понедельник, 27 Октябрь, 2008 15:16 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

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

Звучит странно. Не знаю. Композиту не защищаю.

Автор:  Wlad [ Понедельник, 27 Октябрь, 2008 15:49 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Рэйлвэй Каген писал(а):
По идее, все "car driving process" идентичны с точки зрения исполняемого кода, но в концепции Композиты каждый "car driving process" должен иметь единственного владельца(скорее всего это компонент "car"). Вот собственно и предположение, что реализация компонентной системы содержит кучу идентичного кода,

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

Автор:  Wlad [ Понедельник, 27 Октябрь, 2008 15:55 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

... С другой стороны...
Какая к фигам будет разница при терабайтных адресных пространствах даже для встроенных систем и даже в самом ближайшем будущем? :twisted:
Здесь как раз те из фирм, что закладываются на долгосрочные перспективы а ля Композиты или (как есмертек) помещают ОЧЕНЬ серьёзные ПОДХОДЫ в ядра своих систем - оказываются значительно в выигрыше по сравнению с подходоми "едим гречку вилкой с одним зубом!"...

Автор:  Рэйлвэй Каген [ Понедельник, 27 Октябрь, 2008 20:42 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Не, ну если так рассуждать, то всё вообще-то упрётся в размер батарейки :)

Автор:  Wlad [ Понедельник, 27 Октябрь, 2008 22:52 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Рэйлвэй Каген писал(а):
Не, ну если так рассуждать, то всё вообще-то упрётся в размер батарейки :)

Ну и что?
Именно!
Но остаётся пара "моментикофф": размер памяти (флэш+озу) - есть показатель потенциала предоставляемой функциональности.
А вот борьбу за ЭФФЕКТИВНОСТЬ алгоритмов никто не отменял! Лафа 90-х с увеличением герц тактовой частоты теперь будет вспоминаться аки "золотая эра"... Всё! Сливайте воду! Сушите вёслы! Памяти-то мы теперь размещаем всё больше на кристалле, да вот теперь надо задуматься, что там общёлкивает наши терабайты, на каких принципах, на каких архитектурах, с какими принципами построения...
ВОн уже первые звоночки и от Мура с его СИФортом и Tilera64...

Автор:  Илья Ермаков [ Пятница, 21 Ноябрь, 2008 00:47 ]
Заголовок сообщения:  Re: Свежий язык программирования :)

Кстати, дисер Блейзера написан очень хорошим и прозрачным английским. Через некоторое время чтения я вообще вдруг забыл, что это английский и с удивлением вдруг это вновь обнаружил )) Хотя уж давно обильно не читал...

Автор:  albobin [ Пятница, 13 Сентябрь, 2013 15:19 ]
Заголовок сообщения:  Composita, новое пристанище.

http://concurrency.ch/Projects/Composita

Страница 4 из 4 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/