Да, я действительно не подумал, что для LTCG нужен бекэнд компилятора, а для генерации x86 кода он есть только в x86 варианте. Ну в таком случае им нужно серьезно подумать о рефакторинге одного монолитного бинарника в несколько более меликих.
Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
> Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
Это откуда цитатка (интересно посмотреть на уровень неадеквата)?
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)
Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:
Во первых линкер есть и такой и такой. Во вторых, они уперлись в предел 3Гб адресного пространства, а wow64 процессам (32-битные процессы на 64-битной системе) отдаются вообще все 4Гб адресного пространства (если бинарник говорит о том, что он согласен с тем, что старший бит в указателях может быть ненулевым — а link.exe имеет поддержку больших адресных пространств испокон веков — собственно это тот же флаг, который включает поддерку /3GB для процесса). В общем на полгодика б хватило — а там все равно весь девелопмент переводить на x64. Хоть так хоть эдак. Ну или отключать PGO
1. Ну так на netfx можно как потреблять так и создавать WinRT компоненты. В чем проблема?
2. Опять не разобравшись пытаетесь судить. Ренессанс C++ в новом стандарте. Саттер, наиболее часто употребляющий этот термин, вообще крайне редко упоминает /CX (и начал говорить об этом самом ренессансе ЗАДОЛГО до анонса C++/CX). Хочется ATL-style темплейтов? Пожалуйста — есть WRL — пишите сколько хотите. Вот только использование WRL темплейтов все равно чересчур громоздко по сравнению с C# и JScript, а задачей, напомню, было сделать разработку приложений ОДИНАКОВО легкой на всех поддерживаемых языках. Ну и напоследок, интервью с VC++ топ-менеджерами посвященное ИСКЛЮЧИТЕЛЬНО ренессансу C++. Найдите ХОТЬ ОДНО упоминание /CX
3. Кастомный WebGL вместо нормальной кроссбраузерной поддержки Windows.UI?
Full disclosure: для большей части моего браузинга, я использую Хром со все увеличивающейся долей IE9 (и 10 — у меня есть таблетка и хром там, откровенно говоря, сосет невероятно).
Может я чего не понимаю, но покажете мне студию которая без сторонних расширений сгенерирует вам тулбар за 5 минут?
Если бы вообще генерировалось автоматически, это было бы «5 секунд», а не «5 минут». Вообще, тулбары я не писал а писал BHO, но бегло просмотрев документацию, существенных отличий не вижу. Вот пошаговый пример создания BHO за 5 минут и да, практически вся обвязка генерируется автоматически.
MSHTML — DOM хорошо давайте попробуем сохранить всю страницу, ой блин а нам нужен ещё IPersist и ещё все ресурсы страницы
Даже если нет другого пути (мне лень пытаться разбираться, тем более, что Вы сказали, что потратили на это полтора месяца) — это не вопрос «убогости» COM и даже не вопрос «убогости» IE — все сводится к доступному API (IE то страницы сохранять умеет, просто не предоставляет эту возможность «наружу»).
Для Firefox/Chrome уже школьник может писать расширения.
Вот опять Вы сравниваете «расширения» с плагинами. Расширения вполне себе реализуются как еще один уровень абстракции над плагинами (если не ошибаюсь та же жирная обезьяна была реализована в виде плагина). И лично мне COM нравится гораздо больше, чем NPAPI. Другое дело, что они не реализованы «из коробки» (но реализовано другое). Можно говорить (и поспорить) об «убогости» станадртной ПОСТАВКИ, но никаких свидетельств «убогости» платформы.
Если инструмент не позволяет решить задачу с приемлемой затратой ресурсов может к чёрту этот инструмент.
Да ради бога, вот только если уж взялись назначать виновных — назначайте их правильно. Лично меня совершенно не волнуют проблемы написания тулбаров (я терпеть не могу даже те, что уже есть — не говоря уж о новых). Это же, похоже, относится к тем 40% пользователей IE, которых Вы упомянули. Более того, есть у меня подозрение, что Хромом/Файрфоксом в подавляющем большинстве случаев пользуются не из-за легкости создания тулбаров.
И никто ничего с этой убогостью делать не собирается, нам дадут красивую обёртку, а всередине останется то же убожество.
Мне кажется Вы уже имеете «вывод» (IE — убожество и должен умереть) и пытаетесь подтягивать под него «факты». Ничего, что внутри файрфокса фактически то же самое «убожество» (IUnknown переименован в nsISupports и вместо ProgID используются ContractID, но архитектурно они идентичны)? Более того, одно время у файрфокса были XPCOM-овые плагины, которые позже заменили на более примитивные NPAPI. Ничего, что Вас всю дорогу не устраивала именно «некрасивость» обертки и НИ ОДНОГО аргумента против собственно COM (и IE) Вы так и не выдали?
Тулбар для IE делается минут за 5 (весь код генерируется студией). Писать в реестр из JScript Вы можете и в IE (если зона доверия позволяет) — да-да, через COM.
Насчет прокидывания данных через COM чего то я не понял. MSHTML-овый DOM это И ЕСТЬ набор COM-объектов. Не нужно ничего «прокидывать» — ими нужно просто пользоваться НАПРЯМУЮ.
Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка.
Напомню, что Вы начали с утверждения, что COM устарел и настолько фундаментально испорчен, что остается только его выбросить. Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API».
Перечитал. Несколько сумбурно (не быть мне tech writer-ом), а в одном месте вообще мысль оборвалась (все не могу выработать привычку перечитывать перед нажатием на «submit»), но в целом мысль должна быть ясна.
На всякий случай попробую прояснить суть с другой стороны: важно понимать отличие асинхронной операции от неблокирующей. Неблокирующие операции просто обязаны вернуться сразу же: если они не могут выполнить что-нибудь осмысленное, то они могут вернуться с ошибкой (например, EWOULDBLOCK). Асинхронная же операция это такая, которая может выполняться «в фоне», то есть операция выполняется всегда: если можно выполнить сразу — выполняем сразу, если нельзя — *инициируем* операцию и возвращаемся сразу. Все асинхронные операции неблокирующие, но не все неблокирующие операции асинхронные.
Из этой разницы и следует разница между IOCP и select. IOCP работает с асинхронными операциями и позволяет отреагировать на завершение операции, инициированной где-то в другом месте. select же (в том числе и «асинхронная» версия САМОГО select — WSAXxxSelect) работает с (не)блокирующими операциями. То есть можно создать «неблокирующий» сокет, recv (или read) из которого будет всегда возвращать ошибку, если в буфере пусто, но запостить собственный буфер для ожидания в него данных нельзя.
Насчет непопулярности спорно. Технология всегда была весьма популярна в high-load Windows приложениях. За пределами high-load использование асинхронности просто не имело смысла (ее труднее понять а если выгода неочевидна, то использование синхронных вызовов попросту легче). А за пределами Windows все по разному: на BSD/Solaris были свои аналоги, на Linux же поддержки асинхронных операций вообще не было до относительно недавнего времени (а как по мне, их и сейчас толком нет).
Вот это вот наводит на некоторые размышления и сомнения:
NumberOfConcurrentThreads [in]
На самом деле не должно. Ожидать более, чем «there are processors in the system» не имеет смысла. Следует понимать, что на IOCP можно заблокировать и больше, чем NumberOfConcurrentThreads потоков, но они не
Знать бы как оно работает внутри…
Внутри все довольно просто. Пишу по памяти, так что могу напутать с деталями, но в общих чертах все должно быть правильно.
DISPATCHER_OBJECT (в общем все, что можно ждать при помощи NtWaitForXxxObject, в том числе и файлы) можно ассоциировать с очередью (KQUEUE). Когда объект переводится в signaled state (файлы «сигнализируются» когда завершается операция ввода/вывода для этого файла), в эту очередь, если она есть, добавляется wait-блок. GetQueuedCompletionStatus (вернее его native помощник NtRemoveIoCompletion) блокируется пока в этой очереди не появится чего нибудь.
Если еще короче, в объекте-IOCP есть очередь, а в файлах, ассоциированных с этим IOCP есть указатель на эту очередь. Вот и вся история.
Отвечая на начальный вопрос, WSAXxxSelect (и синхронный select) и IOCP — совершенно разные подходы, причем IOCP более изящный и зачастую более производительный. select отмечает момент времени, когда можно произвести «блокирующее» чтение/запись в файл без, собственно, блокирования (например, когда есть данные в буфере для recv) и предназначен для работы с этими синхронными версиями (send/recv/etc).
В то же время IOCP позволяет определить момент завершения асинхронной операции, требует использования асинхронных вызовов (WSASend/WSARecv/etc), позволяет избавиться от промежуточной буферизации: TCP/IP стек может копировать данные прямо в ожидающий пользовательский буфер, а в случае TOE пользовательский буфер может быть заполнен прямо сетевой картой по DMA. В случае send (и других операция тоже, включая recv, просто для send выгода не так очевидна), настоящие асинхронные операции позволяют опять же избавиться от промежуточного буфера (TCP/IP может «владеть» пользовательским буфером без необходимости срочно скопировать его куда нибудь и отпустить поток), а также это позволяет избавиться от задержек (latency) между готовностью к выполнению следующей операции и собственно выполнением этой операции: приложение может запостить несколько операций чтения/записи подряд — подход, используемый например в высокопроизводительной графике, для снижения задержек (double/triple-buffering).
Прелесть DCT (и других преобразований Фурье) в том, что можно вносить потери не только при кодировании, но и при декодировании: достаточно просто проигнорировать часть высокочастотных коэффициентов.
Я, например, слушал mp3 на MC68020 @14 МГц (поверженного врага можно упоминать и в блоге Intel) без математического сопроцессора. Без заиканий, да. В 8-bit mono + до безобразия урезанные «верхи». При этом на компьютере вообще больше ничего нельзя было делать.
Так что вы оба вполне можете оказаться правы: все зависит как от оптимизированности конкретного кода, выполняющего декодирование так и от настроек, с которыми этот код работает и даже от конкретных файлов, которые проигрываются (даже если «видимые» параметры как то битность на канал и частота дискретизации вроде бы одинаковые).
Лично мои воспоминания говорят о том, что в одной из первых массовых игр, использующих mp3 — HoMM3 (а это поголовно P1/P2 — далеко не все апгрейдились сразу после выхода новых железок) — люди вырезали эти самые mp3 и играли в полной тишине потому что звук заикался и тормозил остальную игру (ну и плюс вырезание звука и видеороликов позволяло сэкономить лишнюю сотню мегабайт на диске).
Если приложение загружает библиотеку lib1.dll не указывая полный путь, то Windows ищет библиотеку сначала в текущем каталоге, потом в каталоге программы, в каталоге Windows и так далее.
Не совсем так, в текущем каталоге поиск происходит одним из последних. Проблемы начинаются если во всех остальных каталогах dll-ки с нужным именем нет, что случается чаще чем хотелось бы.
Да нет, с мышью и клавиатурой пока что отличий в юзабилити от семерки практически нет, так как нет нормальных «Metro style apps» и приходится пользоваться тем же «классическим» софтом — как появятся будет значительно удобнее.
На архитектурном уровне изменения очень существенны
volatile (теоретически) ставит полный memory barrier перед и после обращения. Практически же, компиляторы уже достаточно умны, чтоб осознавать, где OOE быть не может: в частности x86/amd64 не переставляют операции чтения относительно других операций чтения, операции записи относительно других операций записи и, если мне не изменяет память, операции чтения и записи к одному адресу, что делает IA ПОЧТИ in-order и это самое опасное как раз потому, что баги вылазят крайне редко и в крайне специфичных условиях.
Более того, существует опасность, что OOE политика изменится в будущих версиях процессора (что уже случалось во времена пентиума про) или что придется перекомпилировать исходник под архитектуру, с гораздо более агрессивным переставлением инструкций (Windows 8 on ARM, например или там на Xbox).
Вместо собственного велосипеда я бы опять таки посоветовал использовать ConcRT (ну или Intel TBB если хочется кроссплатформенности). Причем явное использование неблокирующей очереди чаще всего не нужно. В ConcRT есть Asynchronous Agents Library с message passing-ом (как data-flow ориентированные message block-и, так и control-flow ориентированные agent-ы), в TBB есть пайплайны и флоуграфы.
Серьезно, самописная синхронизация — это настолько же опасно, как и самописная криптография. Начинать велосипедостроение стоит только если не осталось ну совсем никаких других вариантов.
Write barriers решают ровно половину проблемы, а у x86 есть три разных memory barrier-а: mfence, lfence и sfence. Что еще печальнее, оптимизирующие компиляторы переставляют инструкции независимо от того будет ли целевой процессор переставлять их в рантайме.
Как уже было отмечено, код некорректный. И да, на x86 он тоже не будет работать на моделях, выпущенных в последние 16 лет (исключая текущие атомы — будущие вполне возможно будут иметь OOE). Этот код можно попробовать «починить» очень аккуратным расставлением lfence/sfence на практически все обращения к writerTop/readerTop, при этом малейшая ошибка будет приводить к «гонкам», принципиально невоспроизводимым в отладчике (отладчики всегда исполняют инструкции по порядку). Кроме того, даже если текущие x86 поддерживают когерентность кеша автоматически, это совершенно не означает, что так будет всегда.
«Никогда не пытайтесь реализовать собственные примитивы синхронизации, если только у Вас нет хотя бы 5-тилетнего опыта, связанного с анализом чужих» (с) Я, только что
«Фраза, оформленная в виде цитаты, выглядит более авторитетно» (с) Я, только что
Что же до «не нашел ничего похожего». Простейший запрос возвращает 7 миллионов результатов. Если это Windows приложение, советую использовать ConcRT
Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)
Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:
2. Опять не разобравшись пытаетесь судить. Ренессанс C++ в новом стандарте. Саттер, наиболее часто употребляющий этот термин, вообще крайне редко упоминает /CX (и начал говорить об этом самом ренессансе ЗАДОЛГО до анонса C++/CX). Хочется ATL-style темплейтов? Пожалуйста — есть WRL — пишите сколько хотите. Вот только использование WRL темплейтов все равно чересчур громоздко по сравнению с C# и JScript, а задачей, напомню, было сделать разработку приложений ОДИНАКОВО легкой на всех поддерживаемых языках. Ну и напоследок, интервью с VC++ топ-менеджерами посвященное ИСКЛЮЧИТЕЛЬНО ренессансу C++. Найдите ХОТЬ ОДНО упоминание /CX
3. Кастомный WebGL вместо нормальной кроссбраузерной поддержки Windows.UI?
Если бы вообще генерировалось автоматически, это было бы «5 секунд», а не «5 минут». Вообще, тулбары я не писал а писал BHO, но бегло просмотрев документацию, существенных отличий не вижу. Вот пошаговый пример создания BHO за 5 минут и да, практически вся обвязка генерируется автоматически.
Даже если нет другого пути (мне лень пытаться разбираться, тем более, что Вы сказали, что потратили на это полтора месяца) — это не вопрос «убогости» COM и даже не вопрос «убогости» IE — все сводится к доступному API (IE то страницы сохранять умеет, просто не предоставляет эту возможность «наружу»).
Вот опять Вы сравниваете «расширения» с плагинами. Расширения вполне себе реализуются как еще один уровень абстракции над плагинами (если не ошибаюсь та же жирная обезьяна была реализована в виде плагина). И лично мне COM нравится гораздо больше, чем NPAPI. Другое дело, что они не реализованы «из коробки» (но реализовано другое). Можно говорить (и поспорить) об «убогости» станадртной ПОСТАВКИ, но никаких свидетельств «убогости» платформы.
Да ради бога, вот только если уж взялись назначать виновных — назначайте их правильно. Лично меня совершенно не волнуют проблемы написания тулбаров (я терпеть не могу даже те, что уже есть — не говоря уж о новых). Это же, похоже, относится к тем 40% пользователей IE, которых Вы упомянули. Более того, есть у меня подозрение, что Хромом/Файрфоксом в подавляющем большинстве случаев пользуются не из-за легкости создания тулбаров.
Мне кажется Вы уже имеете «вывод» (IE — убожество и должен умереть) и пытаетесь подтягивать под него «факты». Ничего, что внутри файрфокса фактически то же самое «убожество» (IUnknown переименован в nsISupports и вместо ProgID используются ContractID, но архитектурно они идентичны)? Более того, одно время у файрфокса были XPCOM-овые плагины, которые позже заменили на более примитивные NPAPI. Ничего, что Вас всю дорогу не устраивала именно «некрасивость» обертки и НИ ОДНОГО аргумента против собственно COM (и IE) Вы так и не выдали?
Насчет прокидывания данных через COM чего то я не понял. MSHTML-овый DOM это И ЕСТЬ набор COM-объектов. Не нужно ничего «прокидывать» — ими нужно просто пользоваться НАПРЯМУЮ.
Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка.
Напомню, что Вы начали с утверждения, что COM устарел и настолько фундаментально испорчен, что остается только его выбросить. Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API».
На всякий случай попробую прояснить суть с другой стороны: важно понимать отличие асинхронной операции от неблокирующей. Неблокирующие операции просто обязаны вернуться сразу же: если они не могут выполнить что-нибудь осмысленное, то они могут вернуться с ошибкой (например, EWOULDBLOCK). Асинхронная же операция это такая, которая может выполняться «в фоне», то есть операция выполняется всегда: если можно выполнить сразу — выполняем сразу, если нельзя — *инициируем* операцию и возвращаемся сразу. Все асинхронные операции неблокирующие, но не все неблокирующие операции асинхронные.
Из этой разницы и следует разница между IOCP и select. IOCP работает с асинхронными операциями и позволяет отреагировать на завершение операции, инициированной где-то в другом месте. select же (в том числе и «асинхронная» версия САМОГО select — WSAXxxSelect) работает с (не)блокирующими операциями. То есть можно создать «неблокирующий» сокет, recv (или read) из которого будет всегда возвращать ошибку, если в буфере пусто, но запостить собственный буфер для ожидания в него данных нельзя.
Насчет непопулярности спорно. Технология всегда была весьма популярна в high-load Windows приложениях. За пределами high-load использование асинхронности просто не имело смысла (ее труднее понять а если выгода неочевидна, то использование синхронных вызовов попросту легче). А за пределами Windows все по разному: на BSD/Solaris были свои аналоги, на Linux же поддержки асинхронных операций вообще не было до относительно недавнего времени (а как по мне, их и сейчас толком нет).
На самом деле не должно. Ожидать более, чем «there are processors in the system» не имеет смысла. Следует понимать, что на IOCP можно заблокировать и больше, чем NumberOfConcurrentThreads потоков, но они не
Внутри все довольно просто. Пишу по памяти, так что могу напутать с деталями, но в общих чертах все должно быть правильно.
DISPATCHER_OBJECT (в общем все, что можно ждать при помощи NtWaitForXxxObject, в том числе и файлы) можно ассоциировать с очередью (KQUEUE). Когда объект переводится в signaled state (файлы «сигнализируются» когда завершается операция ввода/вывода для этого файла), в эту очередь, если она есть, добавляется wait-блок. GetQueuedCompletionStatus (вернее его native помощник NtRemoveIoCompletion) блокируется пока в этой очереди не появится чего нибудь.
Если еще короче, в объекте-IOCP есть очередь, а в файлах, ассоциированных с этим IOCP есть указатель на эту очередь. Вот и вся история.
Отвечая на начальный вопрос, WSAXxxSelect (и синхронный select) и IOCP — совершенно разные подходы, причем IOCP более изящный и зачастую более производительный. select отмечает момент времени, когда можно произвести «блокирующее» чтение/запись в файл без, собственно, блокирования (например, когда есть данные в буфере для recv) и предназначен для работы с этими синхронными версиями (send/recv/etc).
В то же время IOCP позволяет определить момент завершения асинхронной операции, требует использования асинхронных вызовов (WSASend/WSARecv/etc), позволяет избавиться от промежуточной буферизации: TCP/IP стек может копировать данные прямо в ожидающий пользовательский буфер, а в случае TOE пользовательский буфер может быть заполнен прямо сетевой картой по DMA. В случае send (и других операция тоже, включая recv, просто для send выгода не так очевидна), настоящие асинхронные операции позволяют опять же избавиться от промежуточного буфера (TCP/IP может «владеть» пользовательским буфером без необходимости срочно скопировать его куда нибудь и отпустить поток), а также это позволяет избавиться от задержек (latency) между готовностью к выполнению следующей операции и собственно выполнением этой операции: приложение может запостить несколько операций чтения/записи подряд — подход, используемый например в высокопроизводительной графике, для снижения задержек (double/triple-buffering).
Я, например, слушал mp3 на MC68020 @14 МГц (поверженного врага можно упоминать и в блоге Intel) без математического сопроцессора. Без заиканий, да. В 8-bit mono + до безобразия урезанные «верхи». При этом на компьютере вообще больше ничего нельзя было делать.
Так что вы оба вполне можете оказаться правы: все зависит как от оптимизированности конкретного кода, выполняющего декодирование так и от настроек, с которыми этот код работает и даже от конкретных файлов, которые проигрываются (даже если «видимые» параметры как то битность на канал и частота дискретизации вроде бы одинаковые).
Лично мои воспоминания говорят о том, что в одной из первых массовых игр, использующих mp3 — HoMM3 (а это поголовно P1/P2 — далеко не все апгрейдились сразу после выхода новых железок) — люди вырезали эти самые mp3 и играли в полной тишине потому что звук заикался и тормозил остальную игру (ну и плюс вырезание звука и видеороликов позволяло сэкономить лишнюю сотню мегабайт на диске).
Не совсем так, в текущем каталоге поиск происходит одним из последних. Проблемы начинаются если во всех остальных каталогах dll-ки с нужным именем нет, что случается чаще чем хотелось бы.
На архитектурном уровне изменения очень существенны
Но вообще я пользуюь 7-zip который умеет wim-ы нативно.
Более того, существует опасность, что OOE политика изменится в будущих версиях процессора (что уже случалось во времена пентиума про) или что придется перекомпилировать исходник под архитектуру, с гораздо более агрессивным переставлением инструкций (Windows 8 on ARM, например или там на Xbox).
Вместо собственного велосипеда я бы опять таки посоветовал использовать ConcRT (ну или Intel TBB если хочется кроссплатформенности). Причем явное использование неблокирующей очереди чаще всего не нужно. В ConcRT есть Asynchronous Agents Library с message passing-ом (как data-flow ориентированные message block-и, так и control-flow ориентированные agent-ы), в TBB есть пайплайны и флоуграфы.
Серьезно, самописная синхронизация — это настолько же опасно, как и самописная криптография. Начинать велосипедостроение стоит только если не осталось ну совсем никаких других вариантов.
«Никогда не пытайтесь реализовать собственные примитивы синхронизации, если только у Вас нет хотя бы 5-тилетнего опыта, связанного с анализом чужих» (с) Я, только что
«Фраза, оформленная в виде цитаты, выглядит более авторитетно» (с) Я, только что
Что же до «не нашел ничего похожего». Простейший запрос возвращает 7 миллионов результатов. Если это Windows приложение, советую использовать ConcRT