греф зажлобил что бы доклады были видны на ютубе
вместо этого на них можно выйти только по прямой ссылке
видимо он знает что конфа так себе, все как один по шаблону и ни одного интересного доклада
так что да,хай лоад хотя бы чуть различие в докладах
M>Что читать, смотреть, чтобы БЫСТРО въехать во все тонкости и изучить все грабли?
Э... Мне кажется что в такую тему можно въехать медленно и через боль от работы с реальными проектами.
Современный highload-это не какие-то волшебные проги, напичканые магией и мудростью внеземных цивилизаций. Это очень монстрообразные кластерные системы, состоящие из огромной кучи компонентов. каждый компонент-это самая простая прога, чаще всего сетевой демон. Он может быть написан на чём угодно, хоть на C++, хоть на Java, хоть на python, хоть на Go. Это вообще не принципиально. Каждый такой компонент не содержит каких-либо сложных вещей, каких-либо крутых оптимизаций или какой-то магии, он обязательно максимально прост. Никаким особым требованиям к компоненты не должны удовлетворять. Более того, если компоненты содержат сложности-то это признак неудачной архитектуры системы в целом, архитекторы зорко следят, чтоб компоненыт были максимально просты. Основная интеллектуальная нагрузка в современном highload лежит на архитекторах, составляющих общую архитектуру этих систем, они же получают максимальную зрплт. Эти набирают или по рекомендациям, или выбирают из числа отметившихся сторожил, в таковые не берут с улицы по объявлениям. Рядовые прогеры в современном highload-это винтики, тупо кодеры, пилящие строго определённый код строго по спекам и правилам, задаваемым архитекторами и аналитиками. Работа одинаковая как у джунов, так и у матёрых разрабов. Много они не получают.
Здравствуйте, reversecode, Вы писали:
R>греф зажлобил что бы доклады были видны на ютубе R>вместо этого на них можно выйти только по прямой ссылке
Какая разница то, если эти самые прямые ссылки выложены публично чуть ли не на главной странице конференции? https://ai-journey.ru/conference-moscow/broadcast
R>видимо он знает что конфа так себе, все как один по шаблону и ни одного интересного доклада
Да ладно, в первый день в секциях AGI, CV и "Новых методов ML" много чего интересного и нового (некоторые вещи даже ещё в коде не существуют) было.
R>так что да,хай лоад хотя бы чуть различие в докладах
Здравствуйте, Molchalnik, Вы писали:
M>бывает ли хайлоад без сетевого программирования? как отсутствие сетевого меняет шансы на найм в хайлоад?
Если ты из геймдева, то разобраться с сетью проблем не составит. Скорее всего тееб просто на собес надо сходить, но не в Я.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Molchalnik, Вы писали:
M>>бывает ли хайлоад без сетевого программирования? как отсутствие сетевого меняет шансы на найм в хайлоад? K>Если ты из геймдева, то разобраться с сетью проблем не составит. Скорее всего тееб просто на собес надо сходить, но не в Я.
Заинтересовала формулировка ответа. А откуда надо быть что бы разобраться с сетью было проблемой? А почему после геймдева не будет проблемой? Область же охрененно огромная.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Molchalnik, Вы писали:
S>Современный highload-это не какие-то волшебные проги, напичканые магией и мудростью внеземных цивилизаций. Это очень монстрообразные кластерные системы, состоящие из огромной кучи компонентов. каждый компонент-это самая простая прога, чаще всего сетевой демон. Он может быть написан на чём угодно, хоть на C++, хоть на Java, хоть на python, хоть на Go. Это вообще не принципиально. Каждый такой компонент не содержит каких-либо сложных вещей, каких-либо крутых оптимизаций или какой-то магии, он обязательно максимально прост. Никаким особым требованиям к компоненты не должны удовлетворять.
Кстати, вот да — главное "открытие", которое для себя нужно сделать пораньше: high-load вовсе не означает high efficiency. Зачастую основная идея там зерг-раш, набросать побольше юнитов, пусть даже КПД каждого будет единицы процентов.
Здравствуйте, kaa.python, Вы писали:
KP>Заинтересовала формулировка ответа.
Да, мужик, сорян, криво сформулировал. Мысли путаются последнее время, видимо приближается тот самый час. KP>А откуда надо быть что бы разобраться с сетью было проблемой? А почему после геймдева не будет проблемой? Область же охрененно огромная.
Если человек из ГД, то у него всё должно быть впорядке с алго. подготовкой, оптимизацией и пониманием проблем производительности системы: блокировки, кэш мисы, излишнее копирование данных, пулы, O(n) и т.п. Надо будет только сеть изучить со спецификой работы стека и протоколов под линуксом, и специфичные вещи работы ОС при которых может падать перфоманс. Без первого, смысла изучать сеть и ОС нет.
P.S. Да, я понимаю что геймдев это не только движок, а ещё и тулы где производительность не сильно важна.
Здравствуйте, smeeld, Вы писали:
S>Современный highload-это не какие-то волшебные проги, напичканые магией и мудростью внеземных цивилизаций.
Хайлоад который мы заслужили. Хотя нет, хайлоад который заслужило новое поколение программистов на питоне, ноджс и Go.
Здравствуйте, Kernan, Вы писали:
K>Хайлоад который мы заслужили. Хотя нет, хайлоад который заслужило новое поколение программистов на питоне, ноджс и Go.
Нет, просто нагрузки сейчас такие, что одна машина их не потянет, ни один майнфрейм. Поэтому нагрузку шарят на кластеры из тысяч и тысяч мелких тазиков. На каждый из тазиков нагрузка приходится очень небольшая и нет никакой необходимости пилить для них что-то сверхеоптимальное.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Kernan, Вы писали:
K>>Хайлоад который мы заслужили. Хотя нет, хайлоад который заслужило новое поколение программистов на питоне, ноджс и Go.
S>Нет, просто нагрузки сейчас такие, что одна машина их не потянет, ни один майнфрейм. Поэтому нагрузку шарят на кластеры из тысяч и тысяч мелких тазиков. На каждый из тазиков нагрузка приходится очень небольшая и нет никакой необходимости пилить для них что-то сверхеоптимальное.
Я это понимаю. С другой стороны, почему нет смысла оптимизировать ПО локально? Дорого слишком?
Здравствуйте, Kernan, Вы писали:
K>Я это понимаю. С другой стороны, почему нет смысла оптимизировать ПО локально? Дорого слишком?
Зачем? Выскооптимизированное ПО имеет смысл писать только для исполнения на мощных и дорогих машинах, чтоб это ПО способно было выжать весь потенциал железа, либо наоборот, если машины слабые и их количество ограничено (как было когда-то, когда старались уложиться в 64 KB RAM). Но если кластеры намеренно собирают из стандартных дешёвых тазиков, то нет смысла вкорячивать на них оптимзированный софт. И да, давно уже дешевле докинуть боксов в кластер, чем держать команду, оптимизирующую софт. Тем более, что софт нельзя оптимизировать до бесконечности, предел оптимизиции софта достигается очень быстро. Количество же тазиков можно наращиать до бесконечности.
Здравствуйте, smeeld, Вы писали:
K>>Хайлоад который мы заслужили. Хотя нет, хайлоад который заслужило новое поколение программистов на питоне, ноджс и Go. S>Нет, просто нагрузки сейчас такие, что одна машина их не потянет, ни один майнфрейм. Поэтому нагрузку шарят на кластеры из тысяч и тысяч мелких тазиков. На каждый из тазиков нагрузка приходится очень небольшая и нет никакой необходимости пилить для них что-то сверхеоптимальное.
Сейчас все что ни пoпaдя называют хайлоад. Масштабы гугла или фейсбука где миллиарды запросов в день — это понятно. Но когда переодически встречаешь статьи и ролики на ютубе, где чуваки разворачивают кластер, чтобы обслужить 10-20 миллионов запросов к сайтику в день и называют это хайлоад — это смешно.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, smeeld, Вы писали:
S>Нет, просто нагрузки сейчас такие, что одна машина их не потянет, ни один майнфрейм. Поэтому нагрузку шарят на кластеры из тысяч и тысяч мелких тазиков. На каждый из тазиков нагрузка приходится очень небольшая и нет никакой необходимости пилить для них что-то сверхеоптимальное.
Дело не в нагрузках, а в масштабируемости разработки. Значительную часть современного "хайлоада" можно решить одним физическим серверов и одним сервисом, но он должен быть хорошо написан и настроен. Куда проще разбить задачу и решить экстенсивным путем на всех уровнях.
Здравствуйте, smeeld, Вы писали:
S>Тем более, что софт нельзя оптимизировать до бесконечности, предел оптимизиции софта достигается очень быстро.
Зато предел пессимизации бесконечен.
Здравствуйте, Anton Batenev, Вы писали:
AB>Это только пока у тебя тазиков 10-20. Когда счет пойдет на тысячи, цена владения начинает сильно кусаться.
Их счёт идёт на миллионы в некоторых канторах. И на десятки тысяч в канторах поменьше. Всё без проблем управляется небольшими командами админов средней квалификации. Количество серваков в несколько сотен-это вообще обыденное дело для любой хоть немного поднявшейся шараажки.
Здравствуйте, Skorodum, Вы писали:
S>Дело не в нагрузках, а в масштабируемости разработки. Значительную часть современного "хайлоада" можно решить одним физическим серверов и одним сервисом, но он должен быть хорошо написан и настроен.
Только если это доморощенный сайтик. Для остальных задач даже майнфреймов уже не хватает, независимо от того, какой степени оптимизированности там софт.
Здравствуйте, smeeld, Вы писали:
S>Только если это доморощенный сайтик. Для остальных задач даже майнфреймов уже не хватает, независимо от того, какой степени оптимизированности там софт.
Вот прям для всех?
