К стати есть ещё unspecified behavior (это когда есть несколько вариантов реализации и разработчик вправе использовать один из них - ну что-то типа BE \ LE, или выпеленное в 2020 году Ones' component \ two's component).
Ну лично я бы проверил, что он вообще понимает что такое VCS[ystems]. В смысле что человек пользуется инструментами на отличном от "нажми на кнопку произойдёт магия" уровне.
UB в спеке означает "компилятор волен выбирать сам, какое поведение использовать"
Нет. Вы путаете UB(undefined behavior) и IB (implementations behavior). UB - это именно "может произойти всё что угодно". Например если мы переполняем signed int (например чтобы вернуть потом как часть структуры) выше по коду - то ниже по коду войдём в ветку с заведомо неверным условием, где сохраним неверное второе поле структуры. Или например "return из функции удалился (соптимизировался)" и вместо возврата мы начали выполнять следующую ф-ию с её начала.
Также разница между "UB ведут себя достаточно предсказуемо" и "при UB в коде и О3-О2 компилятор переврёт ф-ию до неузнаваемости" случился в районе начала 2020х. My best guess - компиляторная команда продавила-таки формальный подход что компилятор обязан то, что написано в его спеке и ни битом разумного больше.
Статья - классная завязка на "подумать" (хотя остановилась в самом интересном месте).
Начал изучать - есть ли скин-эффект в Copper Pillars - и выяснил, что нет. Во-первых керамические конденсаторы стоят сразу после них (именно чтобы убрать скин-эффект). А во вторых микро-конденсаторы стоят прямо в слоях металлизации. Об это КРАЙНЕ полезно было бы упомянуть в статье: https://ieeexplore.ieee.org/document/9943549
Существует измеримый коллапс поколений в устойчивом чтении и письме, и академическая сфера реагирует на это импровизацией и иногда — истощением, а не структурной перестройкой, которую требует процесс.
Существует измеримый коллапс поколений в устойчивом и осмысленном переводе, и переводческая сфера реагирует на это импровизацией нейросетей и иногда — истощением здравого смысла, а не структурной перестройкой, которую требует профессия».
Очевидно, что себестоимость вайбкодинга для компаний, при фиксированном качестве будет снижаться со временем (на горизонте 2-5 лет это будет заментно).
Исходя из этого сценарий "вайбкодить слишком дорого - все вернулись к ручной разработке" выглядит ну прям совсем утопично.
Во вторых вы сменили тему с "что может дать реальный преподаватель" на "идеального преподавателю" что чистейшая маркетинговая уловка, на мой взгляд граничащая с обманом.
В реальности нужно рассчитывать на медианного преподавателя. А медианный полуторатыщерублёвый преподаватель действительно нужен, для самого-самого начала которое в принципе в школе дают. А дальше хорошо если мешать не будет (см первую часть ответа) и уж точно по способностям что объяснения, что составления нормальной программы хуже нейросети.
А вот исправлять редкие ошибки или отвечать на сложные и заковыристые вопросы "как и почему так устроена вот эта часть языка" - ментора на час в неделю как раз хватит (я думаю что пока ещё нейронки его вряд ли заменяют).
Примерно до 1970 года преподаватели английского в универах немножечко мешали - если убрать препода и просто сравнивать с чтением \ слушанием материалов по уровню (см. comprehensible input Стивена Крашена).
С тех пор, конечно, в передовом обучении языкам произошла революция, но в бытовом обучении остались проблемы. Если честно - я думаю что преподаватель для изучения языков не нужен, нужен ментор 1 час в неделю (по х2 тарифу от "преподавателя") отвечающий на сложные вопросы. С преподавателем же вот какой набор скрытых проблем:
Чтобы достигнуть уровня С1 нужно примерно 1_500_000 рублей - что исходит из 1000 часов с преподавателем (у русских как и вообще славяноязычных есть поправочный коэффициент кэмбриджской норме в 700-800 часов с преподавателем).
Качество медианных преподавателей часто не такое же высокое, как рассказывают в передовых методиках
Сегодня чтобы составить себе comprehensible input программу - достаточно поговорить с нейросеткой, которая сама определит твой уровень какие материалы смотреть\слушать\читать в зависимости от сложности и "lexile measure" материалов
У недобросовестных учителей остался последний оплот почему люди должны нести им деньги - "священная идеальная грамматика". Прикол в том, что она не нужна. Человеку нужно нормально изъясняться (для этого достаточно 3.5 грамматических форм) и точно также нормально понимать что ему скажут на international english. При этом говорить достаточно бегло, достаточно понятно, использовать привычные в ЕГО ТЕКУЩЕЙ СРЕДЕ распространённые слова выражения и конструкции.
Активный словарный запас, обычно в 2-4 раза меньше пассивного (для изучающих иностранный).
Такая разница несомненно имеет большое значение если надо научить пользователя языку (и на этом заработать денег).
Такая разница (в 2-4 раза) - имеет очень мало значения если цель - втюхать пользователю подписку, а дальше - пользователь сам подписался, сам не мамонт.
Если что - моё предложение начать заново в силе (кажется я понял что вы имеете в виду - но додумывать за вас вашу работу не хочу - в конце концов не я залетел в трэд с двух ног с придирками к определению).
=======================================
I. Вы так и не привели контрпример - который бы противоречил приведённому мною определению.
II. Вы повторяете то, что я гораздо кратче (и глубже с точки зрения иерархии абстракций) описал 3 дня назад. Зачем?
III. Вы так и не смогли привести где я говорил, что "параллелизм это модель" - или эквивалентное, например "параллелизм является моделью". Факт.
IV. > Но добавлю, что параллелизм – это и не свойство модели исполнения тоже. Он (параллелизм) вообще не имеет непосредственного отношения к тому, как устроены процессы.
> параллелизм - это техническая характеристика вычислительной системы
А потом этот человек обижается, что ему указывают на его ошибки как-то слишком "строго".
Update: Наш разговор уходит в какие-то мелочи. Если хотите - можем начать заново с формулировки позиций с чистого листа.
===============================================
Докопаться до определнения.
Совершить 3 очевидные ошибки когда были поставлены в равные условия.
Жаловаться на "менторский" тон.
Л - логика.
П.С.
Параллелизм - это не модель исполнения
Снова ошибка №2 (из пунктов выше) - вы спорите с тем, чего я не говорил. В очередной раз.
Если я не прав - вы же с лёгкостью процитируете где я сказал, что "параллелизм - модель...." (а не например свойство модели или например google: "модель параллельных процессов" или ещё что-то похожее по форме но иное по содержанию)".
Или опять будете прятаться за "неправильный" тон собеседника.
Параллелизм - это физическое понятие - определённая зависимость от времени, а не логическое. Тут не в последовательности операций дело.
Вполне себе логическое. CS-еры \ компиляторщики именно так об этом и говорят. Более того, определение дано именно в таком ключе (как о гарантиях для всех случаев) - если вас это смущает, могли бы сразу об этом и написать. А не портить объяснения об IT неуместными аналогиями с "завтраками" (как это очень любят делать нейросетки, например).
============== Ну и до кучи ошибки допущенные вами:
Вы пытались доказать неверность моего определения, а доказали (доказали с ошибкой) неверность какого-то левого выдуманного вами. Зачем?
Вы пытаетесь совершить логическкую ошику "инверсия импликации". (a => b) => (!b => !a). Не надо так. Если предусловие не выполняется импликация всегда истинна, просто запомните.
Зачем Вообще говорить о параллельности полностью независимых процессов \ потоков? О параллельности говорят когда потоки как-то влияют друг на друга: control flow \ data flow \ да хоть замедление выполнения или увеличение времени отклика.
Извините если был чересчур придирчивым - но кажется это вы выступили "определения-наци" позиций.
Не понимаю как это делает невалидным определение (не говоря уже о использовании каких-то мутных конструкций типа "фактически последовательных". Из-за мутности примера кажется что вы хотели использовать инверсию импликации - но точно утверждать не могу).
Пожалуйста приведите конкретный пример последовательности операций при многопоточности когда моё определение не верно.
Это другая параллельность - на уровне микроархитектурной реализации.
Ваш студент применил термин "параллельные процессы" - пришлось пояснять все три источника параллельности в аппаратуре. Если бы в примере была, например "вытесняющая многозадачность" - я бы рассказал только про неё.
Так что ваши разъяснения (1) (2) и (3) - говорят что предполагаемый студент просто плохо понимает термины которыми пользуется и если он сказал "параллельные процессы" то ответ будет именно про них. ===================================================
Если же говорить про дедактическую часть - то да, разумеется вы правы и про вытесняющую многозадачность следует рассказать в курсе ОС.
Но всё равно - рассказать про "контекст процесса" и "переключение контекста" вполне можно без регистров. И это будет не "магия" а "таков API", через месяц пройдём.
П.С. Извините - вопрос распался на 2 "фактология" vs "дидактика" я не очень понимаю про какую вы сейчас.
>Чем это отличается от чакры Тем что есть гарантии API. Скажем ни один человек, ни даже всё человечество не знает как работают физические законы до самого конца - но это не мешает конкретным людям пользоваться формулами (которые просто API предоставляемые физическими дисциплинами).
> что значит примерно так работает. Это значит, что я отдаю себе отчёт, что есть сложные контринтуитивные вещи (*) которые студенты до конца не поймут пока не попробуют руками на практике, гораздо бОльшей, чем написать лабораторку. *) (параллельность тредов, скажем не настолько сложная). А например Memory Ordering (лежащие под ним понятия, что нет никакого "момента" когда операция применилась к кэшу или другой распределённой системе - есть лишь гарантии наблюдаемости другими операциями) - это настолько контринтуитивно, что большинство студентов не поймут ни после лекции ни из лаботаторки возможного на практике размера. ========================================= Заметьте я не говорю, что курс хороший, а лишь подход имеет право на существование.
Поэтому предположим я бы читал "архитектуру компьютеров" - по классической иерархии абстракций сверху вниз: проблема - программа - платформа - ISA - microarchitecture - RTL - ... и прозвучал бы ваш вопрос "что такое параллельность".
Хорошо, что ты задал такой вопрос, даже если абстракции не текут, то знание на 2 уровня абстракции в глубину позволяет принимать более качественный решения при работе над "своим" модулем.
Однако: единственный индустриальнйы способ разрабатывать сложные системы это модульность (с использованием интерфейсов) - которая подразумевает, что у нас есть гарантии от нижележащего (его API) и на их основе мы должны предоставить более удобные и богатые абстракции вышележащему слою с какими-то гарантиями(наше API).
Параллельность обозначает что мы не можем никак закладываться ни на какой порядок исполнения команд (для программы инструкций для ISA), за исключением эксплицитно прописанных синхронизаций (однако на конкретных платформах можем).
Про многопроцессорную параллеьность мы пройдём в главе "диайн SoC", про SMT-параллеьность мы узнаем после прохождения AoO-конвейр CPU. Про самый простой вид параллельности с разделением времени - сразу после главы "прерывания".
Сейчас ты оперируешь неправильными абстракциями. А именно ты не разделяешь понятия "видимость результатов операции" и "исполнение операции". Объяснять разницу сейчас - потребует слишком много времени, но ты всегда сам можешь про это прочитать.
К стати "1" и "2" (как и сама классическая иерархия абстракций) - наверное самые efficient общеинженерные знания (по соотношению чего простого слильно не хватает большинству студентов) которые нужно давать в институте.
Для себя я выделил 2 основных вида людей по склонностям "какое объяснение они понимают".
Для одних лучше подходит теоретическое объяснение - ну примерно как курс матанализа в физмат-школах (или стары объяснения ЯП - на основе формальных грамматик).
Для других - около-практические. Примерно как пишутся современные доки на ЯП (Python / Rust). Когда даются практические примеры показывающие ключевую, объясняемую ЗДЕСЬ И СЕЙЧАС особенность. При этом допускается видеть что-то незнакомое, если оно +/- понятно (ну например import).
При этом большинству людей явно ближе второй подход: от знакомого к незнакомому, при этом всегда есть "вот эта магия примерно так работает, объясним потом".
нет вы, как и человек выше путаете Undefined Behavior c Implementation Defined Behavior ( https://timsong-cpp.github.io/cppwp/n4868/impldefindex ).
К стати есть ещё unspecified behavior (это когда есть несколько вариантов реализации и разработчик вправе использовать один из них - ну что-то типа BE \ LE, или выпеленное в 2020 году Ones' component \ two's component).
Ну лично я бы проверил, что он вообще понимает что такое VCS[ystems].
В смысле что человек пользуется инструментами на отличном от "нажми на кнопку произойдёт магия" уровне.
Тут скорее вопрос - "на какую вакансию претендуете: джун / мид / синьёр".
Давайте проверим одну из (по какой у меня есть экспертиза) ваших компетенций ДО КОНЦА. И проверим соответствует ли она лычкам которые вы хотите.
Разумеется это не должны быть технологии перечисленные в "прочие навыки", которых штук 20 у любого прогера сейчас набирается.
П.С.
Но в целом не понимать в 2к26 принципы VCS-систем (не конкретные ключи git) - для джун+ уже очень странно.
Нет. Вы путаете UB(undefined behavior) и IB (implementations behavior).
UB - это именно "может произойти всё что угодно". Например если мы переполняем signed int (например чтобы вернуть потом как часть структуры) выше по коду - то ниже по коду войдём в ветку с заведомо неверным условием, где сохраним неверное второе поле структуры.
Или например "return из функции удалился (соптимизировался)" и вместо возврата мы начали выполнять следующую ф-ию с её начала.
Также разница между "UB ведут себя достаточно предсказуемо" и "при UB в коде и О3-О2 компилятор переврёт ф-ию до неузнаваемости" случился в районе начала 2020х.
My best guess - компиляторная команда продавила-таки формальный подход что компилятор обязан то, что написано в его спеке и ни битом разумного больше.
Статья - классная завязка на "подумать" (хотя остановилась в самом интересном месте).
Начал изучать - есть ли скин-эффект в Copper Pillars - и выяснил, что нет.
Во-первых керамические конденсаторы стоят сразу после них (именно чтобы убрать скин-эффект).
А во вторых микро-конденсаторы стоят прямо в слоях металлизации. Об это КРАЙНЕ полезно было бы упомянуть в статье: https://ieeexplore.ieee.org/document/9943549
Существует измеримый коллапс поколений в устойчивом и осмысленном переводе, и переводческая сфера реагирует на это импровизацией нейросетей и иногда — истощением здравого смысла, а не структурной перестройкой, которую требует профессия».
Очевидно, что себестоимость вайбкодинга для компаний, при фиксированном качестве будет снижаться со временем (на горизонте 2-5 лет это будет заментно).
Исходя из этого сценарий "вайбкодить слишком дорого - все вернулись к ручной разработке" выглядит ну прям совсем утопично.
В 2004 году переповторили классическое исследование Стивен Крашена (где comprehensible input превзошло стандартную методику преподавание с преподом).
И внезапно в 2004 году - CI снова превзошло стандартную методику (правда всего по 4 из 6 показателей).
Да это при том, что преподаватели заведомо не были шарлатанами.
https://www.sciencedirect.com/science/article/abs/pii/S0346251X03000964
===================
Во вторых вы сменили тему с "что может дать реальный преподаватель" на "идеального преподавателю" что чистейшая маркетинговая уловка, на мой взгляд граничащая с обманом.
В реальности нужно рассчитывать на медианного преподавателя. А медианный полуторатыщерублёвый преподаватель действительно нужен, для самого-самого начала которое в принципе в школе дают. А дальше хорошо если мешать не будет (см первую часть ответа) и уж точно по способностям что объяснения, что составления нормальной программы хуже нейросети.
А вот исправлять редкие ошибки или отвечать на сложные и заковыристые вопросы "как и почему так устроена вот эта часть языка" - ментора на час в неделю как раз хватит (я думаю что пока ещё нейронки его вряд ли заменяют).
Примерно до 1970 года преподаватели английского в универах немножечко мешали - если убрать препода и просто сравнивать с чтением \ слушанием материалов по уровню (см. comprehensible input Стивена Крашена).
С тех пор, конечно, в передовом обучении языкам произошла революция, но в бытовом обучении остались проблемы. Если честно - я думаю что преподаватель для изучения языков не нужен, нужен ментор 1 час в неделю (по х2 тарифу от "преподавателя") отвечающий на сложные вопросы. С преподавателем же вот какой набор скрытых проблем:
Чтобы достигнуть уровня С1 нужно примерно 1_500_000 рублей - что исходит из 1000 часов с преподавателем (у русских как и вообще славяноязычных есть поправочный коэффициент кэмбриджской норме в 700-800 часов с преподавателем).
Качество медианных преподавателей часто не такое же высокое, как рассказывают в передовых методиках
Сегодня чтобы составить себе comprehensible input программу - достаточно поговорить с нейросеткой, которая сама определит твой уровень какие материалы смотреть\слушать\читать в зависимости от сложности и "lexile measure" материалов
У недобросовестных учителей остался последний оплот почему люди должны нести им деньги - "священная идеальная грамматика". Прикол в том, что она не нужна. Человеку нужно нормально изъясняться (для этого достаточно 3.5 грамматических форм) и точно также нормально понимать что ему скажут на international english. При этом говорить достаточно бегло, достаточно понятно, использовать привычные в ЕГО ТЕКУЩЕЙ СРЕДЕ распространённые слова выражения и конструкции.
Активный словарный запас, обычно в 2-4 раза меньше пассивного (для изучающих иностранный).
Такая разница несомненно имеет большое значение если надо научить пользователя языку (и на этом заработать денег).
Такая разница (в 2-4 раза) - имеет очень мало значения если цель - втюхать пользователю подписку, а дальше - пользователь сам подписался, сам не мамонт.
У вас в приложении как?
Если что - моё предложение начать заново в силе (кажется я понял что вы имеете в виду - но додумывать за вас вашу работу не хочу - в конце концов не я залетел в трэд с двух ног с придирками к определению).
=======================================
I.
Вы так и не привели контрпример - который бы противоречил приведённому мною определению.
II.
Вы повторяете то, что я гораздо кратче (и глубже с точки зрения иерархии абстракций) описал 3 дня назад.
Зачем?
III.
Вы так и не смогли привести где я говорил, что "параллелизм это модель" - или эквивалентное, например "параллелизм является моделью".
Факт.
IV.
> Но добавлю, что параллелизм – это и не свойство модели исполнения тоже. Он (параллелизм) вообще не имеет непосредственного отношения к тому, как устроены процессы.
> параллелизм - это техническая характеристика вычислительной системы
А потом этот человек обижается, что ему указывают на его ошибки как-то слишком "строго".
Update:
Наш разговор уходит в какие-то мелочи.
Если хотите - можем начать заново с формулировки позиций с чистого листа.
===============================================
Докопаться до определнения.
Совершить 3 очевидные ошибки когда были поставлены в равные условия.
Жаловаться на "менторский" тон.
Л - логика.
П.С.
Снова ошибка №2 (из пунктов выше) - вы спорите с тем, чего я не говорил. В очередной раз.
Если я не прав - вы же с лёгкостью процитируете где я сказал, что "параллелизм - модель...." (а не например свойство модели или например google: "модель параллельных процессов" или ещё что-то похожее по форме но иное по содержанию)".
Или опять будете прятаться за "неправильный" тон собеседника.
Вполне себе логическое. CS-еры \ компиляторщики именно так об этом и говорят. Более того, определение дано именно в таком ключе (как о гарантиях для всех случаев) - если вас это смущает, могли бы сразу об этом и написать. А не портить объяснения об IT неуместными аналогиями с "завтраками" (как это очень любят делать нейросетки, например).
==============
Ну и до кучи ошибки допущенные вами:
Вы пытались доказать неверность моего определения, а доказали (доказали с ошибкой) неверность какого-то левого выдуманного вами. Зачем?
Вы пытаетесь совершить логическкую ошику "инверсия импликации". (a => b) => (!b => !a). Не надо так.
Если предусловие не выполняется импликация всегда истинна, просто запомните.
Зачем Вообще говорить о параллельности полностью независимых процессов \ потоков? О параллельности говорят когда потоки как-то влияют друг на друга: control flow \ data flow \ да хоть замедление выполнения или увеличение времени отклика.
Извините если был чересчур придирчивым - но кажется это вы выступили "определения-наци" позиций.
Не понимаю как это делает невалидным определение (не говоря уже о использовании каких-то мутных конструкций типа "фактически последовательных".
Из-за мутности примера кажется что вы хотели использовать инверсию импликации - но точно утверждать не могу).
Пожалуйста приведите конкретный пример последовательности операций при многопоточности когда моё определение не верно.
Ваш студент применил термин "параллельные процессы" - пришлось пояснять все три источника параллельности в аппаратуре.
Если бы в примере была, например "вытесняющая многозадачность" - я бы рассказал только про неё.
Так что ваши разъяснения (1) (2) и (3) - говорят что предполагаемый студент просто плохо понимает термины которыми пользуется и если он сказал "параллельные процессы" то ответ будет именно про них.
===================================================
Если же говорить про дедактическую часть - то да, разумеется вы правы и про вытесняющую многозадачность следует рассказать в курсе ОС.
Но всё равно - рассказать про "контекст процесса" и "переключение контекста" вполне можно без регистров. И это будет не "магия" а "таков API", через месяц пройдём.
П.С.
Извините - вопрос распался на 2 "фактология" vs "дидактика" я не очень понимаю про какую вы сейчас.
Если это определение неверное - вы легко приведёте контрпример.
Пожалуйста.
Comprehensible input + AI по цене кратно дешевле репетитора, а по качеству для технорей почти не отличается.
Так что в плюсе пользователь.
>Чем это отличается от чакры
Тем что есть гарантии API.
Скажем ни один человек, ни даже всё человечество не знает как работают физические законы до самого конца - но это не мешает конкретным людям пользоваться формулами (которые просто API предоставляемые физическими дисциплинами).
> что значит примерно так работает.
Это значит, что я отдаю себе отчёт, что есть сложные контринтуитивные вещи (*) которые студенты до конца не поймут пока не попробуют руками на практике, гораздо бОльшей, чем написать лабораторку.
*) (параллельность тредов, скажем не настолько сложная). А например Memory Ordering (лежащие под ним понятия, что нет никакого "момента" когда операция применилась к кэшу или другой распределённой системе - есть лишь гарантии наблюдаемости другими операциями) - это настолько контринтуитивно, что большинство студентов не поймут ни после лекции ни из лаботаторки возможного на практике размера.
=========================================
Заметьте я не говорю, что курс хороший, а лишь подход имеет право на существование.
Поэтому предположим я бы читал "архитектуру компьютеров" - по классической иерархии абстракций сверху вниз: проблема - программа - платформа - ISA - microarchitecture - RTL - ... и прозвучал бы ваш вопрос "что такое параллельность".
Хорошо, что ты задал такой вопрос, даже если абстракции не текут, то знание на 2 уровня абстракции в глубину позволяет принимать более качественный решения при работе над "своим" модулем.
Однако: единственный индустриальнйы способ разрабатывать сложные системы это модульность (с использованием интерфейсов) - которая подразумевает, что у нас есть гарантии от нижележащего (его API) и на их основе мы должны предоставить более удобные и богатые абстракции вышележащему слою с какими-то гарантиями(наше API).
Параллельность обозначает что мы не можем никак закладываться ни на какой порядок исполнения команд (для программы инструкций для ISA), за исключением эксплицитно прописанных синхронизаций (однако на конкретных платформах можем).
Про многопроцессорную параллеьность мы пройдём в главе "диайн SoC", про SMT-параллеьность мы узнаем после прохождения AoO-конвейр CPU. Про самый простой вид параллельности с разделением времени - сразу после главы "прерывания".
Сейчас ты оперируешь неправильными абстракциями. А именно ты не разделяешь понятия "видимость результатов операции" и "исполнение операции". Объяснять разницу сейчас - потребует слишком много времени, но ты всегда сам можешь про это прочитать.
К стати "1" и "2" (как и сама классическая иерархия абстракций) - наверное самые efficient общеинженерные знания (по соотношению чего простого слильно не хватает большинству студентов) которые нужно давать в институте.
Пока это голословное утверждение. Чем вы можете его подтвердить?
Для себя я выделил 2 основных вида людей по склонностям "какое объяснение они понимают".
Для одних лучше подходит теоретическое объяснение - ну примерно как курс матанализа в физмат-школах (или стары объяснения ЯП - на основе формальных грамматик).
Для других - около-практические. Примерно как пишутся современные доки на ЯП (Python / Rust). Когда даются практические примеры показывающие ключевую, объясняемую ЗДЕСЬ И СЕЙЧАС особенность. При этом допускается видеть что-то незнакомое, если оно +/- понятно (ну например import).
При этом большинству людей явно ближе второй подход: от знакомого к незнакомому, при этом всегда есть "вот эта магия примерно так работает, объясним потом".