Кажется, что перевод этой статьи - пустая трата сил. (Во-вторых: есть сильные подозрения, что в статье - в целях сокрытия деталей от конкурентов - в некоторых важных деталях прямо наврано).
Главная же проблема - чтобы полезно для себя читать эту статью, требуются сначала предварительные материалы минимум на 2 таких статью (это если прям супер-ускоренно).
Хотябы самая верхнеуровневая проблематика: - что имеем - какие проблемы есть - какие проблемы хотим решить - способ решения.
Уязвимость со спекулятивным исполнением (к стати нигде даже мельком не видел, чтобы такие атаки реально работали и применялись, в отличии от дыр в ПО).
SMT - лишь один из способов заэксплуатировать (через общий L1D-Cache) эту уязвимость.
Как по мне - так проблема в кэшах (о том, что два потока исполнения начинают конкурировать за L1D-Cache процессора вытесняя данные друг-друга написано в конце и очень вскользь). Я бы связал это с тем, что сейчас более модный (и возможно более правильный) подход - с P/E ядрами.
Если вам нужна фоновая работа (как правило не требующая высокой производительности) это планируют на [E]fficient - ядро). Для задач с высокой производительностью вам нужно P[ower] ядро. И за L1D-Cache они между собой не конкурируют.
П.С. Другой вопрос - как в data-центрах продавать процессорное время с SMT-процами. Linux же считает сколько задача была спланирована на ядре. Сколько реально она выполнялась - зависит от параллельной нагрузки. Клиенты могут быть ОЧЕНЬ сильно недовольны.
Микроинструкции не имеют отношения к потокам исполнения, а только о числу execution-units (в современных процессорах перед каждым из них своя очередь ожидающих инструкций).
И да не слышал, чтобы Apple (если M2 M3 - это про Apple) использовали SMT (нам cache throttling между ядрами может начаться - в статье об этом неприлично вскользь сказано) - сейчас подход P/E ядра.
Можете объяснить типовые use-case - зачем вообще вести личную "базу знаний" (разумеется какой-то ежедневник "не забыть сделать Х" - вести надо)?
Пробовал вести - понял, что это для меня лично бесполезно (хотя и и лекции-то в универе не писал). И с тех пор действительно не понимаю зачем людям "личная база знаний".
- Идеи - надо понимать (а когда вернёшься к этой же идее через год - предположим эта идея не частая - ты подойдёшь к ней с бОльшим кругозором и запасом знаний, прошлогодние "тактические соображения" скорее всего окажутся нерелевантными); - Справочную информацию - надо искать в справочниках. - Конкретный рецепт "как сделать Х при помощи 3 технологий" - надо хранить в доке проекта.
Если говорить серьёзно по теме статьи, то три киллера С++ (в порядке увеличения их значимости): 1. С++ 2. Go 3. Rust.
Го подпирает С++ "сверху", как язык более высокоуровневый, Rust снизу, как более низкоуровневый, а сам С++ - стимулирует программистов переходить на другие, более удобные \ безопасные whatsoever языки.
1. Многочленная модель в 3 раза быстрее стандартной синусной функции, если собрать её при помощи clang 11 и опциями -O2 -march=native, а затем выполнить на Intel Core i7-9700F. Но, если собрать её при помощи NVCC с опциями --use-fast-math и выполнить на GPU, а именно на GeForce GTX 1050 Ti Mobile, то стандартная синусная функция окажется в 10 раз быстрее многочленной модели.
Это мне напомнило детские приколы. Кто быстрее: черепаха или Усэйн Болт? А если Усейну ноги в бетон залить?
при "use fast math" - у вас будут не синусы, а функции, отдалённо их напоминающие (там ошибка уж очень большая). Что по-хорошему должно отдельно указываться в ТЗ (для нейросеток с пониженной точностью пойдут, только если learning и inference - использовать на одинаковых устройствах).
> (который, если персонаж с такой аватаркой на сайте один - вы в сознательном возрасте не застали) - мы поняли.
Телепат из вас, как из козла - балерина.
Логическое выражение "Если А то Б" (импликация) ложно только в случае верности первого аргумента и одновременной ложности второго (ссылку на вики прикладываю https://ru.wikipedia.org/wiki/Импликация).
Да действительно, учитывая вашу логическую ошибку вести дальнейший диалог малопродуктивно. На этом разойдёмся.
Мне кажется что вы умудрились сделать настолько усложнённое с одной стороны (начиная с "шахматной доски" - т.е. двумерной адресации там где нужна одномерная), и настолько неполное с другой (define constexpr параметр шаблона), объяснение - что если человек даже начал что-то понимать, это объяснение собьёт его с толку.
Когда я искал первую работу (программист \ сисадмин в Тамбове) - ЗП программиста была чуть ниже ЗП водителя. При этом зарплаты могли отличаться от конторы к конторе, но отношение оставалось тем же - IT-шников местные владельцы бизнесов оценивали чуть ниже чем водителей.
Нагуглил, что цены на яйца обладают сезонностью. В августе как раз дно цен, что вероятно связано с доступностью кормов - отсутствует необходимость в хранении.
К сожалению "общая картинка" нагуглилась только по 2013 год - но наличие сезонности цен очевидно.
С 1950 годов постоянно шёл процесс концентрации компетенций вверху и упрощения работы линейного персонала. Из-за этого линейный персонал имел две опции: - превращаться в "могу копать могу не копать" и иметь снижение ЗП - становится из рабочего - высококвалифицированным рабочим -> технологом -> инженером...
В IT этот процесс пришёл позднее, но пришёл (сначала для "могу прокладывать кабель могу не прокладывать", потом для "могу перекладывать JSON могу не перекладывать).
Вы пишете так, будто считали, что процесс концентрации компетенций никогда не придёт в IT. Каковы были ваши основания так считать?
Так распределение не плоское. Если предположить, что 80% набирают 8-12 из 13, то вероятность уже будет: 4/5 * 5/12 = 1/3. А получить одинаково во всех тестах: 1/3^4 = 81.
Как писалось в детской книжке про вероятности: "я поставил машину против рубля, что следующие 100 человек проходящие мимо не будут мужчинами - и навстречу прошла рота солдат".
Теоретически - да. На практике - для детей это не подходит.
Самый очевидный (на самом деле список весьма длинный): Ежегодная прививка ВОЗ - от 3 штаммов гриппа. За год - всяко больше чем 3 заболеваниями дети переболеют.
Учтите, что подбор паролей параллелится почти идеально.
Это значит, что условная RTX 4090 в 100 раз производительнее CPU. Т.е. поставив одну 4090 мы 24 года рассчётов превращаем в 4 месяца. Что будет если поставить несколько - считайте сами.
Потому, что это "жадный алгоритм" (а если "жадный алгоритм" применят все - то это будет "глупый алгоритм") - тебе выгодно чтобы вот только это благо (например лифт) считали по жетонам, а пользование тротуаром не считали.
И если переводить все общественные блага на "жетончики" - то в проигрыше будут вообще все, т.к. зачастую расходы на взимание транзакционных платежей превосходят расходы на содержание.
Кажется, что перевод этой статьи - пустая трата сил.
(Во-вторых: есть сильные подозрения, что в статье - в целях сокрытия деталей от конкурентов - в некоторых важных деталях прямо наврано).
Главная же проблема - чтобы полезно для себя читать эту статью, требуются сначала предварительные материалы минимум на 2 таких статью (это если прям супер-ускоренно).
Хотябы самая верхнеуровневая проблематика:
- что имеем
- какие проблемы есть
- какие проблемы хотим решить
- способ решения.
Уязвимость со спекулятивным исполнением (к стати нигде даже мельком не видел, чтобы такие атаки реально работали и применялись, в отличии от дыр в ПО).
SMT - лишь один из способов заэксплуатировать (через общий L1D-Cache) эту уязвимость.
Как по мне - так проблема в кэшах (о том, что два потока исполнения начинают конкурировать за L1D-Cache процессора вытесняя данные друг-друга написано в конце и очень вскользь).
Я бы связал это с тем, что сейчас более модный (и возможно более правильный) подход - с P/E ядрами.
Если вам нужна фоновая работа (как правило не требующая высокой производительности) это планируют на [E]fficient - ядро). Для задач с высокой производительностью вам нужно P[ower] ядро. И за L1D-Cache они между собой не конкурируют.
П.С.
Другой вопрос - как в data-центрах продавать процессорное время с SMT-процами.
Linux же считает сколько задача была спланирована на ядре.
Сколько реально она выполнялась - зависит от параллельной нагрузки. Клиенты могут быть ОЧЕНЬ сильно недовольны.
Микроинструкции не имеют отношения к потокам исполнения, а только о числу execution-units (в современных процессорах перед каждым из них своя очередь ожидающих инструкций).
И да не слышал, чтобы Apple (если M2 M3 - это про Apple) использовали SMT (нам cache throttling между ядрами может начаться - в статье об этом неприлично вскользь сказано) - сейчас подход P/E ядра.
Можете объяснить типовые use-case - зачем вообще вести личную "базу знаний" (разумеется какой-то ежедневник "не забыть сделать Х" - вести надо)?
Пробовал вести - понял, что это для меня лично бесполезно (хотя и и лекции-то в универе не писал). И с тех пор действительно не понимаю зачем людям "личная база знаний".
- Идеи - надо понимать (а когда вернёшься к этой же идее через год - предположим эта идея не частая - ты подойдёшь к ней с бОльшим кругозором и запасом знаний, прошлогодние "тактические соображения" скорее всего окажутся нерелевантными);
- Справочную информацию - надо искать в справочниках.
- Конкретный рецепт "как сделать Х при помощи 3 технологий" - надо хранить в доке проекта.
Если говорить серьёзно по теме статьи, то три киллера С++ (в порядке увеличения их значимости):
1. С++
2. Go
3. Rust.
Го подпирает С++ "сверху", как язык более высокоуровневый, Rust снизу, как более низкоуровневый, а сам С++ - стимулирует программистов переходить на другие, более удобные \ безопасные whatsoever языки.
Это мне напомнило детские приколы. Кто быстрее: черепаха или Усэйн Болт?
А если Усейну ноги в бетон залить?
при "use fast math" - у вас будут не синусы, а функции, отдалённо их напоминающие (там ошибка уж очень большая). Что по-хорошему должно отдельно указываться в ТЗ (для нейросеток с пониженной точностью пойдут, только если learning и inference - использовать на одинаковых устройствах).
Логическое выражение "Если А то Б" (импликация) ложно только в случае верности первого аргумента и одновременной ложности второго (ссылку на вики прикладываю https://ru.wikipedia.org/wiki/Импликация).
Да действительно, учитывая вашу логическую ошибку вести дальнейший диалог малопродуктивно. На этом разойдёмся.
Мне кажется что вы умудрились сделать настолько усложнённое с одной стороны (начиная с "шахматной доски" - т.е. двумерной адресации там где нужна одномерная), и настолько неполное с другой (define constexpr параметр шаблона), объяснение - что если человек даже начал что-то понимать, это объяснение собьёт его с толку.
То, что вам захотелось поругать СССР (который, если персонаж с такой аватаркой на сайте один - вы в сознательном возрасте не застали) - мы поняли.
Только какое отношение ваше сообщение имеет к исходному тезису?
Если стейки готовят из говядины - значит ли это, что нам и суши с пельменями правильно готовить из говядины?
Но стоит один раз сказать "фигли ты не по ТЗ сделал, идиот" - и итальянская забастовка в виде идеального соблюдения ТЗ обеспечена.
Ситуация абсолютно несимметрична и в обратную сторону выправляется крайне сложно.
Когда я искал первую работу (программист \ сисадмин в Тамбове) - ЗП программиста была чуть ниже ЗП водителя.
При этом зарплаты могли отличаться от конторы к конторе, но отношение оставалось тем же - IT-шников местные владельцы бизнесов оценивали чуть ниже чем водителей.
Нагуглил, что цены на яйца обладают сезонностью. В августе как раз дно цен, что вероятно связано с доступностью кормов - отсутствует необходимость в хранении.
К сожалению "общая картинка" нагуглилась только по 2013 год - но наличие сезонности цен очевидно.
С 1950 годов постоянно шёл процесс концентрации компетенций вверху и упрощения работы линейного персонала.
Из-за этого линейный персонал имел две опции:
- превращаться в "могу копать могу не копать" и иметь снижение ЗП
- становится из рабочего - высококвалифицированным рабочим -> технологом -> инженером...
В IT этот процесс пришёл позднее, но пришёл (сначала для "могу прокладывать кабель могу не прокладывать", потом для "могу перекладывать JSON могу не перекладывать).
Вы пишете так, будто считали, что процесс концентрации компетенций никогда не придёт в IT.
Каковы были ваши основания так считать?
Так распределение не плоское.
Если предположить, что 80% набирают 8-12 из 13, то вероятность уже будет: 4/5 * 5/12 = 1/3.
А получить одинаково во всех тестах: 1/3^4 = 81.
Как писалось в детской книжке про вероятности: "я поставил машину против рубля, что следующие 100 человек проходящие мимо не будут мужчинами - и навстречу прошла рота солдат".
Теоретически - да.
На практике - для детей это не подходит.
Самый очевидный (на самом деле список весьма длинный):
Ежегодная прививка ВОЗ - от 3 штаммов гриппа.
За год - всяко больше чем 3 заболеваниями дети переболеют.
Вы считаете, что пример со вскрытием гигабайтного rar - хороший (близкий к репрезентативному) пример в даном случае?
Учтите, что подбор паролей параллелится почти идеально.
Это значит, что условная RTX 4090 в 100 раз производительнее CPU.
Т.е. поставив одну 4090 мы 24 года рассчётов превращаем в 4 месяца.
Что будет если поставить несколько - считайте сами.
У героев-3 есть киллер-фича: можно сыграть карту (даже карту по сети с другом) за вечер.
Эта киллер-фича перекрывает всё, вклчая устаревшие механики и скучные (по сравнению, скажем с Героями-5) бои.
ПС
Почему этой киллер-фичи не понимают сами разработчики серии (Heroes-VII - лучшая игра серии, кроме этой единственной киллер-фичи) - я не понимаю.
GoLang подойдёт?
Если нет - то уточните пожалйста критерии.
Потому, что это "жадный алгоритм" (а если "жадный алгоритм" применят все - то это будет "глупый алгоритм") - тебе выгодно чтобы вот только это благо (например лифт) считали по жетонам, а пользование тротуаром не считали.
И если переводить все общественные блага на "жетончики" - то в проигрыше будут вообще все, т.к. зачастую расходы на взимание транзакционных платежей превосходят расходы на содержание.