Re[3]: А чем бы ты хотел заниматься - Компьютерные священные войны

Здравствуйте, Denis Ivlev, Вы писали:

DI>>>Неудачное стечение обстоятельств и вызов ВФ оказывается медленней в сотни раз. При этом в С виртуальные функции при необходимости делаются легко.

Pzz>>Откуда там в сотни раз?

DI>Из архитектуры компьютера:

Это может вообще любого компьютерного телодвижения коснуться, и не специфично для виртуальных методов. Но вообще, в C++, в котором таблица виртуальных методов общая для всех экземпляров класса, у нее больше шансов оказаться в кэше, чем у указателей, размазанных по миллиону структур.

DI>Заинлайненая функция будет запрефетчена в кеш инструкций, поход только в таблицу виртуальных функций, если она не оказалась в кеше может стоить в 200 раз больше, а еще и саму функцию затем надо вызвать, а это еще один поход в память. Но даже если она и не будет заинлайнена, то это все равно сильно дешевле.

Заинланйенная фукция может запросто отжать из кэша инструкций что-нибудь другое, не менее полезное. Я к тому, что инлайн может и ускорять программу, а может наоборот.

Здравствуйте, удусекшл, Вы писали:

У>В C++ не платишь за то, что не используешь. Жаль, что до тебя, как и до вашего главного пингвина, это не доходит

Как только в проекте появляется кто-то кроме тебя, сразу начинаешь платить.

DI>DevOps — это модный базворд.

Если не заниматься пустой болтовней про то, что DevOps — это баззворд или DevOps — это идеология или набор практик или еще какая ересь, а взять и обобщить чем занимаются люди, называющиеся DevOps, то обобщение получится сделать и оно даст довольно четко определенный список задач, которые решают DevOps. По сути — это админы в команде разработчиков.

M>>По сути, DevOps — это квалифицированный админ, который работает с разработчиками

DI>Нет, то что понимают под этим — это разработчик который не говорит "я написал код, деплойте и эксплуатируйте, меня проблемы негров не волнуют", а разработчик который понимает, как его продукт будет эксплуатироваться, то есть понимает процесс сборки, деплоя, мониторинга, прочего и может в это. Соответственно, в нормальных командах каждый разработчик и есть девопс. Если разделять разработку от эксплуатации получается какашка.

Я читал и про такую трактовку термина DevOps, но не согласен с ним. Суть в том, что сисадмин, как и разработчик набирает навыки и опыт годами (это только люди, которые понятия не имеют, чем занимается админ думают, что он дневную работу может сделать на коленке за пол часа ковыряясь с носу, а потом весь день играет в танчики или контрстрайк). Поэтому такого квалифицированного человека (DevOps = admin + programmer) еще поискать придется, да и не понятно как он наработал эти навыки (если свитчер из сисадминов пришедший в разработку, то тогда понятно, а если разработчик решил двигаться не в управленцы, а заняться сисадминством, то совсем непонятно).

По сути, твоя интерпретация термина DevOps (admin + разработчик) аналогична fullstack developer, а с ними, как известно, ситуация проста — отдельный специалист (backend или frontend) и денег больше зарабатывает и в своей сфере деятельности лучше разбирается. И если проект достаточно большой, чтобы каждого загрузить работой на 100% fulltime (а таких большинство), то специализация рулит (по цене и качеству). С admin + разработчик ситуация аналогичная. Лучше в команду разработчиков взять админа, и пусть каждый специализируется на своем, программисты разрабатывают, админ занимается инфраструктурой. Тут есть чисто административная заморочка, если админов/девопсов выделить в отдельный отдел, то их начальник захочет порулить и начнет себе цену набивать в результате проще взять админа в отдел к разработчикам, чем договориться с начальником их отдела. Если еще дать возможность такому админу принимать участие в принятии решений по архитектуре (вместо "у нас тут тормозит — давай разбирайся"), то вообще все станет идеально. Т.е. админ у разработчиков должен быть не задротом, на которого сваливают все подряд и чморят для мотивации, а полноценным членом команды, который участвует в разработке (по своей специализации — построению инфраструктуры, на которой работает проект).

M>>(только настраивает он кормчего "Kubernates", а не индейца "Apache").

DI>Это вообще разные вещи, кубер нужен для оркестрирования, а апач веб сервер, но в серьезном проде я апача давно не видел.

Ты, похоже, вообще не понял, о чем я писал. У админа и девопса различаются только названия сервисов, которые он обслуживает, а остальной опыт на 90% одинаковый. Нет большой разницы в установке и настройке апача и кубернейтса. Разница как писать на C# или Java при условии, что ты пишешь backend для одной и той же прикладной сферы.

M>>Но по сути, DevOps — это админ, а не PM или CTO (при этом девопсу деньги нормальные платят за настройку сервака, а сисадмин — подай, принеси, настрой тот же сервак за 1/2 зарплаты разработчика).

DI>Платят не за настройку сервера, а чтобы продукт легко деплоился и эксплуатировался, что за собой тянет существенный пласт знаний и инструментов.

Или наладить взаимодействие команды разработчиков со своим девопсом, который лучше любого программиста сможет спроектировать инфраструктуру для проекта. И тогда не нужно разработчику быть админом, а админу разработчиком. IMHO, версия, что DevOps = admin+разработчик в одном флаконе имеет шансы на существование, но вариант когда это два специалиста, которые работают ради одной цели — создание и поддержка проекта, и дешевле и надежнее.

Если в проекте возникают трудности с деплоем и эксплуатацией, то тут дело либо в отсутствии понимания конечной цели у разработчиков и админов, либо в отсутствии их взаимодействия. Либо разработчики оборзели до "у меня на localhost все работает, а дальше мне насрать" и админ тупо не может это деплоить и эксплуатировать, либо админы увлеклись "модными" технологиями и забыли, на чем написан проект, либо скорее каждый думает, что он бох и все вокруг его хотелок должны вертеться. Вариант, когда приходит кто-то очень важный, кто решил, что он бох в программировании и администрировании и принимает единолично решение, как оно должно работать, в целом лучше, чем полный бардак. Но в реальности, скорее всего он не особо хорошо разбирается ни в разработке, ни в администрировании (по сравнению с более узкими специалистами) и понапринимает таких решений, что эти самые специалисты начнут искать другого работодателя. Вариант дать каждому делать свою работу и наладить их взаимодействие видится мне более эффективным (админу заниматься инфраструктурой, причем не только поддержкой, но и архитектурой приложения, чтобы его было удобно деплоить, мониторить и находить причины падений, а разработчику разработкой и получением метрик с production, о реальных характеристиках работы приложения).

DI>>Нет, то что понимают под этим — это разработчик который не говорит "я написал код, деплойте и эксплуатируйте, меня проблемы негров не волнуют", а разработчик который понимает, как его продукт будет эксплуатироваться, то есть понимает процесс сборки, деплоя, мониторинга, прочего и может в это. Соответственно, в нормальных командах каждый разработчик и есть девопс. Если разделять разработку от эксплуатации получается какашка.

S>Ну, или админ, который не говорит "ваше приложение говно — я всё настроил, как надо, а оно работает плохо, и меня не парит, почему".

IMHO, если в команде бардак, то либо исполнители не хотят, не умеют, не знают, что они должны делать, либо между ними не налажено взаимодействие. Если кто-то из руководства приходит и вместо налаживания взаимодействия в команде начинает принимать все решения сам, то чуваку явно невтерпеж порулить. И пофиг, что

бардака хоть и станет меньше, но он не исчезнет,
как специалист в каждой конкретной области он хуже, чем узкий специалист, поэтому его решения будут "так себе", да и обдумать их он тупо не успеет толком,
решения, принятые самостоятельно, любой исполнитель будет реализовывать с гораздо большим энтузиазмом,
хреново продуманные решения квалифицированного исполнителя демотивируют.

Такая модель работает там, где может быть один технарь принимать среднего уровня решения и реализовывать их будут ниже среднего исполнители. Технарь будет чувствовать себя богом. Без него все встанет.

Альтернативный вариант — объяснить исполнителям конечную цель всей команды, зону ответственности каждого и с кем и как взаимодействовать, если задача выходит за пределы твоей зоны ответственности. Рулевой влезает только когда что-то пошло не так. В результате думать будет сильно больше одной головы, каждый замотивирован рулить с своей зоне ответственности, у каждого квалификация сильно выше, чем у "избранного". Минусы — тимлид не будет чувствовать себя богом, ибо порулить почти не получится — многие задачи решатся без его участия.

S>Привыкайте, камрады — грядёт эпоха смежных специальностей.

Насколько это грядет не знаю, возможно в сферах, где один "бох" сможет рулить смердами ниже среднего и большой текучкой.

S>>>Тем более, что Си c классами, С++ без всех тех костылей и подпорок, вроде виртуальных функций, такого же наследования, RAII, шаблонов, плясок с auto, и всего прочего мусора, очень даже нормальный ЯП.

S>>Можно предположить, что в прочий мусор вы отнесли ссылки, перегрузки операторов, перегрузки функций, аргументы по умолчанию, исключения, enum class, nodiscard и deprecated, пространства имен...

S>> Ссылки

S>Это такая хрень, которую создавали чтоб облегчить и упростить разработку, чтоб разрабы не делали ошибок при работе с указателям, чтоб не сегфолтились. Но получили, как и всегда в C++, в разы более сложные и в разы более неочевидные проблемы, по сравнению с типичными проблемами работы с указателями. А потом, как и водится в C++, нагородиили кучу костылей и подпорок разной степени уродливости, чтоб эти проблемы нивелировать, и объявили эту кучу костылей невпендюренным развитием ЯП. Всё как и водится в C++.

S>По остальным пунктам примерно такие же выводы.

Отнести C++ РАЙ к мусору и упорствовать в этом...

Мальчик, иди на LOR, там тебя покормят. Тут более взрослые дяди (в плане мировоззрения) общаются.

Ну, а что касается твоей тирады про C++. Так C++ — это практичный инструмент для решения реальных задач. Все, что в нем есть, добавлено из потребностей в решении какой-то реальной задачи. IMHO, на хайпе добавили только модули, которые ничего нового не дают и никому лучше не делают, но их очень многие очень хотели и потому их добавили. Их настолько хотели, что сначала один чувак пилил реализацию, затем другой несовместимую, затем они совмещали их вместе и в результате получили заголовочные файлы, только сделанные чуть аккуратнее и на уровне языка, а не текстового препроцессора (и, кстати, реализации модулей из стандарта до сих пор нет ни в одном компиляторе, насколько я знаю, только в виде отдельных веток в VCS с не факт, что полной функциональностью).

По мне, так надо было делать по-другому. Сделать минимальную реализацию функциональности, которую однозначно хочется увидеть в модулях. Сделать ее несовместимой ни с C ни с текущим C++, но позаботиться об инструменте, который из такого модуля (и, возможно, заголовочного файла, в котором то, что нельзя запихать в модуль) сгенерирует заголовочный файл для более ранних компиляторов (как JetBrains сделали интеграцию Kotlin Native <-> Swift или Kotlin Native <-> C с генераторами библиотек Swift из котлина и библиотек котлина из Swift). А дальше запихивать в модули все, что потребуется (именно потребуется на практике по результатам использования минимальной функциональности модулей), постепенно избавляясь от заголовочных файлов, и заботится только о том, чтобы генератор заголовочных файлов продолжал работать. Таким образом и обратная совместимость не пострадает (из проекта с модулем можно сгенерировать заголовочный файл для более раннего стандарта, поэтому не будет дублирования в виде поддержки модуля и хедера) и архитектура и функциональность модулей была бы более продуманной, потому что развивалась постепенно.

Так что IMHO, C++ практичный язык, все что в нем есть кому-то для чего-то нужно и если ты этого не понимаешь, то либо ты зеленый студент, которому просто не хватает опыта это понять. Либо, если уже давно не студент, значит — упертый фанатик, который живет в альтернативной реальности и неспособен воспринимать реальную реальность. При этом C++ не идеален, он подходит не для всех задач и, возможно, не подходит для твоих. Но тогда дело не в языке, а в том, что это неподходящий инструмент для тебя и твоих задач — просто, возьми более подходящий. Ну, а если нет ничего лучше, то рассказами какое дерьмо этот ваш C++ ты ничего хорошего для себя не добьешься.

Здравствуйте, Pzz, Вы писали:

DI>>Из архитектуры компьютера:

Pzz>Это может вообще любого компьютерного телодвижения коснуться, и не специфично для виртуальных методов.

Лол, шта? Как раз специфичен в силу самого механизма вф, на пальцах это было продемонстрировано.

Pzz>Но вообще, в C++, в котором таблица виртуальных методов общая для всех экземпляров класса,

А что мешает в наколеночной реализации на С иметь одну таблицу на все экземпляры?

Pzz>у нее больше шансов оказаться в кэше

Почему?

Pzz>чем у указателей, размазанных по миллиону структур.

Так ведь в реализации ВФ С++ как раз и есть указатели размазанные по структурам, они ведут в таблицу ВФ. В наколеночной реализации это можно как раз подтюнить держа в структурах не указатель, а саму таблицу, таким образом избежав одного похода по памяти.

Pzz>Заинланйенная фукция может запросто отжать из кэша инструкций что-нибудь другое, не менее полезное.

А может и не отжать.

Pzz>Я к тому, что инлайн может и ускорять программу, а может наоборот.

Может, если человек форсинлайнит не понимая, что делает. Но я не понял, ты сейчас будешь доказывать, что инлайнниг не оптимизация, а пессимизация?

Здравствуйте, Denis Ivlev, Вы писали:

DI>1. В каждом объекте появляется указатель на таблицу виртуальных функций, выросший размер объекта приводит, например, к тому, что твой объект перестает помещаться в кеш линию, а это значит, что в память надо ходить чаще
Как это мешает работать в кернеле?

DI>3. Чтение таблицы ВФ по этому указателю тоже может означать поход по памяти и плюс к этому вытеснение из кеша данных, которые могут скоро понадобится
Как это мешает работать в кернеле?

DI>4. И еще один поход по памяти собственно в функцию
Как это мешает работать в кернеле?

DI>Неудачное стечение обстоятельств и вызов ВФ оказывается медленней в сотни раз.
Только для тех, кто не имеет понятия что творит.

DI>При этом в С виртуальные функции при необходимости делаются легко.
Врукопашную а в итоге точно так же.

DI>Вот теперь, когда ты знаешь про стоимость этой абстракции, скажи будут в ядре ОС использовать ВФ?
Почему нет?