Хочет будден, чтобы в рантайме ещё и компилятор был?
Почему люди не признаются, что хотят сделать интерпретатор? Джава же.
Как посторонним войти на рынок разработки софта для ядерных реакторов
Страница: 1
Сообщений 1 страница 17 из 17
Поделиться12018-11-04 11:18:09
Поделиться22018-11-04 12:56:03
Лис
Скуууучно.
Зато плюс я теперь понял зачем Буддену корутины.
Поделиться32018-11-04 18:54:56
А в синхронизации, непротиворечивости состояний и переменных.
Опять же практическое применение?
А так же их типов.
Так не бывает 
. Либо универсальность либо типы процессора.
Вопрос не в интерпретаторе.
А в изобретение велосипеда, первый из которых назывался Бейсик. Ява и JIT - один шаг и у Вас горячая замена кода. Все что Вам нужно - изначально интерпретировать код.
Отредактировано utkin (2018-11-04 18:58:25)
Поделиться42018-11-04 22:05:20
Так не про процессор речь.
Ну как же не про процессор? Хотим же быстро, а значит есть много оптимизированных на скорость типов. А теперь надо еще и универсально, а так не бывает. Вот и начинают костыли пиарить - корутины им подавай, горячую замену кода.
Практическое применение находят в математических библиотках.
Узкий сегмент. Наиболее распространенная математика это +1 к переменной.
Во-вторых у меня есть моя секретная технология. В совокупности с динамическим патчингом может получится неплохой результат. Вернее только благодаря моей технологии динамический патчинг сможет работать.
У всех какие-то супер секретные технологии. У Буденна тоже прямо все супер-супер. Но я только за на самом деле. Если люди, что-то пытаются, то это только хорошо.
Интерпреататоры решает только часть проблем.
Все решает только часть проблем. Ложки нет.
У корутинов практическое применение для инициализации USB в UEFI.
Уверен, можно было обойтись и без них. Но не суть, если людям нравится пусть используют.
К примеру создание ИИ с помощью генетических алгоритмов которые будут динамически изменять код.
Зачем? Это как менять каждый раз схему компьютера, вместо того чтобы менять программы в нем. Дело же не в том, что машина Тьюринга чего-то не может. А в том, что криворукие программисты сразу не предусмотрели ситуацию при проектировании программы.
Или с точки срения исследований очень удобно сменить часть кода без пересборки и переррасчётов.
Ну интерпретация чистой воды.
Использовать интерпретатор не очень охото, так как он медленный.
А как напишите. Есть же JIT. Все ругают интерпретаторы, но всех их пишут. И все туда стремятся - mono. Питон, Ява, Жабаскрипт, имя им легион.
Отредактировано utkin (2018-11-04 22:14:40)
Поделиться52018-11-04 22:19:07
Есть же JIT.
Так это её составляющая.
Зачем?
Время исполнения бывает, что данных, от которых зависит оптимизация, поболее, чем при стат. компиляции. И в таких случаях горячий код будет быстрее.
А в том, что криворукие программисты сразу не предусмотрели ситуацию при проектировании программы.
Кол-во частных случаев оптимизации бесконечно.
Отредактировано MihalNik (2018-11-04 23:04:34)
Поделиться62018-11-04 22:24:07
Затем что бывает, когда во время исполнения данных, от которых зависит оптимизация, поболее, чем при стат. компиляции. И в таких случаях полученный код работает быстрее.
Я плохо понимаю Ваш французский. Давайте немного подробней.
Кол-во частных случаев оптимизации бесконечно.
Но все оптимизировать нет нужды. Достаточно 20%.
Отредактировано utkin (2018-11-04 22:25:22)
Поделиться72018-11-04 22:43:15
utkin написал(а):
Достаточно 20%.
20% от бесконечности? 
Давайте немного подробней.
Давайте. Во время работы стало известно, что условие перехода в самом частом цикле более никогда не сработает. А его проверка стоит время. Ваши действия?
Или возник внешний физический фактор, срочно требующий новое условие в программе, но Вы не можете произвести остановку управления самолётом, косм. аппаратом, ядерным реактором или жизнеобеспечением человека.
Отредактировано MihalNik (2018-11-04 22:57:14)
Поделиться82018-11-04 23:30:09
20% от бесконечности?
От кода программы
Во время работы стало известно, что условие перехода в самом частом цикле более никогда не сработает.
Мы имеем глючную систему - растрелять все нечетных программистов в проекте, с остальных удержать из зарплаты стоимость патронов.
Ваши действия?
Отправить программу на доработку. В ходе работы выяснилось, что код ущербен. Что делают в таких случаях. Где была отладка, в каком месте?
Или возник внешний физический фактор, срочно требующий новое условие в программе, но Вы не можете произвести остановку управления самолётом, косм. аппаратом, ядерным реактором или жизнеобеспечением человека.
За проблемы в таких системах расстрелять и четных и нечетных и руководителя проекта.
Это же ситуация когда мы просто вешаем костыль. Сначала в одном месте, потом в другом. Потом система просто падает и все. В результате умирают люди. Потому что мы в случае обнаружения ошибок в таких проектах как ядерный реактор вообще-то должны его останавливать.
Отредактировано utkin (2018-11-04 23:33:49)
Поделиться92018-11-04 23:32:09
utkin написал(а):
растрелять
Вот Вас и расстреляют или уволят.
"Расстреляйте меня!" - это вообще не решение, а истерика.
utkin написал(а):
Потому что мы в случае обнаружения ошибок в таких проектах как ядерный реактор вообще-то должны его останавливать.
А если метеорит упадёт - Вы его тоже остановите? Вы сумеете заложить в программу падение метеорита в районе реактора?
Отредактировано MihalNik (2018-11-04 23:36:38)
Поделиться102018-11-04 23:36:09
"Расстреляйте меня!" - это вообще не решение, а истерика.
То что предлагается тоже не решение. Либо это не просто оптимизация и ее можно не проводить. Либо это фатальная логическая ошибка и тогда проект нужно останавливать и отправлять на доработку. Потому что где гарантия, что нет второй такой ошибки, если есть первая? Как же хваленые тесты? Расстрел, только расстрел с занесением в трудовую книжку.
Поделиться112018-11-04 23:37:50
utkin написал(а):
проект нужно останавливать
Остановите реактор за 5 минут, а мы посмотрим как он у Вас остановится.
Отредактировано MihalNik (2018-11-04 23:38:30)
Поделиться122018-11-04 23:43:15
Остановите реактор за 5 минут, а мы посмотрим как он у Вас остановится.
Но ответ тот же, наличие ошибки в критически важной системе требует ее останова, а не игры в русскую рулетку.
Поделиться132018-11-04 23:47:28
utkin написал(а):
Но ответ тот же, наличие ошибки в критически важной системе требует ее останова, а не игры в русскую рулетку.
Критические ситуации требуют их анализа и принятия решений.
Останов сложной системы в критических ситуациях требует анализа и принятия решений.
Программа реал. времени не м.б. остановлена ранее достижения физической системой определённого безопасного состояния - это полная потеря управления.
Отредактировано MihalNik (2018-11-04 23:53:44)
Поделиться142018-11-05 08:36:10
Критические ситуации требуют их анализа и принятия решений.
Решение в таких случаях уже принято до возникновения проблемы. Наличие одной ошибки, говорит о том, что код не отлажен и не гарантирует отсутствия остальных. Это стопроцентный останов и вывод из эксплуатации. Да реактор нельзя остановить сразу - но пока вы напишите патч, уйдет не меньше времени чем на останов реактора или перевод его в безопасное состояние.
Никакой потери управления здесь нет - это завершение работы в аварийном режиме. И большинство систем поддерживают такой режим.
Поделиться152018-11-05 10:32:47
utkin написал(а):
Но ответ тот же, наличие ошибки в критически важной системе требует ее останова, а не игры в русскую рулетку.
Реактор нельзя заглушить. Поэтому в критически важных системах есть дублирующие блоки работающие на разных алгоритмах.
Систему никто не будет останавливать. Максимум могут остановить блок. Но опять таки обычно в блоке есть устройство управления УУ которая выбирает ветки алгоритма из нескольких тем самым может обойти ошибку.
Поэтому скорее всего будет принято решение и вовсе оставить блок на месте, до устранения ошибки на макете и замене блока.
Поделиться162018-11-05 10:38:57
utkin написал(а):
решение в таких случаях уже принято до возникновения проблемы.
Кто Вам это сказал? Инструкции предполагают в т.ч. принятие решений, потому что невозможно описание всех физических ситуаций.
Вы никак не можете понять, что требования к программам меняются и в т.ч. инструкции часто включают требования, предусматривающие изменение программ без их остановки.
utkin написал(а):
Никакой потери управления здесь нет - это завершение работы в аварийном режиме. И большинство систем поддерживают такой режим.
И большинство систем реал. времени поддерживают принятие новых решений без остановки. Аварийные системы также нарушаются.
Пока вы напишите патч, уйдет не меньше времени чем на останов реактора или перевод его в безопасное состояние.
Этого никто никогда заранее не знает.
наличие ошибки
Ещё раз - просчитайте повреждение системы чем-то вроде метеорита. И не надо про низкие вероятности таких случаев. Они же имеются? Имеются.
А для объектов в космосе - и не редкие.
Отредактировано MihalNik (2018-11-05 10:46:03)
Поделиться172018-11-05 21:58:40
Реактор нельзя заглушить.
Как-то же их все равно выводят из эксплуатации. Займет это 2 секунды или два месяца не имеет значения.
нескольких тем самым может обойти ошибку.
Или наткнуться на новую. Гарантий же теперь нет никаких. Так мы полагались на процедуру тестирования, которая не должна пропускать ошибок. Если она пропустила, то соответственно выбор иного алгоритма не гарантирует ничего - успешный пуск равновероятен аварии (на самом деле, вероятности успешного запуска конечно выше, но зато стоимость ошибочного решения непомерно высока).
Кто Вам это сказал? Инструкции предполагают в т.ч. принятие решений, потому что невозможно описание всех физических ситуаций.
Что именно здесь невозможного? Система не работает так как должна? Если это не часть системы по управлению туалетными бачками, то непредвиденного здесь ничего нет.
И большинство систем реал. времени поддерживают принятие новых решений без остановки.
Вполне допускаю, но с реактором как-то неудачный пример.
Этого никто никогда заранее не знает.
Поэтому и не рискуют человеческими жизнями, а останавливают процессы.
Ещё раз - просчитайте повреждение системы чем-то вроде метеорита. И не надо про низкие вероятности таких случаев. Они же имеются? Имеются.
А для объектов в космосе - и не редкие.
Повреждение метеоритом в космосе это первая причина, которая рассматривается и учитывается. Если речь идет о спутниках и космических аппаратах.
Страница: 1