А кэш очищался перед каждым прогоном теста?
Если нет — в первом прогоне (или даже в генерации данных) было обращение к памяти, а во втором и следующих прогонах измерялась скорость повторного доступа к кэшу. То есть, не было случайного паттерна доступа и проявлялось ускорение за счёт кэширования (пологие участки на графиках).
Имхо, выигрывает. В funcparserlib нет лишних управляющих структур (for/yield), которые есть в коде из статьи. Это значит, что без этих структур можно обойтись, и следовательно они не нужны.
И что-то мне подсказывает, что по 2 yield'а в каждой функции — не Python-way (это не выглядит просто).
Комбинаторные парсеры (пример выше) выглядят гораздо "изящнее", чем for'ы вместо последовательностей термов. (Если эти for'ы убрать, то и получатся комбинаторные парсеры. А так — "код в стиле барокко").
Рекурсивный спуск выглядит проще (но объёмнее).
И ещё есть всякие генераторы парсеров, которые должны работать быстрее.
Статья хорошо показывает, что парсер с нуля написать несложно, но я бы не рекомендовал использовать конкретно этот подход. Он избыточен и неочевиден.
Весьма странно видеть MPI и OpenMP как замену SIMD. Они не занимаются векторизацией.
OpenMP — это распараллеливание программы между потоками, и оно помогает задействовать совершенно другие возможности процессоров (многоядерность), чем SIMD (широкие АЛУ).
MPI (если речь идёт о Message Passing Interface) — это вообще про обмен сообщениями между процессами в кластере. Я бы не хотел видеть такое в стандарте языка общего назначения.
К слову, OpenMP-подход (т.е. расширение компилятора для поддержки потоков) сейчас слабо распространён в разных языках, хотя удобен для пользователя. Возможно, не очень хорошо/не очень удобно модифицировать компилятор для поддержки многопоточности, а написать библиотеку намного проще.
Чаще предпочтение отдаётся подходу с параллельным коллекциями. Но, как правило, это тоже не векторизация.
В своё время я пытался переупаковать HttpComponents с помощью maven shade и gradle на этапе сборки (не вышло, где-то использовалась рефлексия), а потом я увидел, что авторы HttpComponents (не от хорошей жизни) предоставляют отдельную сборку под android с другими названиями классов. Но этот вариант никак не подходил (я писал библиотеку, зависящую от HttpComponents), и пришлось отказаться от HttpComponents.
Это печально. Надо бы предусмотреть пункт в лицензии библиотек на случай подобного использования.
Google довольно часто руководствуется принципом "здесь и сейчас", игнорируя правила, и через некоторое время пользователи остаются наедине с негибкими решениями.
Навскидку:
Описанная ситуация с нестабильной версией HttpComponents (включить нестабильную библиотеку в ОС, и тем самым запретить её обновления без костылей? серьёзно?)
Ограничение 64К методов в .dex (конечно, этого хватит всем).
Отсутствие generic-ов в go (сойдёт и так, пока вам не понадобятся самописные коллекции).
Отказ от использования исключений в языках, в которых они есть (в их библиотеках на С++ и по инерции на Java).
Нестандартное для Java соглашение об именовании полей (префикс m).
В принципе, этого достаточно, чтобы подходить с осторожностью к использованию их библиотек/технологий.
Размер потребляемых ресурсов: памяти, процессорного времени, используемых ядер, необходимость или отсутствие доп. оборудования.
Если вы не смогли описать в интерфейсе эти параметры, это проблема конкретного случая. Опишите их в документации, если число ядер или время обработки — действительно часть интерфейса. Из невозможности полностью описать интерфейс средствами языка не следует вывод, что LSP неверен.
В пределе Вы не можете изменить свой код сразу после того как поднимите руки над клавиатурой.
Если вы лезете с клавиатурой прямо в продакшен, то да.
А на практике код можно менять как угодно, если вы в состоянии переписать все участки программы/инфраструктуры, на которые влияет изменение, так, чтобы клиенты не пострадали. OCP, если его применять, только минимизирует число изменений других частей.
В статье очень много максимализма, как уже говорилось выше. Эти принципы намного гибче, чем вам кажется. И SOLID действительно помогает поддерживать и развивать огромные системы.
Как я понял, этот?
В идеальном мире с автопилотами, никаких фур на встречке и обочин людей на обочинах автоматических дорог быть не должно. В случае серьёзного сбоя — да, жертв не избежать. Наверное, страдать должны в первую очередь нарушители правил, во вторую — имеющие отношение к транспорту (кто им пользуется, а не просто идёт мимо). Вопрос сложный.
Можно привести примеры безвыходных ситуаций, когда человек вообще ничего не контролирует, но получает вред здоровью (2 автопилота не поделили дорогу; либо 2 бензовоза столкнулись и взрывом зацепило пешеходов за ограждением). Но это сбои систем автопилотирования или недостатки инфраструктуры, которые нужно предотвращать.
Автопилот не должен ничего решать, он должен следовать непротиворечивому закону.
Лучше относиться к автопилотам как к бездумной полностью автоматической системе (или стихии), которая в 100% случаях способствует выживанию своих пассажиров, а разных личностей, нарушивших правила — как получится. Тогда никто в здравом уме не будет лезть под колёса, надеясь, что с ним всё будет в порядке. Сейчас мало кто лезет руками в циркулярную пилу, или шахту лифта, или гуляет по полю в грозу, так как ясно, чем это закончится.
Что делать с людьми, которые по каким-либо причинам себя не контролируют? Максимально затруднить доступ к автоматическим дорогам абсолютно всем, как это сделано с шахтами лифтов (возможно, достаточно забора на высокоскоростных участках и надземных переходов).
Если автопилот решает, а не убить ли ему пассажиров, это может быть использовано для преднамеренных убийств, ключик для принятия «нужных» решений так или иначе найдётся. Я бы не захотел пользоваться таким транспортом. Почему должны погибать пассажиры, если они не нарушали правил и вообще не имели контроля над ситуацией, а не те, кто контролировал ситуацию и правила нарушил?
Насколько я понял из вики, 1 MET — это скорость расхода кислорода в пассивном состоянии. В неделе 7*24*60=10080 минут, значит пассивные затраты были бы равны 10080 MET*мин за неделю. Даже размерность другая. Что-то здесь явно не так.
Это понятно, но в текущей формулировке есть противоречие «руководитель обязан наказать» — «наказывать нельзя». Выходит, что руководитель сам нарушит свой регламент, и по-хорошему должен будет себя наказать, а вдруг он такой «некоторый» человек, что его нельзя,…
п.17 особенно интересно смотрится в чеклисте с логическими «дырами».
Правила должны быть непротиворечивы, иначе принимать их — себе дороже.
> 5. Руководитель обязан наказать подчинённого, если тот нарушил установленные и доведённые до него правила.
> 23. Некоторых людей наказывать нельзя.
Список таких людей должен быть включён в регламенты? Иначе пункты противоречат друг другу.
А кэш очищался перед каждым прогоном теста?
Если нет — в первом прогоне (или даже в генерации данных) было обращение к памяти, а во втором и следующих прогонах измерялась скорость повторного доступа к кэшу. То есть, не было случайного паттерна доступа и проявлялось ускорение за счёт кэширования (пологие участки на графиках).
Да, но do-синтаксис менее многословен и семантически больше подходит.
Имхо, выигрывает. В funcparserlib нет лишних управляющих структур (for/yield), которые есть в коде из статьи. Это значит, что без этих структур можно обойтись, и следовательно они не нужны.
И что-то мне подсказывает, что по 2 yield'а в каждой функции — не Python-way (это не выглядит просто).
Комбинаторные парсеры (пример выше) выглядят гораздо "изящнее", чем for'ы вместо последовательностей термов. (Если эти for'ы убрать, то и получатся комбинаторные парсеры. А так — "код в стиле барокко").
Рекурсивный спуск выглядит проще (но объёмнее).
И ещё есть всякие генераторы парсеров, которые должны работать быстрее.
Статья хорошо показывает, что парсер с нуля написать несложно, но я бы не рекомендовал использовать конкретно этот подход. Он избыточен и неочевиден.
И почему Python 2 ?
Весьма странно видеть MPI и OpenMP как замену SIMD. Они не занимаются векторизацией.
OpenMP — это распараллеливание программы между потоками, и оно помогает задействовать совершенно другие возможности процессоров (многоядерность), чем SIMD (широкие АЛУ).
MPI (если речь идёт о Message Passing Interface) — это вообще про обмен сообщениями между процессами в кластере. Я бы не хотел видеть такое в стандарте языка общего назначения.
К слову, OpenMP-подход (т.е. расширение компилятора для поддержки потоков) сейчас слабо распространён в разных языках, хотя удобен для пользователя. Возможно, не очень хорошо/не очень удобно модифицировать компилятор для поддержки многопоточности, а написать библиотеку намного проще.
Чаще предпочтение отдаётся подходу с параллельным коллекциями. Но, как правило, это тоже не векторизация.
Если фабрика может вернуть nullptr, вызов метода без проверки на nullptr не является "адекватным".
Класслоадер по-хорошему сначала должен искать стандартные классы (которые уже есть у его родителя), а потом — свои.
В своё время я пытался переупаковать HttpComponents с помощью maven shade и gradle на этапе сборки (не вышло, где-то использовалась рефлексия), а потом я увидел, что авторы HttpComponents (не от хорошей жизни) предоставляют отдельную сборку под android с другими названиями классов. Но этот вариант никак не подходил (я писал библиотеку, зависящую от HttpComponents), и пришлось отказаться от HttpComponents.
Это печально. Надо бы предусмотреть пункт в лицензии библиотек на случай подобного использования.
Google довольно часто руководствуется принципом "здесь и сейчас", игнорируя правила, и через некоторое время пользователи остаются наедине с негибкими решениями.
В принципе, этого достаточно, чтобы подходить с осторожностью к использованию их библиотек/технологий.
А почему вы считаете трупами большие, но работающие, развивающиеся и приносящие деньги системы?
Если вы не смогли описать в интерфейсе эти параметры, это проблема конкретного случая. Опишите их в документации, если число ядер или время обработки — действительно часть интерфейса. Из невозможности полностью описать интерфейс средствами языка не следует вывод, что LSP неверен.
Если вы лезете с клавиатурой прямо в продакшен, то да.
А на практике код можно менять как угодно, если вы в состоянии переписать все участки программы/инфраструктуры, на которые влияет изменение, так, чтобы клиенты не пострадали. OCP, если его применять, только минимизирует число изменений других частей.
В статье очень много максимализма, как уже говорилось выше. Эти принципы намного гибче, чем вам кажется. И SOLID действительно помогает поддерживать и развивать огромные системы.
В идеальном мире с автопилотами, никаких фур на встречке и
обочинлюдей на обочинах автоматических дорог быть не должно. В случае серьёзного сбоя — да, жертв не избежать. Наверное, страдать должны в первую очередь нарушители правил, во вторую — имеющие отношение к транспорту (кто им пользуется, а не просто идёт мимо). Вопрос сложный.Можно привести примеры безвыходных ситуаций, когда человек вообще ничего не контролирует, но получает вред здоровью (2 автопилота не поделили дорогу; либо 2 бензовоза столкнулись и взрывом зацепило пешеходов за ограждением). Но это сбои систем автопилотирования или недостатки инфраструктуры, которые нужно предотвращать.
Автопилот не должен ничего решать, он должен следовать непротиворечивому закону.
Лучше относиться к автопилотам как к бездумной полностью автоматической системе (или стихии), которая в 100% случаях способствует выживанию своих пассажиров, а разных личностей, нарушивших правила — как получится. Тогда никто в здравом уме не будет лезть под колёса, надеясь, что с ним всё будет в порядке. Сейчас мало кто лезет руками в циркулярную пилу, или шахту лифта, или гуляет по полю в грозу, так как ясно, чем это закончится.
Что делать с людьми, которые по каким-либо причинам себя не контролируют? Максимально затруднить доступ к автоматическим дорогам абсолютно всем, как это сделано с шахтами лифтов (возможно, достаточно забора на высокоскоростных участках и надземных переходов).
Если автопилот решает, а не убить ли ему пассажиров, это может быть использовано для преднамеренных убийств, ключик для принятия «нужных» решений так или иначе найдётся. Я бы не захотел пользоваться таким транспортом. Почему должны погибать пассажиры, если они не нарушали правил и вообще не имели контроля над ситуацией, а не те, кто контролировал ситуацию и правила нарушил?
Иногда такие странные вещи по причине обратной совместимости появляются.
п.17 особенно интересно смотрится в чеклисте с логическими «дырами».
Правила должны быть непротиворечивы, иначе принимать их — себе дороже.
> 23. Некоторых людей наказывать нельзя.
Список таких людей должен быть включён в регламенты? Иначе пункты противоречат друг другу.