Хабрахабр / Комментарии к посту «Three Futamura Projections и не только» в блоге «Ненормальное программирование» http://habrahabr.ru/rss/post/47418/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 14:17:38 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif Хабрахабр 03.01.2009 02:39:07 cdev http://habrahabr.ru/blogs/crazydev/47418/#comment_1247489 http://habrahabr.ru/blogs/crazydev/47418/#comment_1247489 На примере unix — некая программа может быть скомпилирована с поддержкой библиотек A, B, C. А может обойтись и без них. Например, с поддержкой JPG, PNG, X11 или без части из них. Это отразится на ее функциональности, но про это мы можем знать заранее. Далее — есть дистрибутивы ОС. Они поставляются с предкомпилированными программами. При инсталляции есть варианты выбора вида инсталляции — с X11 и без оного. Вопрос в том как отрубить у готовых бинарников лишние зависимости? Т.е как вести разработку программ и их оформление чтобы это отрубание происходило без их пере компиляции? Вроде эта задача может иметь решение в отличии от оптимизации любого кода? :)

Если обобщать — как оптимизировать программу зная не фиксированные параметры, а перечни или диапазоны параметров. Или же от обратного — зная те диапазоны параметров, которые заведомо не будут поданы на вход программе.

Или же еще по другому — отсекать диапазоны входных значений на уровне их ввода, а не на уровне использования. При этом оставляя ту же программу — без пере компиляции способную включить требуемую функциональность. Пример — как только появляется библитотека Mysql включить поддержку ее не пересобирая с соответствующей libmysqlclient, но при этом не валиться в core, если пользователь укажет на входе ключик -connect-mysql.

Сейчас по большей части в C это решается через условную компиляцию и #ifdef.

Может есть уже готовые решения?

ps. в давние времена был забавный глюк в некоей IDE — если в программе на C не встречалось ни одного дробного числа в явном виде, то в printf переставало обрабатываться %f — вывод чисел с плавающей запятой. :)]]> Sat, 03 Jan 2009 02:39:07 GMT cdev 03.01.2009 02:13:32 cdev http://habrahabr.ru/blogs/crazydev/47418/#comment_1247475 http://habrahabr.ru/blogs/crazydev/47418/#comment_1247475 Sat, 03 Jan 2009 02:13:32 GMT cdev 22.12.2008 16:35:18 markshevchenko #comment_1220603 #comment_1220603 > прямо «взлетят» от распараллеливания…

Я тоже не думаю, что взлетят. Скорее, появится поле для реализации более сложных функций. Помните время, когда проверка правильности текста выполнялась отдельно от его ввода? А потом в Office 2000 (если не в 97) текст стал проверяться «на лету». Машины дорасли. Но тогда всё это делалось на одном процессоре, а тут, пожалуйста — ещё несколько таких же процессоров под боком.

Из того, что у всех на виду, ожидаю серьёзных прорывов в компьютерных играх. Там производительность всегда актуальна.

Вот с точки зрения прикладного разработчика не всё однозначно. Но вот, скажем, такая частая операция, как построение отчётов, параллелится влёт.

> Где гарантия, что всё это станет действительно быстрее работать? А не начнётся
> пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и
> синхронизацией?

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

> Только вот такие программы и на Си писать легко. Проблемы начинаются, когда
> возникает необходимость сделать «share something».

Я бы не сказал, что легко. Можно, но слишком многословно, и слишком нетрадиционно. Был у меня опыт написания библиотеки нечёткой логики на Си++, воспоминания весёлые. :) Закончилось тем, что когда я этот код пытался показывать другим программистам, они его не понимали, потому что воспринимали императивно. :)

Да, так вот, по поводу разделения ресурсов. Вы, конечно, правы. Но тут без конкретики уже очень сложно обсуждать. Вы приведёте мне проблему, которая не параллелится, я буду приводить проблему, которая хорошо параллелится, и так мы можем впасть в вечный цикл. :)]]> Mon, 22 Dec 2008 16:35:18 GMT markshevchenko 22.12.2008 16:06:17 Daymz http://habrahabr.ru/blogs/crazydev/47418/#comment_1220516 http://habrahabr.ru/blogs/crazydev/47418/#comment_1220516
И ещё «минус первую» проекцию: процесс разработки есть специализация возможностей разработчика конкретной задачей.

Отыскал свои высказывания шестилетней давности на эти темы:
www.jroller.com/deep/entry/cyber_telepathy_of_generative_programming]]> Mon, 22 Dec 2008 16:06:17 GMT Daymz 22.12.2008 15:32:23 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1220418 http://habrahabr.ru/blogs/crazydev/47418/#comment_1220418
более-того ну возьмем мы автоматическое распараллеливание какой-нибудь десктопной программки на Haskell, в которой списки ([a]) автоматически превратились в параллельные массивы ([:a:]) и даже очень много функций принимающих списки автоматически распаралилились и стали принимать параллельные массивы… Где гарантия, что всё это станет действительно быстрее работать? А не начнётся пыхтение, сопение и переключение контекстов и постоянные проблемы с кэшем и синхронизацией?

Нет, я, конечно, не отрицаю, что на Haskell можно достаточно легко писать руками параллельные программы в стиле «share nothing». Только вот такие программы и на Си писать легко. Проблемы начинаются, когда возникает необходимость сделать «share something».

Я считаю на этом поле the next big thing это транзакционная память. Будет ли от неё счастье, мне пока не ясно до конца, но надежды есть…
]]> Mon, 22 Dec 2008 15:32:23 GMT mraleph 22.12.2008 15:16:48 markshevchenko #comment_1220363 #comment_1220363
С функциональными значительно всё проще, вплоть до автоматического распараллеливания. Посмотрим, вдруг и окажется так, что хаскель быстрее си будет.]]> Mon, 22 Dec 2008 15:16:48 GMT markshevchenko 22.12.2008 11:57:14 BisnoyZakat http://habrahabr.ru/blogs/crazydev/47418/#comment_1219752 http://habrahabr.ru/blogs/crazydev/47418/#comment_1219752 Mon, 22 Dec 2008 11:57:14 GMT BisnoyZakat 22.12.2008 11:53:10 afterdark http://habrahabr.ru/blogs/crazydev/47418/#comment_1219734 http://habrahabr.ru/blogs/crazydev/47418/#comment_1219734 Mon, 22 Dec 2008 11:53:10 GMT afterdark 21.12.2008 21:51:36 RumataEstora http://habrahabr.ru/blogs/crazydev/47418/#comment_1218718 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218718 Sun, 21 Dec 2008 21:51:36 GMT RumataEstora 21.12.2008 20:36:17 artyfarty http://habrahabr.ru/blogs/crazydev/47418/#comment_1218577 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218577 Sun, 21 Dec 2008 20:36:17 GMT artyfarty 21.12.2008 20:34:14 maxshopen http://habrahabr.ru/blogs/crazydev/47418/#comment_1218575 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218575
В этом смысле «Футамура» и «Футурама», имхо — идеальная пара, на глаз практически неразличимая.

Да и вообще теории териями, а практика без всяких глупостей доказывает этот тезис. У меня есть знакомый, он часто опечатывается в словах именно по типу неправильного порядка нажатия клавиш. Когда я читаю его письма ~90% слов читаются на ходу]]> Sun, 21 Dec 2008 20:34:14 GMT maxshopen 21.12.2008 17:25:27 FatalErr http://habrahabr.ru/blogs/crazydev/47418/#comment_1218279 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218279 Sun, 21 Dec 2008 17:25:27 GMT FatalErr 21.12.2008 16:36:30 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1218189 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218189 Sun, 21 Dec 2008 16:36:30 GMT alex_blank 21.12.2008 16:04:46 AstralMan http://habrahabr.ru/blogs/crazydev/47418/#comment_1218128 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218128 Sun, 21 Dec 2008 16:04:46 GMT AstralMan 21.12.2008 15:51:36 abdalAziz http://habrahabr.ru/blogs/crazydev/47418/#comment_1218106 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218106 Sun, 21 Dec 2008 15:51:36 GMT abdalAziz 21.12.2008 15:15:50 Kartoshk0 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218035 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218035 Sun, 21 Dec 2008 15:15:50 GMT Kartoshk0 21.12.2008 15:09:43 quintus http://habrahabr.ru/blogs/crazydev/47418/#comment_1218027 http://habrahabr.ru/blogs/crazydev/47418/#comment_1218027 Sun, 21 Dec 2008 15:09:43 GMT quintus 21.12.2008 14:48:11 VDG http://habrahabr.ru/blogs/crazydev/47418/#comment_1217969 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217969
перескоки букв на одну-две позиции очень легко читаются. а в вашем примере дальность «перескока» в основном 3-5 позиций, это сложный пример.]]> Sun, 21 Dec 2008 14:48:11 GMT VDG 21.12.2008 14:36:13 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217925 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217925
разумеется]]> Sun, 21 Dec 2008 14:36:13 GMT alex_blank 21.12.2008 14:29:59 lostmsu http://habrahabr.ru/blogs/crazydev/47418/#comment_1217903 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217903
Очевидно, нельзя написать такую specialize, которая смогла бы специализировать код на любом языке. Нужно некое внутреннее представление, которая specialize могла бы обрабатывать и функция перевода кода в это представление — это раз.

Далее. Какой код, как вы думаете, получится после применения specialize к этому внутреннему представлению? Правильно! Получится снова промежуточный код. А значит, нам нужно преобразовать его к исходному формату. То есть нам нужна ещё и функция перевода промежуточного кода в старый код.

Так вот! По сути компилятором (вернее, генератором кода), оказывается вторая переданная функция, а вовсе не specialize.

Таким образом, мы ничего нового не изобрели, а эта «магическая функция» specialize остаётся не более чем тем, чем она являлась первоначально — вычислителем константных выражений.]]> Sun, 21 Dec 2008 14:29:59 GMT lostmsu 21.12.2008 13:30:21 lostmsu http://habrahabr.ru/blogs/crazydev/47418/#comment_1217755 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217755
Очень интересно, реально ли воспользоваться идеей для написания компиляторов. Есть некая загвоздка — всё было бы прекрасно, если бы транслярор был написан на ассемблере, но сейчас трансляторы пишут на высокоуровневых языках. А это означает, что specialize(interpreter, code) вернёт код на том языке, на котором написан interpreter, а не на asm'е, к сожалению.]]> Sun, 21 Dec 2008 13:30:21 GMT lostmsu 21.12.2008 13:26:19 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1217749 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217749 в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)

в статье функциональщина, я говорил про С++

потому что анализировать функциональный код проще


не думаю что уж сильно проще, где-то проще, а где-то сложнее… вот над fusion в GHC сколько бьются, никак сделать нормально не могут =)

и вообще вас разве привлекают только простые задачи? меня наоборот =)]]> Sun, 21 Dec 2008 13:26:19 GMT mraleph 21.12.2008 13:22:30 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217740 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217740 > большинство известных мне оптимизаций* делаются на уровне весьма себе низкоуровневого императивного IR.

в статье как раз рассказывается про оптимизации на высоком уровне (частичные вычисления)

>> не понял почему.

потому что анализировать функциональный код проще
]]> Sun, 21 Dec 2008 13:22:30 GMT alex_blank 21.12.2008 13:19:09 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1217734 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217734
]]> Sun, 21 Dec 2008 13:19:09 GMT mraleph 21.12.2008 13:16:16 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217729 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217729 Sun, 21 Dec 2008 13:16:16 GMT alex_blank 21.12.2008 13:13:59 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1217723 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217723 а C не быстрее, C — более explicit, так же, как assembler vs. CM

Ну не надо противопоставлять теплое мягкому. explicit это одно свойство языка, а скорость — это совершенно другое.
Графики явно показывают, что С быстрее… Конечно, можно возразить, что у Haskell'а есть другие преимущества и его оптимизацией занимаются не столько времени, сколько занимаются оптимизациями императивных языков… Но тут мы ступаем на весьма зыбкую почву. ]]> Sun, 21 Dec 2008 13:13:59 GMT mraleph 21.12.2008 13:10:14 rumkin http://habrahabr.ru/blogs/crazydev/47418/#comment_1217715 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217715 Sun, 21 Dec 2008 13:10:14 GMT rumkin 21.12.2008 13:09:42 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1217713 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217713 т.е. я вообще не считаю, что с императивными языками стоит возиться

не понял почему.

ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++


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

* — я говорю об императивщине. ]]> Sun, 21 Dec 2008 13:09:42 GMT mraleph 21.12.2008 12:59:15 ciiccii http://habrahabr.ru/blogs/crazydev/47418/#comment_1217689 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217689 Sun, 21 Dec 2008 12:59:15 GMT ciiccii 21.12.2008 12:44:36 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217666 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217666
ну в самом деле, не будете же вы делать оптимизацию ассемблерного кода, когда эти оптимизации проще делать на уровне, скажем, C++]]> Sun, 21 Dec 2008 12:44:36 GMT alex_blank 21.12.2008 12:43:29 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217663 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217663
в статье есть ссылка на попытку сделать суперкомпилятор для Java, но что-то у них не пошло

а C не быстрее, C — более explicit, так же, как assembler vs. C

задача в том, чтобы сделать функциональный код как минимум не медленнее вручную написанного]]> Sun, 21 Dec 2008 12:43:29 GMT alex_blank 21.12.2008 12:23:33 mraleph http://habrahabr.ru/blogs/crazydev/47418/#comment_1217623 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217623
// в статье кстати красивый график есть, к которому заглавие «А Си быстрее и без суперкомпиляции» подходит =)

]]> Sun, 21 Dec 2008 12:23:33 GMT mraleph 21.12.2008 12:11:11 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217588 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217588
A Supercompiler For Core Haskell (pdf)]]> Sun, 21 Dec 2008 12:11:11 GMT alex_blank 21.12.2008 11:55:59 taketwo http://habrahabr.ru/blogs/crazydev/47418/#comment_1217550 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217550 Sun, 21 Dec 2008 11:55:59 GMT taketwo 21.12.2008 11:52:48 alex_blank http://habrahabr.ru/blogs/crazydev/47418/#comment_1217542 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217542 Sun, 21 Dec 2008 11:52:48 GMT alex_blank 21.12.2008 11:49:54 Temp1ar http://habrahabr.ru/blogs/crazydev/47418/#comment_1217533 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217533 Sun, 21 Dec 2008 11:49:54 GMT Temp1ar 21.12.2008 11:46:57 VlK http://habrahabr.ru/blogs/crazydev/47418/#comment_1217525 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217525 Sun, 21 Dec 2008 11:46:57 GMT VlK 21.12.2008 11:39:23 leonard http://habrahabr.ru/blogs/crazydev/47418/#comment_1217511 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217511 Sun, 21 Dec 2008 11:39:23 GMT leonard 21.12.2008 11:13:47 BisnoyZakat http://habrahabr.ru/blogs/crazydev/47418/#comment_1217469 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217469 Sun, 21 Dec 2008 11:13:47 GMT BisnoyZakat 21.12.2008 11:03:46 vuspenskiy http://habrahabr.ru/blogs/crazydev/47418/#comment_1217465 http://habrahabr.ru/blogs/crazydev/47418/#comment_1217465 Sun, 21 Dec 2008 11:03:46 GMT vuspenskiy