truthfinder

Пилоты уже высказывались на этот счёт. Проблемы со связью никак не мешают уходу на второй круг. Вопрос о целесообразности второго круга считаю приоритетным.

Да, очевидно НАДО ждать выводов МАК. Однако теперь, когда есть видео посадки, есть один вопрос, на который МАК надо ответить. Была ли такая необходимость приземлить самолёт именно в этот заход. Предполагаю ответ МАК будет нет (дисклеймер: это моё ИМХО). Ждём официальных заключений.
Ну а дальше… тут ссылка на инструкции была дана, что делать в случае отрыва при посадке (козлении). И она вполне чётко требует выполнения go around (ухода на второй круг).
Земля пухом…

Я так понимаю ключевой посыл статьи состоит в том, что оценка сроков оценивается из опыта выполнения аналогичных задач.

Ну как бы неверно говорить, что докупка датчика исправила бы ситуацию. Так ведь ошибка ещё и в программной оценке показаний корректности датчика, которая судя по всему работала некорректно (баг или фича: так ли важно?). И насколько я знаю, они добавили 3 датчик, который включается, когда появляются подозрения на показания корректности одного из активных датчиков. И при данной проблеме подключает третий, отключая MCAS. Им конечно виднее, но имхо куда надёжнее, когда работают 3, и сравнивают показания, и отключают тот, который выдаёт погоду. И ещё много можно выдумать алгоритмов, которые также будут правиться на уровне софта.

Тот случай, когда статья чуть менее чем полностью состоит из попытки хайпануть.

volatile куда корректнее трактовать как отмену оптимизации, но точно не атомарность. Ну и грубый пример: если для volatile int i сложение ( i+=321; ) ещё может как-то где-то дать (но не гарантировать) атомарность, то умножение ( i *= 321;) уж точно не будет атомарным.
Что касается отмены оптимизации, то очень даже работает в случае, когда компилятор выполняет вычисления в коде, которые без volatile смело отбрасывает.

Так как часто под реактивным подходом имеют ввиду что-то своё, хотелось бы уточнить что именно вы имеете ввиду, и какое решение предлагаете? Я так понимаю просто событие слать вместо добавления компоненты. Если да, то в общем то оно и устраивает.

Два компа на столе: iMac 27" retina 5k, и Dell 24" IPS. Никаких фу-фу-фу на переходах. Это ваши субъективные ощущения. Каждый для себя сам решит, что для него фу-фу-фу.

Мне всё-таки не очень нравится решение с добавлением компоненты для reload и прочего. Почему бы это не делать через события? Просто это провоцирует более активную работу с динамическими компонентами, что имхо медленнее. Может есть опыт и так, и так? Чтобы прокомментировать в сравнении.

Ну и ещё OpenWorld с ECS тоже интересная тема.

А ECS + UI есть опыт или какие-то мысли? Да, нет, вообще нет? Если да, то может есть пример. Возможно ECS + Events для UI?

Хоть статья и понравилась. То что нужно геймдеву не увидел ни у критикуемого, ни у критикующего. Во-первых наличие методов в компоненте это какой-то отдельный пример ECS паттерна. Корректный вариант всё-таки считаю Entity — id, Component — данные(и только данные), System — алгоритм. В этом плане метод Update в компоненте это уже изначально неверный посыл (как и в куче других примеров по ECS), который перетёк в другой неверный посыл. ECS для игр в корректном варианте реализует тот самый переход AoS -> SoA, который так любят современные процы, который cache-friendly и легко масштабируется по ядрам.

Автор так ругает неверное использование принципов ООП (согласен, ещё отмечу: канонично ООП пиарили в книгах в виде 3 основных принципов: инкапсуляция, наследование, полиморфизм). При этом в качестве базы для разбора, считаю, выбран пример с неверным в корне использованием паттерна ECS, который красивый, но ужасный с точки зрения геймдева. Например: методы в компонентах (ещё и виртуальные!), dynamic_cast где он не нужен и т.д.

То что геймдеву реализация не даёт и близко. Равно и новый вариант, который переделал кривой и неработающий SoA подход на красивый, но также не дающий требуемого, AoS формат. А в правильном ECS это одна из ключевых фишек. Которая обычно не работает без ручного аллокатора.

P.S. Мне так и не ясно, почему был выбран такой подход, ведь в репе Араса куда более корректный пример ECS, чем в том, который модифицирует автор статьи.

С вами невозможно спорить ;)

Решение напрашивается само собой. Звучит как план ;)

Ну это уже вам давать оценку какой повреждений считать приемлемым ))) Тут упоминали Игоря Негоду. У них хвост модели успел отгореть, пока они опомнились. Так что каждый сам решает. Я бы так не рискнул, особенно учитывая стоимость движков.

200 кг взлётный вес, 60 кг тяги. Это реально overpower.

Посмотрите скорость подачи топлива в двигатель на старте. Умножьте на два, если двигатели сфейлятся одновременно, но это, думаю, уже действительно маловероятно. Сколько времени надо чтобы выключить двигатель, взять огнетушитель в руки, активировать его? Посчитайте количество залитого горящего керосина. Это при условии, что он не замешкается и не ошибётся. Когда такая процедура не отработана, ошибки на нервах будут сделаны 100%. А гореть то будет возможно уже часть несущей конструкции. В этом отличие кучи огнетушителей от одного огнетушителя наготове.

Сам планерист. Дядьки — красавчики. 60 кг тяги на примерно 200 кг (пилот же) взлётного веса это тема.
Теперь о печальном. Походу они не отгребали пока ни разу с этими двиглами. Заводить надо вдвоём, один контролирует процесс, второй стоит с огнетушителем на готове. Не приведи господь в случае сбоя им в заднюю полость горящий керосин рекой польётся.
Собственно потенциально возможные проблемы блокируют возможность безопасного запуска двигателей в воздухе.

Девочек мы все любим не за их мнение о движках… ;-)

Про X-Ray стоит послушать самих создателей X-Ray, которые теперь в 4A. По их же словам, под новые требования, например стриминг, проще написать новый, чем править старый. А судя по последнему Метро, в движках они что-то понимают.

Когда игры на новом движке появятся, тогда и оценим труды. С нетерпением ждём.

Такой бы цикл статьей, да про самолёты.

Увы, да. Однако это проблема тех, кому нужен double.

В основном да. Но исключения всё-таки есть. Та же _mm256_permute4x64_pd.

SELECT4(src, control){
	CASE(control[1:0])
	0:	tmp[63:0] := src[63:0]
	1:	tmp[63:0] := src[127:64]
	2:	tmp[63:0] := src[191:128]
	3:	tmp[63:0] := src[255:192]
	ESAC
	RETURN tmp[63:0]
}

dst[63:0] := SELECT4(a[255:0], imm8[1:0])
dst[127:64] := SELECT4(a[255:0], imm8[3:2])
dst[191:128] := SELECT4(a[255:0], imm8[5:4])
dst[255:192] := SELECT4(a[255:0], imm8[7:6])
dst[MAX:256] := 0

Я бы не назвал это прям уж проблемой. Иногда ymm нужен именно как спаренный sse (для float индекс будет в диапазоне 0-3), а иногда как один большой регистр с независимыми числами (в этом случае для float уже нужен индекс в диапазоне 0-7). Проблема, что они вторую часть реализуют в следующем наборе, или не реализуют вообще. Как пример, выше упомянутая _mm256_permute4x64_pd.

habr.com/post/418247/#comment_18926127
Вдруг будут идеи.

i7-3770:
x86: тормозят все реализации раза в 2 от ожидаемых
x64: все SSE быстрые, все AVX медленнее в 20-30 от ожидаемых
На 8700K сказали не проявляется.
AVX_v1 быстрее без стриминга. AVX_v2 быстрее со стримингом.

Бенчмарки делаю, но пока не очень получается. Пока погоду показывают. Ни линукса, ни ICC (он вроде платный) у меня под руками нет. Потом когда будут бенчмарки, затестю на том, что подвернётся.
А пока разве только разные сайты использовать, где можно онлайн скомпилить код любым компилятором, и посмотреть результат. Но кому интересно, уже наверняка это сделали. Код то я выложил.

Как вариант приложить в коде. Но на статью, пожалуй, это не тянет. Простой набросок без транспонирования дал уже 32 такта.

А теперь нет. Видимо над тестом придётся ещё поработать.

В чём то вы оказались правы. Но как то странно получилось. Stream никак не сказалось на SSE версии, зато сильно портила жизнь AVX1 (ускорение 6-7 против 8-9). Архитектура IvyBridge. В целом корректно было бы IVB такты измерить. А это лишь IACA 2 может. Но они как то по разному мерят вторая с третьей.

На AVX2 есть _mm256_permute4x64_pd, на AVX действительно придётся допиливать напильником. Но в целом, признаюсь, я далёк от double тематики.

Про это было отмечено в статье, что большие массивы данных нужны скорее на умножении матрицы на массив вершин.

Для эмуляции есть способ. Где то находил в интернетах SDK для эмуляции. С практической точки зрения SDK интересно лишь для отладки.

Здесь вскользь упомянут вариант, как делать для разных платформ. Пишем разные реализации, и потом после анализа процессора через cpuid подставляем нужный указателю на функцию. И потом работаем с данным функционалом через указатель. Данный подход полезен для больших, ёмких операций. Если использовать его для одной инструкции — точно будет только хуже.

Как пример: функция для умножения матрицы на вектор — станет медленнее, функция для умножения матрицы на массив векторов — имеет смысл.

Гибкий вариант есть здесь optimizing_cpp.pdf. Искать по: CriticalFunction_Dispatch.

При миграции с SSE на AVX (повышение разрядности инструкций), сможет с минимальными изменениями. В SSE регистр вмещалось 4 float, в AVX 4 double. Если на той же разрядности регистров нужен double, тогда придётся переписывать.

80 только FPU. SSE: 32*4=64*2=128bit, AVX: 64*4=32*8=256bit.
По сути точность несколько меньше, плата за производительность.

habr.com/post/418247/#comment_18922625
Пожалуй, лучше чем здесь я не отвечу.

Посмотрел. Да, это что мне нужно. Увы, ICC specific.

Согласен. Если бы компиляторы так умели, я бы точно не стал заморачиваться.

Я уверен, что всё равно найдутся несогласные. Но для меня это пройденный опыт, и я не хочу на нём останавливаться. Если вы считаете, что можете лучше с dpps, киньте сюда свою реализацию вычисления умножения с ней, которая будет лучше хотя бы 20 тактов (с учётом чтения матриц m/n и записью в результирующую матрицу r), и я публично признаю свою ошибку.

Кстати я понял почему так вышло. Я взял те самые 4*4*4 из текста, предназначенные для одного умножения во внутреннем цикле, и перенёс их на mulps, в котором 4 умножения.

В моём рабочем коде классов классе пишу вроде
__forceinline __m128 __vectorcall operator + (__m128 const) const noexcept;

Однако здесь всё итак работает хорошо. Всегда проверяю сгенерированный ассемблерный код. Насчёт *assume_aligned я посмотрю что это. Скорее всего то, чего мне сильно и давно не хватает. Но если оно linux/intel_compiler/… specific, то мне, к сожалению, не подойдёт.