[Moscow.pm] Темы для докладов

[Alex Chistyakov]

2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>:
> 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
> moscow-pm на pm.org | http://moscow.pm.org
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>
>
>
> --
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
>