Ну а почему в том же 2012 году не создать широкий альянс заинтересованных стран, обьединть усилия с тем-же Китаем, Индией, Ираном, Египтом и прочими заинтересованными в теме и развивать технологию совместными усилиями и деньгами ( а денег нужно много, чем больше тем лучше ).
P.S. Тут не только технологический, а и политический провал. Не удивительно что у РФ кроме РБ нет дружественно настроенных соседей...
В 1995 году - уже массовый выпуск АMD 586 по 350 нм технологии, с конкурентной ценой. Не нужно сравнивать с - "собрали один экспериментальный экземпляр литографа, пытаемся запустить..."
Такой уровень освоения 350 нм - пожалуй соответствует 1990 году. Ещё наладить промышленный выпуск таких литографов. Установить на фабриках, добиться приемлимого выхода годных. Спроектировать чипы под этот техпроцес. Наштамповать чипов. Насытить ими торговую сеть...
Даже DSP часто делают по тому-же принципу. Одно ядро для управления со своим набором команд, заточеным на переходы и обработку прерываний. И ядра для вычислений, которые действительно VLIW.
Например у Texas Instrument такие DSP были. Я давно с DSP не сталкивался.
Попал в неудачную нишу. Для задач управления или вычислений где много-много неожиданных переходов - VLIW плох. Для линейных, хорошо распаралеливаемых вычислительных задач - выиграл подход gpu. Один набор команд и много-много ядер параллельно их исполняющих. VLIW оказался "между стульями".
По моему amigo браузер от яндекс, который ставился без спроса и который выковырять из системы было не проще чем качественный вирус, это однозначно черное!
Всегда удивляло то, что чем больше человек верует в порочность и жадность людей ( тех же собственников и капиталистов ) тем больше ратует за коммунизм ( для построения которого нужны бескорыстные люди ).
Автор постоянно подчёркивает значимость универсальности, унификации и стандартизации предложенной системы. Но пока человечеством подходы ещё не определены, теории нет, практики очень мало.
В такой ситуации нужно пробовать сотни разных подходов. И для этого нужны сотни конкурирующих стартапов. Из которых только единицы найдут жизнеспособные решения, а усилия остальных , увы окажутся тщетными.
Умозрительно выдумать общие принципы такой всеобьемлющей системы, а потом планомерно её расширять, не имеет и 1% на успех. Наверняка окажется что выбран ложный путь.
Стандарты и унификации должны органично "созреть" на локальных частных конкурирующих решениях. И скорее всего по итогу все окажется не так, как виделось в начале пути... Сразу замахиваться на общее концептуальное решение, почти наверняка "не взлетит".
По крайней мере понятное описание ошибки ( с блок схемами и кодом ) должно быть доступно общественности. По крайней мере что-бы другие специалисты в других проектах её не повторяли. Подходы то в аэрокосмической отрасли похожие, инженеры в одних вузах учились...
И вообще - такие ошибки ПО ( на сотню миллионов долларов ) обычно вызывают широкую дискуссию в компьютерном сообществе. Меняют подходы к написанию и тестированию ПО, синтаксисы языков программирования и моду на них...
Не нужно самой прошивки. Выложите хоть расшифровку загадочной фразы: «Установлено, что наиболее вероятной причиной аварии стало нештатное функционирование бортового комплекса управления, связанное с невключением блока акселерометров в приборе БИУС-Л (блок измерения угловых скоростей) из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором. При этом распределение команд в массивах данных имеет случайный (вероятностный) характер»
массив данных команд - это FIFO без приоритетов? А нужна была очередь с приоритетами? Или это вообще что-то другое?
случайный (вероятностный) характер - это "гонка" в многопоточной среде? Фрагментация какой-то области данных и поиск "дырок"? Следствие обработки прерываний? Двоичный поиск по не уникальному ключу? Хэш коллизия?
На космическом аппарате ускорения не большие. Так что скорее всего значения датчика целочисленные ( такого большого диапазона как у чисел с плавающей точкой не нужно ) и реализация плавучки в датчике излишнее усложнение.
Специальная арифметика целочисленных с особыми целочисленными NaN или NULL в расчетах вряд-ли реализована, скорее всего для целочисленных, обычная целочисленная. Какое же целое число взять в качестве "нет значения"?
Я бы взял 0. Что естественно для аппарата 99% времени летящего без ускорения ( в свободном падении ). Ради минимального шанса - что если программист считает данные с не включенного датчика и использует их в расчетах ничего страшного не произойдет - нулевое значение не исказит расчеты. Как падали в свободном полете так и продолжаем падать...
При любом другом значении NaN или NULL ( например FF..FF ) если это значение "просочится" в расчеты без проверки - они точно выдадут такое, что катастрофа неизбежна. Этого призрачного шанса что ошибка не скажется - не будет...
А с какой реализацией NaN или NULL во встроенных железках с целочисленной арифметикой сталкивались Вы?
Скорее всего говорит что буфера на 4 ( или 8 или 16 ) передаваемых команд хватит всегда с запасом...
Рассмотреть все пути по которым можно пройти и вычислить максимально возможное число команд в буфере - очень сложно. Просто взяли с запасом. Что-б наверняка! Но...
Моя версия: ответов на исполнение команд от БИУС-Л вообще не было предусмотрено. Выполняя измерение - он выставлял на выходе измеренное значение и держал его до следующей команды. Ну а когда он выключен - на выходе естественно 0. Был буфер FIFO ( обычный, без приоритетов ) для передачи команд БИУС-Л. Который при переполнении теряет команду. Решили - что раз команда на включение всегда первая - уж она-то потеряться точно не может ( буфер будет пуст ). Но что-то пошло не так...
Имхо - именно об этом загадочное замечание об не учете приоритета команд и случайном их распределении.
А смысл? Если один датчик не работает - то и два или три аналогичной конструкции скорее всего то-же не сработают. Ну например - сгорел от скачка напряжения. Ну так точно так-же и 3 и 33 аналогичных в этот момент сгорят.
И как всегда возникает вопрос - что делать дальше, если malloc() вернул NULL? Если без работоспособных акселерометров сесть на Луну все равно не возможно, стоит ли проверять, запустились они или нет. Если по итогу все равно провал...
Сразу признаю - действительно не знаю предметной области вообще.
Но как я понимаю - что-бы квантовый компьютер работал как задумывался, нужны управляемые связи ( запутываем или нет ) каждого кубита с каждым. Только тогда получится 2^n состояний. На 100 000 кубитов - полтриллиона связей. Полтриллиона вентелей на чипе - это уровень микроэлектроники следующего десятилетия.
Или связи должны быть коммутируемые. Вот тут не знаю - можно ли передавать запутанность через коммутируемые штуки?
Так что мой принцип ( очень много и очень мелких ) наверное сохраняется. Очень много - это связей. А очень мелких - что-бы не пришлось запихивать огромную бандуру размером с дом в жидкий гелий...
Из самых общих соображений - квантовый компьютер это много ( и даже желательно очень много ) очень мелких элементов ( таких мелких на которых проявляются квантовые эффекты ).
Пока у человечества есть только один способ такое делать ( очень много и очень мелких ) - фотолитография. По этому в изготовлении квантовых компьютеров преуспеют страны лидеры в фотолитографии.
Россия ещё будет держаться в тренде пока все ограничивается лабораторными образцами, из десятков или сотни кубитов. Но дальше ей ничего не светит, промышленные образцы на тысячи и сотни тысяч кубитов она выпустить не сможет...
Причем селфджойн скорее всего будет эффективней: Оптимизатор скорее всего сделает его hash-join-ом (https://habr.com/ru/articles/657021/). Вместо ужасного N IN (SELECT DISTINCT P FROM Tree) внутри CASE, с которым не понятно как оптимизатор справится, даже при наличии индекса по P... А без индекса вообще мрак на большой таблице.
Ну СССР изначально позиционировал себя как единственное правильное государство на земле ( государство из будущего ). В котором живет самый лучший в мире прогрессивный народ - советский народ ( а остальные народы ему в подметки не годятся ). Как уж тут без империализма обойтись?
CCCР как тотальное государство оставил после себя огромное мифологическое культурное наследство, о себе выдающемся. Которое по хорошему, после падения идеологического диктата, должно было бы быть аккуратно инвентаризировано и частью разоблачено.
Что-бы возобладал объективный взгляд на СССР. Но этого не произошло - т.к. люстраций не было. Из всего огромного развесистого мифа были разоблачены только некоторые особо одиозные политические моменты. А все остальное осталось...
P.S. Может стоило-бы запретить показывать "Кубанских казаков" без предварения фильма титрами о реальном уровне жизни крестьянства в 1949 году?
Ну а почему в том же 2012 году не создать широкий альянс заинтересованных стран, обьединть усилия с тем-же Китаем, Индией, Ираном, Египтом и прочими заинтересованными в теме и развивать технологию совместными усилиями и деньгами ( а денег нужно много, чем больше тем лучше ).
P.S. Тут не только технологический, а и политический провал. Не удивительно что у РФ кроме РБ нет дружественно настроенных соседей...
Выращивать слоёный пирог - очень сложная технологическая задача. Пожалуй посложнее чем просто освоить плоские 350 нм.
Слоёные пироги появились через десяток лет после. И видимо закономерно. Очень сложно.
В 1995 году - уже массовый выпуск АMD 586 по 350 нм технологии, с конкурентной ценой. Не нужно сравнивать с - "собрали один экспериментальный экземпляр литографа, пытаемся запустить..."
Такой уровень освоения 350 нм - пожалуй соответствует 1990 году. Ещё наладить промышленный выпуск таких литографов. Установить на фабриках, добиться приемлимого выхода годных. Спроектировать чипы под этот техпроцес. Наштамповать чипов. Насытить ими торговую сеть...
Даже DSP часто делают по тому-же принципу. Одно ядро для управления со своим набором команд, заточеным на переходы и обработку прерываний. И ядра для вычислений, которые действительно VLIW.
Например у Texas Instrument такие DSP были. Я давно с DSP не сталкивался.
Попал в неудачную нишу. Для задач управления или вычислений где много-много неожиданных переходов - VLIW плох. Для линейных, хорошо распаралеливаемых вычислительных задач - выиграл подход gpu. Один набор команд и много-много ядер параллельно их исполняющих. VLIW оказался "между стульями".
По моему amigo браузер от яндекс, который ставился без спроса и который выковырять из системы было не проще чем качественный вирус, это однозначно черное!
Всегда удивляло то, что чем больше человек верует в порочность и жадность людей ( тех же собственников и капиталистов ) тем больше ратует за коммунизм ( для построения которого нужны бескорыстные люди ).
Какой-то логический парадокс получается...
Автор постоянно подчёркивает значимость универсальности, унификации и стандартизации предложенной системы. Но пока человечеством подходы ещё не определены, теории нет, практики очень мало.
В такой ситуации нужно пробовать сотни разных подходов. И для этого нужны сотни конкурирующих стартапов. Из которых только единицы найдут жизнеспособные решения, а усилия остальных , увы окажутся тщетными.
Умозрительно выдумать общие принципы такой всеобьемлющей системы, а потом планомерно её расширять, не имеет и 1% на успех. Наверняка окажется что выбран ложный путь.
Стандарты и унификации должны органично "созреть" на локальных частных конкурирующих решениях. И скорее всего по итогу все окажется не так, как виделось в начале пути... Сразу замахиваться на общее концептуальное решение, почти наверняка "не взлетит".
По крайней мере понятное описание ошибки ( с блок схемами и кодом ) должно быть доступно общественности. По крайней мере что-бы другие специалисты в других проектах её не повторяли. Подходы то в аэрокосмической отрасли похожие, инженеры в одних вузах учились...
И вообще - такие ошибки ПО ( на сотню миллионов долларов ) обычно вызывают широкую дискуссию в компьютерном сообществе. Меняют подходы к написанию и тестированию ПО, синтаксисы языков программирования и моду на них...
Не нужно самой прошивки. Выложите хоть расшифровку загадочной фразы:
«Установлено, что наиболее вероятной причиной аварии стало нештатное функционирование бортового комплекса управления, связанное с невключением блока акселерометров в приборе БИУС-Л (блок измерения угловых скоростей) из-за возможного попадания в один массив данных команд с различными приоритетами их исполнения прибором. При этом распределение команд в массивах данных имеет случайный (вероятностный) характер»
массив данных команд - это FIFO без приоритетов? А нужна была очередь с приоритетами? Или это вообще что-то другое?
случайный (вероятностный) характер - это "гонка" в многопоточной среде?
Фрагментация какой-то области данных и поиск "дырок"? Следствие обработки прерываний? Двоичный поиск по не уникальному ключу? Хэш коллизия?
На космическом аппарате ускорения не большие. Так что скорее всего значения датчика целочисленные ( такого большого диапазона как у чисел с плавающей точкой не нужно ) и реализация плавучки в датчике излишнее усложнение.
Специальная арифметика целочисленных с особыми целочисленными NaN или NULL в расчетах вряд-ли реализована, скорее всего для целочисленных, обычная целочисленная. Какое же целое число взять в качестве "нет значения"?
Я бы взял 0. Что естественно для аппарата 99% времени летящего без ускорения ( в свободном падении ). Ради минимального шанса - что если программист считает данные с не включенного датчика и использует их в расчетах ничего страшного не произойдет - нулевое значение не исказит расчеты. Как падали в свободном полете так и продолжаем падать...
При любом другом значении NaN или NULL ( например FF..FF ) если это значение "просочится" в расчеты без проверки - они точно выдадут такое, что катастрофа неизбежна. Этого призрачного шанса что ошибка не скажется - не будет...
А с какой реализацией NaN или NULL во встроенных железках с целочисленной арифметикой сталкивались Вы?
Скорее всего говорит что буфера на 4 ( или 8 или 16 ) передаваемых команд хватит всегда с запасом...
Рассмотреть все пути по которым можно пройти и вычислить максимально возможное число команд в буфере - очень сложно. Просто взяли с запасом. Что-б наверняка! Но...
Моя версия: ответов на исполнение команд от БИУС-Л вообще не было предусмотрено.
Выполняя измерение - он выставлял на выходе измеренное значение и держал его до следующей команды. Ну а когда он выключен - на выходе естественно 0.
Был буфер FIFO ( обычный, без приоритетов ) для передачи команд БИУС-Л. Который при переполнении теряет команду. Решили - что раз команда на включение всегда первая - уж она-то потеряться точно не может ( буфер будет пуст ). Но что-то пошло не так...
Имхо - именно об этом загадочное замечание об не учете приоритета команд и случайном их распределении.
И что-бы поменялось на следующем витке?
А смысл? Если один датчик не работает - то и два или три аналогичной конструкции скорее всего то-же не сработают. Ну например - сгорел от скачка напряжения.
Ну так точно так-же и 3 и 33 аналогичных в этот момент сгорят.
И как всегда возникает вопрос - что делать дальше, если malloc() вернул NULL?
Если без работоспособных акселерометров сесть на Луну все равно не возможно, стоит ли проверять, запустились они или нет. Если по итогу все равно провал...
Сразу признаю - действительно не знаю предметной области вообще.
Но как я понимаю - что-бы квантовый компьютер работал как задумывался, нужны управляемые связи ( запутываем или нет ) каждого кубита с каждым. Только тогда получится 2^n состояний. На 100 000 кубитов - полтриллиона связей. Полтриллиона вентелей на чипе - это уровень микроэлектроники следующего десятилетия.
Или связи должны быть коммутируемые. Вот тут не знаю - можно ли передавать запутанность через коммутируемые штуки?
Так что мой принцип ( очень много и очень мелких ) наверное сохраняется. Очень много - это связей. А очень мелких - что-бы не пришлось запихивать огромную бандуру размером с дом в жидкий гелий...
Из самых общих соображений - квантовый компьютер это много ( и даже желательно очень много ) очень мелких элементов ( таких мелких на которых проявляются квантовые эффекты ).
Пока у человечества есть только один способ такое делать ( очень много и очень мелких ) - фотолитография. По этому в изготовлении квантовых компьютеров преуспеют страны лидеры в фотолитографии.
Россия ещё будет держаться в тренде пока все ограничивается лабораторными образцами, из десятков или сотни кубитов. Но дальше ей ничего не светит, промышленные образцы на тысячи и сотни тысяч кубитов она выпустить не сможет...
Причем селфджойн скорее всего будет эффективней:
Оптимизатор скорее всего сделает его hash-join-ом (https://habr.com/ru/articles/657021/). Вместо ужасного N IN (SELECT DISTINCT P FROM Tree) внутри CASE, с которым не понятно как оптимизатор справится, даже при наличии индекса по P... А без индекса вообще мрак на большой таблице.
Ну СССР изначально позиционировал себя как единственное правильное государство на земле ( государство из будущего ). В котором живет самый лучший в мире прогрессивный народ - советский народ ( а остальные народы ему в подметки не годятся ).
Как уж тут без империализма обойтись?
CCCР как тотальное государство оставил после себя огромное мифологическое культурное наследство, о себе выдающемся. Которое по хорошему, после падения идеологического диктата, должно было бы быть аккуратно инвентаризировано и частью разоблачено.
Что-бы возобладал объективный взгляд на СССР. Но этого не произошло - т.к. люстраций не было. Из всего огромного развесистого мифа были разоблачены только некоторые особо одиозные политические моменты. А все остальное осталось...
P.S. Может стоило-бы запретить показывать "Кубанских казаков" без предварения фильма титрами о реальном уровне жизни крестьянства в 1949 году?