Лучше ответить на вопрос, переживают ли клиенты выход из строя вашего цода. Всяко бывает -- пожары, землетрясения, наводнения, ракеты.
Все критичные внутренние сервисы Яндекса переживут утрату одного ДЦ. И большинство клиентов Я.Облака, которые не поскупились на зональную репликацию, тоже переживут.
Обеспечивать высокую доступность в наши дни принято за счёт зонального резервирования в первую очередь, и только во вторую за счёт надёжности отдельной зоны.
Размещение на хостинге без нашего зонда и рубильника опасно тем, что хостинг может внезапно отказать вам в услугах -- либо по своему хотению, либо из-за того, что мы его заблочим целиком за проделки отдельных клиентов. И чтобы избежать риска того, что пропадёт доступ к вашим сервисам, мы отключим доступ к вашим сервисам.
Я же поясняю, что эта разница редко когда важна, покуда редко кто будет писать такой нагруженный код, который использовался в этих бенчмарках (которые я, правда, даже не видел).
Покуда многие нагруженные части логики можно написать так, что разница исчезнет. Можно пользоваться удобством динамической типизации там, где производительность не особо важна (в моей практике это подавляющее большинство кода), и перекладывать вычисления в эффективные внешние модули там, где нужна высокая производительность. Притом, этими модулями, как правило, удобно пользоваться. Получается сочетание достоинств двух подходов
в данном случае я подразумеваю не конкретную библиотеку, а blas-интерфейс к векторным инструкциям процессора, который реализует несколько разных библиотек вроде mkl. хотя фортран в Python вполне встречается. взять хотябы популярную зависимость scipy -- там >17% кода на фортране, который транслируется в C с помощью f2c, компилируется и вызывается
Т е сложение двух переменных не есть команда CPU, а есть функция, в которой читаются значения переменных, при этом динамически определяется их тип и потом вызывается опять же функция для исполнения операции сложения.
вот я и говорю -- нет понимания, что такое numpy.
это не pure python библиотека. в numpy статическая типизация. и массивы со значениями, а не указателями на структуры объектов. и все операции с numpy типами никакую динамическую типизацию содержимого не проходят. только однократную самих numpy коллекций на стыке взаимодействия с python. 100 значений в массиве или 1000000 -- не важно. python структура данных объекта в памяти будет только одна -- самого массива, не его элементов
да и вычитать данные из внешнего источника можно сразу в numpy-массивы, мимо python списков, и выгрузить наружу.
и ведь это только начало бесчисленной горы трюков оптимизации в экосистеме python, на которой пострен примерно весь существующий ML. включая всё, что делает, к примеру, OpenAI. "у каждого свой python"
В скриптовых языках применяется динамическая типизация
Боюсь, тут просто нет понимания, что такое numpy и pytorch и как они применяются. Рекомендую вникнуть глубже, разобраться, много ли выходит динамической типизации и характерных для Python структур данных в памяти при их использовании.
Могу лишь пример из практики привести: был у меня в старину процесс, который на mapreduce кластере на сотнях жирных нод считал всякую векторную арифметику на десятках TiB данных. Считал через numpy + blas.
В какой-то момент, я всё-таки решил проверить оптимальность такой конфигурации. Переписал на голом C (+blas) особо нагруженную часть. Ускорение по cpu time оказалось в пределах 15%. Выбросил этот C кусок и больше не вспоминал
На каком примере? Обучения или инференса нейросетей, для чего существует pyTorch? Учитывая то, что python там -- просто обвязка и клей между компонентами, а вычисления неявно выносятся в numpy, blas, cuda у меня есть ряд объективных сомнений, что получится обогнать на сложном примере работы с векторами и матрицами.
Он прав в том смысле, что и в этом посте и в телеграме действительно есть мутные определения, которые вызываеют вопросы.
И цитату про он привёл характерную, про то, что "горутины-то не то, что потоки, они-то живут внутри одного адресного пространства". Это действительно наводит на мысли о недопонимании.
Цитаты же
«Процессы — это, по сути, выполняющиеся программы. Это всё, что о них пока необходимо знать.»
"чем процесс отличается от треда. В таком случае, можете добавить, что процессы друг от друга изолированы, т.е. не имеют доступ к памяти друг друга. Более умным языком - каждый процесс работает в своём собственном виртуальном адресном пространстве, которое изолируется на уровне ОС."
Тоже меня лично смущают. из них можно сделать вывод, что процессы и потоки -- это объекты схожей природы и можно одно заменять другим, что не так.
Поток -- всегда дочерняя сущность одного и только одного процесса. В любом процессе всегда есть хотя бы один поток.
Процесс -- это про виртуальное адресное пространство, метаинфу вроде переменных среды и взаимодействие с операционной системой в плане доступов.
Поток -- это про значения набора регистров (это и есть тот самый контекст) и про планировщик.
Поэтому решили потратить время всех других кандидатов
Да, решил. Я продолжаю считать, что это было верное решение. Мы на рынке. Если кандидатов много, а вакансий мало, я могу и буду пользоваться этим обстоятельством.
У меня нет задачи ублажать кандидатов. У меня есть задача закрыть вакансию с заданным качеством и минимальными трудозатратами. Я не вижу доводов, которые бы показали, что я поступил нерационально в данной ситуации.
наверняка так же меняете работу раз в сколько-то лет
Да, и за свою карьеру делал несколько тестовых заданий. Среди них попадались очень достойные и интересные. Дважды даже неделю тратил, но обретал много ценных знаний в процессе и оставался доволен.
И, очевидно, что места были привлекательные и даже на куда более кандидато-центричном рынке, чем мы имеем сегодня, спроса хватало.
Однажды предложили небольшое, но бесмысленнное и нерелевантное -- вот тогда я прямо спрашивал у нанимателей, какие сигналы и как они планируют вытянуть из решения, в чём смысл? Не получив вразумтительного ответа, я был разочарован. Тогда я предложил им обсудить подходы в привлечении сотрудников и рассказал им подробно, как это делают их конкуренты. Надеюсь, они сделали какие-то выводы и продолжают это дело более осмысленно.
из-за подобной сломанной системы найма вы, в конце концов, и получаете нерелевантные отклики, где люди либо откликаются с навыками, которые совпадают на 10%, либо подделывают резюме под вашу вакансию
Тут чтобы пояснить суть, надо влезать глубоко в контекст, что выходит за рамки обсуждения. Но вкратце так: есть некоторая продуктовая экосистема. В ней 95% исполнителей на рынке делают продукт типа 1, но заодно могут указать в резюме мимоходом куда более редкий продукт типа 2, опыт с которым мне и нужен. И хотя экосистема общая, специфика продуктов 1 и 2 сильно отличается. И знаний клепателей продукта 1 фундаментально не хватает на продукт 2.
Когда эта особенность стала мне понятна по результатам нескольких неудачных собеседований, я стал просить сделать более-менее hello world с минимальной релевантной для моей задачи модифиацией продукта 2, что отсекло множество нерелевантных кандидатов.
В общем, на другую вакансию, где такой специфики нет, я собеседовал людей совершенно иначе. Тестовых заданий не было и не планировалось
Всё-таки этой книге уже прилично лет. Да и описываются там не передовики бигтеха, а второго эшелона IT команда в производственной компании. То, что там показывается как невероятное чудо "ничось, я закомитил, тесты сами прошли и оно само задеплоилось", "мы научились в agile доску (ака канбан) и приоритеты задач" уже давно является минимальным гигиеническим уровнем.
Но я согласен, что автор поста, судя по всему, не понял суть этой книги.
Phoenix Project -- это адаптация "The goal" Голдрата в области управления IT-инфраструктурой. А "The goal" -- это просто попытка на конкретном примере показать идеи и подходы бережливого производства, также известного как Toyota production system.
И смысл там не в том, сколько бывает "вредных" и некомпетентных сотрудников, а в том, какие принципы мышления и техники организации работы применяются для постоянного улучшения процессов.
Это инструмент. Который можно эффективно применять в подходящих условиях.
И первый десяток людей на заданную позицию я собеседовал без него. Однако, поняв, что все кандидаты вообще не шарят, хоть и расписали целевой опыт в резюме, я решил не тратить зря своё время дальше, благо размер входящего потока позволял его фильтровать любыми способами.
В итоге я нашёл нужного человека, который без проблем сделал. И уже больше года со мной успешно работает.
Так что я этот инструмент и дальше буду применять, где нужно.
К слову, у меня нет претензии, что тестовое задание делается с помощью любых привычных инструментов, включая LLM. В этом и смысл тестового задания -- максимально приближенная к реальной практике деятельность.
И подбирал я его так, чтобы:
1) для целевого кандидата это была тривиальная задача на пару часов максимум.
2) в нём можно было продемонстрировать ряд важных навыков и аспектов понимания
3) его решение имело реальный смысл для кандидата, если он пройдёт. что бы это была минималистичная основа того, что ему предстоит дальше строить и развивать.
Я ожидаю, что результат окажется рабочим, без кошмарных косяков, вроде передачи серверных секретов на клиент, а человек сможет ответить на тривиальные вопросы по тому, как этот код устроен.
Но если мне человек принёс код, который сам не понимает даже с высоты птичьего полёта (увы, бывало) -- тут уж звиняйте, не сработаемся
«Братислав» отказался поднести руку к лицу, потому что это бы сняло его AI-фильтр
Теперь, видимо, будет новый этикет видеозвонков: закрыть на секунду лицо рукой, чтобы показать, что лицо настоящее.
Ко мне на собеседование дважды в прошлом году приходили "ненастоящие" кандидаты. Лицо не меняли, но читали ответы и делали тестовое задание с помощью LLM. Оба на лицо восточные азиаты, один по легенде был македонец, второй -- серб. В следующий раз буду первые несколько фраз говорить на "родном" языке кандидата. У одного даже удалось отыскать резюме на другое имя и с другим опытом
Занятно, но если заглядывать так далеко, то можно обнаружить, что "Гарлем -- неблагополучный район Манхэттэна", "Шеньджень -- рыбацкая деревушка" (цитата из Hardware hacker's handbook, по китайским меркам, конечно), а "в Москве на полках магазинов только в этом году появились продукты. правда, мало кому их небывалое разнообразие материально доступно".
30+ лет в наше время много где меняют ситуацию. А уж в Кремниевой долине и подавно
Но вообще ваше мнение, Юрий, в этом обсуждении особенно ценно.
Моя подборка цитат из поста для тех, кому лень читать целиком:
Часть статей написана людьми с весьма странными идеологическими установками. Ну и не исключаю, что часть статей — это откровенная пропаганда, написанная по заказу спецслужб стран, которые в них рекламируются
Мне сняли квартиру на несколько месяцев, поскольку я вообще не представлял процедуру съема жилья в США и не горел желанием жить там
При этом, в США каждый думает лишь о себе. Нет никаких идей об участии граждан в развитии цивилизации в целом. Уровень развития общества в США далеко отстаёт от уровня развития общества СССР в 80-е годы
Боюсь, что абсолютное большинство жителей США — это по натуре — социальные паразиты, которые готовы съесть друг друга за какие-то сиюминутные блага. США — это страна перевёртыш
Со стороны сейчас хорошо можно видеть то, что мы потеряли с развалом СССР. Примерно до 2015-го года тренд в России был на деградацию, проедая наследство СССР.
100 лет назад в СССР любая мебельная фабрика могла быть перепрофилирована под производство новой модели самолётов, выпущенной собственными же конструкторами. А сейчас не то что самолёт, даже самосборный автомобиль на дорогу не позволят выпустить. Да и аэродромы в СССР в 90-м году были чуть ли ни при каждом селе.
в моей анкете было обнаружено место работы МГТУ им. Баумана, после чего меня заподозрили в чём-то, вероятно, очень страшном для них. Проверка АНБ длилась почти 3 месяца
"проверкой АНБ" автор называет процедуру administrative processing, на которую чуть ли не каждый третий мой знакомый попадает
в России даже в нынешнем, сильно деградированном виде по сравнению с советской школой
Школьное образование в России пока ещё не полностью уничтожено и есть надежды на то, что процесс пойдёт вспять к нормальной советской
Какая-то алхимия. Словно дозы морфина и эфедрина (я не анастезиолог, но весьма необычное сочетание как по мне) в 4 - 7.5mg вообще как-то ощущаются. Разве что это расчёт на килограмм массы тела
Уже есть логистический b2b сервис. Но скорее про последюю милю пока.
https://yandexrouting.promo.page/media/kak-sberech-do-30-na-logistike-s-iandeks-marshrutizaciei-67efd5d649aaff41562292c5_0_0?
Но уже своя большая междугородная логистичесая система построена вокруг Маркета. Пока для внутренних нужд.
Но в любой момент (если ещё не) она же начнёт предоставлять b2b услуги сколько-то стандартизированные
Лучше ответить на вопрос, переживают ли клиенты выход из строя вашего цода. Всяко бывает -- пожары, землетрясения, наводнения, ракеты.
Все критичные внутренние сервисы Яндекса переживут утрату одного ДЦ. И большинство клиентов Я.Облака, которые не поскупились на зональную репликацию, тоже переживут.
Обеспечивать высокую доступность в наши дни принято за счёт зонального резервирования в первую очередь, и только во вторую за счёт надёжности отдельной зоны.
Перевожу на русский с канцелярита:
Размещение на хостинге без нашего зонда и рубильника опасно тем, что хостинг может внезапно отказать вам в услугах -- либо по своему хотению, либо из-за того, что мы его заблочим целиком за проделки отдельных клиентов. И чтобы избежать риска того, что пропадёт доступ к вашим сервисам, мы отключим доступ к вашим сервисам.
Я же поясняю, что эта разница редко когда важна, покуда редко кто будет писать такой нагруженный код, который использовался в этих бенчмарках (которые я, правда, даже не видел).
Покуда многие нагруженные части логики можно написать так, что разница исчезнет. Можно пользоваться удобством динамической типизации там, где производительность не особо важна (в моей практике это подавляющее большинство кода), и перекладывать вычисления в эффективные внешние модули там, где нужна высокая производительность. Притом, этими модулями, как правило, удобно пользоваться. Получается сочетание достоинств двух подходов
в данном случае я подразумеваю не конкретную библиотеку, а blas-интерфейс к векторным инструкциям процессора, который реализует несколько разных библиотек вроде mkl.
хотя фортран в Python вполне встречается. взять хотябы популярную зависимость scipy -- там >17% кода на фортране, который транслируется в C с помощью f2c, компилируется и вызывается
вот я и говорю -- нет понимания, что такое numpy.
это не pure python библиотека. в numpy статическая типизация. и массивы со значениями, а не указателями на структуры объектов. и все операции с numpy типами никакую динамическую типизацию содержимого не проходят. только однократную самих numpy коллекций на стыке взаимодействия с python. 100 значений в массиве или 1000000 -- не важно. python структура данных объекта в памяти будет только одна -- самого массива, не его элементов
да и вычитать данные из внешнего источника можно сразу в numpy-массивы, мимо python списков, и выгрузить наружу.
и ведь это только начало бесчисленной горы трюков оптимизации в экосистеме python, на которой пострен примерно весь существующий ML. включая всё, что делает, к примеру, OpenAI.
"у каждого свой python"
Боюсь, тут просто нет понимания, что такое numpy и pytorch и как они применяются. Рекомендую вникнуть глубже, разобраться, много ли выходит динамической типизации и характерных для Python структур данных в памяти при их использовании.
Могу лишь пример из практики привести: был у меня в старину процесс, который на mapreduce кластере на сотнях жирных нод считал всякую векторную арифметику на десятках TiB данных. Считал через numpy + blas.
В какой-то момент, я всё-таки решил проверить оптимальность такой конфигурации. Переписал на голом C (+blas) особо нагруженную часть. Ускорение по cpu time оказалось в пределах 15%. Выбросил этот C кусок и больше не вспоминал
есть что добавить к утверждению автора про спорную "нормальность" индексации с нуля, окромя вкусовщины?
На каком примере? Обучения или инференса нейросетей, для чего существует pyTorch? Учитывая то, что python там -- просто обвязка и клей между компонентами, а вычисления неявно выносятся в numpy, blas, cuda у меня есть ряд объективных сомнений, что получится обогнать на сложном примере работы с векторами и матрицами.
Он прав в том смысле, что и в этом посте и в телеграме действительно есть мутные определения, которые вызываеют вопросы.
И цитату про он привёл характерную, про то, что "горутины-то не то, что потоки, они-то живут внутри одного адресного пространства". Это действительно наводит на мысли о недопонимании.
Цитаты же
Тоже меня лично смущают. из них можно сделать вывод, что процессы и потоки -- это объекты схожей природы и можно одно заменять другим, что не так.
Поток -- всегда дочерняя сущность одного и только одного процесса. В любом процессе всегда есть хотя бы один поток.
Процесс -- это про виртуальное адресное пространство, метаинфу вроде переменных среды и взаимодействие с операционной системой в плане доступов.
Поток -- это про значения набора регистров (это и есть тот самый контекст) и про планировщик.
Можно примеры с пояснениями, почему ответ конкурента лучше?
Да, решил. Я продолжаю считать, что это было верное решение. Мы на рынке. Если кандидатов много, а вакансий мало, я могу и буду пользоваться этим обстоятельством.
У меня нет задачи ублажать кандидатов. У меня есть задача закрыть вакансию с заданным качеством и минимальными трудозатратами. Я не вижу доводов, которые бы показали, что я поступил нерационально в данной ситуации.
Да, и за свою карьеру делал несколько тестовых заданий. Среди них попадались очень достойные и интересные. Дважды даже неделю тратил, но обретал много ценных знаний в процессе и оставался доволен.
И, очевидно, что места были привлекательные и даже на куда более кандидато-центричном рынке, чем мы имеем сегодня, спроса хватало.
Однажды предложили небольшое, но бесмысленнное и нерелевантное -- вот тогда я прямо спрашивал у нанимателей, какие сигналы и как они планируют вытянуть из решения, в чём смысл? Не получив вразумтительного ответа, я был разочарован. Тогда я предложил им обсудить подходы в привлечении сотрудников и рассказал им подробно, как это делают их конкуренты. Надеюсь, они сделали какие-то выводы и продолжают это дело более осмысленно.
Тут чтобы пояснить суть, надо влезать глубоко в контекст, что выходит за рамки обсуждения. Но вкратце так: есть некоторая продуктовая экосистема. В ней 95% исполнителей на рынке делают продукт типа 1, но заодно могут указать в резюме мимоходом куда более редкий продукт типа 2, опыт с которым мне и нужен. И хотя экосистема общая, специфика продуктов 1 и 2 сильно отличается. И знаний клепателей продукта 1 фундаментально не хватает на продукт 2.
Когда эта особенность стала мне понятна по результатам нескольких неудачных собеседований, я стал просить сделать более-менее hello world с минимальной релевантной для моей задачи модифиацией продукта 2, что отсекло множество нерелевантных кандидатов.
В общем, на другую вакансию, где такой специфики нет, я собеседовал людей совершенно иначе. Тестовых заданий не было и не планировалось
Всё-таки этой книге уже прилично лет. Да и описываются там не передовики бигтеха, а второго эшелона IT команда в производственной компании. То, что там показывается как невероятное чудо "ничось, я закомитил, тесты сами прошли и оно само задеплоилось", "мы научились в agile доску (ака канбан) и приоритеты задач" уже давно является минимальным гигиеническим уровнем.
Но я согласен, что автор поста, судя по всему, не понял суть этой книги.
Phoenix Project -- это адаптация "The goal" Голдрата в области управления IT-инфраструктурой. А "The goal" -- это просто попытка на конкретном примере показать идеи и подходы бережливого производства, также известного как Toyota production system.
И смысл там не в том, сколько бывает "вредных" и некомпетентных сотрудников, а в том, какие принципы мышления и техники организации работы применяются для постоянного улучшения процессов.
Это инструмент. Который можно эффективно применять в подходящих условиях.
И первый десяток людей на заданную позицию я собеседовал без него. Однако, поняв, что все кандидаты вообще не шарят, хоть и расписали целевой опыт в резюме, я решил не тратить зря своё время дальше, благо размер входящего потока позволял его фильтровать любыми способами.
В итоге я нашёл нужного человека, который без проблем сделал. И уже больше года со мной успешно работает.
Так что я этот инструмент и дальше буду применять, где нужно.
К слову, у меня нет претензии, что тестовое задание делается с помощью любых привычных инструментов, включая LLM. В этом и смысл тестового задания -- максимально приближенная к реальной практике деятельность.
И подбирал я его так, чтобы:
1) для целевого кандидата это была тривиальная задача на пару часов максимум.
2) в нём можно было продемонстрировать ряд важных навыков и аспектов понимания
3) его решение имело реальный смысл для кандидата, если он пройдёт. что бы это была минималистичная основа того, что ему предстоит дальше строить и развивать.
Я ожидаю, что результат окажется рабочим, без кошмарных косяков, вроде передачи серверных секретов на клиент, а человек сможет ответить на тривиальные вопросы по тому, как этот код устроен.
Но если мне человек принёс код, который сам не понимает даже с высоты птичьего полёта (увы, бывало) -- тут уж звиняйте, не сработаемся
Теперь, видимо, будет новый этикет видеозвонков: закрыть на секунду лицо рукой, чтобы показать, что лицо настоящее.
Ко мне на собеседование дважды в прошлом году приходили "ненастоящие" кандидаты. Лицо не меняли, но читали ответы и делали тестовое задание с помощью LLM. Оба на лицо восточные азиаты, один по легенде был македонец, второй -- серб. В следующий раз буду первые несколько фраз говорить на "родном" языке кандидата. У одного даже удалось отыскать резюме на другое имя и с другим опытом
Занятно, но если заглядывать так далеко, то можно обнаружить, что "Гарлем -- неблагополучный район Манхэттэна", "Шеньджень -- рыбацкая деревушка" (цитата из Hardware hacker's handbook, по китайским меркам, конечно), а "в Москве на полках магазинов только в этом году появились продукты. правда, мало кому их небывалое разнообразие материально доступно".
30+ лет в наше время много где меняют ситуацию. А уж в Кремниевой долине и подавно
Но вообще ваше мнение, Юрий, в этом обсуждении особенно ценно.
Моя подборка цитат из поста для тех, кому лень читать целиком:
"проверкой АНБ" автор называет процедуру administrative processing, на которую чуть ли не каждый третий мой знакомый попадает
Можно подробнее про криминальные районы Пало Альто?
И поэтому надо ехать в Россию, где такой проблемы сейчас нет?
Можно подробнее про криминальные районы Пало Альто?
И поэтому надо ехать в Россию, где такой проблемы сейчас нет?
Какая-то алхимия. Словно дозы морфина и эфедрина (я не анастезиолог, но весьма необычное сочетание как по мне) в 4 - 7.5mg вообще как-то ощущаются. Разве что это расчёт на килограмм массы тела
Что использовали в для наркоза?