LINUX.ORG.RU

Многопоточный питон, PEP 554

 ,


1

4

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

https://github.com/ericsnowcurrently/multi-core-python
https://www.python.org/dev/peps/pep-0554/

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

Теперь главный вопрос: зачем? PEP 554 предлагает обращаться за помощью к каналам, как в Go, но:
- каналы как средство взаимодействия потоков убоги даже в Go;
- в питоне уже есть multiprocessing, который по сути и есть развитая идея каналов с возможностью прокинуть в обе стороны вызов функции и запрос атрибутов объекта, вплоть до итераторов, но не более того.

Для людей, которые уже готовы отвечать «ну дык есть же многопроцессы, есть форк на никсах - вот и используйте их», напомню, что реализация форка процесса на уровне ОС-и в действительности мало помогает многоПРОЦЕССовости питона - машем ручкой сборщику мусора, который передергивает счетчики ссылок:
https://instagram-engineering.com/dismissing-python-garbage-collection-at-ins...

>>> import os, sys, gc
>>> len(gc.get_objects())
6888
Это весьма эффективная модель сборки мусора... если у вас ровно один процесс.

Допустим, у нас уже есть несколько независимых потоков интерпретатора. Логичное желание - придумать какие-то эффективные модели взаимодействия интерпретаторов, которыми кто-то захочет пользоваться.
Примитивные ячейки данных (вроде многопоточного bytearray или других настраиваемых структур) довольно бесполезны, потому что мы же пользуемся питоном для того, чтобы взмыть вверх по абстракциям. Если же мы надумаем передать через подобнюу структуру хотя бы элементарную функцию, вроде

def hello():
    return "hello world"
то окажется, что объект строки и объект функции сидят в другом интерпретаторе, а сборщик мусора принципиально не умеет работать более чем в одном потоке, потому просачивание объекта из одного потока в другой вызывает катастрофические последствия.

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

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

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

Кто-то видит свет в конце тонеля? Или же это предсмертные видения?

★★★★

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

причина роста абстракций не раскрыта

Выгодно. Вот и раскрыта.

20+ ядер и полсотни потоков

Но тормоза при недолокализации обращений к памяти. И да, 20 - это как раз «несколько».

типа производительность техники стоит на месте

Типа да, много лет уже. Последние годы только диски разогнались флешами, остальное растёт вширь.

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

Не такая же. Установка готовых решений проще написания эффективного кода.

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

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

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

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

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

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

Оу, невнимательность, спасибо.

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

причина роста абстракций не раскрыта

Выгодно. Вот и раскрыта.

Почему выгодно? Ладно, я чувствую, что так перекидывание полуфразами может продолжаться долго, потому отвечу развернуто: компьютерная техника проникает во всё более нищие сегменты, которые не могут себе позволить полноценной разработки. Одними из первопроходцев в окучивании нищесегмента был MS - нищеброды оказались доходнее крупных фирм. MS содержал в своем штате очень квалифицированных кодеров, но нынешние кодерские конторы экономят и на кодерах, переходя на пробившие дно технологии, вроде PHP и JS. Питон дно не пробивал, зато уровень кодеров на питоне катастрофически падает.

20+ ядер и полсотни потоков

Но тормоза при недолокализации обращений к памяти. И да, 20 - это как раз «несколько».

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

Типа да, много лет уже. Последние годы только диски разогнались флешами, остальное растёт вширь.

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

Не такая же. Установка готовых решений проще написания эффективного кода.

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

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

Из нас двоих ты один безответственно тащишь зависимости в проект, а потом сваливаешь их поддержку на других

У меня вся инфраструктура есть, для начала

У меня всё есть: яхта, дача на лазурном берегу. Если ты, нищеброд, не можешь позволить себе этих базовых вещей, то зачем ты живешь?

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

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

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

Тоесть твоё оправдание — это админы научившиеся минимизировать вред от тебя-чудака? Пива проставь.

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

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

Тоесть твоё оправдание — это админы научившиеся минимизировать вред от тебя-чудака? Пива проставь.

Знаешь, мне один человек рассказывал, как работал в банке. Суть в том, что дневную работу можно выполнить максимум за 4 часа, но что делать остальное время? В итоге люди занимаются тем, что ломают то, что работало, и потом чинят его, или просто чинят то, что не ломалось. Мне не совсем ясна психология людей, которые там остаются работать длительное время - я бы не смог. Начальник нанимает избыточное кол-во людей, но платит им меньше - таким образом избыточный штат не оказывается бременем.

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

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

byko3y ★★★★
() автор топика

- каналы как средство взаимодействия потоков убоги даже в Go;

Плач неосилятора.

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

нужно обходить изоляцию

Не нужно.

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

Ну так пишешь в api вызов функции, которая вернёт или дёрнет тебе что надо.

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

И в чём коварство? Зачем её засовывать сразу всё в отладчик? Дёргаешь нужное api оно тебе выдаёт результат. Внутри всё работает точно так же. Засовываешь свой микросервис в отладчик, обмазываешь его логами, дёргаешь за api, да смотришь. Огромное удобство в том, что тебе не надо запускать/перезапускать/пересобирать весь твой монолит, чтобы отдебажить одну функцию где-то.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

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

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

Что это js пробило дно, ну-ка обоснуй. Между прочем v8 работает шустрее многих вм пистончика.

Производительность PyPy в исполнении питоновой программы (в противовес работе функций на C) сравнима с V8. Когда же работают функции на C, то уже нет разницы.
Проблема JS заключается в дизайне языка, точнее, в его отсутствии: беспорядочные операции над базовыми типами; словарь, как единственный тип сложных данных; безымянные функции, обращение к которым происходит через переменные или поля словаря; модульная организация в принципе не предусматривалась. У питона есть модули, у питона есть система типов, просто переменные могут принимать значения разных типов и происходят неявные преобразования типов. Для скриптовых языков важнее поддерживаемость, а не скорость исполнения кода - потому CPython много кого устраивает и скорость выполнения не играет роли, ведь байты жуют функции на C.
Не так уж мало проектов на питоне имеют 10 000+ строк кода. Какой самый большой проект на JS? React на 20 тыс строк? Sinon на 30 тыс? Тесты к фаерфоксу на пару сотен тыщ строк вперемешку с данными? Тем временем фреймворк Twisted на питоне - 300 тыс.
JS изначально не предусматривалось использовать ни для чего более, чем десяток строк в веб страничке. Подобная ситуация была и в PHP, но на стороне сервера. Прибили дно они тогда, когда стали использоваться для крупных проектов, то есть - не по назначению. JS пробил еще и второе дно, когда перекочевал на сервер. Я уверен, что PHP бы начали использовать на клиенте, если была бы возможность добавить поддержку PHP в браузерах.

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

- каналы как средство взаимодействия потоков убоги даже в Go;

Плач неосилятора.

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

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

cловарь, как единственный тип сложных данных

Эти типы недостаточно сложные?
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...
https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...
Да и чем плох дефолтный объект?

беспорядочные операции над базовыми типами

Например?

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

И в чём проблема?

модульная организация в принципе не предусматривалась

Там есть require и import, что в них не так?

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

А в js не могут?

Тем временем фреймворк Twisted на питоне - 300 тыс.

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

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

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

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

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

Ну так пишешь в api вызов функции, которая вернёт или дёрнет тебе что надо.

Вот именно, я об этом и пишу. В монолите не нужно никакого API и ничего писать не нужно - всё уже есть.

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

И в чём коварство? Зачем её засовывать сразу всё в отладчик? Дёргаешь нужное api оно тебе выдаёт результат.

Как сказал Миша Соломон ( https://www.youtube.com/watch?v=G-lGCC4KKok ), отладка распределенных систем - это примерно как предсказание погоды: порой их поведение совершенно непредсказуемо и неожидано. Запрос от одного сервиса к другому проходит через относительно слабо контролируемые дополнительные этапы. И сами отдельные сервисы могут меняться относительно друг друга, выводя на поверхность мелкие особенности функционирования кода.
Отладчик позволяет заморозить приложение и управляемо отследить его работу, в распредленной системы такого сделать не получится, и может оказаться, что наблюдаемая в продакшене ошибка просто не повторяется в отладке.
Пока система простая и маленькая - это проблемы не играют роли. По мере роста системы растут и проблемы. Собсна, у монолита тоже возникают свои проблемы, но другие.

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

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

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

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

В монолите не нужно никакого API и ничего писать не нужно - всё уже есть.

В монолите не нужно писать классы/методы/функции? С нормальной рефлексией api делается абсолютно также. Пишешь метод, он заворачивается в api. Даже я так умею.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

Спорное утверждение. Если сам ты ноль, то не спеши хвалить любого кукареку. В гугле в основном макаки работают и тупицы.

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

отладка распределенных систем - это примерно как предсказание погоды: порой их поведение совершенно непредсказуемо и неожидано

Если руки из жопы, то монолит получается точно такой же. Да и что угодно так получается.

Запрос от одного сервиса к другому проходит через относительно слабо контролируемые дополнительные этапы.

Какие, например?

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

Код при одних и тех же входных данных выдаёт разный результат? Ну это уже продукт эпичных говноделов, тут никакая архитектура не поможет.

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

В данном случае высококвалифицированный инженер - это гугл, который написал V8 и cgroups.

И что, значт теперь толпа бомжей из пту может просто сесть и написать нормальный биллинг?

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Эти типы недостаточно сложные?
Float32Array
Int32Array
Map
Set
WeakMap
Да и чем плох дефолтный объект?

Map, Set, WeakMap приняты в стандарт где-то в 2015 году, когда засилие индусов толкнуло к необходимости вводить адекватные типы вместо того, чтобы толкать каждый раз на построение велосипеда. А типизованные массивы в стандарт еще не приняты, к слову.
Простой объект, который на самом деле словарь - это белый лист, который, с одной стороны, дает возможность делать что вздумаешь, но с другой стороны - как потом это поддерживать?
Не так давно переопределение типа массива было нормой, например. Вся история развития разработки на JS последних эдак лет десяти сводилась к построению нового языка, jQuery был лишь одним из первых. В итоге человек, который понимает jQuery и голый JS, не понимает более современные костыли - а этих костылей нынче развелось пруд-пруди, между прочим.

модульная организация в принципе не предусматривалась

Там есть require и import, что в них не так?

«import» 2015 год. «require» актуален только для node.js. Как я уже написал, енпригодность оригинального JS была очевидна в 2015 году.

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

А в js не могут?

Я не об этом писал. Питон подразумевает довольно серьезную опору на типизацию. Та же попытка присвоения значения по индексу массива за пределами размера массива в питоне дает ошибку, потому что в питоне массив - это массив, а не черт знает что.
JS потому и полюбился индусам, что не проверяет типов, не выдает ошибок, позволяет творить любую содомию. Как потом это поддерживать - индуса не волнует.

Тем временем фреймворк Twisted на питоне - 300 тыс.

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

300 тыс строк - это не монструозный комбайн, это просто большой фреймворк, при использовании которого кодеру не придется каждый раз заново притирать компоненты, как это приходится делать в JS, если кто вдруг рискнет сделать большой проект. Монструозный же комбайн - это оракл на 30 млн строк. Я так понимаю, что для современных кодеров миллион строк - это уже космос.

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

Почему выгодно … развернуто … нищие сегменты

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

и если ядро работает со своей областью памяти

Именно. Заставлять массового програмца думать о задержках при обращении к памяти – неконструктивно, он и без этого ошибок наделает на 2 багтрекера. Потому абстракции растут, производительность падает, и это выгодно.

что производители железа не могут …

… [b]продать[/b] сильно паралельное железо. Потому, что слабопаралельные программы не выигрывают от этого. Внезапно оказалось, что GIL весьма полезен – он заставляет кодеров учиться паралелить. И чем больше будут задержки, тем быстрее они научатся, т.ч. на разные компы и общаться TCPями. И снова получается QED :)

что удобство написания монолита теряется

Да, я говорил про «построение системы». Писать распределённый код таки сложнее(впрочем, не всегда заметно). Но чем усложнение от распаралеливания хуже усложнения от оптимизации производительности(которое, кстати, всегда)?

Раньше ты мог просто прочитать переменную или вызвать функцию

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

Ты, часом, не заметил, что отстаиваешь права ленивых кодеров, производить неэффективный код?

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от crutch_master

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

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

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

В монолите не нужно писать классы/методы/функции? С нормальной рефлексией api делается абсолютно также. Пишешь метод, он заворачивается в api. Даже я так умею.

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

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

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

Спорное утверждение. Если сам ты ноль, то не спеши хвалить любого кукареку. В гугле в основном макаки работают и тупицы.

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

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

Запрос от одного сервиса к другому проходит через относительно слабо контролируемые дополнительные этапы.

Какие, например?

Например, через сеть.

Код при одних и тех же входных данных выдаёт разный результат? Ну это уже продукт эпичных говноделов, тут никакая архитектура не поможет.

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

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

В данном случае высококвалифицированный инженер - это гугл, который написал V8 и cgroups.

И что, значт теперь толпа бомжей из пту может просто сесть и написать нормальный биллинг?

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

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

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

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

и если ядро работает со своей областью памяти

Именно. Заставлять массового програмца думать о задержках при обращении к памяти – неконструктивно, он и без этого ошибок наделает на 2 багтрекера. Потому абстракции растут, производительность падает, и это выгодно.

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

Потому, что слабопаралельные программы не выигрывают от этого. Внезапно оказалось, что GIL весьма полезен – он заставляет кодеров учиться паралелить. И чем больше будут задержки, тем быстрее они научатся, т.ч. на разные компы и общаться TCPями. И снова получается QED

Не вижу логики. Скорее я бы согласился, что кодеров учат писать еще более ужасный и неподдерживаемый софт.

Но чем усложнение от распаралеливания хуже усложнения от оптимизации производительности(которое, кстати, всегда)?

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

Раньше ты мог просто прочитать переменную или вызвать функцию

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

Ты имел в виду «сложноотлаживаемый код»? Потому что я не понимаю, какое отношение имеет неэффективность к предыдущему твоему абзацу.
Есть самые разные пути безопасного и простого взаимодействия отдаленных частей монолитного приложения. Есть тот же clojure, в котором довольно сложно написать опасный код.

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

А типизованные массивы в стандарт еще не приняты, к слову.

https://www.ecma-international.org/ecma-262/6.0/#table-49
Обновляй методичку.

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

Функция x делает структуру y. Прочекать структуру y - это проблема?

Вся история развития разработки на JS последних эдак лет десяти сводилась к построению нового языка

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

«import» 2015 год.

Уже 4 года прошло. Надо обновлять методичку.

«require» актуален только для node.js

Браузеропроблемы. Да и для него авторы либ делают обёртки, если надо.

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

А в сишечке такое даёт повреждение памяти. Что сказать то хотел? В пистоне так сделали, тут не захотели так делать, чтобы можно было расширять массив без головняка и подсчётов размера заранее. Да и не такой уж это проблема. По массиву везде бегает forEach, заполняет push, я вообще не помню, когда была какая-то теоретическая возможность выйти за границы или работа напрямую с индексами. Если где-то такое и есть, то границы проверяются до того, как лезти к массиву.

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

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

300 тыс строк - это не монструозный комбайн, это просто большой фреймворк

Ну да, я про это и говорю.

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

Ну т.е. херак-херак и в продакшон.

Монструозный же комбайн - это оракл на 30 млн строк.

И это что, что-то хорошее?

раз заново притирать компоненты

Что такое «притирать компоненты» и зачем их притирать? Либа A имеет такой функционал, либа B - другой. Ты просто берешь и используешь эти либы, передаешь им данные, получаешь результат. Фреймворк подразумевает какую-то свою интеграцию, интерфейсы, типы и любое писательство на фреймворке всю разработку завязывает на него. А если кто-то делает какое-то непереносимое говно, так это его/их личная половая жизнь.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от byko3y

Такой подход к построению архитектуры может приводить, например, к сложности ответа на вопрос «а какие же функции друг у друга вызывают наши сервисы?»

Я просто аннотирую то, какие функции будут вызываться и у кого.

и получается де-факто монолит, где нельзя заменить одну часть, а нужно менять только систему целиком

Есть api. Есть тесты. Берешь да переписываешь. Ну если кто-то делает не нужную связанность, то ссзб.

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

Не понимаю связи. Бомжи из ПТУ пользуются инструментами, написанными среднеквалифицированными писаками

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

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

Например, через сеть.

И какие проблемы несёт в себе сеть?

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

Странное заявление. Если ты не можешь контролировать даже входные данные, то что ты можешь вообще?

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

Функция x делает структуру y. Прочекать структуру y - это проблема?

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

А типизованные массивы в стандарт еще не приняты, к слову.

https://www.ecma-international.org/ecma-262/6.0/#table-49
Обновляй методичку.

«import» 2015 год.

Уже 4 года прошло. Надо обновлять методичку.

Хорошо, обновлю. Авось к 2025 году я наконец смогу записать в методичку, что из JS сделали второй питон.

«require» актуален только для node.js

Браузеропроблемы. Да и для него авторы либ делают обёртки, если надо.

Тебе напомнить про C++, у которого десяток разных реализаций?

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

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

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

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

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

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

Ну т.е. херак-херак и в продакшон.

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

Что такое «притирать компоненты» и зачем их притирать? Либа A имеет такой функционал, либа B - другой. Ты просто берешь и используешь эти либы, передаешь им данные, получаешь результат.

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

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

Такой подход к построению архитектуры может приводить, например, к сложности ответа на вопрос «а какие же функции друг у друга вызывают наши сервисы?»

Я просто аннотирую то, какие функции будут вызываться и у кого.
...
Есть api. Есть тесты. Берешь да переписываешь. Ну если кто-то делает не нужную связанность, то ссзб.

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

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

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

Но берут же. Получается плохо, но получается же.

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

Например, через сеть.

И какие проблемы несёт в себе сеть?

У меня странный вопрос, но: ты в курсе, как работает сеть? Там алгоритмы сложнее, чем твоя софтина.

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

Странное заявление. Если ты не можешь контролировать даже входные данные, то что ты можешь вообще?

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

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

В JS - проблема. Структура y по факту может оказаться любой, и это никого не смущает.

И что? Её принципиально нельзя прочекать на валидность?

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

Это не аргумент. Кучу говна можно навалить на чём угодно.

Тебе напомнить про C++, у которого десяток разных реализаций?

Каким боком тут плюсы? У js кроме v8 вообще скоро не останется реализаций кроме встроек. А импорт уже подтянули на все браузеры. Так что обновляйся.

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

Так она и не кидается ошибками на пользователя. Если что-то не работает оно не работает и валит всё в консоль. Если ты сделаешь a.b.c, где a - пустой объект оно выкинет. Иииии? Сейчас хотят запилить ?. чтобы не чекать отсутствие всей цепочки, а сразу выдвать undef.

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

Если программист не понимает, что у него происходит в коде, то программирование, это очевидно не то, чем ему надо заниматься.

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

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

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

Индус говнодел, а виноват инструмент. Хорошо.

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

Что значит с «минимальными усилиями»? На динамических языках нету постоянной писанины с объявлением типом, но это не значит, что там думать над задачей надо меньше. Думать надо столько же или больше, просто ты на них программируешь, а не набираешь стены кода решая проблемы не относящиеся с делу. Это не значит, что не надо чекать ввод или типы или null. Это всё так же надо чекать. Просто это можно сделать удобно, а не на костылях типа lombook или плясками с «выразительной» рефлексией.

С нынешним подходом на JS не получится сделать большой проект.

Большой проект как что? Как оракл? Или какой-то мегафреймворк - это большой проект? Что такое «большой проект», зачем и кому он нужен?

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

И прибил всё гвоздями к своему twisted/spring/javaee/что у тебя там еще.

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

У меня странный вопрос, но: ты в курсе, как работает сеть? Там алгоритмы сложнее, чем твоя софтина.

Мне похрен как она не работает в контексте js кода. Один передал, другой получил. Если сеть вдруг упала всё свалилось и нагадило в логи. Профит.

Я не могу контролировать, что не забарахлит розетка на роутере

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

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

Я бы на питоне писал или на плюсах - обе версии gui должны работать почти у всех и в них удобно следить за вводом данных и их хранением. Буду рад если посоветуете вменяемые статьи на тему «подружить питон и си без проблем с совместимостью интерфейсов».

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

mazdai ★★★
()
Последнее исправление: mazdai (всего исправлений: 1)
Ответ на: комментарий от byko3y

одном компьютере очень много ядер,

Это терминологическое – в моём словаре между числами «1» и «много» есть ещё «несколько». «Много» будет ближе к сотне.

и проблема сейчас состоит в том, чтобы как-то их задействовать

Правильно. Что мешает? Програмы, написаные в расчёте на мгновенность операций. Но как заставить авторов писать иначе? Увеличить задержки! Только когда иллюзия достаточной производительности немасштабируемой программы исчезнет, они научатся чтить формулы амдала густавича и только тогда программы станут работать быстро(: особенно будучи засунуты обратно на один сервер:).

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

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

С другой стороны скорость (количество «работы»/календарное время) растёт. Впрочем, только для хорошо упаралеленых программ. А последним не очень то и важна общая память и GILы безразличны.

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

Ты имел в виду «сложноотлаживаемый код»? какое отношение имеет неэффективность

Не способный использовать доступные аппаратные ресурсы. Это имеет отношение? Программа, ускоряющаяся на 5% пр увеличении кол-ва ядер вдвое – неэффективна в эпоху роста процессоров вширь. Однако, кластера растут вширь намного дольше и лучше процессоров. Хорошие программ[ист]ы должны были бы уже приспособиться.

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

В JS - проблема. Структура y по факту может оказаться любой, и это никого не смущает.

И что? Её принципиально нельзя прочекать на валидность?

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

Тебе напомнить про C++, у которого десяток разных реализаций?

Каким боком тут плюсы? У js кроме v8 вообще скоро не останется реализаций кроме встроек. А импорт уже подтянули на все браузеры. Так что обновляйся.

Это я к тому, что код труднопереносим между платформами. И мы приходим к тому, что диалект JS - это диалект конкретной реализации, а не какой-то общий стандарт. Потому люди и говорят, что являются кодерами на node.js, а не на жабоскрипте - это разные варианты подобных языков.
В node.js «import» появился только с 8.5.0, например.
А SpiderMonkey вроде пока не собирается никуда уходить.

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

Так она и не кидается ошибками на пользователя. Если что-то не работает оно не работает и валит всё в консоль. Если ты сделаешь a.b.c, где a - пустой объект оно выкинет.

a.b.c - это слишком сложно, мало кто дальше одного уровня будет лезть. Вот a.b тихо прожевывает. Потом через пятсот строк эта ошибка вылезет - поди разбери, где ошибка возникла. Тебе палки в колеса ставит сам язык - а что ты будешь делать с нетривиальными ошибками? «Давайте лучше об этом не думать»? «Если ошибки не видно, то ее и нет»?

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

Если программист не понимает, что у него происходит в коде, то программирование, это очевидно не то, чем ему надо заниматься.

Вот ты снова и снова пишешь как человек, который никогда не работал с крупным проектом. Я регулярно открываю свои модули, с которыми давно не работал, и удивляюсь тому, что не помню их. И здесь возникает вопрос читаемости кода, насколько он выразителен. Если бы просто понимание происходящего в коде решало все проблемы, то люди писали бы коммерческие проекты на brainfuck. У JS плохая выразительность, и ее приходится компенсировать комментариям. Но комментарии не помогут исключить всё неявное поведение при исполнении.

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

300 тысяч строк кода. Давай, обтыкивайся логами - потом «война и мир» покажется тебе легким чтивом на вечер.

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

Индус говнодел, а виноват инструмент. Хорошо.

Ты - тот самый мастер, который готов каменным топором выточить шарикоподшипник? Хорошо.

Большой проект как что? Как оракл? Или какой-то мегафреймворк - это большой проект? Что такое «большой проект», зачем и кому он нужен?

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

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

И прибил всё гвоздями к своему twisted/spring/javaee/что у тебя там еще.

А в чем проблема? У JavaEE были проблемы с патентами, но у twisted их нет.

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

У меня странный вопрос, но: ты в курсе, как работает сеть? Там алгоритмы сложнее, чем твоя софтина.

Мне похрен как она не работает в контексте js кода. Один передал, другой получил. Если сеть вдруг упала всё свалилось и нагадило в логи. Профит.

А если зависло и через время развисло?

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

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

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

Это терминологическое – в моём словаре между числами «1» и «много» есть ещё «несколько». «Много» будет ближе к сотне.

$12'000 за сервер с сотней ядер.

и проблема сейчас состоит в том, чтобы как-то их задействовать

Правильно. Что мешает? Програмы, написаные в расчёте на мгновенность операций. Но как заставить авторов писать иначе? Увеличить задержки! Только когда иллюзия достаточной производительности немасштабируемой программы исчезнет, они научатся чтить формулы амдала густавича и только тогда программы станут работать быстро(: особенно будучи засунуты обратно на один сервер:).

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

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

Давай, реши мне проблему быстрого кодирования аудио/видео, криптографии, компиляции в один поток.

Программа, ускоряющаяся на 5% пр увеличении кол-ва ядер вдвое – неэффективна в эпоху роста процессоров вширь. Однако, кластера растут вширь намного дольше и лучше процессоров.

Не знаю, откуда ты взял цифру 5%, и я не вижу цифры для кластеров: на сколько процентов растет производительность при удвоении числа компьютеров?

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

Вы закрылись в свой стэк докер-нода, и отказываетесь видеть что-то другое в мире.

Так у юзера всё равно ничего другого кроме js нету, если речь про бразуер что тут обсуждать?

Отвалится может часть сети, отвалится может один сервис.

И он, очевидно не будет работать, если не продублирован где-нибудь на такой случай.

А если зависло и через время развисло?

Кстати уйдет на запасной, как вариант.

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

Ты пишешь про то, что код не должен описывать структуру объекта

Так он и не описывает. Описывает какой-нибудь конфиг в случае js.

Весело там у вас.

В чём проблема чекнуть структуру на входе выходе я так и не понял.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Так у юзера всё равно ничего другого кроме js нету, если речь про бразуер что тут обсуждать?

Я не понимаю, неужели в мире ничего, кроме твоего проекта, нету? Есть самые разные сервера, есть самые разные клиентские устройства, есть самые разные задачи.

И он, очевидно не будет работать, если не продублирован где-нибудь на такой случай.

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

А если зависло и через время развисло?

Кстати уйдет на запасной, как вариант.

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

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

Ты пишешь про то, что код не должен описывать структуру объекта

Так он и не описывает. Описывает какой-нибудь конфиг в случае js.

Хорошо, я понял идею. Когда-нибудь это станет стандартом и JS начнет быть похожим на питон.

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