Python Shared Objects

Тот же ZeroMQ, или какую-то MT-ready сишную библиотеку для реализации структур хэштаблица, массив. И делать вокруг него тонкий слой обертки

Есть проблема. Это не простые хэш-таблицы и массивы, а двухверсионные. MT-ready сишная библиотека должна резко разучиться делать любые вызовы malloc/free, а вместо них размещаться в разделяемой памяти и оперировать ShmPointer. Также MT-ready библиотека должна разучиться использовать любые примитивы синхронизации, не работающие через разделяемую память.

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

У тебя, я так понимаю, все равно нет нативных питоновых объектов. Все лежит в неймспейсе PSO

Можно переписать __is_subclass__ и делать вид, что это стандартные питоньи объекты. Правда, в отдельные захардкоженные места их не получится пропихнуть и придется конвертировать в стандартные. Конвертация делается легко, но разделяемость при этом теряется.

Делай редкие причесывающие коммиты. 99% рынка собеседователей не поймет как ты обосрался

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

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

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

Уже хором намекают, что ненужно, но нет, так просто не проймёшь.

Уже хором намекают, что ненужно, но нет, так просто не проймёшь

Да ради бога, если софтина для питона не нужна — значит, не нужна. Но реально ведь многопоточку ведь почти никто не умеет писать. Ну то есть не совсем так: писать много кто умеет — писать рабочие программы мало кто умеет. А у меня софтина работает. Очень даже неплохо работает: не падает с сегфолтами, не повреждает память, не дедлочится, и при этом оперирует весьма нетривиальными структурами данных с кучей блокировок. Сколько сишников могут таким похвастаться?

Microsoft, гугл и фейсбук тут не при чём. Объясняю - завязываться на репозиторий от Васяна который вчера зарегистрировался - это большой риск, даже если выглядит что он шарит в теме. Потому если если Васян только появился, ничего не писал, никуда не контрибутил, то на СПО ему было похрен, а значит с большой вероятностью по-прежнему похрен, никакой ответственности по поддержке он брать не собирается, PR принимать не будет, равно как и на issue реагировать. Скорее всего, он даже не представляет что такое поддержка СПО проекта вообще, и думает что достаточно выложить код. Поэтому об использовании твоей репы речи идти не может даже для наколеночных проектов - слишком большой риск потом всё переписывать. Более того, даже в руках крутить её не хочется, потому что она не используется никем и нигде, и написана непонятно зачем, никакую задачу не решает. Смотреть внутрь просто так тоже никому не интересно - проще, как тебе на хабре уже написали, сваять за полчаса свою реализацию на mmap.

Все ж знают, что у GitHub две функции — хвастаться перед 20-летней HR-кой и качать оттуда опенсорс авторства гугла и фейсбука.

А давай-ка ты ЧСВ поумеришь, ибо ты вот прямо сейчас подтверждаешь гипотезу о незрелости как СПО разработчика и рисках использования твоих проектов. Так-то «все знают» что завязываться на опенсорс авторства гугла и фейсбука - это свои риски, да и проекты у них в большинстве специфичные, а херки по гитхабу позовут только в какой-нибудь гадюшник, так для поиска работы он немного бесполезен. Нет, у GitHub одна функция - делиться качественным поддерживаемым свободным кодом, в множество которого ни поделки корпорашек, ни поделки Васянов «я вот вам написал, как вы смеете не использовать, меня не нахваливать, а ещё и на ошибки указывать» не входят. Согласен - пили дальше модуль и что-нибудь его использующее, зарабатывай доверие, тогда может быть он станет кому-то интересен. Нет - лучше оставь на локалхосте. Требовать внимания вот здесь и сейчас - глупо.

Потому если если Васян только появился, ничего не писал, никуда не контрибутил, то на СПО ему было похрен, а значит с большой вероятностью по-прежнему похрен, никакой ответственности по поддержке он брать не собирается, PR принимать не будет, равно как и на issue реагировать

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

А давай-ка ты ЧСВ поумеришь, ибо ты вот прямо сейчас подтверждаешь гипотезу о незрелости как СПО разработчика и рисках использования твоих проектов. Так-то «все знают» что завязываться на опенсорс авторства гугла и фейсбука - это свои риски

Да мне даром не нужно чтобы вы использовали мою либу в своих проектах. Там до прода еще как до киева раком. У меня оно прям сейчас течет, и я нифига не могу найти причину. Valgrind не прокатывает, даже в однопоточном режиме, поскольку манагер памяти свой. Вполне возможно, что течет сам манагер. Собственно, там манагер памяти в целом недописанный, но у меня есть оправдание — законченных универсальных манагеров разделяемой памяти вообще не существует в природе, есть только специализированные огрызки под конкретные проекты. А чтобы утечку отследить, нужно сканировать кучу кастомной тулзой, которую сначала нужно написать. И это только один из геморроев.

проще, как тебе на хабре уже написали, сваять за полчаса свою реализацию на mmap.

Зачем ваять, когда есть Apache Arrow. И она не только для питона, а мультиязыковая.

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

Ты просто о них не знаешь.

https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess/allocators_containers.html#interprocess.allocators_containers.allocator_introduction.allocator

Зачем ваять, когда есть Apache Arrow. И она не только для питона, а мультиязыковая

Затем, что она, в общем-то, была создана с целью решить схожую проблему, только она ничерта не умеет делать по поводу записи — это read-oriented решение. Ты можешь создавать/пересоздавать блоки, но манипулировать одним блоком из нескольких процессов ты не можешь. То есть, как бы message-passing BLOB-ов с zero-copy — вот и весь Arrow.

Ты просто о них не знаешь.
https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess/allocators_contai...

Это было, наверное, первое решение, которое я нагуглил. Проблема в том, что оно не умеет динамически расти. То есть, оно умеет делить отданный ему сегмент памяти, но не умеет организовывать эти сегменты вместе — эту логику нужно писать самому. А это что-то типа половины всей логики манагера разделяемой памяти. Причем, поскольку эта логика залазит также в логику разделения сегментов на блоки, то и готовые классы буста придется жестко кастомизировать.

Ты знаешь, заглянул в interprocess/sync — вроде вроде интересные блокировочки, можно было бы применить и у себя. Но, блин, почему-то на винде у них вместо пары спинлок-event (как у меня) применяется обычный мутекс на системном вызове. А где, собственно, события? Futex, eventfd, CreateEvent, в конце-концов pipe? Кроме блокировок мы ничего не знаем, что ли? Как сделан named_sync? Созданием файла на ФС и применением LockFile. Для позиксов там вообще ничего не придумали лучше кастомного алгоритма, базирующегося на мутекса. Вот снова: вроде ох какая хорошая либа, всё есть из коробки, а присмотришься — огрызок же ж, кто-то выкинул, а я поднял. Портануть свою поделку на кресты, что ли?

и это тоже https://lgtm.com/

Предлагаю clang-formatter или uncrustify с настройками для PEP-7. Если ты просто создашь готовый к запуску конфиг для проверки сишного кода на соответствие PEP-7, это наберет больше звезд, чем то что ты пилишь. Потому что готового чекера под это я нагуглить не смог.

Напиши нормальные примеры и какие-то бенчмарки. Не очень понятно кому и для чего нужна именно твоя реализация. Кто знает, может у тебя интерфейс ущербный. Сам говоришь, что там другой хер написал только фибоначи. Так напиши нормальный пример ты. Первое впечатление от такого, что кто-то задротствует на какуюто эзотерику. Так что пример использования.

чтобы врубиться, что там автор написал, надо читать - это.

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BD%D0%B0%D1%8F_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%BF%D0%B0%D0%BC%D1%8F%D1%82%D1%8C

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

но реализаций транзакционной памяти хватает, в сслке внизу списки есть.

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

и это тоже https://lgtm.com/

Отличный сканер, спасибо. Я не знаю, видите ли вы это, но вот какие полезные уязвимости он нашел:

Wrong type of arguments to formatting function
[Open] [High] [correctness] [CWE-686] [reliability] [security]

fprintf(pFile, ": %d\n", bucket->value);

This argument should be of type 'int' but is of type 'unsigned long' 

Я никогда этому сканероговну не верил.

Напиши нормальные примеры и какие-то бенчмарки. Не очень понятно кому и для чего нужна именно твоя реализация. Кто знает, может у тебя интерфейс ущербный. Сам говоришь, что там другой хер написал только фибоначи. Так напиши нормальный пример ты. Первое впечатление от такого, что кто-то задротствует на какуюто эзотерику. Так что пример использования

Ну прям внизу ридми примеры же. А в статье бенчи — о них написано прямо в начале ридми. Если этого недостаточно — предложи, какие еще примеры тебе нужны. Могу перенести ссылки на примеры в начало ридми.

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

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

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

А что там еще не обсуждено? Основная проблема — это отмена операций, чуть менее актуальная — инверсия приоритетов. Весь src/shm_types.c посвящен как раз поддержке отмены операций.

Предлагаю clang-formatter или uncrustify с настройками для PEP-7

Это кодестайл для конкретно внутренней реализации бидона. Нигде снаружи оно даром не нужно.

А что там еще не обсуждено?

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

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

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

Кстати, $USERNAME, как ты думаешь, стоит ли в мою никому не нужную поделку вводить крестовый код? Давно хотелось, поскольку крестовые фичи сильно упрощают отдельные формы полиморфизма и в C++11 появились лямбды. а у меня там дофига передач блоков кода аргументами, что сейчас реализовано на сишных макросах.

Кстати, $USERNAME, как ты думаешь, стоит ли в мою никому не нужную поделку вводить крестовый код?

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

при наивном подходе(который естественнен) один из них блокируется, а при идеях локфри - второй тред не блокируется, а пишет копию, которая потом «вмерживается» в данные

Для бидона это бесполезно, по крайней мере пока такое вмерживание может привести к изменению конкурирующего алгоритма. Классический питоний код обращается к общему изменяемому состоянию налево и направо, будто это бесплатно. В принципе, можно запараллелить операции установки разных ключей в ассоциативном массиве, но если вдруг кто-то сделает «if key in dict», или «for key in dict» — это привет, нужно весь словарь лочить на чтение, поскольку любое изменение ключа приведет к изменению результата выполнения. В examples/accounts.pso.py как раз пример, где я вместо изменения большого контейнера засунул в каждую ячейку по маленьком объектику, на который уже нужна маленькая блокировка.

Те же Redis/Memcached вообще не подразумевают использование в режиме «if key in dict»/«for key in dict», то есть, под них код придется переписывать. Я выбрал самый параллелизуемый вариант, под который не придется совершать никаких дополнительных действий для переноса в транзакционную память. То, что развитие CPython все 30 лет шло под себя и код крайне неудобен в оптимизации и параллелизации — ну извиняйте, я не виноват.

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

Там есть заготовочки на async, но я пока что до него не дошел. Ну типа если ресурс оказывается занятым более приоритетным процессом, то ожидание проходит по await с возвратом в главный цикл для обработки накопившихся сообщений. Я писал про это как минимум в Rationale.md.

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

Я очень сомневаюсь, что на плюсовую модель памяти налезет STM в принципе. Я про то, чтобы ввести C++ в мою STM, а не про то, чтобы ввести STM в C++.

Я очень сомневаюсь, что на плюсовую модель памяти налезет STM в принципе.

списочек по с++ там внизу посмотри

https://en.wikipedia.org/wiki/Software_transactional_memory

у плюсов модели памяти вообще нет. память это просто кусок адресов. на такую модель все полезет.

Ну типа если ресурс оказывается занятым более приоритетным процессом, то ожидание проходит по await с возвратом в главный цикл для обработки накопившихся сообщений. Я писал про это как минимум в Rationale.md.

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

зачем питону Shared Object если он даже не работоспособен в multithread? только этого ему нехватало…

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

это крик из прежнего опыта «встроить скриптовый движ в большое серьёзное приложение». Питон с грохотом обломался

Каноническое нинужна

Вот именно

списочек по с++ там внизу посмотри
https://en.wikipedia.org/wiki/Software_transactional_memory

Да, за список спасибо, я не все из них знал.

у плюсов модели памяти вообще нет. память это просто кусок адресов. на такую модель все полезет

На плюсы очень хреново ложится функционально-поточное программирование:

Функциональщина на C++

Я сам был такой дерзкий, но LOR остудил мой пыл по этому поводу. Просто потому, что писать лапшу с неявными goto и изменяемыми по месту данными на C++ сильно проще, чем в любом другом стиле. Убираешь исключения — ы-ы-ы, а как нам теперь передавать ошибки? И так далее.

STM как бы даже на Си натягивали, но история эта очень прохладная, в лучшем случае это упростит написание маленьких коротеньких кусочков кода, но они совсем не дотягивают до уровня «создать кучу сложных динамичных объектов, а потом отменить транзакцию». Та же TL2 тупо все транзакции организует на уровне маш слов, где каждому читаемому/изменяемому слову соответствует запись в хэш-табличке, записал мегабайт изменений — получил 128 тыщ записей в хэш-табличку, а динамическое выделение через malloc/free у них почти никак не обрабатывается.

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

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

Да, это называется lock-based STM. В том же TL2 меньше блокировок, но они есть. Конкретно здесь блокировки пришлось применять потому, что питоньи функции могут курить очень долго, на оптимистичное выполнение тебе никаких циклов процессора не фатит. Оптимистичность — это все-таки больше для языков, в которых операция будет весить менее сотни циклов процессора. Иронично то, именно в таких условиях банальный спинлок работает не хуже, чем оптимистичное выполнение.

Чего «академики» привязались к этому lock-free — ума не приложу. Бесконечный цикл с compare-and-swap — это не lock-free, это практически та же блокировка, которая тупит неопределенно долго при наличии конкурентов. Это то, что академики называют «contention-free algorithm», по характеристикам прикладных реализаций оно один в один совпадает с производительностью блокировок.

зачем питону Shared Object если он даже не работоспособен в multithread? только этого ему нехватало

И никогда не будет способен. Смысл был в том, чтобы шарить память между процессами так же, как между потоками. Разница между процессами и потоками чисто формальна, и часто оно просто исчезает, как в том же Erlang, где формально существуют только процессы, хотя они отображаются в зеленые потоки, потоки ОС, и отдельные процессы ОС.

Нити не изолируются и гарантируются чудеса с именами

Какие еще чудеса с именами?

это крик из прежнего опыта «встроить скриптовый движ в большое серьёзное приложение»

I know that feel, bro, но проблема встраиваемости питона скорее вызвана запредельно кривущей реализацией самого интепретатора, а не какими-то фундаментальными проблемами языка. Там вон в вике чуть ли не икону поставили Гвидо, а мне хочется спросить «вы вообще код реализации питона читали?». Я регулярно как эту дичь читаю, так рву волосы на башке с криками «что это? Как вам это могло прийти в голову? Почему здесь костыль на костыле на костыле? Почему нельзя было один раз грамотно решить проблему?».

Это то, что академики называют «contention-free algorithm», по характеристикам прикладных реализаций оно один в один совпадает с производительностью блокировок.

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

потому забей на свою транзакционную память и не мучайся.

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

Так чему же ты удивляешься?

а тот факт, что мне даже никто не ответил в списках рассылки бидона

Про что должны были ответить? Всё что тут можно ответить - «написал POC, молодец, пиши дальше».

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

Как я отвечал в треде на реддите, блокировка чаще всего не нужна, потому что изначально не нужно разделяемое изменяемое состояние. Проблема блокировок возникает потому, что люди злоупотребляют общим изменяемым состоянием. Например, GIL в большинстве случае ничего не защищает, потому так просто ее убрать из интерпретатора. Но впоследствии выяснится (выяснилось), то там кусочек кода полагается на общее состояние, здесь кусочек кода, и таких косочков кода ТЫЩИ. Вот сейчас в рамках PEP 554 их чистят-чистят, чистят-чистят, пятый год чистят и не могут вычистить.

Но если тебе нужно именно разделяемое состояние — ты неизбежно приходишь к блокировке, оптимистичной или пессимистичной (обычной). Путанницы добавляют диссиденты, которые кричат на каждом углу про жизнь без блокировок и разделяемого состояния, как решение всех проблем в мире. И получается дичь вроде хаскеля, где для работы с изменяемым общим состоянием нужно делать очень много приседаний, и по итогу никто не пишет на хаскеле БД или GUI, которые полностью слеплены из этого самого изменяемого общего состояния.

Мой проект — это просто правильная реализация разделяемого состояния с блокировками для питона, не более не менее. Не «кинем GIL на всё», не «уберем GIL и получим неопределенное поведение из-за гонок», а «не блокируемся без конфликтов, блокируемся при конфликтах, но не дедлочимся».

Вообще, изначально я задумывал проект как простую либу для организации блокировок разделяемой памяти. То есть, штатный multiprocessing.shared_memory, в нем блокировочки, мы аккуратно блокировочки берем по необходимости и отпускаем. Далее возникла проблема — если мы не можем заранее знать, какие блокировки нам нужны, то нам может понадобиться внезапно отменить исполнение при конфликте блокировок. И привет двухверсионные структуры данных с откатами. Очень не хотелось, но иного пути я не нашел.

Про что должны были ответить? Всё что тут можно ответить - «написал POC, молодец, пиши дальше»

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

Например, в каком направлении двигаться.

может забить на питон-то? есть плюсы, ява, шарп, голанг, скриптовый луа, есть даже лисп! во! …и так далее

может забить на питон-то? есть плюсы, ява, шарп, голанг, скриптовый луа, есть даже лисп! во! …и так далее

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

Направления выбирают под задачу. А тут задачи нет. Ковыряй дальше как тебе нравится, хоть Electron и eBPF прикрути.

I know that feel, bro, но проблема встраиваемости питона скорее вызвана запредельно кривущей реализацией самого интепретатора, а не какими-то фундаментальными проблемами языка. Там вон в вике чуть ли не икону поставили Гвидо, а мне хочется спросить «вы вообще код реализации питона читали?». Я регулярно как эту дичь читаю, так рву волосы на башке с криками «что это? Как вам это могло прийти в голову? Почему здесь костыль на костыле на костыле? Почему нельзя было один раз грамотно решить проблему?».

когда встала задача «встроить чё-нить скриптовое», Питон рассматривался в первую очередь - модно,молодёжно,популярно.. Поэтому код интерпретатора конечно смотрел, и тоже не в восторге.

Чуть не исследование потом было проделано по всем языкам, кого можно брать. Список удивительно невелик: lua, mruby, tcl приспособлены к тому чтобы легко встраиваться и расширять приложения. Для прочих приклады должны изначально под них делаться или существенно перепахиваться.

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

Направления выбирают под задачу. А тут задачи нет. Ковыряй дальше как тебе нравится, хоть Electron и eBPF прикрути

Вот именно, я склоняюсь к тому, что питон и библиотеки онного — это абсолютно не сочетаемая и не переиспользуемая хрень. То есть, вот у нас есть числа стандартной либе — но массивы мы не можем множить, слишком медленно. Ага, давайте сделаем NumPy, несовместимые со стандартными функциями питона, но быстро множащие массивы. Но нам бы еще хотелось делать сортировку/фильтрацию/статистику по двухмерным массивам-табличкам — ага, давайте сделаем Pandas dataseries, которое несовместимо со всем предыдущим.

То есть, вместо решения изначальной проблемы в кучу просто докидывается костыль под узкоспециализированную задачу. Потом на reddit вкатывается чел, который написал уникальную библиотеку для HTTP запросов, и срывает овации. Да, выполнение HTTP запроса — это подвиг в питоне. Так и живем. Ждем питоновые бибиотеки для арифметических операций над чётными числами.

Мне тут подумалось: а почему бы мне мою хрень не натянуть на JS? Все-таки, там принято чаще использовать штатные объекты, а не ad-hoc костыли на каждый чих.

Однозначно да. Причем не ограничиваться С++11, а хотя бы 17 или выше.

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

А что с ним не так?

Вот как так проектируют ?

Маркетинг. Быстро слепленный на коленке кусок дерьма с огромным числом никак не сочетающихся фич захватывает рыночек, а потом «да мы уже привыкли», а потом еще и «да лучше ничего не придумали в индустрии!» — это самая веселая категория боевых старых пердунов, которые будут стоять до гроба, как диды в 43-ем. Я как написал первую статью по проблемами питона, так на меня штабелями посыпались эти старые пердуны, минусующие за любую попытку даже высказаться против плохих фич питона.

Это не столько мое отвращение, сколько зависть. У людей «рыночек», люди «работают», а я никак не могу ухватить волну, не могу сделать так, чтобы рыночек работал на меня, а не я на него.

Короче, статью надо раза в 2-3 сократить, при переводе на русский и учиться писать проще и лаконичный, с уважением к чужому времени.

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

Потом на reddit вкатывается чел, который написал уникальную библиотеку для HTTP запросов, и срывает овации. Да, выполнение HTTP запроса — это подвиг в питоне. Так и живем. Ждем питоновые бибиотеки для арифметических операций над чётными числами.

«Оваций» там - два комментария. И да, сэкономить миллисекунду или строчку кода на выполнении HTTP запроса - это подвиг, потому что HTTP запросы выполняются миллиардами, а разделяемое состояние нахрен никому не нужно, тем более в питоне.

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

Так уж устроен мир что не существует серебряных пуль. Да, слишком медленно и да давайте сделаем. То же самое происходит в абсолютно любом языке. Захотел SIMD - положи подряд в память и выровняй. Захотел на GPU - сконверти и залей в карту. Да, оберни это в свой несовместимый вектор, да не моги потом передать его в std::sort, но это и не нужно потому что бессмысленно. Справедливости ради, с совместимостью в упомянутых модулях очень неплохо - почти всегда можно передать объект одной библиотеки в другую и оно будет работать. С накладными расходами, понятное дело.

Ну и что-то я не вижу чтобы ваш код был прям drop-in заменой последовательного кода или мультипроцессинга с пиклом. Какие-то root, connect, транзакции. В чем это более сочетаемая и переиспользуемая хрень чем NumPy?

То есть, вместо решения изначальной проблемы

И в чем же здесь, интересно, изначальная проблема?

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

Я очень сомневаюсь, что на плюсовую модель памяти налезет STM в принципе

Это technical specification, а не стандарт. Так что я с этим не работал, но я знаю что это есть в gcc

https://en.cppreference.com/w/cpp/language/transactional_memory

Знакомая песня. Есть такие люди которые не понимают почему есть так как есть и не хотят даже разобраться, зато все у них вокруг виноваты, там пердуны не дают сказать (ЧСХ «пердуны» без задней мысли взаимозаменяются с «хипстерами» и «смузихлёбами»), тут маркетинг (или корпорации, или «это потому что так сказал XXX а вы на него молитесь»).

Это не столько мое отвращение, сколько зависть. У людей «рыночек», люди «работают», а я никак не могу ухватить волну, не могу сделать так, чтобы рыночек работал на меня, а не я на него.

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

А что с ним не так?

помниться что та-же ерунда что с питоном, глобальный толстый стейт и к нему ещё уборка мусора (схемо-лисп жеж).

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

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

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

Например, даже после целого моего треда по вопросу успеха GitHub я так и не получил железобетонных фактов, с которыми я бы мог прийти и сказать «вот, произошло это, и в результате GitHub завоевал весь рынок». Рассказы про «лучше интерфейс, социальная составляющая» выглядят неубедительно, поскольку GitHub в ранние годы был редкостной тормознутой блевотиной, которая смотрелась лучше разве что на фоне sourceforge.

А знаешь ли ты, что Ruby on Rails поднялся ТОЛЬКО за счет Apple? Если я это среднему айтишнику в вакууме скажу без пояснения логической цепочки, то он скажет «да что ты выдумываешь? Опять заговоры?». А ведь RoR — это очень солидная доля рынка, и никого не колышет вопрос того, откуда эта доля у него взялась.

И да, сэкономить миллисекунду или строчку кода на выполнении HTTP запроса - это подвиг, потому что HTTP запросы выполняются миллиардами, а разделяемое состояние нахрен никому не нужно, тем более в питоне

LOL, а тебя не волнует, что разделяемое состояние способно сократить число запросов в разы? Тупо за счет того, что запрашиваемые данные уже были запрошены кем-то еще.

То же самое происходит в абсолютно любом языке. Захотел SIMD - положи подряд в память и выровняй. Захотел на GPU - сконверти и залей в карту. Да, оберни это в свой несовместимый вектор, да не моги потом передать его в std::sort, но это и не нужно потому что бессмысленно

Как минимум для CUDA были разработки по разделяемой памяти, я не знаю, в каком они сейчас состоянии. Примеры же, которые ты приводишь — это как раз причины такого медленного входа параллельных вычислений в индустрию. Что научились делать на GPGPU в 2021? Нейронки и просто числодробильни? А где веб-сервера на видеокарте? Где веб-браузер на видеокарте? Хотя бы СУБД на видеокарте сделать-то можно? Нет?

Ну и что-то я не вижу чтобы ваш код был прям drop-in заменой последовательного кода или мультипроцессинга с пиклом

А ты не можешь просто взять последовательный код и запустить его параллельно. Потому что он на то и последовательный код — нужна минимальная модификация. Если тебе нужно последовательный код выполнить последовательно, то ты его и не трогаешь. Трогать ты его будешь, если тебе нужно его распараллелить, и в основном это трогание сводится к добавлению строчки with transaction:.

Ну и что-то я не вижу чтобы ваш код был прям drop-in заменой последовательного кода или мультипроцессинга с пиклом. Какие-то root, connect, транзакции. В чем это более сочетаемая и переиспользуемая хрень чем NumPy?

Дело не в том, что я хотел написать «сочетаемый софт ради сочетаемости» — нет, это софт, который позволяет организовывать безопасную параллелизацию, и при этом он сочетаемый с базовым питоном. NumPy этого не умеет, и потому пофигу сколько там лошадиных сил у машины без колёс.

И в чем же здесь, интересно, изначальная проблема?

https://habr.com/ru/post/481782 — это я только по поверхности прошелся. Кривизна питона не является чем-то неотъемлимым, без чего нельзя быстро и удобно разрабатывать на нем программы. Однако, беспорядочно кинутые в язык случайные фичи — это хороший маркетинговый ход, который и обеспечил ему успех. Помнишь лямбды? На потеху лисперам в питона завезли лямбды, filter, map, reduce. И по итогу это говнище оказалось полностью неюзабельным, а reduce вообще убрали и встроенных функций.

Если ты посмотришь на Jira, то она следует точно таким же путем: если есть какой-то альтернативный инструмент или новая фича, то мы реализуем ее у себя, и не важно то, насколько криво эта фича будет работать, насколько беспощадно тормозить, насколько плохо стыковаться с остальными функциями, всё что нас колышет — это чтобы манагеры купили наш продукт для своей работы по критерию «фичанейм есть в Jira, но нету в Redmine». А там уже куда они денутся, когда все их данные будут у нас.

Есть такие люди которые не понимают почему есть так как есть и не хотят даже разобраться, зато все у них вокруг виноваты, там пердуны не дают сказать (ЧСХ «пердуны» без задней мысли взаимозаменяются с «хипстерами» и «смузихлёбами»), тут маркетинг (или корпорации, или «это потому что так сказал XXX а вы на него молитесь»)

Эм-м-м... ты хочешь сказать, что у популярности софта есть немаркетинговая природа? Вот это поворот.

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

Ну типа если я говорю одноногому «ты — одноногий» — это оскорбление? Этика, она же учение про лицемерие, меня не прельщает.

Этика, она же учение про лицемерие, меня не прельщает.

С такой точкой зрения вы всегда найдете себе оправдание в оскорблении любого человека …