[Тред-совет] ЯП с динамической типизацией

> Но ф-ю писать было лень;-)

А с часто повторяющимися кусками кода как? Тоже «функцию писать лень»? Или «copy/paste рулит»? :)))

mv в одном треде утверждал что ПЛИС + CL рвут CPU-GPU в числодробильных задачах. Но ему с цифрами объяснили что он не прав;-)

Я, наверное, уже тред перестал читать, когда мне там с цифрами что-то объяснили. Вас с Кукой роднит то, что не обладая опытом работы в какой-то сфере вы заранее эту сферу топите.

У меня оч простой критерий качества кода - чем меньше строк (при нормальном форматировании), тем код лучше.

Завидую.

Если я так напишу, да ещё во многих местах, то мне уже через пару недель придётся разбираться в подобной каше практически «с нуля».

> Я, наверное, уже тред перестал читать, когда мне там с цифрами что-то объяснили

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

> Но лямбда это ж функциональщина, мне казалось что такие вещи как раз противоречат ФП?

Лямбда - это конструктор объекта класса «функция», это не специфично для ФП. ФП, как я его понимаю, это скорее программирование без побочных эффектов, и наличие в теле лямбды цикла for этому не противоречит.

И даже вне зависимости от сложности/масштабности задачи?!?!

/me удивлён и озадачен...

> Вас с Кукой роднит то, что не обладая опытом работы в какой-то сфере вы заранее эту сферу топите.

В том треде разговор был не о той сфере, в к-й я ничего не понимаю, а той сфере где как раз я таки что то все таки понимаю.

> ФП, как я его понимаю, это скорее программирование без побочных эффектов

Pure FP - это да - без побочных эффектов, но даже гуры ФП признают, что любая функция вывода даёт побочный эффект. А как без вывода обходиться? :)

> Я, наверное, уже тред перестал читать, когда мне там с цифрами что-то объяснили.

Ну так может возродить тот тред? Народ жаждит зрелищ.

Ну есть же генераторы списков и map?

Но в общем да, получается что лямбда в питоне урезана. Но ИМНО беда небольшая, есть же вложенные ф-ии

> А как без вывода обходиться? :)

Насколько я понимаю, это обходят с помощью значения типа World, но я плохо разбираюсь в ФП.

Например, тут

let a = wtf1(c) in
let b = wtf2(a, d) in
  wtf3(a, b)

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

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

Что мне там опровергли? Ни ты, ни твой начальник с FPGA не работали, и к этой идее отнеслись, как инквизитор к круглой Земле. Алгоритмов конкретных приведено не было, чтобы можно было хотя бы прикидочно оценить, как они на FPGA работать будут. Ссылки на первую страничку из гугля о том, как люди на FPGA ускоряют сейсмологию, были также восприняты в штыки: «У нас не то считается.» или «Такого не может быть.». После просьбы выгуглить за вам vhdl-исходник умножителя я покинул дискуссию.

Да и не только. Можно с помощью монад, а можно вообще рассматривать main как ленивую функцию [String] -> [String], принимает ввод, выдает вывод.

> И даже вне зависимости от сложности/масштабности задачи?!?!

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

v8 кстати. JS c вытекающей динамичностью. Компилятор, относительно инфраструктура, nodejs. Общий код для web, сервера, десктопа.

> можно вообще рассматривать main как ленивую функцию [String] -> [String], принимает ввод, выдает вывод.

Исторически первая система В/В для Хаскеля? Я никогда не мог понять, как оно работает.

Интересный подход. Впрочем, выглядит (на мой первый взгляд) достаточно логичным.

Просто я уже как-то привык к мысли, что более-менее серьёзные проекты маленькими не бывают. Либо меньше длинных файлов с исходниками, и тогда - «листание кода». Либо больше относительно коротких, но в этом случае - беготня между файлами. Удобства/неудобства получаются приблизительно одинаковые.

Ище раз. Есть ПЛИС, к-е за счет тонкой настройки работают со 100% эффективностью (верю Вам на слово), т.е. все упирается в число элементарных операций в сек.

Есть CPU-GPU, которые за счет LRnLA то же работают со 100% эффективностью и все упирается в число оп в сек.

CPU-GPU по числу операций в сек ПЛИС делают, что понятно - массовое производство и тд. Фсе. Тут не надо быть специалистом по ПЛИС или по числ методам, эту оценку может любой школьник провести.

Про алгоритм было сказано достаточно.

И то был не единственный тред, к-й Вы «перестали читать»

>nodejs

меня конечно сейчас освистать могут по-полной, но я когда-то присматривался к nodejs, и завершил знакомство после утверждений Дурова о текучести nodejs, что доставляет немало головняка. Это не правда?

В том треде разговор был не о той сфере, в к-й я ничего не понимаю, а той сфере где как раз я таки что то все таки понимаю.

Массивные параллельные вычисления на FPGA?

>Есть CPU-GPU, которые за счет LRnLA то же работают со 100% эффективностью и все упирается в число оп в сек.

это доказано практикой, или теория?

разбивка по файлам - отдельная тема, за это я не говорю. Я к тому, что чем код меньше (суммарно), тем большую часть видишь на экране единовременно. Мне в емакс что пролистать, что переключится между буферами - пофик;-)

> это доказано практикой, или теория?

Доказано практикой. Бол того, доказано практикой 100%я эффективность распарллеливания на любом числе процессоров (проверялось до 1000 процессоров).

Есть CPU-GPU, которые за счет LRnLA то же работают со 100% эффективностью и все упирается в число оп в сек.

Объясните «100% эффективности»?

CPU-GPU по числу операций в сек ПЛИС делают, что понятно - массовое производство и тд.

Не понятно. Сколько, например, сложений CPU-GPU может сделать за одну секунду?

Тут не надо быть специалистом по ПЛИС или по числ методам, эту оценку может любой школьник провести.

Конечно, не надо быть специалистом по ПЛИС. Но надо - это осознать, что если нужно делать тысячу сложений за такт, то на ПЛИС это можно сделать, а на CPU-GPU - нет.

> Массивные параллельные вычисления на FPGA?

Числ. моделирование. Это Вы прибежали с криками «а вот наши ПЛИС лучше всего всегда и везде», я к Вам не приставал с предложениями биржи на LRnLA перевести;-)

Вам все оценки привели. Несогласны с чем то - говорите предметно. А кивать кто в чем не разбирается... у Вас там в Бостоне вообще негров вешали.

Исключительно за счет ленивости. Вместо чтения из stdin просто берется голова списка. Фактически, вычисление тех или иных ленивых частей входного списка и есть непосредственно ввод.

Другим проявлением этого же подхода является функция interact в прелюдии http://hackage.haskell.org/packages/archive/base/latest/doc/html/Prelude.html... . В маленьких программах часто можно встретить идиому main = interact pureMain.

Вам все оценки привели. Несогласны с чем то - говорите предметно. А кивать кто в чем не разбирается... у Вас там в Бостоне вообще негров вешали.

Вы сказали, что алгоритм параллельный на 100%. Я сказал, что FPGA для параллельных алгоритмов - самое то. Мне говорят, что с FPGA не работали, но для параллельных алгоритмов оно не самое то.

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

Я сам не пользуюсь ни nodejs ни v8. Я вобще элитный лиспер:) Просто V8 в памяти всплыл, показалось в тему.

завершил знакомство после утверждений Дурова о текучести nodejs,

По моим слухам все не настолько страшно. Но как я уже писал выше, я эти слухи не проверял.

Если именно web, то можно и Erlang вспомнить.

> Для обеспечения динамизма в статически компилированном коде приходится прибегать к ухищрениям в виде 60-мегабайтного рантайма со встроенным ad hoc, informally-specified, bug-ridden, slow implementation of half of GCC. Более адекватный путь, выбранный цивилизованным IT-миром - JIT-компиляция.

Ну и в чем проблема взять лисп с джитом и маленькими ехешниками?

А что за лисп с джитом? clojure?

> Объясните «100% эффективности»?

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

Не понятно. Сколько, например, сложений CPU-GPU может сделать за одну секунду?

Умножений (наск я помню) - число ядер * частоту * 2...4 при использовании векторизации. Сложений в сбалансированном коде обычно меньше и они идут фоном на конвейре. Детальней Вам тогда VLev отвечал, он в этом лучше разбирается.

Конечно, не надо быть специалистом по ПЛИС. Но надо - это осознать, что если нужно делать тысячу сложений за такт, то на ПЛИС это можно сделать, а на CPU-GPU - нет.

мне пофик скока сложений делает ПЛИС за такт (там такты длиинные наск я понял). Мне интересно число операций железяки в секунду при равной стоимости железяк. Опять таки, в том тереде VLev объяснил почему CPU быстрее.

> Вы сказали, что алгоритм параллельный на 100%. Я сказал, что FPGA для параллельных алгоритмов - самое то. Мне говорят, что с FPGA не работали, но для параллельных алгоритмов оно не самое то.

Вам объяснили ПОЧЕМУ оно не самое то, основываясь на Ваших же цифрах. Фсе, я что хотел сказал, по пятому разу повторять не буду.

Можно ссылку на тот тред? Интересно же.

Нет, с помощью монад нельзя. Монады - это просто интерфейс для механизма, который реализует в хаскеле сайдэффекты. Сами по себе они ортогональны.

> Ну и в чем проблема взять лисп с джитом и маленькими ехешниками?

Где же ты видел лисп с jit-ом? Да и маленькие бинарники/образы лиспам, даже которые схемы то же не свойствены. Только если все под нож.

Racket, например. Да и без jit'a большая часть схем не тащит за собой 60-метровые рантаймы. По-моему это вообще только проблема cl и даже не самого cl, а ряда его конкретных реализаций.

> Вы сказали, что алгоритм параллельный на 100%. Я сказал, что FPGA для параллельных алгоритмов - самое то.

Как я понял, вам в прошлом треде пытались объяснить, что на cpu-gpu алгоритм и так параллелится как надо, в результате все утыкается тупо в частоту, с чем у плисов заведомо хуже.

> Объясните «100% эффективности»?

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

На FPGA можно реализовать схему, выполняющую все операции параллельно за один такт. Соответственно, если сравнивать с обычным процессором, который всё делает последовательно (суперскалярность не учитываем), то тогда можно за такое же время обрабатывать в 2, 5, 10, 100 раз больше данных. Получается, что ваши безоговорочные «100% эффективности» - чистой воды marketing bullshit.

Умножений (наск я помню) - число ядер * частоту * 2...4 при использовании векторизации. Сложений в сбалансированном коде обычно меньше и они идут фоном на конвейре. Детальней Вам тогда VLev отвечал, он в этом лучше разбирается.

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

мне пофик скока сложений делает ПЛИС за такт (там такты длиинные наск я понял).

Такт - это фиксированный квант времени.

Мне интересно число операций железяки в секунду при равной стоимости железяк.

При попытке углубиться в техническую сторону проблемы вы опять съезжаете на тему денег, жлобства/бедности заказчика и т.п., хотя это не имеет ни малейшего отношения к алгоритмам и технической эффективности.

Опять таки, в том тереде VLev объяснил почему CPU быстрее.

Нет, не объяснил. VLev, вероятно, очень круто разбирается в архитектуре x86 (я вполне допускаю, что круче меня, хотя я весьма не слаб в этом вопросе), и, очевидно, гораздо сильней в математической части, но это не отменяет необходимости быть знакомым и с FPGA, чтобы валить эту технологиями реальными фактами, а не домыслами.

Гуманитарии идут лесом.

> Racket, например.

А он все таки scheme.

Да и без jit'a большая часть схем не тащит за собой 60-метровые рантаймы.

А тащит 5 - 10 мб. Или будет простеньким интепритатором.

Или все урезается в пользу с-шног транслятора. После чего вся сбора конструкция переходит в разряд несамостятельных скриптовых языков. Не способных к самосборке. У всего есть цена.

Ну общую идею-то я понял.

Мне в емакс что пролистать, что переключится между буферами - пофик;-)

Во-во, вот про это я и говорю: удобства/неудобства примерно равнозначны.

> Монады - это просто интерфейс для механизма, который реализует в хаскеле сайдэффекты.

Да-да-да, а World в Clean — это тоже только интерфейс?

Как я понял, вам в прошлом треде пытались объяснить, что на cpu-gpu алгоритм и так параллелится как надо, в результате все утыкается тупо в частоту, с чем у плисов заведомо хуже.

Стопроцентная параллельность означает, что 100 одинаковых операций можно сделать в 25 проходов на 4 параллельных вычислителях, а можно за 1 проход на 100 вычислителях. FPGA позволяет сделать столько параллельных вычислителей, сколько физически уместится на матрице.

Lisp и вычисления

> А он все таки scheme.

Он не scheme, это во-первых. Во-вторых, а с каких спор scheme - не лисп?

А тащит 5 - 10 мб.

Это так страшно?

>На FPGA можно реализовать схему, выполняющую все операции параллельно за один такт.

но ведь это далеко не всегда так, и AFAIK, ПЛИС меряет больше в скорости прохождения сигнала, чем в тактах...

> FPGA позволяет сделать столько параллельных вычислителей, сколько физически уместится на матрице.

Это, наверное, ключевой момент, нет? Если у вас на матрице _не уместится_ нужное количество вычислителей, чтобы нивелировать преимущество CPU в скорости? Ну вот вам привели количество умножений на CPU, теперь вы ответьте, сколько умножителей у вас вместится на ПЛИСке.

Слушайте, ну сколько же можно! Если у Вас целевая ф-я - посчитать задачу на FPGA, то конечно надо брать FPGA. У нас целевая ф-я - считать задачу как можно быстрее за как можно меньшие деньги, и тут ПЛИС сливают. Как там параллелится FPGA, как GPU без разницы. Ваши мысли про афигенное число операций выполняемых ПЛИС параллельно все уже давно поняли.