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

Вт Фев 10 01:46:12 PST 2015

10.02.2015 12:01, Alex Chistyakov пишет:
> 2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>:
>> 10.02.2015 10:41, Alex Chistyakov пишет:
>>
>> Это утверждение вопиюще неверно.
>>
>> Ага так и поверил, где аргументы? И что собственно неверно?
>>
>> Значит, вот как мы теперь будем делать: один из нас напишет лютую
>> чушь, а второй ему на это укажет, первый попросит у второго аргументы.
>> То есть, чушь нести будет можно без аргументов - ну, это прекрасно же.
>>
>> Ну прекрасно  на вопрос "О чем это вы?" Вы говорите "А что вы вообще себе
>> позволяете!!!"
>> Вот и прекрасно поговорили.
> Стало быть - аргументов Вы не предоставите.
> Хорошо, тогда я их предоставлю.
> В данный момент в индустрии существует представление о том, что
> асинхронный код сложнее для понимания человеком, чем синхронный.
> Речь идет о понимании средним человеком, а не профессионалом, который
> два десятка лет на такие вещи смотрит.
> Вы сейчас можете, конечно, начать утверждать, что Вы и есть тот
> профессионал (да и все здесь), но я уже давно перестал верить в Деда
> Мороза и другие сказки.

Естественно что однопоточный синхронный код проще однопоточного 
асинхронного кода и
я с этим утверждением не оспаривал.
В контексте я сравнивал многопоточный синхронный и однопоточный 
асинхронный код.

С моей точки зрения всегда многопоточная модель сложнее чем любая 
однопоточная асинхронная.
1) С точки зрения отладки, а имено использования отладчика, а не 
использования print ...
однопоточные приложения сильно проще, потому легче понять когда у тебя 
один поток насилует одну структуру
чем когда 20  нитей одну структуру.
2) Вообще отладчики для многонитевых программ появились позже обычных
  (Про отладчик perl я вообще молчу (его съедобно запускать только в 
однопоточном режиме, кмк)
3) Программы в которых несколько потоков делают одну работу просто 
сложнее, чем там где
туже работу делает один поток, хотя бы из-за необходимости синхронизации.
Пример: перемножение матрицы.

4) Мой препод --- профессор всю жизнь занимался вычислительными методами 
на многопроцессорными системами и программировал на суперкомпьютерах,
так говорил и мне кажется ему можно верить.

Естественно, если потокам не нужно кооперироваться( нету общих данных), 
то разницы большой между однопоточной и многопоточной программой нет.

>
>> Во первых не все, и не всегда. Можно пользоваться redis и memcached и не
>> думать о базах данных.
>>
>> А у memcached внутри не MVCC? O_O
>>
>>
>> Скорее всего нет.
> Не "скорее всего нет", а "точно да".
А какой примитив системы отвечает за MVCC.
Можно реализовать memcached на основе мьютекса.
MVCC это оverkill для такой задачи.

>
>> MVCC(MultiVersion Concurrency Control)  это относится к базам данных и то не
>> ко всем.
> Когда я писал про STM, Вы это предпочли проигнорировать - это потому, 
> что Вы перловик? Вот веди я дискуссию, скажем, с лиспером, он бы 
> взглядом зацепился бы. Но еще не поздно - давайте все вернем, как 
> было, и Вы мне объясните, чем Вам STM не MVCC. 

Вы хотите сказать что при использовании STM издержек не больше, чем при 
использовании обычной памяти?
Или что Вы имели в виду?
И причем тут обсуждаемая тема?
Если про издержки, то  собственно стоимость блокировок и складывается из 
этих издержек в частности.

(зачем же обсуждать очевидные вещи, если они входят в тему, а с моей 
точки зрения не входят)

(Как бы я и на лиспе и scheme программирую еще разбавляю C, XS, Oracle, 
SmallTalk. Но зачем за все цепляться, жизни не хватит)

>> То написано ниже --- не понятно зачем это было написано, и к теме вообще не
>> относиться.
> Конечно, я уже понял - аргументов опять не будет.
>
> --
> 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
>>