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 [ 13.62 КБ | Просмотров: 12848 ] Наверное, могут быть и вариации - можно сделать максимально компактным "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: Свежий язык программирования :) |
... С другой стороны... Какая к фигам будет разница при терабайтных адресных пространствах даже для встроенных систем и даже в самом ближайшем будущем? Здесь как раз те из фирм, что закладываются на долгосрочные перспективы а ля Композиты или (как есмертек) помещают ОЧЕНЬ серьёзные ПОДХОДЫ в ядра своих систем - оказываются значительно в выигрыше по сравнению с подходоми "едим гречку вилкой с одним зубом!"... |
Автор: | Рэйлвэй Каген [ Понедельник, 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/ |