10.02.2015 12:01, Alex Chistyakov пишет:
2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <[email protected]>:
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
[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
