Только раньше взять да и попробовать технологию(я про DP и H-Q) на обычном десктопе раньше можно было, а теперь нет
Увы, так было только до Fermi. В СС 2 появилось прямое копирование DeviceToDevice внутри машины без задействования CPU. Такой вот DMA по утверждению nVidia требует ECC, который только на Tesla присутствует. Вот и получилось — на Tesla фича есть, а на GTX — нет.
Да, картинка меня тоже заставила задуматься, но фраза о независимых инструкциях натолкнула именно на такую мысль.
Обидно, если это действительно лишь ILP, хотя это резонно предположить из-за того, что работу по распараллеливанию можно сделать ещё на этапе компиляции.
__syncthreads действует только для потоков в одном блоке и нужна для синхронизации потоков при доступе к shared mem.
С СС 2.0 появилась ещё __threadfence_system, которая действует на все потоки в grid'е. А до этого да, только новое ядро и можно было запускать.
GK110 обещают ближе к концу года. А что до стоимости, то такие решения никогда не стоили дёшево. Основной упор на то, что ты получаешь мощную железяку, которая работает быстро, надёжно, кушает мало, её можно подоткнуть к какому-нибудь лезвию и использовать 24/7. Из всего этого у GTX есть только скорость. Ну и подключить её тоже можно. Поэтому она и стоит дешевле. Не энтерпрайз и не продакшн уровень.
Что до OpenCL – тут могу только мышек с кактусами вспомнить. Стандарт он на то и стандарт чтобы развиваться медленно. С таким отставанием от текущего развития CUDA я запросто согласен на vendor-lock. Тем более у AMD всё равно нет аналогов Tesla. Возможность программировать на CPU также неудобно как на GPU считаю верхом непрактичности. Слышал ещё про x86-CUDA, которая позволяет использовать CPU как графический расчётный модуль. Но зачем? Другая архитектура, другие принципы оптимизации, всё совсем другое. Люди не используют CUDA, если на то нет большой нужды. Если нет подходящей под эту архитектуру задачи.
На 1 MP в SMX приходится 192 SP. То есть до 6 варпов. Планировщиков 4 и каждый может запускать по 2 инструкции одновременно. На 1 SMX может быть до 16 блоков (если они не используют много регистров и shared памяти) и до 64 варпов. При заполнении 1 block/SMX загрузка практически никогда не будет полной по одной простой причине: если идёт чтение из памяти, то варп засыпает и ждёт пока не придёт результат. Варпы одного блока бегут «близко» друг к другу и поэтому висят и ждут ответа одновременно. Поэтому нужно загружать SMX сразу несколькими блоками, чтобы эту latency покрыть и пока одни висят, другие дробят числа.
Я не знаю точно, какая задача запускалась и возможно она просто имела много операций с double и как в этих задачах поведёт себя 680 я сказать не могу. Всегда считаю только в int и float.
И ещё, 16К потоков для CUDA это как-то несерьёзно. Это же fine-grained параллелизм, в идеале каждый thread должен обрабатывать одну единицу информации.
Связь очень простая. Раньше (в до-Fermi время), действительно на 1 MP запускался 1 warp. Если быть ещё точнее, то сначала выполнялись первый полуварп, а потом второй. Сейчас на одном MP есть несколько планировщиков потоков и они запускают одновременно несколько варпов (до 4), возможно даже из нескольких блоков.
Тут явно просится повторная оптимизация. Увеличение FLOPS/Вт произошло не на пустом месте. Кроме перехода на техпроцесс 28 нм, была существенно снижена частота потоковых процессоров. Раньше они работали на удвоенной частоте, а теперь используют обычную частоту ядра. Роста FLOPSов добились увеличением количества процессоров. Если посмотреть, то количество процессоров утроилось, частота ядра выросла ещё в полтора раза по сравнению с Fermi. А вот FLOPSы только удвоились (хотя должны были увеличиться в 4,5 раза).
Поэтому сами процессоры стали ещё медленней и фокус оптимизации должен быть смещён на максимальную загрузку всех 1536 SP в GPU. Возможно в задаче создаётся слишком мало блоков? Или блоки слишком тяжеловесные (используют много регистров на поток). Тогда их будет помещаться меньше на SMX. Для Kepler во многих задачах регистров нужно использовать меньше, а больше уповать на кэширование и использование read only кэша.
Короче, при всех новых фишках – для HPC по-прежнему нужно хорошо знать подноготную архитектуры, которая с каждым годом становится всё более развесистой. Без этого использовать CUDA на всю катушку не получится.
Думаю про это уже писали и не раз… Если для старых iPod'ов протокол среверсили и сделали программы для синхронизации под все платформы, то iOS – тёмный лес.
Реакция будет только в одном случае – если пользователей Linux на десктопах будет хоть сколько нибудь значимое количество. А пока – либо виртуалка, либо может быть wine (не знаю, насколько это возможно)
С iPad я давно обхожусь без iTunes и даже без компа. Правда в плане видео – только благодаря NAS Synology и его возможности скачивать торренты. Хотя видео можно смотреть онлайн (youtube + vk).
Для книг – iBooks (художка) + Amazon Kindle (купленные и на английском) + GoodReader (PDF с возможностью кропа, быстрой прорисовкой и прочими плюшками) + Stanza (DjVu).
Для видео – AVPlayer, OPlayer, AirPlayer (DLNA в Synology).
Музыку не слушаю. Только иногда дома можно включить DS Audio и постримать с NAS.
Короче, к компу уже давно планшет не подключал.
Честно говоря, вообще не сталкивался с такой проблемой. Храню пароли в 1password и оттуда уже копирую в браузер. Или использую встроенный браузер 1password, который сам введёт логин/пароль когда нужно.
+ генерируются сильные пароли
+ синхронизация между всеми устройствами (через дропбокс, например)
+ плагины к браузерам для автоматического заполнения паролей на компьютере (ну, к iOS это уже не относится, но для меня это было просто очень круто).
Короче, 1Password искренне советую для устранения головных болей с паролями.
Минус только один – нет версии для Linux. Для OS X, Win, Android и iOS – версии есть.
Была та же история со Stanza. Она потом обновилась и снова заработала. Правда по отзывам она теперь работает только на iOS 5).
DjVu читаю только в ней.
Увы, так было только до Fermi. В СС 2 появилось прямое копирование DeviceToDevice внутри машины без задействования CPU. Такой вот DMA по утверждению nVidia требует ECC, который только на Tesla присутствует. Вот и получилось — на Tesla фича есть, а на GTX — нет.
Обидно, если это действительно лишь ILP, хотя это резонно предположить из-за того, что работу по распараллеливанию можно сделать ещё на этапе компиляции.
__syncthreadsдействует только для потоков в одном блоке и нужна для синхронизации потоков при доступе к shared mem.С СС 2.0 появилась ещё
__threadfence_system, которая действует на все потоки в grid'е. А до этого да, только новое ядро и можно было запускать.Впрочем, это не исключает и instruction-level parallelism.
Что до OpenCL – тут могу только мышек с кактусами вспомнить. Стандарт он на то и стандарт чтобы развиваться медленно. С таким отставанием от текущего развития CUDA я запросто согласен на vendor-lock. Тем более у AMD всё равно нет аналогов Tesla. Возможность программировать на CPU также неудобно как на GPU считаю верхом непрактичности. Слышал ещё про x86-CUDA, которая позволяет использовать CPU как графический расчётный модуль. Но зачем? Другая архитектура, другие принципы оптимизации, всё совсем другое. Люди не используют CUDA, если на то нет большой нужды. Если нет подходящей под эту архитектуру задачи.
Я не знаю точно, какая задача запускалась и возможно она просто имела много операций с double и как в этих задачах поведёт себя 680 я сказать не могу. Всегда считаю только в int и float.
И ещё, 16К потоков для CUDA это как-то несерьёзно. Это же fine-grained параллелизм, в идеале каждый thread должен обрабатывать одну единицу информации.
Поэтому сами процессоры стали ещё медленней и фокус оптимизации должен быть смещён на максимальную загрузку всех 1536 SP в GPU. Возможно в задаче создаётся слишком мало блоков? Или блоки слишком тяжеловесные (используют много регистров на поток). Тогда их будет помещаться меньше на SMX. Для Kepler во многих задачах регистров нужно использовать меньше, а больше уповать на кэширование и использование read only кэша.
Короче, при всех новых фишках – для HPC по-прежнему нужно хорошо знать подноготную архитектуры, которая с каждым годом становится всё более развесистой. Без этого использовать CUDA на всю катушку не получится.
Реакция будет только в одном случае – если пользователей Linux на десктопах будет хоть сколько нибудь значимое количество. А пока – либо виртуалка, либо может быть wine (не знаю, насколько это возможно)
Для книг – iBooks (художка) + Amazon Kindle (купленные и на английском) + GoodReader (PDF с возможностью кропа, быстрой прорисовкой и прочими плюшками) + Stanza (DjVu).
Для видео – AVPlayer, OPlayer, AirPlayer (DLNA в Synology).
Музыку не слушаю. Только иногда дома можно включить DS Audio и постримать с NAS.
Короче, к компу уже давно планшет не подключал.
+ генерируются сильные пароли
+ синхронизация между всеми устройствами (через дропбокс, например)
+ плагины к браузерам для автоматического заполнения паролей на компьютере (ну, к iOS это уже не относится, но для меня это было просто очень круто).
Короче, 1Password искренне советую для устранения головных болей с паролями.
Минус только один – нет версии для Linux. Для OS X, Win, Android и iOS – версии есть.
DjVu читаю только в ней.