Это здорово, но почему тогда до сих пор нет подобных симуляторов?
Такие симуляторы называются пакетами для конечно-элементного анализа: Ansys, DYNA, Nastran… Они не особенно заточены под конкретную отрасль, так что применение — отдельная научно-прикладная задача.
И основная проблема — иная, чем недостаточность матмоделей физики упругих тел. Моделей уже понапридумано на все случаи жизни (ну, почти). Как и методов их решения, как и реализаций этих методов… Проблема в том что каждая модель — это все же только идеализация, со своими границами применимости. И останется ли данная симуляция в этих границах — ни заранее не известно, ни по результатам нельзя однозначно судить.
Поэтому методику моделирования подбирают к явлению, и этап такого подбора — не формализуется, требует здравого смысла, конструкторской сметки и т.п. Отсюда специализация «инженер-конструктор-рассчетчик». Реалистично обсчитать даже отдельный узел — примерно задача на уровне дипломного проекта, выработать методику — на уровне кандидатской.
Например, о BMW слышал: моделированием поведения при аварии рулевой колонки занимается отдельный человек. Короче, на стыке науки и искусства :)
Теория оболочек описывает такие конструкции (штампованые детали кузова, покрышки под давлением). Решение — методом конечных элементов (МКЭ). На 34-й секунде можно заметить прямолинейные участки вмятины.
Для таких явлений (неустойчивость оболочки при смятии, остаточные деформации), нужен МКЭ в нелинейной постановке. И еще «контактную задачу» придется решать, чтоб условия нагружения выяснить смотря по поведению упругого тела.
Тут есть подробный отчет (на английском) о рассчетном коде для объемных упругих тел с аналогичными целями разработки: физическая достоверность, реалтайм. И эти авторы на GPU закладывались сразу, в отличие от разработчиков сабжа.
Емнип, ошибка не только на порядок, но и, с другой стороны, вдвое: частота сэмплирования = частота полезного сигнала * 2. То есть, два с половиной кадра в секунду будет мало, а пять — уже хватит.
Явный призыв не обязателен. А хотя бы упоминание альтернатив не помешало бы. Иначе выходит, исходя из материала статьи, что недостатки thread-based подхода нужно преодолевать искусным использованием структур данных и средств синхронизации, доступных в рамках все той же shared-memory модели. И что в результате мы получим некий улучшенный подход, «потоки с очередями», как вы их называете. А это заблуждение. В результате получили кардинально иную «модель параллельного программирования, основанную на передаче сообщений» — со всеми ее подводными камнями навроде латентности, СМО и прочей фундаментальщиной.
Плавность перехода от одной модели параллельного программирования к кардинально иной — при том, что понятие «модель параллельного программирования» явно никак не фигурирует, а обсуждаются только частные подходы в рамках этих моделей — вводит в заблуждение касательно уровня сложности и общности задач, которые могут возникнуть (и неизбежно возникнут) при реализации. Статья хорошая, ключевые идеи в важной области наглядно проиллюстрированы. Однако предлагать такую иллюстрацию кроме как для освоения идей еще и к исполнению на практике, при этом не упоминая наличествующих альтернатив — значит заблуждаться (и, соответственно, вводить в заблуждение) относительно теперешнего уровня развития направления.
К счастью, это легко поправить (например, если возьметесь за следующую статью). Если подать именно как иллюстрацию к принципам message passing модели и путям работы библиотек, которые ее реализуют. А не как изобретение, выстраданное из практики. Даже если именно так ваш код и родился (охотно верю и не имею ничего против). Но поймите и читателя, попытайтесь взглянуть глазами рядового прикладника: и так технологий, как грибов после дождя, и тут снова предлагают ознакомиться с чем-то «yet another ...» в духе «roll your own». Еще раз, спасибо за статью.
Солидный опыт применения, безусловно, заслуживает уважения. Критикую только потому что насторожило вот это:
свою [реализацию очереди] «допиливал» примерно полгода
А также что, судя по всему, собираетесь сподвигнуть желающих на подобные же свершения — следующей статьей «о проектировании программ через конвейерные потоки». Конечно, если пойдет речь о применении какой-то из стандартных систем и соответствующих (этой системе!) тонкостях проектирования, тогда все вопросы снимаются.
А если просто с позиций «с мьютексами трудно отлаживать, давайте мастерить очереди», то это будет вводить в заблуждение, при всей справедливости исходной посылки. Никто не спорит, ручная синхронизация потоков через объекты в большой части случаев вообще худшее из всех возможных решений. Но из этого следует лишь, что в каждом случае нужно выбирать и модель параллелизма, и конкретный подход с инструментарием соответственно задаче. Благо, в наши дни есть из чего выбирать! Вот об этом и было бы интереснее всего почитать, пусть даже ограничиваясь подходами в пределах модели message passing. Например, с точки зрения практики использования соответствующего инструментария. И затрагивать СМО при этом ни в коей мере не обязательно.
Соглашусь по поводу ценности статьи: ставите на повестку очень актуальный подход, и чем дальше, тем он будет актуальнее (глядя на тенденции в «железе»). Но подавая его как просто альтернативу thread-based, позволяющую «избавиться от объектов синхронизации», параллельно вводите в заблуждение ту целевую аудиторию, которую сами очертили. (Уж простите за каламбур.) Потому что изначальный выбор стоит не между объектами и очередями, а между shared memory (где есть thread-based, OpenMP и еще много разного) и message passing (где есть MPI, IntelTBB, Cuncurrency Runtime и еще, кстати, ваш подход). И если уж ставить на повестку message passing как модель, то в части подходов уж во всяком случае нельзя ограничиться самодельным CallbackThread и к нему причитающимся. «Люди имеют право знать!» (с)
Насколько понял вашу задумку, речь идет о еще одной реализации модели параллельного программирования на основе message passing. Потому многие и вспоминают им известные реализации из числа стандартных. Tо есть, уже существующих и во всех смыслах поддерживаемых.
Поскольку вы не изобрели модель message passing, а просто пишете еще одну реализацию «по мотивам» другой реализации одной из разновидностей этой модели (communicating sequential processes в Эрланг), постольку выглядит слегка странным рекламирование преимуществ, получаемых по сравнению со «thread-based» програмированием (которое есть разновидность модели на основе shared memory). Говорю, «выглядит странным», потому что то лишь, что ваш «message passing» выполнен посредством доступных на вашей платформе «thread based» механизмов, поводом к сравнению не является.
Если сможете сравнить то что получилось у вас с другими реализациями той же модели, вот тогда и прояснится, стоит ли игра свечь, и меньше будет упреков по поводу велосипедостроения. (Все мы, по сути, только велосипеды и делаем… Просто когда это оправдано, никто не замечает.) На всякий случай, сегодняшний стандарт де факто в части реализации «message passing» параллелизма для C/C++ и не только — это MPI. Логичнее было бы начать именно с этого и продолжить в духе патентной формулировки: а мой «каспийский монстр» отличается тем, что…
Да, в org-mode есть все и даже больше — спасибо. Насколько понял, там мощный упор на дерево-outline, и тогда достаточно одного файла… А если все же документов несколько, как можно будет перемещаться по «списку открытых»?
Лично за собой заметил, что когда «ни одна запись не пропадет» — это больше чем просто греет, это делает меня чувствительнее к переменам во внешних обстоятельствах. Снижается порог сопротивления к тому чтоб изменить или отвергнуть что-то из того, на что когда-то себя «подписал».
Поясню через аналогию. Толк в составлении подробного плана на квартал — тот же, что и в написании спецификации на продукт, который будет в разработке три месяца.
Понимаю, что для сторонников agile такой аргумент — неубедительный. Ок, мы разные.
Не знаю, наверное — можно. И веб сервер нужно для этого поднимать? (Если я что-то в чем-то понимаю.) Если так, то с mediawiki получается слегка чуть более тяжеловесно, имхо. Но если юзается уже, скажем, редмайн — то согласен, держать все в формате онлайн попродвинутее будет.
"… набор из полудюжины-десятка документов (причем, у каждого он свой!)"
На сроки, которые не актуальны, можно просто не создавать документы — скрипты подхватят правильно, список документов нигде не прописан и не «забюрократизирован». Что писать внутри каждого файла — тоже решает каждый для себя.
Сам я на сегодняшний день, например, на десять лет и на квартал цели пишу, а на 18 месяцев — нет. Так что облегчать себе жизнь — можно. Но вы верно подметили: планирование — тяжкий труд. Здесь, например, сказано: составить подробный план на квартал занимает 10-15 часов и десяток страниц в результате. (Справедливости ради, это — для человека семейного и делового.)
Такие симуляторы называются пакетами для конечно-элементного анализа: Ansys, DYNA, Nastran… Они не особенно заточены под конкретную отрасль, так что применение — отдельная научно-прикладная задача.
И основная проблема — иная, чем недостаточность матмоделей физики упругих тел. Моделей уже понапридумано на все случаи жизни (ну, почти). Как и методов их решения, как и реализаций этих методов… Проблема в том что каждая модель — это все же только идеализация, со своими границами применимости. И останется ли данная симуляция в этих границах — ни заранее не известно, ни по результатам нельзя однозначно судить.
Поэтому методику моделирования подбирают к явлению, и этап такого подбора — не формализуется, требует здравого смысла, конструкторской сметки и т.п. Отсюда специализация «инженер-конструктор-рассчетчик». Реалистично обсчитать даже отдельный узел — примерно задача на уровне дипломного проекта, выработать методику — на уровне кандидатской.
Например, о BMW слышал: моделированием поведения при аварии рулевой колонки занимается отдельный человек. Короче, на стыке науки и искусства :)
Для таких явлений (неустойчивость оболочки при смятии, остаточные деформации), нужен МКЭ в нелинейной постановке. И еще «контактную задачу» придется решать, чтоб условия нагружения выяснить смотря по поведению упругого тела.
Тут есть подробный отчет (на английском) о рассчетном коде для объемных упругих тел с аналогичными целями разработки: физическая достоверность, реалтайм. И эти авторы на GPU закладывались сразу, в отличие от разработчиков сабжа.
Плавность перехода от одной модели параллельного программирования к кардинально иной — при том, что понятие «модель параллельного программирования» явно никак не фигурирует, а обсуждаются только частные подходы в рамках этих моделей — вводит в заблуждение касательно уровня сложности и общности задач, которые могут возникнуть (и неизбежно возникнут) при реализации. Статья хорошая, ключевые идеи в важной области наглядно проиллюстрированы. Однако предлагать такую иллюстрацию кроме как для освоения идей еще и к исполнению на практике, при этом не упоминая наличествующих альтернатив — значит заблуждаться (и, соответственно, вводить в заблуждение) относительно теперешнего уровня развития направления.
К счастью, это легко поправить (например, если возьметесь за следующую статью). Если подать именно как иллюстрацию к принципам message passing модели и путям работы библиотек, которые ее реализуют. А не как изобретение, выстраданное из практики. Даже если именно так ваш код и родился (охотно верю и не имею ничего против). Но поймите и читателя, попытайтесь взглянуть глазами рядового прикладника: и так технологий, как грибов после дождя, и тут снова предлагают ознакомиться с чем-то «yet another ...» в духе «roll your own». Еще раз, спасибо за статью.
А также что, судя по всему, собираетесь сподвигнуть желающих на подобные же свершения — следующей статьей «о проектировании программ через конвейерные потоки». Конечно, если пойдет речь о применении какой-то из стандартных систем и соответствующих (этой системе!) тонкостях проектирования, тогда все вопросы снимаются.
А если просто с позиций «с мьютексами трудно отлаживать, давайте мастерить очереди», то это будет вводить в заблуждение, при всей справедливости исходной посылки. Никто не спорит, ручная синхронизация потоков через объекты в большой части случаев вообще худшее из всех возможных решений. Но из этого следует лишь, что в каждом случае нужно выбирать и модель параллелизма, и конкретный подход с инструментарием соответственно задаче. Благо, в наши дни есть из чего выбирать! Вот об этом и было бы интереснее всего почитать, пусть даже ограничиваясь подходами в пределах модели message passing. Например, с точки зрения практики использования соответствующего инструментария. И затрагивать СМО при этом ни в коей мере не обязательно.
Соглашусь по поводу ценности статьи: ставите на повестку очень актуальный подход, и чем дальше, тем он будет актуальнее (глядя на тенденции в «железе»). Но подавая его как просто альтернативу thread-based, позволяющую «избавиться от объектов синхронизации», параллельно вводите в заблуждение ту целевую аудиторию, которую сами очертили. (Уж простите за каламбур.) Потому что изначальный выбор стоит не между объектами и очередями, а между shared memory (где есть thread-based, OpenMP и еще много разного) и message passing (где есть MPI, IntelTBB, Cuncurrency Runtime и еще, кстати, ваш подход). И если уж ставить на повестку message passing как модель, то в части подходов уж во всяком случае нельзя ограничиться самодельным CallbackThread и к нему причитающимся. «Люди имеют право знать!» (с)
Поскольку вы не изобрели модель message passing, а просто пишете еще одну реализацию «по мотивам» другой реализации одной из разновидностей этой модели (communicating sequential processes в Эрланг), постольку выглядит слегка странным рекламирование преимуществ, получаемых по сравнению со «thread-based» програмированием (которое есть разновидность модели на основе shared memory). Говорю, «выглядит странным», потому что то лишь, что ваш «message passing» выполнен посредством доступных на вашей платформе «thread based» механизмов, поводом к сравнению не является.
Если сможете сравнить то что получилось у вас с другими реализациями той же модели, вот тогда и прояснится, стоит ли игра свечь, и меньше будет упреков по поводу велосипедостроения. (Все мы, по сути, только велосипеды и делаем… Просто когда это оправдано, никто не замечает.) На всякий случай, сегодняшний стандарт де факто в части реализации «message passing» параллелизма для C/C++ и не только — это MPI. Логичнее было бы начать именно с этого и продолжить в духе патентной формулировки: а мой «каспийский монстр» отличается тем, что…
За идеи альтернативных инструментов — спасибо!
Понимаю, что для сторонников agile такой аргумент — неубедительный. Ок, мы разные.
На сроки, которые не актуальны, можно просто не создавать документы — скрипты подхватят правильно, список документов нигде не прописан и не «забюрократизирован». Что писать внутри каждого файла — тоже решает каждый для себя.
Сам я на сегодняшний день, например, на десять лет и на квартал цели пишу, а на 18 месяцев — нет. Так что облегчать себе жизнь — можно. Но вы верно подметили: планирование — тяжкий труд. Здесь, например, сказано: составить подробный план на квартал занимает 10-15 часов и десяток страниц в результате. (Справедливости ради, это — для человека семейного и делового.)