я как-то попробовал в julia 1.0 заюзать @thread, ядра загрузились на ура, а по перфмансу выигрыша было 0%

Segfault in Threads.@thread · Issue #19450 · JuliaLang/julia · GitHub
https://github.com/JuliaLang/julia/issues/19450

когда-то rand был not thread-safe, изумительно)

это старый issue, но для <1.3, насколько можно понять, все одинаково

segmentation fault вываливается почти сразу после входа в этот цикл. И это, явно ненормально. Касаемо использования push! в общий массив, вероятно, лучше экранировать мьютексом. На всякий случай….

Show HN: Wave-based non-line-of-sight computational imaging in Julia (Score: 101+ in 2 hours)

Link: https://readhacker.news/s/48wYF
Comments: https://readhacker.news/c/48wYF

В соседнем чате типов в языках программирования появилась интересная идея:
— вспомнить, что когда-то разделились языки представления знаний (сначала был упор на лисп-машины, потом на пролог и логическое программирование, а по факту остался живым CycL) и просто языки программирования. Онтологическое моделирование шло в FOL с расширениями в сторону HOL на этих самых языках представления знаний. Они, конечно, были чрезвычайно тормозными, и проиграли всему.
— но языки программирования оказались все с базами данных, но не базами знаний. Представление информации о мире оказалось не в языках программирования, а в языках баз данных. И вся обработка данных стала в базах данных. Даже на Julia есть JuliaDB, и там ни разу не знания, и аналитика ни разу не логическая.
— но моделирование данных и интеграционные задачи требуют моделирования справочных данных (НСИ и справочные данные) — это значит, что языки знаний с FOL тут важны.
— берём Julia и прикручиваем к ней болтами экосистему современных солверов на FOL с расширениями по типу JuMP, Modia, DifferentialEquation. Гипотеза, что если теперь эти солверы посадить на GPU, то вообще будет огонь — и в Julia появится свой язык представления знаний, моделирования концептуальных схем, интеграции данных жизненного цикла, описания схем баз данных и т.д.
— проблема в том, что это представление знаний требует компактного синтаксиса, который должен быть чем-то похож нотационно на Prolog DCG — https://www.metalevel.at/prolog/dcg или DCTG — http://cmsmcq.com/2004/lgintro.html (и если не очень похож, то будет некомпактно и неудобно по сравнению со специализированными языками)
— бонус от реализации эко-системы FOL на Julia — это одновременная работа со схемами баз данных (языки представления знаний по большому счёту про это — моделирование мира), deep learning, лингвистикой, вероятностными моделями, статистикой и всем остальным из differential programming. То есть идея гибридных логико-нейронных вычислений может отрабатываться на Julia, если в ней будут и численные солверы на GPU, и FOL и даже HOL солверы разогнанные в GPU, с эвристиками (которые сегодня тоже на нейросетках делают и с вероятностными методами логического вывода, много разных развлечений из численных методов).

Если создавать язык представления знаний как eDSL на Julia, то можно ли обеспечить хоть как-то компактный синтаксис по типу этих DCG и DCTG? Ибо люди собираются городить специальный компилятор для такого компактного языка — это у них был бы наследник Пролога и конкурент CycL (оба при этом неплохие языки, но для численных методов они никакие). А я бы хотел такое иметь в экосистеме Julia — и иметь удовольствие смешивать численные и символьные вычисления в одной программе.

Кто-нибудь что-нибудь может сказать про реализацию нотации DCTG в виде eDSL в Julia? Что там нужно будет подхакивать?

Я работаю с компанией делающей Datalog-подобный (это недалеко от Пролога) язык поверх Джулии, но у них парсер отдельный. При этом есть и прототип, который реализован как eDSL на макросах. Запросы записываются как джулишные list comprehensions, а затем передаются в макросы, реализующие нужную семантику.

Если вы когда-нибудь слышали про LogicBlox, то вот они делают примерно такое на Джулии (и это даже те же люди)

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

Я не знаю что такое dctg, просто предлагаю вам подумать над возможностью описывать ваши запросы в виде list comprehensions (стандартная конструкция в Джулии) и сдавать их в макросы на интерпретацию. В похожих задачах это приводило к успеху

Чат про типы в языках программирования/моделирования/представления знаний и обсуждение всего этого с самого начала (чату целых два дня от роду, а джулия поминается там в практически всех моих репликах) — https://t.me/typeslife

Пример нотационных решений  DCG и DCTG в Prolog кратко вот здесь: http://cmsmcq.com/2004/lgintro.html

Спасибо, я просто сейчас не готов изучать расширения Пролога: мне хватает моего диалекта Даталога…

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

Спасибо за приглашение! Подумаю.

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

Я вообще-то немного из под палки работаю с этим Даталогом. Душа больше лежит к типам в смысле System F и функциональному программированию

Просто тема Datalog там подробно не разворачивалась, некому было развернуть. А я тащил в сторону Julia. ))) И сообщений там за полтора дня, действительно, огромное количество.

Про типы в функциональных языках есть книжка https://pragprog.com/book/swdddf/domain-modeling-made-functional — и я вот мечтал бы такую иметь для Julia. Но некому, увы, написать!

Любопытно, спасибо! Интересно, что там F#