OberonCore
https://forum.oberoncore.ru/

День Оберона в Москве (2015)
https://forum.oberoncore.ru/viewtopic.php?f=155&t=5438
Страница 5 из 6

Автор:  Иван Денисов [ Вторник, 29 Сентябрь, 2015 11:31 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Валерий Лаптев писал(а):
а) OpenMP - она практически везде работает.

MPICH2 лучше, чем OpenMP, читайте например тут: https://www.cacr.caltech.edu/pipermail/ ... 00387.html
Высокоуровневая обвязка для MPICH2 сделана, жду от Ильи его Files, проверю как они вместе работают и выложу. В чем проблема с обычным Files? Наиболее универсальный способ обмена сообщений в MPI стандарте это байты, а чтобы структуры ББ в байты паковать, удобно использовать модуль Stores и Files для выгрузки байтовых структур во временный файл, а затем оттуда байты передаем в функцию MPICH2 Isend для отправки другим процессам. Маленькие файлы точно буферизуются в ОС, поэтому диск не трогают, но как только будут структуры больше 8-16кб, зависит от настроек ОС, то жесткий диск убьет всю производительность. Поэтому для MPICH2 надо использовать реализацию Files в RAM.

Автор:  Иван Денисов [ Вторник, 29 Сентябрь, 2015 11:39 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Это я про MPICH2 все к чему клоню. Параллельность легко реализуется в ББ с помощью дополнительного компонента и одной сторонней библиотеки libmpich, и без этой библиотеки тоже можно обойтись, используя общую память или обмен по TCP. Поэтому ничего в ядре ББ и тем более Компонентном Паскале менять не нужно! Предлагаю лучше допилить мою подсистему Robust. Она может быть расширена разными реализациями параллельности, сейчас драйвером (реализацией) является модуль RobustParallelMpich.

Вложения:
Robust.7z [39.51 КБ]
Скачиваний: 656

Автор:  Пётр Кушнир [ Вторник, 29 Сентябрь, 2015 12:58 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Почему бы не использовать опубликованный компонент для файлов в памяти - ypkDataBlob? https://bitbucket.org/oberoncore/ypk/sr ... at=default файлы в неконтролируемой памяти, переиспользование кусков, абстрактный интерфейс, пример использования.

Автор:  Kemet [ Вторник, 29 Сентябрь, 2015 12:59 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Александр Ильин писал(а):
С существенным отрывом победило значение "1". То есть, последовательная компиляция без всякого параллелизма.

Что-то странное у вас творится, ибо у всех моих знакомых при многопоточной компиляции в студии наа многопроцессорной/многоядероной системе наблюдается заметное увеличение скорости компиляции солюшена с несколькими проектами или с опцией /MP для одиночного проекта. Но, самое главное, нагрузка заметно падает, т.е. если при компиляции в один поток часто всё встает колом, то при многопоточной компиляции/сборке отзывчивость системы практически не изменяется.

Автор:  Валерий Лаптев [ Вторник, 29 Сентябрь, 2015 21:06 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

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

Вы не поняли.
Просто надо параллельно запустить компиляцию разных модулей транслируемой программы на разных ядрах.
Не нужно выявлять никаких зависимостей.
Просто разные модули, входящие в один проект, компилировать параллельно на разных ядрах.
То есть просто запускать несколько копий компилятора на разных ядрах.

Автор:  Александр Ильин [ Вторник, 29 Сентябрь, 2015 22:34 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

kemiisto писал(а):
Ну, это ведь от объёма кода зависит. Понятно, что если есть десяток модулей, то параллелить действительно особо нечего, но на больших объёмах кода будет существенный выигрыш от параллельной компиляции нескольких (независимых) модулей. Возьмите для примера что-то величиной хотя бы с Qt и соберите с make и make -jX (где X обычно выбирают примерно равным числу ядер) и увидите, что смысл есть.
Именно об этом я писал, приводя в пример наш солюшен со 100 проектами. Многие проекты могут компилироваться параллельно после того, как соберутся общие библиотеки. Но потом всё упирается в жёсткий диск и задержки на поиск-чтение-запись файлов.

Автор:  Александр Ильин [ Вторник, 29 Сентябрь, 2015 22:36 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Kemet писал(а):
Александр Ильин писал(а):
С существенным отрывом победило значение "1". То есть, последовательная компиляция без всякого параллелизма.
Что-то странное у вас творится, ибо у всех моих знакомых при многопоточной компиляции в студии наа многопроцессорной/многоядероной системе наблюдается заметное увеличение скорости компиляции солюшена с несколькими проектами или с опцией /MP для одиночного проекта. Но, самое главное, нагрузка заметно падает, т.е. если при компиляции в один поток часто всё встает колом, то при многопоточной компиляции/сборке отзывчивость системы практически не изменяется.
Не знаю, могу завтра ещё проэкспериментировать, привести цифры.
С последним предложением непонятно. Если компилируется параллельно больше проектов, то система менее нагружена получается? Это у вас что-то странное творится : ))

Автор:  Иван Денисов [ Среда, 30 Сентябрь, 2015 06:04 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Пётр Кушнир писал(а):
Почему бы не использовать опубликованный компонент для файлов в памяти - ypkDataBlob? https://bitbucket.org/oberoncore/ypk/sr ... at=default файлы в неконтролируемой памяти, переиспользование кусков, абстрактный интерфейс, пример использования.

Спасибо, Пётр, не знал про него. Попробую.

Автор:  Kemet [ Среда, 30 Сентябрь, 2015 06:43 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Александр Ильин писал(а):
[
С последним предложением непонятно. Если компилируется параллельно больше проектов, то система менее нагружена получается? Это у вас что-то странное творится : ))

У меня как раз ничего не творится, это у Майкрософт что-то творится ), ибо я Студию использую эпизодически да и то, больше для навигации по проектам.
Я просто "озвучил" мнение моих знакомых, активно использующих это чудо мысли в своей работе на больших проектах.

Автор:  Илья Ермаков [ Суббота, 03 Октябрь, 2015 19:47 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Выложил свои Files в памяти: viewtopic.php?f=47&t=5511

Автор:  Kemet [ Воскресенье, 04 Октябрь, 2015 16:09 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

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

Автор:  Иван Денисов [ Суббота, 10 Октябрь, 2015 22:00 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Рассказ Бориса Валерьевича про историю OberonCore:
https://youtu.be/ISJHiwAfd7Y

Автор:  Роман М. [ Воскресенье, 13 Декабрь, 2015 00:13 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Иван Денисов писал(а):
Добавил в плейлист доклад Дмитрия Викторовича Дагаева: «Использование Active Oberon для разработки ПО реального времени»
http://www.youtube.com/watch?v=ttqHBNt9DZc

Спасибо за видео, Иван. А где можно скачать презентацию по данному докладу?

P.S.
Было бы прекрасно если все презентации по Оберону в будущем выкладывались на SlideShare.

Автор:  Дмитрий Дагаев [ Четверг, 17 Декабрь, 2015 10:20 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Роман М. писал(а):
Иван Денисов писал(а):
Добавил в плейлист доклад Дмитрия Викторовича Дагаева: «Использование Active Oberon для разработки ПО реального времени»
http://www.youtube.com/watch?v=ttqHBNt9DZc

Спасибо за видео, Иван. А где можно скачать презентацию по данному докладу?

P.S.
Было бы прекрасно если все презентации по Оберону в будущем выкладывались на SlideShare.

Презентация по докладу

Вложения:
AO_RT.pdf [529.15 КБ]
Скачиваний: 517

Автор:  ignat99 [ Четверг, 17 Декабрь, 2015 15:40 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

В докладе есть фраза "Надо объяснить людям, которые не понимают".

Люди понимают - система реального времени или индустриальная система, которая прошла полную верификацию или была протестирована сотнями и тысячами тестов на продолжении недель, месяцев а иногда и годов это одна история.

А систему в которую вносили изменения на лету 3 человека без полной инструментализации ядра это другая история (продвинутого профайлера - я например знаю три типа таких профайлеров для Linux - Сансунговский SWAP, Аплевский - NOP, GNU - Valgrind (условно) и совсем не знаю про методы других компаний, которые делают систем RT). Такую систему, пусть даже лучшую чем все остальные вместе взятые (хотя это и не так), вот такую систему нельзя ставить в критически важное место.

По простой причине, у вас более 50 объектов, и ешё больше процессов, каждый процесс имеет кучу состояний и варианты нестандартного использования (когда входные данные не соответствуют ожидаемым) и множество возможностей взаимодействия процессов через мониторы - о чём в докладе упоминалось.

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

Например для автопилота маленького самолёта эта система не годиться, а для контролёра автопилота на парусной яхте с максимальной скоростью 5 узлов и расстоянием до препятствия/берега в 5-10 км годиться вполне несмотря на возможные проблемы из за входных данных.

Автор:  Info21 [ Четверг, 17 Декабрь, 2015 21:21 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

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

Автор:  Пётр Кушнир [ Четверг, 17 Декабрь, 2015 21:33 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

ignat99 писал(а):
К сожалению, колхозный метод не подходит для критически важного оборудования

Кстати, "нормальные" солдаты мейнстрима и программисты руками с вами не согласятся http://eax.me/kolkhoz-doctrine/ По всему выходит, именно вы и есть, так сказать, "колхозник", хотя понятно, что термин с вашей стороны использовался в качестве уничижительного, что невероятно предсказуемо.

P.S. Как дела в вашей ментальной Африке? Всё ещё работаете на госдеп, продаёте белым мбванам церебральных рабов?

Автор:  ignat99 [ Пятница, 18 Декабрь, 2015 00:40 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Пётр Кушнир писал(а):
ignat99 писал(а):
К сожалению, колхозный метод не подходит для критически важного оборудования

Кстати, "нормальные" солдаты мейнстрима и программисты руками с вами не согласятся http://eax.me/kolkhoz-doctrine/ По всему выходит, именно вы и есть, так сказать, "колхозник", хотя понятно, что термин с вашей стороны использовался в качестве уничижительного, что невероятно предсказуемо.

P.S. Как дела в вашей ментальной Африке? Всё ещё работаете на госдеп, продаёте белым мбванам церебральных рабов?


Вы да же видео не внимательно посмотрели, не говоря уже о докладе.
Там были оценки автора своей работы - "как колхозной".

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

Опять же автор доклада в курсе - перевожу его последние замечания для тех кто не понял:

Во время старта (из тех 30) не все модули грузятся одинаково при каждой новой загрузке, что то не подгружается, время загрузки всегда разное.
Далее интервалы отзывов во время работы плавают в диапазоне 4%
Далее, автор в отличии от вас, знает что такое профилировщик и как он работает. А вот что такое инструментализация ядра он уже представляет слабо.

Пересмотрите доклад ещё раз, особенно концовку.

Чтоб не быть голословным - вот порядок загрузки модулей, отсчитайте сверху примерно 50 (потому что у меня нет точного списка выкинутых автором модулей - хотя по названному количеству объектов я могу прикинуть) модулей и получите реальную картину происходящего в докладе (каждая группа соответствует ветви с ответвлениями - дерево загрузки построите сами):

Runtime.Mod
Trace.Mod Unix.Glue.Mod Darwin.I386.Unix.Mod
Unix.I386.Machine.Mod Unix.Heaps.Mod Modules.Mod
Unix.Objects.Mod Unix.Kernel.Mod KernelLog.Mod
Streams.Mod Commands.Mod TrapWriters.Mod
Reflection.Mod Unix.StdIO.Mod Unix.Traps.Mod
Files.Mod Unix.UnixFiles.Mod Loader.Mod
Unix.BootConsole.Mod


Dates.Mod Strings.Mod Plugins.Mod Displays.Mod
XMM.I386.Math.Mod XMM.I386.MathL.Mod UpTime.Mod
Inputs.Mod CRC.Mod SystemVersion.Mod
Unix.ProcessInfo0.Mod ProcessInfo.Mod Options.Mod
SystemTools.Mod Unix.X11.Mod Unix.X11Api.Mod
Unix.XDisplay.Mod Unix.Beep.Mod Unix.KbdMouse.Mod
I386.Network.Mod Unix.IP.Mod Unix.Sockets.Mod
Unix.UDP.Mod Unix.TCP.Mod Unix.DNS.Mod
Unix.V24.Mod Unix.DisplayRefresher.Mod Unix.Clipboard.Mod
Unix.XDisplay.Mod Serials.Mod WindowManager.Mod WMGraphics.Mod

WMRectangles.Mod WMRectangles.Mod Autostart.Mod I386.Raster.Mod

XML.Mod

Inflate.Mod

Texts.Mod
WMEvents.Mod
FP1616.Mod

Archives.Mod
WMDefaultWindows.Mod

WMGraphicUtilities.Mod

WMDefaultFont.Mod

WMFontManager.Mod

PNGDecoder.Mod

Localization.Mod
Repositories.Mod

UnicodeProperties.Mod
TextUtilities.Mod

Types.Mod
Models.Mod
WMProperties.Mod

WMDropTarget.Mod
WMComponents.Mod

SyntaxHighlighter.Mod
WMStandardComponents.Mod
WMPopups.Mod
WMPieMenu.Mod
UnicodeBidirectionality.Mod
PositionDebugging.Mod
ContextualDependency.Mod
UndoManager.Mod
HostClipboard.Mod
WMInputMethods.Mod
WMTextView.Mod

WMEditors.Mod
WMMacros.Mod

WMSearchComponents.Mod
WMDialogs.Mod
WMRestorable.Mod
WMDocumentEditor.Mod
WMUtilities.Mod

WMTrapWriter.Mod
FSTools.Mod
WMTabComponents.Mod
MainMenu.Mod
StartMenu.Mod
SkinLanguage.Mod
SkinEngine.Mod
WMRestorable.Mod
WMNavigate.Mod

WMGrids.Mod
WMStringGrids.Mod
WMRepositories.Mod

Notepad.Mod

И на последок, операционные системы реального времени мы делали в zelax ещё в 2002 году (хотя я это и не афишировал до сих пор в интернетах) и позже я имел дело с несколькими системами для устройств трекинга автомобилей. Поверьте мне на слово, основные циклы RT систем выглядят несколько более лёгкими и иерархия таймеров несколько более развита (это мягко говоря, чем в докладе). Вот такая тут "мягкая" RT система получается :lol:

Поэтому Пётр чем писать в очередной раз, лучше почитайте исходники хорошей RT системы.

Автор:  Борис Рюмшин [ Пятница, 18 Декабрь, 2015 06:38 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Товарищи, вы там тему прочитайте, прежде чем продолжать беседу не по теме.

Автор:  ignat99 [ Пятница, 18 Декабрь, 2015 11:59 ]
Заголовок сообщения:  Re: День Оберона в Москве (2015)

Борис Рюмшин писал(а):
Товарищи, вы там тему прочитайте, прежде чем продолжать беседу не по теме.


Я обсуждаю доклад Дмитрия Викторовича Дагаева и привожу цитаты и обращаю внимания на важные моменты во время обсуждения.
Если бы Дмитрий Викторович имел больше ресурсов/работников (средняя группа в проекте Самсунг около 10 человек, средний бюджет на 6 месяцев - 1 миллион долларов), то было бы возможно выделить группу тестирования (для написания тестов) и группу инструментирования ядра именно тех функций которые наиболее критичные по результатам рассмотрения логов профилировщика.

А так как у Дмитрия Викторовича нет таких ресурсов (судя по докладу), то позвольте усомнится в целесобразности использования прямо сейчас операционной системы A2 для критически важных задач.

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

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

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