Что-то незаметно. Вот прошу пояснить смысл анекдота про Штирлица и двузначное число:
Этот анекдот основан на игре слов и чисел, а также на использовании стереотипов и клише. В анекдоте Гиммлер, известный персонаж из романа Юлиана Семенова "Семнадцать мгновений весны", вызывает своих сотрудников и просит их назвать двузначное число.
Первый сотрудник называет число 42, а не 24, потому что 42! (факториал 42) - это очень большое число, которое, по сути, не имеет отношения к заданию. Это может быть намеком на известный роман Дугласа Адамса "Автостопом по галактике", где число 42 является ответом на "главный вопрос жизни, вселенной и всего такого".
Второй сотрудник называет число 28, а не 82, потому что 28 - это простое число, а 82 - нет. Это может быть намеком на то, что первый сотрудник был слишком сложным и загадочным, а второй - более простым и понятным.
Третий сотрудник называет число 33, и Гиммлер сразу узнает Штирлица, известного персонажа из того же романа. Это может быть намеком на то, что Штирлиц - умный и хитрый персонаж, который всегда на шаг впереди.
Таким образом, анекдот использует игру слов и чисел, а также отсылки к известным литературным персонажам, чтобы создать комический эффект.
Откуда тут Адамс вылез? Он же не русскый писатель.
Такой подход к "верности" возможно был бы интересен аппаратчикам, или, узкому кругу АСУ-шников, но для программистов он не слишком актуален.
Для них скорее подойдёт другой: параллельные вычисления должны гарантировать тот же результат, что дают последовательные. Скажем, у нас есть строго последовательный алгоритм сортировки массива, и он корректно работает. Мы переписали его в той или иной модели параллелизма. Далее, идеально было бы уметь доказать, что результат не изменился. Аналогично и для других алгоритмов.
P.S. Что касается схемы C13 я не вижу там проблем, но я далек от схемотехники, да и доступа к продуктам Esterel у меня нет.
Не очень понятно, что делает ту или иную модель параллельных вычислений "верной". Это нужно как-то обосновать. Плюс, практически за каждой используемой сейчас моделью стоит своя теория, будь то CSP, функциональное программирование, модель акторов. Нужно просто их изучить, и вуаля. Если же вернуться к эффективности, то я прекрасно понимаю ваших оппонентов. Хабр - по большей части сайт практиков от программирования. Даже будь какая-то модель супер-хорошей в теории, без примеров эффективной реализации она мертва. Вот, к примеру, функциональный подход (в теории) предлагает прекрасное решение для параллельного программирования. Практически бесконечное масштабирование без какого либо напряга для программиста + доказуемая корректность. Однако с практическими реализациями пока не очень. Как результат - невысокая популярность этой парадигмы.
Ок. Начнем с первого пункта. Вы хотите донести факт "что программировать параллельно можно намного эффективнее". Наверное можно. Но, во-первых, эффективнее чем что? Во-вторых, как уже неоднократно замечали ваши оппоненты, data-driven подход дает достаточно эффективные методы для параллельного программирования. Если же вы, положим, претендуете на то, что ваш (условно "автоматный") подход еще лучше, то надобно привести какие-то примеры решения пусть простых модельных задач, но интересных широкому кругу программистов. Например, реализацию параллельного перемножения матриц, сортировки слиянием, задачи N-тел... Можно реализовать и какую-нибудь интересную структуру данных, concurrent hash map или что-то подобное. А не регулятор нагревателя.
По второму пункту - понятно, что "представлять" базу специально вам вряд ли кто-то будет. Парни из Esterel Technologies вероятно даже не в курсе, что кто-то их научной базой недоволен. Но при желании найти их теоретические наработки не сложно. Можно начать с работы Gérard Berry по конструктивной семантике языка Esterel. Там как раз есть и про преобразование в электрические схемы и про операционную семантику Плоткина. https://www-sop.inria.fr/members/Gerard.Berry/Papers/EsterelConstructiveBook.pdf И список литературы для дальнейшего изучения есть.
Прочел несколько ваших статей, но так и не понял цели их написания...
1. Вы хотите помочь программистам писать более эффективные параллельные программы? 2. Вы хотите обратить внимание аппаратчиков на конечные автоматы? 3. Вы хотите прорекламировать собственный пакет для аудитории Хабра?
Если последнее, то вопросов больше нет, цель вполне достойная. Если же первое, то не слишком понятно, как это поможет. Ведь жизнь не исчерпывается моделями нагревателя и функцией И-НЕ.
Я могу понять, в чем помогают индустрии парни из (бывшего) Esterel Technologies. Они дают возможность генерировать верифицированный код на базе формальных моделей исполнения. Удобны ли эти модели - другой вопрос. Так или иначе, за ними стоит достаточно проработанная научная база. Однако, хотите ли вы идти по этому пути - мне не ясно.
Париж вероятно лучшее место с точки зрения зарплаты, но по большинству других параметров проигрывает остальной Франции. Конечно, в нём сосредоточено много IT-компаний, но есть и другие технопарки по всей стране, где хороший специалист не пропадет. Единственная проблема которая будет преследовать везде - французская бюрократия. Но она хотя бы предсказуема.
Эльбрус, IMHO, это просто очень высокий и холодный эскалатор. Но очень популярный почему-то. Причины этой популярности еще предстоит выяснить социологам…
Что-то незаметно. Вот прошу пояснить смысл анекдота про Штирлица и двузначное число:
Откуда тут Адамс вылез? Он же не русскый писатель.
Интересно. А вот бывает ли такая вещь как "китайский стартап". И если да, то какая будет обстановка в нем?
Я посмотрел на вашу статью, но действительно, без таблиц и без конкретного кода который можно было бы запустить для проверки смысла в ней немного.
Такой подход к "верности" возможно был бы интересен аппаратчикам, или, узкому кругу АСУ-шников, но для программистов он не слишком актуален.
Для них скорее подойдёт другой: параллельные вычисления должны гарантировать тот же результат, что дают последовательные. Скажем, у нас есть строго последовательный алгоритм сортировки массива, и он корректно работает. Мы переписали его в той или иной модели параллелизма. Далее, идеально было бы уметь доказать, что результат не изменился. Аналогично и для других алгоритмов.
P.S. Что касается схемы C13 я не вижу там проблем, но я далек от схемотехники, да и доступа к продуктам Esterel у меня нет.
Не очень понятно, что делает ту или иную модель параллельных вычислений "верной". Это нужно как-то обосновать. Плюс, практически за каждой используемой сейчас моделью стоит своя теория, будь то CSP, функциональное программирование, модель акторов. Нужно просто их изучить, и вуаля.
Если же вернуться к эффективности, то я прекрасно понимаю ваших оппонентов. Хабр - по большей части сайт практиков от программирования. Даже будь какая-то модель супер-хорошей в теории, без примеров эффективной реализации она мертва.
Вот, к примеру, функциональный подход (в теории) предлагает прекрасное решение для параллельного программирования. Практически бесконечное масштабирование без какого либо напряга для программиста + доказуемая корректность. Однако с практическими реализациями пока не очень. Как результат - невысокая популярность этой парадигмы.
Ок. Начнем с первого пункта. Вы хотите донести факт "что программировать параллельно можно намного эффективнее". Наверное можно. Но, во-первых, эффективнее чем что? Во-вторых, как уже неоднократно замечали ваши оппоненты, data-driven подход дает достаточно эффективные методы для параллельного программирования. Если же вы, положим, претендуете на то, что ваш (условно "автоматный") подход еще лучше, то надобно привести какие-то примеры решения пусть простых модельных задач, но интересных широкому кругу программистов. Например, реализацию параллельного перемножения матриц, сортировки слиянием, задачи N-тел... Можно реализовать и какую-нибудь интересную структуру данных, concurrent hash map или что-то подобное. А не регулятор нагревателя.
По второму пункту - понятно, что "представлять" базу специально вам вряд ли кто-то будет. Парни из Esterel Technologies вероятно даже не в курсе, что кто-то их научной базой недоволен. Но при желании найти их теоретические наработки не сложно. Можно начать с работы Gérard Berry по конструктивной семантике языка Esterel. Там как раз есть и про преобразование в электрические схемы и про операционную семантику Плоткина.
https://www-sop.inria.fr/members/Gerard.Berry/Papers/EsterelConstructiveBook.pdf
И список литературы для дальнейшего изучения есть.
Ошибся веткой.
Прочел несколько ваших статей, но так и не понял цели их написания...
1. Вы хотите помочь программистам писать более эффективные параллельные программы?
2. Вы хотите обратить внимание аппаратчиков на конечные автоматы?
3. Вы хотите прорекламировать собственный пакет для аудитории Хабра?
Если последнее, то вопросов больше нет, цель вполне достойная. Если же первое, то не слишком понятно, как это поможет. Ведь жизнь не исчерпывается моделями нагревателя и функцией И-НЕ.
Я могу понять, в чем помогают индустрии парни из (бывшего) Esterel Technologies. Они дают возможность генерировать верифицированный код на базе формальных моделей исполнения. Удобны ли эти модели - другой вопрос. Так или иначе, за ними стоит достаточно проработанная научная база. Однако, хотите ли вы идти по этому пути - мне не ясно.
P.S. С модератором, кстати, тоже согласен.
Теперь ждем следующего шага - определение IQ по МРТ мозга.
Да... Много лет потребовалось, чтобы сделать что-то похожее на PF. Но вот с читабельностью так и не получилось.
Я имею ввиду какие-нибудь законодательные запреты.
Только радиолюбителям? А обычным людям можно?
Париж вероятно лучшее место с точки зрения зарплаты, но по большинству других параметров проигрывает остальной Франции. Конечно, в нём сосредоточено много IT-компаний, но есть и другие технопарки по всей стране, где хороший специалист не пропадет. Единственная проблема которая будет преследовать везде - французская бюрократия. Но она хотя бы предсказуема.
Мощно Терехов-старший подколол младшего. :)
Что до его транслятора Алгола-68 — то мало кто его любил, да и глючил он часто.
Кумо-Манычская впадина и все такое…