Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Саша достаточно чётко расписывает спецификацию требований к аллокатору. В том числе и такие вещи как выедание ассоциативности кэша. A>>Это не так уж просто, ведь не только кэш-данных и кэш-кода в ЦПУ, но и надо помнить про TLB-кэш. Учитывая не только нюансы использования N-входов частично-ассоциативного кэша ЦПУ, но и нюансы работы механизмов виртуальной памяти на конкретной архитектуре.
S>Это всё праздное симпозиумное балабольство. Когда у тебя под ногами несколько систем, занимающихся выделением тебе памяти, и всё что ты можешь-это как-то распорядиться выделенными тебе кусками, то учитывать нужно не только TLB или механизмы отображения выртуальных адресов в адреса страниц физической памяти, но и особенносьти реализации этих самых подсистем под ногами. Тут же получаются рассуждения о скорости бега, сидя в инвалидном кресле-твоя скорость в любом случае будет определяться скоростью того самого кресла.
Эффективность это не только скорость, но и деградация производительности по мере возрастающего давления на кучу (из-за увеличивающейся фрагментированности). Т.е. надо искать некий компромисс или консенсус исходя из нюансов работы и взаимодействия тредов внутри конкретной подсистемы.
Здравствуйте, a7d3, Вы писали:
A>Конечно не умею, и ваш CTO тоже не умеет. О чём сам и говорит, что собеседования они проходить умеют замечательно, но вот работать у них получается хреново или вообще не получается.
Ну да, конечно. При этом на лето мы набираем пачку стажеров из студентов, чтобы они хреново работали и отнимали время у своих руководителей. А некоторых потом еще и в штат берут, чтобы и дальше продолжали хреново работать.
Здравствуйте, a7d3, Вы писали:
A>Например, поговорить о проблематики создания спецификаций кода отдельных подсистем, в рамках подготовки к использованию формальных методов валидации. A>Так понимаю, что любители задачек на таком вопросе начнут мило хлопать глазками сидя на попе ровно.
Здравствуйте, a7d3, Вы писали:
A>Например, поговорить о проблематики создания спецификаций кода отдельных подсистем, в рамках подготовки к использованию формальных методов валидации. A>Так понимаю, что любители задачек на таком вопросе начнут мило хлопать глазками сидя на попе ровно.
почему именно про это? почему не про тонкости реализации FUSE файловых систем, или не про алгоритмы gait planning в робототехнике, уверен, каждый второй может написать прошивку для Big Dog-а, от кандидатов отбоя не будет
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, a7d3, Вы писали:
A>>Например, поговорить о проблематики создания спецификаций кода отдельных подсистем, в рамках подготовки к использованию формальных методов валидации. A>>Так понимаю, что любители задачек на таком вопросе начнут мило хлопать глазками сидя на попе ровно.
CK>ты хотел сказать формальных методов верификации?
Если не знаешь разницу между валидацией и верификацией, то разговора не получится
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, a7d3, Вы писали:
A>>Например, поговорить о проблематики создания спецификаций кода отдельных подсистем, в рамках подготовки к использованию формальных методов валидации. A>>Так понимаю, что любители задачек на таком вопросе начнут мило хлопать глазками сидя на попе ровно.
CK>почему именно про это? почему не про тонкости реализации FUSE файловых систем, или не про алгоритмы gait planning в робототехнике, уверен, каждый второй может написать прошивку для Big Dog-а, от кандидатов отбоя не будет
Потому что с человеком надо знакомиться, а не гонять его по чеклисту.
Знакомиться — это узнавать «чем дышит», какие у него увлечения и предпочтения в профессиональном плане. Чего и как с кругозором, что его цепляет, в сторону какого направления ему хотелось бы развиваться.
Собеседование не сводится к унижению или «размазыванию» людей ради того, чтобы за их счёт поднять свою самооценку. Не сводится и к оценке и сравниванию людей. Ты должен в результате разговора уйти узнав для себя что-то новое, а не со скучающе-надменным видом задавать вопросы два-три часа вопросы, ответы на которые уже 20 лет как всем набили оскомину. Не трать в пустую ни своё ни чужое время — жизнь коротка и если чувствуешь себя погано, то это не повод выплёскивать негатив на других спуская в унитаз кучу времени.
Здравствуйте, sergey2b, Вы писали:
s> а чем они мотивируют запрет использования юсключений
Медленные. И слишком тонка грань между "просто ошибка" и "ошибка требующая выброса исключения" в результате чего хрупкий баланс костылей и противовесов быстро нарушается в сторону выбрасывания исключений на любой чих в одних подсистемах, тотальному return err в других, и в итоге это приводит к падениям или просадке производительности приложения в самых неожиданных местах, когда первое скрещивают со вторым.
Впрочем, я не настоящий сварщик и возможно есть более лаконичное объяснение.
Здравствуйте, bzig, Вы писали:
B>>>Программистом? N>>Ага. B>При этом уже много лет тут рассказываешь, какой ты крутой ПМ. Не сходятся концы. <рвёт на себе тельняшку>Ты #$%^& кого ПМом назвал??
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, sergey2b, Вы писали:
s>> а чем они мотивируют запрет использования юсключений
AB>Медленные. И слишком тонка грань между "просто ошибка" и "ошибка требующая выброса исключения" в результате чего хрупкий баланс костылей и противовесов быстро нарушается в сторону выбрасывания исключений на любой чих в одних подсистемах, тотальному return err в других, и в итоге это приводит к падениям или просадке производительности приложения в самых неожиданных местах, когда первое скрещивают со вторым.
AB>Впрочем, я не настоящий сварщик и возможно есть более лаконичное объяснение.
Тоже не настоящий, но более лаконичное: «не осилили».
Это когда бардака в компании много, за процессами следить некому. В итоге и нанимают абы кого, всяких олимпиадников и коммитят сотрудники абы что и абы как.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, a7d3, Вы писали:
A>>Саша достаточно чётко расписывает спецификацию требований к аллокатору. В том числе и такие вещи как выедание ассоциативности кэша. A>>Это не так уж просто, ведь не только кэш-данных и кэш-кода в ЦПУ, но и надо помнить про TLB-кэш. Учитывая не только нюансы использования N-входов частично-ассоциативного кэша ЦПУ, но и нюансы работы механизмов виртуальной памяти на конкретной архитектуре.
S>Это всё праздное симпозиумное балабольство. Когда у тебя под ногами несколько систем, занимающихся выделением тебе памяти, и всё что ты можешь-это как-то распорядиться выделенными тебе кусками, то учитывать нужно не только TLB или механизмы отображения выртуальных адресов в адреса страниц физической памяти, но и особенносьти реализации этих самых подсистем под ногами. Тут же получаются рассуждения о скорости бега, сидя в инвалидном кресле-твоя скорость в любом случае будет определяться скоростью того самого кресла.
Смотреть данный доклад полезно всем, кому приходится задуматься над темой кастомизированных аллокаторов. Просто для того, чтобы получить некий overview (общее представление?) по данной теме. Ознакомиться с неким дайджестом по всему тому, что вращается там и как-либо формирует ландшафт.
В остальном же, тяга к универсальным решениям в общем виде — это бич программистов, такой же как стремление ковбойствовать или писание кода в состоянии потока. От того, что нет желающих оплачивать ни первое, ни второе, ни третье.
Здравствуйте, Zhendos, Вы писали:
Z>Так в Go до сих пор GC без поколений, разве нет? То есть если Z>есть куча объектов одновременно, то будет тормозить.
В случае с кучей объектов в Go принято использовать sync.Pool. Немного замеров (да, синтетика, но и в реале хорошо ускоряет) можно тут посмотреть.
Z>Плюс обработка ошибок не лучше чем исключения, в плане того что всегда можно пропустить Z>или забыть это вечно `err != nil` по-моему даже std::variant<OkType, ErrType> лучше, Z>он заставит пользователя подумать о том, чтобы оба варианта обработать
В Go принято подключать к проекту линтеры и они всегда рапортуют о необработанных ошибках. Например на всех наших проектах смерждить в мастера просто не возможно пока линтеры не удовлетворишь. Обработка, конечно, развесисто-лапшичная, тут возразить нечего.
Здравствуйте, sergey2b, Вы писали:
S>а чем они мотивируют запрет использования юсключений
Так это, может в первоисточнике посмотреть? Обрати внимание на вот этот кусок из их мотивировки:
On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code.
Ну и еще довольно интересно что в CppCoreGuidelines насчет исключений и их применимости говорят. Вот не менее интчересный кусок из CoreGuidelines:
* Often, explicit error checking and handling consume as much time and space as exception handling.
* Often, cleaner code yields better performance with exceptions (simplifying the tracing of paths through the program and their optimization).
По большому счету, сторонники отказа от исключений либо говно мамонта поддерживают, либо в ооочень жестком окружении работают, либо идиоты ретрограды.
Здравствуйте, jamesq, Вы писали:
mgu>>>>В маленькой компании из 5 человек путь к должности CTO гораздо короче.
НС>>>Вот только СТО в маленькой кнторе и в большой это две очень большие разницы.
mgu>>Так ведь задача-то "раздавать визитки".
J>Задача — раздавать визитки крупной конторы. J>А если просто "раздавать визитки", то тебе даже и компания на 5 человек не нужна. J>Ты же наверное знаешь, что учредить ООО сейчас — это тысяч 10 рублей уставного капитала (ну и немного больше на другие расходы, вроде банковского обслуживания)? J>И ты там можешь стать сразу директором. У меня вон есть один знакомый такой. В 18 лет как раз стал директором такой конторки. Что-то там собирался организовывать.
J>Да да. А ещё, своего младшего брата ты можешь записать супер-пупер-мега архитектом, дедушку просто программистом-сеньором, а бабушку главбухом (и кстати, если она и впрямь работала им, думаю, она даже и не посрамит титул).
Вы техзадания так же имплементируете? Так вот, чтобы раздавать визитки, достаточно их нарисовать и напечатать.
J>Ох уж эти намёки, что ваша шаражка на 5 персон — аж целый Ватикан. Даже если так, при таких раскладах, подозреваю, путь к CTO может оказаться ничуть не проще чем в крупной конторе. J>Просто ибо никто тебе не обязан ничего предоставлять, это контора собственность её хозяина, вертикальный рост отсутствует как явление, и вы можете 20 лет работать в неизменном составе.
Выделенное: блин, да это же контора мечты (коллектив и заказчики не разбегаются), где же найти такую?
Здравствуйте, smeeld, Вы писали:
S>Поэтому яндекс не есть гугл и никогда таковым не станет.
Как раз стал, со всеми вторичными половыми признаками монстра: доход поступает от первого продукта, написанного во времена малого размера компании, и скупленных стартапов. А 80% разработчиков занимаются... как бы это пополиткорректнее? -- кинопоиском.
Здравствуйте, Hobbes, Вы писали:
H>Компьютер или телефон, с которого ты пишешь, машина, на которой ты ездишь, холодильник, где ты хранишь сыр — эти высокотехнологичные продукты созданы большими компаниями.
Здравствуйте, Sharov, Вы писали:
S>Программы обучения коррелируют с соотв. навыками и инстинктами нужными для яндекса и им подобных, а именно уметь писать быстро и качественно эффективно работающий код.
Их студенты 1-3 курсов пачками проходят.