Хабр Курсы для админов
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Администрирование доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 97
"Горячая петля"? А у нас так говорят? Может быть нагруженный цикл? Уже даже вычиткой после ИИ лень заниматься?
Самое смешное когда "bot" переводится как "сапог"...
"Биоволк" (Beowulf).
разок купил гречку в магазине (там), смотрю: "содержание белка 13г", строчка ниже "squirrel content 13g". Вот жеж гады, экспортеры белочек в гречку начали подмешивать! Теперь на сверчков в муке перешли, басурмане! Всегда удивляла экономия в пару баксов на переводчиках.
В России до сих пор плющит от новояза вроде "сайзинг" и тд - ну есть же русские слова. Или используй английский. Сейчас я не знаю как писать документацию на русском - мне проще на английском, потому что не знаю где уместно русское слово использовать а где принято заимствованное.
Я всегда стараюсь использовать русские, за исключением либо устоявшейся терминологии, либо когда не могу придумать достаточно короткого русского аналога. Грубо говоря, я буду писать "монитор" или "дисплей", а не "устройство видеоконтрольное", как в советской документации, но вот в своём переводе "Принципов работы Системы 370" и "...z/Architecture" я exception перевожу, как его перевели в СССР -- "особый случай", ибо слово "исключение" жутко перегружено ("за исключением исключения в связи с исключением".
Потому что он минимизирует зависимость от ветвления
Зависимость от ветвления? В современных чипах это ветвление занимает ноль тактов.
Если речь про чипы эпохи 80-х, то зачем написано про векторизацию компилятором?
облегчает предсказание кэша?
Что-что облегчает?
Старые программисты часто использовали ручную распаковку циклов именно ради этого.
Раскрытие циклов они использовали.
и никто не думал о том, что сборка должна быть мгновенной
Прямо так никто не думал, ага.
Чай сам себя не выпьёт(с)
Зависимость от ветвления? В современных чипах это ветвление занимает ноль тактов.
Неудачно предсказанное ветвление в современных чипах может стоить сотни, а в особо неудачных случаях -- и тысячи тактов.
Прямо так никто не думал, ага.
Угу, не думали-с. Потому что, в зависимости от того, на чём работал и каков объём программы, компиляция и сборка могли занять и несколько секунд, и несколько часов. Это сейчас хелловорлды мгновенно собираются -- и то лишь с точки зрения человека.
Хотя насчёт... хм... языка... хм... статьи я Вами полностью согласен.
Неудачно предсказанное ветвление в современных чипах может стоить сотни, а в особо неудачных случаях -- и тысячи тактов.
Это Вы с кэшем и памятью попутали, неверно предсказанный условный переход стоит на современном интеловском камушке максимум десяток-другой тактов - то ли 15 то ли 19 циклов, но уж никак не сотни и тысячи. И какие "особо неудачные случаи" имеются ввиду? Тут либо верно предсказано, либо неверно. В теории можно заморочиться и померять, но пару часов для набрасывания подходящей оснастки таки придётся положить.
Так а если в кэше нет команды, на которую переход? Жди, пока заполнится из памяти. А если в этот момент с этим банком памяти идёт интенсивный ввод-вывод? Жди, пока он не закончится. Вот и набегают тысячи тактов. Так что неверно предсказанный переход может быть крайне дорогим, если рассматривать всю вычислительную систему в комплексе, а не ограничиваться только процессорным ядром.
А, понял, что имеется ввиду. Это скорее всё-таки именно промах кэша инструкций, а не предсказателя ветвлений. Мне так думается, что когда предсказатель увидел, что зашёл не в ту дверь, то на разворот ему много тактов не надо. Тоже можно померять, но чуть более заморочно. Просто когда мы говорим о пенальти там и сям, то я сторонник подхода "покажите мне код-демку или документацию".
Потому я и сказал про очень паршивые случаи. Сама ошибка предсказания ветвления -- да, где пару тактов (в достаточно примитивных процессорах), где, может, под сотню (Пень-4 с его жутко глубоким конвейером и всё такое), но уж точно не тысячи.
Ещё, кстати, интересно, что будет делать проц, если ветвление предсказано, а команды в кэше нет. По идее, запустит процесс выборки, не дожидаясь точного определения ветвления -- и в случае ошибки это тоже может дорого стоить.
Но я всё это больше к тому, что реальная производительность может очень сильно зависеть от того, насколько хорошо компилятор (или программист) расположил код -- чтоб минимизировать риски кэш-промахов, а тут надо и предсказания ветвлений по возможности учитывать, и адреса размещения и команд, и данных, и команды предвыборки разумным образом вставлять... Ну, это в идеале, конечно :)
Просто когда мы говорим о пенальти там и сям, то я сторонник подхода "покажите мне код-демку или документацию"
Как по мне, зачастую достаточно "правдоподобных рассуждений" -- тем более, что некоторые вещи трудно проверить в реальности. Скажем, создать описанную мной ситуацию (кэш-промах и одновременная занятость нужного банка памяти интенсивным вводом-выводом) на ПК весьма и весьма непросто, если вообще возможно с разумными усилиями, да и на микроконтроллере, где ты работаешь с голым железом и действительно можешь такое создать, за 5 минут демку не набросаешь.
Векторизирующие компиляторы были уже для Cray-1 (1976) и Cyber STAR (1974)
В современных чипах это ветвление занимает ноль тактов.
Ну я вполне втыкался в производительность branch-miss'ов, для этого есть даже хрестоматийный пример, который вы можете воспроизвести и у себя: наивное чтение var-int'ов с помощью цикла. В этом случае у предсказателя переходов слишком высокая доля ошибок. Тривиальное лечение - вручную развернуть цикл, чтобы у таблицы переходов были разные адреса, и тогда если у вас в горячем цикле var-int'ы примерно одного размера, то всё починится само. Если у вас совсем произвольные var-int'ы, тогда есть чуть более сложные техники.
Тем не менее, даже в случае, если у вас всё хорошо предсказывается, таблицы предсказания ветвлений в процессорах не бесконечные. Руками вы конечно вряд ли их забьёте, но если начнёте генерировать код с избыточным ветвлением, то статистика предсказаний вполне может начать вытесняться.
сам пишу программы, поэтому во многом согласен с автором
Я не программист-профессионал. Я любитель.
Я делю людей на тех, кто программирует професионально, и знает в программировании много, нарисуем большой круг.
И вторая категория - те, кто знает в своей профессиональной области много, прямо большой круг, который очерчивает объем знаний в своей профессиональной сфере, который равен по объему знаниям программиста в языках программирования. У него даже может быть меньше, нежели у программиста.
Но знает ли в узкопрофессиональной области (например в телекоммуникациях) программист столько же, сколько телекоммуникационщик? Да нет....Я знаю полно примеров, когда программисты плохо различали TCP и UDP, не знали тонкости протоколов других...
А знает ли телекоммуникационщик в области программирования столько, сколько программист? Да нет, не потянет, особенно в такой лапше как С и ассемблер.
Так вот, если заставить программиста писать код для телекоммуникационной балалайки, то лучше всего ему будет писать на ЯВУ, причем объектном. Пусть трудно будет начинать, но потом код польется как из ручья. Потому как я, как слабый программист никогда такого не напишу с нуля вообще. И на языках НЕ объектных, не очень высокого скажем уровня, я вообще не пойму код.
Но если код будет написан классами и прочими фишками типа python, PHP я, как ни странно, подразберусь сам с написанным, и смогу даже ткнуть на ошибки, и даже! их некоторые исправить.
Другая противоположность - написание загрузчиков, ядер ОС и прочего прочего, что необходимо сделать компактным. Для этого и придумали ассемблер и С. Потому что круг знаний в области программирования с кругом знаний в области предмета у таких кодеров-программеров почти совпадает. И им не надо писать классы, методы и прочее прочее, они напишут кратко и по делу. В чем я точно не буду никогда шарить.
Зато я буду шарить в своей предметной области и смогу сопровождать написанный кем-то громоздкий код на некомпиллируемом языке с классами.
Каждому свое. Вот какой вид открывается с моей колокольни.
Сделайте одно упражнение прямо сейчас: выберите модуль, где вы чаще всего правите баги, и зафиксируйте три вещи которые вы делаете в ручном режиме при его отладке. Затем формализуйте их до чек-листа.
На мой взгляд, если в каком-то модуле приходится регулярно править баги, то это показатель того, что он неправильно спроектирован и написан, и его лучше бы заменить целиком.
По моему опыту, программы 80х - 90х лагали намного чаще и, что важно, критичнее, чем современные. Так что я бы не хотел, чтобы практики тех лет переносили в современную разработку.
А я вот знаю одну СМ-1420 под управлением ОС-РВ, в девичестве RSX-11M, которая без перезагрузки работала несколько лет (что странно, за это время не было поломок не только в чистой электронике -- к тому времени делать её надёжно у нас уже научились, но даже в дисках -- хотя, может, про них уже подзабыл, их на машине несколько штук, поэтому можно было выводить из действия и подключать обратно по мере необходимости). Так что код коду рознь, и качество может быть совершенно различным. Нынешний код, если брать "в среднем по больнице", пожалуй, будет хуже -- но это следствие снижения порога входа в профессию.
Нынешний код, если брать "в среднем по больнице", пожалуй, будет хуже -- но это следствие снижения порога входа в профессию.
Или увеличения среднего количества строк кода на приложение.
Ну то есть если среднее количество ошибок на строку кода осталось прежним, а строк стало больше, то и ошибок будет больше.
не было поломок не только в чистой электронике -- к тому времени делать её надёжно у нас уже научились,
Это когда такое счачтливое время было когда чистую электронику делать её надёжно у нас уже научились? То что делали во втрой половине 80х и в 90х - это было совсем ненадежно. А раньше почти все в мини ЭВМ делалось на 155, немного на 555 серии (тысячи в одной ЭВМ). Я на обслуживании таких сидел, упомянутого светлого периода не наблюдал. Чтобы без перезагрузки работала несколько лет, - ну не знаю, там сервисное обслуживание чаще с полным выключением процессора, насколько помню, спирт на это выделялся.
Были ещё 133, 130 и 224...
Они лучше 155.
133, 130 не было в гражданской технике. А 224-ая серия - Набор толстопленочных интегральных схем для бытовой радиоэлектронной аппаратуры - телевизоров, приемников, не для ЭВМ. Да и 133 и 533 были только немного лучше пластмассы 155.
Ну, 133-ю я в измериловке встречал -- но не в ЭВМ. Хотя, возможно, сами приборы изначально делались для вояк и лишь потом появились на гражданских предприятиях.
131-я была -- кажется, в СМ-1600 в проце как раз К131ИП3, а не 531, но за давностью лет утверждать не берусь.
У меня из моих запасов микросхем самая древняя -- триггер К155ТВ1 1973 года (ещё со старым обозначением, К1ТК551, вроде б). С год назад его специально нашёл, запустил -- работает-с :)
В общем, думаю, тут как повезло (например, на каком конкретно заводе производили микросхемы).
Значит не 224: там были такие металлические квадратики, и точно не для телевизоров )
Дык тогда и было -- вторая половина 1980-х и 90-е. Электроника дохла очень редко. У одной из знакомых СМ-1420 примерно за 10 лет -- одна КР531ИП3 в диспетчере памяти (MMU) и ещё пару отказов электроники в периферии; у одной СМ-1600 постоянно дохли К170-что-то-там в синхронном последовательном интерфейсе, забыл его шифр, но всё остальное работало много лет без проблем; в ЕС-1035 постоянно дохла только оперативная память (К565РУ1, с темпом микросхема в месяц, но код Хэмминга спасал, давая нормально отработать смену), логика -- очень редко (ну, за те же примерно 10 лет несколько микросхем заменили), в проце ЕС-1130 за больше 5 лет сдохла одна К1800ВС1 и, кажется, всё (вот с дисками ЕС-5080 там проблемы были постоянные -- но это уже не чистая электроника). Так что всё вполне надёжно было. Ну а так -- да, в СМках и большинстве ЕСовской периферии -- 155, 555, 531 и небольшое количество БИС (те же КР1804ВС1 в проце СМ-1420), в ЕСках -- в основном, 500-я серия...
А на сервисное обслуживание просто забили -- спирт же по нормам выписывают, а не по факту обслуживания :) Мужикам (на одном довольно крупном машиностроительном предприятии, я на другом работал, но общались постоянно) интересно стало, сколько машина проработает, поэтому и не выключали. (Основная работа была готовить перфоленты и всё такое прочее для станков с ЧПУ и что-то там умное считать -- ну и змейку гонять, конечно).
Дык тогда и было -- вторая половина 1980-х и 90-е. Электроника дохла очень редко.
В девяностые и ни одного отключения электричества за несколько лет? Может на ночь все-таки выключали, производство стояло, смысл впустую десятки киловатт расходовать?
Начали эксперимент ещё при СССР. Завод в три смены работал, поэтому отключать в плане экономии смысла не было (хотя диски, наверное, отключали, тем более, что самой системе они нужны только для загрузки): станки в любом случае жрали куда больше, чем одна СМка. Ну а десятков киловатт даже со всей периферией быть не могло. Процессор -- ватт 700, память -- ещё меньше, контроллеры периферии -- где 300, где 500 Вт... Это ж не ЕС ЭВМ, где действительно несколько десятков киловатт могло быть, когда всё включено.
Дисковые системы с кассетами на кажется 29 мегабайт жрали наверное хорошо больше киловатта, если их несколько, то уже что-то. Мониторы ватт по 500 наверное, их могло быть много, но ночью их выключали скорее всего. Система фильтрации воздуха, без нее никак, пылью все быстро забьется. Освещение не одну сотню ватт в помещении и окрестностях. Кондиционер чтобы все эти киловатты отводить. Не ну если для прикола только один процессор и память оставить плюс один монитор, никаких спец. устройств, кондиционер отключить, то не много мощности будет брать.
Большие машины обычно работали круглосуточно. И длинные расчёты случались, и каждое утро выполнять загрузку было не с руки.
Только не с кассетами, а с пакетами уже -- кассетные были меньше (2,4 и 13 Мбайт). Они действительно много жрали (ЕС-5061, которые очень близки, хотя и не идентичны, -- кажется, 1,5 кВт, а в пике до 3). Мониторы выключали наверняка -- точней, по моему опыту, их включали, когда они были нужны только. НМЛы и принтер -- тоже по необходимости. Какой-нить там мультиплексор передачи данных, к которому мониторы подключены, и контроллеры дисков и лент вряд ли отключали -- но они и жрут довольно мало. Плюс, повторюсь, это завод, там станки в 3 смены пашут -- и на этом фоне что есть та СМка, что её нет...
А что именно, кстати, обслуживали, ежели не секрет? Т.е. какие модели -- может, в этом дело?..
Помню такую машину), писал на фортране для нее с ассемблерными вставками, обсчитывал спектры эффекта Мессбауэра. Ломался часто жесткий диск размером с современную тумбочку. Программных сбоев вообще не помню.
С периферией у нас всё сильно хуже было, если говорить про качество и надёжность. Да и с самими носителями тоже. Были, например, НМЛ ЕС-5025 (если склероз не изменяет), обеспечивающие плотность записи и 32, и 64 бит/мм. Наши ленты на 32 работали, на 64 -- фигвам, а буржуйские (басфовские, вроде б) -- без проблем. Т.е. сам наш НМЛ, получается, реально мог работать на этой плотности (впрочем, у IBM за лет 10 до этого уже была 246 бит/мм), а нормальную ленту производить так и не научились (во всяком случае, доступную обычным предприятиям).
без перезагрузки работала несколько лет
Вы меня удивить этим хотите, или насмешить, я что-то не пойму? У меня в лабе все компьютеры годами работают без перезагрузки, это для современных компьютеров совершенно обычный режим работы. Меня повеселило скорее то, что в вашем представлении непрерывная работа в течение нескольких лет - это какой-то повод для гордости.
Нет, это показатель того, что не только современные компьютеры могут годами работать без перезагрузки.
Только вот для современных это правило, а для сорокалетних - исключение.
1987, кластер, MicroVAX II (KA 630, 32 бита 33 МГц RISC), 9 МБ памяти на узел, полная виртуализация, несколько ТК на полдюймовке, терминальный мультиплексор на 50 пользователей, геораспределенка, по 2 HDD по 27 блинов на 850 МБ с аргоновой продувкой.
Да, на терминалах VT340 было разрешение 800*500, 4096 цветов и оконный интерфейс DECWindow, если надо (не надо).
Годами непрерывная работа; раз в год плановая остановка и автоочистка/калибровка HDD.
шкаф документации (читаешь - и понимаешь, что ничего нового в Windows/*nix за 40 лет не изобретено (разве что ИИ, да и то - нет, был же Lucas), и это всё - просто потомки (от ядра NT до PowerShell, удивительно напоминающего DCL по идеологии (DEC Command Language). Даже файловая система-БД NT Longhorn, которая в серию не пошла - с ушами RMS (VAX/VMS Record Management System).
Я бы не недооценивал сорокалетних :))) это не только брак СМ
ЗЫ. а еще на экран VT340 можно было налепить (сама прилипала) дискету 5.25, что заглючила, и его включить - петля размагничивания сама чинила дискеты :) )
ЗЗЫ. а еще в 2010+ продолжало работать.
читаешь - и понимаешь, что ничего нового в Windows/*nix за 40 лет не изобретено
Plug & Play?
пожалуй, тут вы правы ) хотя probe/challenge/handshake протоколы были, но тут - да.
Был автоконфигуратор что в RSX-11, что в VAX/VMS, -- но он полагался на то, что устройства будут по стандартным адресам: обнаружил, что по некоему адресу что-то есть -- значит, это устройство такое-то, даже если там совсем другое устройство. Т.е. P&P в привычном современном виде, кажется, возникло всё-таки на ПК с программной поддержкой, в первую очередь, в Винде.
Но, за исключением P&P, я не знаю никаких "низкоуровневых" вещей, которые не использовались (пускай и в единичных случаях) уже в начале 1970-х.
Точно! RSX уже подзабыл, а в VMS 5.3 точно был, как раз probe/challenge. Но привычнее был ручной конфиг.
адреса или жесткие или перемычками/переключателями, поэтому искать что попало где ни попадя не нужно было.
А как приятны были команды типа stop dub0:ivanov :)
а еще в тему статьи можно было писать сразу на Fortran / Pascal / C и с добавлением BLISS и DCL - и всё работало из коробки.
P&P по существу был уже на Apple II. Там драйвер устройства находился в ПЗУ платы расширения, а операционная система просто инициализировала его переходом в начало адресного пространства устройства.
Не было. То, что там было (я с этим знаком, хотя, в первую очередь, на наших Агатах, которые были полуклонами Эпла-2) -- это даже близко не P&P, это именно что вызов подпрограмм инициализации по фиксированному набору адресов из ПЗУ плат расширения, ежели таковые присутствовали. Абсолютно то же самое было реализовано (позже, да) в IBM PC, но никакого отношения к P&P это не имело.
P&P -- это, по меньшей мере, возможность стандартным образом определить наличие устройства, его тип и требуемый ему набор ресурсов, чтобы иметь возможность распределить их между имеющимися устройствами. Вызов же подпрограммы из ПЗУ более-менее решал только первую из этих задач.
Так если там ресурсы уже в силу архитектуры были заранее распределены между слотами, зачем их ещё раз распределять?
P&P, по определению – это возможность подключить устройство, чтобы при этом оно сразу работало, без необходимости что-то конфигурировать руками в аппаратных или программных настройках. И это на Apple II выполнялось.
Это ущербный "P&P". Сие могло работать только на крайне убогой машине (Эпл-2 -- как раз такая, как и всё прочее 8-разрядное) с крайне убогим набором периферии (в природе существует 2,5 устройства, а сделать и воткнуть 25 в принципе невозможно -- ограничено количеством предусмотренных разъёмов, которое нельзя расширить -- в отличие от, например, ISA или PCI), где вся поддержка намертво зашита в ПЗУ и в "операционную систему" (нет возможности использовать сторонние устройства со сторонними драйверами). Для сколько-нибудь серьёзной техники это абсолютно недостаточно -- потому на ПК в конце концов P&P и сделали. А это... для меня -- ни разу не настоящий P&P.
25 устройств, конечно, воткнуть в Apple II невозможно (да это никакому персональному компьютеру и не нужно, и во всяком случае в шину Apple II можно было воткнуть больше, чем в стандартный PCI), но что касается существования в природе – тут вы сильно неправы. На то время это был персональный компьютер с самым развитым набором периферии. К нему и роботов подключали, и второй процессор, и бог знает что ещё. Именно благодаря прозрачной шинной архитектуре.
В стандартную PCI можно воткнуть много больше -- поскольку она не навязывает определённое распределение ресурсов и т.д. и т.п., ну а электрические ограничения преодолеваются с помощью мостов. А вот с эпловской шиной это не провернёшь -- как раз благодаря его недо-P&P.
Пы.Сы. ISA не менее прозрачная, да и более ранние шины тоже -- Unibus, например.
Но только драйверы многих устройств PCI через несколько мостов не будут работать. Именно поэтому материнские платы более чем с 4 слотами являются большой экзотикой, и там зачастую даже вместо второго моста использовалась PCI Bufurcation, требующая настройки вручную вместо обещанного PnP.
Кроме того, PCI – несимметричная шина в том смысле, что хост туда не воткнёшь (как было со вторым процессором Z80 в Apple II).
По поводу Unibus и прочих не спорю – я вовсе не имел в виду, что Возняк первым изобрёл универсальную шину. Но как там было всё организовано программно, мне неизвестно.
Мосты PCI прозрачны для обычного обмена и никакого влияния на драйверы не оказывают. Они влияют только на процесс настройки, но технически никаких проблем "дотянуться" до удалённого устройства нет. Что в реализации раннего P&P было полно косяков -- это факт, но это именно косяки, а не какие-то принципиальные ограничения.
Что же до Unibus, то это чисто железная шина, без каких-либо программных ограничений (за исключением разрядности адреса и данных, понятное дело). Мастеров могло быть, в принципе, сколько угодно, хотя прерывания (точней, запросы на захват шины, в рамках которых выдавались в том числе и прерывания) мог обрабатывать только один арбитр шины (технически -- часть процессора, хотя логически -- независимая сущность). У нас, например, была СМ-1600 -- двухпроцессорная машина, где основной процессор реализовал систему команд PDP-11, а т.н. спецпроцессор -- систему команд М5000, только привилегированные были изменены. Идея там была в том, что ПДПшный проц рулит всем вводом-выводом, а спецпроцессор выполняет ОС и прикладные задачи, ранее созданные под М5000, а для ввода-вывода дёргает ПДПшный (через прерывание). Естественно, спецпроцессор тоже был мастером шины.
Мосты PCI прозрачны для обычного обмена и никакого влияния на драйверы не оказывают.
Насколько я помню, поиск устройства драйвером на шине PCI происходит на её конкретном участке размером 4 слота, потому что там адресуются именно 4 слота. Мост – это переход к следующей шине по цепочке. И далеко не всякий драйвер (включая BIOS) способен вообще работать с устройствами дальше 4 слота.
Это как разведено. Поиск -- перебором комбинаций, записываемых в соответствующий регистр чипсета, и проверкой ответа (детали, естественно, уже не помню, но глянуть при нужде можно -- спецификации имеются).
Драйверы работать со всем этим и не должны: их дело -- управлять устройствами, а не настраивать их, последним занимаются BIOS и менеджер PnP из состава ОС (и драйверы шин -- но не драйверы устройств). Вот что далеко не всё было нормально реализовано -- да, но, повторюсь, это не жёсткое ограничение шины, а недостатки или прямые ошибки конкретных реализаций.
Кстати говоря, современная PCI-e с точки зрения программиста -- та же PCI, только немного расширенная, с сохранением совместимости "снизу вверх", хотя с точки зрения электроники -- совершенно другое.
когда надо делали неплохо и на лампах, Q7 в конце 50х в среднем была в нерабочем состоянии порядка нескольких часов в год, но один процессор из 2х постоянно в горячем резерве
typedef struct {
uint32_t id;
uint32_t value;
} item_t;
uint64_t sum_values(const item_t *items, size_t n) {
uint64_t sum = 0;
size_t i = 0;
// простой цикл, который компилятор может векторизовать
for (; i + 3 < n; i += 4) {
sum += items[i].value;
sum += items[i+1].value;
sum += items[i+2].value;
sum += items[i+3].value;Ужасная у вас тут векторизация, куча кэш-промахов будет, я бы за такое увольнял как профнепригодного, тут Struct of Arrays нужно, а не AoS
Старая школа (с)
Да и циклы так никто давно уже не разворачивает, современный компилятор делает это сам, интеловский OneAPI вообще иногда чудеса автоматической оптимизации показывает, надо только в листинг на ассемблере поглядывать время от времени для контроля.
Так говорят те, кому не доводилось увольнять сотрудников.
Когда у тебя проект целиком компилируется несколько часов - как-то само собой учишься разделять его на библиотеки, которые один раз пишешь, тестируешь, собираешь - и не трогаешь потом каждый раз при доработках, пытаясь переписать под очередную теорию правильного программирования на новом языке.
Первый раз он всё равно будет долго компилироваться. Или когда глобально для проекта зависимости с мейкфайлом изменятся. А в остальном не замечал, чтобы любой make без make clean каждый раз работал часами.
Автор для красного словца этот пример привёл, имхо. Так же как и сравнение инвестигации по логам, через core dump и воспроизведение через CI - абсолютная дичь, имхо, особенно для продакшена. Через ci редко одиночную ошибку воспроизведёшь, core dump в продакшене никто не разрешит для одиночной ошибки делать, трассировать тоже, так что только логи
а правка в продакшн означала
Какой такой продакшн в 70-90-х? Не было такого слова.
реальное сокращение латентности иногда приходит от таких ручных инсайтов.
Не было тогда никакой латентности (как же задолбали меня этим новоязом). Было время выполнения, скорость выполнения, задержка.
жили и дышали циклами edit compile run debug.
Обычно был еще link после compile.
Обратите внимание на простоту и предсказуемость. Нет богомерзких зависимостей,
Да, святая простота из трех исзодников. Если взять все зависимости современного web-сервиса, напрмер, и включить в проект в виде исходников, то получится тысячи файлов и сотни тысяч строк кода. Или надо руками всё писать каждый раз заново? Или можете лучше и меньше? Так напишите, изобретите велосипед. Если выделят время, деньги и программистов.
Да, и насчёт 1420, которая годами... Может, это была какая-то военная сборка? Или повезло) У нас эти СМ-ки и их периферия ломались довольно часто.
Из моего опыта, мы знали наизусть, сколько циклов процессора занимает та или иная операция в языке. И конечно же, экономили каждый байт. Но ни то, ни другое сейчас не актуально в 99.9% проектов. А где актуально, там и сейчас знают и экономят.
Да, и насчёт 1420, которая годами... Может, это была какая-то военная сборка? Или повезло) У нас эти СМ-ки и их периферия ломались довольно часто.
Ну, я несколько СМок и ЕСок знал лично -- и чисто электронная часть везде работала (почти) надёжно, если и дохли, то вполне конкретные микросхемы, а не то одно, то другое -- что наводит на мысль о разном качестве изготовления на разных заводах. Вот периферия -- да, везде не самым сильным местом была, хотя тоже есть нюансы (скажем, древние 7,25-мегабайтные ЕС-5052 и ЕС-5056, оставшиеся "в наследство" от ЕС-1022, работали вполне себе надёжно, а их контроллеры вообще никогда не ломались, а вот новые ЕС-5080 на 200 Мбайт -- это был ужас).
Насчёт военки -- именно та, с которой мужики экспериментировали, скорей всего, именно такая и была; у нас на ВЦ одну из ЕС-1035 называли "военной", хотя "военного" там, кажется, только золото на разъёмах, сами микросхемы -- обычная 500-я серия, главным образом (хотя фиг знает, может, для военных ЕСок шли обычные же микросхемы, только проверенные качественно; другая наша ЕС-1035 была "оловянной" и постоянно сбоила из-за неконтактов -- чинилась пинками по рамам процессора).
Дохли только определенные схемы - это точно не "работала годами".
Да, могли просто собирать их серийных деталей, но прошедших спец. ОТК.
Дохли только определенные схемы - это точно не "работала годами".
А это уж смотря где эти схемы используются. Скажем, в упоминавшейся СМ-1600 постоянно дохли упоминавшиеся К170-что-то-там в синхронном последовательном интерфейсе -- но машина сохраняла полную работоспособность и без этого интерфейса. А вот чтоб у неё вышел из строя процессор, память, контроллеры дисков или лент -- такого не припоминаю вообще (как и у всех СМок, с которыми был знаком). И они реально, за исключением отдельных периферийных устройств (в данном случае -- мало кому нужного интерфейса), годами сохраняли работоспособность без необходимости ремонта.
Не было тогда никакой латентности (как же задолбали меня этим новоязом). Было время выполнения, скорость выполнения, задержка.
Ага, а еще отладка и аварийный останов (АВОСТ / ABORT / ABEND) и пакетные задания )
И посмертный дамп.
Пакетные и сейчас есть. И пакетная обработка и прочее. А эта "латентность" ничем не отличается от задержки. Или отличается?
Только новоязом. А так - ничто не ново под луной, выше написал :) всё экстенсивный рост, качественные скачки за счет абстракции/сборки из готовых модулей/примитивов да ускорение вычислений. Инженерный аппарат со времен Ляпунова, Вирта и прочих Кнутов/Аммералов/Таненбаумов тоже всё тот же
(не осуждаю, мне нравится (кроме питона с его отступами) - просто констатирую)
Экстенсивный? Уже давно произошёл переход количества в качество. Причём, раз несколько)
По мне так - с какого расстояния смотреть - и по факту качество лишь одно - "скорость". Связи, поиска, генерации мусора, решения типовых задач... т.е. сокращение трудозатрат на рутину - при неизменной скорости жизнедеятельности человека и природных процессов. Т.е. алгоритмически - экстенсивно, хотя да, это качество есть. Вопрос философский...
А для вас - какое именно качество?
питона с его отступами
жесть как бомбит от этих отступов
Нормальные такие отступы. Беленькие (или какой там у вас фон), красивенькие, ровненькие, все как на подбор.
А мне они не заходят :) Вообще, не люблю, когда язык навязывает стиль оформления. Хотя, есно, мой быдлокод (если он не на ассемблере, а на це/це++) с отступами и прочим, но иногда для улучшения читабельности оформляется довольно затейливо (скажем, длинное условие в if разбиваю на несколько строк, где тоже будут отступы).
В Python длинное условие в if тоже можно разбивать на несколько строк, причём двумя способами.
Полностью согласен- отступы нормальные, я бы даже сказал- отличные отступы! Вот только какой идиот придумал оформлять логику невидимыми символами и что в тот момент у этого товарища было в голове - этого мне непонять. Хочется простых каких-нибудь скобок - есть условие и оно в скобках, есть секция кода в условном операторе или в цикле - и она в скобках. Какого рожна туда эти отступы присунули- я непонимаю. Это вообще чьих рук дело? Гвидо? Ну ладно бы он был каким-нибудь новомодным хипстером-зумером, но он же 56ого года рождения.. Ну как так то??.. Прям вот начинаю думать, что это из-за того, что там у них трава в ходу..))
Ну ладно бы он был каким-нибудь новомодным хипстером-зумером, но он же 56ого года рождения.. Ну как так то??..
Примерно вот так: https://inference-review.com/article/the-origins-of-python
Ну, разве что как технический термин. Типа, задержка -- это вообще про любую задержку, а латентность -- это сколько времени проходит от момента выдачи адреса в блок памяти до начала получения данных из этого блока. Хотя лично я предпочитаю использовать русский язык, если говорю/пишу на русском :)
Ну не до такой же степени ужимать ресурсы, что на точках в тексте экономить.
< Вопрос к вам: есть ли у вас в команде практика создавать минимальные реплики для багов.
IMHO, без такой практики трудно воспроизводимые баги найти очень сложно. Например, что-то падает или неправильно работает раз в несколько дней.
Мы однозначно из разных миров, ведь (:
Обратите внимание на простоту и предсказуемость. Нет богомерзких зависимостей, которые появляются в логах при каждом npm install или pip install.
Для меня богомерзкая зависимость — это и сам makefile...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Менталитет старой школы: инженерные привычки программиста 70–90-х и как их применять сегодня