Здравствуйте, Evgeny.Panasyuk, Вы писали:

I>>И что тебя смущает ?

EP>Привёл ссылку где рассказывается как Python может вызывать C/C++/Fortran библиотеки. Что сказать-то хотел?

Спасибо, капитан, а я то думал, что Питон в 100% случаев именно так и работает, а оказывается, так оно и есть.

I>>Посмотри какие либы используются для научных вычислений. Там довольно часто код пишется дольше чем работает.

EP>Какой-нибудь FEM (которых только в РФ штуки 4 из известных) — требует много вычислительных ресурсов.
EP>Причём аппетит приходит во время еды — более мелкая сетка, разные сочетания нагрузок, нелинейные материалы, динамика, mesh optimization, progressive collapse analysis и т.д и т.п. При добавлении какого-либо нового свойства — время расчёта увеличивается на порядок, а то и несколько.

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

I>>И в итоге, все суммировав, получится в лучшем случае как-бэ-функциональный-дсл,

EP>Да нет никакого DSL — просто библиотека, в худшем случае — framework.

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

EP>unsafePerformIO можно запретить, вся связь с внешним миром, в том числе с библиотеками, будет идти строго через монаду IO — получится действительно чистое ФП. Разница для разработчика будет минимальной.
EP>Так вот, мой тезис в том, что такое чистое ФП — плохо мэппится существующее железо, а не в том что элементы ФП не нужны.

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

Здравствуйте, Klapaucius, Вы писали:

K>

K>fibs = fix $ (1:) . (1:) . (zipWith (+) <*> tail)
K>fibs !! 100
K>573147844013817084101
K>

[...]
EP>>Соответственно понадобится boilerplate для их определения: Lazy<T>, LazyList<T>, каррированные cons, zipWith, etc.
EP>>Пример выше запишется вот так:
EP>>

EP>>auto fibs = fix(cons(0) * cons(1) * (zipWith(plus) <ap> tail));
EP>>

Где * это композиция функций, а <ap> — это соответствующий named operator.
K>Когда я говорил "попробуйте написать" — имелся в виду работающий код, а не псевдокод.

Так это и есть работающий код:

gentoo fibs # tail -n 6 main.cpp && clang++ main.cpp -std=c++1y -stdlib=libc++ && echo _____ && ./a.out
int main()
{
   auto fibs = fix(cons(0) * cons(1) * (zipWith(sum) <ap> tail));
   auto x = fibs <at> 101;
   cout << x << endl;
}
_____
573147844013817084101

Вот только смысла так писать нет — итеративная версия будет и проще и быстрее.
Но если нужна действительно быстрая версия, то посыпание синтаксическим сахром ничем не поможет — нужно использовать подходящий алгоритм, типа ((1,1),(1,0))^n*(1,0).

Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Подробнее.
EP>Основа для зелёных потоков есть и там и там — в C++ stackful coroutine, в D — fiber. Нужна инфраструктура в виде библиотек/фреймворков. Но это всё-таки нельзя назвать интерпретатором.
Насколько я помню, всё упиралось в модель памяти. Возможно, всё это обходимо в C++ и/или D.

Здравствуйте, alex_public, Вы писали:

_>Не забываем, что задачка у нас: "добавить optional в старый код, вообще не меняя его". Т.е. разговор вообще то был не о том как делать собственно преобразование (это думаю всем давно очевидно), а как его автоматически добавить в код.
Так и есть. Всё отличие "нового" кода от "старого" — это замена части аргументов с X на Monad<X>. А дальше начинаем замены.
Что смущает-то? Если брать "обычный" процесс разрешения имён из языка вроде C++, то всё работает почти как обычно. Вот мы видим обращение к somefunction(expression), где expression имеет статический тип Monad<X>. Если у нас в scope есть подходящая функция с таким именем, принимающая Monad<X>, то всё в порядке. Если нет — начинаем искать функцию с таким же именем, принимающую X. Если нашли — то смотрим на тип результата. Если он уже Monad<Y>, то заменяем somefunction(expression) на bind(somefunction)(expression). Если тип результата Y, то заменяем somefunction на bind(unit(somefunction))(expression).
После этого процесс вывода типов продолжается дальше как обычно.
Для многоаргументных функций всё это несколько осложняется, но в целом принцип точно такой же.

_>P.S. Кстати, bind осуществляет не лифтинг (создание новой функции), а непосредственно применяет функцию к монаде.
Странно. Мне казалось, что у неё сигнатура (в терминах C#) именно

Function<Monad<A>, Monad<B>> bind(Function<A, Monad<B>> func)

_>Хотя это на суть дела не влияет
Вот именно. В ленивом языке не очень важно, возвращаешь функцию или сразу её результат.

Здравствуйте, alex_public, Вы писали:
_>А что здесь подразумевается под "подобной архитектурой"? Модель акторов или же вообще весь Эрланг с его прологоподобным синтаксисом, хитрой распределённой средой исполнения и ещё кучей всяких нюансов? Если первое, то это уже давно без проблем делается соответствующими библиотеками. Ну а если второе, то действительно получится что-то вроде написания интерпретатора Erlang'а и такое нафиг не нужно.
Главное — его модель многозадачности, где помимо green threads есть передача владения, и в итоге получаем адскую скорость разбора пакетов, офигенные гарантии изоляции (т.е. поломанный актор не может ни попортить память других, ни отожрать 100% CPU), плюс горячую замену кода.
Сделать что-то отдалённо похожее — можно, но либо ценой перформанса, либо ценой надёжности.

Здравствуйте, alex_public, Вы писали:
_>Исходные коды, из которых генерируется бинарный код, полностью типизированы. А то, что копилятор не обращает внимания на куски исходников, не используемые для генерации бинарного кода, никак не снижает уровень типизации.
Оппонент намекает на то, что разработка библиотеки на таком языке — адски трудное занятие. Отсутствие типизации означает, что компилятор откладывает проверку кода не просто до "генерации бинарного кода", а до "генерации бинарного кода, которая происходит очень далеко в пространстве-времени от написания шаблонного кода". Наш гипотетический монадно-ориентированный компилятор мог бы (и должен был бы) прямо во время компиляции монады, скажем, optional сказать нам "вы неправильно описали монаду — у вас функция bind имеет неверный тип аргумента. Ваш optional — это функтор". Или "ваши определения unit и bind нарушают требования к монаде".
И всё это — до того, как мы попробуем привинтить этот optional к конкретному типу.

_>Ну так это же опять не компиляция в исполняемый код (как и в том случае в Хаскелем при соответствующей оптимизации), а просто некое переформатирование исходников. )))
Речь не о переформатировании исходников, а об объёме анализа, проводимого во время этого переформатирования.

_>Что-то вы всё время придумываете некоторые мысли за меня и потом успешно с ними боретесь. ))) Я же чётко противопоставлял скорость обобщённого кода и раздельность компиляции, а не типизированность и раздельность компиляции.

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

Здравствуйте, Ikemefula, Вы писали:

I>Я немного не понимаю, для чего здесь С++. Это чисто математическая задача — накидать решение хоть в чем угодно, а потом сгенерировать тупой максимально быстрый код.

Всё зависит от масштабов. Во многих случаях делают именно так, как ты описал. И для этого у учёных есть любимейший инструмент под названием Mathematica. Он позволяет с помощью символьных вычислений получить что-то типа конечной формулы, а потом автоматом сгенерировать из неё рабочий C код. Именно за эту возможностью многие отдают деньги за лицензию на Mathematica. Естественно профессиональный программист на C++ без проблем сделает код оптимальнее, чем Mathematica, но не приставишь же такого к каждому учёному. Конечно некоторые учёные могут ещё фортране что-то накидать, но там чаще всего мрак выходит.

Однако решение выше подходит для какого-нибудь учёного, считающего свою задачку на обычном лабораторном сервере. А если речь заходит об огромных кластерах или вообще суперкомпьютерах, то цена вопроса уже существенно возрастает. И тогда между учёными и компьютером всё же ставится команда программистов, которые чаще всего работают на C/C++.

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

I>Такое чистое ФП нужно там, где архитектура вычислителя другая. Если ты хочешь гонять код ровно в одном ядре, то конечно императивный язык здесь заруливается всех в минуса, я про то уже писал около десяти раз за последние полгода.

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

Здравствуйте, Sinclair, Вы писали:

S>Так и есть. Всё отличие "нового" кода от "старого" — это замена части аргументов с X на Monad<X>. А дальше начинаем замены.
S>Что смущает-то? Если брать "обычный" процесс разрешения имён из языка вроде C++, то всё работает почти как обычно. Вот мы видим обращение к somefunction(expression), где expression имеет статический тип Monad<X>. Если у нас в scope есть подходящая функция с таким именем, принимающая Monad<X>, то всё в порядке. Если нет — начинаем искать функцию с таким же именем, принимающую X. Если нашли — то смотрим на тип результата. Если он уже Monad<Y>, то заменяем somefunction(expression) на bind(somefunction)(expression). Если тип результата Y, то заменяем somefunction на bind(unit(somefunction))(expression).
S>После этого процесс вывода типов продолжается дальше как обычно.
S>Для многоаргументных функций всё это несколько осложняется, но в целом принцип точно такой же.

Ну так а в каком языке подобное возможно? ) И если предположим возможно, то благодаря каким-то особым свойствам языка или благодаря особым свойствам монад? )

S>Странно. Мне казалось, что у неё сигнатура (в терминах C#) именно
S>

S>Function<Monad<A>, Monad<B>> bind(Function<A, Monad<B>> func)
S>

Нет, bind возвращает Monad<B> и именно поэтому можно писать код вида monad>>=func1>>=func2>>=func3. И кстати как раз заменой подобного и является do сахар в Хаскеле, ну разве что он позволяет ещё вставить другие вызовы между элементами цепочки.

Здравствуйте, Sinclair, Вы писали:

S>Главное — его модель многозадачности, где помимо green threads есть передача владения, и в итоге получаем адскую скорость разбора пакетов, офигенные гарантии изоляции (т.е. поломанный актор не может ни попортить память других, ни отожрать 100% CPU), плюс горячую замену кода.
S>Сделать что-то отдалённо похожее — можно, но либо ценой перформанса, либо ценой надёжности.

Без проблем это всё делается на C++. Например вот http://www.theron-library.com/index.php?t=page&amp;p=tour1 интересное решение. Ну т.е. конечно небольшая разница есть. В том смысле, что т.к. C++ позволяет иметь самый низкий уровень доступа, то при желание можно без проблем обмануть библиотеку и сломать модель. Но это если специально стараться (в Эрланге такое даже при этом не выйдет), а если следовать правилам библиотечки, то получается абсолютно такой же быстродействующий и надёжный код.

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

Здравствуйте, Sinclair, Вы писали:

S>Оппонент намекает на то, что разработка библиотеки на таком языке — адски трудное занятие. Отсутствие типизации означает, что компилятор откладывает проверку кода не просто до "генерации бинарного кода", а до "генерации бинарного кода, которая происходит очень далеко в пространстве-времени от написания шаблонного кода". Наш гипотетический монадно-ориентированный компилятор мог бы (и должен был бы) прямо во время компиляции монады, скажем, optional сказать нам "вы неправильно описали монаду — у вас функция bind имеет неверный тип аргумента. Ваш optional — это функтор". Или "ваши определения unit и bind нарушают требования к монаде".
S>И всё это — до того, как мы попробуем привинтить этот optional к конкретному типу.

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

А так, весьма точное описание проблемы. Только вот называть её отсутствием типизации как-то глупо. Всё же код, используемый для компиляции, является жёстко типизированным. А здесь у нас просто проблема "отсутствия компиляции". Т.е. я нигде не отрицал существование вышеописанной сложности, но к типизации это отношения не имеет.

Кстати, на мой взгляд интересное решение для данной сложности может лежать не в области компилятора, а в области IDE. Что-то типа:

template<typename T> Test<T, typename enable_if<is_base_of<Parent, T>::value>::type>{
    T t;
    Test()
    {
        t.//и тут автодополнение выдаёт члены класса Parent
    }
};

можно без проблем реализовать средствами IDE. Правда пока C++ IDE не до этого, им бы пока просто Boost распарсить конца. )))

S>Как мы знаем из практики, скорость обобщённого кода и раздельность компиляции — это четыре разных человека. То, что бинарный код генериков в C# появляется только на целевой машине — ну так весь дотнет такой, всё отложено до джита. Так что скорость обобщённого кода — точно такая же, как и у обычного. А компиляция исходников гарантирует отсутствие ошибок в коде генерика.

В C++ тоже скорость обобщённого кода и обычного одинаковы (и при этом больше C#) и точно также гарантировано отсутствие подобных ошибок в исполняемом файле. Единственное отличие/ограничение варианта C++ в том, что в нём невозможно скомпилировать обобщённый код сам по себе. Т.е. нет раздельной компиляции шаблонов и использующего их кода.

Здравствуйте, alex_public, Вы писали:

I>>Такое чистое ФП нужно там, где архитектура вычислителя другая. Если ты хочешь гонять код ровно в одном ядре, то конечно императивный язык здесь заруливается всех в минуса, я про то уже писал около десяти раз за последние полгода.

_>И на многих ядрах всё тоже самое.

Нет, на нескольких ядрах уже слишком много издержек из за синхронизации. Дальше я скипнул — ты ведь не занимаешь суперкомпьютерами, правильно ?

Здравствуйте, alex_public, Вы писали:

S>>Главное — его модель многозадачности, где помимо green threads есть передача владения, и в итоге получаем адскую скорость разбора пакетов, офигенные гарантии изоляции (т.е. поломанный актор не может ни попортить память других, ни отожрать 100% CPU), плюс горячую замену кода.
S>>Сделать что-то отдалённо похожее — можно, но либо ценой перформанса, либо ценой надёжности.

_>Без проблем это всё делается на C++.

Если Адъ и Израиль это без проблем, то всё в порядке, можно согласиться. Щас вот закомые пилят решение для виртуализации на С++. Это такой трэш, не передать словамаи.

Единственный раз я видел "без проблем" это когда в команде сиплюсников не было ни одного разраба меньше 10 лет опыта. Я, правда, к тому времени решил отказаться от С++ насовсем, ибо таких команд всего пару штук в моем городе.

Да и вообще таких команд очень мало, их тупо не хватит на все проекты. Поэтому совершенно неинтересно читать, что там есть для С++.
И вот очень интересно читать, что есть для джавы, дотнета, питона, джаваскрипта, ибо таких разработчиков искать не нужно.

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

Здравствуйте, Ikemefula, Вы писали:

I>То есть, просто сиплюсника можно найти быстро. Сиплюсника который свободно владеет бустом и хотя бы многопоточностью, уже много сложнее. А сиплюсника который умеет и многопоточность, и распределнные вычисления, и асинхронное программирование и при этом успел прокачать и stl и буст, и кучу других либ надо искать днём с огнём.

К слову, аналогичного джависта, питонщика, дотнетчика искать относительно просто, естественно вместо stl и буста будут другие либы.

Здравствуйте, Ikemefula, Вы писали:

I>Нет, на нескольких ядрах уже слишком много издержек из за синхронизации. Дальше я скипнул — ты ведь не занимаешь суперкомпьютерами, правильно ?

По бизнесу не занимаюсь. Но не плохо знаком с этой темой, т.к. их эксплуатируют в основном учёные для разных числодробилок, а у меня там много контактов. Так вот, в этой области решение mpi+openmp полностью накрывает весь спектр проблем связанных с распараллеливанием и в общем то это почти как негласный стандарт. Ну точнее так было до появления GPU — под них пришлось переделывать код руками на низком уровне, что было мучением в общем то. Поэтому недавнее появление Intel Xeon Phi прошло просто на ура — можно снова работать на относительно высоком уровне. )

Насчёт синхронизации... Ну покажи мне как ты предлагаешь распараллелить обработку массива на несколько ядер. Т.е. берём массив 1000000 элементов и надо допустим изменить каждый его элемент, возведя его в квадрат. Код для одного ядра что-то типа for(int i=0; i<size; i++) x[i]=x[i]*x[i]; С помощью openmp мы можем это распараллелить на все ядра процессора одной простейшей директивой. А как предлагаешь сделать ты и чтобы без всякой синхронизации? )

Здравствуйте, Ikemefula, Вы писали:

I>Если Адъ и Израиль это без проблем, то всё в порядке, можно согласиться. Щас вот закомые пилят решение для виртуализации на С++. Это такой трэш, не передать словамаи.

С интересом посмотрю на решение этой задачи на другом языке...

I>Единственный раз я видел "без проблем" это когда в команде сиплюсников не было ни одного разраба меньше 10 лет опыта. Я, правда, к тому времени решил отказаться от С++ насовсем, ибо таких команд всего пару штук в моем городе.

I>Да и вообще таких команд очень мало, их тупо не хватит на все проекты. Поэтому совершенно неинтересно читать, что там есть для С++.
I>И вот очень интересно читать, что есть для джавы, дотнета, питона, джаваскрипта, ибо таких разработчиков искать не нужно.

С этим не поспоришь. )

I>То есть, просто сиплюсника можно найти быстро. Сиплюсника который свободно владеет бустом и хотя бы многопоточностью, уже много сложнее. А сиплюсника который умеет и многопоточность, и распределнные вычисления, и асинхронное программирование и при этом успел прокачать и stl и буст, и кучу других либ надо искать днём с огнём.

Здравствуйте, alex_public, Вы писали:

_>Насчёт синхронизации... Ну покажи мне как ты предлагаешь распараллелить обработку массива на несколько ядер. Т.е. берём массив 1000000 элементов и надо допустим изменить каждый его элемент, возведя его в квадрат. Код для одного ядра что-то типа for(int i=0; i<size; i++) x[i]=x[i]*x[i]; С помощью openmp мы можем это распараллелить на все ядра процессора одной простейшей директивой. А как предлагаешь сделать ты и чтобы без всякой синхронизации? )

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

Здравствуйте, Ikemefula, Вы писали:

I>... а в киеве дядька. Ты всё еще продолжаешь насиловать фон Неймановскую архитектуру, а я говорю о принципиально иной архитектуре.

Что за иная архитектура?

И откуда оно возьмётся в задачах числодробилок, если вот тот мой пример полностью соответствует реальной задаче учёных (массив — это некая физическая величина, заданная на решётке)?

Здравствуйте, alex_public, Вы писали:

_>Ну так а в каком языке подобное возможно? )
Подобное возможно в С#, в виде Lifted Operators для Nullable.

_>И если предположим возможно, то благодаря каким-то особым свойствам языка или благодаря особым свойствам монад? )
Благодаря особым свойствам монад. Монада определяется не только сигнатурой операций, но их семантикой (см. тж. монадные законы). Поэтому гипотетический компилятор будет иметь право сделать такие замены автоматически.

Здравствуйте, alex_public, Вы писали:

_>Без проблем это всё делается на C++. Например вот http://www.theron-library.com/index.php?t=page&amp;p=tour1 интересное решение. Ну т.е. конечно небольшая разница есть. В том смысле, что т.к. C++ позволяет иметь самый низкий уровень доступа, то при желание можно без проблем обмануть библиотеку и сломать модель. Но это если специально стараться (в Эрланге такое даже при этом не выйдет), а если следовать правилам библиотечки, то получается абсолютно такой же быстродействующий и надёжный код.
К сожалению, нет никакого способа убедиться в том, что некоторый код "следует правилам библиотечки". Специально стараться никуда не нужно — я не представляю себе способа написать минимально безопасную библиотеку на С++. Потому что в языке нет никакого способа запретить штуки типа char*, которые могут указывать буквально куда угодно.

_>А вообще, модель акторов это такая простая вещь, что даже не обязательно использовать какие-то готовые библиотеки. Например, если нам не нужны всякие там планировщики и распределённые системы, то подобный код легко пишется просто в лоб, без введения специальных сущностей. Я частенько работаю даже с обычными std::thread в таком стиле.
Дело не в модели акторов, а в том, чтобы иметь гарантии. На всякий случай напомню, что безо всякой распределёнщины С++-ный проект для эриксоновского свитча так и не взлетел. Несмотря на то, что там не самые тупые девелоперы писали, уж наверное могли "легко написать просто в лоб". А потом пришёл Эрланг, и внезапно оказалось, что всё можно написать не только языком на форуме, и оно даже работает.

Здравствуйте, alex_public, Вы писали:

_>Так фокус в том, что многие шаблонные библиотеки C++ не компилируются вообще. Т.е. они поставляются только в виде набора заголовочных файлов и для них компилятор вообще никогда не запускается и даже теоретические не может быть запущен. Ну т.е. понятно, что авторы в реальности работают в какой-то своей тестовой программкой (и кстати в ней естественно есть инстанцирование, так что компилятор отрабатывает все ошибки в шаблоне на полную), но в саму библиотеку она не входит.
Вы так пишете, как будто это хорошо. Это, по факту, означает, что компилятор никак не помогает авторам таких библиотек.
Насчёт "отрабатывает все ошибки в шаблоне на полную" — это вы хорошо пошутили, я оценил.
Если взять среднего девелопера, то он сходу не сможет написать тестовую программу для, скажем, optional<T>. Вы вот, к примеру, не смогли.