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

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

Вы вот похожи на человека, к-й овладел микроскопом и теперь ругает всех кто вокруг с молотками.

> тут подсказывают, что программирование и яп в численных методах занимает 0.0000001% усилий.

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

Если человек прекрасный программист, знает числ методы но плохо знает предметную область толка от него никакого. Проще обезьяну научить писать на С++, чем программиста научить физике.

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

Я его пока плохо знаю, сам только знакомлюсь.

Ну в этом вы правы. Но тут уже о другом речь, да. На этом языке хорошо можно строить хорошие алгоритмы =) А для числодробилок лучше что-то другое... И да... языки хорошо комбинировать, ага.

> для разработки ИИ вроде как хорошо годится

могу я взглянуть на тонны ИИ на лиспе? на другие реализации?

вот к примеру шахматы (и пусть тут кто-то вспомнит про перебор, хрен с ним). пусть лучше представители лисповых и прочих ИИ умов сразятся ;)

Какое шахматы имеет отношение к ИИ?

> Какое шахматы имеет отношение к ИИ?

самое прямое, а вот к ИР они уже отношения не имеют

Ты мне лично кидал ссылку на статью сильно до того, как написать эту статейку на лорвики. Вопрос был в том, каким это местом код на сипэпэпэ может быть __сильно быстрее__ кода на фортране. Где там сравнение?

> Зато на С++ в ряде задач код считает сильно быстрее, и разрабатывается сильно быстрее;-) www.linux.org.ru/wiki/en/User:AIv/LRnLA

Вот там по ссылке написано:

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

Т. е. типичное такое метапрограммирование, которое на CL выглядело бы куда более естественно и просто. И проблема «отсутствия в современных ЯП встроенных конструкций для...» (цитата, опять же, из текста по ссылке) в CL решается тривиально. Я это всё к тому, что, по-видимому, разрабатывавший это всё дело человек знал только C++ и питон (ну и фортран ещё, быть может) - поэтому и использовал для реализации своих идей то, что хорошо знает. Что вполне естественно. Знай он CL - скорее всего, выбрал бы его, т. к. это позволило бы не строить свои велосипеды для метапрограммирования и решения проблемы «отсутствующих конструкций».

Что касается производительности кода на лиспе: если использовать хороший компилятор (sbcl к примеру) и писать код с рассчётом на максимальное быстродействие (т. е. декларировать типы где это необходимо, избегать «медленных» конструкций (например, использования CLOS) и т. д.), то результат по производительности получается практически такой же как на c++. При грамотном подходе ко всему этому вполне можно сохранить понятность кода и удобство разработки (средств для этого в языке хватает - те же макросы), плюс там где нет нужды сильно оптимизировать - можно использовать не столь эффективные, но более гибкие конструкции вроде того же CLOS. Если не хватает производительности того, что может выдать компилятор «из коробки» - его можно расширить достаточно небольшими усилиями, «научив» компилировать определённые конструкции в «более правильный» машинный код. Да, при этом, конечно, придётся привязываться к определённой реализации CL - но а) на это вполне можно пойти ради прироста скорости, б) несложно сделать чтобы тот же код на любом другом ANSI-совместимом компиляторе работал бы точно так же, но без наших хитрых оптимизаций.

В качестве примера: вот здесь: https://github.com/angavrilov/ecl-compute/raw/master/doc/report.ru.pdf приведено нечто вроде отчёта о результате применения такого подхода к задаче атмосферного моделирования. Автор утверждает, что метапрограммирование + sse дало выигрыш в 14 раз по сравнению с кодом на фортране (из них sse даёт 4-кратное ускорение, остальное - результат оптимизаций при кодогенерации). (я, если что, этого человека не знаю, код его когда-то случайно нашёл).

В общем, мне кажется, возможности CL для численного моделирования сильно недооцениваются. Во многом из-за того, что люди, им занимающиеся, о CL либо вообще не слышали, либо слышали что-то не то (не соответствующее действительности). В результате они пишут свои велосипеды для метапрограммирования, вместо того чтобы использовать готовый CL, в очередной раз подтверждая десятое правило Гринспена :)

Что касается сложности обучения: могу на своём примере сказать, что за два месяца неспешного ковыряния какого-нибудь своего кода и чтения On Lisp можно изучить CL на довольно неплохом уровне (вполне достаточном для эффективного использования метапрограммирования (с пониманием что и как там работает, что немаловажно) и написания эффективного в плане производительности и поддерживаемости кода). На изучение C++ до того же уровня у меня ушло, на мой взгляд, гораздо больше времени (ибо C++ содержит гораздо больше тонкостей и очень многие вещи (простые по своей сути) в нём делаются через ж^W чрезмерно хитрые манипуляции с шаблонами).

> В качестве примера: вот здесь: https://github.com/angavrilov/ecl-compute/raw/master/doc/report.ru.pdf приведено нечто вроде отчёта о результате применения такого подхода к задаче атмосферного моделирования. Автор утверждает, что метапрограммирование + sse дало выигрыш в 14 раз по сравнению с кодом на фортране

человек хотел доказать, что лисп рулит - и себе( и другим фанатам ) он это «доказал», ведь очень удобно сравнивать с безымянной реализацией фортрана, так же как и удобно «не замечать» того, что FORTRAN не только умеет CUDA, но и умеет его «официально», благодаря производителям видеокарт, которые этим обеспокоились

> FORTRAN не только умеет CUDA, но и умеет его «официально», благодаря производителям видеокарт, которые этим обеспокоились

Ну так осталось его обернуть и использовать в теплом ламповом CL. Код реюз же.

«самое прямое» (с) aho

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

За ссылку большое спасибо. Да, Вы правы - мы не знаем CL. Вопрос о компиляторах - сейчас gcc очень хорошо оптимизирует код. Что в этом плане можно сказать о CL?

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

В самом своем первом посте в этом треде я примерно то же самое и сказал. И в статье на лорвики написано, что наверное на CL это сделать можно, но у нас его никто не знает. Беда в том, что у меня напр ну нету никакой возможности сейчас учить CL - надо решать конкретные задачи.

> Беда в том, что у меня напр ну нету никакой возможности сейчас учить CL - надо решать конкретные задачи.

Некогда думать, надо трясти.

Для анонимусов отличающихся умом и сообразительностью - есть хорошее рабочее решение. Нет никакой уверенности, что CL окажется той самой серебряной пулей, к-я сделает это решение настока лучше, что переход на CL окупится. Хотите - присоединяйтесь и пилите то же самое на CL (хаскеле, фортране и тд), будем рады. Но на ЛОРе троллить конечно куда интересней...

Рекомендую прочесть PCL. Займёт пару-тройку вечеров, но от многих заблуждений излечит.

великолепный пример! [два чая этому товарищу!]

Действительно хороший ответ, спасибо!

Правда, меня всегда интересовало возможность применить метапрограммирование Лиспа в несколько другой области - в создании MVC-фреймворков аля Django и RoR.

Что думаете, на Лиспе можно построить более мощный фреймворк именно за счет метапрограммирования?

Смотря что понимать под моделью (первая 'm' в mvc) и как раскрывать понятие метапрограмирование.

Если на CL писать числодробильню с «ноля», то ничего хорошего из этого не выйдет. А вот если взять уже готовые низкоуровневые вещи (blas/lapack...), а на CL написать только логику и, возможно, кодогенерацию, то по скорости можно сравняться с C++, а по скорости разработки даже выйграть.

Дык мы ж выигрываем на том, что юзаем хитрые локально-рекурсивные алгоритмы обхода. Все эти стандартные пакеты используют стандартный же обход -> для наших задач неэффективны. Нафига мне лисп, если я могу взять С++ для числ ядра, питон для всего остального, выиграть по скорости разработки на порядок и иметь производительность С++?

Вся эта кухня с кодогенерацие и пр. для нас актуальна тока для LRnLA. Статью от slav я автору LRnLA показал, ну хорошо бы дядечку живьем послушать... но пока никаких весомых аргументов в пользу CL я не услышал.

> В качестве примера: вот здесь: https://github.com/angavrilov/ecl-compute/raw/master/doc/report.ru.pdf приведено нечто вроде отчёта о результате применения такого подхода к задаче атмосферного моделирования.

Автор просто написал небольшой специализированный компилятор арифметических выражений (причем эти выражения даже в стандартной математической нотации: «Язык Лисп использует префиксный синтаксис, который неудобен для ввода и понимания больших формул»). Он сделал это на CL, но выгоды от легендарного лиспового метапрограммирования из статьи не очевидны.

По возможностям генерации вычислительного кода на Си лишпики и рядом с Mathematica не валялись.

> По возможностям генерации вычислительного кода на Си лишпики и рядом с Mathematica не валялись.

ORLY?

> Что думаете, на Лиспе можно построить более мощный фреймворк именно

за счет метапрограммирования?

Более мощный фреймворк можно, но не за счёт «метапрограммирования», а за счёт того, что CL более мощный язык, а «метапрограммирование» всего лишь один из его элементов.

> а два месяца неспешного ковыряния какого-нибудь своего кода и чтения

On Lisp можно изучить CL на довольно неплохом уровне

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

Возможность написания поддерживаемого и эффективного кода на CL после пары месяцев знакомства даже для опытных программистов мне представляется чем-то совершенно фантастическим.

> По возможностям генерации вычислительного кода на Си лишпики и рядом с Mathematica не валялись.

Mathematica умеет генерить код, использующий SSE, CUDA и прочие сецифические железные плюшки?

Да, умеет: http://www.wolfram.com/products/mathematica-cuda-free-white-paper.html

И про кодогенерацию вообще:

http://www.wolfram.com/mathematica/new-in-8/symbolicc/

http://www.wolfram.com/mathematica/new-in-8/integrated-c-workflow/

Лишпеки нервно курят за дверью

> Лишпеки нервно курят за дверью

Статья написана раньше, чем whitepaper с CUDA.

> В большинстве вакансий на тему CL, которые время от времени появляются, обычно требование к опыту программирования на CL - более 5 лет. И должен сказать, что я понимаю почему.

а они всегда требуют стандартные сроки... иногда до анекдотов доходит (сейчас ссылку не найду но думаю многие и сами видели) когда опыт превышает время существования технологии по которой требуют опыт :)

> а они всегда требуют стандартные сроки...

Кто они? В разных местах для разных языков я видел разные требования, в итоге всё дело в предлагаемой оплате.

Вот на Python можно набирать людей вообще без опыта в Python, но при наличии большого опыта в других (разных) языках. А на CL брать людей с небольшим опытом в CL ещё более опасно, чем на С++ с небольшим опытом в С++.

> А на CL брать людей с небольшим опытом в CL ещё более опасно

Почему?

> А на CL брать людей с небольшим опытом в CL ещё более опасно

Почему?

Кластеры метапарадигм же. Как нафигячат кто во что горазд. Разгребай потом.

> Кластеры метапарадигм же. Как нафигячат кто во что горазд. Разгребай потом.

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

У них там всего два разработчика и есть.

CUDA

Чего с ней делать, если расчёты целочисленные? С неограниченной размерностью.

Вопрос о компиляторах - сейчас gcc очень хорошо оптимизирует код. Что в этом плане можно сказать о CL?

SBCL обеспечивает бОльшую производительность, чем для лиспа нужно. Писать числодробилку на лиспе - нонсенс. Надо быстро и на лиспе - напишите DSL и транслятор из него в VHDL, считайте на FPGA. FPGA считает на столько быстро, что носки сдувает. Подходящий девкит с PCI-express интерфейсом стоит не больше, чем приличная видеокарта, и лишён всех проблем, связанных с побочной природой вычислений на видеокарте.

У них там всего два разработчика и есть.

Зависит от человека. У нас был человек, который за полтора года исключительно лиспового ваяния ни одного макроса не написал. Код писался ужоснаховского качества. Сейчас другой товарищ, сишно-ядерной направленности, начал писать для себя хелперы на лиспе (на сях заманаешься), так уже через пару месяцев у него очень достойно стало получаться.

Слабых программистов лучше вообще в компанию не брать, а сильные на чём угодно хорошо будут писать.

> Чего с ней делать, если расчёты целочисленные? С неограниченной размерностью.

человек по ссылке использовал CUDA с лиспом, чтобы обогнать фортран

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

Свиное рыло в халяльном ряду.

Чудо, вычисления бывают не только численными, но и символьными.

> Чудо, вычисления бывают не только численными, но и символьными.

Чудо, кроме сабжа существует, какбэ, контент:

Нужно не много - матрицы оборачивать (желательно разряженные) и интегрировать, ну и строить простейшие графики y=f(x)

> Подходящий девкит с PCI-express интерфейсом стоит не больше, чем приличная видеокарта, и лишён всех проблем, связанных с побочной природой вычислений на видеокарте.

Вот этот место вызвало некоторое бурление в массах:

«Легко за $100 купить видеокарту, производительность которой будет существенно превышать производительность топового CPU. А за $300 --- так и просто на порядок.

Не могли бы Вы привести параметры девкит-ов по цене $100 и $300 ?» (c) массы.

http://www.altera.com/products/devkits/kit-dev_platforms.jsp

> Вот этот место вызвало некоторое бурление в массах:

«Легко за $100 купить видеокарту, производительность которой будет существенно превышать производительность топового CPU. А за $300 --- так и просто на порядок.

Тут есть одна мелочь - алгоритм придется писать на VHDL.

Это вообще отдельная история, массы пока любопытствуют потенциальными возможностями этой вундервафли.

> массы пока любопытствуют потенциальными возможностями этой вундервафли.

Для специализированных задача сравнение ПЛИС и CPU просто не имеет смысла - ПЛИС зарулит CPU в глубокие минуса.

Наверное это зависит во первых от специфики задачи, во вторых от параметров по которым их сравнивать?

> Наверное это зависит во первых от специфики задачи

Да, конечно. Но основная «специфика» - это готовность писать алгоритм на VHDL (ну или DSL, как в конторе mv).

во вторых от параметров по которым их сравнивать?

Параметр - скорость работы готового изделия.