Использование Go Go Go Goines для создания сети Bayes

Question

У меня есть большой набор данных философских аргументов, каждый из которых связан с другими аргументами как доказательство или опровержение данного утверждения. Коренное заявление может иметь множество доказательств и опровержений, каждый из которых может также иметь доказательства и доказательства. Выражения могут также использоваться на нескольких графиках, а графики могут анализироваться в «заданном контексте» или предположении.

Мне нужно построить байесовскую сеть связанных аргументов, чтобы каждый узел распространял влияние справедливо и точно на свои связанные аргументы; Мне нужно уметь вычислять вероятность цепочек подключенных узлов одновременно, причем каждый узел требует поиска хранилища данных, которые должны блокировать получение результатов; процесс в основном связан с I/O, и мое соединение с хранилищем данных может выполняться асинхронно в java, go и python {google appengine}. Как только каждый поиск завершается, он распространяется на все другие связанные узлы до тех пор, пока вероятность дельта не опустится ниже порога неуместности {в настоящее время 0,1%}. Каждый узел процесса должен вычислять цепочки соединений, а затем суммировать все результаты по всем запросам, чтобы скорректировать результаты достоверности, с результатами, прикованными наружу к любым связанным аргументам.

Чтобы избежать повторения бесконечно, я думал использовать A-подобный процесс в goroutines для распространения обновлений на карты аргументов с эвристикой, основанной на влиянии компаундирования, которая игнорирует узлы, когда вероятность влияния падает ниже, скажем 0,1%. Я попытался настроить вычисления с помощью триггеров SQL, но он слишком сложный и беспорядочный. Затем я перешел в google appengine, чтобы воспользоваться асинхронным nosql, и это было лучше, но все же слишком медленно. Мне нужно быстро запускать обновления, чтобы получить мгновенный пользовательский интерфейс, поэтому, когда пользователь создает или голосует за или против доказательства или доказательства, они могут сразу увидеть результаты, отраженные в пользовательском интерфейсе.

Я думаю, что Go - это язык выбора для поддержки параллелизма, который мне нужен, но я открыт для предложений. Клиент - это монолитный javascript-приложение, которое просто использует XHR и websockets для толкания и вытягивания карт аргументов {и их обновлений} в реальном времени. У меня есть прототип java, который может вычислять большие цепочки через 10-15 секунд, но мониторинг производительности показывает, что большая часть моей среды выполнения тратится впустую на синхронизацию и накладные расходы от ConcurrentHashMap.

Если есть другие высококонкурентные языки, которые стоит попробовать, пожалуйста, дайте мне знать. Я знаю java, python, go, ruby ​​и scala, но изучаю любой язык, если он соответствует моим потребностям.

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

Answer 1

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

Goroutines довольно дешевы и идеально подходят для современных веб-приложений, которые сильно используют XHR или Websockets (и другие приложения, связанные с вводом-выводом, которым приходится ждать ответов на базы данных и тому подобное). Кроме того, run runtime также может выполнять эти goroutines параллельно, так что Go также хорошо подходит для задач с привязкой к процессору, которые должны использовать преимущества нескольких ядер и скорость изначально скомпилированного языка.

Но вы также должны иметь в виду, что goroutines и каналы не предоставляются бесплатно. Они по-прежнему требуют некоторого объема памяти, и каждая точка синхронизации (например, передача или получение канала) поставляется с ее стоимостью. Это, как правило, не проблема, поскольку синхронизация по сравнению с запросом базы данных, например, чрезвычайно дешева, но может быть не подходит для построения эффективных байесовских сетей, особенно если фактическая работа каждого goroutine/node незначительна по сравнению с накладные расходы синхронизации.

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