Обсуждение

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

Нет, не мог бы. Любая каталогизация проигрывает полнотекстовому поиску, в том числе и потому что интересы со временем (в том числе и других людей, которые совсем необязательно видят мир через сетку моих тегов) меняются, и в старых текстах люди вычитывают новое содержание, новую рубрикацию. Вот тут я в 2009 году на эту тему подробно: https://ailev.livejournal.com/715272.html, вот тут ещё дискутирую: https://ailev.livejournal.com/715018.html?thread=6418954#t6418954 Я сам пользуюсь полнотекстовым поиском. Например, в Гугле вы можете искать по моему блогу более-менее полноценно (хотя полноту я и не проверял), вставляя в строку с запросом site:ailev.livejournal.com

> Какая-нибудь большая толстая фирма заявит, что будет программировать на чём-то Ага... Например Микрософт... Например на R :) > DSL Ну просто вот есть и tf, и CNTK, и theano, и H2O, и всякие sparkи с хадопами. И сам R теперь умеет в матрицы бесконечного размера на безразмерных кластерах в конечное время. Что касается (e)DSL, то весь R это куча (e)DSL и всякого прочего сахара поверх Схемы. Все в духе SICP --- покоряй сложность как только смогло придумать человечество.

За играми питонов и прочих животных смотрю со стороны (работаю на Python, всё больше JS и всё реже R). Учитывая количество пользователей и всё возрастающую популярность JavaScript и производных, учитывая тренд на переход в веб, учитывая, что JS зашёл на серверную часть, учитывая неустанную работу над компиляторами и увеличение оперативной памяти машин, создание гибкого распределённого суперкопьютера с вычислениями на JS кажется мне ожидаемым. > поспекулировать о том, что Julia (как и Фортран, как Си) это суперкомпьютерный язык, а Python -- не очень. Питон не может в GPU, в этом его беда. Python в том числе является функциональным языком, есть библиотеки для векторных и многопоточных расчётов, как и библиотеки для GPU рассчётов. Я не понял, почему Python не может в GPU.

эпиграф, кстати - адаптированное "Greenspun's tenth rule"

Питон не может внутрь GPU, он же интерпретатор по сути -- а компиляторные его версии пока весьма специфичны и имеют свои родовые ограничения. Вот я не могу написать кусок параллельного питоновского кода и отправить его выполняться в GPU. А в Julia это делается, например, через CUDAnative.jl

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

Вы рассматривали возможность из следующей статьи? https://developer.nvidia.com/how-to-cuda-python (первое видео -- установка, второе -- показ простого примера)

Не знаю как сейчас, но в самом начале SAP PredictiveAnalytics являлся визуальной оболочкой R, была интеграция с SAP HANA.

К слову, Вы оценивали-экспериментировали-работали R через микросервисы в контейнерах? В частности, с удобной и быстрой разработкой REST API для i/o R скриптов?

Так это Numba и её компилятор! Конечно, это решает некоторые проблемы для питонистов. Но не все. Когда стартовали разработку Julia, этих примочек к Питону ещё не было, сейчас они есть и довольно бодро развиваются -- и в сообществе Julia признают, что их наличие немного замедляет переход людей на Julia. Но там решается часть проблем, целиком "проблему двух языков" (отладочного медленного и быстрого для целевой версии) это не решает, ибо в Питоне есть родовые травмы, препятствующие его а) эффективному компилированию в б) параллельный код. Поэтому-то там с 1989 года такой небольшой прогресс. Зато людей уже много, силы на эту экосистему немеренные тратятся сейчас. Даже то, что не должно компилироваться, придумывают, как будет откомпилировано ))) Julia заходит просто с другого конца, явно опираясь на свои средства для метапрограммирования. Но людей по сравнению с экосистемой Питона пока мало, так что всё не очень быстро получается. В любом случае, я от сообщества людей Julia слышу главным образом счасть е и радость -- разве что тяжело им, бедненьким, от пока непрерывных breaking changes. Питон свой переход от 2.7 к 3.6 ещё ведь тоже не полностью преодолел, эта беда и там есть )))

> Но там решается часть проблем, целиком "проблему двух языков" (отладочного медленного и быстрого для целевой версии) это не решает, ибо в Питоне есть родовые травмы, препятствующие его а) эффективному компилированию в б) параллельный код К сожалению, теоретическое и прикладное невежество не позволяет мне оценить истинность высказывания. Нашёл статью 14 года в которой числами обосновывается утверждение "проблемы GIL в Python для численных расчетов практически преодолены". https://habrahabr.ru/post/238703/ В формальной логике общие утверждения (А типа) "все С являются П" опровергаются единственным истинным утверждением (О типа) "некоторы С не являются П", тогда как утверждения (Е типа) "нет С которые П" опровергаются хотя бы одним утверждением (I типа) "некоторые С являются П". В рамках формальной логики, (Е) утверждение "Питон не может в GPU" опровергается моим (I) примером использования нумбы. (А) утверждение "Питон может в GPU" опровергается (О) примером несостоятельности питона в GPU, но из-за уже упоминавшегося невежестве не могу понять, является ли упоминание родовой травмы таким утверждением или нет, -- если упоминание родовой травмы является отсылкой к GIL, то статья показывает обратное.

Вот я поэтому и хочу сделать современный курс логики, где аристотелевщина преодолена и работаем с байесовскими оценками. Нет никаких чёрно-белых высказываний, везде распределения вероятностей. Если из 20 каких-то операций 5 засунули в GPU (цифры абстрактны), это не означает, что проблема полностью решена -- но в формальной логике это невыразимо. Мой любимый пример -- это https://en.wikipedia.org/wiki/Universal_approximation_theorem (нейронная сеть с одним скрытым слоем универсальна! только толку от этого нет: вычислительно там запредельно плохо становится с ростом сложности функции. Поэтому решение только в глубоких сетях, а не в теоретически верных обычных). Поэтому меня переход к формальной логике только печалит в таких случаях, когда оценивается одновременно производительность, универсальность, высокий уровень абстракции языка и т.д.. Аристотелевская логика тут туманит, а не проясняет. И уж точно ничего не доказывает.

В docker чтобы положить оценивал несколько, опыта эксплуатации пока нет (как хватало всегда ZeroMQ). Вот пока два осталось "к выбору" :) "совсем микро но просто туча" https://www.opencpu.org/ и "просто сервис" https://cran.r-project.org/web/packages/plumber/index.html

Если в GPU засунули необходимый минимум (а там вообще минимум и реализован), то любое вычисление реализовано.

Упомянутые правила являются частью современной математической логики, хотя и привязаны к классической. Эта бинарная логика безусловно полна ограничений, и по мнению Александра Александровича Зиновьева, в двадцатом веке логика ушла от богатства логических работ девятнадцатого века, но бинарной "классической" логике нельзя не отдавать должного. Поэтому перебегая от метода к методу, я в итоге решил плотно ознакомиться с бинарной, и только после переходить ко многозначной логике, выдерживая в русле математической логики, ибо оная предполагает возможность переложить рассуждения в компьютерную модель. Я не знаю что такое байесова логика, в голову приходит теорема Байеса из теории вероятности, и можно предположить, что байесова логика является подвидом многозначной логики, в которой (1) ложь-истина вычисляется "вероятностью" от 0 до 1 и (2) оценка вероятности/истинности одной утверждения может повлияеть на вероятность/истинность другого утверждения. При этом, предполагая участие теоремы Байеса в этих вычислениях, эти выводы/вычисления должны проходить в рамках заранее сформулированных понятий со связями между оными. И если понятий со связями нет, то ни байесова вывода, ни формального не получится. Я как-то интересовался выводом пользуясь статистическими методами, значимой частью которого является проверка статистических гипотез. На правах ознакомления пришлю неполную схему, которая с формальной точки зрения проста, но использование в большой работе требует валидации и уточнений по каждому элементу и связи, что, в зависимости от уровня теоретической и методологической подготовки человека, уйдёт от нескольких человекомесяцев до нескольких человеколет. Статистику и теорию вероятности тоже можно переводить в компьютерные модели, но до проработанной символической логики требуется проделать гигантское количество работы, и я не уверен, что она под силу одному человеку вне зависимости от остроты ума, широты познаний и количества чугуния пятой точки. Возвращаясь к питону через GPU. На мой взгляд, показать ограниченность питона можно и в рамках формальной логики. Сейчас же позиция такова. Мой текущий длинный проект может потребовать больших вычислений в режиме реального времени, как минимум часть которых потребует большого количества одинаковых операций, а значит перевод в GPU может стать верным архитектурным решением. Учитывая сомнительность поспешной оптимизации, микросервисную архитектуру, потребность в вычислениям можно будет удовлетворить в том числе оптимизацией кода (на питоне) или размножением контейнеров. И только если методы "родной" питоновской экосистемы станут недостаточными, если Питон действительно не может сам в GPU (я пока видел обратные примеры), часть микросервисов можно будет переписывать на другом языке, например, Julia.

Для ознакомления с Docker советую обратить внимание на книгу Docker in Practice. Спасибо.

Хотя за год эксплуатации активной всего стека (уж слишком часто все это хозяйство обновляется что бы держать в основной системе) в docker вроде всё устраивает, однако непременно почитаю, вдруг чего недопонялТМ из официальной документации с сайта проекта.

Сам я только начинаю использовать Docker, из-за архитектурных требований к проекту. Исходя из опыта изучения разных прикладных дисциплин, в новой предпочитаю основательно вникать в базу, и лучшим для этого началом считаю изучение оной по правильным книгам, которые иногда можно найти только перебором стопки. Правильная книга структурирована по задачам, и каждая задача сопровождается достаточным количеством примеров и пояснений, в том числе и по компонентам с концепциями. Таким образом, книга даёт полноценный концептуальный аппарат (концепции, правила применения) с примерами использования оного. Упомянутая книга является правильной, и что более важно -- значимо повышает зрелость рабочей культуры разрабочика ПО, как бы ни на уровне TDD.

Вот свежая статья, в которой подробней разъясняется про подход к GPU со стороны Python и Julia: https://arxiv.org/abs/1712.03112