Думал можно для это использовать VPMADDUBSW из AVX2, но похоже из-за того, что потом результат нужно вручную ужимать из 16 до 8 бит получается просад производительности.
Сравнивают плавающее умножение на CPU и GPU с умножением 8 битных целых на TPU. Конечно, в итоге будет сравнение по теплу будет в сто раз. Но что интересно, заявлено что на Haswell пускали также целочисленное 8 битное умножение и оно дало в два раза большие цифры, чем плавающие операции. Что странно, ибо в AVX2 есть инструкции для умножения векторов с 8 битными элементами, что даёт 4 кратное увеличение пропускной способности по сравнению с 32 битным FP умножением, а не двукратное.
Размышления про Skylake тоже странные, ибо в серверной версии будут AVX512 инструкции, которые дадут вдвое большую ширину вектора, чем доступно в Haswell.
А ну как VS надо накатить на сервер, который стоит в специальной защищённой подсети с отдельным фаерволом с особо суровыми настройками? В моём случае было именно так.
Я не нашёл никаких дополнительных механизмов. В интернетах советовали как «включить скрипты» в настройках браузера, но не помогало. Начиная с какого-то апдейта заработало, видать там действительно была проблема где-то под капотом.
А вот хочешь поднять VS на компе за корпоративным фаерволом и с повышенными политиками безопасности и вдруг узнаёшь, что без включенных скриптов (я так и не понял что за скрипты ему нужны были, JavaScript включал) и чего-то там ещё нормально залогиниться не получается.
В общем, это может быть хорошей фичей для некоторых сценариев работы, но принуждать этим пользоваться в принудительном порядке — это уже перебор.
Интересно, решат ли вопрос с размещением процессинговых центров в России? Т.е. не будет ли проблем с властями, которые поимели некоторое время назад Мастер с Визой.
Про исключения в деструкторах я не говорил. Мало ли какие поля не инициализированы (и это нормальное состояние структуры данных). Тут всё зависит от предметной области и такое бывает вполне оправдано, не все поля бывают прибиты гвоздями к полу и инициализированы. Хотя лично я бы постарался это обрабатывать как-то иначе.
Это всё понятно. Но когда такое используют, то обычно понимают такие моменты. Вообще, очень часто множественного наследование запрещено в coding standards.
Я не спорю, что тут есть свои подводные камни, я просто привожу пример когда это вполне уместно, если не считать что это UB.
A()->B()
Если в A() произошла ошибка, он может вернуть nullptr. B() может просто проверять this на nullptr и корректно отваливаться. Когда цепочка из большого количества вызовов, это удобно. Альтернатива — это исключения возбуждать, либо проверять после каждого вызова результат. И то, и другое решение так себе. В итоге люди проверяют this на ноль.
В начале каждой из Олимпиад писали что всё пропало, ужас-ужас. Вспомнить хотя бы Сочи-2014. Чтобы понять реальное состояние дел надо дождаться окончания.
Но какое это имеет отношение к космонавтике, я понять не могу.
Размышления про Skylake тоже странные, ибо в серверной версии будут AVX512 инструкции, которые дадут вдвое большую ширину вектора, чем доступно в Haswell.
Интересует вариант с максимальной загрузкой вычислениями (у меня счётные задачи).
А вот хочешь поднять VS на компе за корпоративным фаерволом и с повышенными политиками безопасности и вдруг узнаёшь, что без включенных скриптов (я так и не понял что за скрипты ему нужны были, JavaScript включал) и чего-то там ещё нормально залогиниться не получается.
В общем, это может быть хорошей фичей для некоторых сценариев работы, но принуждать этим пользоваться в принудительном порядке — это уже перебор.
Достаточно спорное утверждение. ИМХО у нас PayPass гораздо распространённее, чем Apple Pay, PayPass и PayWave вместе взятые в США.
Я не спорю, что тут есть свои подводные камни, я просто привожу пример когда это вполне уместно, если не считать что это UB.
Если в A() произошла ошибка, он может вернуть nullptr. B() может просто проверять this на nullptr и корректно отваливаться. Когда цепочка из большого количества вызовов, это удобно. Альтернатива — это исключения возбуждать, либо проверять после каждого вызова результат. И то, и другое решение так себе. В итоге люди проверяют this на ноль.
Но какое это имеет отношение к космонавтике, я понять не могу.
Но у них есть, например, Embraer, который вполне себе успешен и конкурентоспособен.