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

> Он не scheme, это во-первых.

А почему не scheme? Вроде бы, Racket - «естественное продолжение» PLT Scheme, не? Или я с чем-то путаю?

но ведь это далеко не всегда так,

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

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

Это одно и то же. Если сигнал физически не может быть доставлен за такт, то схема на этой частоте работать не будет.

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

Нет, world и уникальные типы в clean - это как раз языковое средство для реализации сайд-эффектов. В хаскеле аналогичную функцию выполняет unsafePerformIO. Монады - просто интерфейс к unsafePerformIO, можномонады убрать и с точки зрения выразительности хаскель ничего не потеряет. Но следует обратить внимание - в clean у нас есть возможность контролировать сайдэффекты, а в хаскеле нет. Другими словами - система хаскеля не может запретить нам написать код, который может быть некорректен. Система типов clean - может.

У нас целевая ф-я - считать задачу как можно быстрее за как можно меньшие деньги, и тут ПЛИС сливают.

Как это ваще утверждение соотносится с другим вашим утверждением: http://www.linux.org.ru/jump-message.jsp?msgid=6808609&cid=6810118?

> А почему не scheme? Вроде бы, Racket - «естественное продолжение» PLT Scheme, не? Или я с чем-то путаю?

Продолжение, да. Но совместимости нет. Ни прямой, ни обратной.

Целиком и полностью согласуется. Что именно Вам не понятно и где Вы видите противоречия?

И что, вообще никакой совместимости со scheme?

Спрашиваю потому, что Racket глубоко не копал, поверхностно поковырял и всё. То есть, теперь Racket - это совсем не scheme, так?

В ракете есть схема, но в дефолтовом режиме он не схема и даже не является надмножеством схемы, так как некоторые вещи вырезали или ограничили. Например, пары иммутабельные и операции set-car!/set-cdr! отсутствуют.

можно сказать #lang r5rs в начале файла, тогда можно будет писать на схеме

> Он не scheme, это во-первых.

Если мне изменяет память он может транслировать вcю R5 схему и плюс еще мног всего. Или это уже непрвда?

каких спор scheme - не лисп?

С тех самых, с каких оно scheme. Если вы хотели доказать что трансляторы scheme есть и с jit, то так бы и сказали. Дальше о терминалогии спорить не буду, мне оно как-то все равно.

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

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

Ну я даже SBCL, терплю, так что чего мне боятся.

Другой вопрос что имея полноценный лисп (или scheme) много в объеме образа не выиграешь. Тут сам подход изначально другой по сравнению <С |какой-то скриптовый язык|>. А JIT суть костыль, хоть и часто удобный.

> Нет, world и уникальные типы в clean - это как раз языковое средство для реализации сайд-эффектов.

Интересно девки пляшут. Чем отличается «языковое средство» от «интерфейса» в том смысле, в котором он присутствовал во фразе «монады — это только интерфейс»?

Монады - просто интерфейс к unsafePerformIO, можномонады убрать и с точки зрения выразительности хаскель ничего не потеряет.

Ну нет же, нет. unsafePerformIO вообще нет в стандарте. Если убрать IO, то мы просто останемся без IO, в сферическом вакууме.

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

Можно пример неконтроллируемого ввода-вывода?

Так, ясно.

Благодарю за инфу.

Надо будет посмотреть внимательно, что из него сделали. А то я, наивный, считал Racket следующим этапом в развитии PLT Scheme.

лисп это общее наименование семейства языков в которые входят и scheme и common lisp

> И что, вообще никакой совместимости со scheme?

Ну никакой - это грубо сказано, конечно, самая главная несовместимость, пожалуй - это то, что в racket консы по дефолту иммутабельные, а в схеме - мутабельные. Ну и я говорю именно о racket, как об языке, если говорить о фреймворке, то там есть #lang для r6rs.

То есть, теперь Racket - это совсем не scheme, так?

По сути, чтобы сохранять совместимость со scheme, придется не пользоваться racket-специфичными фичами. Но их слишком много, и они слишком вкусные, чтобы ими не пользоваться. То есть если вы хотите писать на racket как на scheme - это будет не ъ-вей. Хотя, конечно, можно при желании, в рамках упомянутого #lang.

Уже неплохо.

Но меня сейчас крайне заинтересовало, во что превратили Racket. :)

Это движение в какую сторону? (если он по дефолту не схема) На что похоже?

Я, конечно, сам буду углубляться, но интересно прямщас узнать, чему в той или иной степени аналогичен Racket.

> Интересно девки пляшут. Чем отличается «языковое средство» от «интерфейса» в том смысле, в котором он присутствовал во фразе «монады — это только интерфейс»?

В том, что монады сайдэффекты не реализуют, работу с сайд-эфектами реализует конкретная функция - unsafePerformIO. Монады от нее совершенно независимы. И с сайд-эффектами де-факто никак не связаны. Это просто набор ф-й оберток.

Ну нет же, нет. unsafePerformIO вообще нет в стандарте. Если убрать IO, то мы просто останемся без IO, в сферическом вакууме.

Ну да, в стандарте хаскеля вообще не описывается работа с сайд-эффектами. Там их просто нет. ИО - это просто какая-то монада, но что эта монада делает - по стандарту неизвестно. Просто монада. Как хочешь - так и реализуй. предполагается (семантически), что эта монада описывает вычисление, а программа на хаскеле - возвращает вычисление, но кто это вычисление будет исполнять (и, соответственно, кто и как будет производить инкапсулированные в нем сайд-эффекты) - это неизвестно. Короче, стандарт в данном случае упоминать смысла нет, потому что согласно стандарту в хаскеле вообще нет никакого способа вывести строчку текста на экран.

Можно пример неконтроллируемого ввода-вывода?

с unsafePerformIO же.

Но благодаря LRnLA в таких задачах ПЛИСам просто нечего делать - оба решения работают со 100% эффективностью, поскольку CPU-GPU рвут ПЛИС по флопсам при равной стоимости, то с-но фсе...

Целиком и полностью согласуется. Что именно Вам не понятно и где Вы видите противоречия?

Ознакомьтесь: http://saahpc.ncsa.illinois.edu/09/sessions/day2/session3/Herbordt_presentation.pdf. Товарищи на достаточно слабой и недорогой ПЛИС (Stratix-III) собрали свой вычислитель, рвущий на конкретной задаче CPU и GPU.

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

Во-во-во, новые фичи - это самое интересное, аж внутри всё зачесалось. :) Тотчас же полезу смотреть, что и как. И как же это я оплошал, считая PLTScheme => Racket ?

А чтобы «писать на схеме» у меня guile для этого предназначен? Тоже, конечно, не pure scheme, но всё-таки...

> (если он по дефолту не схема) На что похоже?

Ну на схему с кучей батареек и похоже больше всего :)

Это движение в какую сторону?

Racket - это такой ЯП для написания ЯП. Это, иожно сказать, официально обозначенное направление :)

Теперь всё ясно. Спасибо за краткий курс. :)

Пойду ковырять вглубь.

PS: А я-то у Racket даже сайт толком не посмотрел до сих пор... :(

Да боже мой...

1) они не использовали LRnLA, поэтому CPU и GPU у них работали неэффективно. Если бы они сумели заставить работать эффективно GPU - ПЛИС бы продули.

2) Задачи мол динамики имеют весьма специфические требования к железу, и не имеют практ. и ничего общего c теми задачами о к-х я говорю.

> В том, что монады сайдэффекты не реализуют, работу с сайд-эфектами реализует конкретная функция - unsafePerformIO. Монады от нее совершенно независимы. И с сайд-эффектами де-факто никак не связаны. Это просто набор ф-й оберток.

Ну это совсем несерьезный разговор. «Интерфейс» и «языковое средство» в данном контексте — это одно и то же. И то, и другое — это ровно то, что видит и чем пользуется программист на хацкеле.

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

После этой фразы вообще не вижу смысла продолжать. Чисто для справки на прощание: http://www.haskell.org/onlinereport/haskell2010/haskellch41.html#x49-32000041

> Если мне изменяет память он может транслировать вcю R5 схему и плюс еще мног всего. Или это уже непрвда?

#lang racket - не может. Какой-то другой #lang - может транслировать все, что душе угодно. Например, сейчас активно допиливается #lang honu с бесскобочным синтаксисом и сахарком на каждый чих. Есть алгол, мл (без типов правда), разные вариации того же racket, около-прологовые #lang-и, декларативные (типа #lang scribble - для описания документации)

Другой вопрос что имея полноценный лисп (или scheme) много в объеме образа не выиграешь.

Рантайм racket - 3.5 метра. И он по сравнению с рантаймом джавы - как самолет пятого поколения по сравнению с кукурузником довоенныхвремен.

> сейчас активно допиливается #lang honu с бесскобочным синтаксисом и сахарком на каждый чих. Есть алгол, мл (без типов правда)

А строго типизированные языки есть?

...строго и статически, я хотел сказать

> Ну это совсем несерьезный разговор. «Интерфейс» и «языковое средство» в данном контексте — это одно и то же. И то, и другое — это ровно то, что видит и чем пользуется программист на хацкеле.

НеТ, это совершенно не одно и то же. В clean есть возможность описывать сайд-эффекты средсвами языка и контролировать их на уровне типов. В хаскеле - нету. В хаскеле невозможно вообще описать ф-ю с сайд-эффектом.

После этой фразы вообще не вижу смысла продолжать. Чисто для справки на прощание: http://www.haskell.org/onlinereport/haskell2010/haskellch41.html#x49-32000041

Все это нельзя выразить в рамках семантики хаскеля. Вы можете сказать, мол - «да, это функция, которая возвращает некоторое вычисление, которое будет читать из файла». Но как _исполнить_ это вычисление - неизвестно, ну не умеет хаскель этого делать. Может, в вашей монаде описание ИО хранится вообще на каком-то интерпретируемом ЯП, интерпретатор которого вы потом должны запускать на коде, сгенерированном программой на хаскеле. Стандарт это не запрещает.

Вы упорно не можете принять тот факт, что кто то может заставить эффективно работать CPU/GPU.

> А строго типизированные языки есть?

http://docs.racket-lang.org/ts-reference/index.html Только не надо, пожалуйста, про «ваша система типов - говно». Здесь основной задачей было сделать систему типов максимально совместимую с нетипизированным кодом, а не максимально выразительную.

Всмысле статически типизированные? Есть #lang typed/racket

> http://docs.racket-lang.org/ts-reference/index.html Только не надо, пожалуйста, про «ваша система типов - говно».

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

Вы упорно не можете принять тот факт, что кто то может заставить эффективно работать CPU/GPU.

Define «эффективно»? «Используя Lrnwhatever (c)(tm) мы»? FPGA даёт больше гибкости в реализации вашей эффективности тупо по своей природе. CPU/GPU - универсальные и, тем самым, ограниченные решения.

> можно сказать #lang r5rs в начале файла, тогда можно будет писать на схеме

Так они, кажется, заявляли и о поддержке r6rs. Даже дока по r6rs в пакет включена.

r6rs тоже есть

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

> тот же алгол - он статически типизированный?

Да.

CPU/GPU - универсальные и, тем самым, ограниченные решения.

Вы не пробовали посмотреть на проблему под другим углом?

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

тот же факт, что эта связка является универсальным решением в 100500 прочих случаях нас не должен тревожить в данном случае, ибо к делу не относится

таким образом Вы можете выжать FPGA, но лишь не вполне оптимальным образом приблизитесь к архитектуре, которая уже существует и, добившись требуемой эффективности и заточенности под задачу, всё равно проиграете, поскольку имеете дело с узкоспециализированным железом :)

PS да, это всего лишь моё предположение, оно основано лишь на смутных ощущениях от изучения алгоритма и Ваших с оппонентами диалогах, можете кидать свои помидоры

// а то ведь все копья уже поломали

> FPGA даёт больше гибкости в реализации вашей эффективности тупо по своей природе. CPU/GPU - универсальные и, тем самым, ограниченные решения.

Есть такая ТРИЗ (теория решения изобретательских задач). Так вот, согласно этой теории, в ситуации когда есть море дешевых CPU/GPU (за счет массовости производства и для игр и проч. бытовых приложений), и сколько то дорогих элитарных FPGA, для решения задач с большой выч сложностью куда разумней использовать CPU/GPU разработав соотв. код. То-то амерские беспилотники и проч хрень на GPU летает, хотя делали совсем не для них (один из разработчиков делился на семинаре).

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

> Так они, кажется, заявляли и о поддержке r6rs. Даже дока по r6rs в пакет включена.

Вот тут список практически всего, что есть: file:///C:/Program%20Files/Racket-Full-5.1.3.8/doc/index.html еще можно глянуть на planet

> У FPGA совсем другая ниша, напр высоконагруженные системы обработки данных в реальном времени

Если РЛС того же БПЛА не является такой системой, можешь бросить в меня камень :)

Тьфу ты http://docs.racket-lang.org/

Если РЛС того же БПЛА не является такой системой, можешь бросить в меня камень :)

1. с чего Вы решили что у любого БПЛА всенепременно есть РЛС?
2. даже если и есть - не является, гуглите по РЛС или готов пояснить на пальцах, если лень :)

За что купил, за то и продаю - был у нас на семинаре разраб GPU, рассказывал что склепали фреймфорк для военных и теперь у них те же GPU ставят во все подряд. Почему не ПЛИС - мне тоже не понятно, мб тупо дорого? Могу предположить, что не настолько оно высоконагруженно (авионика сушки суммарно как 386 что ли, но хватает элеронами шевелить), с другой стороны хитрые алгоритмы распознавания образов и че там еще стоит в БПЛА могут быть весьма прожорливы (при том что джип с арабами за латентность в 0.001 сек далеко не уедет;-)).

> с чего Вы решили что у любого БПЛА всенепременно есть РЛС?

Кто говорил о «любом»? У штатовских боевых и разведывательных беспилотников она есть, думаю, и у израильских тоже.

даже если и есть - не является

Является.

готов пояснить на пальцах, если лень :)

Давай.

авионика сушки суммарно как 386 что ли, но хватает элеронами шевелить

у нас всё что не по схеме «утка» - на тягах до сих пор, емнип

другой стороны хитрые алгоритмы распознавания образов и че там еще стоит в БПЛА

у меня только один вопрос - нафига они на борту нужны? :)

> За что купил, за то и продаю - был у нас на семинаре разраб GPU, рассказывал что склепали фреймфорк для военных и теперь у них те же GPU ставят во все подряд. Почему не ПЛИС - мне тоже не понятно

Как по мне, оба решения работоспособны, но лично мне больше нравится решение на DSP (GPU - это фактически DSP), потому что гибче.

А что за GPU конкретно, не помнишь? NVIDIA?

> у меня только один вопрос - нафига они на борту нужны? :)

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

> GPU - это фактически DSP

Я вас таки умоляю, в современных GPU полноценные АЛУ и сотни независимых аппаратно планируемых тредов. Вылезай уже из криокамеры, а?

> А что за GPU конкретно, не помнишь? NVIDIA?

Наск помню - да (но могу и соврать). Год что ли назад было...

лол, спалился вендузнятнег :)