Здравствуйте, AndrewVK, Вы писали:

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

Ох, больная это тема. Я тут голосование устроил

http://rsdn.ru/poll/2205.aspx

Автор: Pavel Dvorkin
Дата: 10.10.08
Вопрос: Какие критерии, на Ваш взгляд, наиболее важны для ПО ? Я намеренно ограничиваю выбор двумя пунктами — выберите наиболее важное

и результаты его меня просто пугают. Но не хочу сейчас флейм на эту тему устраивать.

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

А где там запутанность ? Нормальный код, как все на Win32 пишут.


AVK>Вот, кстати, характерная твоя ошибка — говорим о дизайне кода, а ты даже не в состоянии привести пример без использования специфики Win32.

Опять ? Я же привел тебе описание задачи! Ну не могу же я его привести, не упоминая окна и пикселей, если задача именно с окном и именно с пикселями.

>Все я прекрасно понимаю, но разбираться в этом принципиально не хочу, потому что к обсуждаемому вопросу это отношения не имеет.

Да никто и не заставляет. Ну не нравится тебе мое описание — сказал, я согласился, дал другое. Оно не нравится — скажи, уточню еще раз. Чего тему-то мусолить ?

AVK>Ты вообще понимаешь разницу между конструкциями языка и API операционной системы?



>Мы здесь, еще раз напоминаю, обсуждаем именно конструкции языка, и ничто иное. Обойтись без LINQ для демонстрации возможностей ФП на шарпе нельзя в принципе, обойтись без Win32 для демонстрации того, что LINQ ничего не дает можно, и даже нужно.

Согласен. Я вполне могу убрать оттуда и окно, и GetPixel, а просто предложить просуммировать столбцы некоего двумерного массива, каким-то образом заданного. Правда, чтобы время померить, придется либо в цикл это вставить, либо уж очень большой массив использовать. Впрочем, чтобы IT-ские проценты сравнить в AsParallel и без, то же придется сделать. Но все же никак не пойму — чего ты к пустякам придираешься ? Ну какое отношение к распараллеливанию имеет вопрос откуда и как брать эту матрицу ?


AVK>Конечно, в том и суть, что ты, ничего не зная ни про ФП, ни про LINQ, тем не менее понимаешь код, который IT привел.



Вообще-то нет. Про ФП я могу не знать, про LinQ тоже, а вот SQL знать надо, иначе я его этот SELECT и GROUP в нем не пойму.

AVK>>>А теперь сравни со своей простыней. Что там у нас осталось? Параллелить вкривь и вкось различными способами?

PD>>Если не сложно, объясни , почему вкривь и вкось, это раз

AVK>Не знаю, тебе захотелось по диагонали или еще как то там пиксели обсчитывать.

Андрей, это уж никуда не годится. Я привел этот пример именно, чтобы показать, что когда мне надо не в "горизонтально-вертикальном", а в произвольном направлении ходить, ваш подход ИМХО пробуксовывает. ИМХО, заметь — я же вопрос задал, а не утверждал, что нельзя. Если докажешь, что можно и логично при этом получится — признаю, конечно. Ну а насчет того, что , мол, вкривь и вкось — не будешь же ты утверждать всерьез, что матрицы только по строкам или по столбцам проходят

Я вот одно понять не могу. Ну что стоит признать, что для определенной ситуации этот подход не очень хорош ? Вот был бы я на вашем месте, ответил бы так — "да, для такого рода действий этот подход не годится или не очень эффективен (или еще что-то). Зато он очень хорош, для задач типа той, о которйк я написал". И все, вопрос исчерпан, и я тут же соглашусь — для заточки карандашей не годится топор, а дерево рубить не надо столовым ножиком. И обсуждать больше нечего, разве что детали и эффективность того или иного решения.

AVK>Понимаю. И что? Я тебе в который раз напоминаю — речь не о библиотеках и их возможностях, речь о языке программирования. AsParallel просто демонстрирует эти возможности, не более того.

Понимаешь, для меня большой разницы между языком и библиотекой нет. Реально для меня это два взаимосвязанных инструмента, и без одного из них, любого, я не обойдусь. Теоретически обойдусь, пока просто так думаю, а как сяду за компьютер — нет. Как ни страшно это для тебя звучит, но это так. Ну хорошо, давай оставим только язык. Linq твой останется, допустим, но ведь всех библиотек .NET FW я тебя лишу, если ты хочешь меня лишить Win32. И что ты сможешь сделать ? Или ты заявишь, что .Net FW — это часть языка, а Win32 — нет ? Массивы в C# — это часть языка или нет ? Безусловно да, входят в спецификацию. Но ведь без реализации класса Array в .Net FW не будет у тебя массивов!

PD>> Не обязательно так, конечно, скорее там пул потоков, посмотрю как-нибудь. Ну нет в Win32 иного способа параллелить и нет в Windows ничего, что не проходио бы через Win32 (про OS/2 и POSIX умолчим).

AVK>Оторвись от замочной скважины и открой наконец дверь.

Да пойми ты наконец, что все проходит через эту замочную скажину, если уж тебе такое сравнение нужно. Я абсолютно ниченго не знаю, скажем, про реализации ЛИСПА, да и сам ЛИСП не знаю, но если мне кто-то скажет, что в ЛИСПЕ можно записать файл, минуя в конечном счете WriteFile — это даже не смешно.

PD>>Итераторы в С++ существуют, а вообще это понятие языково-независимо.

AVK>Под итераторами в C# здесь подразумеваются специальные возможности языка. Это частный случай продолжений (continuations), предназначенный для легкого и удобного создания сложных итераторов. В С++ такое эмулируют при помощи макросов, но качество решения получается при этом ниже плинтуса.

Ну это обсуждать не будем, предлагаю так, а то мы еще один флейм устроим.

PD>> Вот ответь прямо — да или нет ?

AVK>Отвечаю прямо — неважно.

Не ответил

>Не уводи от темы. Распараллеливание здесь в качестве примера, а не самоцель.

А вот в этом не уверен. IT именно это и заявил — могу , мол, легко распараллелить.

>Если не можешь съехать с Win32, я могу в примере заменить распараллеливание на, скажем, кеширование.

Ты хочешь, чтобы мы еще флейм на тему кеширования завели ? Не надо

PD>>Честно говоря, не слишком понял — что ты суммируешь и куда. Если это реализация моей задачи

AVK>Она.

PD>> — где массив сумм по столбцам ?

AVK>Вот тебе с массивом, это еще проще:
AVK>

AVK>return
AVK>    (
AVK>        from x in Enumerable.Range(0, Width)
AVK>        select Enumerable.Range(0, Height).Sum(y => pixels[x, y])
AVK>    )
AVK>    .AsParallel()
AVK>    .ToArray();
AVK>

AVK>Обрати внимание, насколько просто оказывается поменять код.

Да просто, кто спорит. Я еще раз говорю — я совсем не противник этого. Я не согласен, когда это за панацею выдается.

А все же, как с диагоналями ? . Мне-то несложно.
PD>>Ты все же попробуй те 5 вопросов осилить.

AVK>Смысл? Игрища с приоритетами потоков в контексте вопроса малоинтересны и непринципиальны (ну будет там какой нибудь доп.параметр у AsParallel()).

Вот то-то и оно. IT уверен — напишу AsParallel и все, остается только сливки снимать. Ты уже засомневался, и это верно, хочешь какой-то параметр (в скобках — или метод, или аттрибут или еще что-то). Дело в том, что поручив все это системе(библиотеке, FW) и надеясь, что она сделает все наилучшим образом, ты очень скоро поймешь, что иногда да, это совсем неплохо, а иногда — ни в какие ворота. И тогда тебе придется изучать всю эту кухню (не обязательно на Win32, реализация Thread в С# в общем, повторяет Win32) и требовать, чтобы у AsParralel были какие-то возможности управления.

Хотя теоретически да, можно представить себе систему, которая сама примет решение о том, как и когда распараллеливать алгоритм. Но эта задача эквивалентна задаче автоматического распараллеливания произвольного алгоритма, а ее, насколько я понимаю, еще никто не решил. Впрочем, почитай здесь же в форуме, ИМХО с год назад тут большая дискуссия была о параллелизме.



PD>> А это суммирование, конечно, распараллелить можно, задачка-то пустяковая.

AVK>Только даже на такой пустяковой задачке прекрасно видно, насколько твой императивнй код запутаннее.

Андрей, не надо. Код как код, делает то, что ему положено, и запутанного там ничего нет. Ты просто мой код еще не знаешь — если уж я впрямь начну запутанный код писать, его никто, кроме меня, не распутает (Ох, какой козырь я тебе дал — но будь джентльменом, не воспользуйся им, прошу

PD>>Вообще-то я не очень понимаю — в чем разница. Он какие-то проценты считает на баз неких коллекций, а я суммы считаю на базе тоже, если хочешь, "коллекций — столбцов пикселей.

AVK>У него алгоритм намного сложнее, а, главное, там уровень косвенности выше.

У него в реальных его задачах — не сомневаюсь. И никаких сомнений в его качествах как специалиста я не высказывал, это ему очень хочется доказать, что я проценты считать не умею. Алгоритм вычисления процентов — мб и сложнее, чем вычисления сумм, но, по правде сказать, обоим (как алгоритмам) место в средней школе во втором-третьем месяце изучения программирования.

PD>> Делить я не делю и не суммирую, верно, но так ли это важно ? Есть распараллеливание алгоритма, что тут особого-то.

AVK>Ты сделай сперва без распараллеливания, и мы обсудим результат.

Ну опять