Во-первых, странный синтаксис. Думаю, проще для мозга приводить примеры со стандартным синтаксисом си-подобных языков, да хоть того же JS. Ну да ладно.
Модификаторы функций — как я понял, возникли из-за того что способов применения обычных операций и функций к массивам может быть больше чем к скалярам.
Просто способ конкретизировать что именно делает операция "+" — попарное сложение элементов массивов или сложение всех элементов в общую сумму.
Модификатор map — это, как я понял, выполнение операций над каждым элементом массива и получение на выходе массива той же размерности
Все новое — хорошо забытое старое.
Особенно, если не знал, не знал — и забыл...
Вспоминаем систему Альфа-6, сделанную под руководством Ершова Андрея Петровича еще в конце 60-х.
Векторы и матрицы были сделаны в ней как нормальный тип данных.
Естественно, с соответствующими операциями.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Вспоминаем систему Альфа-6, сделанную под руководством Ершова Андрея Петровича еще в конце 60-х. LVV>Векторы и матрицы были сделаны в ней как нормальный тип данных. LVV>Естественно, с соответствующими операциями.
Ну так и на С++ не проблема сделать векторы и матрицы нормальным типом данных. И такие классы уже сделаны в большом количестиве.
В чем тогда преимущество "векторных" языков?
Здравствуйте, x-code, Вы писали:
XC>Ну так и на С++ не проблема сделать векторы и матрицы нормальным типом данных. И такие классы уже сделаны в большом количестиве. XC>В чем тогда преимущество "векторных" языков?
Здравствуйте, x-code, Вы писали:
XC>Во-первых, странный синтаксис. Думаю, проще для мозга приводить примеры со стандартным синтаксисом си-подобных языков, да хоть того же JS. Ну да ладно.
Для знакомых с функциональными языками уже многое понятно.
XC>Модификаторы функций — как я понял, возникли из-за того что способов применения обычных операций и функций к массивам может быть больше чем к скалярам.
Да. Хотя часть их это то же самое как превратить y=f(x) в y=map(f,x), которое где-то внутри раскроется в for(i=0;i<x.size();++x) { y[i]=f(x[i])}. Тут и дальше мне облом вспоминать соответствующую функцию STL, пишу циклом.
XC>Просто способ конкретизировать что именно делает операция "+" — попарное сложение элементов массивов или сложение всех элементов в общую сумму.
Угу.
XC>fold — бинарная операция выполняется над всеми элементами массива XC>
+/fold [1,2,3] == 1+2+3
Это таки свёртка, то есть fold(func, input, initial) это
accum = initial; // если initial пропущен в аргументах, берётся дефолтное значение для типа, для числа это 0
for (i=0; i<input.size();++i) { accum = func(input[i], accum); }
return accum;
XC>Далее пишут что "fold легко расширяется на произвольное число аргументов". Вот тут совершенно непонятно как именно.
Можно пройтись последовательно по входным цепочкам, а можно сделать вектор результатов прохождений всех цепочек — это уже разные расширения. (Цепочка, массив, последовательность, список, вектор — тут считаем одним и тем же.)
XC>left, right — "разновидности map для двух аргументов". Тут уже я совсем теряю мысль
Тебе задали аргумент, который прибивается к функции. То есть имеем что-то вроде
и тебе просто дали удобный стиль описать подобный карринг, превращающий бинарную функцию в унарную за счёт фиксации одного аргумента. В случае right фиксируется первый аргумент функции, а второй применяется для прохождения по входной цепочке.
"Карринг" — термин для операции создания новой функции фиксацией значения аргументов — частный случай замыкания.
В k и q, карринг даёт функцию пока остаётся хоть один аргумент, но если 0, то результат уже просто значение функции (чуть неровно, но логика видна).
XC>В общем, если здесь есть знатоки APL, J, K, Q и прочих языков, на основе которых написана сабжевая статья — с удовольствием прочитаю ваши комментарии.
Про Q я писал.
В целом kdb+ интересна совершенно безумной скоростью за счёт разнообразных приёмов упрощения интерпретатора (чем больше кэшируемой обработки и чем меньше ветвлений, тем быстрее), язык немного помогает этому за счёт акцента на явные операции с цепочками.
В целом же, есть любители писать подобные вещи компактно (вплоть до одного символа на операцию), и есть полезность в изображении операций для транслятора/среды так, чтобы они могли легко найти оптимизацию в SIMD операции процессоров (что может ускорить на порядки) — а это лучше всего делать, оказывается, явным синтаксисом и отрубанием того, что может мешать таким оптимизациям).
Здравствуйте, x-code, Вы писали:
XC>Ну так и на С++ не проблема сделать векторы и матрицы нормальным типом данных. И такие классы уже сделаны в большом количестиве. XC>В чем тогда преимущество "векторных" языков?
Ну на kdb+ видно то преимущество, что эти операции уже напрямую реализованы векторно в интерпретаторе.
Там, где компиляторы C++ ещё должны понять, как им векторизовать действия из цикла, тут уже есть готовый вылизанный код.
Скорость работы у неё в результате просто сумасшедшая — ограничением становится скорость последовательного доступа к памяти.
А если ещё умный контроллер умеет группировать операции с DRAM — то вообще улёт
LVV>>Вспоминаем систему Альфа-6, сделанную под руководством Ершова Андрея Петровича еще в конце 60-х. LVV>>Векторы и матрицы были сделаны в ней как нормальный тип данных. LVV>>Естественно, с соответствующими операциями. XC>Ну так и на С++ не проблема сделать векторы и матрицы нормальным типом данных. И такие классы уже сделаны в большом количестве. XC>В чем тогда преимущество "векторных" языков?
В более глубокой интеграции с параллельной архитектурой.
Трансляция изначально рассчитана на параллельность
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, x-code, Вы писали:
XC>Прочитал статью, но многого не понял. Обсудим здесь?
Векторизация — это мощная штука, но что-то мне этот язык Вектор кажется слегка перегруженным синтаксически Могу рассказать как векторизация реализована в языке R — здесь она поддерживается из коробки и является одной из основных фич.
Вкратце, в R есть 2 основных структуры данных — вектор (одномерный массив) и матрица (двухмерный массив). Скалярные значения рассматриваются как векторы из одного элемента. Есть еще списки, но их оставим в стороне пока. Типы элементов могут быть разными — вещественное число, целое, комплексное, строка, логическое и т.д. Прежде всего нас интересуют числа.
Далее, в R все базовые операции и функции — математические, сравнение и т.д. — векторизированы. И это не только самые простые вещи типа +, -, *, \, > — но сотни и тысячи других ф-ций (например, sqrt, sin, cos, transpose).
То, что ф-ция векторизирована означает, что она будет правильно работать, что для скаляра, что для пустого вектора, что для матрицы и т.д.
Т.е. допустим нужно сложить 2 массива. В каком-нибудь С++ нужно писать цикл: for() c[i] = a[i] + b[i]. В R достаточно написать с = a + b. И это будет работать даже, если a & b — это матрицы или вектора или скаляры. Естественно, можно писать более сложны формулы типа log(sqrt(a) + b * c). Безусловно есть определенные нюансы, когда мы пытаемся работать с элементами разной размерности — по умолчанию R будет пытаться привести их друг к другу. Т.е. можно написать 3 * А + 4 и это сработает если А — вектор или матрица.
Два основных преимущества — выразительность кода и производительность. С выразительностью думаю вопросов нет. Насчет производительности — все основные матфункции в R реализованы на C/C++/Fortran и по сути R — это просто обертка над этим кодом. И большинство из этих ф-ций оптимизировано для векторных вычислений. Например, некоторые напрямую используют SSE инструкции.
В принципе, при желании того же можно добиться в С++ перегрузив операторы / написав соответсвующие ф-ции, но ведь это придется писать кучу кода. А в R — это уже есть из коробки, написанное и тщательно оттестированное.
Дальще если просто писать циклами в С++, компилятор может сделать оптимизацию в SSE, а может и не сделать — зависит от ситуации. Если же код изначально пишется векторизированым, то здесь можно сразу применять оптимизированный подход.
Что касается дополнительных операций map / reduce и т.д. Они тоже есть в R, но мне кажется, что это уже больше относится к функциональному программированию. Т.е. если у вас есть вектор А и ф-ция func, можно применить эту ф-цию к вектору и получить новый вектор: x = apply(a, func). Обычно это используется, когда ф-ция написана неправильно и не реализовывает векторизацию внутри.
Есть также Reduce — т.е. можно написать Reduce(a, `+`), чтобы сложить все элементы вектора / матрицы вместе. Reduce может быть применен к любой операции или функции.
Здравствуйте, x-code, Вы писали:
XC>Ну так и на С++ не проблема сделать векторы и матрицы нормальным типом данных. И такие классы уже сделаны в большом количестиве. XC>В чем тогда преимущество "векторных" языков?
Здравствуйте, netch80, Вы писали:
N>Про Q я писал. N>В целом kdb+ интересна совершенно безумной скоростью за счёт разнообразных приёмов упрощения интерпретатора (чем больше кэшируемой обработки и чем меньше ветвлений, тем быстрее), язык немного помогает этому за счёт акцента на явные операции с цепочками.
Все правда, но имхо конкурент таки появился — Julia. Просто, почти как в Питоне, а потом легким движением рук получаешь "безумную скорость".
Да с явной векторизацией и без закорючек получается чуток длиннее, но не сильно:
Q:
baseusage:raze {(idbase[x]+til counts[x])!flip(`long$(0.5*base[x])+counts[x]?base[x];counts[x]#x)} each custtypes
Julia:
baseusage = vcat([hcat((b=idbase[x]):b+counts[x] — 1, 0.5*base[x] .+ rand(0:base[x], counts[x]), fill(x, counts[x])) for x in custtypes]...)
Здравствуйте, pagid, Вы писали:
P>Польза от этого какая? И это не строчка а картинка.
kdb+/q самый дорогaя софтина на свете. Лицензия на дистрибутив состоявший из одного ехе весом в 700KB стоит ... $100К в год. Покупают, значит есть польза. Это за 64 бита, 32 бесплатно.
Здравствуйте, novitk, Вы писали:
N>kdb+/q самый дорогaя софтина на свете. Лицензия на дистрибутив состоявший из одного ехе весом в 700KB стоит ... $100К в год. Покупают, значит есть польза. Это за 64 бита, 32 бесплатно.
Тогда конечно да
Но платят именно за возможность записать в одну строчку?
Здравствуйте, novitk, Вы писали:
N>Здравствуйте, pagid, Вы писали:
P>>Польза от этого какая? И это не строчка а картинка.
N>kdb+/q самый дорогaя софтина на свете. Лицензия на дистрибутив состоявший из одного ехе весом в 700KB стоит ... $100К в год. Покупают, значит есть польза. Это за 64 бита, 32 бесплатно.
Мне такой прайс выставили пару лет назад:
Pricing
• $0.005 per core minute — for cores that are instantiated but not being used
• $0.10 per core minute — for the first 4 cores used in any given minute
• $0.05 per core minute — for any cores above the first four being used in a given minute
Здравствуйте, x-code, Вы писали:
XC>Прочитал статью, но многого не понял. Обсудим здесь? XC>https://habr.com/ru/company/dbtc/blog/530564
Однако. Конец 2020-го года, эти map, fold, reduce — это уж много лет как есть в любом языке, хоть и не факт что в очень уж оптимальный код компилится.
А обсуждать — да, есть определенный класс задач, всякие параллельные алгаритмы, которые заточены под операции map, reduce, fold (это кстати частный случай reduce), scan, group, может еще что забыл, ибо этой всей параллельностью довольно давно интересовался. Этот класс задач позволяет полностью реализовать возможности железа, включая SIMD инструкции процессора и видеокарты, в результате чего производительность оказывается просто бешенная. К сожалению не панацея это, ибо подходит под определенный класс задач, и не все можно распараллелить, ну и читается это все не очень приятно, соответственно без необходимости лучше этим не злоупотреблять.
На деле. После того, как производительность не получается наращивать путем тупого увеличения частоты, как раньше, но весьма неплохо получается наращивать путем увеличения количества ядер процессора плюс увеличением количества ALU, появилась потребность всю эту мощь эффективно использовать в алгоритмах. И все эти векторные языки и вот эти классические операции — это как раз сделано с целью полностью использовать мощь современных процессоров без использования магии низкого уровня.
Здравствуйте, HFTMan, Вы писали:
N>>kdb+/q самый дорогaя софтина на свете. Лицензия на дистрибутив состоявший из одного ехе весом в 700KB стоит ... $100К в год. Покупают, значит есть польза. Это за 64 бита, 32 бесплатно.
HFT>Мне такой прайс выставили пару лет назад: HFT>Pricing HFT>• $0.005 per core minute — for cores that are instantiated but not being used HFT>• $0.10 per core minute — for the first 4 cores used in any given minute HFT>• $0.05 per core minute — for any cores above the first four being used in a given minute
В результате купили? Если да, сколько в год выходит?
Здравствуйте, HFTMan, Вы писали: N>>kdb+/q самый дорогaя софтина на свете. Лицензия на дистрибутив состоявший из одного ехе весом в 700KB стоит ... $100К в год. Покупают, значит есть польза. Это за 64 бита, 32 бесплатно.
HFT>Мне такой прайс выставили пару лет назад: HFT>Pricing HFT>• $0.005 per core minute — for cores that are instantiated but not being used HFT>• $0.10 per core minute — for the first 4 cores used in any given minute HFT>• $0.05 per core minute — for any cores above the first four being used in a given minute
Ну, где-то 1/10 от заработка соотв. специалиста, если не меньше — очень вменяемый прайс.
