LINUX.ORG.RU
ФорумTalks

Академические алгоритмы в современном программировании: не маразм ли?

 , , ,


3

2

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

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

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

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 1)

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

в общем O(n) рулит не подетски, а за параллельность должен отвечать компилятор, виртуальная машина.

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

«Основы» могут сильно подзапутать и подзасрать мозг.
Например те же мутабельные объекты при параллельном программирование дают больше вреда чем пользы.

Например, если бы ты был знаком с основами распараллеливания, то подобных идиотских заявлений не делал бы. https://en.wikipedia.org/wiki/Shared_nothing_architecture

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

проблема не в том, что питон плохо параллелится, а то что там Global Interpreter Lock, т.е. никакой параллельности там нет и быть не может

но ты можешь запустить Python на JVM (т.е. JPython), и проблема исчезнет

так что вперед изучать джаву :3

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

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

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

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

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

но ты можешь запустить Python на JVM (т.е. JPython), и проблема исчезнет

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

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

Подзасрать мозг можно чем угодно, если не освоить материал до конца, и ломануться «в бой» ;)

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

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

Массивов чего?
Утилиты написанные на C могут быть в ~235 раз быстрее hadoop-кластера.
https://news.ycombinator.com/item?id=8908462
https://habrahabr.ru/post/267697/

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

Утилиты написанные на C могут быть в ~235 раз быстрее hadoop-кластера.

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

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

действительно не понял

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

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

Ты так договоришься, что не надо MS SQL Server, Oracle и MS Exchange во все дыры пихать.

dmxrand
()

Не маразм. Дело в том, что для решения многих задач недостаточно твоих 128-ядерных систем. И представь, недостаточно иногда даже 50 000 этих самых 128-ядерных систем.

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

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

Ни одна виртуальная машина и компилятор сами не смогут догадаться, где у вас куски кода, способные выполняться параллельно (цикл какой-нибудь можно заменить на вязанку тредов), а где - строго последовательные. Вернее, подобное возможно, но в функциональных языках, где по определению не может быть side-effect'ов от выполнения одной и той функции в нескольких потоках. Т.е. я легко могу представить, как автоматически параллелятся матрёшки Lisp'а, но не могу представить, как это в общем виде могло бы выглядеть в «процедурных» языках. Т.е. в том же perl'е есть MCE, но там заранее понятно, что mce_map какой-нибудь будет пытаться выполнять код в параллельных потоках, но каким образом компилятор должен превращать ваш обычный последовательный код в параллельный? Может быть, тогда уж он ещё за вас код писать будет, да и зарплату получать... тоже?

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

Не маразм. Дело в том, что для решения многих задач недостаточно твоих 128-ядерных систем. И представь, недостаточно иногда даже 50 000 этих самых 128-ядерных систем.

Ииии... Собственно, что месье хотел этим сказать?

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

ты идиот, но таких как ты много, увы.

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

Современные реалии - это одноядерный процессор частотой 560 МГц, память 128 Мбайт, флеш 32 Мбайт.

ИМХО ископаемое.
Я сейчас сходил на Яндекс Маркет, модулей DDR3,DDR3L и DDR4 менее чем 1Gb в продаже(!) просто не существует.
Модули 128 Мб это только DDR1, DDR2 уже от 256 Мб и обе уже вчерашний день.

torvn77 ★★★★★
()

ТС, всегда надо помнить об объёмах данных, которые ты перелопачиваешь. Линейное ускорение в n раз при разбиении задачи на n потоков хорошо, и может быть очень эффективно на относительно небольших объемах данных. Однако принципиальное изменение O(n) на больших объемах даст больше профита. Это как с мелкими оптимизациями, когда на маленьких объемах какая-нибудь пузырьковая сортировка может показать себя лучше QuickSort-а.

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

svr4> А его нет. Видюха по факту (с т.з. программирования, а в случае радиков 2xxx-5xxx и архитектурно) является этакой VLIW-херовиной, а не многоядерным процом.

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

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

dmxrand> man: Преждевременная оптимизация — корень всех зол

Офигенное оправдание не делать оптимизация вообще. Сначала «преждевременная оптимизация - корень всех зол», а потом оказывается, что архитектура так наворочена, что оптимизировать без полного переделывания невозможно, а переделывать заново - это фактически разработка с нуля, так как архитектуру проекта придётся менять. Кидаться где-то там услышанными фразами без понимания их значения - зло.

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

dmxrand> Так я и говорю. Народ обчитается, что все надо распараллелить. Потом обчитается про Эрланг. И потом хочется обнять и плакать.

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

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

dmxrand> Я на работу пришел и там начальник написал софтину. Хорошая была софтина. Но когда оставалось 99% он находил в ней изъян. То библиотека новая выйдет. То алгоритм вот тут можно сделать быстрее... Вот за 10 лет пользователи так эту софтину и не увидели. Было 3-4 тестовых человека. Все очень хвалили (и она была хорошая).

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

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

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

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

эрланга дернуть Си и хоп - эрланг стал числодробилкой

и хоп сегфолт си уносит с собой в ад всю erlang vm, ок

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

Числсодробилки на си пишут только мазохисты. Для этого фортран есть.

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

надеюсь это сарказм

Это embedded.

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

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

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

Модули 128 Мб это только DDR1, DDR2 уже от 256 Мб и обе уже вчерашний день.

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

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

В институте как раз-таки писали чудесные верчения матриц и метод Гаусса. С тех пор оно мне больше не понадобилось ни разу...

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

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

Пример: http://migmit.dreamwidth.org/70250.html

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

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

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

Может быть, тогда уж он ещё за вас код писать будет, да и зарплату получать... тоже?

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

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

да, у нас такое и бывало, всякое ffmpeg, по этому поводу наработана система костылей

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

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

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

На, посмотри: https://ru.wikipedia.org/wiki/Модель_памяти_Java

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

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

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

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

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

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

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

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

даёт эффект умножения эффективности алгоритма на количество ядер

Что, с точки зрения асимптотики, похрен.

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

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

Ещё раз уточняю: академический подход хорош, безусловно, но дело в том, что это не статичный какой-то набор «лучших рецептов на все случаи жизни». Я более, чем уверен, что в передовых компаниях разработчиках-софта уже давно набор алгоритмов, которые они используют если и коррелирует с тем, что преподают в тех же российских ВУЗах или с тем, что написано в замечательных толстых книжках 40-ка летней давности, то разве что неким «логическим ядром» коррелирует. Т.е. идеи, безусловно, все те же, все эти «мыслетрюки» никуда не делись, но составляют они лишь малую часть как такового конечного алгоритма. А вот конечный алгоритм уже не просто учитывает возможности распаралеливания по ядрам, а делает это весьма агрессивно, по принципу «если твой алгоритм не умеет распараллеливаться, то, скорее всего он - Г**но». Мало того, если алгоритм сам по себе не параллелится - распараллеливается логика вычислений: массив данных делится на слайсы - и уже эти слайсы пихаются в параллельно выполняемые треды/процессы, реализующие тот самый последовательный алгоритм.

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

DRVTiny ★★★★★
() автор топика
Последнее исправление: DRVTiny (всего исправлений: 3)

Прошу прощения. Но stevejobs, теперь ты просто обязан восстановить сообщение, которое тебе обошлось такой кровью.

logon
()

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

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

К тому же надо отметить тот факт, что количество человекочасов (а за них надо платить деньги) не имеет прямой связи с объёмом данных для обработки (количеством клиентов приложения и т. д.). А вот требуемое количество серверов - имеет. И в какой-то момент оказывается, что выгоднее нанять кодеров подороже (которые всё лучше оптимизируют), чем удваивать парк серверов.

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

Ну, ок :-) Это был ответ на сообщение пользователя dmxrand на то, что GIL добавлен не случайно.

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

важный инвариант этого ответа: существует конкурентное и параллельное программирование, это важно. Треды нужны для конкурентного, дальше речь идет о нем. Реальность заключается в том, что у нас есть shared mutable state в огромном количестве, тысячи кешей разного уровня ума и фантазии (включая аппаратные), и мы должны над ними выполнять алгоритмы, которые эффективно одновременно меняют одни и те же данные. Причем недостаточно просто дать возможность так делать, нужно еще для программиста имитировать реальность, в которой отдельные треды исполняются как будто бы параллельно и независимо как отдельные программы (хотя это совершенно не так), и что существует какое-то линейное время в котором его инструкции последовательно выполняются (что тоже не так). Так как создание такой системы подразумевает нетривиальные операции, разработка начинает делиться на разработку абстрактной виртуальной машины (по сути - разработку необычайно математически точного стандарта), и разработку физической реализации. Идея в том, что такие понятия как «время» имеют свои определения на уровне абстрактной машины, и пока операция правильно работает с точки зрения этой машины, физическая реализация может выбирать любую последовательность оптимизаций для получения максимально эффективного варианта исполнения. На всякий случай, джавовское happens-before - это не «время», хотя о нем можно для начала так думать, и это понижает порог входа. Поверх этого нужно придумать специальную культуру/дисциплину программирования и стандартную библиотеку, позволяющую писать реальным прикладным программистам реальный прикладной код. Всё вместе это очень сложная задача.

Вы реально считаете, что GIL засунули просто так?

конечно не просто так, а по следующим причинам:

1) Изначально питон делала группа энтузиастов, у которой нет денег на другое 2) Питон изначально рассчитан на широкую аудиторию (включая обучение программированию школьников и студентов), а дизайн-решения 0 дня сложно поменять в будущем

Россум в 94 году сделал язык, работая в институте математики и информатики (и работал там вплоть до версии 1.2). Потом перешел в CRNI и создал проект «программирование для всех» (вплоть до 1.4). Проект финансировала DARPA, ей хотелось, чтобы простые вояки могли накодить простой скриптец, если припечет, но потом финансирование перекрыли (видать, вояки всё таки оказались на уровне живых табуреток). Он не потерял команду энтузиастов с этого проекта, и вместе они выпустили питон версии 2. Пруфы: https://ru.wikipedia.org/wiki/История_языка_программирования_Python

И тема оказалась очень плодотворной, например один из лучших технологических институтов мира MIT заменил Java на Python в качестве средства для изучения программирования (алгоритмов) студентами. Мотивация - в питоне можно думать именно об алгоритмах, а не о ненужных деталях реализации типа конкаренси.

Проблема тут в том, что на самом деле, программирование конкурентных приложений - не для всех. Для этого нужно Очень Серьезно Шарить. (это типа каламбур «шарить» - значит и «разбираться в чем-то», и «делать ресурс общедоступным»).

Конкурентное программирование - это о эффективном использовании shared mutable state. Поэтому существует ряд контрольных вопросов - например, можешь ли ты рассказать о false sharing, и что это для тебя значит. Например, если мы говорили бы о джаве, то для меня это значит, что в коде самого JDK можно писать аннотацию @Contended, а в пользовательском коде - нельзя, можно только окружить важное поле пустыми полями и надеяться, что компилятор/рантайм сохранит порядок полей как в исходнике (что совершенно не факт).

Нет никакого шанса, что школьник или неспециалист может рассказать о false sharing. Даже если школьника будут бить бичом родители, он не успеет прочитать соответствующее количество книжек к этому времени. Необходимость разбираться в таких вопросах для написания кода ставит крест на доступности этого занятия «для всех».

Даже если мы пойдем на уступки и сведем всё к fine-grained locking, как это написано на вики Питона (на самом деле, многие джависты воспринимают это так), то это всё равно куча реального пота. Есть книжки типа Java Concurrency In Practice, которые надо ботанить и обдумывать долгими бессонными ночами. Есть документы типа Шипилевского Close Encounters of The Java Memory Model Kind (тебе это стоит почитать, даже если не кодишь на джаве, просто чтобы ужоснуться: https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/). У меня с этой областью знаний всё еще реальные проблемы.

Но ужасней всего для команды энтузиастов то, что для написания хорошей виртуальной машины для многопоточного кода, нужно тратить на это реально огромное время самых лучших специалистов. В коммунити их немного, а чтобы купить их на фуллтайм - нужно быть или Microsoft (.NET/C#) или Sun (JVM/Java). Или нужно иметь сообщество из ученых, которые по какой-то необъяснимой причине начнут писать свои докторские на основе этого языка. Посмотри на топовых разработчиков Java/C# - там полно докторов CS, которые годами напролёт защищают свои дипломы на вопросах конкурентности в означенных языках. А такое сообщество можно организовать только если например, собрать помешаных на решении сложных конкаренси проблем ученых, и начать им просто так подбрасывать деньги на жизнь и исследования. Для Microsoft/Sun/Oracle/IBM/RedHat/etc это как нефиг делать, кучке хипстеров, в свободное время от работы пишущих «язык программирования для всех» это околоневозможно

Вот так и получилось то, что получилось.

Глум тут в том, что вместо того, чтобы честно сказать - «мы под влиянием идеи о простом языке для всех, а также отсутствия финансирования и комьюнити сделали 0day решения, которые делают невозможным эффективную многопточность, а менять мы их не можем ибо это означает создание совершенно нового компилятора». Вместо этого они начинают придумывать смешные опровдания, в которые может поверить только тот, кто не знает историю и суть проблемы. Или кому просто нужны оправдания, чтобы не чувствовать себя лошарой.

Имхо, вместо этого лучше признать проблему, и решать её. Частично в Питоне она решена в других средах (например, в JPython), а то о чем мы говорим - это исключительно тяжелое наследие CPython

Неверно понимаешь. GIL обоснован на том, что внешние библиотеки могут поменять чтонибудь в объекте причем так, что сломают его.
Собственно вот тебе Python без GIL PyPy
Гвидо ван Россум, заявляет, что GIL не так уж и плох и он будет в > CPython до тех пор, пока кто-то другой не представит реализацию Python > без GIL, с которой бы однопоточные скрипты работали так же быстро PyPy.
И да Гвидо совсем не любитель. И денег на избавления от ГИЛ дохрена.
Пока никто из критиков GIL не смог сделать быстрее.

Это сейчас их дофига. Но не когда история начиналась.

Для примера масштаба проблемы. Была такая задача - сделать джаву модульной, чтобы для хэлловорлда не приходилось тянуть файлы SDK на 300 мегабайтов шириной. Типа копировать в финальную сборку только то, что нужно. Решение этой задачи заняло десять лет. Работы людей, находящихся на зарплате. Прямо сейчас в джаве захотелось немного поменять интерфейс работы с нативными библиотеками, это называется Project Panama. Уже сейчас это заняло 2 года работы людей на зарплате, а в будущем займет еще больше.

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

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

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

Слушай. Ну опять удалят ведь. Прошлый раз ты как светофор был.

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

GIL засунули по следующим причинам:
группа энтузиастов, у которой нет денег
рассчитан на широкую аудиторию

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

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

Часто не так уж накладно форкать задачи-воркеры, а не потоки. IPC SharedMemory никто не отменял, да и чем плох подход, при котором каждый процесс пишет свой результат вычислений независимо от остальных? Т.е. ИМХО нужно всё-таки стараться делать так, чтобы не приходилось вообще ничего блокировать, ибо ИМХО любая блокировка делает локальный кусок кода фактически не параллельным, а последовательным, вынуждая процессы/треды становится «в очередь» за ресурсом.

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

Проект финансировала DARPA, ей хотелось, чтобы простые вояки могли накодить простой скриптец, если припечет,

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

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

Если всё будет хорошо, добавят multicore: https://news.ycombinator.com/item?id=9582980

«What this „multicore support“ means is that you'll be able to have threads in the same process that run in parallel because the GIL is going away. In practice it'll probably be implemented directly into Lwt so you'll be able to do something with Lwt_preemptive and just tell it to run some function in a separate thread and then use >>= to handle its result. It's gonna be simpler than both options I described above.»

Это было в 2015 году

Интересно послушать доводы от окамловцев в пользу GIL, но пока не нагуглил

stevejobs ★★★★☆
()

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

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