Здравствуйте, Guard, Вы писали:
G>Уже имеются двухъядерные процессоры, на 2007 анонсированы четырехъядерные, в течение пяти лет обещают 80-ядерные. Что мы обычно имеем при таком
>>> S>Да, это прямо скажем гигантский шаг вперед — от многопоточного user/gdi к однопоточной тормозной WPF >>> >>> Кто тебе сказал, что user многопоточный? > > S>А кто тебе сказал, что он однопоточный. > > А ты попробуй.
сто раз пробовал
> Я как то давно по неопытности пробовал .
И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток?
> Хотя некоторые моменты прокатывают. Например смена значения у прогресс-бара.
Замечательно. Таким образом, мы выяснили, что SendMessage и PostMessage вполне себе многопоточны Осталось выяснить, что же конкретно в user, на твой взгляд, не многопоточно... Попробуй назвать хотя бы одну функция для работы с окнами, которую бы требовалось вызывать только из нитки, создавшей окно.
> Но вобще то любое обращение нужно перекидывать не напрямую, а через message loop.
Все что надо винда сама зашлет через message loop. А прикладному программисту при этом дозволяется самому решать, из какой нитки вызывать функции для работы с окнами. А иногда даже — обращаться не только из другой нитки, но и из другого процесса.
>>> А аналог GDI в WPF многопоточный. > > S>Я таки надеюсь, они со временем и всю WPF на многопоточную переделают. > > Ранние беты были многопоточными. А сейчас он на попытку работы из другого потока без диспатчера делает кислую рожу. Так что пока не будет управляемой версии браузера, надеятся не стоит. Хотя конечно бог его знает, что там послужило настоящей причиной этих финтов ушами.
Я так думаю, настоящей причиной послужила банальная нехватка времени.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, trophim, Вы писали:
T>А как распараллелить алгоритм, который никаким боком не хочет распараллеливаться. Т.е. такой, например, где очередной результат зависит от предыдущих расчетов. Ему наличие кучи ядер никак не поможет.
Лет 10 назад, мне мой научный руководитель в универе мимоходом рассказал про то, что есть такая область математики, что америкосы вовсю ею занимаются и ухитрились даже процесс сложения двух двоичных чисел распараллелить. ХЗ правда или нет.
Здравствуйте, Sergey, Вы писали:
S>Числомолотилки — не такое уж и ограниченное количество приложений Это, помимо всякого рокет сайнс, и архиваторы, и сжатие видео, и даже игрушки (да и не только игрушки — вообще, любое 3D).
Шифрование забыл. Всякие SSL/TLS/GPG/etc. Куда ж сейчас без этого?
Здравствуйте, Sergey, Вы писали:
S>Почему то мне кажется, что такая теория сродни теории автоматического доказательства корректности программ — вроде бы она и есть, но в практически важных случаях не работает, а потому нафиг ни кому не упала.
Она скорее сродни оптимизации кода, которая вполне даже работает, во вполне даже общих случаях.
> S>Числомолотилки — не такое уж и ограниченное количество приложений Это, помимо всякого рокет сайнс, и архиваторы, и сжатие видео, и даже игрушки (да и не только игрушки — вообще, любое 3D). > > Шифрование забыл. Всякие SSL/TLS/GPG/etc. Куда ж сейчас без этого?
Какое-то параллелится, а какое-то не очень. Я, например, не очень себе представляю, как тот же blowfish распараллелить. Там же блок зашифровался — ключик сменился. Потому и не написал.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток?
Я прошу прощения, что встреваю. Доков под рукой нет, возился с этими вещами давно, но разве сама винда не заботится о синхронизации потоков при обращении к окну? Мне что-то смутно помнится, что поток А, обращающийся к окну, созданному в потоке Б, блокируется (то бишь фактически вызов пропускается через message loop).
skipped
XZ>>Ворд — проверка орфографии заметно тормозит ввод текста, можно бы и расшить.
AVK>У меня не тормозит совсем. Что я делаю не так?
Согласен со всеми утверждениями, кроме этого. Вы неправильно делаете только одно: документы маленькие открываете (на быстрой машине). Когда документ на несколько сот страниц, то при его листании торможение из-за спеллчекера становится очень ощутимым. Я так и не смог отключить спеллчекер — пришлось снесни (все галочки по 10 раз убирал и снова ставил — нифига). Почему-то он у меня всегда(!) активен и тормозит, пёс.
> S>И, видимо, по неопытности же не понял, из-за чего были проблемы Давай попробую угадать — то было MFC'шное окошко, у которого ты напрямую вызвал метод? И ты по неопытности после этого решил, что к окошкам нельзя лазить из разных ниток? > > Я прошу прощения, что встреваю. Доков под рукой нет, возился с этими вещами давно, но разве сама винда не заботится о синхронизации потоков при обращении к окну?
Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя
> Мне что-то смутно помнится, что поток А, обращающийся к окну, созданному в потоке Б, блокируется (то бишь фактически вызов пропускается через message loop).
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя
Я так не считаю и не считал никогда. Вспоминаем о чем собственно топик был — об ускорении на нескольких ядрах. Синхронизация через message loop это не многопоточное выполнение, это именно синхронизация разных потоков. Естественно, что обратиться к существующему окну можно из другого потока. Естественно, в одном приложении можно запустить несколько потоков со своими message loops (в янусе, кстати, вовсю используется). А вот чего нельзя, так это собрать иерархию окон из разных потоков. А без этого говорить об многопоточном UI, имхо, не имеет смысла.
> S>Заботиться, конечно. Впрочем, AndrewVK считает, что так делать нельзя > > Я так не считаю и не считал никогда.
Извольте цитату: "Кто тебе сказал, что user многопоточный? Где ты окно создал, там его и используй, иначе будут глюки."
> Вспоминаем о чем собственно топик был — об ускорении на нескольких ядрах. Синхронизация через message loop это не многопоточное выполнение, это именно синхронизация разных потоков. Естественно, что обратиться к существующему окну можно из другого потока.
"Где ты окно создал, там его и используй, иначе будут глюки"
> Естественно, в одном приложении можно запустить несколько потоков со своими message loops (в янусе, кстати, вовсю используется). А вот чего нельзя, так это собрать иерархию окон из разных потоков.
Тоже можно. Могу пример выложить, если кто не верит.
> А без этого говорить об многопоточном UI, имхо, не имеет смысла.
Еще как имеет.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
>> Я так не считаю и не считал никогда.
S>Извольте цитату: "Кто тебе сказал, что user многопоточный? Где ты окно создал, там его и используй, иначе будут глюки."
Под использованием имелось ввиду именно использование контрола в своем окне, а не обращение к нему через SendMessage/PostMessage.
S>"Где ты окно создал, там его и используй, иначе будут глюки"
Так и есть.
>>А вот чего нельзя, так это собрать иерархию окон из разных потоков.
S>Тоже можно. Могу пример выложить, если кто не верит.
Здравствуйте, AndrewVK, Вы писали:
S>>Извольте цитату: "Кто тебе сказал, что user многопоточный? Где ты окно создал, там его и используй, иначе будут глюки."
AVK>Под использованием имелось ввиду именно использование контрола в своем окне
Неплохая оговорочка
AVK>, а не обращение к нему через SendMessage/PostMessage.
А ShowWindow можно вызвать? Или SetWindowLong?
S>>"Где ты окно создал, там его и используй, иначе будут глюки"
AVK>Так и есть.
Тогда ответь на простой вопрос — что именно будет глючить?
>>>А вот чего нельзя, так это собрать иерархию окон из разных потоков.
S>>Тоже можно. Могу пример выложить, если кто не верит.
AVK>Выкладывай.
Здравствуйте, Sergey, Вы писали:
S>Неплохая оговорочка
Это не оговорочка. Я говорю в контексте этого топика и обсуждать сопредельные темы мне не интересно.
AVK>>, а не обращение к нему через SendMessage/PostMessage.
S>А ShowWindow можно вызвать? Или SetWindowLong?
Можно.
AVK>>Так и есть.
S>Тогда ответь на простой вопрос — что именно будет глючить?
Обработка сообщений. Циклы то обработки сообщений будут разные. Для того, чтобы гуй был по честному многопоточный, нужно, чтобы обработка сообщений была в режиме клиент-сервер, т.е. на каждое внешнее сообщение нужно заводить свой поток обработки. Особенно это важно в случае сообщений вроде WM_PAINT. В WPF от этого ушли вынесением рендеринга во внешний движок.
> S>Неплохая оговорочка > > Это не оговорочка. Я говорю в контексте этого топика и обсуждать сопредельные темы мне не интересно.
Значит, мы очень по-разному понимаем контекст этого топика . Мне, например, помимо "честной многопоточности", как ты ее называешь, в контексте этого топика очень важно иметь возможность просто обращаться к любому окну из любого потока, не заморачиваясь с синхронизацией, поскольку это сильно упрощает разработку многопоточных программ с GUI.
> AVK>>, а не обращение к нему через SendMessage/PostMessage. > > S>А ShowWindow можно вызвать? Или SetWindowLong? > > Можно.
Итого — вообще все функции для работы с окнами вызывать можно. Чего ж там тогда однопоточного?
> AVK>>Так и есть. > > S>Тогда ответь на простой вопрос — что именно будет глючить? > > Обработка сообщений. Циклы то обработки сообщений будут разные.
И что с того, что разные? С чего бы им от этого глючить?
> Для того, чтобы гуй был по честному многопоточный, нужно, чтобы обработка сообщений была в режиме клиент-сервер, т.е. на каждое внешнее сообщение нужно заводить свой поток обработки.
Это уже никому не нужный экстремизм, налагающий вдобавок чересчур сильные ограничения на прикладной код.
> Особенно это важно в случае сообщений вроде WM_PAINT.
В случае долгой отрисовки один черт приходится применять двойную буферизацию. Соответственно, рисовать в отдельном потоке не представляет труда и без поддержки user.
> В WPF от этого ушли вынесением рендеринга во внешний движок.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Значит, мы очень по-разному понимаем контекст этого топика . Мне, например, помимо "честной многопоточности", как ты ее называешь, в контексте этого топика очень важно иметь возможность просто обращаться к любому окну из любого потока, не заморачиваясь с синхронизацией, поскольку это сильно упрощает разработку многопоточных программ с GUI.
С приличными обертками, вроде тех, что в .NET FW 2.0 это уже можно сделать довольно легко и прозрачно (в WPF в том числе, отличие от User32 только в деталях, а внутри все тот же message loop). Я сам это пользую в больших количествах. Но! Это все нужно, когда не хочется подмораживать UI при каком нибудь сетевом обращении. Если же нам хочется, чтобы за счет распараллеливания UI стал работать на нескольких ядрах быстрее, то такая техника бесполезна. Вот, собственно, и все, что я хотел сказать. Приношу извинения за то, что неясно выразился.
>> Для того, чтобы гуй был по честному многопоточный, нужно, чтобы обработка сообщений была в режиме клиент-сервер, т.е. на каждое внешнее сообщение нужно заводить свой поток обработки.
S>Это уже никому не нужный экстремизм
Ну, отчасти кое где такой подход используется.
S>, налагающий вдобавок чересчур сильные ограничения на прикладной код.
Без этого никуда, если мы хотим получить ускорение за счет многоядерности. Ну а то, что задачка эта непростая, так об этом я говорил с самого начала. Впрочем, функциональный стиль заметную часть проблем способен убрать.
>> Особенно это важно в случае сообщений вроде WM_PAINT.
S>В случае долгой отрисовки один черт приходится применять двойную буферизацию.
Double buffering всего лишь средство избавления от мерцания, техника ортогональная тому, о чем я говорю. Вынесение отрисовки в другой поток позволяет, во-первых, избежать мусора на экране из-за замерзания GUI-потока (в swing это есть), а во-вторых ускорить время реакции интерфейса на действия пользователя за счет отсутсвия ожидания завершения графической операции.
S> Соответственно, рисовать в отдельном потоке не представляет труда и без поддержки user.
Ну, если собственную диспетчеризацию отрисовки сделать, то наверное да. Но хотелось бы это на уровне библиотеки иметь и не только для WM_PAINT.
> S>, налагающий вдобавок чересчур сильные ограничения на прикладной код. > > Без этого никуда, если мы хотим получить ускорение за счет многоядерности. Ну а то, что задачка эта непростая, так об этом я говорил с самого начала. Впрочем, функциональный стиль заметную часть проблем способен убрать.
Я имел в виду — сложно надо делать только тогда, когда об этом явно попросит прикладной программист, а не по умолчанию. Можно, конечно, предусмотреть разные threading models, как с ActiveX, но это тоже не выход — люди их порой воспринимают совершенно неадекватно, этого я в свое время достаточно нагляделся.
> S>В случае долгой отрисовки один черт приходится применять двойную буферизацию. > > Double buffering всего лишь средство избавления от мерцания, техника ортогональная тому, о чем я говорю. Вынесение отрисовки в другой поток позволяет, во-первых, избежать мусора на экране из-за замерзания GUI-потока (в swing это есть), а во-вторых ускорить время реакции интерфейса на действия пользователя за счет отсутсвия ожидания завершения графической операции.
Я, возможно непонятно выразился. Имелась в виду следующая техника, хотя я таки немного прогнал — многопоточность user в данном случае желательна, чтобы не организовывать закат солнца вручную. Double buffering позволяет достаточно легко вынести отрисовку в другой поток. Для этого достаточно помнить, какая область объекта у нас отрисована в буфер. По приходе WM_PAINT объявляем, что у нас все нарисовано ( BeginPaint / EndPaint ), проверяем — отрисовано или на самом деле в буфер то, что надо. Если да, просто блитим буфер на экран, если нет — запускаем нить с отрисовкой (окно ей не нужно, потому я и написал, что многопоточность от user в данном случае не требуется). По окончании работы нити с отрисовкой вызываем InvalidateRect () для нашего окна и отрисованного прямоугольника (а вот тут уже хорошо бы, чтобы не пришлось для этого организовывать самопальную очередь).
> S> Соответственно, рисовать в отдельном потоке не представляет труда и без поддержки user. > > Ну, если собственную диспетчеризацию отрисовки сделать, то наверное да. Но хотелось бы это на уровне библиотеки иметь и не только для WM_PAINT.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sergey, Вы писали:
S>Я имел в виду — сложно надо делать только тогда, когда об этом явно попросит прикладной программист, а не по умолчанию. Можно, конечно, предусмотреть разные threading models, как с ActiveX, но это тоже не выход — люди их порой воспринимают совершенно неадекватно, этого я в свое время достаточно нагляделся.
+1. Собственно это и есть одна из главных проблем использования многоядерных процессоров на десктопе.
S>Я, возможно непонятно выразился. Имелась в виду следующая техника, хотя я таки немного прогнал — многопоточность user в данном случае желательна, чтобы не организовывать закат солнца вручную. Double buffering позволяет достаточно легко вынести отрисовку в другой поток. Для этого достаточно помнить, какая область объекта у нас отрисована в буфер. По приходе WM_PAINT объявляем, что у нас все нарисовано ( BeginPaint / EndPaint ), проверяем — отрисовано или на самом деле в буфер то, что надо.
Здравствуйте, Sergey, Вы писали:
S>Пока чего-нибудь радикального не придумают — ни куда не денешся, кроме как на откуп разработчика ее оставлять. Но радикальных придумок что-то не видать.
Вы просто не в курсе. Познакомтесь с чистыми функциональными языками. Там проблема распараллеливания как класс отсутствует. И каких-либо особых телодвижений от программиста для распараллеливания в виде создания костылей типа семафоров, тредов, критических секций и прочего не требуется.
> S>Пока чего-нибудь радикального не придумают — ни куда не денешся, кроме как на откуп разработчика ее оставлять. Но радикальных придумок что-то не видать. > > > Вы просто не в курсе. Познакомтесь с чистыми функциональными языками.
Покажите мне хотя бы один видеокодек или архиватор, написанный на чисто функциональном языке, и я вам почти поверю — после того, как сравню его производительность и качество сжатия с "традиционными". Почти — потому что вам придется еще доказать, что язык, позволяющий что-то читать-писать из файла (и вообще общаться с внешним миром) может считаться чисто функциональным.
> Там проблема распараллеливания как класс отсутствует.
Допустим, мои данные не влазят в память, и мне приходится их держать на диске. В файл(ы) за этими данными одновременно лезет несколько потоков. Проблема синхронизации по-прежнему будет отсутствовать в случае, если программа, которая это делает, написана на чисто функциональном языке?
> И каких-либо особых телодвижений от программиста для распараллеливания в виде создания костылей типа семафоров, тредов, критических секций и прочего не требуется.
Копировать все подряд данные, так чтобы для доступа к ним не требовалось мьютексов и кондишенов, я могу и на С++, С или даже ассемблере. Только что при этом станет с производительностью, если обрабатываемые массивы данных достаточно большие?
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
