Исследуя материал для доклада по ветвлениям внутри студии, я пришел к выводу, что данный штраф не так критичен, учитывая, что в среднем лишь 5% предсказаний ошибочны. Непредсказуемые ветвления — это минус, но большинство из них хорошо поддаются профилированию в горячих функциях и их хорошо видно что в PIXe, что в Razor'e. Оптимизировать алгоритм имеет смысл только там, где профилировщик выявляет проблемы. За последние двадцать лет процессоры стали более устойчивыми к неоптимизированному коду, а компиляторы научились его оптимизировать, так что оптимизация ветвлений ранзыми костылями и хаками из конца 90-х уже не так актуальна и требуется в основном для максимального увеличения производительности уже на этапах пост профилировки релиза.
Branch-order-buffer завезли в x86 вроде бы в Nehalem (как и почти всё перечисленное - изобретения 1960-1970 годов). Раньше branch missprediction стоил сотни такотов. Начиная с Nehalem (благодаря BOB) - длину конвейра.
У банок SRAM(вообще у любых но у SRAM в частности тоже) есть ограничение по глубине/частоте. А поскольку у вас ширина задана - то фактически ограничение на максимальный объём банки. Это во-вторых.
Во-главных же: вы просто не разведёте (на этапе физ-дизайна) достаточно большой кэш за достаточно маленькое число тактов. Чисто теоретические модели - могут дать логарифмическое время доступа от размера, но на практике они слабо применимы.
Ну и в итоге вы балансируете (на своём наборе нагрузок): cache_hit_prob * cache_hit_time + (1 - cache_hit_prob) * cache_miss_time.
Реальная ставка НДС (она же налоговая нагрузка от НДС) = 6.6% рассчитывается, как: (поступления-НДС-внутренний + поступления-НДС-таможенный) / ВВП.
Т.е. берём весь собранный НДС, весь ВВП и делим первое на второе. Это позволит усреднить "шаурму с 0%" + "кондиционер с 20%" + "квартиру с не разберись сколько возвращено".
Но в целом налоговая нагрузка в РФ меньше чем в среднем в ЕС, о чём вам уже написали.
Я отвечал на верхний комментарий. В частности времена, когда "ВУЗ за ручку приведёт талантливых ребят" - давно прошли. Студентов, как минимум в системном программировании, уже давно надо хантить.
А в целом - рынок найма довольно сильно испорчен и перекошен. И с точки зрения "рынка в целом" - такая инициатива Я попытка крупнейшего игрока исправить ситуацию стандартными и доброкачественными рыночными методами (разумеется попутно заработав денег на хорошей рыночной услуге).
Вот я в системном программировании три мои последние конторы взаимодействовали с ВУЗ-ами.
Ну что могу сказать - студентов ВУЗов надо брать со 2-3 курсов (иначе уведут) учить 2-3 года на своей кафедре (тратить время синьоров), платить деньги (иначе уйдёт к другим), чтобы 30-50% из них через 2 года осталась у тебя за рыночную ЗП.
Вот я на прошлой работе занимался наймом себе в отдел. Через 3 недели сформировал позицию - кандидатов после курсов с менее года опыта не рассматриваем.
На текущей работе и позапрошлой (я не занимаюсь наймом) тоже людей после курсов вообще не рассматривают.
Ну вы средний по тем временам (когда фильтр входа в профессию был "спать не могу как интересно пока программу ХХ не допишу" - я если что бывало до 2 ночи лежал думал, а потом когда родители засыпали вставал и за комп дописывать прогу садился). По нынешним у вас фора в виде офигенного буста в начале карьеры + 15 лет опыта.
не гнался
Кажется (могу ошибаться, но неоднократно видел такое в жизни) вы попали в ту же ловушку, что и "блатной продавец в СССР" -> "продавец пятёрочки" (к счастью для вас - на пару уровней выше).
Зачем мне напрягаться мне и так неплохо? А потом прогресс и технологичность дошли до вашей области. И всем кто не напрягался и почевал на лаврах присунули "трекер рабочего времени". Теперь напрягаться по стрессу и/или часам работы - что в линейном персонале что в условных архитекторах/principal engineer надо примерно одинаково. Только у архитектов и ЗП повыше и задачи поинтереснее. А прыгнуть с вашей текущей линейной позиции в principal - уже ой как не просто.
По большому счету очередная история как в моей молодости пломбир был вкуснее
Да нет же. Просто обычная жизненная история: с ослаблением отбора падает средний уровень навыка.
Другой вопрос, что "вот такой вот как сейчас рынок", - это факт объективный. На него можно жаловаться его можно не любить, но это объективный факт. С ним вам жить в любом случае.
А вопрос, который вызывает подозрения - как такой замечательный супер-программист оказался +/- в медиане рынка на +/- рядовых позициях. Что-то какое-то несоответствие заявленной позиции и наблюдаемых эффектов.
Мне кажется вот и ответ на вопрос: - когда профессия свернула не туда? - когда умение понять алгоритм дийкстры (с соответствующим комментом) стало признаком синьора.
Я бы добавил (разумеется это вкусовщина) - курс Андрея Карпатого. Neural Networks: Zero to Hero (примечательно, он опубликован также и во Вконтакте: Neural Networks: Zero to Hero )
Скажем так - если его смотришь и всё понимаешь (желательно и "что" и "как" и "почему") - то в принципе первые две части, можно пропускать.
Если совсем кратко: - в кольцевой буфер кладём инструкции - регистры разыменовываем с дополнительным уровнем косности (т.е. не AX, а reg-112) - когда все регистры инструкции готовы - инструкцию на исполнение - когда инструкция исполнилась - оповещаем, что её регистр (переименованный) готов на общую шину - фиксируем все исполненные подряд идущие инструкции из хвоста очереди (это называется retire).
Кажется, что перевод этой статьи - пустая трата сил. (Во-вторых: есть сильные подозрения, что в статье - в целях сокрытия деталей от конкурентов - в некоторых важных деталях прямо наврано).
Главная же проблема - чтобы полезно для себя читать эту статью, требуются сначала предварительные материалы минимум на 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 - использовать на одинаковых устройствах).
Branch-order-buffer завезли в x86 вроде бы в Nehalem (как и почти всё перечисленное - изобретения 1960-1970 годов).
Раньше branch missprediction стоил сотни такотов. Начиная с Nehalem (благодаря BOB) - длину конвейра.
Ссылка почитать:
https://www.realworldtech.com/sandy-bridge/3/
Из всего описанного в статье - вроде бы только TLB и SIMT появились не в 1960-1970.
У банок SRAM(вообще у любых но у SRAM в частности тоже) есть ограничение по глубине/частоте. А поскольку у вас ширина задана - то фактически ограничение на максимальный объём банки. Это во-вторых.
Во-главных же: вы просто не разведёте (на этапе физ-дизайна) достаточно большой кэш за достаточно маленькое число тактов.
Чисто теоретические модели - могут дать логарифмическое время доступа от размера, но на практике они слабо применимы.
Ну и в итоге вы балансируете (на своём наборе нагрузок):
cache_hit_prob * cache_hit_time + (1 - cache_hit_prob) * cache_miss_time.
В РФ НДС от 0% до 20%.
Реальный 6.6%.
Реальная ставка НДС (она же налоговая нагрузка от НДС) = 6.6%
рассчитывается, как: (поступления-НДС-внутренний + поступления-НДС-таможенный) / ВВП.
Т.е. берём весь собранный НДС, весь ВВП и делим первое на второе. Это позволит усреднить "шаурму с 0%" + "кондиционер с 20%" + "квартиру с не разберись сколько возвращено".
Но в целом налоговая нагрузка в РФ меньше чем в среднем в ЕС, о чём вам уже написали.
Я отвечал на верхний комментарий. В частности времена, когда "ВУЗ за ручку приведёт талантливых ребят" - давно прошли. Студентов, как минимум в системном программировании, уже давно надо хантить.
А в целом - рынок найма довольно сильно испорчен и перекошен.
И с точки зрения "рынка в целом" - такая инициатива Я попытка крупнейшего игрока исправить ситуацию стандартными и доброкачественными рыночными методами (разумеется попутно заработав денег на хорошей рыночной услуге).
Вот я в системном программировании три мои последние конторы взаимодействовали с ВУЗ-ами.
Ну что могу сказать - студентов ВУЗов надо брать со 2-3 курсов (иначе уведут) учить 2-3 года на своей кафедре (тратить время синьоров), платить деньги (иначе уйдёт к другим), чтобы 30-50% из них через 2 года осталась у тебя за рыночную ЗП.
А в чём проблема?
Вот я на прошлой работе занимался наймом себе в отдел. Через 3 недели сформировал позицию - кандидатов после курсов с менее года опыта не рассматриваем.
На текущей работе и позапрошлой (я не занимаюсь наймом) тоже людей после курсов вообще не рассматривают.
Медианную ЗП считать не правильно.
Т.к. женщины у нас работуют больше "чтобы можно было ребёнка в\из садика забирать, а ещё на больничном с ним сидеть, а ещё....".
Т.е. фактически правильно считать либо медианную для мужчин либо медианную по домохозяйствам.
Ну вы средний по тем временам (когда фильтр входа в профессию был "спать не могу как интересно пока программу ХХ не допишу" - я если что бывало до 2 ночи лежал думал, а потом когда родители засыпали вставал и за комп дописывать прогу садился).
По нынешним у вас фора в виде офигенного буста в начале карьеры + 15 лет опыта.
Кажется (могу ошибаться, но неоднократно видел такое в жизни) вы попали в ту же ловушку, что и "блатной продавец в СССР" -> "продавец пятёрочки" (к счастью для вас - на пару уровней выше).
Зачем мне напрягаться мне и так неплохо?
А потом прогресс и технологичность дошли до вашей области. И всем кто не напрягался и почевал на лаврах присунули "трекер рабочего времени".
Теперь напрягаться по стрессу и/или часам работы - что в линейном персонале что в условных архитекторах/principal engineer надо примерно одинаково. Только у архитектов и ЗП повыше и задачи поинтереснее. А прыгнуть с вашей текущей линейной позиции в principal - уже ой как не просто.
Да нет же. Просто обычная жизненная история: с ослаблением отбора падает средний уровень навыка.
Другой вопрос, что "вот такой вот как сейчас рынок", - это факт объективный. На него можно жаловаться его можно не любить, но это объективный факт. С ним вам жить в любом случае.
А вопрос, который вызывает подозрения - как такой замечательный супер-программист оказался +/- в медиане рынка на +/- рядовых позициях. Что-то какое-то несоответствие заявленной позиции и наблюдаемых эффектов.
Мне кажется вот и ответ на вопрос:
- когда профессия свернула не туда?
- когда умение понять алгоритм дийкстры (с соответствующим комментом) стало признаком синьора.
Так в том и дело, что требования бестолковы - не отражают сути того, что нужно.
Если "общего здравого смысла" нет - то они бесполезны.
Если же общий здравый смысл присутствует - то гораздо проще и полезнее избавиться от ТЗ и сразу писать "что нужно".
Именно поэтому эти недоформализмы и заменяются (где не приколочены законодательными гвоздями) - на "use case / user story", конкретные примеры.
Очень качественная подборка.
Я бы добавил (разумеется это вкусовщина) - курс Андрея Карпатого.
Neural Networks: Zero to Hero (примечательно, он опубликован также и во Вконтакте: Neural Networks: Zero to Hero )
Скажем так - если его смотришь и всё понимаешь (желательно и "что" и "как" и "почему") - то в принципе первые две части, можно пропускать.
По сути идея - два фронтэнда (fetch \ decode \ issue) : один бэкэнд.
Это максимально просто и понятно на уровне идеи.
А вот чтобы понять дальше - нужно объяснять про современные процессорные архитектурные, что совершенно упущено в статье.
Бэкэнд, в современных ОоО-процессорах даже близко не похож на то, как на картинке, а представляет собой развитие вот этого подхода:
https://translated.turbopages.org/proxy_u/en-ru.ru.5f38ea06-66c539fc-e3c02850-74722d776562/https/en.wikipedia.org/wiki/Tomasulo%27s_algorithm
Если совсем кратко:
- в кольцевой буфер кладём инструкции
- регистры разыменовываем с дополнительным уровнем косности (т.е. не AX, а reg-112)
- когда все регистры инструкции готовы - инструкцию на исполнение
- когда инструкция исполнилась - оповещаем, что её регистр (переименованный) готов на общую шину
- фиксируем все исполненные подряд идущие инструкции из хвоста очереди (это называется retire).
Кажется, что перевод этой статьи - пустая трата сил.
(Во-вторых: есть сильные подозрения, что в статье - в целях сокрытия деталей от конкурентов - в некоторых важных деталях прямо наврано).
Главная же проблема - чтобы полезно для себя читать эту статью, требуются сначала предварительные материалы минимум на 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 - использовать на одинаковых устройствах).