Рассмотрено обстоятельно :) Я, однако, для себя обхожусь куда более простым объяснением действительно весьма частого некорректного понимания утверждения Д. Кнута. Проблема, как мне видится, в том, что подавляющее большинство разбрасывающихся фразой “Преждевременная оптимизация корень всех зол”, во-первых, никогда не читали всей (довольно объёмной) статьи Кнута (и тут совершенно уместно сказать о том, что “фраза вырвана из контекста”); во-вторых, и это прямо следует из во-первых, не знают, какое слово использовал Кнут, переведённое (скажем прямо — кривовато переведённое) на русский, как “преждевременное”. Его воспринимают литерально и в самом простом и прямолинейном смысле “раньше времени, рано”, как если бы Кнут использовал слово “early”. Но Кнут-то написал “premature”, которое в англо-русских словарях хоть и имеет среди прочих и перевод “преждевременный”, но в контексте статьи семантика у него всё же иная. Я бы перевёл как “непродуманная, поспешная”, что Кнут и подтверждает хотя бы банальным “Если у вас нет результатов профилирования, то оптимизировать ещё буквально нечего” (это не перевод, а моя вольная интерпретация :) Именно о такой “преждевременной” оптимизации речь.
Рискну предположить на грани уверенности, что ты никогда не имел дела с системами реального времени. Вот прям жесточайшего реального времени. Говоря проще (для моего случая) — с разработкой боевых алгоритмов систем вооружений. Где читаемость твоего кода — на предпоследнем месте.
А вообще ты то ли не увидел, то ли не понял самых первых слов моего комментария. Позволю себе повторить специально для тебя: “Вне контекста применения.” То есть, в том самом вакууме, в котором так любят объезжать сферических коней многочисленные далёкие от практики теоретики...
Вне контекста применения разговоры об асимптотической сложности и прочих O — болтовня теоретиков и слушателей/выпускников модных курсов. Я достаточно навалял оплеух таким, которые для трёх значений вызывали библиотечную sort(). Уместно будет вспомнить и рассказ чувака, объяснявшего почему в программе (той, что на борту ракеты) управления ракетой ПВО не освобождается память: дешевле удвоить установленную физическую память, чем переписывать уже давно “вылизанный” код — до того момента, когда память могла бы “кончится”, ракета никогда не долетит, она либо сработает по цели, либо самоуничтожится.
На фотографии, названной «Деннис Ритчи (слева) позже сказал...» Деннис Ритчи хоть и находится по левую руку от Кена Томпсона, но на фотографии он всё-таки справа.
До того как начать что-то использовать в меру, необходимо усвоить ещё более важные принципы — не охотиться с мортирой на воробьев, не забивать микроскопом гвозди, не использовать что бы то ни было только потому, что “ну, раз оно есть, то надо заюзать” или “а чтоб было!”, и т.д. Убеждён, если бы все так поступали, микросервисных поделок было бы на порядки меньше. K8s для какой-нибудь тудушки на пару сотен юзеров — это даже не смешно, это микросервис головного мозга в терминальной стадии.
Кстати, из опыта того же StackOverflow -- там, где нагрузка может привести к падению процесса (справедливости ради — это везде :), в первую очередь надлежит не об отдельном сервисе задумываться, а убедиться в обеспеченности этого процесса ресурсами. Их главная инженерка прямо отметила, что поставить на машину с PostgreSQL терабайт RAM оказалось решением куда более простым и эффективным, чем вся так микросервисная фигня, которая частенько взбредает в головах “молодых да буйных”.
Попасть в ядрену боеголовку -- весьма нетривиальная задача по причине скорости полета этой самой боеголовки. На входе в атмосферу там 20-25Mach. Решили, что проще шарахнуть несколько мегатонн, чтобы снести всё в радиусе нескольких километров.
На земле “ничего не будет”, Симоньян же рассказывала :)
Немножко корректировок/уточнений из того, что сам знаю, поскольку сам непосредственно работал как раз на том самом объекте, что на картинке про “Полигон Сары-Шаган” (это объект 51, 38-я площадка). Прежде всего, “компьютеризированная система ПРО” там не просто испытывалась, а буквально создавалась — инженерный персонал причастных “почтовых ящиков” из России, Украины, Беларуси, Казахстана нередко проводил куда больше времени в продолжительных командировках (с переездом всей семьи) на этом самом полигоне, чем в стенах своих НИИ, куда ездили раз в полгода на перекомандировку (КЗоТ запрещал командировки продолжительнее 180 дней).
А-350Ж по сути так и не “случилась”. В отличие от В-1000, которой, собственно, и был осуществлён впервые успешный перехват боеголовки МБР. В 1968.
А-35 вокруг Москвы была практически бутафорской. Всегда.
ЭВМ в составе комплекса называлась 5Э92б, а не 5Э926. А по сути это была БЭСМ в военном исполнении. Кстати, прямо с центрального пульта 5Э92б “Иртыша” (это РЛС/ФАР, самый большой “шарик” на фотографии, слева) на “Аргуни” в 1985-м говорили по “громкой” с Джанибековым, стыкуя его с мертвеньким Салютом-7.
Кстати, у 5Э92б была и более продвинутая “младшая сестра” 5Э51. Продвинутость выражалась прежде всего в наличии плавающей запятой.
Во второй половине 80-х стало ясно, что и эти ЭВМ слишком “динозавры” для актуального состояния дел. В НИИДАР “по заданию партии” разработали “спец-вычислитель” Д-89ОА. Тоже монстр многостоечный, гарвардской архитектуры, с канальным В/В (использовалась периферия ЕС). На 133 ТТЛ элементной базе. Работающей на верхних порогах допустимых частот. Как закономерное следствие — на двух рядом стоящих машинах одна и та же программа могла показать разные результаты. Понижение частоты выравнивало картину :) Всего было выпущено 14 машин, 12 отправились на “объект”, две уехали в Гомель, в Конструкторское Бюро Системного Программирования.
В первой половине 90-х мы (говорю “мы”, поскольку это было при моём непосредственном участии) таки нашли способ управления конвейерами отправляемых с ФАР “Аргуни” и получаемых отражёнными от “целей” зондов, а потом и способ отличать ядерные боеголовки от ложных на раннем этапе — в верхних слоях атмосферы.
Ну, а потом “Перестройка” с окончательным развалом “совка” закончили всё это дело.
Заявить “Agile умер” мог только человек, который Agile никогда не видел живьём, и имел в виду то, что видел, называя это почему-то Agile.
Просто у меня Agile “случился” ещё в конце 80-х, хотя такого названия ещё не имел. Зато я с тех пор хорошо представляю, как оно выглядит, и никакими скрамами с дейликами меня не обманешь — они к Agile не имеют никакого отношения. Могут быть, а могут и не быть, но их отсутствие не делает Agile-команду какой-то “неправильной”. А вот наличие оных, да ещё и под иерархическим руководством множественных менеджеров, мастеров и экспертов всех мастей — очень даже может.
Интересные у вас сравнения, однако. Как в On Premise, так мастер-серверам подайте аж “не менее 512GB RAM”, а как “приходите в наше облако, сэкономите!”, так ему уже и 64GB хватает.
Эксплуатация предполагаемой инфраструктуры в полтора десятка обычных серийных серверов — это работа для трёх лежачих администраторов, жалование которых по масштабам никогда не приблизится к “операционным расходам” на ваше чудесатое “облако”.
Ключевое заблуждение с первого же слова статьи. И повторяется далее неоднократно.
Agile невозможно внедрить. Оно может только возникнуть. Относитесь к нему примерно так же, как к счастью — оно может свалиться с неба, вырваться из-под земли, материализоваться из воздуха, но насадить его невозможно никакими методами.
В одной очень близкой мне типографии за долгие годы работы перепробовали кучу всего. С выхлопом от “Вы вообще о работе типографии чего-нибудь знаете, если написали такое убожество?” до “Да идите вы лесом, если необходимая для нашего полиграфического производства функция требует три месяца вашей работы и полмиллиона наших денег!”
Итог — в полтора лица с нуля написанная своя система (1С, всё ещё 7-ка). Любая блажь пользователей — от гендира/коммерса/сэйла до операторов ламинатора и резки — решается за несколько часов. Дней, если блажь масштабная.
Это ваше “впервые слышу” лишь выдаёт ваш довольно скромный опыт. Думайте логично и хотя бы неможко рыночно — в своё время владелец СКС потратил на неё от нескольких сотен тысяч до миллионов рублей, с чего бы он вдруг занимался благотворительностью и дарил её новым “жильцам”? По-моему, его желание получить некоторую, с учётом амортизации, компенсацию своих затрат вполне объяснимо и нормально.
С учётом того, что из двух тредов zstd, создаваемых “по умолчанию”, один занимается I/O, а другой [де]компрессией, то исполнение обоих на одном ядре — нормальное явление для системы, у которой average load не стремится к нулю.
ДВК — это целая линейка довольно разных компьютеров, а LSI-11 — конкретный 4-чиповый микропроцессор. Маловато простора для аналогий, система команд — далеко не единственный критерий.
Рассмотрено обстоятельно :) Я, однако, для себя обхожусь куда более простым объяснением действительно весьма частого некорректного понимания утверждения Д. Кнута. Проблема, как мне видится, в том, что подавляющее большинство разбрасывающихся фразой “Преждевременная оптимизация корень всех зол”, во-первых, никогда не читали всей (довольно объёмной) статьи Кнута (и тут совершенно уместно сказать о том, что “фраза вырвана из контекста”); во-вторых, и это прямо следует из во-первых, не знают, какое слово использовал Кнут, переведённое (скажем прямо — кривовато переведённое) на русский, как “преждевременное”. Его воспринимают литерально и в самом простом и прямолинейном смысле “раньше времени, рано”, как если бы Кнут использовал слово “early”. Но Кнут-то написал “premature”, которое в англо-русских словарях хоть и имеет среди прочих и перевод “преждевременный”, но в контексте статьи семантика у него всё же иная. Я бы перевёл как “непродуманная, поспешная”, что Кнут и подтверждает хотя бы банальным “Если у вас нет результатов профилирования, то оптимизировать ещё буквально нечего” (это не перевод, а моя вольная интерпретация :) Именно о такой “преждевременной” оптимизации речь.
Рискну предположить на грани уверенности, что ты никогда не имел дела с системами реального времени. Вот прям жесточайшего реального времени. Говоря проще (для моего случая) — с разработкой боевых алгоритмов систем вооружений. Где читаемость твоего кода — на предпоследнем месте.
А вообще ты то ли не увидел, то ли не понял самых первых слов моего комментария. Позволю себе повторить специально для тебя: “Вне контекста применения.” То есть, в том самом вакууме, в котором так любят объезжать сферических коней многочисленные далёкие от практики теоретики...
Что раньше, что сейчас чёткое, однозначное, исключающее трактовки, не ставящее вопросы, и вообще грамотное ТЗ — одно на тысячи.
Вне контекста применения разговоры об асимптотической сложности и прочих O — болтовня теоретиков и слушателей/выпускников модных курсов. Я достаточно навалял оплеух таким, которые для трёх значений вызывали библиотечную
sort(). Уместно будет вспомнить и рассказ чувака, объяснявшего почему в программе (той, что на борту ракеты) управления ракетой ПВО не освобождается память: дешевле удвоить установленную физическую память, чем переписывать уже давно “вылизанный” код — до того момента, когда память могла бы “кончится”, ракета никогда не долетит, она либо сработает по цели, либо самоуничтожится.На фотографии, названной «Деннис Ритчи (слева) позже сказал...» Деннис Ритчи хоть и находится по левую руку от Кена Томпсона, но на фотографии он всё-таки справа.
Тебе, похоже, не надо в ИТ — ты чертовски невнимателен. Практически прямая ссылка есть в подписи ко второй картинке (Этап №1).
До того как начать что-то использовать в меру, необходимо усвоить ещё более важные принципы — не охотиться с мортирой на воробьев, не забивать микроскопом гвозди, не использовать что бы то ни было только потому, что “ну, раз оно есть, то надо заюзать” или “а чтоб было!”, и т.д. Убеждён, если бы все так поступали, микросервисных поделок было бы на порядки меньше. K8s для какой-нибудь тудушки на пару сотен юзеров — это даже не смешно, это микросервис головного мозга в терминальной стадии.
Кстати, из опыта того же StackOverflow -- там, где нагрузка может привести к падению процесса (справедливости ради — это везде :), в первую очередь надлежит не об отдельном сервисе задумываться, а убедиться в обеспеченности этого процесса ресурсами. Их главная инженерка прямо отметила, что поставить на машину с PostgreSQL терабайт RAM оказалось решением куда более простым и эффективным, чем вся так микросервисная фигня, которая частенько взбредает в головах “молодых да буйных”.
Попасть в ядрену боеголовку -- весьма нетривиальная задача по причине скорости полета этой самой боеголовки. На входе в атмосферу там 20-25Mach. Решили, что проще шарахнуть несколько мегатонн, чтобы снести всё в радиусе нескольких километров.
На земле “ничего не будет”, Симоньян же рассказывала :)
Если бы создатели StackOverflow считали микросервисы “правильным путем”, у нас бы не было StackOverflow. Как один из примеров, что у всех на виду.
Немножко корректировок/уточнений из того, что сам знаю, поскольку сам непосредственно работал как раз на том самом объекте, что на картинке про “Полигон Сары-Шаган” (это объект 51, 38-я площадка). Прежде всего, “компьютеризированная система ПРО” там не просто испытывалась, а буквально создавалась — инженерный персонал причастных “почтовых ящиков” из России, Украины, Беларуси, Казахстана нередко проводил куда больше времени в продолжительных командировках (с переездом всей семьи) на этом самом полигоне, чем в стенах своих НИИ, куда ездили раз в полгода на перекомандировку (КЗоТ запрещал командировки продолжительнее 180 дней).
А-350Ж по сути так и не “случилась”. В отличие от В-1000, которой, собственно, и был осуществлён впервые успешный перехват боеголовки МБР. В 1968.
А-35 вокруг Москвы была практически бутафорской. Всегда.
ЭВМ в составе комплекса называлась 5Э92б, а не 5Э926. А по сути это была БЭСМ в военном исполнении. Кстати, прямо с центрального пульта 5Э92б “Иртыша” (это РЛС/ФАР, самый большой “шарик” на фотографии, слева) на “Аргуни” в 1985-м говорили по “громкой” с Джанибековым, стыкуя его с мертвеньким Салютом-7.
Кстати, у 5Э92б была и более продвинутая “младшая сестра” 5Э51. Продвинутость выражалась прежде всего в наличии плавающей запятой.
Во второй половине 80-х стало ясно, что и эти ЭВМ слишком “динозавры” для актуального состояния дел. В НИИДАР “по заданию партии” разработали “спец-вычислитель” Д-89ОА. Тоже монстр многостоечный, гарвардской архитектуры, с канальным В/В (использовалась периферия ЕС). На 133 ТТЛ элементной базе. Работающей на верхних порогах допустимых частот. Как закономерное следствие — на двух рядом стоящих машинах одна и та же программа могла показать разные результаты. Понижение частоты выравнивало картину :) Всего было выпущено 14 машин, 12 отправились на “объект”, две уехали в Гомель, в Конструкторское Бюро Системного Программирования.
В первой половине 90-х мы (говорю “мы”, поскольку это было при моём непосредственном участии) таки нашли способ управления конвейерами отправляемых с ФАР “Аргуни” и получаемых отражёнными от “целей” зондов, а потом и способ отличать ядерные боеголовки от ложных на раннем этапе — в верхних слоях атмосферы.
Ну, а потом “Перестройка” с окончательным развалом “совка” закончили всё это дело.
Уже 7 лет картинке, но что-то список всё в том же состоянии...
Может, я чего-то не понимаю в актуальной реальности, но:
каким образом процессорный сокет оказался чипсетом?
Заявить “Agile умер” мог только человек, который Agile никогда не видел живьём, и имел в виду то, что видел, называя это почему-то Agile.
Просто у меня Agile “случился” ещё в конце 80-х, хотя такого названия ещё не имел. Зато я с тех пор хорошо представляю, как оно выглядит, и никакими скрамами с дейликами меня не обманешь — они к Agile не имеют никакого отношения. Могут быть, а могут и не быть, но их отсутствие не делает Agile-команду какой-то “неправильной”. А вот наличие оных, да ещё и под иерархическим руководством множественных менеджеров, мастеров и экспертов всех мастей — очень даже может.
Интересные у вас сравнения, однако. Как в On Premise, так мастер-серверам подайте аж “не менее 512GB RAM”, а как “приходите в наше облако, сэкономите!”, так ему уже и 64GB хватает.
Эксплуатация предполагаемой инфраструктуры в полтора десятка обычных серийных серверов — это работа для трёх лежачих администраторов, жалование которых по масштабам никогда не приблизится к “операционным расходам” на ваше чудесатое “облако”.
Ключевое заблуждение с первого же слова статьи. И повторяется далее неоднократно.
Agile невозможно внедрить. Оно может только возникнуть. Относитесь к нему примерно так же, как к счастью — оно может свалиться с неба, вырваться из-под земли, материализоваться из воздуха, но насадить его невозможно никакими методами.
В одной очень близкой мне типографии за долгие годы работы перепробовали кучу всего. С выхлопом от “Вы вообще о работе типографии чего-нибудь знаете, если написали такое убожество?” до “Да идите вы лесом, если необходимая для нашего полиграфического производства функция требует три месяца вашей работы и полмиллиона наших денег!”
Итог — в полтора лица с нуля написанная своя система (1С, всё ещё 7-ка). Любая блажь пользователей — от гендира/коммерса/сэйла до операторов ламинатора и резки — решается за несколько часов. Дней, если блажь масштабная.
Это ваше “впервые слышу” лишь выдаёт ваш довольно скромный опыт. Думайте логично и хотя бы неможко рыночно — в своё время владелец СКС потратил на неё от нескольких сотен тысяч до миллионов рублей, с чего бы он вдруг занимался благотворительностью и дарил её новым “жильцам”? По-моему, его желание получить некоторую, с учётом амортизации, компенсацию своих затрат вполне объяснимо и нормально.
Не в туда ответил, прошу прощения :)
Текст перенесён.
С учётом того, что из двух тредов zstd, создаваемых “по умолчанию”, один занимается I/O, а другой [де]компрессией, то исполнение обоих на одном ядре — нормальное явление для системы, у которой average load не стремится к нулю.
ДВК — это целая линейка довольно разных компьютеров, а LSI-11 — конкретный 4-чиповый микропроцессор. Маловато простора для аналогий, система команд — далеко не единственный критерий.