Что за хрень

Выходит это не прикол LibEv, а что-то другое...

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

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

Ну то, что я вижу из проблем, то только асинхронное общение между потоками

Ну или строить их на пейрСокет

Я хочу сравнить питон и ди в производительности потоков. Думаю как лучше сделать. Запустить больше потоков чем ядер и посмотреть где быстрее отработаются?

Или есть вариант лучше?

Я хочу сравнить питон и ди в производительности потоков. Думаю как лучше сделать. Запустить больше потоков чем ядер и посмотреть где быстрее отработаются?

Больше чем ядер - не имеет смысл

Нужно их запускать кратное количеству ядер

Но тогда я эффект от GIL не замечу

Я хочу сравнить питон и ди в производительности потоков. Думаю как лучше сделать. Запустить больше потоков чем ядер и посмотреть где быстрее отработаются?

В этом нет смысла - ди быстрее

Я хочу убедиться в этом и цифры глянуть

Я хочу убедиться в этом и цифры глянуть

Раз в десять точно

)))

Питон интерпритируемый язык

Ди - компилируемый

Конечно будет быстрее

Но тогда я эффект от GIL не замечу

Эффект от GIL проявляется при числе потоков больше 1. С ним же даже на 32 ядрах все равно лишь один поток работает.

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

с многопоточным программированием всегда есть проблемы, которых нет при однопоточном, что бы ты не придумывал)

просто D позволяет проще обращать внимание на важные моменты

но и сравнение может быть не совсем честным: на python есть много разных библиотек, которые могут быть видеокартой ускорены, что автоматически на большом объёме порвёт процессор

как пример перемножение: матриц на питоне и на D

если всё написать чисто на питоне и чисто на D, то понятно, что D будет быстрее а вот если прикрутить к питону какую-нибудь мат.либу, то уже спорный момент

Это уже будет D vs C+Python

Или даже фортран.

Кстати, а как D Runtime работает? Через промежутки времени запускается или как?

Что значит работает? Это просто набор служебных функций.

Делаешь new - вызывается ф-я из рантайма.

И т.д.

Я об GC конкретнее

https://dlang.org/spec/garbage.html#op_involving_gc

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

Если не аллоцируешь - он не вызывается.

Можно хоть весь день в цикле крутиться, ни разу GC не спровоцировав.

То есть на GC нет накладных расходов, считай?

пока не делаешь операцию, которая требует GC, нет

а там уже как повезет)

Тогда непонятно, почему в betterC нет GC

в каком плане непонятно?

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

И как это противоречит идеям betterC?

кажется назревает очередная итерация беседы про betterc)

Платиновый тред, ветер северный

у betterc по факту нет идей, это просто D с выкинутым рантаймом

Когда у тебя malloc работает не микросекунды, а секунды - это хуже, чем Си, а не лучше. :)

Есть одна идея - как Си, только лучше.

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

и еще один плюс: в win32 x86_mscoff простенькие программки генерят .exe размером меньше 10 кб)

Тогда непонятно, зачем выкидывать классы? Можно же под капотом new сделать malloc, а под капотом delete (которого удалили непонятно за что) - free

ну как сказать, тогда для классов нужен будет какой-нибудь подсчет ссылок

Нет

У нас же есть delete

Удаляем вручную

нету у нас delete

Был. Но мне непонятно, что мешало бы сделать такое поведение

ну вот есть у тебя где-нибудь ссылка на объект, а где-то в другом месте ты взял и прибил его

Да не в этом дело, структуры-то есть, с ними вопросы ссылок и памяти те же самые.

Просто в Си классов нет, есть структуры.

А тут тот же Си, только лучше. :)

Технический момент там был - это кастинг

Он по-хорошему требует кое-каких штук из рантайма

Для хождения по иерархии классов

структуры же на стеке по умолчанию и копируются)

Не все же они на стеке будут

В реальных программах большинство живет в куче

структур-то?

Да

ERROR: S client not available

ну не знаю)

Открой любой проект на Си

мы про ди говорим же, не про си

Нужны же данные, живущие дольше одной ф-ии

Мы говорим про betterC

именно

BetterC — это D с выброшенным рантаймом)

и половиной языка

ну со всем, что завязано на рантайм

хотя, много чего незаслуженно попало под нож)

просто потому что оно нечаянно было завязано на рантайм, но это поправляют

Кароч, если нужен беттерСи с классами и ГЦ, то надо вызывать его компилятор без ключика -betterC ;)

Это просто D

Так вот, мне все равно непонятно, что, только идеология(с) betterC мешает туда классы завезти?

классы серьезно завязаны на рантайме

Как именно?

они создаются в куче, за их жизнью следит сборщик мусора, для наследования нужно typeinfo

есть возможность использовать extern(c++) классы, даже вроде с наследованием, но только через грязные хаки и боль)

Первые две не препятствие, а про третье надо подробнее. Разве наследование не в CT?

с чего вдруг не препятствие?)

Создавать можно было бы malloc'ом

Следить вручную

Достаточно прикрыть new - malloc и добавить delete - free, как я уже писал выше

Первые две не препятствие, а про третье надо подробнее. Разве наследование не в CT?

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

но этого сделать нельзя же, и никакого delete не существует)

хочешь ручных классов — есть целый язык, C++ называется)

но этого сделать нельзя же, и никакого delete не существует)

Оператор delete был же?

Если вернуть в betterC GC и классы то у него снова рантайм распухнет на сотню кб

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

Без GC

С ручным управлением памятью

Тогда непонятно, почему в betterC нет GC

С ручным управлением памятью

Так делай) нет проблем