Как человек живший в 3 домах с мусоропроводом (и последним без) - заявляю, что вам очень повезло.
Проблема мусоропровода в том, что достаточно на 3 дня "подзабить" на него (управляшка воюет с ресурсниками) и запах обеспечен. Достаточно на 2 недели подзабить на него и невыводимый запах, а значит разная живность (от крыс до тараканов) обеспечена.
И да как нормально и без запаха работает мусоропровод у моей тёщи в Мск - я не знаю и считаю чудом.
ок, вполне возможно (я не статью критикую, если что - а данный конкретный случай).
Забавно, что данный случай (UB в компиляторе) это вариант практической инженерии и к сводимости \ несводимости к State Machine вообще отношения не имеет.
Просто используйте в компиляторе только эквивалентные преобразования (и запретите потенциально неэквивалентные) - и будет вам счастье. А что там где-то вне вашего innermost цикла, который вы вылизали есть какое-то зависание - да и бог с ним.
Блин вот комментатор выше "поумничал". Но вы то повелись зачем?
Конечность (сводимость к state machine) / бесконечность потенциальных данных вообще тут не при чём. Компилятор просто делает эквивалентные преобразования одного языка к другому (пока не перейдёт от условного C++ к условному IA32 / x86-64).
и легко можно выделить подмножество преобразований, которые безусловно корректны (почти весь peephole, существенная часть GSH (но не все из-за бесконечных циклов), существенная часть inlining).
> если сравнить плохоньких программистов с передовыми девопсами А к чему вообще проводить такие сравнения? Мне они кажутся заведомо манипулятивными.
Чтобы стать хорошим программистом - надо сломать себе мозг разными античеловеческими концепциями (один раз, но надо - хотя бы освоить их до уровня навыка), типа "потока управления, программного стэка, представления объектов в памяти".... Т.к. сравниваем ты будешь всегда с людьми, которые в профильных старших классах \ начальных курсах "поняли рекурсию".
DevOps же - гораздо ближе, в этом смысле к любой другой обычной человеческой технологической деятельности (не IT), типа починке телевизоров, приведению в порядок автохлама и т.д.
можно было бы закончить и отправить автора учить матчасть.
Авторов таких "разоблачительных" комментариев следовало бы отправить изучать экономику, в частности что такое "минимальный [экономически выгодный] эффект масштаба (см. ссылку)".
Касательно темы: как по мне это глупость - говорить про UB при разыменовании, например. Какое языку программирования C должно быть дело, что там разыменовывают с помощью mov dword ptr [rax]?
Касательно темы - UB в стандарте сформулировано таким образом (поведение не определено), что компилятор имеет право вести себя так, будто UB в коде нет, т.к. если UB произошло - то программа просто как-бы отменила всё ранее сделанное.
Последние лет 10 (1) - компиляторы стали этим злоупотреблять (2), - и просто помечать весь код, содержащий UB как недостижимый, что привело не только к выкидыванию самого кода с UB, но и к compile-time наложению условий на значение переменных, которые "таковы, что UB не произойдёт".
1) после того, как компиляторы стали сверхагрессивно инлайнить ф-ии 2) а уже не всегда возможно отделить "злоупотребление" от "разумных оптимизаций"
Сейчас рынок такой, что ваше резюме (хоть честное хоть приукрашенное - если только не выдумывать 100% из головы) почти не имеет шанов пройти фильтр HR и дойти до технического специалиста.
Из этого вытекает, - для вас и для любого джуна зацепившегося в IT-контору в около-IT, - что лучшее решение на сегодня это прогресс до уровня миддла внутри кампании (ну и в целом кажется что сейчас реферальные программы + набор из ВУЗов - становятся главным рабочим инструментов в найме).
Ещё один немаловажный момент о котором вам уже писали - решите для себя вы именно хотите быть программистом (ну для меня это создавать работающий код силой своей мысли, извините за пафос) или просто хотите вкатиться в IT. В первом случае - вам однозначно в программисты. Во втором - возможно карьера условного DevOps или чего-то похожего будет лучшим выбором по соотношению "ментальные затраты" / зарплата.
Проблема в том, что "уровень разработчика" определяется не медианной сложностью задачи которую он выполняет в каждый момент времени, а самыми сложными кусками работы - которые могут вылезти в процессе выполнения почти любой задачи.
Это, к стати очень глубоко сидит во всём процессе разработки о довольно сильно связано с особенностями человеческого интеллекта - ну например если джун начинает закапываться, в процессе решения задачи лучшее что он может сделать - своевременно обратится за помощью.
И вот нам завезли "джун*" (не + или минус, а именно ) - под ход мыслей и интеллект которого весь процесс разработки не подстроен. Поэтому одни концентрируются на том, что "джун*" даже до джуна не дотягивает по ряду задач. Другие - на том, что он и миддла (да и любого человека по скорости печатания какого-нибудь заведомо понятного кода) по другим метрикам перебивает.
Проблема в том, что для полноценного внедрения ИИ как минимум весь процесс разработки должен быть перестроен под именно его сильные / слабые стороны.
Покупатель именно что оценивает (готовностью расстаться со своими деньгами, т.е. временем которое он потратил на работу) вашу вещь - стоит "3 часа / 5 часов / 20 часов" моего времени.
С технической точки зрения: "Если хотите идти быстро - идите один, если хотите идти далеко - идите вместе". С управленческой точки зрения - выбирайте что вам нужно. Решение за вами.
То есть куда-то подевались эти самые опытные программисты. ИИ должен помочь их вернуть.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.
Почти любая классификация людей на "типы" (вот утюги их надо включать в розетку и не обжечься, а вот ЭЛТ-телевизоры их надо периодически бить сбоку посильнее чтобы работали) - оказывалась в итоге лженаукой, без кавычем, ибо зачастую изначально претендавала на верность и полезность.
Ваш изначальный "тэйк" неправильный. И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
Ну конкретно псие может и не помог, но те же маки уже 5й год на унифицированной быстрой памяти и это явно сильно круче традиционного разделения памяти между цпу и гпу.
SLC (system level cache) - точка когерентности для CPU и GPU SLC когерентна для L2, с инвалидацией DMA-регионов (где-то в промежутке вариант, когда поверх общей памяти мапим GPU-регион в обход кэша).
Вы не правы потому, что предполагаете первый вариант ультимативно лучше. На самом же деле оба этих варианта конкурентны и предпочитаются в зависимости от типа нагрузки.
Ох... не примите ниженаписанное за нападки - мне просто очень грустно от качества статей по микроэлектронике вообще ((.
Про перезарядку конденсаторов говорил в самом конце (про усилители считывания), в абзаце с уточнениями. ..... В следующей части будут разбираться уже логические аспекты: режимы работы процессоров х86 и их влияние на память, сегментация, страничная организация памяти и так далее.
Кажется вообще самая содержательная часть всего описания памяти, определивная весь дизайн SOC последних 30 лет - memory wall - в план статьи не попадает.
Грустно. Это вообще какая-то болезнь хабра. Про "физику" - пожалуйста. Про что-то уже понятное прикладному программисту - пожалуйста.
Написать содержательно про системное программирование и\или микроэлектронику - просто выпадает из фокуса внимания.
Труд офигенный. Но самое главное (с точки зрения цифровой схемотехники - это действительно самое главное) не освещено:
Активируемая строка считывается в лэчи (можно регистры - но это не оптимально) - по порядку величины это время 10 нс.
Это действие называется row activation - и при это даныне из капаситоров пропадают.
После этого происходят многократные манипуляции с активированной строкой (то, что так выгодно делать основывается на ключевом свойстве программ - локальности).
После того, как мы закончили обработку текущей строки - мы заново "речаржим" строку (что по порядку величины также занимает 10 нс). Это необходимо сделать, даже если мы только читали, т.к. см "1.1" - в банке памяти текущей строки больше нет, она заменена 0-ми.
Ну и обо всяких мелочах, что общение происходит словами (а значит ширина смещения адреса внутри строки = "размер строки / размер слова в битах") - лучше бы тоже поправить. Вы буквально на всех уровнях: ISA / LLC / DDR-контроллер - оперируете со словами в памяти, а не с какими-то наборами бит.
В целом ощущение, что одну полноценную статю вы скомпали в пару абзацев и решили "и так сойдёт", хотя это прям ключевые моменты про устройство DDR.
Как человек живший в 3 домах с мусоропроводом (и последним без) - заявляю, что вам очень повезло.
Проблема мусоропровода в том, что достаточно на 3 дня "подзабить" на него (управляшка воюет с ресурсниками) и запах обеспечен.
Достаточно на 2 недели подзабить на него и невыводимый запах, а значит разная живность (от крыс до тараканов) обеспечена.
И да как нормально и без запаха работает мусоропровод у моей тёщи в Мск - я не знаю и считаю чудом.
ок, вполне возможно (я не статью критикую, если что - а данный конкретный случай).
Забавно, что данный случай (UB в компиляторе) это вариант практической инженерии и к сводимости \ несводимости к State Machine вообще отношения не имеет.
Просто используйте в компиляторе только эквивалентные преобразования (и запретите потенциально неэквивалентные) - и будет вам счастье.
А что там где-то вне вашего innermost цикла, который вы вылизали есть какое-то зависание - да и бог с ним.
Блин вот комментатор выше "поумничал".
Но вы то повелись зачем?
Конечность (сводимость к state machine) / бесконечность потенциальных данных вообще тут не при чём.
Компилятор просто делает эквивалентные преобразования одного языка к другому (пока не перейдёт от условного C++ к условному IA32 / x86-64).
и легко можно выделить подмножество преобразований, которые безусловно корректны (почти весь peephole, существенная часть GSH (но не все из-за бесконечных циклов), существенная часть inlining).
> если сравнить плохоньких программистов с передовыми девопсами
А к чему вообще проводить такие сравнения? Мне они кажутся заведомо манипулятивными.
Чтобы стать хорошим программистом - надо сломать себе мозг разными античеловеческими концепциями (один раз, но надо - хотя бы освоить их до уровня навыка), типа "потока управления, программного стэка, представления объектов в памяти"....
Т.к. сравниваем ты будешь всегда с людьми, которые в профильных старших классах \ начальных курсах "поняли рекурсию".
DevOps же - гораздо ближе, в этом смысле к любой другой обычной человеческой технологической деятельности (не IT), типа починке телевизоров, приведению в порядок автохлама и т.д.
https://www.semestr.ru/economic/ks3.php
Авторов таких "разоблачительных" комментариев следовало бы отправить изучать экономику, в частности что такое "минимальный [экономически выгодный] эффект масштаба (см. ссылку)".
что там "подробно рассматривать" то?
MT (как и любая процессорная архитектура) с конечной памятью - просто ОЧЕНЬ большой конечный автомат.
Касательно темы - UB в стандарте сформулировано таким образом (поведение не определено), что компилятор имеет право вести себя так, будто UB в коде нет, т.к. если UB произошло - то программа просто как-бы отменила всё ранее сделанное.
Последние лет 10 (1) - компиляторы стали этим злоупотреблять (2), - и просто помечать весь код, содержащий UB как недостижимый, что привело не только к выкидыванию самого кода с UB, но и к compile-time наложению условий на значение переменных, которые "таковы, что UB не произойдёт".
1) после того, как компиляторы стали сверхагрессивно инлайнить ф-ии
2) а уже не всегда возможно отделить "злоупотребление" от "разумных оптимизаций"
Сейчас рынок такой, что ваше резюме (хоть честное хоть приукрашенное - если только не выдумывать 100% из головы) почти не имеет шанов пройти фильтр HR и дойти до технического специалиста.
Из этого вытекает, - для вас и для любого джуна зацепившегося в IT-контору в около-IT, - что лучшее решение на сегодня это прогресс до уровня миддла внутри кампании (ну и в целом кажется что сейчас реферальные программы + набор из ВУЗов - становятся главным рабочим инструментов в найме).
Ещё один немаловажный момент о котором вам уже писали - решите для себя вы именно хотите быть программистом (ну для меня это создавать работающий код силой своей мысли, извините за пафос) или просто хотите вкатиться в IT.
В первом случае - вам однозначно в программисты.
Во втором - возможно карьера условного DevOps или чего-то похожего будет лучшим выбором по соотношению "ментальные затраты" / зарплата.
Проблема в том, что "уровень разработчика" определяется не медианной сложностью задачи которую он выполняет в каждый момент времени, а самыми сложными кусками работы - которые могут вылезти в процессе выполнения почти любой задачи.
Это, к стати очень глубоко сидит во всём процессе разработки о довольно сильно связано с особенностями человеческого интеллекта - ну например если джун начинает закапываться, в процессе решения задачи лучшее что он может сделать - своевременно обратится за помощью.
И вот нам завезли "джун*" (не + или минус, а именно ) - под ход мыслей и интеллект которого весь процесс разработки не подстроен.
Поэтому одни концентрируются на том, что "джун*" даже до джуна не дотягивает по ряду задач. Другие - на том, что он и миддла (да и любого человека по скорости печатания какого-нибудь заведомо понятного кода) по другим метрикам перебивает.
Проблема в том, что для полноценного внедрения ИИ как минимум весь процесс разработки должен быть перестроен под именно его сильные / слабые стороны.
Но ведь рынок - это баланс спроса и предложения.
Покупатель именно что оценивает (готовностью расстаться со своими деньгами, т.е. временем которое он потратил на работу) вашу вещь - стоит "3 часа / 5 часов / 20 часов" моего времени.
О чём спор-то?
С технической точки зрения: "Если хотите идти быстро - идите один, если хотите идти далеко - идите вместе".
С управленческой точки зрения - выбирайте что вам нужно. Решение за вами.
Вы всерьёз спрашиваете или троллите?
Впрочем в любом из этих вариантов смысла в дальнейшем разговоре не вижу. Всего хорошего.
У нас в системном программировании - доля 40+ весьма значительна.
Если же говорить о "программировании вообще" - последние лет 20 в России число программистов росло экспоненциально год от года. Долю тех, кто вошёл 10-30 лет назад можете вычислить сами, в зависимости от знаменателя прогресии.
Есть куча материалов, где экспериментатор утверждает, что гоминиды шутят.
Но довольно сложно найти материал, где гоминиды без
суфлёраэкспериментатора демонстрируют те же способности.Почти любая классификация людей на "типы" (вот утюги их надо включать в розетку и не обжечься, а вот ЭЛТ-телевизоры их надо периодически бить сбоку посильнее чтобы работали) - оказывалась в итоге лженаукой, без кавычем, ибо зачастую изначально претендавала на верность и полезность.
И вот ещё одна.
Ваш изначальный "тэйк" неправильный.
И по-хорошему минусы надо ставить за тэйк, а не случайную ошибку (но ошибка - показывает, что вы влезли вообще не имея представления о чём пишите).
SLC (system level cache) - точка когерентности для CPU и GPU
SLC когерентна для L2, с инвалидацией DMA-регионов
(где-то в промежутке вариант, когда поверх общей памяти мапим GPU-регион в обход кэша).
Вы не правы потому, что предполагаете первый вариант ультимативно лучше. На самом же деле оба этих варианта конкурентны и предпочитаются в зависимости от типа нагрузки.
Что называется - давайте обратимся к источника.
Худшее, что можно сделать с guard clauses - это смешать их с вложенными условиями, особенно попеременно.
Особенно попеременно. После этого код становится абсолютно нечитаемым и крайне осложнённым для понимания.
Ох... не примите ниженаписанное за нападки - мне просто очень грустно от качества статей по микроэлектронике вообще ((.
Кажется вообще самая содержательная часть всего описания памяти, определивная весь дизайн SOC последних 30 лет - memory wall - в план статьи не попадает.
Грустно.
Это вообще какая-то болезнь хабра. Про "физику" - пожалуйста.
Про что-то уже понятное прикладному программисту - пожалуйста.
Написать содержательно про системное программирование и\или микроэлектронику - просто выпадает из фокуса внимания.
Труд офигенный.
Но самое главное (с точки зрения цифровой схемотехники - это действительно самое главное) не освещено:
Активируемая строка считывается в лэчи (можно регистры - но это не оптимально) - по порядку величины это время 10 нс.
Это действие называется row activation - и при это даныне из капаситоров пропадают.
После этого происходят многократные манипуляции с активированной строкой (то, что так выгодно делать основывается на ключевом свойстве программ - локальности).
После того, как мы закончили обработку текущей строки - мы заново "речаржим" строку (что по порядку величины также занимает 10 нс). Это необходимо сделать, даже если мы только читали, т.к. см "1.1" - в банке памяти текущей строки больше нет, она заменена 0-ми.
Ну и обо всяких мелочах, что общение происходит словами (а значит ширина смещения адреса внутри строки = "размер строки / размер слова в битах") - лучше бы тоже поправить. Вы буквально на всех уровнях: ISA / LLC / DDR-контроллер - оперируете со словами в памяти, а не с какими-то наборами бит.
В целом ощущение, что одну полноценную статю вы скомпали в пару абзацев и решили "и так сойдёт", хотя это прям ключевые моменты про устройство DDR.