хотя и отрабатывает логику

при 11т вместо 10т корутин потребление памяти практически в 2 раза больше

что такое корутины?

мои знания ограничиваются 3-мя концепциями: процессы (по сути программа) потоки (единица управления многопоточностью для системы) зелёные потоки — fiders (они находятся внутри одного потока и блокировка одно заблокирует всё остальное в потоке)

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

файберы можно плодить тысячами, а потоки не имеет смысла

потому что физически всё-равно будет исполняться параллельно не более количества процессоров

Разве файберы в D блокирующие?

гипертрейдинг от интела это аппаратные файберы по сути

а как они могут быть не блокирующими?

поток при io блокируется системой

пока сделал навскидку тест по созданию практически пустых spawn-еных функций

00001 5mb 01000 15mb 02000 44mb (+29) 03000 75mb (+31) 04000 89mb (+14) 05000 109mb (+20) 06000 119mb (+10) 07000 138mb (+19) 08000 153mb (+15) 09000 198mb (+45) 10000 213mb (+15) 11000 222mb (+9) 11500 174mb (-48) 12000 вылетает в OwnerTerminated

spawn это поток

это 12000 * 2 переключений ОС в режимы ядра и обратно

я думаю да, исходя из того что он возвращает Tid

и зачем их столько?

в vibe организованно норм в этом плане

создаётся оптимальное кол-во потоков и на каждый поток пулы файберов

а как они могут быть не блокирующими?

Ну вот например в го горутины неблокирующие

spawn тоже вроде как, стараются использовать наработки по чистоте функций и неизменности данных

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

spawn тоже вроде как, стараются использовать наработки по чистоте функций и неизменности данных

spawn создаёт новый поток https://github.com/dlang/phobos/blob/master/std/concurrency.d#L537

ясненько, значит их имеет смысл делать не больше количества процессоров, верно?

ну +\-

всё-таки это не железное правило

по поводу spawn Александреску писал: "Вследствие последних усовершенствований аппаратного и программ­ного обеспечения D решил отойти от других императивных языков: да,язык D поддерживает потоки, но они не разделяют никакие изменяе­мые данные по умолчанию - они изолированы друг от друга. Изоляция обеспечивается не аппаратно (как в случае с процессами) и не с помо­щью проверок времени исполнения; она является естественным следст­вием устройства системы типов D."

ну там он слукавил немного

ну как минимум строка 522 того же файла

спауны где полезны?

auto spawnTid = Tid( new MessageBox );

не shared new

когда 2 года назад воткнулся во что-то сильно (с массивами в многопоточности было связанно: arr ~= elem не работал, хотя arr = arr ~ elem работал) стал копать внутрь этого модуля

и обнаружил, что они сами обходят это ограничение типов для этого messagebox и ещё каких-то мелочей

спауны где полезны?

чтобы понимать что и где полезно нужно понимать для чего это нужно

spawn полезен при многопоточном программировании

создаётся поток + messagebox

общаешься с другим потоком через разделяемую очередь с блокировками

а как ты это уже применять будешь — другой вопрос

тоесть там где нужны потоки с разделяемыми данными?

нет

вообще философия потоков в D как-бы намекает, что разделяемые данные это плохо

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

Share by communicating, not communicating by sharing

таким образом если мне нужно организовать "полную" занятость процессоров то нужно создать соответствующее количество потоков (Thread) исполнения и для абстрагирования от оборудования нагрузить эти потоки через некий менеджмент файберами (Fiber) и более простого пути тут нет?

как было сказано vibe.d реализует такой механизм, верно?

жаль, так верилось в волшебную пилюлю )

в го насколько помню в рекламации зазывают свободными от ограничений горутинами которые вроде и не надо менеджерить по процессорам

Олег, а простые потоки получается между собой общаться не могут?

стоп, а родные Thread как по этой правильной классификации называются? не потоками?

нашёл такое сравнение thread/fiber https://octarineparrot.com/article/view/getting-more-fiber-in-your-diet

Олег, а простые потоки получается между собой общаться не могут?

ну тебе нужно самому это взаимодействие строить

стоп, а родные Thread как по этой правильной классификации называются? не потоками?

spawn это родные потоки

Oleg всё же не совсем так судя по описанию: The type of concurrency used when logical threads are created is determined by the Scheduler selected at initialization time. The default behavior is currently to create a new kernel thread per call to spawn, but other schedulers are available that multiplex fibers across the main thread or use some combination of the two approaches.

https://dlang.org/library/std/concurrency.html

код конечно говорит за себя ) но идея ширше чем ядрёные потоки

и шедулер в комплекте есть как я понимаю https://dlang.org/library/std/concurrency/scheduler.html

думается мне, что всёже создание через spawn с настройкой sheduler оптимальнее чем построение своего комбайна на голых thread + fiber

Oleg всё же не совсем так судя по описанию: The type of concurrency used when logical threads are created is determined by the Scheduler selected at initialization time. The default behavior is currently to create a new kernel thread per call to spawn, but other schedulers are available that multiplex fibers across the main thread or use some combination of the two approaches.

ну я говорил про поведение spawn по умолчанию

как-то, кстати, тут был вопрос про файберы и генераторы

http://dlang.org/phobos/std_concurrency.html#.Generator

попробую сделать планировщик на основе интерфейса Sheduler и примера FiberSheduler... заменил ThreadSheduler им и действительно получилось без проблем масштабировать количество spawn-функций

100т вместо 10т при ThreadSheduler без проблем создано и памяти помешьше ест в два раза, осталось разобрать Fiberы по Threadам

попробую сделать планировщик на основе интерфейса Sheduler и примера FiberSheduler... заменил ThreadSheduler им и действительно получилось без проблем масштабировать количество spawn-функций

А ты свой сервер пишешь чтоль?

нет, но от части и это тоже

ERROR: S client not available

есть несколько проектов, пишу каркас приложения пока, который бы смог работать на всех них... vibe.d это конечно здорово... но это сродни юзать ruby on rails для голого api

один из проектов пиринговый нод, так что там конечно серверная часть однозначно есть

ну и от части данные ноды должны уметь оптимально юзать многопоточность как локально на оборудовании так и колаборативно между собой

Перед кем-нибудь вставала такая проблема: сервер не отдаёт в ответе данные, а присылает ссылку для скачивания xml (только xml), пока приходится скачивать файл с помощью std.net.curl.download (самое простое решение, но, мне кажется, не лучшее). Эти данные нужно записать в mongodb, чуть видоизменив (добавив некоторую информацию, чуть изменив имена полей) Как сделать красиво? Стандартный std.xml, как я понял, не позволяет читать итеративно файл, работает с ним только после прочтения в строку. Чтобы сформировать данные для добавления в базу нужно их сначала в vibe.data.bson перевести. В std.xml есть класс DocumentParser, но он работает со строкой, а не с файлом, итеративно читая + не умеет произвольные имена тэгов.

В итоге получается: 1. получаю ссылку сохраняю файл на диск (нагружаю диск зря) 2. читаю файл целиком (расходую память зря) 3. перевожу пока весь файл (опять расход памяти, но это легко исправить) 4. пишу в базу

если слить 3 и 4 пункты, то поменьше расход памяти будет в 2 раза

смотрел на эту библиотечку, вроде можно скачать файл частями и на диск оно по умолчанию не пишет https://habrahabr.ru/post/304072/

но без итеративного разбора xml это бесполезно

хотя проще руками видимо

О что я вычитал: " Порядок выполнения деструкторов модуля - снизу вверх (обратный лексиче­ский порядок)."

в го насколько помню в рекламации зазывают свободными от ограничений горутинами которые вроде и не надо менеджерить по процессорам

Насколько я знаю поверхностно о го, там действительно есть фишка, когда горутины незаметно для разработчика могут переноситься по разным ядрам, таким образом выполнение оптимизируется.

Например если 3 ядра проставивают, а на 4 фигачат тяжелые горутины, то некоторые из них могут быть переброшены на первые 3 ядра чтобы была равномерная нагрузка. Есть ли такое в D я не знаю. Но может в vibe.d что-то придумано.

" Изоляция обеспечивается не аппаратно (как в случае с процессами) и не с помо­щью проверок времени исполнения; она является естественным следст­вием устройства системы типов D."" Я не понял, а как дишная система типов позволят изолировать данные друг от друга?

Павел, на сколько я знаю этого нет и не планируется т.к. перенос файберов по тредам дело сложное и выхлоп очень сомнительный именно поэтому в вайбе от этого отказались

И в продолжение темы про Spawn. Получается spawn это поток который умеет перекидываться с другим потоком сообщениями? Просто я не понял там вроде как про встроенный планировщик написано. Получается это не поток ОС?

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

данные которые shared так или иначе используют блокировки и очерёдность в доступе

spawn это надстройка над thread, fiber, которая в купе с sheduler предоставляет некий конкретный механизм разделения потока исполнения

по умолчанию spawn плодит kernel threads

но изменив sheduler (он интерфейс) можно сделать любое другое поведение

Ржу. С форума: - D оттолкнул тем, что его сделал Александреску, а о нем я невысокого мнения из-за его Zortech C++ - Но Александреску не имел никакого отношения к Zortech C++. - Скорее всего это был Брайт, а Александреску всплыл в памяти из-за того, что он более известный, поэтому и осадочек остался

Так, я что-то подтупливаю. Есть массив JSON: [{foo:"123"},{bar:"321"}] мне чтобы до foo дотянуться что нужно? Цикл писать?

или как-то покрасиве можно

там разве нет какого-то asArray(), возвращающего JSONValue[]?

и в каком виде оно могло бы это возвращать?

в том плане, что можно было обращаться myarra["foo"] ?

я не помню названия функций, но уверен, что нужно что-то вроде json.asArray()["foo"].asStr()

Есть такая функция, но она вроде бы для структур и классов http://vibed.org/api/vibe.data.serialization/asArray

можно проще

json[0]["foo"]

так как исходный json это массив, а потом уже внутрь объекта лезешь

и JSONValue из std.json и Json из vibe.data.json поддерживают этот синтаксис