LINUX.ORG.RU

Lisp решение оказалось самым быстрым в ПФП2009


0

0

Из корректно отработавших программ Lisp решение самое быстрое --- 74с.

Ближайший конкурент на C# 153 с.

При этом решение написано полностью в духе Lisp --- стек eDSL.

Увы но жюри не осилившее по всей видимости такой подход к решению не присудило заслуженного I места :( Всех отправить на пересдачу SICP :)

Характерна строчка из таблицы (из обсуждения на форуме журнала) характеризующей Lisp решение среди прочих: «Lisp --- ХЗ какая логика».

Там же (в обсуждении) муссируется некое решение на питоне которое якобы быстрое «но вот беда некорректно решает примеры» :) Думаю что довести его до ума это задача, в ходе решения которой станет ясно почему подход с порождением цепочки eDSL является более продуктивным.

http://community.livejournal.com/fprog/11783.html

★★★★★

А что, на цедвакреста никто писать не стал?

Ближайший конкурент на C# 153 с.

Why so slow?

anonymous
()

> Lisp решение оказалось самым быстрым в ПФП2009

за такой топик, щас тебя назовут «лиспером» и обвинят в троллизме

CL-USER
()
Ответ на: комментарий от anonymous

> А что, на цедвакреста никто писать не стал?

в следующий раз пусть создадут отдельный топик в Development с соот-им заголовком, хотя может он был - но я, например, про этот ПФП2009 только сейчас услышал

lester ★★★★
()

> стек eDSL.

Увы но жюри не осилившее по всей видимости такой подход к решению не присудило заслуженного I места

«Lisp --- ХЗ какая логика».

И это реальный недостаток: код, помимо всего прочего, должен быть понятным. 4 уровня макроподстановок чем-то напоминают однострочник на перле.

anonymous
()

хм, надо будет туда че нить на плюсах толкнуть в селудущем году

antony986
()

Отличный пример того, как и в уровне абстракции не проиграть,
и производительность не угробить. На C++ такого никогда нельзя
будет сделать, слишком запутанный язык.

Sphinx ★★☆☆
()
Ответ на: комментарий от lester

Этот конкурс был объявлен в каком-то номере журнала «Практика функционального программирования» и задачи этого конкурса обсуждались на лоре в новости о выходе этого номера журнала.

gorky ★★
()
Ответ на: комментарий от gorky

> Этот конкурс был объявлен в каком-то номере журнала «Практика функционального программирования» и задачи этого конкурса обсуждались на лоре в новости о выходе этого номера журнала.

очевидно, что не все читают этот журнал и обсуждают его, кстати если не сложно - киньте кто-то ссылку на условия задач

lester ★★★★
()
Ответ на: комментарий от mv

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

lester ★★★★
()
Ответ на: комментарий от anonymous

>4 уровня макроподстановок чем-то напоминают однострочник на перле.

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

зы я Ъ, но по ссылке нет никаких результатов, где вы это все нашли?

cvb
()

«Нам ничего не понятно!» - Это очень забавный критерий оценки

bioreactor ★★★★★
()
Ответ на: комментарий от cvb

> Какая разница сколько там макросов если dsl задокументирован

«Нам ничего не понятно!» - Это очень забавный критерий оценки


Реальный код надо расширять и в этом случае разница большая. Самое простое решение является самым лучшим до тех пор, пока удовлетворяет требованиям задачи. В данном случае swizard не дал никакого объяснение, что принятая им сложная схема является действительно необходимой: непонятно какая бы была производительность если он действовал в лоб в стиле решения на VB. В обсуждении результатов редакция ссылалась как отрицательный на пример одного решения на OCaml, где ради 20%-процентного прироста в производительности автор пошёл на существенное увеличение размера кода.

Вообще, очевидно, что данное решение вообще-бы никакого места не заняло, если бы не продемонстрированная производительность. Но мысль о возможности выбора Common Lisp ради производительности выглядит не очень убедительно. В данном случае можно ещё и подозревать, что решение на чистом C было бы короче, яснее и быстрее.

Изначально редакция надеялась, что решение на ФП-языках или на вариантах lisp будет короче и яснее, так как считается, что эти языки обладают большей выразительности. Однако, среди представленных решений наибольшей ясностью обладают решения на C# и VB. Количество представленных решений было очень мало, так что на основе этого нельзя делать каких-либо выводов, но если бы схожие результаты были получены и при большем количестве участников (а это представляется мне весьма вероятным), то это дало бы все основания утверждать, что профессиональная разработка на ФЯП и диалектах lisp отсутствует как явление.

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

archimag ★★★
()
Ответ на: комментарий от anonymous

> И это реальный недостаток: код, помимо всего прочего, должен быть понятным. 4 уровня макроподстановок чем-то напоминают однострочник на перле.

1) каждый из уровней прозрачен как ... хм, скажем «слеза младенца».

2) каждый из уровней оптимизирован ( может быть оптимизирован) до предела.

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

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от cvb

> зы я Ъ, но по ссылке нет никаких результатов, где вы это все нашли?

вот описание решения на CL...

http://swizard.livejournal.com/142027.html

после этого спрашивать «как оно работает?» могут только люди, которые до Зусмана доколебаться способны на тему логики работы цикла интерпретатора eval-apply :(

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от archimag

>Изначально редакция надеялась, что решение на ФП-языках или на вариантах lisp будет короче и яснее, так как считается, что эти языки обладают большей выразительности.

«Изначально редакция» хотела, чтобы «ей сделали за@бись», а потом оказалось «лебедь раком щуку»

Ну и если при рассмотрении решения на CL выкинуть создание eDSL, но добавить краткую справку о нём - решение не станет «короче и яснее»?

Или чего бы тогда не просмотреть заодно исходники «стандартных библиотек» всех остальных языков (тем где эти библиотеки шире стандарта CL)?

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

Когда уже недодрочившие спермотоксикозники перестанут пенисомерией заниматься?

yyk ★★★★★
()

Основная сложность была в алгоритме. Сам язык программирования здесь вторичен. Потому решение на питоне оказалось самым быстрым, хотя и уходящим в бездну (_|_) для некоторых входных данных.

dave ★★★★★
()
Ответ на: комментарий от dave

> Потому решение на питоне оказалось самым быстрым

Да не было там никакого Python, там был прежде всего Cypthon, который вовсе не Python.

archimag ★★★
()
Ответ на: комментарий от yyk

> А писать на лиспе макаронный код

Извините, а что такое «макаронный код»? Я с таким жаргонизмом не знаком :(

archimag ★★★
()
Ответ на: комментарий от archimag

а я надеялся :) даже цитату заготовил: «С трибуны махали нам члены, такого родного...» (С) жюри :)

Вообще «судейство» по Козьме П. прошло: «Полнота специалиста подобна флюсу».

Судейскую коллегию отбирают по принципу схожести мнения. Например оценить решения батареи эталонных задач. Даже методы есть учёта недостоверности мнения эксперта на основе его ошибок в тестовых задачах.

Ну или второй метод классический (когда нет эталонных задач). По Дельфи этапы оценки, на каждом из которых анонимно экспертов знакомят с объяснениями аномально отклонившихся оценок. Процесс прекращают когда оценка перестает меняться. Мнение «бабы яги против» выносят в решение как альтернативное.

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от dave

нет. я же все таки понял, вот если бы не понял... :)

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от psv1967

Ничего не хочу сказать о степени объективности судейства, мне это как бы не интересно, в концов концов, это же не пионерский отряд, а первое место в конкурсе максимум тянет на флаг, которым можно помахать на ЛОРе.

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

archimag ★★★
()
Ответ на: комментарий от archimag

>Извините, а что такое «макаронный код»? Я с таким жаргонизмом не знаком :(

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

yyk ★★★★★
()
Ответ на: комментарий от archimag

>решение на Common Lisp должно было бы претендовать на лидерстве прежде всего в ясности и простоты кода

эти факторы можно оценить объективно и верифицируемо?

yyk ★★★★★
()
Ответ на: комментарий от yyk

> это не «жаргонизм», а моя собственная «подсознательная ассоциация» =)

Видимо тот пост полностью из таких «подсознательных ассоциаций» и состоит, ибо я абсолютно не понял, что вы хотели сказать.

эти факторы можно оценить объективно и верифицируемо?


Зачем? Код читаю и расширяют не машины, а люди, конкретные люди живую в данный момент. Возможно, через 100 лет, когда «матан» будут преподавать в младших классах (что, конечно, вряд ли), или у людей будет прямое подключение к «матрице» (что более вероятно) люди будут оценивать код по другому. Сейчас же, вполне достаточно того, что несколько специалистов (не самых последних программистов) посмотрели и сказала: «ничего не понятно».

archimag ★★★
()
Ответ на: комментарий от archimag

>Видимо тот пост полностью из таких «подсознательных ассоциаций» и состоит,

ну если вам «видимо» - я причём? =)

ибо я абсолютно не понял...


опять-же, ваши проблемы - не? =)

Ну да, я нарываюсь на «чукча не читатель - чукча писатель». Тред закончен.

Сейчас же, вполне достаточно того, что несколько специалистов (не самых последних программистов) посмотрели и сказала: «ничего не понятно».


Ну да, ёжик тоже ничего не понимал, слезая с кактуса

yyk ★★★★★
()
Ответ на: комментарий от yyk

решение на Common Lisp должно было бы претендовать на лидерстве прежде всего в ясности и простоты кода

эти факторы можно оценить объективно и верифицируемо?

Можно. Решение же на VB выиграло. Думаешь, жюри ПФП (которое к VB относится, скорее всего, как к чему-то не очень хорошему) не хотели бы видеть в лидерах Хаскелль или хотя бы CL? Но нет, отрицать простоту решения на VB - это было бы необъективно.

Я лично давно стал рассматривать эффективность программы, главным образом, с позиций усилий, потраченных на её разработку. Остальное вторично.

mv ★★★★★
()
Ответ на: комментарий от mv

>> эти факторы можно оценить объективно и верифицируемо?

Можно.


можно только в случае формализации оценки этих факторов. Возьмётесь? В противном случае это всего лишь мнение, пусть и «авторитетных», но всё-же «отдельных лиц».

yyk ★★★★★
()
Ответ на: комментарий от LamerOk

А поддержка, внедрение и сопровождение?

От языка программирования это, по-моему, совсем не зависит.

mv ★★★★★
()
Ответ на: комментарий от yyk

В чём заключается ваша мысль? У вас есть отличное мнение? Ну так озвучили бы его...

archimag ★★★
()
Ответ на: комментарий от yyk

можно только в случае формализации оценки этих факторов. Возьмётесь? В противном случае это всего лишь мнение, пусть и «авторитетных», но всё-же «отдельных лиц».

Любая оценка - это чьё-то мнение. Пусть даже метрику посчитал компьютер, но принцип оценки в него всё равно заложил человек.

Касаемо той программы на VB: она работает корректно, текст программы очень маленький, решение доступно для понимания, ибо сделано «в лоб». Скорость всего в 2-3 раза хуже.

mv ★★★★★
()
Ответ на: комментарий от mv

>Думаешь, жюри ПФП ... не хотели бы...

А думаю (да, это всего лишь моё мнение), что жюри хотело лишь показать, какое оно жюри... Ну или само себя загнало в такие условия должным образом не расставив акценты в описании факторов и их «весов», которые будут участвовать в оценке... Опять-же, конкурс алгоритмов или их кодирования? Короче, shootout, при всей своей абсурдности, вершина подобной пенисометрии :\

yyk ★★★★★
()
Ответ на: комментарий от mv

>Любая оценка - это чьё-то мнение. Пусть даже метрику посчитал компьютер, но принцип оценки в него всё равно заложил человек.

А длинна чего-то, измеренная линейкой - это мнение того, кто «изобрёл» линейку для измерения «длин»? =\

Так я и предложил вам «изобрести» такие «линейки» для указанных факторов.

Касаемо той программы на VB: она работает корректно, текст программы очень маленький, решение доступно для понимания, ибо сделано «в лоб».


VB - это как калькулятор. Переписать его можно на каком угодно языке. Смысл тогда в этом конкурсе? Таки главным критерием было «способность кодера придумать наиболее простой алгоритм»? Тогда при чём тут языки?

yyk ★★★★★
()
Ответ на: комментарий от jtootf

>скажи, какой вариант проще?

ну ещё одно доказательство, что конкурс алгоритмов, а не их реализаций

yyk ★★★★★
()
Ответ на: комментарий от yyk

> Таки главным критерием было «способность кодера придумать

наиболее простой алгоритм»?


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

archimag ★★★
()
Ответ на: комментарий от archimag

>Простота - это то, что ценится прежде всего, ибо действительно требует мастерства.

Ещё раз акцентирую ваше внимание: при чём здесь особенности разных языков? Да, вот идея на окамле мне понравилась (на vb так и не посмотрел). Кто победил? КОДЕР! Вопрос: при чём тут языки со своими возможностями/особенностями?

yyk ★★★★★
()
Ответ на: комментарий от mv

>Я этот алгоритм видел ~10 лет назад у Шикина с Боресковым ;) «Компьютерная графика: полигональные модели.», с. 202

осталось спросить у авторитетного жюри - читали ли они когда-нибудь эту книгу? =]]]]

yyk ★★★★★
()
Ответ на: комментарий от jtootf

В узком случае да, проще.

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

psv1967 ★★★★★
() автор топика
Ответ на: комментарий от yyk

> Вопрос: при чём тут языки со своими возможностями/особенностями?

есть задача - распарсить XML в 100Мб, причем сделать это быстро и без использования дополнительной памяти - покажите решение не на С/С++

lester ★★★★
()
Ответ на: комментарий от yyk

Вопрос: при чём тут языки со своими возможностями/особенностями?

Если бы на хаскелле или лиспе программа получилась в 10 строчек и при этом ещё и работала корректно, то выиграла бы она.

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

mv ★★★★★
()
Ответ на: комментарий от yyk

осталось спросить у авторитетного жюри - читали ли они когда-нибудь эту книгу? =]]]]

В этой книге просто понадёрганы рецепты. Алгоритм тот - тоже не их изобретение.

mv ★★★★★
()
Ответ на: комментарий от yyk

> Вопрос: при чём тут языки со своими возможностями/особенностями?

Как при чём? Если язык Common Lisp является более выразительным, чем VB (а это так), то и решение на Common Lisp должно быть более выразительным, ясным и простым. В данном случае, количество участников конкурса не позволяет делать какие-либо выводы. Но в любом случае, оцениваются ведь не языки, а способность людей писать хорошие программы на этих языках. Т.е. фактор человека является ключевым. Языки создаются для людей: что бы одни писали, а другие читали и модифицировали, а не существуют сами по себе в вакууме.

archimag ★★★
()
Ответ на: комментарий от archimag

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

Ну не знаю, введение eDSL всегда упрощает работу с задачей. Решение на СL по моему и продемонстрировало эффективность такого фундаментального подхода к решению задач.

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

Да это именно «индустриальный» подход не для традиционной «галеры с рабами», а для специалиста из постиндустриального мира. Именно это я и приветствую у Автора.

Вопрос только в рынке задач такой сложности. Сейчас вся ИТ на уровне паровоза какого то работает.

Лично я «негром на галере» быть не собираюсь ни при каких обстоятельствах не связанных с угрозой жизни мне и близким.

psv1967 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.