Comments 19
Понравилась мысль, что параллелизм — это не свойство алгоритма, а всего лишь особенность модели его исполнения.
Это мнение ИИ. У меня другое. Все же есть алгоритмы последовательные и параллельные. Так что параллелизм - это все же свойство алгоритма. Это следует также из выяснения какую же программу считать параллельной.
Ну я же всегда могу считать параллельный алгоритм последовательно, разве нет?
Всегда - нет. Конечно, все зависит от вида параллельного алгоритма, но если между параллельными потоками есть, так называемые, обратные связи (иногда их называют алгебраическими цепями, петлями), то точно нет.
Хотя я немного "дал в штангу" :) Если буквально понимать Ваш вопрос, то - всегда. Как так? Для этого нужно для параллельного алгоритма найти эквивалентный ему последовательный алгоритм. Вот это можно сделать всегда. Правда, это может потребовать уйму вычислений, но ... кто ж их формально считает? :) Главное, что такая возможность есть всегда.
Так что прошу прощения - просто я посмотрел на ваш вопрос в спешке слишком "в лоб" ;).
А в чём идея статьи? Показать, что нейронка хороший собеседник? Ну... Как бы да...
Это не душа а рефлексия. Вы рефлексируете сами с собой через нейронку.
Но оценка статьи «натуральным интеллектом» и комментарии к ней говорят буквально об обратном. На момент написания этих строк голосов за статью (https://habr.com/ru/articles/937448/) ровно ноль - три плюса и три минуса и масса «хейта».
Удивительно, что всего три минуса и так мало "хейта". Поскольку вы задекларировали решение "кошмара параллельности", а по факту предложили подход из категории "устранение перхоти путем отсечения головы": ваша библиотека тупо не может запускать код в параллель и принципиально отказывается использовать больше одного вычислительного ядра современных CPU. Т.е. ваше "лекарство" от "кошмаров параллельности" -- это полный отказ от той самой параллельности.
Что в современном мире, где рост вычислительной мощности уже давно идет за счет увеличения количества ядер, тогда как прозводительность на одно ядро растет все меньше и меньше.
Вы задали хороший вопрос и в чем-то даже правы: да, эта библиотека и статья не про использование нескольких ядер CPU для ускорения вычислений. Если стоит задача распараллелить рендеринг видео, тренировку нейросети или обработку больших данных, то это совершенно не тот "молоток".
Но я о другом - об детерминированном управлении в embedded-системах и IoT. И вот почему библиотека VCPa - это не про «отсечение головы», а «точная хирургия»:
Из статьи должно быть ясно, что параллелизм != многопоточность на многоядерных CPU
В мире микроконтроллеров (ESP32, STM32, AVR) под «параллелизмом» чаще понимают конкурентное выполнение множества задач на одном ядре (concurrency), а не истинный параллелизм (parallelism). Проблема не в том, чтобы считать быстрее, а в том, чтобы управлять сотней независимых процессов (датчики, сеть, кнопки, дисплей) детерминированно и без гонок.
Цель: Надёжность, а не производительность
Для многих устройств (медицина, промышленная автоматика, умный дом) предсказуемость и отсутствие ошибок в 1000 раз важнее, чем использование всех ядер.
Потоки/Мьютексы на MCU — это сложно, рискованно и resource-heavy. Один deadlock — и устройство умрет и это на производстве.
Корутины - чуть лучше, но требуют ручного управления и скрывают состояние системы.
Автоматы — дают абсолютно детерминированную, проверяемую и визуализируемую модель. Мы жертвуем «истинным параллелизмом» ради гарантированной надёжности.
Нишевое применение — это сила
Да, этот подход не для всех. Он идеален для:
Управляющей логики: Протоколы связи, сами конечные автоматы бизнес-логики, обработка пользовательского ввода.
Систем, где ваша голова стоит дороже лишнего ядра: Медицинские приборы, промышленные контроллеры, бортовые системы.
Любого устройства, где есть жёсткие требования по времени отклика (не путать с вычислительной мощностью). Автомат гарантирует, что критическая реакция на событие всегда уложится в заданный timeout.
Короче: я предлагаю не «отказаться от параллелизма», а «решить проблему параллелизма другим, более подходящим для embedded-мира способом».
Спасибо, что дали возможность прояснить этот фундаментальный момент. Надеюсь, теперь контекст статьи стал понятнее.
Если стоит задача распараллелить рендеринг видео, тренировку нейросети или обработку больших данных, то это совершенно не тот "молоток".
Тогда вам нужно перестать употреблять термин "параллельное программирование" (aka parallel computing).
под «параллелизмом» чаще понимают конкурентное выполнение множества задач на одном ядре (concurrency), а не истинный параллелизм (parallelism)
Ну так и употребляйте термин "конкурентное программирование" или "конкурентность" (aka concurrent computing).
А то вы приходите на уже накрытую поляну параллельного программирования со своей специфической темой конкурентности в однопоточном режиме и потом обижаетесь, почему вам напихивают полную панамку.
Причем вы не правы в очень важном моменте: из ваших статей не становится понятно, что вы путаете "паралелльность" с "конкурентностью". Это, в лучшем случае, выясняется в комментариях, когда вас начинают размазывать припирать к стенке конкретными вопросами.
Когда пытаются размазывать или припирать, то нормальная реакция - дать адекватный ответ. И тут начинается - от "а ты кто такой" до "а нас то за что?"... Но не будем сразу "хвать за грудки" друг друга. Это не наш подход, т.к. мы, надеюсь, адекватные ребята.
Но дело совсем не в этом. Мне понравилась Ваша ассоциация с "поляной". И тут как бы мы не хотели, о чем бы не мечтали, но ... поляна у нас одна - параллельное программирование и хочешь не хочешь, а ее как-то надо делить. Но есть и другие варианты - занять ее полностью, выдавив конкурента, или ретироваться, понимая, что здесь ловить нечего. Я за мирное разрешения проблемы и постоянно об этом говорю.
Может я ошибаюсь, но вы напоминаете мне охранника, которому дали указание - не пущать! и он должен этот приказ выполнять. С охранником договариваться смысла нет и я, очень надеюсь, что это не этот случай.
Но тогда явно должен быть "адекватный начальник", отдавший указание, но с которым можно договориться. Все же мы "одной крови" - параллельной и в такой ситуации можно и даже нужно договариваться. Иначе, действительно, .- кроме войны варианта не просматривается. Это надо тоже осознавать. "Охранник" явно не тот, с которым можно на эту тему разговаривать.
Но мне хотелось бы понять с кем я говорю - с "охранником" или "начальником"? А потому у меня к Вам вопрос: "Какую программу мы будем считать параллельной?"
Дайте ответ и я, возможно, пойму с кем разговариваю. Ведь, явно только правильный ответ на "пароль" - "параллельная программа" даст пропуск на упомянутую Вами "поляну", которую, так уж случилось, сейчас вы занимаете.
Разве не так?
Когда пытаются размазывать или припирать, то нормальная реакция - дать адекватный ответ.
"Только та революция чего-нибудь стоит, которая умеет защищаться." Вы бы должны были бы помнить.
И тут начинается - от "а ты кто такой" до "а нас то за что?"...
Нет, в комментариях к вашим статьям начинается "коллеги, а не втирают ли нам какую-то дичь?"
Но мне хотелось бы понять с кем я говорю - с "охранником" или "начальником"?
Тут есть встречные вопросы: а хватит ли у вас мозгов и опыта разобраться в том, что вам пишут оппоненты? А то ведь по качеству текстов ваших статей и ваших комментариев есть серьезные вопросы по первому пункту, а исходные тексты вашего VCPa заставляют задуматься о том, а умеете ли вы программировать вообще. Студенты 3-го курса должны бы код лучше выдавать.
"Какую программу мы будем считать параллельной?"
Как минимум, утилизирующую одновременно больше одного вычислительного ядра.
Более того, использующую доступные вычислительные ядра для сокращения общего времени выполнения задачи за счет распараллеливания выполняемых операций.
Блин, я вам ссылки на Wikipedia давал, где описывается, что есть parallel computing.
Или тут опять вопрос к вашему умственному развитию и опыту, раз вы написанное там не в состоянии понять?
Я задал конкретный технический вопрос о критериях параллельной программы. Вместо ответа по существу Вы оскорбили меня и неизвестных мне студентов.
Это говорит о том, что конструктивный диалог с вами невозможен. Терминологические споры — это нормально. Переход на личности — нет.
Моя работа и её качество — предмет оценки сообщества и моих заказчиков, а не ваших личных выпадов. На этом наш текущий диалог я считаю исчерпанным. Учтите это, если желаете общаться со мной и дальше.
А вот, если у кого-то есть конкретные технические вопросы по существу статьи или библиотеки — я всегда рад продуктивному обсуждению.
Вместо ответа по существу Вы оскорбили меня и неизвестных мне студентов.
Ой как удобно: сперва наговорили кучу не относящихся к техническим вопросам слов о том, что я вам кого-то напоминаю, затем откровенно перешли на личности желая узнать кто перед вами, а когда вам ответили тем же в духе "а судьи кто?" вы стали играть обиженку.
На ваш технический вопрос, кстати говоря, бы дан ответ.
Моя работа и её качество — предмет оценки сообщества
Ну вот любой желающий может заглянуть в ваш VCPa и сделать для себя вывод стоит связываться с таким кодом или нет. Я для себя сделал.
ЗЫ. Можно развлечь себя рассматриванием, например, класса LConvStr и его реализации.
На самом деле, для того, чтобы убрать сопутствующие параллелизму проблемы из одноядерных систем изобретать ничего особо не надо. Достаточно запретить системному таймеру переключать контекст и тогда, внезапно, программа (за вычетом входящих) становится детерминистичной. Передача же управления/смена контекста осуществляется на блокирующих операциях. Получаются те же самые автоматы, но без автоматов
Спасибо за интересный комментарий! Вы правы и попали в самую суть. То, что вы описываете — это классическая кооперативная многозадачность (cooperative multitasking). Не пробовал, но, думаю, он отлично сработает.
Если разбить всю программу на шаги и переключать контекст только вручную в точках блокировки, мы получим детерминированную систему. Фактически, каждый такой блокирующий вызов (вроде delay(), await, yield) — это и есть неявное состояние конечного автомата.
Тогда в чём же разница? Мой подход — это эволюция этой идеи, которая решает несколько практических проблем чистого кооперативного подхода:
Проблема масштабирования и читаемости. Когда у вас 10-20-100 задач, ручное управление точками
yieldпревращается в спагетти-код, где состояние системы распределено по всем функциям и скрыто в порядке вызовов. Автомат делает это состояние явным и централизованным. Вместо того чтобы гадать, в каком месте какая функция остановилась, вы контролируете состояние автомата.Проблема ремонтопригодности и ошибок. Добавить новое состояние или событие в ручной код с
yieldочень сложно — можно сломать всю логику. В автомате это делается добавлением одной строки в таблицу переходов. Это делает код модульным и защищённым от ошибок.Проблема формальной верификации. Автомат, заданный таблицей переходов, можно формально проверить на недостижимые состояния, deadlock'и и т.д. Сделать это с кодом, перемешанным с
yield, практически невозможно.
Проще говоря, ваш подход — это то, как это работает под капотом. А автомат — это инструмент проектирования, который позволяет управлять этой сложностью на высоком уровне, не задумываясь каждый раз о ручной расстановке точек останова.
Вы же не изобретаете автомат — вы неосознанно его реализуете. Моя библиотека просто предлагает делать это явно, системно и с меньшими затратами на поддержку.
Спасибо, что подняли этот вопрос! Вы прекрасно проиллюстрировали, что проблема действительно актуальна, и её можно решать разными способами на разных уровнях абстракции.
Я объявляю «войну» интеллекту… человеческому. Часть 1. (из цикла бесед с ИИ)