Вы успешно использовали GPGPU? [закрытый]
Google для надежного обнаружения браузера часто приводит к проверке строки агента пользователя. Этот метод не является надежным, так как тривиально обманывать это значение. Я написал метод обнаружения браузеров с помощью duck-typing .
Используйте только метод обнаружения браузера, если это действительно необходимо, например, чтобы показать инструкции для конкретного пользователя для установки расширения , Использовать обнаружение функции, когда это возможно.
Демо: https://jsfiddle.net/311aLtkz/
// Opera 8.0+
var isOpera = (!!window.opr && !!opr.addons) || !!window.opera || navigator.userAgent.indexOf(' OPR/') >= 0;
// Firefox 1.0+
var isFirefox = typeof InstallTrigger !== 'undefined';
// Safari 3.0+ "[object HTMLElementConstructor]"
var isSafari = /constructor/i.test(window.HTMLElement) || (function (p) { return p.toString() === "[object SafariRemoteNotification]"; })(!window['safari'] || (typeof safari !== 'undefined' && safari.pushNotification));
// Internet Explorer 6-11
var isIE = /*@cc_on!@*/false || !!document.documentMode;
// Edge 20+
var isEdge = !isIE && !!window.StyleMedia;
// Chrome 1+
var isChrome = !!window.chrome && !!window.chrome.webstore;
// Blink engine detection
var isBlink = (isChrome || isOpera) && !!window.CSS;
Анализ надежности
предыдущий метод зависел от свойств механизма рендеринга ( -moz-box-sizing и -webkit-transform) для обнаружения браузера. Эти префиксы в конечном итоге будут удалены, поэтому, чтобы сделать обнаружение еще более надежным, я переключился на специфические для браузера характеристики:
- Internet Explorer: JScript Условная компиляция (до IE9 ) и
document.documentMode. - Edge: в браузерах Trident и Edge реализация Microsoft предоставляет конструктор
StyleMedia. Исключение Trident оставляет нас с Edge. - Firefox: API Firefox для установки надстроек:
InstallTrigger - Chrome: глобальный объект
chromeсодержащий несколько свойств, включая документированный объектchrome.webstore. - Safari: уникальный шаблон именования в его именах конструкторов. Это наименее прочный метод всех перечисленных свойств и угадайте, что? В Safari 9.1.3 он был исправлен. Поэтому мы проверяем
SafariRemoteNotification, который был введен после версии 7.1, чтобы охватить все Safaris от 3.0 и выше. - Opera:
window.operaсуществует в течение многих лет, но будет отброшена , когда Opera заменит свой движок Blink + V8 (используется Chromium). Обновление 1: Выпущена Opera 15 , ее строка UA выглядит как Chrome, но с добавлением «OPR». В этой версии определяетсяchromeобъект (ноchrome.webstore- нет). Так как Opera пытается клонировать Chrome, я использую для этого нюансы агента пользователя. Обновление 2:!!window.opr && opr.addonsможно использовать для обнаружения Opera 20 + (вечнозеленых). - Blink:
CSS.supports()был введен в Blink , как только Google включил Chrome 28. Это, конечно, тот же Blink, который используется в Opera.
Успешно протестировано в:
- Firefox 0.8 - 61
- Chrome 1.0 - 68
- Opera 8.0 - 34
- Safari 3.0 - 10
- IE 6 - 11
- Edge - 20-42
Обновлено в ноябре 2016 года, чтобы включить обнаружение браузеров Safari от 9.1.3 и выше
Обновлено в августе 2018 года, чтобы обновить последние успешные тесты на chrome, IE IE Firefox и краю.
blockquote>
9 ответов
Я делал gpgpu разработку с поток SDK ATI вместо Cuda. Какое увеличение производительности, которое Вы получите, зависит от партия из факторов, но самой важной является числовая интенсивность. (Таким образом, отношение вычисляет операции к ссылкам памяти.)
А уровень 1 BLAS или функция уровня 2 BLAS как добавление двух векторов только делают 1 математическую операцию для каждых 3 памятей ссылки, таким образом, NI (1/3). Это всегда выполняется медленнее с CAL или Cuda, чем просто выполнение на CPU. Главной причиной является время, которое требуется для передачи данных от CPU до gpu и назад.
Для функции как FFT, существуют O (N, регистрируют N), вычисления и O (N) ссылки памяти, таким образом, NI является O (зарегистрируйте N). Если N будет очень большим, скажите 1,000,000, то это, вероятно, будет быстрее, чтобы сделать это на gpu; Если N будет маленьким, скажите 1,000, то это почти наверняка будет медленнее.
Для уровня 3 BLAS или функции LAPACK как разложение LU матрицы или нахождение ее собственных значений, существуют O (N^3) вычисления и O (N^2) ссылки памяти, таким образом, NI является O (N). Для очень небольших массивов скажите, что N, некоторые выигрывают, это все еще будет быстрее, чтобы сделать на CPU, но как N увеличения, алгоритм очень быстро идет от ограниченного памятью для вычислений ограниченный и увеличение производительности на повышениях gpu очень быстро.
Что-либо включающее комплекс arithemetic имеет больше вычислений, чем скалярная арифметика, которая обычно удваивает NI и увеличивает gpu производительность.
(источник: earthlink.net )
Вот производительность CGEMM - сложное матричное умножение матриц одинарной точности, сделанное на Radeon 4870.
Я записал тривиальные приложения, действительно помогает, можете ли Вы parallize вычисления с плавающей точкой.
я нашел проходящий курс cotaught преподавателем Университета Иллинойса Урбана Шампейн и инженером NVIDIA очень полезным, когда я начинал: http://courses.ece.illinois.edu/ece498/al/Archive/Spring2007/Syllabus.html (включает записи всех лекций).
Я использовал GPGPU для обнаружения движения (Первоначально использующий CG и теперь CUDA) и стабилизация (использующий CUDA) с обработкой изображений. Я добирался о 10-20X ускорении в этих ситуациях.
Из того, что я читал, это довольно типично для параллельных данным алгоритмов.
В то время как у меня еще нет практического опыта с CUDA, я изучал предмет и нашел много бумаг, какой документ положительные результаты с помощью API GPGPU (они все включают CUDA).
Этот бумага описывает, как соединения базы данных могут быть параллелизированы путем создания многих параллельных примитивов (карта, рассеяние, собраться и т.д.), который может быть объединен в эффективный алгоритм.
В этом бумага , параллельная реализация стандарта Шифрования AES создается с сопоставимой скоростью к осторожным аппаратным средствам шифрования.
Наконец, этот бумага исследования, как хорошо CUDA относится ко многим приложениям такой, как структурировано и не структурировано сетки, логика комбинации, динамическое программирование и анализ данных.
Я реализовал вычисление Монте-Карло в CUDA для некоторого финансового использования. Оптимизированный код CUDA о 500x быстрее, чем, ", возможно, попробовал тяжелее, но не действительно" многопоточная реализация ЦП. (Сравнение GeForce 8800GT к Q6600 здесь). Это, хорошо знают, что проблемы Монте-Карло смущающе параллельны все же.
Главные проблемы, с которыми встречаются, включает потерю точности из-за G8x и ограничения микросхемы G9x к числам одинарной точности с плавающей точкой IEEE. С выпуском микросхем GT200 это могло быть смягчено в некоторой степени при помощи единицы двойной точности, за счет некоторой производительности. Я еще не испытал его.
кроме того, так как CUDA является расширением C, интегрирование его в другое приложение может быть нетривиальным.
I have used CUDA for several image processing algorithms. These applications, of course, are very well suited for CUDA (or any GPU processing paradigm).
IMO, there are three typical stages when porting an algorithm to CUDA:
- Initial Porting: Even with a very basic knowledge of CUDA, you can port simple algorithms within a few hours. If you are lucky, you gain a factor of 2 to 10 in performance.
- Trivial Optimizations: This includes using textures for input data and padding of multi-dimensional arrays. If you are experienced, this can be done within a day and might give you another factor of 10 in performance. The resulting code is still readable.
- Hardcore Optimizations: This includes copying data to shared memory to avoid global memory latency, turning the code inside out to reduce the number of used registers, etc. You can spend several weeks with this step, but the performance gain is not really worth it in most cases. After this step, your code will be so obfuscated that nobody understands it (including you).
This is very similar to optimizing a code for CPUs. However, the response of a GPU to performance optimizations is even less predictable than for CPUs.
Да. Я реализовал фильтр нелинейной анизотропной диффузии , используя API CUDA
. Это довольно просто, так как это фильтр, который необходимо запускать параллельно с входным изображением. У меня не было особых трудностей по этому поводу, так как для этого требовалось просто ядро. Ускорение было примерно в 300 раз. Это был мой последний проект по CS. Этот проект можно найти здесь (он написан на португальском thou).
Я тоже пробовал написать алгоритм сегментации Mumford & Shah , но писать об этом было сложно, так как CUDA все еще в начале, и поэтому происходит много странных вещей. Я даже заметил улучшение производительности, добавив if (false) {} в код O_O.
Результаты для этого алгоритма сегментации не были хорошими. У меня была 20-кратная потеря производительности по сравнению с подходом с ЦП (однако, поскольку это ЦП, можно использовать другой подход, который дал те же результаты). Работа над ней все еще продолжается, но, к сожалению, я покинул лабораторию, над которой работал, поэтому, возможно, когда-нибудь я смогу ее закончить.
Я реализовал генетический алгоритм на графическом процессоре и получил ускорение примерно в 7 раз. Как заметил кто-то другой, возможен больший выигрыш с более высокой числовой интенсивностью. Так что да, выгода есть, если приложение правильное
Я реализовал факторизацию Холецкого для решения больших линейных уравнений на GPU с помощью ATI Stream SDK. По моим наблюдениям
Получено увеличение производительности до 10 раз.
Работа над той же проблемой, чтобы еще больше оптимизировать ее, масштабируя ее на несколько графических процессоров.