LINUX.ORG.RU

Многопоточный питон... снова

 , ,


0

1

В продолжение: Многопоточный питон, PEP 554

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

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

Очевидная сфера применения - это веб сервера. Мы заменяем всякие там Redis, RabbitMQ, Celery на родные питоньи решения. То есть, например, энное число процессов получают запросы пользователей, скидывают их в родную питоновую очередь в виде родных питоновых объектов, а потом оттуда эм процессов питона достают объекты и обрабатывают их. Нынче для подобных задач у вас есть выбор межуд in-memory Redis с неродными объектами, либо какие-то более родные, но не in-memory решения:
https://github.com/nascheme/durus
https://pypi.org/project/dobbin/
http://www.zodb.org/en/latest/
http://www.garret.ru/dybase.html

Прикладной data mining и ML - это вообще дремучий лес для меня, к тому же, по моему первому впечатлению мне кажется, что проблему параллелизации непитоновыми методами там уже решили, вроде того же TensorFlow, где большая часть логики, в том числе многопотоков и вычислений на видеокартах, написано на C/C++.

★★★★

Ответ на: комментарий от byko3y

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

Направление верное, но боюсь будет как с perl6 или вообще не взлетит по очевидным причинам:

  • если не совместимо на уровне исходников, то это отдельный язык, для которого мало-кто будет пилить отдельные версии библиотек.
  • питонисты почти поголовно не умеют в многопоточность, но виноватым будешь ты.
  • еще похороны python 2.x не отпраздновали, поэтому еще лет 5 коммунити будет закидывать помидорами любое упоминание о 4.x
anonymous
()
Ответ на: комментарий от byko3y

Ну пиши на Си в питоне дальше, в чем проблема?

Сишечку я выучил до питона.

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

Вы сами это знаете и сказали даже. Эти готвые решения набирают техдолг, а потом их убивают.

По этой причине я поднимал тему о преобразовании питона и устранении недостатков

Ну появился новый диалект, один недостаток в виде GIL устранён. Теперь надо устранять ещё недостатки, переманивать хипстеров и пиарить. Если сможете сделать всё правильно, что ж, будет хорошо. Если не сможете, ждём продолжения цикла и очередного побега.

Питон же не создавался для всех масштабов и тому подобного. Он создавался быстро налабать и несколько раз мутировал. Ну вы понимаете. Дохнет консистентность и язык гниёт. Просто снаружи, а внутри…

anonymous
()
Ответ на: комментарий от anonymous

Это один из актуальных сейчас языков.

Через некоторое время загнётся

В нулевых так тоже говорили про PHP. И где теперь сейчас PHP, а где - лисп?

Ты выбираешь не язык. Ты выбираешь стадо фреймворкоделов. Ты мог точно так же выбрать SWIG и писать на любом языке

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

на десятки реализаций Scheme и полудесяток реализаций CL нет ни одной реализации с GIL. Лисперы вообще не подозревали, что можно так уродовать рантайм

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Не никсы, а GUI-тулкиты, решившие на иксы выдавать не инструкции по отрисовке графики, а саму графику

А иксы у нас научились в антиалиасинг и сложное рисование?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

Вы как-то сильно преувеличиваете. Особенно словами «выучить десяток языков». Вы не сказали даже слово «подъязык» или слово «форма», что более близко к реальности, потому что DSL-и на лиспе по большей части ничем от лиспа не отличаются и даже очень мало отличаются от вызова тех же функций. От стандартных форм лиспа визуально они не отличаются почти никак. Можно, конечно, залезть в глубину, но можно и не залезать.

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

питонисты почти поголовно не умеют в многопоточность, но виноватым будешь ты

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

еще похороны python 2.x не отпраздновали, поэтому еще лет 5 коммунити будет закидывать помидорами любое упоминание о 4.x

CPython - это мусор, который нет смысла переделывать. Но писать на нем будут еще лет 10 минимум.

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Лучше обучить иксы, чем гонять по сети, да и туда-сюда битмапы

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В нулевых так тоже говорили про PHP. И где теперь сейчас PHP, а где - лисп?

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

Сейчас PHP уже не растёт особо, ему направлена дорога в одно место. И это хорошо.

Нет, питон - это именно клей, который оказался наиболее удобен.

Не надо этот клей, лучше уж писать на своём, а этот клей плохой, токсичный.

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

Я смотрел на парочку биндингов питоновых батареек. Вы меня извините, но это какое-то переусложнённое дно. Я пилил батарейки под guile. Со стороны самого лиспа - да, не особо продумали с красивостями, стоило бы нарисовать что-то, что на сишку должно быть похожим, но снизу (со стороны C) их писать явно проще любых монструозных кишок питона. Вообще, со стороны лиспа батарейки лучше пишутся в Racket и Chicken; подозреваю, что в универсальном UFFI/CFFI из CL всё зделоли так, шо батя будет рад. @lovesan , как запиливатель своего кросс-FFI в дотнет, может сказать гораздо больше.

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

PIL всё-таки перепилили, можно новое заворачивать на swig. Или можно сделать мост, как сделали в chicken.

anonymous
()
Ответ на: комментарий от anonymous

Вы не сказали даже слово «подъязык» или слово «форма», что более близко к реальности, потому что DSL-и на лиспе по большей части ничем от лиспа не отличаются и даже очень мало отличаются от вызова тех же функций

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

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

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

Вы точно так же будете проходиться по хаскелю, потому что там каждая монада — это свой, особенный мирок?

Да, к монадам хаскеля у меня очень большие претензии. Хаскель в итоге приходит к отказу от lazy evaluation и к mtl, в которой для чистых и грязных функций применяют одну и ту же MonadIO. Но язык без lazy evaluation и с mtl — это соврешенно другой язык, по сути — тот же ML, к которому пришли через огромный крюк. А попробуй на досуге почитай сообщения об ошибках, которые выдает хаскель при минимальных оплошностях в коде с mtl — там же рехнуться можно.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Начнём с того, что этот ваш вяленд на других *nix не приживётся и портировать на аналоги вяленда на других *nix никто ничего не будет.

anonymous
()
Ответ на: комментарий от anonymous

Не надо этот клей, лучше уж писать на своём, а этот клей плохой, токсичный

Миллионы токсикоманов не согласятся. Им очень даже нравится читаемость кода и заменяемость биошестеренок.

PIL всё-таки перепилили, можно новое заворачивать на swig. Или можно сделать мост, как сделали в chicken

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от anonymous

Начнём с того, что этот ваш вяленд на других *nix не приживётся и портировать на аналоги вяленда на других *nix никто ничего не будет

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

читаемость кода

Неконсистентность не ведёт к читаемости. Намеренное выбрасывание фич не ведёт к читаемости, оно ведёт к костылям. Миллионы токсикоманов вообще не выбирали, всё выбрали за них. Никто IRL про лисп не слышал, да и про более распространённые вещи.

Да что уж там, большая часть пользователей Ubuntu вообще не в курсе, что в их убунточке можно сметить тот же DE.

заменяемость биошестеренок

Эти товарищи вас всех вообще на JS переведут. К слову, вот есть на Linux пока что два (дело потихоньку идёт к трём, но третий случай мы опустим) юзерлэнда. Один написан заменяемыми биошестерёнками, другой написан с миру по нитке. Тот, что написан с миру по нитке, может больше, хотя его пишут в среднем меньше людей, иногда без возможности замены. У него есть продуманная документация, уж точно попродуманней оной, написанной биошестерёнками. Нужно ли такое общество биошестерёнок?

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

Но всё-таки пилить на SWIG интерфейс проще, чем писать эту груду кишок. В случае Guile по-быстрому запилить сишный модуль выйдет быстрее, чем почитать мануал к SWIG.

Прокладки прокладками, но swig минимальные прокладки делать умеет. Допиливать, может, и надо, но можно жить и так.

anonymous
()
Ответ на: комментарий от anonymous

Неконсистентность не ведёт к читаемости. Намеренное выбрасывание фич не ведёт к читаемости, оно ведёт к костылям

Я не понимаю, о какой неконсистентности и выбрасывании фич идет речь.

Эти товарищи вас всех вообще на JS переведут

Я уже.

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

Я не понимаю, про какие юзерленды идет речь.

Но всё-таки пилить на SWIG интерфейс проще, чем писать эту груду кишок. В случае Guile по-быстрому запилить сишный модуль выйдет быстрее, чем почитать мануал к SWIG

Это все просто, когда задачи простые. А если нужно налаживать взаимодействие разных объектов друг с другом, то вся простота куда-то исчезает. В том же хацкеле ввод-вывод иил STM представляют собой ад еще тот, потому что достаточно сильно интегрированы и предоставляют много возможностей использования. А вот вызвать простую функцию на Си тоже очень просто.

byko3y ★★★★
() автор топика
Ответ на: комментарий от peregrine

Сейчас благодаря ой-вейленду

А я думал благодаря вайну и дяде Габену

Хорошо, скажем так: благодаря прямому рендерингу. Да, вейленд здесь отыгрывает незначительную роль. Но и Габен без поддержки нвидии/интеля/амд много бы не сделал.

byko3y ★★★★
() автор топика
Ответ на: комментарий от peregrine

Но GO не тянет на замену питону. Я бы с радостью ушел с питона, но альтернативы нет

Для написания веб сервисов? Вполне себе тянет. А где ты собрался еще использовать питон?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

peregrine ★★★★★
()
23 декабря 2020 г.
Ответ на: комментарий от byko3y

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.