Здравствуйте, thesz, Вы писали:
T>1) Откуда ты знаешь, что понимают в MS?
Все разработчики ведут блоги, есть записи на channel 9 обсуждений различных вещей.
Кроме того MS на начальном этапе развития новых идей создает community и прислушивается к его мнению.
Так что совсем не сложно узнать что понимают в MS.
Здравствуйте, thesz, Вы писали:
T>Вот, смотри. Лисп стал функциональным в районе 1983 года. Только Common Lisp устаканил алгоритм упрощения (reduction), который имел хоть какой-то аналог в лямбда-исчислении.
И что? У лиспа пиписька длиннее стала?
T>Вопрос: какой порядок упрощения в функциональном подмножестве C#?
Встречный вопрос: что это меняет?
Хоть форум и называется философией, но абстрактно-теоретические рассуждения мало кому нужны.
Здравствуйте, gandjustas, Вы писали:
G>Не думаю что Axum поможет при ускорении расчетов.
То же предлагаешь обсудить свои ощущения?
G> Для числомолотилки доожен быть прямолинейный код, который исполняется на всех доступных ядрах одновременно.
Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, eao197, Вы писали:
E>Существует мнение, что с приходом массовых multicode машин под HPC будут попадать даже такие утилиты, как IrfanView и ACDSee. Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий.
Направление мысли правильное
E>В отличии от использования data-flow механизмов на агентах типа Axum-овских.
Вот вот.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, VoidEx, Вы писали:
VE>А где я требую отсутствие поддержки других стилей?
Ты? Без понятия. Но с предлагаемым подходом не только шарп не функциональный, но и F# с окамлом в ту же корзину, поскольку лямбду с побочными эффектами там, как два пальца об асфальт.
VE>Вот пока еррора нет, никакой функциональщины тоже нет.
Весьма спорно, но в контексте данного топика — непринципиально.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, thesz, Вы писали:
T>Я привожу сравнение с Эрлангом, где всего для параллельного программирования больше.
Всего это чего? Паттерн-матчинга? А чем он параллельному программиррованию помогает?
А Erlang умеет прозрачно задействовать все ядра процессора и при этом не терять производительность?
T>>>, из чего следует, что это PR AVK>>Из того что ты пытаешься следует? Отличная логика. И прекрасная демонстрация того, что это все таки вера. T>"Что это PR" следует из минимальности нововведений в Axum.
Теперь осталось доказать "минимальности нововведений в Axum".
Для начала можешь привести критерий минимальности, а потом список нововведений в Axum.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Не думаю что Axum поможет при ускорении расчетов. AVK>То же предлагаешь обсудить свои ощущения?
Тут видимо только этим и занимаются.
G>> Для числомолотилки доожен быть прямолинейный код, который исполняется на всех доступных ядрах одновременно.
AVK>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть.
Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Axum в этом не помощник, он как раз старается грузить минимум.
Здравствуйте, VoidEx, Вы писали:
VE>Здравствуйте, AndrewVK, Вы писали:
AVK>>Таким образом он не попадает под определение "исключительно функциональный". Я об этом с самого начала говорил. А по тому, что по ссылке — попадает. VE>
VE>functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data
VE>Не can avoid, а avoids.
И сколько таких языков?
Какие из них были\есть mainstream?
Здравствуйте, gandjustas, Вы писали:
G>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Суть, к сожалению, все таки несколько меняется, и проблемы при HPC и работе с IO все таки несколько разные, особенно в плане акцентов. К примеру, грануляризация для IO почти по барабану, а для HPC — ключевой момент.
G>Axum в этом не помощник, он как раз старается грузить минимум.
Думаю, ты ошибаешься все же.
... << RSDN@Home 1.2.0 alpha 4 rev. 1218 on Windows Vista 6.1.7100.0>>
Здравствуйте, gandjustas, Вы писали:
AVK>>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть. G>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
Мимо. Задача не в том, чтобы нагрузить все ресурсы, а в том, чтобы получить максимальный эффект от распараллеливания (в идеале -- линейную масштабируемость). И здесь высокоуровневые механизмы (те же самые агенты) могут позволить разработчику достичь этой цели с меньшими трудозатратами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>>Это очень узкий подход к проблеме. Нет, совершенно необязательно прямолинейный. С прямолинейным и сейчас проблем нет. Проблемы начинаются когда он не совсем прямолинейный, или, скажем, плохо гранулируется. Вот тогда и вылазят всякие фьючерсы, континуэйшены и прочая асинхронная нечисть. G>>Только суть от этого не меняется — надо нагрузить все ресурсы с миниммальным оверхедом.
E>Мимо. Задача не в том, чтобы нагрузить все ресурсы, а в том, чтобы получить максимальный эффект от распараллеливания (в идеале -- линейную масштабируемость). И здесь высокоуровневые механизмы (те же самые агенты) могут позволить разработчику достичь этой цели с меньшими трудозатратами.
Забыл добавить -- remark здесь несколько мегапостов написал на эту тему. Так что обращайстесь к первоисточнику
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
Система была реал-тайм?
Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
Здравствуйте, eao197, Вы писали:
E>>>Стоит сменить предметную область с fault-tolerant systems на high perfomance computing и окажется, что практически все эти достоинства, в лучшем случае, окажутся мертвым грузом.
G>>Преимущества Эрланга имеют большое значение в любых серверных приложениях с требованием 24х7, которые работают не в пакетных (как high-performance computing), а в интерактивных сценариях.
E>Даже в области серверных приложений с требованиями 24x7 подход Erlang-а далеко не единственный.
Единственных подходов вообще не бывает. Их всегда пруд пруди. Я тебе сейчас не о подходе говорю, а о тех преимуществах, которые есть не подход, а свойства, и которые ты попытался отмести предыдущим постом.
А если говорить о твоем подходе в SObjectizer — он хуже по всем пунктам. Почему — я показал.
G>>High-performance computing — это настолько узкая и малораспространенная область, что сменить что-либо на нее будет очень затруднительно. И она достаточно уныла, чтобы не возникало такого желания.
E>Существует мнение, что с приходом массовых multicode машин под HPC будут попадать даже такие утилиты, как IrfanView и ACDSee.
Мнение можно иметь любое. Оно отличается тем, что его принципиально нельзя ни доказать, ни опровергнуть. Особенно если "мнение" относится к жонглированию терминами.
E>Которые будут использовать 8-16 имеющихся в их распоряжении ядер даже для простейшей обработки 20-30 мегапиксельных фотографий. Какой толк от Erlang-а во внутренностях IrfanView (с горячей заменой кода, немутабельных данных, сопоставлении с образцом и принципом let it fail) я не представляю. В отличии от использования data-flow механизмов на агентах типа Axum-овских.
Ты мало слишком писал на Эрланге, чтобы представлять себе этот толк. Никаких проблем выразить простейшие параллельные задачи, которыми и являются числодробилки, в модели Эрланга нет. Модель Эрланга может быть перенесена в любой язык. В том числе и в С++.
Здравствуйте, gandjustas, Вы писали:
G>>>>"Декларативность" как свойство сама по себе не есть преимущество. Преимущество проявляется в контексте задачи. Тем более что самый обычный фьючерс дают ту же самую декларативность, с той разницей, что она более гранулярна, и содержит гораздо меньше магии. И это есть хорошо.
AVK>>>Но при этом ты доказываешь, что твои фокусы с файберами, которые магия куда как более хардкорная, это тоже хорошо
G>>Секунду. Все что я доказываю, это что синхронная запись лучше асинхронной. И все. G>Как в анекдоте: G>-синхронная запись лучше, чем асинхронная G>-чем лучше? G>-чем асинхронная!
Весьма глупый комментарий. Я это показал достаточно развернуто (рядом), с примерами кода, для тех, кто умеет читать, что написано. Умеешь — прочтешь.
G>>Данная "декларативность" его имхо затрудняет. G>Данная декларативность не влияет на наблюдаемое поведение.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
V>Система была реал-тайм?
soft-realtime.
V>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Gaperton, Вы писали:
G>>А вот мой подход на файберах в том же С++, который я реализовал лет 6 назад для CQG, позволяет обрабатывать тысячи нитей без каких-либо проблем синхронизации,
V>Система была реал-тайм? V>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев.
А вообще, нет проблем сделать и планировщик с жестким рилтаймом. Алгоритмы гибридных планировщиков, обеспечивающих хард рилтайм описывались еще в книге по оперсистемам Цикридзиса-Бернстайна. Другое дело, что в случае файберов жесткие гарантии обеспечить тяжело — не охота их насильственно прерывать. Хотя — и это можно.
Здравствуйте, Gaperton, Вы писали:
V>>Мне вот не удавалось заставить нормально работать "обобщенный планировщик" в асинхронной среде, явная диспетчеризация и на примитивах синхронизации экономит, и эффективнее в разы. Да, расплачиваемся автоматной моделью, но в том же .Net выручает yield как раз для таких случаев. G>У меня получилось. Мой планироващик отрабатывает за O(1), независимо от количества задач. Так же, как планировщик в современной венде или Linux.
Планировщик в современном Линуксе срабатывает за O(log N) времени — это даёт приятные фичи типа точного accounting'а и на практике работает как O(1), так как процессов не бывает особо много.
