2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <[email protected]>: > 10.02.2015 10:41, Alex Chistyakov пишет: > > Это утверждение вопиюще неверно. > > Ага так и поверил, где аргументы? И что собственно неверно? > > Значит, вот как мы теперь будем делать: один из нас напишет лютую > чушь, а второй ему на это укажет, первый попросит у второго аргументы. > То есть, чушь нести будет можно без аргументов - ну, это прекрасно же. > > Ну прекрасно на вопрос "О чем это вы?" Вы говорите "А что вы вообще себе > позволяете!!!" > Вот и прекрасно поговорили.
Стало быть - аргументов Вы не предоставите. Хорошо, тогда я их предоставлю. В данный момент в индустрии существует представление о том, что асинхронный код сложнее для понимания человеком, чем синхронный. Речь идет о понимании средним человеком, а не профессионалом, который два десятка лет на такие вещи смотрит. Вы сейчас можете, конечно, начать утверждать, что Вы и есть тот профессионал (да и все здесь), но я уже давно перестал верить в Деда Мороза и другие сказки. > > Во первых не все, и не всегда. Можно пользоваться redis и memcached и не > думать о базах данных. > > А у memcached внутри не MVCC? O_O > > > Скорее всего нет. Не "скорее всего нет", а "точно да". > > MVCC(MultiVersion Concurrency Control) это относится к базам данных и то не > ко всем. Я знаю, к чему это относится. У memcached внутри мультиверсионность, это совершенно точно. > И к сожалению к языкам программирования к async,threads, сустемному > программированию не относиться ни одним боком. Когда я писал про STM, Вы это предпочли проигнорировать - это потому, что Вы перловик? Вот веди я дискуссию, скажем, с лиспером, он бы взглядом зацепился бы. Но еще не поздно - давайте все вернем, как было, и Вы мне объясните, чем Вам STM не MVCC. > То написано ниже --- не понятно зачем это было написано, и к теме вообще не > относиться. Конечно, я уже понял - аргументов опять не будет. -- SY, Alex > > > > > > А иногда бывает полезно иметь общий пул данных > > Так вот, те, кто работают с базами данных, знают слова вроде > "оптимистичная блокировка", "MVCC". > Есть еще такая вещь, как STM. > > Опять не все, и не всегда. > > Да я уже понял, что не все и не всегда. > > Даже если блокировка самая быстрая, это не значит что на неё не используются > ресурсы процессора вообще. > > Где я это утверждал? > > А поход в базу данных это совсем не дешевая альтернатива. > > Где я говорил, что это альтернатива? > > 100-200 циклов процессора минимум на одном примитиве. > > compare-and-swap это 100-200 циклов процессора минимум? > Но на что? O_O > > А вы читали Intel Design Manual для IE-32 и IE-64? > > А Вы читали Orange Book? > > А про POSIX ? А про > примитивы синхронизации, как они устроены? > > Да не - ну куда мне? > > А про spin lock, что вам известно? > > А какая связь между spinlock и CAS? > > Почитайте, погуглите. > Может оказаться, что на CAS 100-200 циклов и уходит. > > Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели? > У Вас что, профайлер в это место в коде показал, или что? > Или Вам жалко эти 100-200 циклов? > Ну вот же все на поверхности лежит: > http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive > Какие спинлоки, какой позикс, какой интел дизайн? > Где факты, где основания, где показания профайлера? > А то то, что для одного expensive, для другого может быть не expensive > - тут вон учаснеги на динамически типизированном языке годами пишут, и > норм им. > > А одной блокировкой как правило, дело обычно не заканчивается. > > > -- > SY, > Alex > > > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. > > > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > > > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org > -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
