Здравствуйте, Denis Ivlev, Вы писали:
DI>Что отлично показывает, что твоя методика оценки не работает
Методика простая — просто покажите деньги.
DI> так как по количеству и качеству технологий Твитеру до Яндекса как до Луны.
Какая цена этим "технологиям" прекрасно видно из зарабатываемых ими сумм.
Да и если посмотреть подробнее то заявленные "технологии" выглядят как передирание уже сделанного другими с подточкой под местный рынок.
А за то, что Яндекс.Такси сотворил с перекупленным в РБ убером так и вовсе взять и уе... хочется.
Технология "Мидас современности" — всё что трогает превращается в говно.
CC>Если под интернет-компаниями понимать все, что активно что то делают в инете (те, что назвали бы .com) то по revenue YNDX плетётся в хвосте CC>Лень делать правильный screener, примерный список будет тут: https://en.wikipedia.org/wiki/List_of_largest_Internet_companies
По твоей ссылке яндекс третий из европейских после Spotify и Flipkart
И даже 27-е место в общемировом рейтинге это круто.
Здравствуйте, chaotic-kotik, Вы писали:
CK>По твоей ссылке яндекс третий из европейских после Spotify и Flipkart
Там ж написано: "This list is incomplete"
Меня конечно грызло сомнение что не надо было ссылки на вики приводить, где данные чёрти кто чёрти откуда заполняет.
CK>И даже 27-е место в общемировом рейтинге это круто.
Это даже не рейтинг.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, a7d3, Вы писали:
A>>Просто нельзя лениться донося до персонала нюансы и приколы этой темы с релятивистскими эффектами из-за реордеринга и моделей памяти. Тогда спокойнее воспринимается запрет самим влезать в эти вопросы (типа баба с возу — кобыле легче).
CK>Я там где-то выше писал про то, что один разраб у нас долго доказывал всем что задача слишком сложная и решать ее не надо, а потом новичок ее зарулил. Мне там ответили что у нас шарага и аутсорс. Вот живой пример того, как "опытный" разраб доказывает что что-то не нужно, потому что сложно.
CK>Можно ныть про то что lock-free это сложно, а можно осилить TLA+ и доказать с его помощью корректность lock-free алгоритмов.
Не было никаких сомнений, что от людей вроде тебя ускользнёт смысл сказанного мною. Или что будет какой-то детский сад с выдёргиванием фраз из контекста
Важно чтобы дилетанты не хватались за сложные вещи. Мотивов этому сразу несколько, так что велкам перечитывать сказанное и думать ещё раз.
Здравствуйте, a7d3, Вы писали:
A>Не было никаких сомнений, что от людей вроде тебя ускользнёт смысл сказанного мною. Или что будет какой-то детский сад с выдёргиванием фраз из контекста
В общем то взаимно, смысл сказанного был в том, что есть люди, которые будут до посинения объяснять тебе то, что что-то делать не надо, а что-то и так хорошо, работает же. Я так и подумал что это про тебя, напомню:
CK>>>Чеклист и равные условия для всех нужны потому, что не всегда условный обладатель большого опыта и каких-то узких знаний в области создания спецификаций и подготовке к использованию разных вещей, является успешным разработчиком. Бывает так, что такой вот человек пол года рассказывает всем о том, что какая-та задача является нерешаемой, а потом приходит новый кандидат, 2 года после универа с почти пустым резюме, и замечательно ее решает. И поэтому хочется дать все одинаковые возможности, не зависимо от опыта. Но тебе этого видимо не понять, потому что корона давит и тебе не приходит в голову то, что твой опыт мало применим за пределами твоего огорода, а способность решать алгоритмические задачи — применима.
A>>Откуда этот бардак? Что кто-то из сотрудников может пудрить мозг коллегам столь продолжительное время? A>>У людей недостаточный уровень образования или же им просто начхать на происходящее?
Т.е. в соседней ветке ситуацию с "надо ли фокусироваться на решениях под большое число ядер, если основную выручку генерируют клиенты с 8 ядрами" ты назвал бардаком
Вот я лично вижу тут простую лень. Lock-free — сложно, многопоточность — тоже слжоно. Давайте не фокусироваться на решениях под большое количество ядер (и не нарабатывать экспертизу в этой области).
Подобная лень мне встречалась в работе очень часто. Когда люди удовлетворяются так себе решением, которое вытащили off the top of their head и не копнули глубже в поисках более оптимального решения. Этими своими задачками Яндекс пытается найти людей, способных сделать этот лишний шаг нужное количество раз.
A>Важно чтобы дилетанты не хватались за сложные вещи. Мотивов этому сразу несколько, так что велкам перечитывать сказанное и думать ещё раз.
Глупо делить разработчиков в команде на тех, кому можно пилить те или иные вещи, и на тех кому нельзя. Объяснить почему?
Здравствуйте, chaotic-kotik, Вы писали:
CK>Т.е. в соседней ветке ситуацию с "надо ли фокусироваться на решениях под большое число ядер, если основную выручку генерируют клиенты с 8 ядрами" ты назвал бардаком
CK>Вот я лично вижу тут простую лень. Lock-free — сложно, многопоточность — тоже слжоно. Давайте не фокусироваться на решениях под большое количество ядер (и не нарабатывать экспертизу в этой области). CK>Подобная лень мне встречалась в работе очень часто. Когда люди удовлетворяются так себе решением, которое вытащили off the top of their head и не копнули глубже в поисках более оптимального решения. Этими своими задачками Яндекс пытается найти людей, способных сделать этот лишний шаг нужное количество раз.
A>>Важно чтобы дилетанты не хватались за сложные вещи. Мотивов этому сразу несколько, так что велкам перечитывать сказанное и думать ещё раз.
CK>Глупо делить разработчиков в команде на тех, кому можно пилить те или иные вещи, и на тех кому нельзя. Объяснить почему?
Решение на блокирующей многопоточке более производительно на малом количестве ядер ЦПУ, чем вариант через lock-free/wait-free.
Если 90% выручки формируют клиентов покупающих продукт для использования на четырёх-восьми-ядерных системах и производительность для них важна, то конечно же надо положить на них всех — переделав усё на lock-free. Ты же хозяин-барин, что хочешь то и творишь.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Можно ныть про то что lock-free это сложно, а можно осилить TLA+ и доказать с его помощью корректность lock-free алгоритмов.
Здравствуйте, chaotic-kotik, Вы писали:
CK>В общем то взаимно, смысл сказанного был в том, что есть люди, которые будут до посинения объяснять тебе то, что что-то делать не надо, а что-то и так хорошо, работает же.
А еще есть люди, которые даже не задумываясь бегут делать вещи, в которых ничерта не понимают. Тебе если примера с самодельной очередью мало — так у меня их еще много. Тут один товарищ решил свою мастер-пастер репликацию запилить. Нужно объяснять чем это закончилось?
CK>Вот я лично вижу тут простую лень. Lock-free — сложно, многопоточность — тоже слжоно. Давайте не фокусироваться на решениях под большое количество ядер
Ты что то свое услышал. Lock free это сложно, поэтому давайте использовать готовые алгоритмы и их реализации, а если уж приспичило изобрести свой, то надо трезво оценивать нужную квалификацию, объем работ и количество потребных тестов.
Здравствуйте, a7d3, Вы писали:
A>Решение на блокирующей многопоточке более производительно на малом количестве ядер ЦПУ, чем вариант через lock-free/wait-free.
в общем случае параллельно вообще, производительность тут будет зависеть от contention, можно построить lock-free алгоритм, у которого будет очень высокий уровень contention и он будет медленно работать как на малом количестве ядер, так и на большом
тоже самое справедливо относительно блокирующей синхронизации
то что твой код работает быстро на 8-ми и медленно на 48-ми ядрах, говорит о высоком уровне contention, поэтому решается здесь все не изменением способа синхронизации, очевидно же
A>Если 90% выручки формируют клиентов покупающих продукт для использования на четырёх-восьми-ядерных системах и производительность для них важна, то конечно же надо положить на них всех — переделав усё на lock-free. Ты же хозяин-барин, что хочешь то и творишь.
то что в многопоточке нужно использовать разные алгоритмы и примитивы синхронизации для большого и малого количества ядер — это поверхностное решение, которое может быть легче найти, но которое точно не является приемлемым (хотя смотря для кого)
сегодня у твоих клиентов 8 ядер, завтра 48, а через неделю 96
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А еще есть люди, которые даже не задумываясь бегут делать вещи, в которых ничерта не понимают. Тебе если примера с самодельной очередью мало — так у меня их еще много. Тут один товарищ решил свою мастер-пастер репликацию запилить. Нужно объяснять чем это закончилось?
ты так говоришь, словно мульти-мастер это так сложно
этот твой товарищ решил запилить и сделал очевидно плохо, но сделать плохо, это первый шаг к тому чтобы сделать хорошо
ну или можно было ничего не делать, потому что сложна
НС>Ты что то свое услышал. Lock free это сложно, поэтому давайте использовать готовые алгоритмы и их реализации, а если уж приспичило изобрести свой, то надо трезво оценивать нужную квалификацию, объем работ и количество потребных тестов.
это какбы само собой разумеется, не думал что нужно явным образом очевидное проговаривать
Здравствуйте, chaotic-kotik, Вы писали:
CK>ты так говоришь, словно мульти-мастер это так сложно
Ну как тебе сказать. Есть такая САР теорема, сильно ограничивает полет мысли.
CK>этот твой товарищ решил запилить и сделал очевидно плохо, но сделать плохо, это первый шаг к тому чтобы сделать хорошо
Ну да. А то что небольшой проект делали больше года и так и не сделали, это так, ерунда. А товарищ тот в итоге вообще свалил.
CK>ну или можно было ничего не делать, потому что сложна
Нет, можно было не делать мастер-мастер репликацию, а делать то что требовалось. Или, если уж приспичило, взять готовое решение.
CK>это какбы само собой разумеется,
Это как бы само собой почти никогда не разумеется на практике.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну как тебе сказать. Есть такая САР теорема, сильно ограничивает полет мысли.
спасибо что открыл глаза
CK>>ну или можно было ничего не делать, потому что сложна НС>Нет, можно было не делать мастер-мастер репликацию, а делать то что требовалось. Или, если уж приспичило, взять готовое решение.
я же не знаю что требовалось, если требовалось писать бухгалтерию на 1С а он писал мультимастер то плохо, да
я просто подумал, что раз взялись писать мультимастер, значит требовалась поддержка множества датацентров, например, а не костыльно это можно сделать только так
ну и это не так уж сложно, если требуется написать какой-нибудь распределенный кэш или KV, в общем что-то не требующее транзакций и cluster membership/shard migration не автоматический
НС>Это как бы само собой почти никогда не разумеется на практике.
возможно тебе просто не везет с местом работы, попробуй отправить резюме в Яндекс
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, a7d3, Вы писали:
A>>Решение на блокирующей многопоточке более производительно на малом количестве ядер ЦПУ, чем вариант через lock-free/wait-free.
CK>в общем случае параллельно вообще, производительность тут будет зависеть от contention, можно построить lock-free алгоритм, у которого будет очень высокий уровень contention и он будет медленно работать как на малом количестве ядер, так и на большом CK>тоже самое справедливо относительно блокирующей синхронизации
CK>то что твой код работает быстро на 8-ми и медленно на 48-ми ядрах, говорит о высоком уровне contention, поэтому решается здесь все не изменением способа синхронизации, очевидно же
A>>Если 90% выручки формируют клиентов покупающих продукт для использования на четырёх-восьми-ядерных системах и производительность для них важна, то конечно же надо положить на них всех — переделав усё на lock-free. Ты же хозяин-барин, что хочешь то и творишь.
CK>то что в многопоточке нужно использовать разные алгоритмы и примитивы синхронизации для большого и малого количества ядер — это поверхностное решение, которое может быть легче найти, но которое точно не является приемлемым (хотя смотря для кого) CK>сегодня у твоих клиентов 8 ядер, завтра 48, а через неделю 96
если всерьёз полагаешь, что переход от блокирующей многопоточности к вариантам lock-free является лишь изменением способа синхронизации, то разговаривать нам с тобой не о чем.
люди верующие в розовых пони и серебряную пулю априори больны душевно или же умственно неполноценны.
A>если всерьёз полагаешь, что переход от блокирующей многопоточности к вариантам lock-free является лишь изменением способа синхронизации, то разговаривать нам с тобой не о чем.
я так не считаю, возможно не очень понятно выразился
lock-free это вообще про гарантии и не имеет никакого отношения к масштабируемости, про которую ты заговорил
соответственно, дальше я обсуждал написание масштабируемого кода, что может быть сделано как с помощью правильно написанного блокирующего кода, так и неблокирующего
A>люди верующие в розовых пони и серебряную пулю априори больны душевно или же умственно неполноценны.
Здравствуйте, chaotic-kotik, Вы писали:
НС>>Так несложно, что до сих пор разве в CosmosDB это удалось сделать сносно. CK>dynamo paper в 2007-м году опубликовали CK>может ты что-то другое под этим имеешь ввиду, хз
Consistency: Most multi-master replication systems are only loosely consistent, i.e. lazy and asynchronous, violating ACID properties.
Performance: Eager replication systems are complex and increase communication latency.
Integrity: Issues such as conflict resolution can become intractable as the number of nodes involved rises and latency increases.
