Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 82
Мне кажется было бы вернее написать не почему неправильно, а как сделать правильно, предложить свой план с объяснениями. То, что айтишники работают в Макдональдсе конечно плохо, но тут вопрос комплексный - как они закончили университет, если не имеют знаний, почему сами не восполнили то, чего не хватало в учебнике - в девайсе для просмотра тиктоков есть мощный поисковик.
И у вас по-моему грамматическая ошибка в предпоследнем абзаце
Ну как окончили университет это понятно - в США родители платят университетам сотни тысяч долларов за ребенка, поэтому их не стоит огорчать, а стоит ставить оценки по медиане - то есть кто лучше большинства - A то бишь пять, кто хуже C то бишь три.
Почему самим не восполнить нехватку знаний: студент же протирает штаны в колледже/университете, усердно выполняет какие-то задачки, он и сам абсолютно уверен, что всё правильно – не будут же преподы рисовать ему оценки просто так? А они будут, потому что иначе придётся признать, что их учебная программа, мягко скажем, несовершенна.
основа этой ошибки - непонимание уровня понимания у субъекта обучения.
1. предположим это учебник для людей которые уже знают все эти темы поверхностно, тогда учебник даст глубокие знания, (возможно).
2. если это начинающий то - да полный провал.
Цель описываемой книжки - сделать введение во все уровни технологии для первокурсников, начиня от логических элементов и D-триггеров, до register transfer level, до архитектуры и микроархитектуры итд заканчивая многослойными сетевыми протоколами, файловыми системами итд.
Плохих (ну хорошо, средненьких) книжек на ИТ-тематику -- тонны. Особенно этим грешит нынче издательство Пакт. Плюс средненькие переводы хороших книжек на русский. А нативно русскоязычную ИТ-литературу вообще нет смысла читать -- на 99% ничего полезного и оригинального в ней не будет, действительно хорошие русскоязычные айтишные авторы -- как жемчужины на вес золота.
Вот какие есть книжки "хорошие и правильные" -- это да, вопрос.
Я думаю, под кешами подразумевались не кеши процессора, а дисковые кеши и memory-mapped files, эта тема связана с темой виртуальной памяти
Виртуальная память тоже строится на аппаратном кэше трансляций из виртуального адреса в физический, который называется tlb - TLB - Translation Lookaside Buffer
Строго говоря, не обязательно, хотя во всех современных архитектурах, думается, это именно так. Навскидку из отличающихся "исторических" архитектур:
80286 с его теневыми регистрами для сегментов (хотя, подобно TLB, теневые сегментные регистры хранят информацию, полученную из таблиц в памяти, но, в отличие от TLB, это не "кэш" в том смысле, что каждый теневой регистр обновляется процессором не "по собственному желанию", а в строго определённый момент -- когда выполняется загрузка соответствующего сегментного регистра, т.е. по прямому указанию программиста). В IA-32 теневые регистры сохранены, но там появился уже и нормальный TLB, поскольку появилась нормальная страничная организация памяти;
PDP-11, где преобразование адресов основано на регистрах MMU: из-за малого объёма виртуального адресного пространства (64 Кбайта) нужды в таблицах переадресации, расположенных в ОЗУ, нет, и всё необходимое лежит прямо в MMU; соответственно, нужды в TLB тоже нет.
В более поздних архитектурах, например в MIPS, TLB был не в памяти, а на основе CAM (блоков context-addresable memory) и регистровых структур. При tlb miss происходило исключение и в его программном обработчике можно было подгрузить данные из памяти. Page walker появился в MIPS потом.
В любом случае, сейчас академический стандарт - RISC-V, и такие темы нужно давать на нем, хотя можно и на ARM.
В более поздних архитектурах, например в MIPS, TLB был не в памяти, а на основе CAM (блоков context-addresable memory) и регистровых структур. При tlb miss происходило исключение и в его программном обработчике можно было подгрузить данные из памяти.
Мне это такой дикостью показалось: ведь жутко медленно и неэффективно по сравнению с аппаратной выборкой из таблиц переадресации, а последняя -- вещь весьма простая, чтоб на ней усиленно экономить.
В любом случае, сейчас академический стандарт - RISC-V
Что, уже официально на RISC-V перешли? Я-то от образования далёк, поэтому не в теме, что там и как -- только по книжкам что-то вижу.
Но говорил я больше о том, что давать глубоко надо, конечно, современное, но упомянуть неплохо бы и существовавшие некогда другие подходы -- для общего развития, так сказать, но без траты сколько-нибудь значительного времени на это дело (кто заинтересуется историей -- сам найдёт, ему достаточно ключевые слова подсказать).
Мне это такой дикостью показалось: ведь жутко медленно и неэффективно по сравнению с аппаратной выборкой из таблиц переадресации,
Придумали это не дураки, а люди которые все внимательно по тактам меряли, и у них получилось что статистически это в среднем работает хорошо.
с аппаратной выборкой из таблиц переадресации, а последняя -- вещь весьма простая, чтоб на ней усиленно экономить.
А вы в курсе, что даже в достаточно простых мипсовских ядрах микроконтроллерного класса аппаратные кэши трансляций состояли не из одной таблицы, а из трех? И в дополнение к нему вот тот механизм.
Вот вся моя презентация по вопросу
Так что таблица переадресации не такая простая, CAM дорогой для малых ядер, а page walker тем более.
но упомянуть неплохо бы и существовавшие некогда другие подходы -
286 - это ядро с разными тупиковыми странностями как я помню, а PDP-11 упоминать нельзя, потому что люди влюбляются в его ассемблер и им приходится доказывать, что это плохая архитектура так как она делает конвейеризацию дорогой из-за двухоперандности и аутоинкрементов.
В учебных программах мало времени, учителя норовят впихнуть свою ностальгию по детству (6502 всякие), а студенты легко отвлекаются на всякое, поэтому нужно держать их строго фокусированными, чтобы они могли решать задачи на будущих интервью, а не процессорной археологией заниматься.
В крайнем случае можно рассказать про scoreboard в CDC 6600 (первый out-of-order) и про алгоритм Томасуло, так как это релевантно суперскалярным процессорам.
Придумали это не дураки, а люди которые все внимательно по тактам меряли, и у них получилось что статистически это в среднем работает хорошо
Ну так и саму концепцию RISC придумали не дураки, и посчитали правильно -- что в CISC-процессорах активно используется от силы 10% команд, а остальные -- эпизодически, вот и решили их выкинуть. Однако на сегодняшний день от их изначальной концепции осталось только выполнение операций исключительно в регистрах, и то есть определённые подвижки для ухода от этого в некоторых специфических случаях: внезапно оказалось, что эти самые редко используемые команды многократно ускоряют выполнение соответствующих классов задач, т. е. отнюдь не бесполезны, если речь идёт о вычислительных системах достаточно высокой производительности, а не минимальной стоимости и потребляемой мощности. Вот и набиты современные типа RISC-процессоры сотнями, а то и тысячами странных и редко используемых команд :) (хотя насколько странных, как EDMK в Системе 360, сейчас, пожалуй, не встречается)
Ну и если б такое управление TLB работало бы действительно хорошо, от него бы, в конечном итоге, не отказались бы, да и использовался бы такой подход намного шире.
А вы в курсе, что даже в достаточно простых мипсовских ядрах микроконтроллерного класса аппаратные кэши трансляций состояли не из одной таблицы, а из трех? И в дополнение к нему вот тот механизм.
Нет, не в курсе; я особо в MIPS не погружался -- так, полистал немного для общего развития, и всё. На практике с ними никогда сталкиваться не приходилось, вот и не углублялся. Но это уже тонкости реализации, а не архитектурно-концептуальный уровень (очевидно, что у современных мэйнфреймов z/Architecture TLB тоже несколько отличается от, скажем, использованного в System 370/145, чья микроархитектура была нами содрана и воплощена в ЕС-1035: там весь TLB аж из восьми (восьми!) элементов состоит, а управляется микропрограммно, насколько помню; однако для программиста эти тонкости совершенно безразличны, ибо на концептуальном уровне TLB ведёт себя одинаково на любых моделях).
286 - это ядро с разными тупиковыми странностями как я помню
Угу. Не столько даже тупиковая -- сделать полноценную ОС с виртуальной памятью и прочим на этом можно, и даже некоторые дополнительные возможности были бы доступны и реализовывались бы дёшево в плане скорости, но очень уж неудобно всё это дело было, поэтому и не прижилось. (Замечу в скобках, что подход IBM -- "нормальная" виртуальная память на основе страниц с "нормальным" MMU плюс архитектурная концепция множества адресных пространств плюс архитектурный же механизм "вызова программы" оказались намного элегантнее и эффективнее, чем Интеловские описатели сегментов и шлюзов вызова, хотя, в первом приближении, позволяют решить одни и те же задачи аппаратными (с точки зрения программиста) средствами, т.е. достаточно быстро -- в отличие от чисто программной реализации путём вызова соответствующих сервисов операционной системы, что всегда очень дорого).
а PDP-11 упоминать нельзя, потому что люди влюбляются в его ассемблер и им приходится доказывать, что это плохая архитектура так как она делает конвейеризацию дорогой из-за двухоперандности и аутоинкрементов
А тем, кто влюбился, показать VAX-11, а потом попросить набросать концепцию суперскалярного процессора этой архитектуры :) Ага, с длиной кода команды от 1 до 36 байт :)))) В PDP-11, по крайней мере, выборку и декодирование команд сделать несложно -- длина хоть и переменная, но количество вариантов ограничено (1, 2 или 3 слова, т. е. 2/4/6 байтов), а однозначно определить её можно анализом первого слова (хотя в Системе 360 и её потомках анализ ещё проще: длину кода команды (тоже 2/4/6 байтов) определяют два старших бита первого байта). Собственно, поэтому мне VAX-11 и не нравится, хотя PDP-11 -- моя любимая 16-разрядная архитектура, а VAX лишь продолжил её идеи: просто DEC решила сделать мощную машину, а концептуальный подход использовала, который был успешным для маленькой и дешёвой машины; естественно, ничего из этого не вышло (VAX-11 получился слишком дорогим, чтоб вытеснить PDP-11 из её ниши, но при этом не имел шансов стать высокопроизводительным, чтоб действительно составить конкуренцию тем же мэйнфреймам IBM).
В учебных программах мало времени, учителя норовят впихнуть свою ностальгию по детству (6502 всякие), а студенты легко отвлекаются на всякое, поэтому нужно держать их строго фокусированными, чтобы они могли решать задачи на будущих интервью, а не процессорной археологией заниматься.
Честно говоря, не уверен. Что бизнесу нужны готовые специалисты -- это понятно, а Вы как раз в бизнесе и работаете, решаете реальные инженерные задачи. С другой стороны, нельзя подготовить исследователя/учёного, если у него кругозор ограничивается тем, что нужно и эффективно здесь и сейчас. Но это возвращаемся уже к общим проблемам образования -- в частности, к "целеполаганию" в образовании: а кого мы вообще готовим в том или ином учебном заведении? Думается, количество вузов, как я их понимаю, нужно сократить радикально -- раз в 10, а то и больше, -- и они должны готовить именно учёных; ну а для более приземлённых вещей типа обычных программистов или там "вериложников" -- условные техникумы и ПТУ. Ну, думаю, Вы понимаете идею.
внезапно оказалось, что эти самые редко используемые команды многократно ускоряют выполнение соответствующих классов задач
Это понятно, я сам работал в MIPS 10 лет и видел как стали делать page walker вместо этой хитроумной схемой по софтверному перепрограммированию TLB на лету.
С другой стороны, нельзя подготовить исследователя/учёного, если у него кругозор ограничивается тем, что нужно и эффективно здесь и сейчас.
Кругозор - это хорошо, но если кругозор есть, а задачки на интервью решать не умеет - то что делать? Направлять работать в журналисты, а не в микроархитекторы CPU? В вузе время ограничено, а кругозор можно и вне курсов набрать.
ну а для более приземлённых вещей типа обычных программистов или там "вериложников" -- условные техникумы и ПТУ.
Вы думаете у человека, у которого не набита рука на верилоге - вдруг возникнет талант сделать гениальный CPU? Это не получится по очень банальной причине: когда дизайнер придумывает микроархитектуру, стадии конвейера, внутренние буфера и таблицы всякие - он должен очень хорошо чувствовать у каких операций будет какая задержка внутри такта. Если это чувство неразвито, то получится очень дурацкая ситуация: по тактам процессор выполняет CoreMark / MHz быстрее конкурентов, но его нельзя синтезировать на высокой частоте.
Если процессор A выполняет бенчмарк за миллион тактов, а его конкурент B только за два миллиона, но при этом процессор B можно синтезировать с той же библиотекой ASIC на 1.5 GHz, а процессор A - не более чем на 0.5 GHz, то процессор A будет невозможно продавать. Это не умозрительная идея, я такое видел у двух компаний. Причем одна из них была стартапом, который пыталась выкрутиться просто не включая данные о максимальной тактовой частоте в презентации венчурным капиталистам.
Вы думаете у человека, у которого не набита рука на верилоге - вдруг возникнет талант сделать гениальный CPU? Это не получится по очень банальной причине: когда дизайнер придумывает микроархитектуру, стадии конвейера, внутренние буфера и таблицы всякие - он должен очень хорошо чувствовать у каких операций будет какая задержка внутри такта
Скорей, не в верилоге или другом ХДЛ, а в схемотехнике: нужно же понимать, в какое "железо" превращаются те или иные конструкции языка, а не просто уверенно владеть синтаксисом ХДЛ и уметь описать на нём желаемое поведение.
А вот и нет. Я могу прочитать курс по этому плану так, чтобы избежать всех Ваших замечаний. Но не стану этого делать потому, что план является последовательным, а последовательное изложение любой нетривиальной темы заведомо ущербно. А не ущербно - итерационное. Поэтому курсы и математики и физики, в хорошем вузе, и возвращаются к одним и тем же вещам снова и снова.
Ключевой навык обучения - способность обнаруживать и откладывать до поры непонятное. Ключевая психологическая особенность в основе способности к обучению - отложенное непонятное подогревает интерес. Это не у всех так, поэтому и обучение не для каждого. А объём непонятного помещающийся в мозги - главное, что определяет максимальную скорость обучения. Через шаг итерационной спирали определяет.
Изложить материал так, чтобы всё новое основывалось на уже изученном, часто можно, но всегда контрпродуктивно. В реальной работе, кроме той где коленом под зад от ИИ сразу, так всё равно не будет. Способность сначала увидеть непонятное а потом заметить что оно стало понятным - ценность сама по себе, развивать потребно. Чем логичнее новое вытекает из старого, тем труднее учащемуся сообразить почему сделано так а не иначе.
С другой стороны, интересы и снятия денег за обучение с контингента поширше, и нежелания преподавателей вкалывать работая с учениками, или хотя бы группами учеников, индивидуально, и уже уходящей потребности воспитать работников удовлетворённых местом у конвейера вполне, и стремления добиться того, что Вы живописуете в последних трёх абзацах - они совпадают и требуют как раз последовательный план...
Лирические отступления на тему числом три, к делу не относящиеся
Автору главы приходится объяснять
А вот Стругацкие, вспоминая творческий путь, отдельно выделяли момент, показавшийся им потрясающим, когда они осознали - объяснять сразу не обязательно.
Есть один любимый мной мультик, где молодая девчёнка в статусе перспективной певицы даёт концерт для бригады строителей, а перед ним даёт ещё и интервью. В нём она сначала вываливает, с дивной точностью, всё, чем её уже успели загрузить, а потом заканчивает словами: "а почему выступать нужно обязательно в купальнике - это я узнаю позже". Её я бы мог выучить...
Обучение есть развитие, развитие происходит по спирали, диалектика называется, а про силу спирали тоже есть специальный мультик. Тот, где бур пронзает небеса.
Я не против итеративно-спиралевидного обучения, но против введения больших блоков мутных сущностей с ссылками на "мы объясним это потом". Потому что тогда фраза "потоки разделяют этот ресурс через семафор" будет звучать как "поток энергии випасанны пошел через нижнюю чакру".
Чтобы не было мути, это необходимо объяснить объектами более низкого уровня - atomic access, прерывание итд. А на другой итерации добавить и hardware-supported mutithreading.
Описываемый курс -- явно вводный и фактически может быть сведен к тех документации от разработчика, которая полностью определена, и поэтому систематическое последоательное изложение возможно. В отличие от упомянутых математики и физики, где на пару понятий -- дюжина логических и философских проблем, и литерали один господь бог знает, почему оно работает. Не, я понимаю, что как работает современный Виндовс уже тоже никто не знает, и уж точно не препод в среднем вузе, однако онтологическая разница пока еще есть.
Поставил Вам плюсик однако за другое - учебные курсы не должны охватывать всё без пробелов, это просто неэффективно. Они должны предлагать правильный и целеориентированный подход к предмету. Возможно, автор поста и прав по-своему, но с той конкретной авторкой преподавательницей у него конфликт целей, который он собственно и изложил, так что пост у него в общем риторический.
Разумеется курсы не должны охватывать все. Вводный курс вообще должен построить только набросок дискциплины. Но в этом наброске я был хотел, чтобы было без камлания неопределенными словами. Я вот ниже написал:
Если человек произносит слова "параллельные процессы в операционной системе", это не значит что он их понимает. Что значит "параллельные"? Микроконтроллер выбирает инструкции из памяти по одной (оставим за скобками prefetch итд). Где берется параллельность? Это не "понятные", а просто многократно повторенные другими людьми вокруг и в брошурках для пользователя.
А вот если курс перевернуть, то все становится определено.
Я могу прочитать курс по этому плану так, чтобы избежать всех Ваших замечаний.
Что вы будете делать, если во время лекции после ваших слов "параллельные процессы в операционной системе" - встанет какой-нибудь студент и спросит:
"Что значит "параллельные"? Микроконтроллер выбирает инструкции из памяти по одной (оставим за скобками prefetch а также выборку нескольких инструкций из строки кэша в fetch unit итд). Где берется параллельность?"
Как вы это объясните без упоминания слов "прерывание" и "сохранение регистров которые входят в контекст процесса"?
Ну, первым делом я бы очень удивился. Потом бы сказал что-то по настроению, с большой вероятностью типа "Вы узнали, что микроконтроллер выбирает инструкции из памяти по одной и заключили, что он только это и делает. Причина Вашего недоумения в том, что такое заключение неверно."
Слова "прерывание" и "регистры" - это часть решения. Проблема должна быть объяснена до решения, это весьма удобно. Поэтому я бы и удивился - студент должен был уже понимать, что параллельность берётся из необходимости в параллельности. Оставить такое вот, и вообще всё про решения, на будущее, просто - говорим, знаете ли, проблема решена и решение мы рассмотрим тогда-то, или не рассмотрим - ищите самостоятельно там-то.
Отложить объяснение проблемы на будущее тоже можно, но это, как по мне, рисковано и избыточно расходует ценные ресурсы психики обучаемого. А может и нет. Например, когда объясняют асинхронность, обычно пишут async и сразу await, и на этом всё. Выглядит как чистое безумие, но если человек сам догадывается почему нет - наверно получает пользу, но если так и не догадывается...
Поскольку процессор выполняет команды, для него выглядящие как набор битов (машинный код), а для человека -- как программа на языке ассемблера, то, очевидно, перед разбором того, как процессор устроен и работает, необходимо разобраться, как писать программы на ассемблере и как команды кодируются.
Поскольку ОС управляет выполнением программ, а последние, опять-таки, являются последовательностью команд ассемблера, то опять нужно понимать, что в реальности они из себя представляют, как выполняются на концептуальном (не физическом) уровне и т.д. -- знать про регистры, про адреса памяти и т.д. и т.п. Соответственно, базовый курс по ассемблеру должен предшествовать курсу по ОС.
Что касается ввода-вывода, то прежде чем браться за ОС и её драйверы, неплохо знать, как реально ведётся работа с устройствами -- а этого проще всего достигнуть написанием (или разбором готового) небольших программ, взаимодействующих с простыми устройствами типа UART на уровне регистров. Тогда станет достаточно очевидно, что ОС, во-первых, абстрагирует прикладные задачи от подобного "общения" с устройствами, зависящего от специфики устройств и т.д. и т.п., во-вторых, организует очереди запросов ввода-вывода, а в-третьих, разруливает обращения от разных задач к одним и тем же устройствам по определённым правилам.
В общем, курс по ОС в любом случае должен быть последним, ибо ОС имеет дело с низкоуровневыми сущностями, с которыми нужно быть более-менее знакомым до того, как начать разбираться с работой ОС.
Никуда вы не денетесь! Поле знания многомерно (причем с очень большим количеством размерностей), а нить повествования - одномерна. Следуя по ней преподавателю приходится оставлять в стороне целые вселенные. И идти приходится не просто по спирали, и даже не наматывать клубок, а буквально превращать эту нить в войлок.
Как говорил В.И. Ленин: «Учиться, учиться и ещё раз - Учиться». Когда мне приходилось учиться по книгам (был такой период), то обычно одной книги было мало. Ну, подумаешь, в одной книге криво написали - возьми вторую, третью, пятую. Поначалу начинаешь обращать внимание на незнакомые термины и запоминать их контекст, потом, после N-й попытки глядишь - и начал понимать тему в любой последовательности.
Нельзя научить, можно только научиться, было бы желание. Сильному желанию плохая книга не помеха, а нет желания - и хорошая не поможет (но хотя бы оставит приятное впечатление).
Помню, как я однажды узнал, (1990 год), что программы пишут на C++, у меня был опыт только школьных упражнений на Basic. Один знакомый дал текстовый файл с азами программирования на C++, я его распечатал на матричном принтере в тетрадь с пружинкой. Вот это был квест - это сейчас в инете можно найти описание любой ошибки, а в тот момент у меня под рукой только Компилятор и эта распечатанная книга и больше ничего, даже того знакомого не было, чтобы спросить. Первое сообщение было о синтаксической ошибке. Дальше пошли вычитывание книги и прокачивание интуиции (Basic от C всё-таки сильно отличается). К сожалению, по прошествии времени я не смог найти ту распечатанную тетрадку, может она и не лучшая была, но она научила меня внимательности и не верить всему, что написано перед глазами: ошибка там была из-за отсутствия в конце строки точки с запятой, в Basic их ведь нет, поэтому я и пропустил случайно, а ошибка, как любит делать коварный C, сообщала, что строкой ниже встретился недопустимый знак «}». Представьте ваши ощущения, когда вы сами в результате экспериментов доходите до того, что «случайно» понимаете причину ошибки. В моём случае это было на втором или третьем перепечатывании примера с 0 и тут я и обратил внимание на этот символ «;» после printf(), потому что в примере с hello_world этот символ был единственным на всю программу и его важность была дико не очевидна, т.к. в других строках этого символа нет (наверняка вы вспомните эту самую простейшую программу hello_world, где символ «;» встречается только один раз в распечатке).
Забавно, что после получения корректного результата через пару страниц нашлось-таки описание как раз именно моей ситуации и что я всё правильно сделал.
Поэтому я даже соглашусь с вами, что можно и правильнее написать книгу, о которой вы говорите, но помните мультфильм «Ральф против интернета», когда Шенк спалила двух игроков:
-Шенк, тебе не кажется, что ты немного жестковата?
-Но если поддаваться, то в чём смысл?
(Простите, у меня прямо сейчас было много свободного времени, чтобы всё это написать)
Согласен со сказанным в статье, однако, кроме того, мне представляется, что для такой глубины обучения, которая включает набор команд, здесь смешаны две или три различные дисциплины.
В принципе используя в качестве целевой платформы какой нибудь Tang Nano 20k можно пройти весь путь от базовой логики до ОС (линукс там поднимается , в качестве курсовой/дипломной можно дать портирование, скажем, 9front).
Для стран такой дефект становится фатальным: в одной стране происходит засилье импорта и студенты превращаются в продавцов в компьютерных магазинах, а в другой стране происходит массовый завоз инженеров из других стран, и местное население вытесняется работать в макдональдс.
В минском БГУИР (МРТИ) порядок преподавания этих тем правильный и давно, следовательно в РБ очень сильные инженеры-микроэлектронщики/программисты. Есть пул компетентных кадров, так сказать. Подскажите, когда в Минске откроются центры разработки Samsung, Nvidia и AMD? А то пока за таким крупняком людям приходится в Польшу ездить или дальше.
Если проанализировать как учили Гарри Поттера в Хогвартсе, то тоже можно прийти к выводу что учили его и его однокурсников плохо, но научили то хорошо! А до этого весьма профессионально научили того кого нельзя называть, ...
Мне кажется с обучением всегда так. Не очень результат обучения зависит от обучателей, больше от обучаемых, ну может еще от внешних обстоятельств. Сказка ложь, да в ней намек.
Не знаю как учили в Хогвартсе, но от интервьирования студентов я понял, что в университетах нужно что-то менять. Их превратили в дорогой научпоп, большинство выпускников беспомощны, могут поговорить, не могут решать инженерные задачи.
Это я согласен совершенно! Но только дело не в том что там порядок чего-то не правильный, мне кажется, а в том что обучение совершенно оторвалось от какой бы то ни было практической применимости изучаемых предметов!
Вот я когда учился у нас были постоянно и много практические лабораторные, а теперь все поголовно и совершенно ушли в область сферических коней в вакууме, облачных вычислений и искусственного интеллекта. Из сферического вакуума у нас, кстати, тоже было в 90-е, например Z-преобразование (по схемам с задержками и коэффициентами - никогда не встречал потом на практике!), но это было только на первом курсе, на абстрактном мат-анализе.
А про то что сейчас расцвело мне нравится как Гоголь когда-то написал:
«Тогдашний род учения страшно расходился с образом жизни: эти схоластические, грамматические, риторические и логические тонкости решительно не прикасались ко времени, никогда не применялись и не повторялись в жизни. Учившиеся им ни к чему не могли привязать своих познаний, хотя бы даже менее схоластических. Самые тогдашние учёные более других были невежды, потому что вовсе были удалены от опыта».
А мне вспомнился Терри Прачет и его "Народ", где "полуглавная героиня" -- девочка из британской королевской семьи, попавшая на почти необитаемый остров -- в один момент думает, что их (девочек знатного происхождения) учат лишь тому, что точно никогда не пригодится в реальной жизни :)
Из сферического вакуума у нас, кстати, тоже было в 90-е, например Z-преобразование (по схемам с задержками и коэффициентами - никогда не встречал потом на практике!), но это было только на первом курсе, на абстрактном мат-анализе
Из школьного: вводят производные и интегралы в последних классах на уроках алгебры -- но чисто "сферически в вакууме", и основная масса учеников понятия не имеет, нафиг нужны эти математические извраты. А вводить можно было бы даже раньше, но в рамках физики -- механики, где прекрасно видно, как резко эти извраты упрощают решение многих задач, приближённых к реальности (преобразования между путём-скоростью-ускорением и т.п.). Как по мне, пользы от такого обучения было бы куда больше: и достаточно понятная, очевидная и практически применимая физика, и сразу математический аппарат для её обслуживания.
мне даже кажется что это какая-то национальная особенность, что любые методы (математические как пример) в нашем образовании максимально отделяются-отрываются от их практического использования, и подаются в каком-то совершенно абстрактном виде и это в конечном итоге приводит к тому что Гоголь описал, потому что в конечном итоге связь с реальностью этих методов таким образом в какой-то момент совершенно теряется.
Может это своего рода предрасположенность в психологии любых империй (Британия тоже была империей), которая ведет как раз к краху империй, который в истории регулярно наблюдается.
Кстати, вот этот мой Высокий слог тоже мысли примерно в этом направлении.
Помню, на городской олимпиаде по физике какую то задачку по электростатике решил интегрируя уравнения Максвелла (почитывал фейнмановские лекии класса с 9го), прокатило )
Скорее всего её метод обучения построен по образу от более понятного к менее понятному, вот и всё, это объясняет почему главы перевёрнуты
Если человек произносит слова "параллельные процессы в операционной системе", это не значит что он их понимает. Что значит "параллельные"? Микроконтроллер выбирает инструкции из памяти по одной (оставим за скобками prefetch итд). Где берется параллельность. Это не "понятные", а просто многократно повторенные другими людьми вокруг и в брошурках для пользователя.
Микроконтроллер выбирает инструкции из памяти по одной
А там вдруг VLIW ;) А так согласен, хорошо когда кандидат может рассказать про разные уровни параллелизма в железе и софте и маппинге одного на другое. И может внятно рассказать, что происходит при исполнении инструкции по загрузке из памяти в регистр.
Это просто вводная лекция, чтобы первокурсники не разбежались от скуки на первой неделе. Начнут с транзисторов - до сессии доживет полтора землекопа
Логично строить обучение снизу вверх, но подход сверху вниз тоже работает. Даем абстракцию ОС, а потом постепенно спускаемся под капот к прерываниям и ассемблеру
Но тогда начинается жонглирование словами, которые не несут физического смысла. Я выше написал:
Вот возмем фразу "параллельные процессы в операционной системе". Что значит "параллельные"? Микроконтроллер выбирает инструкции из памяти по одной (оставим за скобками prefetch а также выборку нескольких инструкций из строки кэша в fetch unit итд). Где берется параллельность? Как это объяснить без упоминания слов "прерывания" и "сохранения регистров которые входят в контекст процесса"? Вот и пререквизиты.
Ровно такое же жонглирование словами будет и в обратном случае: "И какая конкретно команда процессора используется, когда я выполняю клик на "Пуск"?
Никакой кнопки пуск еще нет на тот момент в материале, как и ОС.
Тут ничего жонглировать не нужно. При нажатии на кнопку мыши происходит транзакция на шине USB которая либо выставляет бит в memory-mapped регистре ассоциированном с данным устройством, либо вызывает прерывание, которое обрабатывается драйвером. При входе в обработчик прерывания первая команда может быть например сохранение регистра, который предполагается использовать для проверки причины прерывания. Это все можно продемонстрировать на плате с встроенным процессором.
Кстати, не конкретно эта, но смежная тема меня сейчас практически интересует. Сразу после включения ноутбука эмулируемый i8042 даёт работать с клавой, но на любые обращения к мыши выдаёт fc (error). Тачпад GT7863 вроде как в PS/2 эмуляцию умеет, но вопрос как её включить. Всяческие команды инициализации/тестирования самого i8042 и aux пробовал, ничего не меняется. Винда и линукс, скорее всего, работают через I2С, но хочется с минимальными телодвижениями поднять PS/2.
Хотел было поинтересоваться, зачем начинающая преподавательница вдруг изобретает давно уже изобретённый велосипед, но вспомнил старые байки про академическую литературу в некоторых университетах. Те истории, где студентам для положительного результата полагается готовиться непременно по материалам "от местной профессуры" с доступом к оным материалам за отдельные деньги. Когда затейливые эрзац-"знания" и "формулы замещения" реальных знаний в сопровождении эклектичных "corner case'ов" как раз и являются искомыми признаками того, что студент готовился к экзамену/курсовой "как следует". И если это на самом деле так, то речь просто идёт о действительно перспективной начинающей преподавательнице )))
С другой стороны, когда реальная цель у системы зарабатывать (осваивать) как можно больше денег - вполне естественный результат.
Для себя я выделил 2 основных вида людей по склонностям "какое объяснение они понимают".
Для одних лучше подходит теоретическое объяснение - ну примерно как курс матанализа в физмат-школах (или стары объяснения ЯП - на основе формальных грамматик).
Для других - около-практические. Примерно как пишутся современные доки на ЯП (Python / Rust). Когда даются практические примеры показывающие ключевую, объясняемую ЗДЕСЬ И СЕЙЧАС особенность. При этом допускается видеть что-то незнакомое, если оно +/- понятно (ну например import).
При этом большинству людей явно ближе второй подход: от знакомого к незнакомому, при этом всегда есть "вот эта магия примерно так работает, объясним потом".
В этом случае память быстро исчерпывается, и человек начинает теряться в не систематизированных деталях. Далее он либо переходит к схеме 1 (теория сначала), либо останавливается в обучении.
Что значит "примерно так работает"? Чем это отличается от "энергия випасанны пошла через чакры"? Я написал ниже:
Что вы будете делать, если во время лекции после ваших слов "параллельные процессы в операционной системе" - встанет какой-нибудь студент и спросит:
"Что значит "параллельные"? Микроконтроллер выбирает инструкции из памяти по одной (оставим за скобками prefetch а также выборку нескольких инструкций из строки кэша в fetch unit итд). Где берется параллельность?"
Как вы это объясните без упоминания слов "прерывание" и "сохранение регистров которые входят в контекст процесса"?
>Чем это отличается от чакры
Тем что есть гарантии API.
Скажем ни один человек, ни даже всё человечество не знает как работают физические законы до самого конца - но это не мешает конкретным людям пользоваться формулами (которые просто API предоставляемые физическими дисциплинами).
> что значит примерно так работает.
Это значит, что я отдаю себе отчёт, что есть сложные контринтуитивные вещи (*) которые студенты до конца не поймут пока не попробуют руками на практике, гораздо бОльшей, чем написать лабораторку.
*) (параллельность тредов, скажем не настолько сложная). А например Memory Ordering (лежащие под ним понятия, что нет никакого "момента" когда операция применилась к кэшу или другой распределённой системе - есть лишь гарантии наблюдаемости другими операциями) - это настолько контринтуитивно, что большинство студентов не поймут ни после лекции ни из лаботаторки возможного на практике размера.
=========================================
Заметьте я не говорю, что курс хороший, а лишь подход имеет право на существование.
Поэтому предположим я бы читал "архитектуру компьютеров" - по классической иерархии абстракций сверху вниз: проблема - программа - платформа - ISA - microarchitecture - RTL - ... и прозвучал бы ваш вопрос "что такое параллельность".
Хорошо, что ты задал такой вопрос, даже если абстракции не текут, то знание на 2 уровня абстракции в глубину позволяет принимать более качественный решения при работе над "своим" модулем.
Однако: единственный индустриальнйы способ разрабатывать сложные системы это модульность (с использованием интерфейсов) - которая подразумевает, что у нас есть гарантии от нижележащего (его API) и на их основе мы должны предоставить более удобные и богатые абстракции вышележащему слою с какими-то гарантиями(наше API).
Параллельность обозначает что мы не можем никак закладываться ни на какой порядок исполнения команд (для программы инструкций для ISA), за исключением эксплицитно прописанных синхронизаций (однако на конкретных платформах можем).
Про многопроцессорную параллеьность мы пройдём в главе "диайн SoC", про SMT-параллеьность мы узнаем после прохождения AoO-конвейр CPU. Про самый простой вид параллельности с разделением времени - сразу после главы "прерывания".
Сейчас ты оперируешь неправильными абстракциями. А именно ты не разделяешь понятия "видимость результатов операции" и "исполнение операции". Объяснять разницу сейчас - потребует слишком много времени, но ты всегда сам можешь про это прочитать.
К стати "1" и "2" (как и сама классическая иерархия абстракций) - наверное самые efficient общеинженерные знания (по соотношению чего простого слильно не хватает большинству студентов) которые нужно давать в институте.
Параллельность обозначает что мы не можем никак закладываться ни на какой порядок исполнения команд (для программы инструкций для ISA), за исключением эксплицитно прописанных синхронизаций (однако на конкретных платформах можем).
Это асинхронность.
При асинхронности на одном ядре можно по крайней мере на sequential consistency полагаться.
Если это определение неверное - вы легко приведёте контрпример.
Пожалуйста.
Два фактически последовательно друг за другом выполненных процесса являются асинхронными друг по отношению к другу (если последовательное выполнение не гарантировано), но не являются параллельными.
Например, сначала позавтракал, потом асинхроннно к завтраку подумал об асинхронных процессах. А если бы параллельно - то это было бы во время еды.
Не понимаю как это делает невалидным определение (не говоря уже о использовании каких-то мутных конструкций типа "фактически последовательных".
Из-за мутности примера кажется что вы хотели использовать инверсию импликации - но точно утверждать не могу).
Пожалуйста приведите конкретный пример последовательности операций при многопоточности когда моё определение не верно.
Параллелизм - это физическое понятие - определённая зависимость от времени, а не логическое. Тут не в последовательности операций дело.
Я привёл пример с завтраком. Если вам так хочется именно с потоками, то это любые два независимых потока, один из которых завершился раньше старта второго. Они асинхронны, но не параллельны.
Параллелизм - это физическое понятие - определённая зависимость от времени, а не логическое. Тут не в последовательности операций дело.
Вполне себе логическое. CS-еры \ компиляторщики именно так об этом и говорят. Более того, определение дано именно в таком ключе (как о гарантиях для всех случаев) - если вас это смущает, могли бы сразу об этом и написать. А не портить объяснения об IT неуместными аналогиями с "завтраками" (как это очень любят делать нейросетки, например).
==============
Ну и до кучи ошибки допущенные вами:
Вы пытались доказать неверность моего определения, а доказали (доказали с ошибкой) неверность какого-то левого выдуманного вами. Зачем?
Вы пытаетесь совершить логическкую ошику "инверсия импликации". (a => b) => (!b => !a). Не надо так.
Если предусловие не выполняется импликация всегда истинна, просто запомните.Зачем Вообще говорить о параллельности полностью независимых процессов \ потоков? О параллельности говорят когда потоки как-то влияют друг на друга: control flow \ data flow \ да хоть замедление выполнения или увеличение времени отклика.
Извините если был чересчур придирчивым - но кажется это вы выступили "определения-наци" позиций.
Параллелизм - это не модель исполнения, а техническая характеристика вычислительной системы.
Не думаю, что ваш менторский тон уместен.
Update:
Наш разговор уходит в какие-то мелочи.
Если хотите - можем начать заново с формулировки позиций с чистого листа.
===============================================
Докопаться до определнения.
Совершить 3 очевидные ошибки когда были поставлены в равные условия.
Жаловаться на "менторский" тон.
Л - логика.
П.С.
Параллелизм - это не модель исполнения
Снова ошибка №2 (из пунктов выше) - вы спорите с тем, чего я не говорил. В очередной раз.
Если я не прав - вы же с лёгкостью процитируете где я сказал, что "параллелизм - модель...." (а не например свойство модели или например google: "модель параллельных процессов" или ещё что-то похожее по форме но иное по содержанию)".
Или опять будете прятаться за "неправильный" тон собеседника.
Так вы свои посты редактируете постоянно, что их цитировать? Но так как всё-таки копия остаётся в почтовой рассылке, то я вам процитирую изначальный вариант вашего сообщения, на который я отвечал, и который вы поменяли в неоправданной надежде добиться тактического успеха в дискуссии:
Здесь вы делаете ровно такую же ошибку - перепутали "конкретный запуск" с "моделью исполнения".
Но добавлю, что параллелизм – это и не свойство модели исполнения тоже. Он вообще не имеет непосредственного отношения к тому, как устроены процессы.
Параллелизм (с точки зрения ОС) – это то самое, что вам выводит команда top:
Processes: 784 total, 2 running, 782 sleeping, 3007 threadsЗдесь мы видим 3007 параллельных ниток, большинство из которых никак не связаны друг с другом, и многие из них не имеют вообще никакой модели синхронизации, так как не синхронизируются вовсе.
У отдельных исполнительных устройств есть свой собственный внутренний параллелизм, но смысл его тот же самый. Выполнение следующей работы до окончания предыдущей.
В функционировании человека тоже есть параллелизм, и нет ничего плохого в том, чтобы на это указать.
Что касается определения, то оно важно, так как многие люди путают параллелизм с логической асинхронностью.
А что до менторского тона, то он уместен, когда есть соответствующие регалии, а не от анонима в интернете. Тут уж, извините, придётся вам подсократить ЧСВ.
Если что - моё предложение начать заново в силе (кажется я понял что вы имеете в виду - но додумывать за вас вашу работу не хочу - в конце концов не я залетел в трэд с двух ног с придирками к определению).
=======================================
I.
Вы так и не привели контрпример - который бы противоречил приведённому мною определению.
II.
Вы повторяете то, что я гораздо кратче (и глубже с точки зрения иерархии абстракций) описал 3 дня назад.
Зачем?
III.
Вы так и не смогли привести где я говорил, что "параллелизм это модель" - или эквивалентное, например "параллелизм является моделью".
Факт.
IV.
> Но добавлю, что параллелизм – это и не свойство модели исполнения тоже. Он (параллелизм) вообще не имеет непосредственного отношения к тому, как устроены процессы.
> параллелизм - это техническая характеристика вычислительной системы
А потом этот человек обижается, что ему указывают на его ошибки как-то слишком "строго".
Слово "асинхронность" употреблять опасно, потому что оно в софтвере и хардвере означает разное. Например есть процессоры спроектированные по асинхронной методологии без тактового сигнала.
Параллельность обозначает что мы не можем никак закладываться ни на какой порядок исполнения команд (для программы инструкций для ISA), за исключением эксплицитно прописанных синхронизаций (однако на конкретных платформах можем).
Это другая параллельность - на уровне микроархитектурной реализации. Да, в конвейере сложного процессора могут одновременно находится находится на разных стадиях исполнения десятки инструкций, многие спекулятивно. Но в конечном итоге, на стадии write-back / graduate (в терминологии MIPS) / retire (в терминологии Intel) все будет записано в архитектурные регистры так, что для пользовательской программы гарантирована иллюзия последовательного выполнения.
(Эта иллюзия нарушается для определенных инструкций в привилегированном режиме, но оставим это за скобками)
Когда говорят о параллельных процессах в операционных системах, как правило имеют в виду в виду другие упомянутые вами параллельности:
параллельность между процессами, которая организована с помощью прерываний.
Реже - многопроцессорность с кэш-когерентностью.
Редко - поддержку со стороны OS многопоточных процессоров, например ThreadX поддерживает MIPS 34K и его потомков.
Но как минимум (1) стоило было бы объяснить сразу при введении в операционные системы.
Это другая параллельность - на уровне микроархитектурной реализации.
Ваш студент применил термин "параллельные процессы" - пришлось пояснять все три источника параллельности в аппаратуре.
Если бы в примере была, например "вытесняющая многозадачность" - я бы рассказал только про неё.
Так что ваши разъяснения (1) (2) и (3) - говорят что предполагаемый студент просто плохо понимает термины которыми пользуется и если он сказал "параллельные процессы" то ответ будет именно про них.
===================================================
Если же говорить про дедактическую часть - то да, разумеется вы правы и про вытесняющую многозадачность следует рассказать в курсе ОС.
Но всё равно - рассказать про "контекст процесса" и "переключение контекста" вполне можно без регистров. И это будет не "магия" а "таков API", через месяц пройдём.
П.С.
Извините - вопрос распался на 2 "фактология" vs "дидактика" я не очень понимаю про какую вы сейчас.
Вообще, невозможно идеально упорядочить материал: связи между темами это скорее граф, а не линия. Преподаватель же должен каким-то образом это линейно упорядочить, ну просто потому, что изучаем мы последовательно. Тут по-видимому очень глубоко, и возможно связано с ролью порядка в теории алгоритмической сложности. Дело в том что данные в памяти часто естественно упорядочены, скажем по номеру ячейки. Этот порядок часто не имеет ничего общего с задачей, но используется алгоритмом. Известно, например, что проблема наличия Гамильтонова пути в графе NP полная. Алгоритм работает как-то так: берём первую вершину из списка, берём соседнюю вершину с минимальным номером... Этот порядок, вообще говоря, не связан со структурой графа, но если мы изначально правильно упорядочили вершины, так что они образуют Гамильтонов путь (или самый длинный путь без повторений), то и нет проблемы, все работает быстро...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
К каким социальным проблемам приводит неправильная последовательность глав в учебнике по программированию