Здравствуйте, PhantomIvan, Вы писали:
E>>MPI и OpenMP.
PI>ага, спасибо, упоминание о первом сегодня (в неожиданном месте) видел PI>я так понимаю, это стандарт, не зависящий от языка, не так ли?
Да. И маппинг MPI есть, если не ошибаюсь, на C/C++, Java и Fortran.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
постпенно проясняется ситуация, спасибо
VD>1. Для распараллеливания вычислений современными средствами (то есть потоками ОС) необходимо прикладывать много усилий.
в каком смысле много?
VD>2. Явное разделение задач на подзадачи и организация фрэймворков позволяющих бесшовно связывать эти параллельные задачи.
и такой вопрос, нельзя ли фреймворк (библиотеку) построить, которая позволяла бы быстро переключаться между 2 моделями (на псевдопараллелизме/потоках/участниках кластера)?
Здравствуйте, PhantomIvan, Вы писали:
PI>и такой вопрос, нельзя ли фреймворк (библиотеку) построить, которая позволяла бы быстро переключаться между 2 моделями (на псевдопараллелизме/потоках/участниках кластера)?
Это можно сделать даже на C++
Только вот когда говорят о параллелизме, нужно уточнять, о чем именно идет речь. Числодробилки и матричные операции -- это одно, параллельная обработка HTTP-запросов -- совсем другое.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>>>MPI и OpenMP.
PI>>ага, спасибо, упоминание о первом сегодня (в неожиданном месте) видел PI>>я так понимаю, это стандарт, не зависящий от языка, не так ли?
E>Да. И маппинг MPI есть, если не ошибаюсь, на C/C++, Java и Fortran.
PI>>и такой вопрос, нельзя ли фреймворк (библиотеку) построить, которая позволяла бы быстро переключаться между 2 моделями (на псевдопараллелизме/потоках/участниках кластера)?
E>Это можно сделать даже на C++
а примеры есть? если те, что ты приводил уже, то что они позволяют в этом плане?
сколько усилий потребуется, чтоб уже написанную программу, работающую на потоках, разнести на кластер
E>Только вот когда говорят о параллелизме, нужно уточнять, о чем именно идет речь. Числодробилки и матричные операции -- это одно, параллельная обработка HTTP-запросов -- совсем другое.
это что за зверь такой? распределение нагрузки на разные серверы?
я подразумевал общее решение, но можно ограничиться чисто вычислительными задачами
как областью, требующей, просто взывающей к созданию такого рода инструментов
VD>То что смысл изменился почти на 100%.
PI>>несвязный проект — это не проект, а набор разнородных проектов
VD>Нет. Хто все же один проект. По крайней мере он так понимается разработчиком.
колбаса она и в Африке колбаса...
если у кого-то конвейер подобных проектов, нужно пробовать обобщать...
а несвязный проект нужно называть солюшн по крайней мере, правильный термин для разработчика...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Синтаксически, это, конечно, не "классический list comprehension", но семантически — вполне себе.
VD>Не, это ты продемонстриовал набор функций аля ЛИНКС. В коментариях у тебя вообще был почти сиквел-запрос.
Это я продемонстрировал таки ж набор функций Руби. Потому что Линкс таки выглядит как "почти сиквел-запрос":
where (prefix != "")
take(10,
for (var w <- wordlist)
where (w.word ~ /{prefix}.*/)
orderby (w.word)
[w]
)
VD>А лист-компрехеншон это фича из Хасклея которую реализовали в некоторых языках (в том числе на макросах в Немерле).
Ну, моя логика такова. Абстрактный "list comprehension" (хммм.... "охват списка"?) — суть способ задать список путем указания, каким условиям должны соответствовать значения списка:
Частный случай (когда значения выбираются из конечного диапазона), реализованный на Питоне (скрадено там же):
L = range(100) # lists in Python must be finite , this is from 0 to 99
S = [x for x in L if x**2 > 3]
Тот же код, реализованный на Руби (специального синтаксиса, маскирующегося "под Хаскель", нет):
L = (0..100)
S = L.select{|x| x**2 > 3}
#или так:
S = (0..100).select{|x| x**2 > 3}
Код достаточно близок ко второму варианту на Хаскеле.
ы?
Ну, понятно, что sort, это, конечно, не вполне уже list comprehension — но в парадигме остаемся той же. Может быть, корректнее обозвать этот вариант "использование генераторов", а не "использование компрехенсионов".
Впрочем, если у Фила Вадлера хватает наглости называть свою версию на Links "list comprehension" (Фил Вадлер — таки ж один из создателей Хаскеля), то почему мне нельзя?
ЗЫ: хотя, понятное дело, спор о терминологии — самый идиотский и безнадежный вид дискуссии
E>Sun в свое время очень нехило поспособствовало тому, что ты называешь прогрессом. Даже еще до изобретения Java, просто начав выпуск своего Unix-а и разработав NFS. MS так же двигает прогресс, выпуская .NET и C#. Причем они не останавливаются. И тут на их фоне появляется что-то интересное, но нераскрученное и не поддерженное серьезными игроками. Ты решил рискнуть и поставить на эту темную лошадку.
я думаю, тут лучше прыгунов в высоту представлять...
тренируются, соревнуются...
бежит такой прыгун "джава", прыг — 1.75
бежит прыгун "дотнет", прыг — 2.10
...и тут такой красавец... с шестом...
Здравствуйте, eao197, Вы писали:
IT>>Скалу не видел, но из твоих слов могу предположить, что между ней и джавой гораздо больше внешних различий чем между N и C#. К тому же в C# есть такие вещи как делегаты, в том числе анонимные, понимание которых и умение работать с ними делают вхождение в FP более гладким.
E>Гладким, но не достаточно глубоким. Вопросы хвостовой рекурсии, паттерн-матчинга (и способов избежания спаггети кода в случае паттерн-матчинга), различных fold-ов и map-ов -- все это требует серьезного изучения.
Глубокость не берётся наскоком, она приходит с практикой. Или ты хочешь сказать, что ты не берёшься писать ни одной строчки до тех пор, пока детально не изучишь все нюансы языка?
E>>>Это и все? Единственный аргумент к руководству?
IT>>К какому руководству?
E>Хороший вопрос. У тебя, как я понял, руководства нет. Зато есть у других, в том числе и у меня.
У меня руководство есть, причём очень вменяемое руководство. И лёгкость вхождения в N воспринимается им очень положительно.
E>>>Я так и не понял зачем кто-то будет менять C# на Nemerle сейчас.
IT>>Если ты не понимаешь в свои годы, что означает слово прогресс, то мне сложно будет тебе это объяснить.
E>Извини, это демагогия с помощью общих слов.
Не извиню. Какой вопрос — такой ответ. Впрочем, тебя же ведь ответ в принципе не интересует, не так ли?
E>А как ту думаешь, сколько предпочтут очередного шага в стророну прогресса от более солидных игроков?
Многие.
E>И, зная, что эти игроки не замедлят себя ждать, какой смысл сейчас рисковать?
А вот это мы посмотрим. Более того, надеемся, что это будет так.
IT>>Очевидно, чтобы быстрее, дешевле, качетсвеннее, удобнее. Вот и Nemerle позволяет писать софт быстрее, дешевле, качественнее и удобнее.
E>Я думаю, это в твоих частных условиях так.
Я думаю, что так не только в моих.
E>>>Не всем же нужна compile-time генерация в собственном фреймворке. IT>>Ты не говори за всех. Ты лучше для себя определись, тебе лично нужна compile-time генерация? E>Мне нет.
Наконец-то мы научились говорить только за себя.
ЗЫ. Впредь, не стоит так настойчиво отождествлять себя с НАРОДОМ. Это очень дешовый приём и он не делает тебе чести. Договорились? Ну вот и славненько
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, PhantomIvan, Вы писали:
E>>Только вот когда говорят о параллелизме, нужно уточнять, о чем именно идет речь. Числодробилки и матричные операции -- это одно, параллельная обработка HTTP-запросов -- совсем другое.
PI>это что за зверь такой? распределение нагрузки на разные серверы?
Имеется ввиду следующее. Для числодробилок нужно максимально эффективно задействовать все имеющиеся ресурсы. Т.е. если процессоров больше одного, то ни один из них не должен простаивать. Обслуживание запросов от нескольких клиентов даже на одном процессоре подразумевает, что быстрый запрос, не требующий много ресурсов должен проходить быстро, а долгий может и подождать.
И в том и в другом случае речь идёт о паралельности, но цели и способы реализации у неё разные.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
VladD2 wrote: > R>Вполне имеет. Shell-скрипты пишут для исполнения на unix-подобных > R>системах, которые должны примерно быть похожими хоть на какой-то > R>стандарт: POSIX, SUS, SysV. И в любом случае grep должен быть. Так что в > R>shell-скриптах наличие grep считается гарантированным. > > Ну, а что будешь делать если грепа не хватит? Ну, нужна тебе другая > функциональность?
Запускать sed.
У shell имеется относительно ограниченная область применимости — с этим
никто не спорит. Однако она не так мала, как кажется, и в ней shell
банально удобен... Многие действия по обработке текста и общению с
системой на нём в три раза короче при той же читаемости. Да, две строчки
вместо семи более коротких, но писать обвязки больше, чем кода, всё
равно не хочется. Да и сделаны "библиотеки" под конкретную задачу, из-за
чего повышается уровень.
И трудно предположить, что писать даже экран кода в REPL, имея
completion, хуже, чем в компилируемом языке.
Здравствуйте, IT, Вы писали:
E>>Гладким, но не достаточно глубоким. Вопросы хвостовой рекурсии, паттерн-матчинга (и способов избежания спаггети кода в случае паттерн-матчинга), различных fold-ов и map-ов -- все это требует серьезного изучения.
IT>Глубокость не берётся наскоком, она приходит с практикой. Или ты хочешь сказать, что ты не берёшься писать ни одной строчки до тех пор, пока детально не изучишь все нюансы языка?
Ответственного софта (т.е. того, за который платит заказчик и за который мне отвечать) ни строчки.
E>>А как ту думаешь, сколько предпочтут очередного шага в стророну прогресса от более солидных игроков?
IT>Многие.
Ну вот, сообственно об этом и речь.
IT>>>Очевидно, чтобы быстрее, дешевле, качетсвеннее, удобнее. Вот и Nemerle позволяет писать софт быстрее, дешевле, качественнее и удобнее.
E>>Я думаю, это в твоих частных условиях так.
IT>Я думаю, что так не только в моих.
Ну тогда к тебе можно применить твои же слова:
Наконец-то мы научились говорить только за себя.
ЗЫ. Впредь, не стоит так настойчиво отождествлять себя с НАРОДОМ. Это очень дешовый приём и он не делает тебе чести. Договорились? Ну вот и славненько
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, PhantomIvan, Вы писали:
PI>>>и такой вопрос, нельзя ли фреймворк (библиотеку) построить, которая позволяла бы быстро переключаться между 2 моделями (на псевдопараллелизме/потоках/участниках кластера)?
E>>Это можно сделать даже на C++
PI>а примеры есть? если те, что ты приводил уже, то что они позволяют в этом плане? PI>сколько усилий потребуется, чтоб уже написанную программу, работающую на потоках, разнести на кластер
Если она написана на агентах с соответствующими способами коммуникции, то не много.
E>>Только вот когда говорят о параллелизме, нужно уточнять, о чем именно идет речь. Числодробилки и матричные операции -- это одно, параллельная обработка HTTP-запросов -- совсем другое.
PI>это что за зверь такой? распределение нагрузки на разные серверы?
PI>я подразумевал общее решение, но можно ограничиться чисто вычислительными задачами PI>как областью, требующей, просто взывающей к созданию такого рода инструментов
Это разные задачи -- параллельная обработка чего-нибудь и параллельные вычисления.
Вот смотри, возмем обсуждавшися здесь пример с grep-ом.
Пусть у на есть конвейер:
Т.е. во множестве *.log-файлов ищутся строки с pattern-1, все найденные строки сохраняются в файле found.txt и, кроме того, передаются дальше по конвейеру, из них выбираются все строки, в которых нет pattern-2, и количество таких строк подсчитывается. Каждая часть конвейера -- это отдельный процесс, который может работать на своем процессоре. При этом не трудно заметить, что работа может вестись ими параллельно:
wc | ---->---->---->---->---->---->
grep2| ---->---->---->---->---->---->
tee | ---->---->---->---->---->---->
grep1|--->---->---->---->---->---->
===================================================>
(кстати, пускай приверженцы скриптования на высокоуровневых языках попробуют повторить этот конвейер с равной степерью параллелизации )
Паралльная обработка характеризуется тем, что разные стадии обработки чаще всего выполняются строго последовательно. И передача информации от одной стадии к другой может выполняться как отсылка сообщения или запись порции данных в какой-то канал ввода/вывода.
Если вернуться к параллельной обработке HTTP-запросов, то здесь можно выделить ряд последовательных задач: обнаружение подключения нового клиента к серверному порту, обнаружение и вычитывания из соединения HTTP-запроса, парсинг запроса, аутентификация клиента, выполнение самого запроса, рендеринг результирующей страницы, запись результата рендеринга в канал как HTTP-ответ. Каждую из этих задач можно представить отдельным потоком, а их взаимодействие -- через очереди сообщений или каналы ввода/вывода.
Причем, как не трудно заметить, подобная параллелизация отражается явным образом на архитектуре ПО. И здесь вряд ли вообще возможно сделать какой-то автоматический думатель, который за разработчика разобъет задачу на параллельно работающие компоненты.
По моему мнению, сложность создания подобных программ сильно преувеличивается. Имхо, здесь все упирается в уровень используемых примитивов. Если разработчик опускается на уровень ручного создания потоков, ручного использования семафоров/мутексов и условных переменых, то тогда при росте количества нитей он отгребает все приключения с deadlock-ами и race condition-ами по полной программе. Однако, если использовать инструмент, который предоставляет готовые механизмы активизации отдельных сущностей и готовые каналы обмена сообщениями или механизмы проведения рандеву, то сложностей не так уж и много.
А вот дальше я начинаю говорить о том, с чем по работе не сталкивался. Так что могу и соврать чего-нибудь, звиняй, ежели чего.
В вычислительных же задачах параллелить требуется мелкие фрагменты отдельных последовательных алгоритмов. Например, умножение всех элементов вектора на какой-то скаляр. В каком-то алгоритме это может быть всего-лишь маленький шажок: B = Ax. Зато, если разбить Ax на N процессоров (каждый из которых будет выполнять перемножение всего лишь (A.size/N) элементов), то скорость выполнения операции Ax возрастет, образно говоря, в N раз (хотя здесь будут вмешиваться архитектура вычислительной системы и накладные расходы по синхронизации разделяемой памяти). И весь фокус состоит в том, чтобы имея линейную запись какого-нибудь вычислительного алгоритма, как можно лучше выявить те места, которые поддаются распараллеливанию. Как раз здесь участие программиста желательно свести к минимуму. Хотя бы из-за того, что мы люди и из-за недостатка опыта или элементарной забывчивости можем забыть что-нибудь распараллелить (или напротив, попробовать распараллелить то, что не следует). Т.е. переложить задачу распараллеливания вычислений на умный компилятор, который будет выявлять знакомые ему паттерны (например, умножение вектора на скаляр, сортировки строк матриц, сложение матриц/векторов и пр.) и эффективно параллелить соответствующие операции.
Вот как-то так. Что знал, рассказал
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
IT>>Глубокость не берётся наскоком, она приходит с практикой. Или ты хочешь сказать, что ты не берёшься писать ни одной строчки до тех пор, пока детально не изучишь все нюансы языка?
E>Ответственного софта (т.е. того, за который платит заказчик и за который мне отвечать) ни строчки.
Глупости. Тогда тебе для перехода на новый язык/технологию понадобилось бы по нескольку лет. А у студентов вообще никогда бы не было шанса получить работу. Впрочем, теперь понятно почему ты до сих пор не можешь соскочить с C++.
E>>>А как ту думаешь, сколько предпочтут очередного шага в стророну прогресса от более солидных игроков? IT>>Многие. E>Ну вот, сообственно об этом и речь.
Так я тебе это уже десятый раз толкую. И не только я.
IT>>>>Очевидно, чтобы быстрее, дешевле, качетсвеннее, удобнее. Вот и Nemerle позволяет писать софт быстрее, дешевле, качественнее и удобнее. E>>>Я думаю, это в твоих частных условиях так. IT>>Я думаю, что так не только в моих. E>Ну тогда к тебе можно применить твои же слова:
Мда. По-моему, ты не только не улавливаешь значения слова прогресс, но и не чувствуешь разницы между "всем" и "не только в моих" Бред какой-то
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
спасибо, было интересно
E>(кстати, пускай приверженцы скриптования на высокоуровневых языках попробуют повторить этот конвейер с равной степерью параллелизации )
это довольно просто повторитьна yield-ах
E> переложить задачу распараллеливания вычислений на умный компилятор, который будет выявлять знакомые ему паттерны (например, умножение вектора на скаляр, сортировки строк матриц, сложение матриц/векторов и пр.) и эффективно параллелить соответствующие операции.
боюсь, это практически нереально
да, как правило операции ведутся с матрицами и векторами, но автоматическое распараллеливание... умный компилятор... выглядит как утопия (по крайней мере на ближайшие годы)
E>Вот как-то так. Что знал, рассказал
ага, буду более подробно изучать, когда до реально-параллельных задач дойду
Здравствуйте, PhantomIvan, Вы писали:
E>> переложить задачу распараллеливания вычислений на умный компилятор, который будет выявлять знакомые ему паттерны (например, умножение вектора на скаляр, сортировки строк матриц, сложение матриц/векторов и пр.) и эффективно параллелить соответствующие операции.
PI>боюсь, это практически нереально PI>да, как правило операции ведутся с матрицами и векторами, но автоматическое распараллеливание... умный компилятор... выглядит как утопия (по крайней мере на ближайшие годы)
Лет пятнадцать-тринадцать назад видел на кафедре в унивеститете какую-то книгу, посвященную реализации распараллеливания матричных операций на суперскалярных процессорах. Издания где-то 80-х годов. Вроде как там приводились какие-то примеры специализированных языков для суперкомпьютеров (типа Cray), которые умели это делать.
PI>когда ждать SObjectizer на Немерле?
Нет уж, пока C++. Потом, если все будет хорошо, попробуем Scala Кросс-платформенность, панимаш, это такая важная штука...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
PI>>когда ждать SObjectizer на Немерле?
E> E>Нет уж, пока C++. Потом, если все будет хорошо, попробуем Scala Кросс-платформенность, панимаш, это такая важная штука...
а actors там, это не в ту же степь?
думаешь, макросы тебе не понадобятся?
колбаса она и в Африке колбаса...
по крайней мере, правильный термин для разработчика...
Если нам не помогут, то мы тоже никого не пощадим.
