Ну эта штука поинтереснее, но до многоразовых РН сильно не дотягивает по значимости и полезности. Впрочем сами же пишете — ее все равно не будет. К сожалению — ожидаемо. Мы банальную «Науку»-то еще с 2007 года (!!!) запустить к МКС не можем, а здесь был проект порядка на два более сложный и рискованный.
Лидерство по количеству запусков — довольно паршивая метрика. К примеру СССР лидировал по количеству спутников в основном потому что то что у американцев по 15 лет спокойно работало у нас за два-три года выходило из строя и его приходилось непрерывно заменять. Пусков много, толку — меньше чем у американцев. В постсоветской России тоже в общем-то не все слава богу: на наших ракетах летали в основном из-за низкой цены, а низкая цена была скорее заслугой низких зарплат работников космической отрасли чем достижением отрасли.
А что в этой идее хорошего-то? Абсолютно бестолковый проект, имхо. На «полезной нагрузке» все равно нужны двигатели, этим двигателям все равно нужно топливо — ну и нафига гонять «паром» там где нагрузка на меньшем (ибо масса которую нужно двигать меньше) количестве топлива сама дойдет до нужной орбиты?
Авария в этом сценарии — отказ двигателя. Вообще в (современной) ракетной технике не так уж и часто что-то именно прямо взрывается. Даже там где визуально наблюдается что-то на него похожее чаще идет разрушение конструкции под действием аэродинамических сил и/или перегрузок.
Чтобы покупали новые CPU :). Технически скорее всего какой-нибудь дополнительный набор инструкций AVX2 в библиотеке используется который только с 4-го поколения поддерживается
Это широко распространенное заблуждение. Во-первых наивная передискретизация сигнала кратной частоты, к примеру усреднением двух подряд идущих отсчетов для снижения частоты дискретизации вдвое создаст проблемы. Во-вторых при понимании почему такое происходит становится очевидно что никаких ограничений на «кратность частот» на самом деле нет. Кратность влияет сугубо на удобство обработки, у кратных частот вычисления можно значительно упростить.
Разница в технологии получения depth map для изображения, но статья-то не про технологию а про контейнер для этой depth map в изображении и о том какие преимущества наличие depth map может давать. Lytro вполне эффективно делает depth map-ы.
Кроме того, вообще говоря на улице, насколько я могу судить, интеловский RealSense реконструирует глубину по схожим с Lytro принципам и вполне может давать худшее качество
Ну у меня статья оставила впечатление разбора «как улучшить код чтобы помочь тупому компилятору который не может обойти зависимости по данным». А компилятор-то как раз здесь отнюдь не туп. Если Вы разрешаете изменять порядок суммирования — то нафига разбирать варианты с /fp:precise? Стоило бы написать в другом ключе: разобрать что такое /fp:fast vs /fp:precise, показать насколько драматичный выигрыш дает fp:fast и как можно получить тот же результат модификацией кода если по каким-то причинам fp:fast при компиляции использовать вдруг не получается (хотя мне сложно представить почему). Это то что касается первой, содержательной части статьи.
Что касается второй части — то это просто очень сырая идея и вдобавок велосипед, т.к. задача суммирования «деревом» на массивно-параллельной архитектуре является классикой программирования для GPU и очень давно подробно иследована и разобрана. Было бы любопытно увидеть результаты подобной оптимизации на суперскалярах, но как раз ее-то у Вас в статье и нет
Это уже не ограничение по скорости распространения электромагнитного излучения и с размерами чипа FO4 насколько я понимаю слабо связано. А так материал очень интересный, не знал и соответственно подсказать что-либо не смогу.
Изначально вопрос был: а можно ли, скомпилировать один раз, а потом использовать на более новых процессорах максимально эффективно.
Похожая задача в значительно более острой форме стоит для GPGPU вычислений, т.к. вариабельность GPU намного выше чем вариабельность CPU. И ничего лучшего чем тупо хранить исходный код и компилировать его на месте под нужный GPU там пока не придумали. Потихоньку правда есть движение в сторону того чтобы хранить не прямо сырцы а уже распарсенное фронт-эндом синтаксическое дерево.
Ну и Java там где производительность менее критична, да :)
Уважаемый сэр, обращаю Ваше внимание на один простой факт: изменение порядка суммирования float-ов меняет конечный результат.
Режим /fp:precise гарантирует что компилятор сумму посчитает именно так как написано в коде — последовательно. Ваш «код с подсказкой для компилятора» дает другой результат и если компилятор подобное сам забабахает в режиме /fp:precise то это будет ошибкой. Отсюда и наблюдается драматическая разница. Для интереса можете повторить эксперимент на сумме int-ов :)
Подобные ньюансы кажутся мелочами ровно до первого случая когда влетаешь в проблему связанную с мааааленькими ошибочками округления из-за которых программа при включении /fp:fast внезапно начинает крэшиться из-за возникнования отрицательного числа в выражении которое ну никак казалось бы отрицательным быть не может :)
Стоимость FPGA сегодня намного выше чем стоимость GPU.
Performance/watt — это да, в некоторых задачах получше, но это все равно очень нишевое получается решение
Из породистых имхо на сибиряка похож
Статья оставляет отчетливое впечатление очередного изобретения велосипеда
Кроме того, вообще говоря на улице, насколько я могу судить, интеловский RealSense реконструирует глубину по схожим с Lytro принципам и вполне может давать худшее качество
Что касается второй части — то это просто очень сырая идея и вдобавок велосипед, т.к. задача суммирования «деревом» на массивно-параллельной архитектуре является классикой программирования для GPU и очень давно подробно иследована и разобрана. Было бы любопытно увидеть результаты подобной оптимизации на суперскалярах, но как раз ее-то у Вас в статье и нет
Похожая задача в значительно более острой форме стоит для GPGPU вычислений, т.к. вариабельность GPU намного выше чем вариабельность CPU. И ничего лучшего чем тупо хранить исходный код и компилировать его на месте под нужный GPU там пока не придумали. Потихоньку правда есть движение в сторону того чтобы хранить не прямо сырцы а уже распарсенное фронт-эндом синтаксическое дерево.
Ну и Java там где производительность менее критична, да :)
Режим /fp:precise гарантирует что компилятор сумму посчитает именно так как написано в коде — последовательно. Ваш «код с подсказкой для компилятора» дает другой результат и если компилятор подобное сам забабахает в режиме /fp:precise то это будет ошибкой. Отсюда и наблюдается драматическая разница. Для интереса можете повторить эксперимент на сумме int-ов :)
Подобные ньюансы кажутся мелочами ровно до первого случая когда влетаешь в проблему связанную с мааааленькими ошибочками округления из-за которых программа при включении /fp:fast внезапно начинает крэшиться из-за возникнования отрицательного числа в выражении которое ну никак казалось бы отрицательным быть не может :)
Performance/watt — это да, в некоторых задачах получше, но это все равно очень нишевое получается решение