Я написал в преамбуле, что это достаточно вольный перевод, я его делал исключительно для себя, любимого… до той степени, которая даёт мне понимание интересующих меня вопросов.
Сюда я его выкладываю а). на халяву и б). от доброты душевной… as is ;-)
У вас есть лучше перевод? Давайте его сюда.
Да, это было бы чрезвычайно интересно.
Даже не обязательно пригласить, а найти (указать URL) его публикаций, заметок, обсуждений.
Известная мне его заметка Scalable Go Scheduler Design Doc, Dmitry Vyukov
May 2, 2012
— это изложение ещё плана того, что и как хотелось бы реализовать, в сослагательном наклонении.
Возможно, кто-то найдёт возможным обратиться по мэйлу, указанному в этой заметке: dvyukov_AT_google.com
В принципе, существует даже перевод указанной вами статьи, вот для беглого просмотра: Производительность без цикла событий.
Только:
1. раз уже есть перевод той статьи, то зачем бы я делал перевод её ещё раз?… поэтому выбрана была другая статья (меня интересует внутренняя механика, а не уверения, что «всё очень хорошо»).
2. и почему та статья так уж «гораздо более детальная»? как на моё мнение (IMHO!) она как раз очень поверхностная, на уровне общих рассуждений и обещаний.
3. а если вы уж действительно хотите «гораздо более детальная» — то смотрите вот ту огромную и тяжёлую для восприятия статью, которую я показал в преамбуле к переводу.
А зачем здесь вообще preempt_enable_no_resched? Чем плох preempt_enable?
1. я написал, может, значит, недостаточно внятно, что я постарался максимально неприкосновенно сохранить код, так как он написан был в первоисточнике… у автора там preempt_enable_no_resched()
2.… но preempt_enable() столь же плох — в ядре >3.14 он порождает warning показанный в тексте
По поводу «опасности» трюков с CR0 я слышал десятки раз и в разных компаниях, поэтому это действительно стоит уточнения:
— речь о том, что в SMP между изменением CR0 и следующей записьж в защищённую область RAM может произойти перепланирование потока выполнения на другой процессор…
— … может…, но вероятность такого события примерно равна вероятности рождения сверхновой во Вселенной: если непрерывно развлекаться тем, что только загружать-выгружать модуль, то такое можно будет наблюдать… ну раз в 1000 лет… если кто доживёт
— но факт такой возможности настолько на виду, настолько это элементарно, что его сразу же указывают как только речь об этом заходит… т.е. говорится такое не для обсуждения предмета, а чтобы сказать «какой же я умный»… ну не могут разные люди слово в слово повторять эту элементарщину — это как пыанэр-зубрила, который руку тянет: «и я, и я, и я ...»
— и в чём выражается эта «опасность» если она и случится: операционную систему подвесите? вообще её инсталляцию снесёте? компьютер у вас задымится и выгорит ярким пламенем?… Нет, всего лишь не загрузится ваш собственный модуль с сообщением Оооps…
— и лечится это так же элементарно, как и объясняется: запрет прерываний на время записи на локальном процессоре на котором выполняется операция (и в коде приводимом это есть)…
— и давно это известно и описано… в этой вот, например, публикации: WP: Safe or Not? (на которую и ссылка показывалась где-то в предыдущей части… но это же читать надо!)
Я не могу понять смысл Go. Если мне нужен системный язык, я использую C/D/Rust. Если мне нужен язык с хорошей поддержкой параллелизма, то я использую Erlang или Haskell.
Параллелизм и конкурентность — очень разные вещи, когда вы переходите к SMP и истинной многопроцессорности.
Параллелизм Erlang или Haskell — кажущийся… логический, если хотите. Эффективное распараллеливание функциональных языков на мультипроцессоры — это больше теоретические изыски, чем практические достижения.
Главная фишка Go — эффективное использование многопроцессорной среды за счёт лёгких goroutine. Опыт (тестовые результаты) показывает, что они быстрее и эффективнее pthread_t языка C и POSIX.
Не говоря уже про Python и многие другие интерпретируемые языки, где параллельные ветви — это вообще только фикция, модель удобная для формализации и только… а реально они толкутся на одном процессоре только затрудняя выполнение.
(с) А.А.Галич
О-о-о-о… гопник косяком пошёл… из сельпо вырвался…
Проблема не в github и сурцах, юный друг, тексты пишутся не для для того, а для понимания — проблемы в мозгах… или в отсутствии оных у некоторых ;-)
Сюда я его выкладываю а). на халяву и б). от доброты душевной… as is ;-)
У вас есть лучше перевод? Давайте его сюда.
Даже не обязательно пригласить, а найти (указать URL) его публикаций, заметок, обсуждений.
Известная мне его заметка Scalable Go Scheduler Design Doc, Dmitry Vyukov
— это изложение ещё плана того, что и как хотелось бы реализовать, в сослагательном наклонении.
Возможно, кто-то найдёт возможным обратиться по мэйлу, указанному в этой заметке: dvyukov_AT_google.com
Только:
1. раз уже есть перевод той статьи, то зачем бы я делал перевод её ещё раз?… поэтому выбрана была другая статья (меня интересует внутренняя механика, а не уверения, что «всё очень хорошо»).
2. и почему та статья так уж «гораздо более детальная»? как на моё мнение (IMHO!) она как раз очень поверхностная, на уровне общих рассуждений и обещаний.
3. а если вы уж действительно хотите «гораздо более детальная» — то смотрите вот ту огромную и тяжёлую для восприятия статью, которую я показал в преамбуле к переводу.
если читателям так удобнее — добавлю и туда.
1. я написал, может, значит, недостаточно внятно, что я постарался максимально неприкосновенно сохранить код, так как он написан был в первоисточнике… у автора там preempt_enable_no_resched()
2.… но preempt_enable() столь же плох — в ядре >3.14 он порождает warning показанный в тексте
но я специально не размещал такие мизерные архивы на GitHub.
http://mylinuxprog.blogspot.com/2015/10/4.html
— речь о том, что в SMP между изменением CR0 и следующей записьж в защищённую область RAM может произойти перепланирование потока выполнения на другой процессор…
— … может…, но вероятность такого события примерно равна вероятности рождения сверхновой во Вселенной: если непрерывно развлекаться тем, что только загружать-выгружать модуль, то такое можно будет наблюдать… ну раз в 1000 лет… если кто доживёт
— но факт такой возможности настолько на виду, настолько это элементарно, что его сразу же указывают как только речь об этом заходит… т.е. говорится такое не для обсуждения предмета, а чтобы сказать «какой же я умный»… ну не могут разные люди слово в слово повторять эту элементарщину — это как пыанэр-зубрила, который руку тянет: «и я, и я, и я ...»
— и в чём выражается эта «опасность» если она и случится: операционную систему подвесите? вообще её инсталляцию снесёте? компьютер у вас задымится и выгорит ярким пламенем?… Нет, всего лишь не загрузится ваш собственный модуль с сообщением Оооps…
— и лечится это так же элементарно, как и объясняется: запрет прерываний на время записи на локальном процессоре на котором выполняется операция (и в коде приводимом это есть)…
— и давно это известно и описано… в этой вот, например, публикации: WP: Safe or Not? (на которую и ссылка показывалась где-то в предыдущей части… но это же читать надо!)
Н-да…
Как я понимаю, предметного обсуждения этой «опасности» мы не услышим…
От ваших ошибок… от кривых рук ;-)
Нука, нука… Определение — в студию.
Желательно со ссылкой на авторитетный источник.
ну так давайте обсудим чем же так «опасны»?
Ну и как? ;-)
А почему и как (?!) компилируемый в машинный код язык может стать «новой Java», которая требует интерпретации байт-кода в JVM?
… в WEB-программировании? ;-)
… или в этом… в DevOps-се? ;-) ;-)
(с) М.Жванецкий
Н-да… сильно я разрушил единомыслие и согласие в таком дружном семействе…
Ты глянь, как по минусам тыцкают! ;-)
Параллелизм и конкурентность — очень разные вещи, когда вы переходите к SMP и истинной многопроцессорности.
Параллелизм Erlang или Haskell — кажущийся… логический, если хотите. Эффективное распараллеливание функциональных языков на мультипроцессоры — это больше теоретические изыски, чем практические достижения.
Главная фишка Go — эффективное использование многопроцессорной среды за счёт лёгких goroutine.
Опыт (тестовые результаты) показывает, что они быстрее и эффективнее pthread_t языка C и POSIX.
Не говоря уже про Python и многие другие интерпретируемые языки, где параллельные ветви — это вообще только фикция, модель удобная для формализации и только… а реально они толкутся на одном процессоре только затрудняя выполнение.
не 3, а 6