Здравствуйте, AndrewVK, Вы писали:
AVK>Смешно. Потрясающий ты человек, Павел Дворкин.
Ну и смейся на здоровье. Я , собственно говоря, во всех этих дискуссиях порой с одной целью участвую — посмеяться над фанатиками чего бы то ни было
AVK>Да я и не требую.
Ты — нет, верно, сорри. Это IT вообразил, что он командовать может. Я как-то вас обоих перестал разделять, а напрасно. Учту
>Только выглядят после этого твои слова, как бы это помягче, неубедительно.
Да бога ради. Для тебя одно неубедительно, для меня другое, а третьи лица пусть сравнивают и убеждаются.
PD>>Ну насчет каши — не нравится язык — дело твое. Я другой язык использовать не буду.
AVK>Кто бы сомневался.
А зря, между прочим. Не буду — означало для данной задачи. А в остальном я вполне свободен в выборе. Надо будет — буду писать на C# (писал уже, хоть и совсем немного), надо будет — и на VBA напишу (тоже чуть-чуть приходилось), более того — если окажется, что в данном случае лучше всего GW-Basic
— напишу на нем, хоть и чертыхнусь в душе.
А вот тебя заставить писать на C/C++ и Win32, похоже, можно только под дулом пистолета
Еще раз, Андрей, пойми наконец. Я вовсе не противник шарпа, LINQ или ФП. Там где они уместны — да бога ради. Я вовсе не предлагаю на ассемблере доступ к таблице БД писать. Не надо мне приписывать того, что я не говорил. Но когда мне начинают заявлять, что некие высокоуровненые средства ну никак нельзя реализовать на уровне ниже — я просто не знаю, смеяться или плакать. Потому что кто-то же их реализовал, ибо процессор не умеет ни LISP, ни LinQ обрабатывать. Вот и все.
PD>> А описание — мне казалось , что я его дал.
AVK>Вот именно что казалось.
Ну каждый дает описание исходя из своего понимания того, как это дают. Если бы я это в форуме по Win32 написал — уверен, меня бы с полуслова поняли бы.
>>>поэтому я просто распараллелил вычисление сумм красных компонент по столбцам окна.
AVK>Компонент чего, rакого окна?
Компонент пикселей окна, красных. Окна любого, Windows.
>О чем вообще речь? Сравни свое "описание" с описанием IT. Ну хотя бы по объему. А с таким описанием я тебе могу дать точно такой же ответ:
AVK>AVK>return things.AsParallel().Select(thing => thing.RedComponent).Sum();
AVK>
Нет, не пойдет этот аргумент. Пусть даже ты прав, и можно было уточнить. Но текст программы приведен, и в нем (по крайней мере в непаралельной части) разберется любой мой студент за 1 минуту, даже если я вообще никакого описания не дам. несерьезно это. Ну а потом — я же дал тебе после этого более развернутое описание задачи, зачем опять муссировать это ?
AVK>Из комментариев еще можно понять, что у тебя там вроде бы есть еще и непараллельный алгоритм, но AsParallel реально параллелит только если есть несколько ядер. Впрочем, явно указать тоже не проблема:
Если ты не очень понимаешь Win32, это еще не причина, чтобы жаловаться. Я не лучше тебя знаю LinQ, но я не заявлял, что не пойму этот SELECT, что IT привел. Если не понимаю — мои проблемы.
AVK>А теперь сравни со своей простыней. Что там у нас осталось? Параллелить вкривь и вкось различными способами?
Если не сложно, объясни , почему вкривь и вкось, это раз, и откуда там различные способы, если там всего один. А второй вопрос — ты хоть понимаешь, что внутри твоего AsParallel зашита работа с потоками примерно так, как я и сделал. Не обязательно так, конечно, скорее там пул потоков, посмотрю как-нибудь. Ну нет в Win32 иного способа параллелить и нет в Windows ничего, что не проходио бы через Win32 (про OS/2 и POSIX умолчим).
>Все это задается начальными итераторами, теми, которые на вход AsParallel поступают. И тут тоже у шарпа с его итераторами возможностей по понятной и эффективной реализации всяких причудей будет больше, чем ты сможешь на С++ изобразить.
Итераторы в С++ существуют, а вообще это понятие языково-независимо. Распараллеливание тоже (не в С++, а в Win32).
И никак нельзя распараллелить иначе, чем Win32 (или на худой конец native API) позволит. С этим-то хоть ты согласен ? Вот ответь прямо — да или нет ?
PD>>Дано окно Windows с неким рисунком в нем. Пройти по всем пиксельным столбцам клиентской области этого окна и найти для каждого столбца сумму R (красных) компонент пикселей , записать результаты в массив columnSum. Две реализации — в лоб без распараллеливания, и с распараллеливанием
PD>>Реализация с распараллеливанием — создаются N потоков, где N — число процессоров (возвращает GetSystemInfo). Если процессоров 2, то один поток займется левой половиной окна, а другой правой. Если 3 — левой, средней и правой соответственно. И т.д.
AVK>Если это все, тогда в первый вариант вместо things подставляем:
AVK>AVK>window.Rows.SelectMany(row => row.Values)
AVK>
AVK>Или, если тебе хочется исключительно индексы, то:
AVK>AVK>Enumerable.Range(0, Width).SelectMany(x => Enumerable.Range(0, Height).Select(y => pixels[x, y]))
AVK>
AVK>Или, используя query comprehension
AVK>AVK>from x in Enumerable.Range(0, Width)
AVK>from y in Enumerable.Range(0, Height)
AVK>select pixels[x, y]
AVK>
AVK>Ну и все вместе:
AVK>AVK>return
AVK> (
AVK> from x in Enumerable.Range(0, Width)
AVK> from y in Enumerable.Range(0, Height)
AVK> select pixels[x, y].Red
AVK> )
AVK> .AsParallel()
AVK> .Sum();
AVK>
Честно говоря, не слишком понял — что ты суммируешь и куда. Если это реализация моей задачи — где массив сумм по столбцам ?
Но то, что эту задачу ты распараллелишь, я и не сомневаюсь. Ты все же попробуй те 5 вопросов осилить. А это суммирование, конечно, распараллелить можно, задачка-то пустяковая.
AVK>А теперь я поработаю чуток предсказателем — ты все равно не напишешь пример IT в императивной форме.
Вообще-то я не очень понимаю — в чем разница. Он какие-то проценты считает на баз неких коллекций, а я суммы считаю на базе тоже, если хочешь, "коллекций
— столбцов пикселей. Делить я не делю и не суммирую, верно, но так ли это важно ? Есть распараллеливание алгоритма, что тут особого-то.
Ну а если тебе так уж нужны именно эти проценты — обещать не могу, что сделаю в ближайшее время, но так и быть, постараюсь сделать. Но не торопи. Не до этого мне сейчас.
