Здравствуйте, VladD2, Вы писали:
VD>В общем, твои слова верны для редких частных случаев и не верны в общем.
Как раз-таки наоборот. Его слова верны в общем случае, а ты говоришь о наиболее вероятных случаях, которые уже являются частными.
Если уж на то пошло, то спор должен идти о распределении задач по шкале "будет деградация" — "будет улучшение" — "будет линейное масштабирование". Мне кажется, ваш спор сводится к тому, что ты ставишь слишком большую часть задач в область "будет улучшение" и далее, а он — "будет улучшение" и меньше.
VD>А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
Ну и самый весомый аргумент в споре — это всё предположить об оппоненте и на этом основании его грязью полить.
Здравствуйте, dr.Chaos, Вы писали:
DC>Да дело то не в ФП, а в возможности построения алгоритмов путём комбинирования набора примитивных операции, а тут у Хаскелла, ИМХО, абсолютное преимущество и система типов, и TemplateHaskell и ещё море фич и библиотек, которые могут в этом помочь.
Ох, ох, ох. Просто фанатизм какой-то. Прямо за пределми Хаскеля мир кончается и только на нем можно комбинаторы делать.
Для "построения алгоритмов путём комбинирования набора примитивных операции" нужно всего лишь, чтобы в языке имелась возможность создавать функции (или лямбды) в рантайме путем комбинирования других функций. Это есть начиная с C# 2.0, а в C# 3.0 это можно делать относительно удобно.
А уж в языках поддерживающих ФП на 100% это делается точно не сложнее чем в Хаскеле.
DC>Я бы ещё понял если б ты вспомнил о Немерле с его макросами, но от додиеза выигрыш только в ФП будет.
Я привел минимально достаточный пример. Вот, к примеру, тебе ссылка
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remark, Вы писали:
R>Да, всё правильно. Самые интеллектуальные из работающих сейчас и постоянно развивающихся средств поддержки таких парадигм, которые я знаю (средства), — есть библиотеки для С++ и Fortran.
В С++ (Open MP) как раз я вижу самые убогие и экстенсивные средства. Массовый параллелизм на них делать очень сложно.
Из того что есть можно выделить PLINQ и Эрланг (а так же похожие решения: акторы в Скале и Рандеву в Ада).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
E>Ну о чём у вас спор-то? Ты не веришь, что аппаратно адаптированный под узкий круг задач чип может быть радикально эффективнее компа общего назначения (например однокристаллки)?
Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций.
E>Ну в сторону CUDA посмотри, например, или на синоптические чипы...
Неистребима страсть местного народа поучать
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dr.Chaos, Вы писали:
DC>>Да дело то не в ФП, а в возможности построения алгоритмов путём комбинирования набора примитивных операции, а тут у Хаскелла, ИМХО, абсолютное преимущество и система типов, и TemplateHaskell и ещё море фич и библиотек, которые могут в этом помочь.
VD>Ох, ох, ох. Просто фанатизм какой-то. Прямо за пределми Хаскеля мир кончается и только на нем можно комбинаторы делать.
Дык кто спорит то? Хаскелл вообще в чистый Си преобразовать можно. Толку?
DC>>Я бы ещё понял если б ты вспомнил о Немерле с его макросами, но от додиеза выигрыш только в ФП будет.
VD>Я привел минимально достаточный пример. Вот, к примеру, тебе ссылка
где Elifant говорит о том, что он воспроизвел Parsec на Nemerle. Погляди на реализацию. Макросами там и не пахнет. Только функциональные комбинаторы которые могут быть реализованы и на Шарпе. Менее красиво, более громоздко, но могут.
И на С++ можно на функторах что-то залудить, вопрос в наличии развитого и удобного инструмента иначе, как ты сам любишь говорить, это закат солнца вручную.
ЗЫ Вообще не хочу холиваров Хаскелл vs С#, Хаскелл vs .Net и т.п. Просто на мой взгляд Хаскелл на данный момент наиболее мощный язык и если уж хотим максимальной декларативности и простого распараллеливания то лучше смотреть в эту сторону, но мнения своего никому не навязываю.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
T>>Значит, не масштабируется. Либо класс задач с такими свойствами (много независимых актёров с изменяемым независимо состоянием) очень узкий.
R>Я не думаю, что он особо узкий. Большинство серверного ПО можно побить на множество актёров, воспользовавшись преимуществом отдельных соединений или запросов. Моделирование различных систем, описываемых графами. Даже в толстых клиентах можно 10-20 независимых актёров/подсистем выделить. Масштабироваться это будет замечательно. Особо много и не надо, достаточно сотен.
Рекомендую попробовать. Практика рассеивает иллюзии, как ничто другое.
Выделенным я занимаюсь последний месяц, похожим я занимался последних два года.
Мой опыт говорит мне прямо противоположное твоим утверждениям.
R>В любом случае непонятно смешивание модели актёров и факта, что они имеют состояние и внутренне не распараллеливаются. Это 2 абсолютно независимых вещи — можно параллелить на уровне актёров (отвлечёмся пока от факта, сколько актёров мы можем выделить в системе — параллелить на таком уровне мы всё равно можем), можно параллелить на уровне отдельных функций (пользуясь преимуществом неизменяемых данных), можно применить сразу оба метода.
Я не смешиваю, я указываю.
Если актер занят обработкой одного запроса и сменой состояния на его основе, он не может обрабатывать другой.
Вместо одного бутылочного горлышка получается сотня или сколько там актеров в системе.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>Бред он, в прочем как всегда, излагает. Если попытаться выципить крупицы смысла из его рассуждений, то получится вот что. LINQ — это библиотека предназначенная для обработки последовательностей (ака списки). Библиотека эта инкапсулирует алгоритмы обработки списков. Эти алгоритмы могут быть уточнены функциями передающимися в качестве параметров.
VD>Исходя из этого просто не корректно обсуждать "почему LINQ не позволяет обрабатывать матрицы". А уж рассуждать о каких-то понижениях или повышения на 1, 2, 10 и т.п. Просто бессмысленно.
VD>Создай библиотеку инкапсулирующую алгоритмы обработки матриц и получишь то что воображении Дворкина называется "понижением на один", а у всех остальных называется банальной инкапсуляцией.
ты всего лишь споришь о словах...
Насколько я понял Павла, "понижением размерности на 2" он называл бы аналог SQL, который, например, мог бы работать с треугольными таблицами. Нафиг это надо -- спроси Павла.
VD>Вот ты явно пишешь на С++. Тебе знакомы Boost.Function, Boost: Function, Bind, Lambda?
Смотрел, но не использую. А как это связпно с темой?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, VladD2, Вы писали:
R>>Замечательно. А я не сталкиваюсь с особыми проблемами при работе в императивном стиле. И мне тоже С++ компилятор помогает тем, что ничем не мешает. VD>А как ты с ними столкнешся если ты даже стоя по колено в граблях думаешь, что так оно и должно быть и что с этим ничего не поделаешь.
Так может не надо искать проблемы-то? Если грабли не мешают, значит не мешают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, AndrewVK, Вы писали:
E>>Ну о чём у вас спор-то? Ты не веришь, что аппаратно адаптированный под узкий круг задач чип может быть радикально эффективнее компа общего назначения (например однокристаллки)? AVK>Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций.
Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
E>>Ну в сторону CUDA посмотри, например, или на синоптические чипы... AVK>Неистребима страсть местного народа поучать
Это было не поучение, а аргумент.
Обрати, кстати, внимание, что слой абстракций "куды" тоже довольно таки дырявый...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
Не уловил мысль
E>Обрати, кстати, внимание, что слой абстракций "куды" тоже довольно таки дырявый...
Следствие убогости куды и недостаточного развития инструментальных средств. Здесь главное понимать — это проблема, которую надо решать, а не оставлять все как есть, заставляя прикладников вникать в тонкости организации внутренних конвееров конкретной железки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Mr.Cat, Вы писали:
MC>Напомню, что все началось с того, как remark провел параллель между sql и функциональными языками.
Что значит параллель? Оригинальный SQL, без императивных расширений, это и есть функциональный язык.
MC> Я посчитал, что (т.к. sql довольно узкоспецтализированный dsl) он имеет в виду какое-либо из императивных расширений
При проведении параллелей с функциональными языками имел в виду императивные расширения? Ты его за кого принимаешь?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, mkizub, Вы писали:
M>И весь этот бардак решается простым способом — я добавляю в язык новые семантические понятия (вроде арифметики векторов). Если компилятор не понимает этих понятий — компилирует (например) в библиотечные вызовы. Если понимает — прямо компилирует в SIMD инструкции. Быстро, просто, и с гарантированным результатом.
Здравствуйте, Erop, Вы писали:
E>Насколько я понял Павла, "понижением размерности на 2" он называл бы аналог SQL, который, например, мог бы работать с треугольными таблицами.
С прямоугольными.
>Нафиг это надо -- спроси Павла.
Спроси лучше Синклера. Это ему понадобилось объяснение, что такое понижение на 2, ну вот я ему и соорудил пример. Мне он не нужен.
Здравствуйте, Sinclair, Вы писали:
PD>>Хм. Дело в том, что тут не всегда четыре сложения, идущие подряд, есть. Это лишь простейший случай. Их просто может и не быть явно. Чтобы они появились, надо код переписать, сделать так, чтобы они появились. S>Нет. S>Начнем сначала: ты привел пример кода, где сложения выполняются в цикле. S>Да, такой код компилятору трудно векторизовать, но всё еще возможно.
S>Вот если ты постараешься испортить этот код, затуманить задачу — например, вручную распараллелив цикл и навтыкав туда volatile — тут да, точно, "алгоритм придется несколько поменять".
Да нет, все проще. Например, суммирование двух матриц без всякого распараллеливания. Если идем по строке, то 4 числа лежат рядом, их можно взять за один присест из одной матрицы, из другой и векторизованно просуммировать. А если идем по столбцам ? Числа лежат черт те как, их надо в отдельную область памяти скопировать, чтобы потом _m128 загрузить. Не уверен, что компилятор это будет делать, равно как сомневаюсь в осмысленности этого.
S>Легче всего компилятору действовать тогда, когда он компилирует с языка, на котором твои действия записаны в максимально осмысленном виде. Вместо конкретного цикла, с конкретным битоперемешиванием мелконарезанных фрагментов, компилятор, к примеру, наблюдает операцию типа a = b + c, где все компоненты — это, скажем, вектора. Семантика операции + компилятору полностью известна, в том числе коммутативность, а также отсутствие побочных эффектов. Благодаря этому он волен сам выбирать, при помощи чего складывать компоненты, паралелить это или нет, и пользоваться ли MMX/SSE или штатным скалярным execution unit.
См. ответ mkizub. Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ? Не запишешь ведь "понизив на порядок" (в моем определении этого).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Да нет, все проще. Например, суммирование двух матриц без всякого распараллеливания. Если идем по строке, то 4 числа лежат рядом, их можно взять за один присест из одной матрицы, из другой и векторизованно просуммировать. А если идем по столбцам ? Числа лежат черт те как, их надо в отдельную область памяти скопировать, чтобы потом _m128 загрузить. Не уверен, что компилятор это будет делать, равно как сомневаюсь в осмысленности этого.
Еще раз поясняю: эти проблемы возникают только если "идти по столбцам". Не нужно этого делать: это мешает компилятору.
Если компилятор видит целиком выражение a*b+c*b, то он может применить злую магию и выбрать оптимальный набор операций. Включая транспонирование одной или нескольких матриц для того, чтобы обеспечить эффективность операций. Он может вообще сразу построить некоторые из промежуточных матриц в транспонированном виде.
PD>Со своей строны отмечу, что ты привел простой уж очень пример. Да, a=b+c очень уж понятно. А если надо, скажем, a[i] = a[i-1] + b[i]+c[i] ? Или по диагоналям сумму найти ?
А в этих случаях SIMD помогает? PD>Не запишешь ведь "понизив на порядок" (в моем определении этого).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Erop, Вы писали: AVK>>Верю. Я не верю в то, что это можно использовать без дополнительных промежуточных абстракций. E>Обычно он очень дырявый оказывается. Вообще всё так странно устроено, что для эффективной работы часто требуются дыры в слое абстракций. С и С++ скорее всего так популярны именно из-за дырявости своих обстракций. Свозь эти дыры всюду хорошо и близко доступна аппаратура.
На досуге поинтересуйся судьбой ключевого слова register в C++, который ты тут всуе поминаешь.
И попробуй проэкстраполировать эту судьбу на другие "дыры, сквозь которые видна аппаратура"
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Хреновый надо сказать пример, если ты про дотнетгные регекспы. Это как раз пример того, что никакая рантайм-кодогенерация не может заменить качество алгоритмов.
Не уверен. Я что-то при беглом просмотре не нашел бенчмарков, которые бы сравнивали плюсовые и дотнетные регекспы. VD>Помнится у нас подсветка синтаксиса асма дико тормозила как раз в следствии того, что использовались регекспы.
А заменили ее на что? Не на ручной лексер, случайно?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Спроси лучше Синклера. Это ему понадобилось объяснение, что такое понижение на 2, ну вот я ему и соорудил пример. Мне он не нужен.
Ну то есть был задан риторический вопрос относительно того, почему на SQL пишут мало "реальных программ", несмотря на его ориентированность на обработку данных.
На что ты дал ответ, построенный на некорректных предположениях о сути SQL.
Естественно, сам ответ тоже некорректен. Проблемы SQL совершенно точно не связаны с "недостаточным понижением размерности".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Тут у Хаскелла ИМХО более развитые средства для этого. Выразительная мощьс ©
