API tools faq
paste
Guest User

https://www.linux.org.ru/forum/development/13512175

a guest
Jul 15th, 2017
156
0
Never
Add comment
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 127.61 KB | None | 0 0
raw download clone embed print report
  1.  
  2. LINUX.ORG.RU
  3.  
  4. добро пожаловать, www_linux_org_ru
  5. Новости
  6. Галерея
  7. Форум
  8. Трекер
  9. Уведомления (5)
  10. Поиск
  11.  
  12. Форум — Development
  13. Потоки в Julia: зелёные или нормальные?
  14.  
  15. greenshit, julia, pthreads, threads
  16.  
  17. 2
  18.  
  19. 5
  20.  
  21. Собственно, весь вопрос в заголовке: из официальной документации непонятно, являются ли экспериментально реализованные потоки в языке julia настоящими или же это очередная кооперативная фикция, зелёная и в пупырышках. Просто если последнее, то я даже смотреть в сторону этой фигни не стану (в Julia отлично реализовано взаимодействие форкнутых процессов), если же процессы основаны на pthreads или чём-то подобном, то это круто и весьма интересно.
  22. DRVTiny ★★★★★
  23. 29.06.2017 15:04:57
  24.  
  25. Ответить на это сообщение Ссылка
  26.  
  27.  
  28. ← Гарантированно асинхронная запись в Linux?
  29. Срочно требуется Мейнтейнер deb-based дистрибутива Linux (за хорошую оплату). →
  30.  
  31. настоящими или же это очередная кооперативная фикция, зелёная и в пупырышках.
  32.  
  33. Что плохого в green threads?
  34. hateyoufeel ★★★★ (29.06.2017 16:44:31)
  35.  
  36. Ответить на это сообщение Ссылка
  37.  
  38. блин, а наплодить 100500 потоков и тупо в top посмотреть не? Где дух исследователя, вашу мать?
  39. anonymous (29.06.2017 16:53:22)
  40.  
  41. Ответить на это сообщение Ссылка
  42.  
  43. Ответ на: комментарий от hateyoufeel 29.06.2017 16:44:31
  44.  
  45. Если N (>1) физических потоков обсуживают M логических, то всё хорошо. Если N всегда равно 1, тогда проблемы со скалируемостью.
  46. anonymous (29.06.2017 17:00:00)
  47.  
  48. Ответить на это сообщение Ссылка
  49.  
  50. Ответ на: комментарий от anonymous 29.06.2017 17:00:00
  51.  
  52. Ну так это не зелёные потоки виноваты, а отсутствие поддержки SMP.
  53. hateyoufeel ★★★★ (29.06.2017 17:00:52)
  54.  
  55. Ответить на это сообщение Ссылка
  56.  
  57. Ответ на: комментарий от hateyoufeel 29.06.2017 16:44:31
  58.  
  59. Green threads - говно, потому что не используют многоядерную архитектуру процессора в 10-е годы 21-го века.
  60.  
  61. Ещё вопросы?
  62. DRVTiny ★★★★★ (29.06.2017 17:05:45)
  63. Последнее исправление: DRVTiny 29.06.2017 17:06:38 (всего исправлений: 1)
  64.  
  65. Ответить на это сообщение Ссылка
  66.  
  67. Ответ на: комментарий от DRVTiny 29.06.2017 17:05:45
  68.  
  69. Green threads - говно, потому что не используют многоядерную архитектуру процессора в 10-е годы 21-го века.
  70.  
  71. Green threads и SMP — довольно ортогональные понятия. Некоторые языки/платформы умеют и то и другое одновременно (Haskell, JVM, Erlang, C++ с Boost Fibers), другие — что-то одно (Python, Ruby).
  72. hateyoufeel ★★★★ (29.06.2017 17:09:32)
  73.  
  74. Ответить на это сообщение Ссылка
  75.  
  76. Ответ на: комментарий от anonymous 29.06.2017 17:00:00
  77.  
  78. Главная проблема одна - это не параллелизм. Да, всё равно при обращении к памяти или при любом конкурентном IO придётся выстраиваться в цепочку, параллелизм не бывает абсолютным. Но запуск приложения с кучей в действительности последовательно выполняемых «кагбе потоков» - это всегда путь к проблемам «упс, меня застряло» - в форточках это выглядело как курсор-«часики», которые крутились и крутились, и даже не думали «отвисать», а помогал в таких случаях чаще всего Ctrl+Alt+Delete.
  79. DRVTiny ★★★★★ (29.06.2017 17:15:37)
  80.  
  81. Ответить на это сообщение Ссылка
  82.  
  83. Ответ на: комментарий от DRVTiny 29.06.2017 17:15:37
  84.  
  85. то всегда путь к проблемам «упс, меня застряло»
  86.  
  87. Каким образом обычные треды спасают от дедлоков?
  88. RazrFalcon ★★ (29.06.2017 17:22:00)
  89.  
  90. Ответить на это сообщение Ссылка
  91.  
  92. Ответ на: комментарий от DRVTiny 29.06.2017 17:15:37
  93.  
  94. Да, всё равно при обращении к памяти или при любом конкурентном IO придётся выстраиваться в цепочку, параллелизм не бывает абсолютным.
  95.  
  96. Для тебя, наверное, это окажется сюрпризом, но треды ОС от этого тоже страдают.
  97. hateyoufeel ★★★★ (29.06.2017 17:22:49)
  98.  
  99. Ответить на это сообщение Ссылка
  100.  
  101. Ответ на: комментарий от DRVTiny 29.06.2017 17:15:37
  102.  
  103. Почему зеленые потоки не могут исполняться параллельно на разных ядрах? Ты уверен?
  104. dave ★★★★★ (29.06.2017 17:45:43)
  105.  
  106. Ответить на это сообщение Ссылка
  107.  
  108. Ответ на: комментарий от dave 29.06.2017 17:45:43
  109.  
  110. Потому что им нужны общие данные, поскольку вообще 99% смысла потоков - в том, чтобы легко шарить данные.
  111.  
  112. Как предполагается шарить данные между этими псевдопотоками, если они работают в рамках разных задач (процессов, если хотите)? Абсолютное большинство современных языков настолько абстрактны и настолько «платформонезависимы», что про shared memory они «не знаю - не слышали», остаются всякие каналы, которые практически везде есть. Но через каналы данные копируются, а не шарятся, вот в чём беда-то ;)
  113. DRVTiny ★★★★★ (29.06.2017 17:53:27)
  114. Последнее исправление: DRVTiny 29.06.2017 17:53:54 (всего исправлений: 1)
  115.  
  116. Ответить на это сообщение Ссылка
  117.  
  118. Ответ на: комментарий от hateyoufeel 29.06.2017 17:22:49
  119.  
  120. Если почитаете внимательно - я о настоящих тредах и говорил: а именно о том, что даже потоки, исполняющиеся на разных ядрах процессора, только при очень грамотно продуманной архитектуре не будут мешаться друг у друга под ногами, постоянно синхронизируясь явным и неявным образом. Но «кооперативные потоки» создают куда более дерьмовую проблему: если один из них наглухо виснет - остальные просто не выполняются. Например, подход python в духе «20 инструкций этого потока, потом 20 - другого» - хорош тольк тогда, когда 20 инструкций одного потока выполняются примерно столько же, сколько и 20 другого, а ещё есть данная Высшими Силами абсолютная гарантия того, что одна из 20-ти инструкций не приведёт к подвисанию потока на пару минуточек.
  121. DRVTiny ★★★★★ (29.06.2017 17:58:39)
  122.  
  123. Ответить на это сообщение Ссылка
  124.  
  125. Ответ на: комментарий от DRVTiny 29.06.2017 17:58:39
  126.  
  127. Но «кооперативные потоки» создают куда более дерьмовую проблему: если один из них наглухо виснет - остальные просто не выполняются.
  128.  
  129. Это верно только в довольно убогих реализация типа того же питона.
  130. hateyoufeel ★★★★ (29.06.2017 18:03:27)
  131.  
  132. Ответить на это сообщение Ссылка
  133.  
  134. Ответ на: комментарий от RazrFalcon 29.06.2017 17:22:00
  135.  
  136. Каким образом обычные треды спасают от дедлоков?
  137.  
  138. Тут разве про дедлок. Как я понимаю зеленый поток это как кооперативная многозадачность, т.е. в зеленом потоке нужно явно вызывать на исполнение другой поток, не? Т.е. некий wait и так должно быть во всех используемых I/O библиотеках иначе никакого конкаренси работать не будет.
  139. Aber (29.06.2017 18:05:26)
  140.  
  141. Ответить на это сообщение Ссылка
  142.  
  143. Ответ на: комментарий от Aber 29.06.2017 18:05:26
  144.  
  145. в зеленом потоке нужно явно вызывать на исполнение другой поток, не?
  146.  
  147. Только в C/C++.
  148. hateyoufeel ★★★★ (29.06.2017 18:06:10)
  149.  
  150. Ответить на это сообщение Ссылка
  151.  
  152. Ответ на: комментарий от hateyoufeel 29.06.2017 17:09:32
  153.  
  154. Green threads и SMP — довольно ортогональные понятия. Некоторые языки/платформы умеют и то и другое одновременно ... JVM ...
  155.  
  156. Помню читал, что java 1.0 умела только green threads, я думал что нативные потоки заменили их совсем. Но green threads как идея в принципе вернулись в виде неблокирующего I/O.
  157. Aber (29.06.2017 18:20:20)
  158.  
  159. Ответить на это сообщение Ссылка
  160.  
  161. а почему у анонiмуса теперь 5 звезд и пишет он почти по человечески?
  162. qnikst ★★★★★ (29.06.2017 18:26:16)
  163.  
  164. Ответить на это сообщение Ссылка
  165.  
  166. Ответ на: комментарий от DRVTiny 29.06.2017 17:05:45
  167.  
  168. Да, есть вопрос, почему ты выдаешь ложь за правду?
  169.  
  170. Green threads поддерживают N:M mapping в нормальных языках.
  171. qnikst ★★★★★ (29.06.2017 18:27:31)
  172.  
  173. Ответить на это сообщение Ссылка
  174.  
  175. Ответ на: комментарий от DRVTiny 29.06.2017 17:15:37
  176.  
  177. posix треды не решают ни одну из этих проблем. То, что ты пишешь про форточки абсолютно иррелевантно к green тредам.
  178.  
  179. Может тебе статей накидать, может хоть полезное что почитаешь?
  180. qnikst ★★★★★ (29.06.2017 18:28:58)
  181.  
  182. Ответить на это сообщение Ссылка
  183.  
  184. Ответ на: комментарий от qnikst 29.06.2017 18:28:58
  185.  
  186. поговорил с анонiмусом..
  187. qnikst ★★★★★ (29.06.2017 18:30:11)
  188.  
  189. Ответить на это сообщение Ссылка
  190.  
  191. Ответ на: комментарий от Aber 29.06.2017 18:05:26
  192.  
  193. Я хз, что ТС подразумевает под «застряло».
  194.  
  195. Я ноль в гринтредах, но наезжать на них только из-за того, что они не такие как в сишке, как минимум странно.
  196. RazrFalcon ★★ (29.06.2017 18:42:38)
  197.  
  198. Ответить на это сообщение Ссылка
  199.  
  200. Ответ на: комментарий от RazrFalcon 29.06.2017 18:42:38
  201.  
  202. Гринтред - это просто очередное «красивое» абстрактное слово. Реализованы везде по-разному, а вся суть сводится к тому же, что делает Coro в Perl (кстати, там это не догадались назвать «зелёными потоками») : N процедур выполняются поочерёдно: немного кода одной процедуры, потом немного когда другой, потом немного третьей. Где-то выполнение прерывается не извне, а прямо в коде процедуры явным образом передаётся управление следующей.
  203.  
  204. Нужны гринтреды для того, чтобы абстрагироваться от бренного мира, а на самом деле для того, чтобы проще было писать компиляторы и не заморачиваться нативными тредами на разных платформах. Разработчики успешно сами себе находят оправдания - LLVM им нужен, чтобы под разные платформы не писать компиляторы (раньше компилировали в Сишный код, теперь стал модным LLVM), гринтреды - чтобы не заморачиваться с системным программированием под целевые платформы.
  205.  
  206. А в конечном итоге всё это нужно для того, чтобы больше людей могли создавать больше языков программирования. Огромный профит же от изобилия языков, каждый из которых в равной мере не умеет использовать возможности процессоров. Процессоры уже 10-ть лет развиваются по пути горизонтального масштабирования, наращивая количество ядер каждый год, а языки программирования переизобрели кооперативную многозадачность, которая, казалось бы, протухла ещё в начале 90-х годов.
  207. DRVTiny ★★★★★ (29.06.2017 19:07:27)
  208.  
  209. Ответить на это сообщение Ссылка
  210.  
  211. Ответ на: комментарий от qnikst 29.06.2017 18:27:31
  212.  
  213. Чувак, мне жаль, но ты пропустил все лекции по операционным системам и сразу, ничего не читая, принялся писать. Сходи подучись сначала, а потом приходи с новыми полезными знаниями.
  214.  
  215. И да, прекрати уже писать так, словно ты тупая блондинка в аське, несолидно.
  216. DRVTiny ★★★★★ (29.06.2017 19:09:55)
  217.  
  218. Ответить на это сообщение Ссылка
  219.  
  220. Ответ на: комментарий от Aber 29.06.2017 18:20:20
  221.  
  222. Всё верно, только насколько я знаю - «зелёные потоки» как раз наоборот родились из идеи асинхронного (в общем случае - событийного) программирования. Зелёные потоки - вырожденный случай, когда событие - внутреннее и формулируется примерно как «ой, надо бы переключиться на следующий кагбепоток». Триггером события выступают довольно странные вещи типа «эта процедура выполнила свои 20 инструкций - надо переключаться» или «эта процедура выполнила yield, какое счастье, уже таки можно переключаться».
  223. DRVTiny ★★★★★ (29.06.2017 19:14:40)
  224.  
  225. Ответить на это сообщение Ссылка
  226.  
  227. Ответ на: комментарий от hateyoufeel 29.06.2017 18:03:27
  228.  
  229. В любом случае, даже если эти «кагбе потоки» реализованы где-то лучше, чем в Питоне, в абсолютном большинстве случаев, за исключением разве что Golang'а, их «призвание» - это сделать потоки платформонезависимыми и вообще ни от чего независимыми, а по сути и не потоками вовсе.
  230. DRVTiny ★★★★★ (29.06.2017 19:18:18)
  231.  
  232. Ответить на это сообщение Ссылка
  233.  
  234. Ответ на: комментарий от DRVTiny 29.06.2017 19:09:55
  235.  
  236. Вообще-то не я.
  237. qnikst ★★★★★ (29.06.2017 19:35:50)
  238.  
  239. Ответить на это сообщение Ссылка
  240.  
  241. Ответ на: комментарий от DRVTiny 29.06.2017 19:14:40
  242.  
  243. вообще-то поток проработал свою порцию времени и находится в safepoint или поток остановился на получении результата асинхронного IO, ну прям как в OS тредах, только контекст свич отличается на пару порядков.
  244. qnikst ★★★★★ (29.06.2017 19:40:52)
  245.  
  246. Ответить на это сообщение Ссылка
  247.  
  248. Ответ на: комментарий от qnikst 29.06.2017 19:40:52
  249.  
  250. вот например, как это сделано в ghc RTS http://simonmar.github.io/bib/papers/conc-substrate.pdf
  251.  
  252. и далее по ссылкам.
  253. qnikst ★★★★★ (29.06.2017 19:43:15)
  254.  
  255. Ответить на это сообщение Ссылка
  256.  
  257. Ответ на: комментарий от qnikst 29.06.2017 19:40:52
  258.  
  259. интересно, а как из документации на https://docs.julialang.org/en/stable/manual/parallel-computing/ можно не получить ответ на вопрос /0, там черным по белому что количество воркеров задаётся опциями ком строки и фиксировано и как происходит шедулинг.
  260.  
  261. или тред не для ответа на этот вопрос был, а про лёгкие потоки пообщаться?
  262. qnikst ★★★★★ (29.06.2017 20:01:13)
  263. Последнее исправление: qnikst 29.06.2017 20:03:04 (всего исправлений: 1)
  264.  
  265. Ответить на это сообщение Ссылка
  266.  
  267. Ответ на: комментарий от DRVTiny 29.06.2017 19:18:18
  268.  
  269. в абсолютном большинстве случаев, за исключением разве что Golang'а, их «призвание» - это сделать потоки платформонезависимыми и вообще ни от чего независимыми, а по сути и не потоками вовсе.
  270.  
  271. Мальчик, ты баклажан. В большинстве случаев green threads сделаны ради упрощения кода, чтобы можно было не писать асинхронную лапшу а-ля node.js или поллинг как в C, а обычных дубовый синхронный код и вместе с тем обрабатывать большое количество событий. В сочетании с развитым IO-менеджером green threads ведут к крайне низким накладным расходам в обмен на сильное упрощение кода. Ты можешь писать такой же код на обычных тредах, но у них накладные расходы на переключение контекста намного выше, поэтому так мало кто делает.
  272. hateyoufeel ★★★★ (29.06.2017 20:22:43)
  273.  
  274. Ответить на это сообщение Ссылка
  275.  
  276. Ответ на: комментарий от qnikst 29.06.2017 20:01:13
  277.  
  278. Лично я там нашел только упоминание количества ядер процессора, что не говорит ни о чём по сути. Если бы там хоть слово было о том, как именно реализовано, какой либой - я бы не задал этот вопрос.
  279.  
  280. Насчёт контекст свитчей - когда они делаются в рамках одного процесса, вся эта карусельная внутренняя кухня гринтредов начинает работать только после того как процесс получит свой квант времени. Этот шедуллинг процесса внутри шедуллинга ядра - это какой-то противоесиественный путь самоограничения, слово бы из скромности: не использовать больше квантов времени, стесняться занять дополнительные ядра cpu. Зачем?
  281. DRVTiny ★★★★★ (29.06.2017 20:23:50)
  282.  
  283. Ответить на это сообщение Ссылка
  284.  
  285. Ответ на: комментарий от DRVTiny 29.06.2017 17:53:27
  286.  
  287. Да вопрос был скорее риторический. Просто хочу сказать, что при правильной реализации зеленые потоки не имеют тех недостатков, что ты им приписываешь (питон к этому списку не относится). Они вполне работают параллельно сразу на нескольких ядрах процессоров. Это уже реальность.
  288.  
  289. Так скорее проблема, как правильно не вызвать ненароком блокирующий метод. В Haskell она решается, и для этого было сделано очень много. Используются неблокирующие операции IO по возможности.
  290.  
  291. У зеленых потоков есть, конечно, слабые места, но они немного другие, как я себе представляю
  292. dave ★★★★★ (29.06.2017 20:24:03)
  293.  
  294. Ответить на это сообщение Ссылка
  295.  
  296. Ответ на: комментарий от DRVTiny 29.06.2017 19:07:27
  297.  
  298. Разработчики успешно сами себе находят оправдания - LLVM им нужен, чтобы под разные платформы не писать компиляторы
  299.  
  300. Удивительно было бы если бы все рвались писать свои кодогенераторы под все платформы.
  301.  
  302. раньше компилировали в Сишный код, теперь стал модным LLVM
  303.  
  304. LLVM налагает гораздо меньше ограничений на модель выполнения кода и позволяет писать свои плагины с оптимизациями и прочими ништяками. Как минимум этим он выигрывает у C в качестве бэкенда для компиляции.
  305.  
  306. гринтреды - чтобы не заморачиваться с системным программированием под целевые платформы.
  307.  
  308. Особенно если учесть, что из целевых платформ сейчас большинством поддерживаются только pthreads (и то не весь зоопарк реализаций) и венда. Отличная гипотеза! Браво!
  309. hateyoufeel ★★★★ (29.06.2017 20:27:04)
  310.  
  311. Ответить на это сообщение Ссылка
  312.  
  313. Ответ на: комментарий от dave 29.06.2017 20:24:03
  314.  
  315. Если «зелёные потоки» выполняются на разных ядрах процессоров - значит, они не «зелёные», потому кто кроме ядра ОС назначить потоку выполнения ядро не может никто, а ОС про что-то там «зелёное» ничего близко не знает, для неё это просто процесс, не более того. Другое дело, что сам процесс может создать реальные потоки внутри себя и уже их поделить на «зелёные» - тогда да, эти «кагбепотоки» могут работать на разных ядрах, поскольку нормальные нативные потоки работают на разных ядрах.
  316.  
  317. Против такой реализации ничего не имею, но языки, которые вообще не осиливают pthreads, и при этом в документации рассказывают что-то про поддержку потоков - меня слегка бесят. Именно по той самой причине, о которой я сказал в самом начале: это не параллелизм, это какая-то имитация бурной деятельности.
  318. DRVTiny ★★★★★ (29.06.2017 20:40:56)
  319.  
  320. Ответить на это сообщение Ссылка
  321.  
  322. Ответ на: комментарий от DRVTiny 29.06.2017 20:23:50
  323.  
  324. В вопросе есть ложная дихотомия, нормально реализованные грин треды занимают все ядра, у них n рабочих OS процессов, и их количество советуют делать по количеству ядер (как в Джулии). В общем это на 80% даёт ответ, но если читать далее, то в разделе про шедулинг написано, что таски это корутины, и дальше дано пояснение, цитирую: Tasks (aka Coroutines)
  325.  
  326. Tasks are a control flow feature that allows computations to be suspended and resumed in a flexible manner. This feature is sometimes called by other names, such as symmetric coroutines, lightweight threads, cooperative multitasking, or one-shot continuations
  327.  
  328. вроде тут однозначно.
  329.  
  330. я попытаюсь написать более взвешенный и длинный коммент про гринтреды еще
  331. qnikst ★★★★★ (29.06.2017 20:48:11)
  332.  
  333. Ответить на это сообщение Ссылка
  334.  
  335. Ответ на: комментарий от hateyoufeel 29.06.2017 20:27:04
  336.  
  337. Особенно если учесть, что из целевых платформ сейчас большинством поддерживаются только pthreads (и то не весь зоопарк реализаций) и венда.
  338.  
  339. Cocoa NSThread? Не слышали?
  340.  
  341. Ну и да, почему-то весьма немало софтверных компаний пытается клепать мультиплатформенное ПО там, где это в эпоху тотальной виртуализации уже даром не нужно.
  342.  
  343. У разработчиков же, в том числе и у разработчиков ЯП, вообще какая-то фобия разработки под определённую платформу: дескать, «если я буду хорошо понимать, как это работает в Linux, но плохо понимать - как работает в Windows, то стану менее востребованным на рынке. Лучше я буду оперировать абстрактными понятиями в полном вакууме - и буду одинаково класть болт на все платформы, под которыми работает мой софт, потому что так оно спокойнее»
  344. DRVTiny ★★★★★ (29.06.2017 20:48:34)
  345.  
  346. Ответить на это сообщение Ссылка
  347.  
  348. Ответ на: комментарий от DRVTiny 29.06.2017 20:40:56
  349.  
  350. Грин треды не про parallelism, они про concurrency. Если кто-то ожидает, что в параллельных задачах generic реализация гринтреды даст ощутимые плюсы (за исключением случаев нерегулярного общения, извиняюсь за самоизобретенный термин, то он делает это зря)
  351. qnikst ★★★★★ (29.06.2017 20:50:19)
  352.  
  353. Ответить на это сообщение Ссылка
  354.  
  355. Ответ на: комментарий от qnikst 29.06.2017 20:50:19
  356.  
  357. за исключением случаев нерегулярного общения
  358.  
  359. в этом случае они эвквивалентны event loop
  360. annulen ★★★★★ (29.06.2017 20:51:55)
  361.  
  362. Ответить на это сообщение Ссылка
  363.  
  364. Ответ на: комментарий от qnikst 29.06.2017 20:48:11
  365.  
  366. А насчёт затрат на переключение контекста - почему вдруг они выше с вашей точки зрения?
  367.  
  368. Если без учёта блокировок IO (предположим, все потоки просто выполняют долгоиграющие вычисления) контекст переключался, условно, 1 раз в 20 мс, то он так и будет переключаться раз в 20 мс, что здесь можно сэкономить.
  369.  
  370. Переключение контекста из 0-го кольца защиты в 3-е и обратно - не самая приятная задача конечно, но использование таймера как основного источника событий переключения не позволяет как-то гибко жонглировать количеством этих переключений в единицу времени.
  371. DRVTiny ★★★★★ (29.06.2017 20:54:33)
  372.  
  373. Ответить на это сообщение Ссылка
  374.  
  375. Ответ на: комментарий от DRVTiny 29.06.2017 20:48:34
  376.  
  377. Cocoa NSThread? Не слышали?
  378.  
  379. Но зачем, когда pthreads поддерживаются нативно?
  380.  
  381. WebKit на макоси использует pthreads, если бы у NSThread были хоть какие-то преимущества то полюбому бы их использовали
  382. annulen ★★★★★ (29.06.2017 20:55:45)
  383.  
  384. Ответить на это сообщение Ссылка
  385.  
  386. Ответ на: комментарий от qnikst 29.06.2017 20:50:19
  387.  
  388. Запилил крохотный пример с тредами на Julia - на первом же @printf оно вывалилось в Segfault. Вот теперь охотно верю в то, что потоки «честные», pthread'овые. Так бы они сразу и сказали в документации, а то всё больше намёками вокруг, да около.
  389. DRVTiny ★★★★★ (29.06.2017 20:58:30)
  390.  
  391. Ответить на это сообщение Ссылка
  392.  
  393. Ответ на: комментарий от DRVTiny 29.06.2017 20:58:30
  394.  
  395. я не умею делать такие выводы.. честно не вижу связи в segfault и модели выполнения
  396. qnikst ★★★★★ (29.06.2017 21:01:12)
  397.  
  398. Ответить на это сообщение Ссылка
  399.  
  400. Ответ на: комментарий от qnikst 29.06.2017 20:50:19
  401.  
  402. Раз ты тут оказался по случаю. Ты в курсе, что у вас reconnect не всегда работает? Хотя да, видел у вас issue. Собираетесь исправлять?)
  403.  
  404. Кстати, могу подкатить тест на основе своего кода полностью по BSD3
  405. dave ★★★★★ (29.06.2017 21:01:37)
  406.  
  407. Ответить на это сообщение Ссылка
  408.  
  409. Ответ на: комментарий от qnikst 29.06.2017 20:48:11
  410.  
  411. В вопросе есть ложная дихотомия, нормально реализованные грин треды занимают все ядра, у них n рабочих OS процессов
  412.  
  413. Не понимаю. Совсем. Есть потоки исполнения, давайте говорить о них. Потоки исполнения в рамках одного процесса просто разделяют данные, таблицы страниц ОЗУ, у них один и тот же TSS.
  414.  
  415. Так вот, для того, чтобы «зелёные потоки» заняли несколько ядер - они должны работать в разных настоящих потоках исполнения pthreads. А после этого они уже, на мой взгляд, перестают быть таким уж зелёными, разве нет?
  416. DRVTiny ★★★★★ (29.06.2017 21:04:27)
  417.  
  418. Ответить на это сообщение Ссылка
  419.  
  420. Ответ на: комментарий от qnikst 29.06.2017 21:01:12
  421.  
  422. Связь прямая: нижележащий код вывода на экран не является thread-safe. В рамках простого переключения кусков кода в одном потоке исполнения (кагбетредов), как это делает тот же python, никаких проблем с printf'ом бы не было, будь он хоть сколько угодно не safe.
  423. DRVTiny ★★★★★ (29.06.2017 21:06:44)
  424. Последнее исправление: DRVTiny 29.06.2017 21:07:05 (всего исправлений: 1)
  425.  
  426. Ответить на это сообщение Ссылка
  427.  
  428. Ответ на: комментарий от DRVTiny 29.06.2017 20:58:30
  429.  
  430. pthreads не обязан создавать «честный» os thread (и не создаёт на некоторых os). Это бы только запутывало.
  431. anonymous (29.06.2017 21:11:19)
  432.  
  433. Ответить на это сообщение Ссылка
  434.  
  435. Ответ на: комментарий от DRVTiny 29.06.2017 21:04:27
  436.  
  437. А как вы такие потоки называете? Синими?
  438. anonymous (29.06.2017 21:15:47)
  439.  
  440. Ответить на это сообщение Ссылка
  441.  
  442. Ответ на: комментарий от annulen 29.06.2017 20:51:55
  443.  
  444. они и так человеческий вариант написания event loop.
  445. qnikst ★★★★★ (29.06.2017 21:18:05)
  446.  
  447. Ответить на это сообщение Ссылка
  448.  
  449. Отвечаю полность. Сразу извиняюсь, что писал про aнонiмуса, просто он любит делать вбросы в очень похожем стиле. Теперь к потокам:
  450.  
  451. 1. Есть разные варианты маппинга грин тредов на реальные 1:1, N:1, N:M, все толковые языки реализуют N:M, причем OS треды могут быть разными в зависимости от нижележащей OS.
  452.  
  453. 2. Да грин треды это не паралелизм, это concurrency, в том случае когда нужно сделать много разной работы при этом зачастую IO, а не CPU bound. В случае если просто параллелизм, то нету большого смысла делать больше рабочих процессов, чем ядер, все равно ось магию не совершит, а так хоть меньше переходов будет.
  454.  
  455. 3. Соответсвенно в большинстве случаев грин треды это человеческое лицо к poll-интерфейсу, когда вместо лапши из колбеков/корутин пишется человеко-понятный код.
  456.  
  457. 4. Несмотря на то, что green треды это про конкаренси, помочь параллелизму они тоже могут
  458.  
  459. 5.
  460.  
  461. Как предполагается шарить данные между этими псевдопотоками, если они работают в рамках разных задач (процессов, если хотите).
  462.  
  463. green треды работают в рамках одного процесса, но могут выполняться в разных тредах, я не понимаю, в чем проблема с шареньем данных (если это не erlang).
  464.  
  465. 6. да в грин тредах кооперативная многозадачность, но обычно задача переключения ложится на RTS. Делать можно по разному, например, в haskell передача управления происходит в safe points (аллокации), если истек таймер, или если тред «заблочился», на операции (для тредов многие операции выглядят блокируемыми), в связи с этим есть фишка в невозможности переключения процесса, который ничего не аллоцирует (с другой стороны компилятор сейчас умеет это решать).
  466.  
  467. 7. Shared memory ортогонально потокам, и выполнению в разных тредах. Вопрос к библиотеке языка, все здоровые языки умеют (во всяком случае в библиотеках)
  468.  
  469. 8.Грин треды не абстракция над OS тредами.
  470.  
  471. 9. Когда ядро делает context switch, то ему нужно сделать много больше, сохранить/восстановить значения регистров, настроить страницы виртуальной памяти и т.п. По сравнению с программой, внутри которой переключение почти бесплатно. Так же каждый OS поток ест больше ресурсов системы, память записи в структуры данных и т.п. ~1000ns против 10?
  472.  
  473. 10. С другой стороны RTS будет обязательно вносить свой оверхед и для задач, где надо тупо считать, а потом обменяться данными это может быть абсолютно бесполезно
  474. qnikst ★★★★★ (29.06.2017 21:21:46)
  475.  
  476. Ответить на это сообщение Ссылка
  477.  
  478. Ответ на: комментарий от qnikst 29.06.2017 21:01:12
  479.  
  480. Кстати, https://docs.julialang.org/en/stable/manual/parallel-computing/
  481.  
  482. - звучит на удивление разумно. Редко в документации к ЯП можно увидеть что-то подобное. Особенно про эксклюзивный доступ ядра процессора к «своей» области памяти здорово написано.
  483. DRVTiny ★★★★★ (29.06.2017 21:22:49)
  484.  
  485. Ответить на это сообщение Ссылка
  486.  
  487. Ответ на: комментарий от DRVTiny 29.06.2017 21:04:27
  488.  
  489. Так вот, для того, чтобы «зелёные потоки» заняли несколько ядер - они должны работать в разных настоящих потоках исполнения pthreads. А после этого они уже, на мой взгляд, перестают быть таким уж зелёными, разве нет?
  490.  
  491. Представь, у тебя задача 200 миллисекунд ждёт данных из сокета или файлового дескриптора, 100 миллисекунд обрабатывает полученное и ещё 200 миллисекунд его выводит в другой сокет или дескриптор. Сколько тебе ядер нужно серверу для непрерывной обработки пяти потоков данных?
  492. anonymous (29.06.2017 21:25:52)
  493.  
  494. Ответить на это сообщение Ссылка
  495.  
  496. Ответ на: комментарий от DRVTiny 29.06.2017 21:04:27
  497.  
  498. Нет, не перестают. Давайте с другой стороны, может проще будет - есть green thread, у него есть свой мелкий стек, код, который выполняется id внутри программы и OS про него ничего не знает. Программист пишет код в этой абстракции.
  499.  
  500. Все что ему гарантируется, что эти потоки будут «как-то» выполняться, при том, так что специфика выполнения не влияет на результат, в идеале ещё fairness guarantee - то что поток, когда-нибудь выполнится, + гарантия (с какими-то оговорками), что другие green треды не влияют на поведение данного.
  501.  
  502. Все, тут вообще нету никаких других утверждений и то, как выполнять код является целиком и полностью делом системы выполнения.
  503.  
  504. Существуют 3 большие стратегии выполнения:
  505.  
  506. * 1:1 - один green тред маппим на 1 OS тред - это очень простая но ресурсоёмкая стратегия, дающая хорошие гарантии; но так обычно никто не делает * N:1 - N green тредов на 1 OS тред - то про что пишешь ты * N:M - N green тредов на M OS тредов, где N много больше M (обычно M = числу CPU). Это достаточно сложно пишется, там возникает много вопросов про то, как балансировать треды, как правильно делать foreign вызовы. Но все же многие языки делают эту модель.
  507.  
  508. Независимо от выбора стратегии зеленые треды останутся зелеными.
  509.  
  510. Например, ghc haskell, про который я тут люблю говорить умеет N:1 модель (non-threaded RTS) и N:M модель. Если я правильно кинул ссылку, то в статье что я кинул описываются детали релизации N:M модели, может быть интересно почитать на досуге.
  511. qnikst ★★★★★ (29.06.2017 21:30:34)
  512.  
  513. Ответить на это сообщение Ссылка
  514.  
  515. Ответ на: комментарий от DRVTiny 29.06.2017 21:06:44
  516.  
  517. как-то неожиданно, мне лень ставить и копаться в джулии, в других языках с N:M стратегией выполнения легких потоков проблем нету, функции вывода на экран работают прекрасно и ни о чем думать не надо, даже если поток перекинут в другой тред.
  518. qnikst ★★★★★ (29.06.2017 21:34:43)
  519.  
  520. Ответить на это сообщение Ссылка
  521.  
  522. Ответ на: комментарий от qnikst 29.06.2017 21:21:46
  523.  
  524. Замечания :)
  525.  
  526. По 9-му пункту - вытесняющая многозадачность предполагает переключение контекста по таймеру. Таким образом, что мы сэкономим на гринтредах, если переключение просто N раз секаунду? Я когда собирал тогда ещё ядра Linux 2.4, а потом первые 2.6 - можно было прямо в конфигурилке задавать частоту переключений: для десктопов повыше, для серверов пониже.
  527.  
  528. По 8-му - да, не абстракция, но существуют-то они внутри OS тредов, которые «вытесняемые потоки исполнения».
  529.  
  530. По 6-му пункту - если гринтреды в разных реальных/вытесняемых потоках исполнения, то они вообще никак друг с другом не соприкасаются, их, получается, переключают разные «внутриязыковые» планировщики?
  531.  
  532. Относительно N*M - я понял, что речь идёт именно о вытесняемых потоках исполнения N и M зелёных потоков. Просто исходно речь вроде шла об N процессах - и меня это конечно удивило (мне ли не знать, насколько геморно реализованы nix'овые IPC, например).
  533. DRVTiny ★★★★★ (29.06.2017 21:38:00)
  534. Последнее исправление: DRVTiny 29.06.2017 21:40:05 (всего исправлений: 1)
  535.  
  536. Ответить на это сообщение Ссылка
  537.  
  538. Ответ на: комментарий от qnikst 29.06.2017 21:34:43
  539.  
  540. Как-то неожиданно, мне лень ставить и копаться в джулии, в других языках с N:M стратегией выполнения легких потоков проблем нету,
  541.  
  542. Исходно printf из Glibc, насколько я помню, не thread-safe, так что ничего удивительного нет...
  543. DRVTiny ★★★★★ (29.06.2017 21:39:43)
  544.  
  545. Ответить на это сообщение Ссылка
  546.  
  547. Ответ на: комментарий от DRVTiny 29.06.2017 21:39:43
  548.  
  549. For an explanation of the terms used in this section, see attributes(7).
  550.  
  551. ┌────────────────────────┬───────────────┬────────────────┐
  552. │Interface │ Attribute │ Value │
  553. ├────────────────────────┼───────────────┼────────────────┤
  554. │printf(), fprintf(), │ Thread safety │ MT-Safe locale │
  555. │sprintf(), snprintf(), │ │ │
  556. │vprintf(), vfprintf(), │ │ │
  557. │vsprintf(), vsnprintf() │ │ │
  558. └────────────────────────┴───────────────┴────────────────┘
  559.  
  560. мой man говорит так, но я могу его неверно интерпретировать
  561. qnikst ★★★★★ (29.06.2017 21:42:30)
  562.  
  563. Ответить на это сообщение Ссылка
  564.  
  565. Ответ на: комментарий от DRVTiny 29.06.2017 21:38:00
  566.  
  567. 9. Переключение дороже в 100 раз даже на модных процессорах, стек грин треда 2-16kb начальный, posix_thread 8Mb, но тюнится, так? Вообще когда хочется сказать что green треды это плохо, можно green треды заменить на epoll с не фиксированными callback-ами (я знаю что говорить callback тут не правильно, но вы ведь поняли). Т.к. если юзер может добавлять новые fd (и события для таймера, на которых ждать) и что выполнять, когда это произойдет. Вот это грин треды и есть.
  568.  
  569. На самом деле RTS решает много связанных вопросов, о которых думать не надо.
  570.  
  571. 8. Я не вижу проблем в шедулере внутри шедулера, более того я вижу смысл от самописанного шедулера, внутри языка с легкими потоками. Это может быть полезно когда нужно реализовывать разные стратегии планировки, которые зависят от задачи, например FIFO для IO bound и FILO для CPU bound тредов.
  572.  
  573. 6. да их переключают/(синхронизуют если нужно для GC) внутриязыковые планировщики.
  574.  
  575. Если я где-то сказал N процессов, то я сделал это зря. Если честно я нигде не видел того, чтобы раскидывали на процессы, и не представляю зачем это может быть нужно. Можно erlang к такому отнести и ему подобные решения, но это все равно не то.
  576. qnikst ★★★★★ (29.06.2017 21:50:40)
  577.  
  578. Ответить на это сообщение Ссылка
  579.  
  580. Ответ на: комментарий от qnikst 29.06.2017 21:50:40
  581.  
  582. UPD. знаю, для языков со stop the world GC могут быть бонусы от разнесения по разным процессам.
  583. qnikst ★★★★★ (29.06.2017 21:53:07)
  584.  
  585. Ответить на это сообщение Ссылка
  586.  
  587. Ответ на: комментарий от qnikst 29.06.2017 21:42:30
  588.  
  589. Нет, всё верно, значит всё-таки Thread-safe. Забавно, что код, не выполняющий print в любом виде, выполняется многопоточно без проблем.
  590. DRVTiny ★★★★★ (29.06.2017 21:53:46)
  591.  
  592. Ответить на это сообщение Ссылка
  593.  
  594. Ответ на: комментарий от DRVTiny 29.06.2017 19:07:27
  595.  
  596. С вашей логикой нужно вообще подальше от IT держаться.
  597. RazrFalcon ★★ (29.06.2017 22:11:50)
  598.  
  599. Ответить на это сообщение Ссылка
  600.  
  601. Ответ на: комментарий от DRVTiny 29.06.2017 17:53:27
  602.  
  603. вообще 99% смысла потоков - в том, чтобы легко шарить данные.
  604.  
  605. в моде вроде имутабельность, не?
  606. Rastafarra ★★★ (30.06.2017 6:59:32)
  607.  
  608. Ответить на это сообщение Ссылка
  609.  
  610. Ответ на: комментарий от DRVTiny 29.06.2017 20:40:56
  611.  
  612. Именно по той самой причине, о которой я сказал в самом начале: это не параллелизм, это какая-то имитация бурной деятельности.
  613.  
  614. Потому что многопоточность - это многопоточность, параллелизм - это параллелизм.
  615. anonymous (30.06.2017 11:24:03)
  616.  
  617. Ответить на это сообщение Ссылка
  618.  
  619. Ответ на: комментарий от DRVTiny 29.06.2017 17:58:39
  620.  
  621. Например, подход python в духе «20 инструкций этого потока, потом 20 - другого» - хорош тольк тогда, когда 20 инструкций одного потока выполняются примерно столько же, сколько и 20 другого, а ещё есть данная Высшими Силами абсолютная гарантия того, что одна из 20-ти инструкций не приведёт к подвисанию потока на пару минуточек.
  622.  
  623. Потому что GIL надо отпускать! Или вам сказали что в питоне всё так просто, что справится любой идиот, и вы поверили?
  624. anonymous (30.06.2017 11:26:36)
  625.  
  626. Ответить на это сообщение Ссылка
  627.  
  628. Ответ на: комментарий от anonymous 30.06.2017 11:24:03
  629.  
  630. Многопоточность - это либо параллелизм, либо псевдопаралеллизм, и нужна в любом случае для параллельного выполнения заданий. А уж для чего они выполняются параллельно (даже если и псевдо-) - дело десятое. «Многопоточность» в полном вакууме не существует. Я понимаю любовь программистов к придумываемым ими же словечкам, но не нужно голову-то терять.
  631. DRVTiny ★★★★★ (30.06.2017 13:00:06)
  632.  
  633. Ответить на это сообщение Ссылка
  634.  
  635. Ответ на: комментарий от DRVTiny 30.06.2017 13:00:06
  636.  
  637. anonymous под многопоточностью понимает concurrency. Есть 2 well established слова *concurrency* и *parallelism*, на русский переводящиеся, как «параллельные вычисления», хотя термины разные и оно не является «псевдо-другим».
  638. qnikst ★★★★★ (30.06.2017 15:00:01)
  639.  
  640. Ответить на это сообщение Ссылка
  641.  
  642. Ответ на: комментарий от qnikst 29.06.2017 21:50:40
  643.  
  644. Ну вот объясни мне, уважаемый эксперт, почему вы настолько экспертны? Ваша экспертность резанула мне глаз даже при пролистывания темы «по диагонали».
  645.  
  646. Переключение дороже в 100 раз даже на модных процессорах
  647.  
  648. Не верно. Никакое переключение не дороже, да и его там нет. Ваши представление о мире осталось за гранью реальности - на обочине истории, а именно примерно в районе 95года, а может даже раньше.
  649.  
  650. Гринтреды го нихрена не быстрее птредов. Я советую, всё же, соотносить свои «познания» с реальностью, а не маркетинговым булшитом ориентированным на терминально лсных домохозяек.
  651.  
  652. posix_thread 8Mb, но тюнится, так?
  653.  
  654. Та же самая проблема. Эти 8мб никакого отношения к тем мегабайтам, о которых ты подумал, не имеют.
  655.  
  656. Я не вижу проблем в шедулере внутри шедулера, более того я вижу смысл от самописанного шедулера, внутри языка с легкими потоками. Это может быть полезно когда нужно реализовывать разные стратегии планировки, которые зависят от задачи, например FIFO для IO bound и FILO для CPU bound тредов.
  657.  
  658. А можно узнать - зачем нужны эти «грин»-«треды»?
  659. saifuluk (01.07.2017 0:19:28)
  660.  
  661. Ответить на это сообщение Ссылка
  662.  
  663. Ответ на: комментарий от saifuluk 01.07.2017 0:19:28
  664.  
  665. цифры, бенчмаркинг статьи, развернутые комментарии, если ты вообще хочешь, чтобы твоё мнение было интересно. Пока ты неотличим от низкоуровневого тролля.
  666. qnikst ★★★★★ (01.07.2017 6:03:02)
  667.  
  668. Ответить на это сообщение Ссылка
  669.  
  670. Ответ на: комментарий от qnikst 01.07.2017 6:03:02
  671.  
  672. цифры, бенчмаркинг статьи
  673.  
  674. В том и проблема, что твои представления о мире заканчивают на маркетинговых днищестатьях для домохозяек.
  675.  
  676. При этом меня удивляет то, что ты пруфцевать не должен, а я должен? При этом ты никак не попытался защитить свою ТЗ и опровергнуть мою, а из этого следует лишь одно - ты ретранслятор.
  677.  
  678. Если бы ты знал почему там 8мб - ты мне доказал, что я неправ. Но ты не смог. И причину я уже назвал.
  679.  
  680. Писать и доказывать каждому ламерку что-то мне лень. Твои ответы для любого вменяемого человека уже показательны, а вернее определяют тебя за ноль.
  681.  
  682. А по поводу бенчмарков: https://habrahabr.ru/post/306768/#comment_9725810
  683.  
  684. 100500 тредов запускается? Каждый по 8 метров. И того в районе терабайта по памяти, если считать по твои выкладкам, что явно несоответствует реальности.
  685.  
  686. Так же и с производительностью самих тредов.
  687.  
  688. Как же я люблю вас, экспертов. Прочитал какую-то херню в каком-то днищебложике и уже решил, что он эксперт и может кому-то что-то ретранслировать. Это так не работает.
  689. saifuluk (01.07.2017 17:44:24)
  690.  
  691. Ответить на это сообщение Ссылка
  692.  
  693. Ответ на: комментарий от saifuluk 01.07.2017 17:44:24
  694.  
  695. А по поводу бенчмарков: https://habrahabr.ru/post/306768/#comment_9725810
  696.  
  697. Для начала — автор комментария по ссылке даже не в курсе, отчего он упёрся в лимит в 30к потоков. Ну вот даже не подозревает и узнать не хочет. Это забавно.
  698.  
  699. А так вариант на Go отрабатывает у меня за 0m0,113s, тогда как вариант с pthread — за 0m0,727s. В обоих случаях брал максимальное время. Если брать среднее, то выходит 0,05 секунд против 0,65. И вариант с реальными тредами сегфолтится от раза к разу, ибо дефолтные лимиты я не увеличивал.
  700. i-rinat ★★★★★ (01.07.2017 18:00:12)
  701.  
  702. Ответить на это сообщение Ссылка
  703.  
  704. Сообщение удалено merhalak по причине Уже написали (0)
  705. Ответ на: комментарий от DRVTiny 29.06.2017 21:04:27
  706.  
  707. Нет. Считай там внутренний планировщик может присутствовать, который разбрасывает «зеленые» по системным. Зелеными они быть не перестают, просто работают поверх не одного системного, а пула системных.
  708. merhalak ★★★ (01.07.2017 19:16:22)
  709. Ответ на: комментарий от DRVTiny 29.06.2017 17:53:27
  710.  
  711. Копируют потому, что на шареные нужно ставить блокировки, и прощай параллелизм.
  712. anonymous (01.07.2017 19:22:27)
  713.  
  714. Ответить на это сообщение Ссылка
  715.  
  716. Ответ на: комментарий от qnikst 01.07.2017 6:03:02
  717.  
  718. низкоуровневого тролля
  719.  
  720. DirectTroll12®
  721. anonymous (01.07.2017 19:28:08)
  722.  
  723. Ответить на это сообщение Ссылка
  724.  
  725. Ответ на: комментарий от DRVTiny 29.06.2017 20:54:33
  726.  
  727. В современном линуксе тик шедулера отключается, если на ядре проца один поток.
  728. anonymous (01.07.2017 19:34:36)
  729.  
  730. Ответить на это сообщение Ссылка
  731.  
  732. Ответ на: комментарий от i-rinat 01.07.2017 18:00:12
  733.  
  734. Для начала — автор комментария по ссылке даже не в курсе, отчего он упёрся в лимит в 30к потоков. Ну вот даже не подозревает и узнать не хочет. Это забавно.
  735.  
  736. Я смотрел код ведра, считал эти дефайны и на какой-то итерации я понял, что ограничение это ограничено чисто шизофренией и мне это стало не интересно. Если ты думаешь, что какой-то нулёвый алёша в чём-то может разобраться лучше меня - у меня для тебя плохие новости.
  737.  
  738. Никакого харварного ограничения нет, а читать и угадывать почему кто-то запилил так, как ему захотелось - мне неинтересно.
  739.  
  740. Точно так же мне не интересна и эта бесполезная задача запуска более 30к тредов. Я доказал, что го-адепты балаболы. Доказал. Остальное меня волнует мало.
  741.  
  742. Если брать среднее, то выходит 0,05 секунд
  743.  
  744. Врёшь. https://pastebin.com/cPUYxKDs
  745.  
  746. По поводу всего остального. Из твоего ответа ничего не слеудет. Запущено больше рама/8мб? Больше. Разница не в 100раз? Не в сто. Разницу ты намерил в 6.
  747. saifuluk (01.07.2017 20:06:00)
  748.  
  749. Ответить на это сообщение Ссылка
  750.  
  751. Ответ на: комментарий от saifuluk 01.07.2017 20:06:00
  752.  
  753. разобраться лучше меня
  754.  
  755. Да кто угодно разбирается в этом лучше тебя. Нет в ядре жёсткой границы в 30к нитей. У меня в системе, например, лимит по умолчанию установлен в десять с чем-то тысяч. Но это легко поднимается, и 100500 нитей легко создаются.
  756.  
  757. Врёшь. https://pastebin.com/cPUYxKDs
  758.  
  759. Ой. Да ты просто туповат.
  760. i-rinat ★★★★★ (01.07.2017 20:33:13)
  761.  
  762. Ответить на это сообщение Ссылка
  763.  
  764. Ответ на: комментарий от i-rinat 01.07.2017 20:33:13
  765.  
  766. Да кто угодно разбирается в этом лучше тебя. Нет в ядре жёсткой границы в 30к нитей. У меня в системе, например, лимит по умолчанию установлен в десять с чем-то тысяч. Но это легко поднимается, и 100500 нитей легко создаются.
  767.  
  768. Поподробнее об этом. Как мне запустить 100500 нитей?
  769.  
  770. Ой. Да ты просто туповат.
  771.  
  772. Действительно.
  773. saifuluk (01.07.2017 21:12:49)
  774.  
  775. Ответить на это сообщение Ссылка
  776.  
  777. Ответ на: комментарий от saifuluk 01.07.2017 21:12:49
  778.  
  779. Как мне запустить 100500 нитей?
  780.  
  781. Обычно ограничено число процессов, число нитей, число открытых файлов и число mmap областей. Ещё в случае с systemd есть ограничения на число pid в cgroup. Все эти лимиты нужно увеличить.
  782. i-rinat ★★★★★ (01.07.2017 21:49:09)
  783.  
  784. Ответить на это сообщение Ссылка
  785.  
  786. Ответ на: комментарий от i-rinat 01.07.2017 21:49:09
  787.  
  788. Обычно ограничено число процессов, число нитей, число открытых файлов и число mmap областей.
  789.  
  790. Всё это стоит выше ляма. макстред( не ставится выше 100к с копейкой). Неработает. На всё это я выходил. Всё это я увеличивал. Как и говорил - я вышел на ограничение в ведре - уже не помню что он там считал, толи раму, толи вм, но в любом случае там именно что упиралось в захардкоренное значение.
  791. saifuluk (01.07.2017 22:46:55)
  792.  
  793. Ответить на это сообщение Ссылка
  794.  
  795. Ответ на: комментарий от saifuluk 01.07.2017 22:46:55
  796.  
  797. там именно что упиралось в захардкоренное значение
  798.  
  799. Не видел такого. У меня увеличивается без проблем.
  800. i-rinat ★★★★★ (01.07.2017 22:55:46)
  801.  
  802. Ответить на это сообщение Ссылка
  803.  
  804. Ответ на: комментарий от i-rinat 01.07.2017 22:55:46
  805.  
  806. В таком варианте, работает?
  807.  
  808. int main() {
  809. std::atomic<size_t> c{0};
  810. size_t n = 100500;
  811.  
  812. for(size_t i = 0; i < n; ++i) std::thread{[&](){
  813. ++c;
  814. sleep(10);
  815. }}.detach();
  816. while(c < n) {}
  817. fprintf(stderr, "%lu\n", (size_t)c);
  818. }
  819.  
  820. а n = 150000?
  821.  
  822. Может в системд какая проблема - у меня раньше его не было. Но я никакие лимиты в нём не ставил. Поищу потом.
  823. saifuluk (01.07.2017 23:05:03)
  824.  
  825. Ответить на это сообщение Ссылка
  826.  
  827. Ответ на: комментарий от saifuluk 01.07.2017 23:05:03
  828.  
  829. а n = 150000?
  830.  
  831. В 125 тыщ с копейками упирается. Выяснилось, что в ядре не даёт установить лимит на число нитей выше определённого значения, так чтобы занимаемый ими объём не превышал одной восьмой от доступного ОЗУ. Ставишь больше памяти — получаешь больше нитей.
  832. i-rinat ★★★★★ (01.07.2017 23:46:47)
  833.  
  834. Ответить на это сообщение Ссылка
  835.  
  836. Ответ на: комментарий от i-rinat 01.07.2017 23:46:47
  837.  
  838. Ну, собственно, это я и находил тогда. Действительно - вспомнил, что зависело от кол-ва памяти. А ты обвинял меня, подлец, в том, что я не разбирался. Фу таким быть.
  839.  
  840. Ну сейчас у меня падает совсем на копейках - значит это подлое системд меня где-то подставило.
  841. saifuluk (02.07.2017 0:10:05)
  842.  
  843. Ответить на это сообщение Ссылка
  844.  
  845. Ответ на: комментарий от saifuluk 02.07.2017 0:10:05
  846.  
  847. что я не разбирался
  848.  
  849. Ну ты же не разобрался. Оно ведь ищется легко и обходится без особых проблем.
  850.  
  851. Но ты только подумай — миллион нитей сожрут как минимум 16 гигов. Но ты эти гигабайты не увидишь.
  852. i-rinat ★★★★★ (02.07.2017 0:28:04)
  853. Последнее исправление: i-rinat 02.07.2017 0:28:16 (всего исправлений: 1)
  854.  
  855. Ответить на это сообщение Ссылка
  856.  
  857. Ответ на: комментарий от DRVTiny 29.06.2017 21:04:27
  858.  
  859. Не понимаю. Совсем. Есть потоки исполнения, давайте говорить о них. Потоки исполнения в рамках одного процесса просто разделяют данные, таблицы страниц ОЗУ, у них один и тот же TSS.
  860. Так вот, для того, чтобы «зелёные потоки» заняли несколько ядер - они должны работать в разных настоящих потоках исполнения pthreads. А после этого они уже, на мой взгляд, перестают быть таким уж зелёными, разве нет?
  861.  
  862. У тебя есть 6 ядер. Только для тебя. Повесь на них 6 потоков и context switch не произойдет никогда. Но у тебя 12 задач. И ты вешаешь 2 задачи на одно ядро – получаешь 1 context switch на каждое ядро на шаг работы программы. Но 6 твоих задач могут быть «зелеными» – они могут безопастно засыпать и просыпаться в любой момент. Тогда ты выделяешь (например*) 3 ядра для «классических» потоков и 3 ядра для «зеленых» и получаешь в два раза меньше context switch'ей.
  863.  
  864. *в реальности надо бенчить что даст максимальный перфоманс.
  865. Stil ★★★★★ (02.07.2017 1:59:23)
  866.  
  867. Ответить на это сообщение Ссылка
  868.  
  869. Ответ на: комментарий от i-rinat 02.07.2017 0:28:04
  870.  
  871. Ну ты же не разобрался. Оно ведь ищется легко и обходится без особых проблем.
  872.  
  873. Обходится что?
  874.  
  875. Ты мне предлагаешь вот это обойти: https://code.woboq.org/linux/linux/kernel/fork.c.html#427
  876.  
  877. Но ты только подумай — миллион нитей сожрут как минимум 16 гигов. Но ты эти гигабайты не увидишь.
  878.  
  879. Сколько они сожрут в го? Это всего менее 20к на нить + стек. Хотя я, конечно, не понимаю нахрена ядру целых 20к на нить, но что поделать.
  880. saifuluk (02.07.2017 2:53:39)
  881.  
  882. Ответить на это сообщение Ссылка
  883.  
  884. Ответ на: комментарий от saifuluk 02.07.2017 2:53:39
  885.  
  886. Ты мне предлагаешь вот это обойти
  887.  
  888. Для экспериментов — можно. Для продакшена столько нитей использовать — идиотизм. Больше 200–300 уже будут доставлять проблемы. man c10k problem.
  889.  
  890. Сколько они сожрут в го?
  891.  
  892. Спроси у специалистов по Go. Но я сомневаюсь, что там много. Это не эмуляция фиберов для обычного Си-кода, там нет нужды выделять стек и переключаться на него. По сути, это эквивалент кода на колбеках в Си, только без боли.
  893.  
  894. Хотя я, конечно, не понимаю нахрена ядру целых 20к на нить
  895.  
  896. Тут тебе нужно почитать про то, что такое нити в Linux и чем они отличаются от процессов.
  897. i-rinat ★★★★★ (02.07.2017 12:40:28)
  898. Последнее исправление: i-rinat 02.07.2017 12:40:54 (всего исправлений: 1)
  899.  
  900. Ответить на это сообщение Ссылка
  901.  
  902. Ответ на: комментарий от Stil 02.07.2017 1:59:23
  903.  
  904. и получаешь в два раза меньше context switch'ей.
  905.  
  906. Плюс сбросы кеша при одновременном доступе разных потоков, работающих с одной и той же страницей памяти.
  907. anonymous (02.07.2017 13:19:59)
  908.  
  909. Ответить на это сообщение Ссылка
  910.  
  911. Ответ на: комментарий от i-rinat 02.07.2017 12:40:28
  912.  
  913. Для экспериментов — можно. Для продакшена столько нитей использовать — идиотизм. Больше 200–300 уже будут доставлять проблемы.
  914.  
  915. Не будут.
  916.  
  917. man c10k problem.
  918.  
  919. Это убогий мусор для развода ламерков и строчения статеек на помойках, который протух и не актуален уже десять лет. Как и рассуждения про «медленные сисколы», «медленные треды», «8мегабайт на тред + тачка виснет уже на 20» и прочий мусор.
  920.  
  921. Я тут уже много подобных экспертов-жертв протухшей макулатуры видел. Одни мне доказывали, что спринтф+мусор будут быстрее open+openat, другие что на 50тредах загнётся. В конечном итоге все они из треда почему-то улетали.
  922.  
  923. Спроси у специалистов по Go. Но я сомневаюсь, что там много. Это не эмуляция фиберов для обычного Си-кода, там нет нужды выделять стек и переключаться на него.
  924.  
  925. Это 20к не включая стэк. Да и вроде сравниваем мы гринтреды( т.е. юзерспейс треды) и обычные( кернелспейс). И там и там должен быть стек.
  926.  
  927. Смысл треда в том, чтобы можно было его стопнуть в любом месте. Естественно, на самом деле треды не нужны и всё делается в 10раз быстрее и лучше без них. Но это никого не волнует. Сравнивалось то, что сравнивалось.
  928.  
  929. Тут тебе нужно почитать про то, что такое нити в Linux и чем они отличаются от процессов.
  930.  
  931. Я не об этом. Это мне никак не поможет и ничего мне не даст. Естественно если оно память жрёт, то оно там что-то хранит. А что конкретно оно там хранится - меня волнует мало. Из нужного там контекст на максиму 1к + ну максимум 2-3к. Остальное всё - это заморочки ведра, которые к делу отношения не имеют.
  932.  
  933. Первый тык: https://code.woboq.org/data/symbol.html?root=../linux/&ref=task_struct
  934.  
  935. А тут уже -3к на ненужную отладочную фигню бам, а там ещё нума-хренума, а там ещё битмаска на 500+ ненужных цпу. Всякие цгрупы и прочее.
  936.  
  937. Смысл моего вопроса заключается в том, что я не вижу того, что можно было запихнуть в этом тред, из вещей напрямую относящихся к треду. Я их не вижу - их и нету. А засунуть туда можно всё что угодно.
  938. saifuluk (02.07.2017 20:49:23)
  939.  
  940. Ответить на это сообщение Ссылка
  941.  
  942. Ответ на: комментарий от saifuluk 02.07.2017 20:49:23
  943.  
  944. В конечном итоге все они из треда почему-то улетали.
  945.  
  946. Ну давай сделай веб-сервер по принципу одно соединение — один тред. Посмотрим, сколько он выдаст и когда он загнётся. Сравниваем с nginx. Или ты сразу из треда улетаешь? ^_^
  947.  
  948. сравниваем мы гринтреды( т.е. юзерспейс треды) и обычные( кернелспейс) <...> И там и там должен быть стек.
  949.  
  950. Лолшто? Зачем?
  951.  
  952. Из нужного там контекст на максиму 1к + ну максимум 2-3к.
  953.  
  954. Ух-ты. Ни малейшего представления о том, что там хранится, и при этом полное нежелание выяснять. Но точно знает, сколько места хватит для хранения неизвестного набора данных. Волшебник, прям.
  955. i-rinat ★★★★★ (02.07.2017 21:21:12)
  956.  
  957. Ответить на это сообщение Ссылка
  958.  
  959. Ответ на: комментарий от i-rinat 02.07.2017 21:21:12
  960.  
  961. Ну давай сделай веб-сервер по принципу одно соединение — один тред. Посмотрим, сколько он выдаст и когда он загнётся. Сравниваем с nginx. Или ты сразу из треда улетаешь? ^_^
  962.  
  963. Пошла херня опять. То он болтает про «man c10k problem», то как только поплыл уже начинает сливаться на «сделай быстрее нгинкса». c10k - это про 10к коннектов, а не про нгинкс. Работоспособность 10к тредов доказана? Доказана. Вылетел? Вылетел.
  964.  
  965. Ах ну и да, вебсервер не нужен. Нгинкс - это пускалка пхп. Пхп это пускалка ворпресса. Вордпресс больше 50рпс не выдаёт. 50тредов за глаза хватит.
  966.  
  967. Лолшто? Зачем?
  968.  
  969. Я написал. Для того, чтобы мочь стопнуть его в любой момент. И вообще стопнуть.
  970.  
  971. Ух-ты. Ни малейшего представления о том, что там хранится, и при этом полное нежелание выяснять.
  972.  
  973. Опять болтаешь херню. То, что там хранится никакого отношения к теме не имеет. То, что хранится в линуксе - это отдельная реализация и напихать в неё можно всё что угодно. Но к тому, что это хранимое необходимо для работы тредов вообще это отношения не имеет.
  974.  
  975. Ты можешь попытаться взять ту структуруку и попытаться обосновать необходимость каких-то полей в контексте не линукса и вылетить из треда.
  976.  
  977. Я тебе даю задачу - каким образом цгрупс связан с тредами? И нахрена он нужен? А он не нужен. Точно так же я тебе привёл пример с CONFIG_LOCKDEP, которйы нахрен не упёрлся тредам.
  978.  
  979. Ты ни на один вопрос не ответил и причина проста - вылетишь из треда в момент.
  980.  
  981. saifuluk (02.07.2017 21:52:48)
  982.  
  983. Ответить на это сообщение Ссылка
  984.  
  985. Ответ на: комментарий от saifuluk 02.07.2017 21:52:48
  986.  
  987. c10k - это про 10к коннектов, а не про нгинкс. Работоспособность 10к тредов доказана? Доказана. Вылетел? Вылетел.
  988.  
  989. Вот ты и слился. Как языком молоть, так крутой. А на простенькой задаче лапки поднял и что-то там про работоспособность мямлит. Нет, пока не покажешь рабочий пример, ты просто балабол.
  990.  
  991. Нгинкс - это пускалка пхп.
  992.  
  993. Какую же ты чушь пишешь.
  994.  
  995. Я написал. Для того, чтобы мочь стопнуть его в любой момент. И вообще стопнуть.
  996.  
  997. Ты придумал что-то своё и теперь споришь. Какой смысл спора, если ты витаешь в каком-то своём мире и с общепринятыми понятиями не пересекаешься?
  998.  
  999. Я тебе даю задачу
  1000.  
  1001. Сервер сначала напиши. Ишь чего о себе возомнил.
  1002.  
  1003. вылетишь из треда в момент.
  1004.  
  1005. Если ты не осилишь базовые вещи сначала освоить, то таки да, смысла с тобой разговаривать больше нет. Можешь считать, что я «вылетел из треда». Порадуйся там, что ли. Победитель, все дела. :-)
  1006. i-rinat ★★★★★ (02.07.2017 23:23:56)
  1007.  
  1008. Ответить на это сообщение Ссылка
  1009.  
  1010. Ответ на: комментарий от i-rinat 02.07.2017 21:21:12
  1011.  
  1012. Мне всегда по наивности и незнанию казалось, что стек нужен для вызова функций: конечно разные треды не могут использовать один и тот же стек при вызове функций, по этой самой причине у каждого треда он свой. Собственно, стек при вызове функций тоже не сильно нужен, ведь можно передавать параметры через регистры, но есть одна засада, которую не обойдёшь никак: в стек отправляется адрес смещения в сегменте cs, на который нужно будет вернуться инструкцией ret (можно и «вручную» сделать то же, что делает ret). Хотя я лично всеми оставшимися конечностями за то, чтобы передавать параметры в регистрах процессора, в том числе и указатели на области памяти в сегментах данных, что в общем случае нарушает ключевую концепцию функциональщины (результат работы функции определяется только её входными параметрами, у функции не должно быть побочных эффектов).
  1013. DRVTiny ★★★★★ (03.07.2017 14:03:49)
  1014.  
  1015. Ответить на это сообщение Ссылка
  1016.  
  1017. Ответ на: комментарий от saifuluk 02.07.2017 20:49:23
  1018.  
  1019. Смысл треда в том, чтобы можно было его стопнуть в любом месте.
  1020.  
  1021. В стране торгашей, занимающихся уёб-комерцией - да.
  1022.  
  1023. А так вообще смысл тредов в организации параллельных вычислений. Есть ещё всякие неведомые штуки типа MPI, которые позволяют организовать распределённые вычисления, но всё это в СР не нужно, да. У нас только веб-серверы, реклама и массовые перепродажи дешёвого китайского дерьма. Обслужить (читай - на*бать) больше тупоголовых потребл*дских хомячков в единицу времени - вот предел мечтаний отчественного бузинеса. И тут конечно IO страшно всё тормозит, самая критичная задача - обойти треклятое IO на повороте, а не использовать максимальное число циклов CPU в единицу времени.
  1024.  
  1025. У СР один верный путь - в СГ. Это давно известно, нам всем туда, так что давайте идти туда дружно.
  1026. DRVTiny ★★★★★ (03.07.2017 14:10:33)
  1027. Последнее исправление: DRVTiny 03.07.2017 14:11:09 (всего исправлений: 1)
  1028.  
  1029. Ответить на это сообщение Ссылка
  1030.  
  1031. Ответ на: комментарий от DRVTiny 03.07.2017 14:03:49
  1032.  
  1033. То, что ты пишешь — в каком-то смысле верно. Если хочется сделать сопрограммы, которые могут использоваться в Си-программах, без стека не обойтись. И существующие реализации сопрограмм переключают стек.
  1034.  
  1035. Но если у тебя другой язык, требование «настоящего» стека пропадает. Ведь на самом деле тебе нужен не стек, а контекст задачи. И тут уже переключать стек не нужно. Можно, например, неявно передавать указатель на структуру в каждую функцию.
  1036. i-rinat ★★★★★ (03.07.2017 14:16:28)
  1037.  
  1038. Ответить на это сообщение Ссылка
  1039.  
  1040. Ответ на: комментарий от Stil 02.07.2017 1:59:23
  1041.  
  1042. получаешь 1 context switch на каждое ядро на шаг работы программы.
  1043.  
  1044. Что ещё за шаг работы программы?
  1045.  
  1046. Мне кажется или со вчерашнего дня принудительное переключение потоков исполнения по самому обычному таймеру уже отменили? Теперь ОС знает тайны того кода, который внутри неё работает - и даже про некие «шаги работы» осведомлена.
  1047.  
  1048. Т.е. не просто по тику таймера планировщик ядра, отобравший управление у предыдущего потока исполнения принимает решение о переключении на следующий в соответствии с заданной стратегией планирования (которую, AFAIK, можно менять прямо во время работы ОС) - а что-то такое вообще магическое происходит с шагами. Где почитать об этом?
  1049. DRVTiny ★★★★★ (03.07.2017 14:17:17)
  1050.  
  1051. Ответить на это сообщение Ссылка
  1052.  
  1053. Ответ на: комментарий от i-rinat 03.07.2017 14:16:28
  1054.  
  1055. Какой бы ни был язык, он же всё равно как минимум в своём ядре использует банальную инструкцию call (если речь об Intel-архитектуре, о других ничего не скажу, не знаю). И внутри потока вызовы встроенных функций ЯП - скорее всего, те же call'ы. А они без стека не живут, к сожалению.
  1056.  
  1057. Ну и для каждого потока ядро ОС хранит его состояние (регистры процессора в первую очередь) - только это никакой не «стек». Вроде бы даже ядро Linux не забило на TSS, использует штатную реализацию Intel, хотя для переключения задач Торвальдс изобрёл свой легковесный велосипед.
  1058. DRVTiny ★★★★★ (03.07.2017 14:24:27)
  1059.  
  1060. Ответить на это сообщение Ссылка
  1061.  
  1062. Ответ на: комментарий от DRVTiny 03.07.2017 14:24:27
  1063.  
  1064. Хотя, гм, насчёт никакого не стека я что-то гоню. Блин, уже забыл всё напрочь, что знал насчёт всех этих TSS, LDT, GDT, IDT, PDPR
  1065. DRVTiny ★★★★★ (03.07.2017 15:06:16)
  1066.  
  1067. Ответить на это сообщение Ссылка
  1068.  
  1069. Ответ на: комментарий от DRVTiny 03.07.2017 14:24:27
  1070.  
  1071. В контексте Go (и не только), ЕМНИП количество «потоков» (в данном случае сопрограмм - goroutine, которым нужен только контекст) != количество нативных потоков и их отображение решается внутренним планировщиком.
  1072. SkyMaverick ★ (03.07.2017 15:44:04)
  1073. Последнее исправление: SkyMaverick 03.07.2017 15:45:38 (всего исправлений: 1)
  1074.  
  1075. Ответить на это сообщение Ссылка
  1076.  
  1077. Ответ на: комментарий от SkyMaverick 03.07.2017 15:44:04
  1078.  
  1079. Да, так и есть. Обсуждали выше.
  1080. DRVTiny ★★★★★ (03.07.2017 16:58:35)
  1081.  
  1082. Ответить на это сообщение Ссылка
  1083.  
  1084. Ответ на: комментарий от i-rinat 02.07.2017 23:23:56
  1085.  
  1086. Вот ты и слился. Как языком молоть, так крутой. А на простенькой задаче лапки поднял и что-то там про работоспособность мямлит. Нет, пока не покажешь рабочий пример, ты просто балабол.
  1087.  
  1088. Смотри, ты утверждаешь c10k и прячешься за нгинкс. Т.е. ты утверждаешь по сути «не можешь», я утверждаю обратное. Почему ты можешь использовать как пруф готовое, а я не могу?
  1089.  
  1090. Тем более c10k не имеет никакого отношения к вебчику.
  1091.  
  1092. Ты придумал что-то своё и теперь споришь. Какой смысл спора, если ты витаешь в каком-то своём мире и с общепринятыми понятиями не пересекаешься?
  1093.  
  1094. Да нет, ты просто поплыл в очередной раз. Общепринятое понятие «Тред» никаким образом не относится к понятию «конкретная реализация тредов в линуксе». Я говорил о первом, а ты слился на второе. Далее сломался и начал нести бред.
  1095.  
  1096. Если ты не осилишь базовые вещи сначала освоить, то таки да, смысла с тобой разговаривать больше нет. Можешь считать, что я «вылетел из треда». Порадуйся там, что ли. Победитель, все дела. :-)
  1097.  
  1098. Бла-бла. Домохозяйки в ютубе мне то же самое говорят. Как только одна извилина закипает - в меня начинает литься «да, я не я - ты не понимаешь базовые вещи».
  1099.  
  1100. Причина этого проста. Любой адепт и любяа домохозяйка является ретранслятором того, что услышала в интернете. Она просто болтает и ретранслирует. Т.е. каждая «вещь», которая крутится в её черепушки не имеет никакого обоснования. Она просто там плавает.
  1101.  
  1102. И когда ты начинаешь об этих вещах спрашивать домохозяйку - как и почему. Она не может ответить. У неё просто в голове есть это поверье и всё. Она не может ничего с эти поделать.
  1103.  
  1104. Она привыкла, что её окружение читала те же интернеты и влито в собратьев то же, что влито и в её черепушку. Да и отбор происходит по этому «влитому». И внутри этого круга, влитое считается как само собою разумеющиеся. Это базовые вещи, вещи которые все знают. Все их знают просто потому, что знают. Как, почему и где они возникли? Кого это волнует.
  1105. saifuluk (03.07.2017 22:19:33)
  1106.  
  1107. Ответить на это сообщение Ссылка
  1108.  
  1109. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1110. Ответ на: комментарий от DRVTiny 03.07.2017 14:10:33
  1111.  
  1112. В стране торгашей, занимающихся уёб-комерцией - да.
  1113.  
  1114. В реальном мире. Выше вон пациент попытался слиться на «контекст для каждой функции» - типичная история. Мы говорим о стеке как о том, что требует это нечто, что требует прицепить к треду кусок памяти.
  1115.  
  1116. Если ты хочешь на каждый локальный объект доблить хип - долби. Хочешь весь контекст собирать для каждой функции отдельно - в любом случае это будет стэк.
  1117.  
  1118. Нужно где-то хранить объекты созданные внутри функции, нужно куда-то записать «куда вернутся». Куда?
  1119.  
  1120. вот предел мечтаний отчественного бузинеса.
  1121.  
  1122. Причём тут слово «отечественного»? Тут должно быть слово «любого».
  1123.  
  1124. И тут конечно IO страшно всё тормозит, самая критичная задача
  1125.  
  1126. Ничего оно не тормазит и никакие потокик это не решают.
  1127.  
  1128. Убогая архитектура, убогая вера в то, что «много тредов» что-то дадут. Зачем из 100тредов долбить ядро, которое потом опять соберёт всё это в один?
  1129.  
  1130. На уровне работы с сокетами мы уже осилили всю бесполезность сего действа, а вот в контексте ИО ещё не осилилось.
  1131. saifuluk (03.07.2017 22:29:55)
  1132. Ответ на: комментарий от saifuluk 03.07.2017 22:19:33
  1133.  
  1134. Почему ты можешь использовать как пруф готовое, а я не могу?
  1135.  
  1136. Моги. Возьми Apache старенький, например, и выжми на нём обработку десяти тысяч соединений одновременно.
  1137.  
  1138. Тем более c10k не имеет никакого отношения к вебчику.
  1139.  
  1140. Ты вообще с этой планеты?
  1141.  
  1142. Общепринятое понятие «Тред» никаким образом не относится к понятию «конкретная реализация тредов в линуксе».
  1143.  
  1144. Во-во, ты уже плывёшь, но всё ещё пытаешься делать весёлую мину при плохой игре.
  1145.  
  1146. Домохозяйки в ютубе мне то же самое говорят.
  1147.  
  1148. Постыдился бы в приличном обществе такое рассказывать.
  1149.  
  1150. Кого это волнует.
  1151.  
  1152. Смотри. Ты сейчас пишешь на русском языке, а не на придуманной тобой тарабарщине. Знаешь зачем? Чтобы тебя понимали. То же самое и с терминологией, это часть языка.
  1153.  
  1154. Пока что я вижу, что ты пыжишься. Судя по эмоциональному окрасу, ты там какой-то крутой спец. Только вот кроме тебя никто твоего величия понять не может, потому что твой язык известен только тебе одному.
  1155.  
  1156. Хочешь чтобы тебя понимали — выражайся яснее.
  1157. i-rinat ★★★★★ (03.07.2017 22:30:06)
  1158.  
  1159. Ответить на это сообщение Ссылка
  1160.  
  1161. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1162. Ответ на: комментарий от i-rinat 03.07.2017 22:30:06
  1163.  
  1164. Моги. Возьми Apache старенький, например, и выжми на нём обработку десяти тысяч соединений одновременно.
  1165.  
  1166. Я уже обосновал тут то, что 10к тредов спокойно работают. Мне пойти тебе хелворд написать? Ты не можешь из А вывести Б?
  1167.  
  1168. Во-во, ты уже плывёшь, но всё ещё пытаешься делать весёлую мину при плохой игре.
  1169.  
  1170. И никаких обоснований твоих потугами не последовало, так? Ты мне доказал то, что говорил я о чём-то ином? Нет. Ты начал нести бред, а как засыпался продолжил нести другой.
  1171.  
  1172. Постыдился бы в приличном обществе такое рассказывать.
  1173.  
  1174. Да не, просто меня удивляет это. Как мне пацаны из себя строят, а по повадкам и понимают типичные домохозяйки. Только набор ключевых слов разный.
  1175.  
  1176. Пока что я вижу, что ты пыжишься. Судя по эмоциональному окрасу, ты там какой-то крутой спец. Только вот кроме тебя никто твоего величия понять не может, потому что твой язык известен только тебе одному.
  1177.  
  1178. Понять могут все, кто хоть что-то понимает в теме. Да и ни о каком величии я не говорю. Всё, о понимании чего со своей стороны я заявляю - я понимаю. Это доказано сотни и тысячи раз.
  1179.  
  1180. А то, что кто-то мне рассказывает «я не верю, я не понимаю» - ну дак тебя никто не заставляет. Ты опровергни то, что сказал я. Не можешь? Ну дак это твоя проблема. У балаболов всегда есть расхождение между «могу» и «заявляю».
  1181. saifuluk (03.07.2017 23:28:33)
  1182. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1183. Ответ на: комментарий от saifuluk 03.07.2017 23:28:33
  1184.  
  1185. Я уже обосновал тут то, что 10к тредов спокойно работают. Мне пойти тебе хелворд написать? Ты не можешь из А вывести Б?
  1186.  
  1187. У тебя уже было времени чтобы десять раз его написать. Но что-то я не вижу кода. Ты хотел взять готовый код, так бери. Чего на попятную пошёл? Погуглил-почитал и понял, что сморозил, а теперь пытаешься выгородиться? :-D
  1188.  
  1189. У балаболов всегда есть расхождение между «могу» и «заявляю».
  1190.  
  1191. Ты пока что только языком чешешь.
  1192.  
  1193. Ты опровергни то, что сказал я. Не можешь? Ну дак это твоя проблема.
  1194.  
  1195. Чайник Рассела.
  1196.  
  1197. Знаешь, не пытайся больше ничего писать. Мне надоело тебе пытаться объяснить твои заблуждения.
  1198. i-rinat ★★★★★ (03.07.2017 23:42:33)
  1199. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1200. Ответ на: комментарий от i-rinat 03.07.2017 23:42:33
  1201.  
  1202. У тебя уже было времени чтобы десять раз его написать. Но что-то я не вижу кода. Ты хотел взять готовый код, так бери. Чего на попятную пошёл? Погуглил-почитал и понял, что сморозил, а теперь пытаешься выгородиться? :-D
  1203.  
  1204. Ты слился в тот момент, когда задал идиотское условие. Нудаладно. Давай ещё раз. Что я должен написать?
  1205.  
  1206. Хорошо, определи критерий решения c10k. Чётко и ясно. Играем на звёзды, кстати.
  1207.  
  1208. Чайник Рассела.
  1209.  
  1210. Не относящие к теме, бесполезно поверье в среде школьников. Твои потуги не являются ничем, а значит ты их доказывать должен точно так же. Естественно ты - обыкновенный ретранслятор поверьев из интернета и именно это не позволяет тебе ничего доказать, ведь поверья из интернетов доказательством не являются.
  1211. saifuluk (04.07.2017 0:53:13)
  1212. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1213. Ответ на: комментарий от saifuluk 04.07.2017 0:53:13
  1214.  
  1215. Хорошо, определи критерий решения c10k. Чётко и ясно.
  1216.  
  1217. HTTP реверс-прокси, за которым один медленно отдающий данные бекенд. Твой реверс-прокси должен адекватно обрабатывать 10 тысяч одновременных подключений. Для определённости бекенд отдаёт файл длиной 8192000 байт с ограничением скорости в 8192 байта в секунду. Твоя реализация должна обрабатывать каждое соединение в отдельной нити. Полной реализации HTTP не требуется, допустима реализация подмножества HTTP/1.0. Достаточна реализация identity кодировки передачи. Реализация keep-alive — на усмотрение. Реализованная часть протокола не должна противоречить RFC 2616.
  1218.  
  1219. От тебя требуется только реализация реверс-прокси. В качестве бекенда можешь взять любой понравившийся веб-сервер. Главное — чтобы он не был узким горлышком в системе.
  1220.  
  1221. Играем на звёзды, кстати.
  1222.  
  1223. Соломку подстилаешь уже? :-D
  1224.  
  1225. доказать
  1226.  
  1227. Удобная у тебя позиция. Несёшь чушь, а другие должны её опровергать. Нет, это не работает. Есть некоторое сложившийся здравый смысл. Не факт, что он не содержит ошибок. Но если ты заявляешь что-то, что идёт с ним в разрез, бремя доказательства лежит на тебе.
  1228. i-rinat ★★★★★ (04.07.2017 1:20:17)
  1229. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1230. Ответ на: комментарий от saifuluk 04.07.2017 0:53:13
  1231.  
  1232. Кстати. Года два назад в интернете уже широко гуляли инструкции по тюнингу nginx и сетевой подсистемы Linux для обработки миллиона одновременных подключений на одном сервере. Сейчас это можно даже назвать обыденностью. Текущая проблема — 10 миллионов одновременных подключений. Железо уже может, пока упираются в ядро.
  1233.  
  1234. На нитях реализовывать, ага.
  1235. i-rinat ★★★★★ (04.07.2017 1:26:57)
  1236. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1237. Ответ на: комментарий от i-rinat 04.07.2017 1:20:17
  1238.  
  1239. HTTP реверс-прокси, за которым один медленно отдающий данные бекенд. Твой реверс-прокси должен адекватно обрабатывать 10 тысяч одновременных подключений. Для определённости бекенд отдаёт файл длиной 8192000 байт с ограничением скорости в 8192 байта в секунду. Твоя реализация должна обрабатывать каждое соединение в отдельной нити. Полной реализации HTTP не требуется, допустима реализация подмножества HTTP/1.0. Достаточна реализация identity кодировки передачи. Реализация keep-alive — на усмотрение. Реализованная часть протокола не должна противоречить RFC 2616.
  1240.  
  1241. Пошла херня. Я так и знал, что балаболка будет юлить до последнего. Будет всё больше и больше ставится условий, специально, чтобы это тратило всё больше и больше времени, и естественно на что я не пойду.
  1242.  
  1243. Как только я выкачу c10k на тредах - балаболка улетит из треда. А она улетит - это 100%. Далее пойдут сливы на тему «треды медленнее», а далее пойдут сливы на память. И так буде бесконечно.
  1244.  
  1245. The C10k problem is the problem of optimising network sockets to handle a large number of clients at the same time.[1]
  1246.  
  1247. sockets. В очередной раз пробалаболил.
  1248.  
  1249. В рамках c10k определяется одновременную обработку 10к сокетов. Трепут никак не определяется. Никаких файлов, никакой другой херни нет. Никакого хттп, вебчика и прочего нет.
  1250.  
  1251. Поэтому ты, либо идёшь и правишь википедию, либо сливаешься из треда. Обработку 10к сокетов я выкачу. И не забывай про звёзды.
  1252.  
  1253. Удобная у тебя позиция. Несёшь чушь, а другие должны её опровергать. Нет, это не работает. Есть некоторое сложившийся здравый смысл. Не факт, что он не содержит ошибок. Но если ты заявляешь что-то, что идёт с ним в разрез, бремя доказательства лежит на тебе.
  1254.  
  1255. Как я и говорил. Есть общество сектантов, в рамках которого те поверья, что ты ретранслируешь доказательствами не облагаются. Можно нести любую херню под предлогом «все это знают».
  1256. saifuluk (04.07.2017 1:36:54)
  1257. Сообщение удалено Pinkbyte по причине Блокировка пользователя с удалением сообщений (0)
  1258. Ответ на: комментарий от i-rinat 04.07.2017 1:26:57
  1259.  
  1260. Во, балаболка уже пошла сливаться. Погуглил? Щас пойдёт вся фигня. А сделай мне нгинкс, а с10к уже устарели( самое смешно, что выше я говорил, что они протухли, но балаболка не унималась, а сейчас вдруг оказывается, что оно устарело. Вот так новость). Далее пойдут «а на слабом процессоре», «а если у меня 100мегабайт памяти», «а если у МКашка», «а нгинкс быстрее», «а 10к мало» и прочее и прочее.
  1261.  
  1262. Это предсказуемо. А пока я дают тебе время на подготовку к вылету и на прощание со звёздами.
  1263. saifuluk (04.07.2017 1:40:24)
  1264. Сообщение удалено Pinkbyte по причине Блокировка пользователя с удалением сообщений (0)
  1265. Ответ на: комментарий от i-rinat 04.07.2017 1:26:57
  1266.  
  1267. Данный балабол знает, что споря с любым моим утверждением ты уже проиграл по определению, особенно шансов нет у подобных тебе.
  1268.  
  1269. Именно поэтому ты и начал сливаться на «а победи нгинкс» - ты знал, что проиграл и ты начал заранее пытаться подготавливать пути ко сливу. Но в любом случае я добрый и хотя ты бы уже давно вылетел из треда за балабольство после моей одной цитаты из википедии.
  1270. saifuluk (04.07.2017 1:45:28)
  1271. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1272. Ответ на: комментарий от saifuluk 03.07.2017 22:29:55
  1273.  
  1274. Я как раз против IO через треды, я за асинхронность на уровне системных вызовов. С моей точки зрения треды нужны прежде всего для рапараллеливания вычислений, а не для убогих попыток обойти недостатки ядра ОС.
  1275. DRVTiny ★★★★★ (04.07.2017 1:57:17)
  1276. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1277. Ответ на: комментарий от i-rinat 04.07.2017 1:26:57
  1278.  
  1279. Ну и самое главное. Пациент поплыл просто феерически с с10к. Пытаясь врать и пытаться всех обмануть.
  1280.  
  1281. Смысл с10к, как и один коннект==1тред основана на ИО, а именно блокирующей природе рид/врайтов. Именно поэтому там и взялись треды.
  1282.  
  1283. Сама обработка хттп, хреноххпп, пхпешки и прочей херни к этим тредам отношения не имеет и может быть организована как угодно.
  1284.  
  1285. Т.е. потоки нужны только для того, чтобы позволить блокирующим ридам/врайтам в сокеты быть параллельными. Всё.
  1286.  
  1287. Эту реальность балабол пытается подменить на свою шизофрению, подменяя те базовые понятия, о которым он сам и болтал.
  1288.  
  1289. Ну и самое главное. с10к, с100к, с1кк - это проблемы ни коннекшенов, ни вебсерверов, ни ядра, ни потоков. Это проблема сокетов. Сокеты - есть ущербанское, убогое и мусорное api. От любой вменяемой реализации юзерпейс tpc-стека ядро улетает в помойку, вместе с нгинксом и прочей хернёй. И причина проста - api.
  1290.  
  1291. Там не стоит с1кк, ни с1кккк проблем.
  1292. saifuluk (04.07.2017 2:04:07)
  1293. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1294. Ответ на: комментарий от saifuluk 04.07.2017 1:36:54
  1295.  
  1296. Будет всё больше и больше ставится условий
  1297.  
  1298. Ты просил чётко и ясно? Получил чётко и ясно. Чего тебе ещё нужно?
  1299.  
  1300. и естественно на что я не пойду
  1301.  
  1302. И это ты мне говоришь про сливание? Ты тут уже облажался по полной, даже не начав код писать.
  1303.  
  1304. Как только я выкачу c10k на тредах ...
  1305.  
  1306. Ты сначала выкати.
  1307.  
  1308. sockets. В очередной раз пробалаболил.
  1309.  
  1310. Да ты, я вижу, дурачок. Кому нужны сокеты сами по себе? Главное — полезная работа. Это только ты любишь байты туда-сюда поперекладывать с нулевым полезным результатом. Это, может, и прикольно, да вот только полезного выхлопа ноль.
  1311.  
  1312. Никакого хттп, вебчика и прочего нет.
  1313. Обработку 10к сокетов я выкачу.
  1314.  
  1315. Ой-ой. Ты планировал десять тысяч раз вызвать socket()? Мда... Хотя давай, выкатывай. Поржём.
  1316. i-rinat ★★★★★ (04.07.2017 2:04:25)
  1317. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1318. Ответ на: комментарий от saifuluk 04.07.2017 2:04:07
  1319.  
  1320. Смысл с10к, как и один коннект==1тред основана на ИО, а именно блокирующей природе рид/врайтов. Именно поэтому там и взялись треды.
  1321.  
  1322. Если ты не в состоянии на примитивном уровне реализовать HTTP, ты просто ноль. На самом деле, это условие облегчает тебе работу, так как для тестов можно переиспользовать уже существующие инструменты.
  1323.  
  1324. Если хочешь, пиши просто на read/write. Но тогда тест-клиент и бекенд тоже реализуешь ты.
  1325.  
  1326. Сокеты - есть ущербанское, убогое и мусорное api.
  1327.  
  1328. Вот ты ещё соломки подстелил. Да, проблема в подходе есть. Только вот она возникает при переходе от миллиона к десяти миллионам. Не пытайся прикрыться этим при обработке 10k потоков.
  1329. i-rinat ★★★★★ (04.07.2017 2:10:58)
  1330. Последнее исправление: i-rinat 04.07.2017 2:14:21 (всего исправлений: 1)
  1331. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1332. Ответ на: комментарий от i-rinat 04.07.2017 2:04:25
  1333.  
  1334. Запаковывайте балаболку - она сломалась.
  1335.  
  1336. Я тебе сказал, ты либо опровергай википедию и иди её править, либо вылетай из треда. Всё просто.
  1337.  
  1338. Полезная работа - это чтение данных из сокета.
  1339. saifuluk (04.07.2017 2:14:10)
  1340. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1341. Ответ на: комментарий от saifuluk 04.07.2017 2:14:10
  1342.  
  1343. Где код? Где тесты?
  1344. i-rinat ★★★★★ (04.07.2017 2:14:37)
  1345. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1346. Ответ на: комментарий от saifuluk 04.07.2017 2:14:10
  1347.  
  1348. Держите меня семеро!
  1349.  
  1350. FTFY
  1351. i-rinat ★★★★★ (04.07.2017 2:15:48)
  1352. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1353. Ответ на: комментарий от i-rinat 04.07.2017 2:10:58
  1354.  
  1355. Если ты не в состоянии на примитивном уровне реализовать HTTP, ты просто ноль. На самом деле, это условие облегчает тебе работу, так как для тестов можно переиспользовать уже существующие инструменты.
  1356.  
  1357. Это так мило, когда меня тыкают убогими хелвордами, которые даже на лабу не тянут.
  1358.  
  1359. Если хочешь, пиши просто на read/write. Но тогда тест-клиент и бекенд тоже реализуешь ты.
  1360.  
  1361. Я напишу просто ххтп-хелворд в ответ.
  1362.  
  1363. Мне не особо интересны разговоры с вами, трата на это время. Ну пока собирается можно и на лоре пописать. Я вот всё надеюсь, что вы осилите начинать понимать, а не ретранслировать херню из интернета.
  1364.  
  1365. Я выше доказал, что линукс спокойно может шедулить 10к тредов. Ты думаешь он не сможет вызвать врайт в этих 10к тредах? Сомневаюсь.
  1366.  
  1367. Этого уже достаточно для любого вменяемого человек( не балабола). Но я иду на твои убогие условия и всё ради чего? Оно мне надо.
  1368.  
  1369. И ты продолжаешь мне пастить и пастить всякий бред. Зачем?
  1370. saifuluk (04.07.2017 2:22:47)
  1371. Сообщение удалено Pinkbyte по причине Блокировка пользователя с удалением сообщений (0)
  1372. Ответ на: комментарий от i-rinat 04.07.2017 2:14:37
  1373.  
  1374. Я сказал уже, что тесты я тебе дам. Дам их тогда, когда мне будет не лень этим заниматься. У меня много и других дел. Мои дела для меня намного интересней и профитнее, вернее доказательство тебе что-то мне не интересно и никакого профита не даёт.
  1375.  
  1376. Я в процессе переваривания «новой» для меня архитектуры - я люблю в это время посраться на форуме. Тут тупняк и расслабуха. Может когда-то в споре с вами понадобится напрягать хоть одну извилину, но то мечты.
  1377.  
  1378. Постараюсь до утра выкатить.
  1379. saifuluk (04.07.2017 2:28:07)
  1380. Сообщение удалено Pinkbyte по причине 4.3 Провокация flame (-2)
  1381. Ответ на: комментарий от i-rinat 04.07.2017 2:15:48
  1382.  
  1383. Починился? Ты дейтвительно не понимаешь уровня всего того маразма, что ты мне тут выкатываешь? Как ты юлишь, как ты пытаешься со мною играть и меня дурить.
  1384.  
  1385. Эти глупые манипуляции, смены темы по 20раз. Игнорирования всего и вся. Куда я бы не зашел - у вас у всех повадки идентичны.
  1386.  
  1387. Фу на вас. Не беспокойся. Будут тебе твои 10к. Я же тебе в прошлый раз обещал самый быстрый поиск - когда-нибудь он будет. Самый быстрый. Но пока средства те, которые ему позволят существовать находятся в разработке.
  1388. saifuluk (04.07.2017 2:36:03)
  1389. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1390. Ответ на: комментарий от saifuluk 04.07.2017 2:36:03
  1391.  
  1392. Я же тебе в прошлый раз обещал самый быстрый поиск - когда-нибудь он будет. Самый быстрый.
  1393.  
  1394. Ага, как же. Или это у тебя такое правило — если не забывать говорить «щас-щас», это не считается за «слился»?
  1395.  
  1396. Куда я бы не зашел - у вас у всех повадки идентичны.
  1397.  
  1398. Никто в твою гениальность не верит на слово? Все требуют каких-то доказательств? Глупцы, да и только.
  1399.  
  1400. Как ты юлишь
  1401.  
  1402. Юлишь тут ты. Попросил чёткие условия — я дал тебе чёткие условия. Так ты сразу начал задачу менять. Мол, это не буду решать, буду другое решать.
  1403. i-rinat ★★★★★ (04.07.2017 2:47:54)
  1404. Сообщение удалено Pinkbyte по причине 7.1 Ответ на некорректное сообщение (авто) (0)
  1405. Ответ на: комментарий от saifuluk 04.07.2017 2:22:47
  1406.  
  1407. Это так мило, когда меня тыкают убогими хелвордами, которые даже на лабу не тянут.
  1408.  
  1409. Тебя не тыкают, тебе протягивают спасательный круг. А ты, беспомощно барахтаясь за бортом, изо всех сил кричишь, что это тонут те, кто на судне. Кричишь, что бывают баржи водоизмещением в десятки тысяч тонн и как они это судно за пояс заткнут.
  1410.  
  1411. Это не мило. Это грустно. Когда же ты поймёшь.
  1412. i-rinat ★★★★★ (04.07.2017 2:53:04)
  1413. Сообщение удалено Pinkbyte по причине Блокировка пользователя с удалением сообщений (0)
  1414. Ответ на: комментарий от i-rinat 04.07.2017 2:47:54
  1415.  
  1416. Попросил чёткие условия — я дал тебе чёткие условия.
  1417.  
  1418. Ах да, чем ты собрался мерить свои «чёткие условия»?
  1419. saifuluk (04.07.2017 5:06:58)
  1420. ← Гарантированно асинхронная запись в Linux?
  1421. Development
  1422. Срочно требуется Мейнтейнер deb-based дистрибутива Linux (за хорошую оплату). →
  1423. Похожие темы
  1424.  
  1425. Новости Julia 0.5 (2016)
  1426. Новости Julia 0.4 (2015)
  1427. Форум Текущий статус языка Julia (2014)
  1428. Форум Кто-нибудь пробовал Julia? (2014)
  1429. Форум Julia Studio теперь Open Source (2013)
  1430.  
  1431. Форум Потоки (2014)
  1432. Форум Потоки (2016)
  1433. Новости The Julia Language — ещё один ЯП? (2012)
  1434. Форум Julia, можно ли получить бинарник и/или so? (2015)
  1435. Форум Синхронизация потоков с помощью семафоров (2013)
  1436.  
  1437. О Сервере - Правила форума - Правила разметки
  1438. https://www.linux.org.ru/
Add Comment
Please, Sign In to add comment
Public Pastes
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy.  OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!