LINUX.ORG.RU

В кои-то века родил статью по своей питоновой либе

 ,


2

1

https://habr.com/en/post/526002/ — Making python's dream of multithreading come true

Хотелось написать что-то для прочтения буграм, но и вам запощу, так и быть. Буду благодарен, если кто-то запостит это на reddit.com/r/python и даст ссыль сюда, потому что мне еще две недели нужно ждать, пока аккаунту разрешат делать посты.

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

В частности, написание статьи само по себе помогло сообразить, что без механизма каналов особо нечего ловить в прикладнухе. Причем, я уже знаю, как эти каналы можно сделать гибкими на зависть Go-шникам, потому что это будет не прибитый гвоздями к языку черный ящик, а отдельные примитивы синхронизации и хранилище аля std::deque, для которого можно как быстро в lock-free режиме добавлять и забирать записи, так и выполнять на самом питоне сложные транзакции плана «выбрать записи определенного типа из очереди» — не блокируя при этом lock-free добавление новых сообщений и не блокируя параллельных читателей. То есть, в одном флаконе умещаются любые сочетания взаимодействий производитель-потребитель. Конечно, я подозреваю, что алгоритмы на питоне будут тормознутыми, но что ж поделать, это питон.

★★★★

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

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

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

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

«-» в том, что «критики» много будет. «+» что помощь /скорее всего/ будет.

PS: Через какое-то время если код будет на C/C++ обязательно поработаю с исходниками.
Пока «параллельной работы» не реализовал /нужно, но не приоритетно/.

PS: Хорошая и нужная у вас задача.
Постарайтесь не прибить API гвоздями к гадюке.

Владимир

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

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

Может быть «декораторы» в Python добавить для переменных, функций, … к котором возможен доступ из нескольких потоков, … /вариации на тему/?

У меня этот вопрос решен так - каждое поле объекта может иметь свойства /любого вида сложности и иерархии/.

Надеюсь понятно зачем?

Владимир

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

У меня этот вопрос решен так - каждое поле объекта может иметь свойства /любого вида сложности и иерархии/.

Конечно и объект может иметь свойства.
Тем самым объект и поля могут иметь семантические свойства, права доступа, алиасы, …, …, …

Владимир

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

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

А он (статический анализатор) должен это уметь? Поставлю более общий вопрос: каким образом повышается качество твоего кода; откуда ты вообще знаешь, что то, что ты там напрограммировал делает то, что ты хочешь?

PS: и что такое ют?

юнит-тесты

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

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

anonymous
()

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

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

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

… но для страдающих ИдиоМетапрогоСинкразицией лучше бы запилить его вариант на великом и могучем ИдиоПитоПроге …

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

Конечно и объект может иметь свойства. Тем самым объект и поля могут иметь семантические свойства, права доступа, алиасы, …, …, …

Все «декораторы» в разных языках программирования от того, что

Слышали звон, да не знают где он

Владимир

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

для страдающих лингвистической идиосинкразией

Если есть про что проблеять миру, надо блеять. Стиль вырабатывается потом. Когда-то писал в онлайне и на бумаге, на инглыше и у дойчеров, на почившем в бозе IBM developer network, и даже у мелкософта (вот ведь поганец, ага). потом в жизни произошли фундаментальные огорчения и малость подзасох. Как бы и надо бы и с мыслями подсобраться уже.

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

… и конечно не большевики у которых «разработка» построена так

До основания все разрушить ...

Владимир

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

ведь

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

Дай объявление что-ль. А то маешься дурью.

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

А то маешься дурью

Дружище, сколько же у тебя «в запасе» ведер с помоями?
Злой ты дядя.

Владимир

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

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

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

Да, я думал о том, что неплохо было бы для отладки этой моей штуки слабать свои инструменты, которые бы умели анализировать сквозь границы процессов. Но пока что леплю на коленке, через массовые assert-ы. Если быть точным, то не совсем assert-ы, а специальный обработчик, который при ошибке проверки условия останавливает все процессы для их проверки отладчиком. Самое удобное здесь то, что, в отличие от логов, такой подход не ломает течение программы, в отличие от логов. В том числе на этих обработчиках я реализовал проверку racing condition через банальный атомарный инкремент/декремент счетчиков на входе и выходе из функций доступа.

Еще есть такая годнота, как rr — но это уже тяжелая артилерия, которая больше актуальная для отладки на пользовательской машине, а не разрабовской.

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

В случае анализаторов для C/C++ они «скорее всего» найдут ошибку, по крайней мере простую и очевидную.

ну так, хотя бы самые легкие, «лоховские» ошибки нашел? Или философия такая: «если нельзя верифицировать параллельную логику - то и на примитивные ошибки наплевать»?

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

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

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

Здесь есть проблема, которую я недавно увидел в ядре линя, а именно — «наверное это будет работать». То есть, баги загоняются в области 1/100'000'000'000, когда за пятдесят лет работы он воспроизведется пару раз, которые оба спишут на аппаратный сбой. Вот если бага проявляется несколько раз в год — тогда зовут Торвальдса и он фиксит багу.

Я же, по крайней мере в своем проекте, проповедую иной подход: прохождение тестов не значит ничего; корректность работы определяется безупречной целостностью памяти по окончанию работы при условии прохождения работы по всем веткам, в том числе очень редким — для насильного захода в необычные ветки применяются отладочные флаги, активирующие ветку по условию вроде «rand() % 23 == 0». Вот чтобы эту штуку автоматизировать и дать хоть какую-то гарантию, что я не пропустил какую-то ветку или комбинацию веток, я бы и хотел какой-нибудь инструмент.

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

ну так, хотя бы самые легкие, «лоховские» ошибки нашел? Или философия такая: «если нельзя верифицировать параллельную логику - то и на примитивные ошибки наплевать»?

Мне кажется, что ты не представляешь, что такое множественная read-write блокировка с честностью. Все, кто до меня подумывал о реализации подобной штуки, просто соснули. Как правило, RW-блокировки пишутся для короткого доступа, желательно к одному ресурсу, и «билеты» они получают для одной-единственной блокировки. У меня же билеты глобальны, одна блокировка может быть отменена по конфликту в другой блокировке по глобальным билетам, и при этом желательно, чтобы после конфликта низкоприоритетная задача ждала окончания работы высокоприоритетной — последнее условие у меня не всегда выполняется, поскольку есть адовые варианты конфликтов, при которых не ясно, кто, кого, и когда вообще должен ждать. Потому что, напоминаю, пользоваться данными под одной блокировкой может большое число процессов, если они, например, только читают данные. Но еще может оказаться, что читатель решит стать писателем — и тогда ему нужно будет искать, кого ждать, а кого убивать. При этом другие задачи так же могут кого-то ждать и кого-то убивать, как по этой, так и другой блокировке.

Так вот, я добился 100% корректного выполнения, без дедлоков и без одновременного доступа к ресурсу. По крайней мере, на достаточно скромных наборах данных и 2-3 блокировках одновременно взятых.

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

Мне кажется,

понятно, значит, философия именно такая, как я написал выше

Так вот, я добился 100% корректного выполнения

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

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

без формального доказательства это болтовня

Ты когда-нибудь пробовал формально доказать хоть три строчки lock-free кода с доступом к двум ячейкам? У меня где-то валялось формальное доказательство корректности алгоритма lock-free очереди на десяток строк кода — что-то вроде двух страниц текста доказательства. Выделение-высвобождение памяти, естественно, осталось за кадром в виде безупречно работающего черного ящика.

Это сложная задача даже для нескольких строчек, а у меня RW-блокировка занимает примерно 600-700 строк! Формальное доказательство этого кода влезет в томик на один-два килограмма.

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

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

Сорян, конкретно сейчас времени свободного почти нет. Кое-как разве что вам успеваю отвечать, а там статья почти на 20 тыс символов — ну нее нафик.

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

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

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

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

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

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

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

Владимир

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

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

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

Сделай этот, как его, pymorphy2, там скорости фантастически не хватает и распараллелить многое можно в теории.

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

У питона одна очень-очень сильная сторона, которой нет ни у одного другого языка. На нём очень легко сделать фигак-фигак и готовое решение

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

На нём очень легко сделать фигак-фигак и готовое решение, которое можно повторно использовать

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

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

Насколько я понял, основная идея приведена на картинке в разделе Lazy vs Eager. Остальное - детали реализации и всем известная теория. Вопрос: возможно ли вместо рестарта транзакции в младшем потоке использовать умные локи, которые блокируют младший поток, когда он дошёл до любого из данных, которое будет использоваться в начавшейся транзакции старшего?

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

Так вот, я добился 100% корректного выполнения

ну это мы еще посмотрим :D

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

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

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

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

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

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

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

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

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

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

Довелось немного покодить на lisp, smalltalk, lua, bash, java, kotlin, js, 1С, vala, pascal, perl, php, scala, basic, C#, C, C++, Rust, FASM, всякие matlab-ы и scilab-ы с их внутренними языками очевидно тоже, очевидно что и SQL тоже. То что они не все в профиле указаны, значит что опыта у меня в них слишком мало, чтобы про них писать или они мне не нравятся по тем или иным причинам (1С, lua). Так что обзорный охват всякого говна у меня даже слишком большой, чтобы с ним уметь правильно работать, но чтобы представлять вокруг чего там вся идея крутится ИМХО достаточно.

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

Довелось немного покодить на lisp, smalltalk, lua, bash, java, kotlin, js, 1С, vala, pascal, perl, php, scala, basic, C#, C, C++, Rust, FASM, всякие matlab-ы и scilab-ы

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

При всей скорости использования готовых функций на питоне, написание собственных приводит к открытию той боли и страданий, которые испытывали создатели готовых решений, которыми ты до этого пользовался и не подозревал о цене этих решений. Причем, питон абсолютно никак не облегчает эту задачу по сравнению с Java/C#/C++, и даже наоборот, не имеет ряда фич (например, статической типизации), которые облегчают написание готовых решений. По этой причине питон выглядит привлекательно для чего-то немного сложнее hello world, но по мере роста сложности очень быстро становится очевидно, что недостатки сильно перевешивают преимущества. То есть, грубо говоря, в крестах сложность разработки растет как k1*N^2, а в питоне — k2*N^3, где N — условная сложность задачи.

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

Вот не надо тут про C# задвигать и питон, а так же их простоту поддержки, вот на этих языках я собаку съел. Динамика и статика это вкусовщина на самом деле, не более. Культура разработки решает, если её нету, то тебе никакой ЯП не поможет и она разная для этих языков. То что хорошо для питона не всегда хорошо для C# и наоброт. Просто не надо ходить в чужой монастырь со своим уставом и всё будет нормально.

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

Динамика и статика это вкусовщина на самом деле, не более.

Согласен, как и любые проверки компилятора.

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

Динамика и статика это вкусовщина на самом деле, не более.

Все зависит от задачи.
Как «грабли» полезны для некоторых задач, как и «микроскоп».

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

Владимир

anonymous
()

https://habr.com/en/post/526002/ — Making python’s dream of multithreading come true
Хотелось написать что-то для прочтения буграм, но и вам запощу, так и быть.

Бугры молчат …
Наверное там «бугров» нет.

А мы вот «кочки» пытаемся вести диалог.

Владимир

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

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

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

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

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

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

Не для ТС, а «кочек» /меня это не задело «ни как». Шучу однако … /.

Гуглите «Java одновременный доступ к переменной» и «вариации на тему».

Владимир

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

Я не привязываю мои рассуждения к питону, …

И правильно.
Не знаю прав или нет, но пока считаю, что не всякий алгоритм можно распараллелить.
Может быть и можно, но код должен быть «пригоден» для распараллеливания.
Впрочем в OpenMP эти вопросы красиво решены. Тема - СУПЕР!

Владимир

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

Может быть и можно, но код должен быть «пригоден» для распараллеливания.

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

Вот маленький пример. Имеем исходный код
int iSum = 0;

for ( int i = 0; i < 100; i++ ) iSum += i

Можно преобразовать в int iSum01 = 0;

for ( int i = 0; i < 50; i++ ) iSum01 += i

Второй поток int iSum02 = 0;

for ( int i = 50; i < 100; i++ ) iSum02 += i

Результат iSum01 + iSum02.

«И коллизий нет, а хорошо жить еще лучше»

Владимир

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

Ок, теперь распараллельте вычисление N-го числа Фибоначчи.

О чем и речь /см. сказанное выше/!
Не все алгоритмы можно распараллелить.

Владимир

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

… теперь распараллельте вычисление N-го числа Фибоначчи.

Не к спору, а продолжению дискуссии.
Все же можно, если будем использовать формулу Бине
https://ru.wikipedia.org/wiki/Числа_Фибоначчи

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

А вот «учетные» задачи типа 1С, пожалуй можно эффективно параллелить.

Владимир

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

Все же можно, если будем использовать формулу Бине

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

F(1) = 1
F(2) = 1
F(3) = 1
F(4) = 1
F(n) = F(n-1) - F(n-2) + F(n-3) / 2 + F(n-4), n > 4
Kogrom
()
Последнее исправление: Kogrom (всего исправлений: 1)
Ответ на: комментарий от Kogrom

F(n) = F(n-1) - F(n-2) + F(n-3) / 2 + F(n-4), n > 4

Well, well, well!

В 1С 7.7. /хоть она и древняя/ многие обобщенные алгоритмы легко не только писать/генерировать.
Интересно как в C++ с учетом новых фишек в compiltime можно реализовать этот алгоритм …

Владимир

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

Бугры молчат …
Наверное там «бугров» нет

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

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

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

Одна из ближайших задач будет - генерация и обеспечение выполнения кода на основе использования run-time объектов /переменная это
тоже объект, …, …, …/ без использования JIT или VM.

Фишка в том, что можно будет использовать динамический код в C, C++, 1С, Python, PHP, … и конечно https://ru.wikipedia.org/wiki/Brainfuck.

Владимир

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

Надеюсь, автор темы не обидется за оффтоп

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

Мне это интересно, так как я планировал для embeded диалект своего языка делать. Но пока время есть только на то, чтобы осваивать средства разработки, которые предоставляет изготовитель контроллера.

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

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

Скорее всего очень интересная задача.
Приходилось мне лишь с PIC поработать.
Те задачи, которые ныне первоочередные считаю «нужными».
Run-time подсистему можно будет использовать конечно и в микроконтроллерах.

Для меня задача N1 - GUI /2D и 3D/.

Владимир

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

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

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

Владимир

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