• Авиакатастрофа в Шереметьево: исторические аналогии
    +1
    Пилоты уже высказывались на этот счёт. Проблемы со связью никак не мешают уходу на второй круг. Вопрос о целесообразности второго круга считаю приоритетным.
  • Авиакатастрофа в Шереметьево: исторические аналогии
    +1
    Да, очевидно НАДО ждать выводов МАК. Однако теперь, когда есть видео посадки, есть один вопрос, на который МАК надо ответить. Была ли такая необходимость приземлить самолёт именно в этот заход. Предполагаю ответ МАК будет нет (дисклеймер: это моё ИМХО). Ждём официальных заключений.
    Ну а дальше… тут ссылка на инструкции была дана, что делать в случае отрыва при посадке (козлении). И она вполне чётко требует выполнения go around (ухода на второй круг).
    Земля пухом…
  • Оценка сроков на разработку и тестирование задачи (не нужна)
    0
    Я так понимаю ключевой посыл статьи состоит в том, что оценка сроков оценивается из опыта выполнения аналогичных задач.
  • Не купили DLC: функцию, которая спасла бы упавшие 737, «Боинг» продавал как опцию
    0
    Ну как бы неверно говорить, что докупка датчика исправила бы ситуацию. Так ведь ошибка ещё и в программной оценке показаний корректности датчика, которая судя по всему работала некорректно (баг или фича: так ли важно?). И насколько я знаю, они добавили 3 датчик, который включается, когда появляются подозрения на показания корректности одного из активных датчиков. И при данной проблеме подключает третий, отключая MCAS. Им конечно виднее, но имхо куда надёжнее, когда работают 3, и сравнивают показания, и отключают тот, который выдаёт погоду. И ещё много можно выдумать алгоритмов, которые также будут правиться на уровне софта.
  • Аналитика девушек с низкой социальной ответственностью (Заряжено Power BI, Qlik Sense, Tableau)
    +9
    Тот случай, когда статья чуть менее чем полностью состоит из попытки хайпануть.
  • Топ 20 ошибок при работе с многопоточностью на С++ и способы избежать их
    0
    volatile куда корректнее трактовать как отмену оптимизации, но точно не атомарность. Ну и грубый пример: если для volatile int i сложение ( i+=321; ) ещё может как-то где-то дать (но не гарантировать) атомарность, то умножение ( i *= 321;) уж точно не будет атомарным.
    Что касается отмены оптимизации, то очень даже работает в случае, когда компилятор выполняет вычисления в коде, которые без volatile смело отбрасывает.
  • ООП мертво, да здравствует ООП
    0
    Так как часто под реактивным подходом имеют ввиду что-то своё, хотелось бы уточнить что именно вы имеете ввиду, и какое решение предлагаете? Я так понимаю просто событие слать вместо добавления компоненты. Если да, то в общем то оно и устраивает.
  • Установка IPS-дисплея в Thinkpad T430S
    +1
    Два компа на столе: iMac 27" retina 5k, и Dell 24" IPS. Никаких фу-фу-фу на переходах. Это ваши субъективные ощущения. Каждый для себя сам решит, что для него фу-фу-фу.
  • ООП мертво, да здравствует ООП
    0
    Мне всё-таки не очень нравится решение с добавлением компоненты для reload и прочего. Почему бы это не делать через события? Просто это провоцирует более активную работу с динамическими компонентами, что имхо медленнее. Может есть опыт и так, и так? Чтобы прокомментировать в сравнении.

    Ну и ещё OpenWorld с ECS тоже интересная тема.
  • ООП мертво, да здравствует ООП
    0
    А ECS + UI есть опыт или какие-то мысли? Да, нет, вообще нет? Если да, то может есть пример. Возможно ECS + Events для UI?
  • ООП мертво, да здравствует ООП
    +2
    Хоть статья и понравилась. То что нужно геймдеву не увидел ни у критикуемого, ни у критикующего. Во-первых наличие методов в компоненте это какой-то отдельный пример ECS паттерна. Корректный вариант всё-таки считаю Entity — id, Component — данные(и только данные), System — алгоритм. В этом плане метод Update в компоненте это уже изначально неверный посыл (как и в куче других примеров по ECS), который перетёк в другой неверный посыл. ECS для игр в корректном варианте реализует тот самый переход AoS -> SoA, который так любят современные процы, который cache-friendly и легко масштабируется по ядрам.

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

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

    P.S. Мне так и не ясно, почему был выбран такой подход, ведь в репе Араса куда более корректный пример ECS, чем в том, который модифицирует автор статьи.
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    0
    С вами невозможно спорить ;)
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    0
    Решение напрашивается само собой. Звучит как план ;)
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    0
    Ну это уже вам давать оценку какой повреждений считать приемлемым ))) Тут упоминали Игоря Негоду. У них хвост модели успел отгореть, пока они опомнились. Так что каждый сам решает. Я бы так не рискнул, особенно учитывая стоимость движков.
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    0
    200 кг взлётный вес, 60 кг тяги. Это реально overpower.
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    +4
    Посмотрите скорость подачи топлива в двигатель на старте. Умножьте на два, если двигатели сфейлятся одновременно, но это, думаю, уже действительно маловероятно. Сколько времени надо чтобы выключить двигатель, взять огнетушитель в руки, активировать его? Посчитайте количество залитого горящего керосина. Это при условии, что он не замешкается и не ошибётся. Когда такая процедура не отработана, ошибки на нервах будут сделаны 100%. А гореть то будет возможно уже часть несущей конструкции. В этом отличие кучи огнетушителей от одного огнетушителя наготове.
  • Реактивный самолёт своими руками: «Два дебила — это сила»
    +3
    Сам планерист. Дядьки — красавчики. 60 кг тяги на примерно 200 кг (пилот же) взлётного веса это тема.
    Теперь о печальном. Походу они не отгребали пока ни разу с этими двиглами. Заводить надо вдвоём, один контролирует процесс, второй стоит с огнетушителем на готове. Не приведи господь в случае сбоя им в заднюю полость горящий керосин рекой польётся.
    Собственно потенциально возможные проблемы блокируют возможность безопасного запуска двигателей в воздухе.
  • Зачем писать свой игровой движок?
    –1
    Девочек мы все любим не за их мнение о движках… ;-)

    Про X-Ray стоит послушать самих создателей X-Ray, которые теперь в 4A. По их же словам, под новые требования, например стриминг, проще написать новый, чем править старый. А судя по последнему Метро, в движках они что-то понимают.
  • Зачем писать свой игровой движок?
    +3
    Когда игры на новом движке появятся, тогда и оценим труды. С нетерпением ждём.
  • Как собирают вагоны для пассажирских поездов
    +3
    Такой бы цикл статьей, да про самолёты.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Увы, да. Однако это проблема тех, кому нужен double.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    +1
    В основном да. Но исключения всё-таки есть. Та же _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
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Я бы не назвал это прям уж проблемой. Иногда ymm нужен именно как спаренный sse (для float индекс будет в диапазоне 0-3), а иногда как один большой регистр с независимыми числами (в этом случае для float уже нужен индекс в диапазоне 0-7). Проблема, что они вторую часть реализуют в следующем наборе, или не реализуют вообще. Как пример, выше упомянутая _mm256_permute4x64_pd.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    habr.com/post/418247/#comment_18926127
    Вдруг будут идеи.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    i7-3770:
    x86: тормозят все реализации раза в 2 от ожидаемых
    x64: все SSE быстрые, все AVX медленнее в 20-30 от ожидаемых
    На 8700K сказали не проявляется.
    AVX_v1 быстрее без стриминга. AVX_v2 быстрее со стримингом.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Бенчмарки делаю, но пока не очень получается. Пока погоду показывают. Ни линукса, ни ICC (он вроде платный) у меня под руками нет. Потом когда будут бенчмарки, затестю на том, что подвернётся.
    А пока разве только разные сайты использовать, где можно онлайн скомпилить код любым компилятором, и посмотреть результат. Но кому интересно, уже наверняка это сделали. Код то я выложил.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Как вариант приложить в коде. Но на статью, пожалуй, это не тянет. Простой набросок без транспонирования дал уже 32 такта.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    А теперь нет. Видимо над тестом придётся ещё поработать.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    В чём то вы оказались правы. Но как то странно получилось. Stream никак не сказалось на SSE версии, зато сильно портила жизнь AVX1 (ускорение 6-7 против 8-9). Архитектура IvyBridge. В целом корректно было бы IVB такты измерить. А это лишь IACA 2 может. Но они как то по разному мерят вторая с третьей.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    На AVX2 есть _mm256_permute4x64_pd, на AVX действительно придётся допиливать напильником. Но в целом, признаюсь, я далёк от double тематики.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Про это было отмечено в статье, что большие массивы данных нужны скорее на умножении матрицы на массив вершин.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Для эмуляции есть способ. Где то находил в интернетах SDK для эмуляции. С практической точки зрения SDK интересно лишь для отладки.

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

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

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

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

    80 только FPU. SSE: 32*4=64*2=128bit, AVX: 64*4=32*8=256bit.
    По сути точность несколько меньше, плата за производительность.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    habr.com/post/418247/#comment_18922625
    Пожалуй, лучше чем здесь я не отвечу.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Посмотрел. Да, это что мне нужно. Увы, ICC specific.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Согласен. Если бы компиляторы так умели, я бы точно не стал заморачиваться.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Я уверен, что всё равно найдутся несогласные. Но для меня это пройденный опыт, и я не хочу на нём останавливаться. Если вы считаете, что можете лучше с dpps, киньте сюда свою реализацию вычисления умножения с ней, которая будет лучше хотя бы 20 тактов (с учётом чтения матриц m/n и записью в результирующую матрицу r), и я публично признаю свою ошибку.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    Кстати я понял почему так вышло. Я взял те самые 4*4*4 из текста, предназначенные для одного умножения во внутреннем цикле, и перенёс их на mulps, в котором 4 умножения.
  • Ускоряем умножение матриц float 4x4 с помощью SIMD
    0
    В моём рабочем коде классов классе пишу вроде
    __forceinline __m128 __vectorcall operator + (__m128 const) const noexcept;

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