не совсем так. если составить тело из таких же частиц, то частицы будут естественным образом обрабатываться за один проход как частица-частица взаимодействия, останется только собрать физику мягкого тела на spring-mass-damper связях между частицами, и, чтобы достичь более менее интересных характеристик упругости, обязательно не забыть именно про damper составляющую (иначе будет кипеть при попытке перехода от мягкого к упругому), плюс на один шаг симуляции взаимодействий частиц делать несколько шагов симуляции передачи импульса между частицами по связям
я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»
в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:
демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц
плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)
если говорить чисто об SPH, без образования временных валентных связей, то 1млн+ частиц c «сеткой соседей» в 60 FPS можно считать на GTX 780, если на CUDA, с построением динамической сетки по примеру стандартной демки
только нужно обязательно переходить на VBO (избегать копирования данных на хост и обратно) и заменять fast_radix_sort в построении сетки на inclusive_scan (лучшая научная работа по теме оптимизации регулярных сеток для SPH-подобных симуляций:
(тормозная за счёт того, что он с реализацией напутал, но конкретно его идея замены fast-radix-sort'а inclusive_scan'ом — шикарна, x10 прирост производительности построения сетки)
на GTX 1080 — я ожидаю возможным 2-2.5млн+ частиц при максимально эффективной известной мне реализации
200-500 сотен тысяч частиц в чистом виде можно считать даже на GTX 580
Сейчас мы делаем ставку на качественный перенос специализированных страниц и новостей, так как они есть на большинстве бизнес-сайтов.
Специализированные страницы переносятся в uKit как страницы, собираемые из виджетов и блоков, новости, если они успешно распознаны — идут в блог (у uKit есть специальный тип страниц — блог/новости).
В случае галереи и каталога, зависит от того, насколько они объёмны. При небольшом количестве изображений формируется стандартная страница на основе виджета «галерея»/«прайс»/«каталог», если контента много, будет формироваться множество страниц с разделами (если удастся эффективно синтезировать подструктуры).
Возможно, будем фильтровать изображения галереи, рекомендуя не использовать избыточную информацию:
В целом, система должна из «конвертера» постепенно эволюционировать в экспертно-рекомендательное решение, способное не только выполнить конвертацию, но и объяснить пользователю, что и почему на его сайте не стоит переносить «как было», и действовать исходя из решений, который пользователь примет уже в процессе обработки его сайта. Но это следующий шаг.
Форум штука специфическая, и на текущем этапе мы не ставим себе цели переносить форумы, как минимум по причинам необходимости переноса авторизационной информации участников форума, что невозможно сделать извне. Однако, возможно использование информации со страниц форума для дополнительных эвристик по тематике сайта.
Возможно, не понял вопрос. Под «блоком» имеется ввиду не один конкретный элемент DOM, а множество элементов, которые не входят во множество элементов, геометрически и структурно встречающееся на всех остальных страницах сайта с небольшими отклонениями.
Условно, большинство сайтов формируют страницу как «дизайн» + контент. Чтобы выделить контент, мы идём от обратного — ищем всё, что общее на всех страницах (часто кроме главной), после чего всё что остаётся — считаем контентом
> Кроме того, сейчас мы научились делать то, что умеют делать и продвинутые нейронные сети
если не секрет, производительность при моделировании на GPU при решении практических задач, скажем, распознавания образов существующими свёрточными нейросетями, оказывается на порядки ниже, примерно равной, или на порядки выше? (по расходу памяти и скорости работы/обучения)
насколько я понимаю, голографическая модель даст взрывной эффект экономии ресурсов на высоком уровне абстракции, потому что там «почти будет решаться NP-задача голографическими сайд-эффектами», но конкурировать по производительности с существующими нейросетевыми моделями эта штука не сможет, так как очень дорогая для моделирования на существующем железе. верно?
голографический принцип в организации сознания, по всей видимости, имеет место быть, и Вы, похоже, разобрались
а) как он «виртуализирован» на биологической основе
б) как свойства этого «голографического эфира» порождают осознание
«виртуализирован», потому что сам голографический принцип функционирования сознания, возможно, существует и за пределами биологического мозга, если предположить, что весь материальный мир происходит как «сон-симуляция» в некотором сверхпространстве осознания высшего порядка и Вселенная обладает самоосознанием.
Тогда биологический мозг интересен в первую очередь именно как способ создать фрактальную рекурсию, проекцию давно известного принципа о том, что пространство, обладающее определёнными свойствами клеточного автомата для протекания в нём голографических волновых-интерференционных процессов, будет порождать процессы самоосознания. И весь вопрос тогда будет в том, как «локальный кусочек такого пространства» виртуализировать в теле организма на органической основе. Похоже на попытку сделать компьютер внутри компьютера из кубиков Minecraft
Под исходным глобальным пространством («океаном голографического осознания») я предполагаю клеточный автомат квантовой структуры физического континуума (отсылка к идее «голографической Вселенной»)
Очевидно, сейчас будет эксперимент по сбору минусов, но если кого из здешних читателей реально интересует относительно продвинутая точка зрения на то, «в какой момент эмбрион получает душу», рекомендую работы визионера Alex Grey
непосредственно момент получения души эмбрионом (промотать страницу чуть ниже):
ещё более захватывающее продолжение фантазии о цензурируемых и внушаемых мыслях жителям матричного мегаполиса будущего, можно прочесть в предпоследней книге Пелевина "Любовь к трём Цукербринам".
Существует официальная формулировка, почему некоторые редкие книги всё же нельзя копировать? Грубо говоря, это вопрос секретности или вопрос сохранности?
я пока не готов распространять информацию по проекту в кругу людей, с которыми я не знаком лично хотя бы заочно. будет очень жаль, если кто-то возьмёт относительно примитивную по объёму и качеству часть уже достигнутых результатов, и выложит на всеобщее обозрение.
у меня есть представление о той планке качества, начиная от которой я готов буду показать результаты многолетнего развития проекта сообществу. надеюсь, это произойдёт в течение ближайших 1-2 лет.
говоря короче, я считаю, что ранняя публичность в любой форме может негативно сказаться на судьбе проекта в целом.
«Голографичность» кодирования информации — это следующая ступень развития, позволяющая упаковать максимум информации в разреженных представлениях.
Я думаю, начинать с этой концепции плохо, и вот почему:
Экспериментируя с тем же HTM Джеффа Хокинса (мы перевели модель на GPU и пытались добиться проявления поведенческих паттернов, т.е. животного уровня самоосознания — с тем чтобы применить HTM для контроля виртуальных персонажей), мы пришли к выводу, что «голографичность» крайне усложняет постановку сложных экспериментов, когда автоассоциативную темпорально-пространственную иерархическую модель пытаешься заставить решать какие-то задачи (скажем, смоделировать центр удовольствия).
Хорошим вариантом видится реализация идей, изложенных в книге «об интеллекте», сначала в представлении, где каждый нейрон и контексты имеют одиночные специализированные представления (конечно, это приведёт к снижению производительности и большому потреблению памяти, но сеть станет более прозрачной для исследователя), а затем, когда сеть начнёт проявлять необходимые свойства — произвести что-то вроде её «голографической свёртки», заменив специализированные нейроны на разреженные голографические представления. Это, конечно, не факт что будет легко и всегда возможно, но HTM (и, я думаю, другие сети с разреженным представлением данных) слишком чёрный ящик для экспериментов, особенно любительских.
p.s. насколько я помню, после написания книги «Об интеллекте», Джефф Хокинс реализовал именно сеть без разреженного кодирования информации, но столкнулся с колоссальными объёмами оперативной памяти, необходимой для реализации его концепций — и это, как я понимаю, стало толчком к созданию HTM)
Я также интересуюсь созданием нейросетей с динамическим образованием нейронов (считаю, что основное преимущество, которое цифровые модели имеют перед биологическими — это то, что цена создания новой ноды (нейрона) в графе — сравнима с ценой передачи нервного импульса. Мозг себе такого в физической реализации позволить не может, только создаёт новые синапсы, и то очень медленно по сравнению со скоростью передачи информации. Я думаю в этой области для цифровых моделей — огромный потенциал)
существует похожая opensource разработка N.A.R.S., рекомендую познакомиться как минимум с визуалом. NARS тестируется на задачах эвристической имитации поведения игровыми персонажами в играх уровня 8 битных приставок (понять правила игры и успешно её проходить, хороший тест для «действующего» ИИ)
>Площадка является веб-приложением Chrome (Chrome Experiment), использующая WebGL, чтобы имитировать до 22 кубитов на GPU.
Интересно, каким образом WebGL используется для ускорения вычислений?
— либо там ещё и WebCL
— либо там для вычислений используется графическая метафора (т.е. рисуем картинку, а затем исходя из того, как картинка выглядит — понимаем каков результат наших вычислений)
— либо я чего-то не знаю о WebGL
Честно говоря, не знаю. Я делюсь своим практическим опытом. В версию с автоперемещением данных в L1 кеш готов верить.
>но инструкторы все-таки советовали перемещать данные в shared memory
Думаю, доля смысла в этом есть. но очень важно не спугнуть новичков всеми этими наворотами!
Я до сих пор не видел хорошей статьи, в которой главным образом утверждалась бы аксиома «не бойтесь и пробуйте решать ваши реальный задачи в лоб без вникания в моменты тонкой оптимизации! на современных устройствах оптимизации перестали быть критически значимыми». сразу начинают нагонять страху кучей моментов, которые якобы должен удерживать в голове GPGPU программист. А в результате — community чуть менее чем никакое, приток новичков плохой, GPGPU развивается в разы медленнее, чем мог бы.
когда я 3 года назад входил «в тему», мне понадобилось много самурайского духа, чтобы сначала решиться и вкурить все эти особенности архитектуры GPGPU, а затем ещё столько же, чтобы осознать, что все эти фичи в 95% случаев не критичны и в первую очередь нужно просто решиться писать GPGPU код, простой и прямой как молоток. и всё будет хорошо работать.
не берусь оценивать, я бы посоветовал провести эксперимент и сравнить результаты.
здесь слишком простой код, и то, что в моих «реальных» задачах даёт размытую на общем фоне оптимизацию в 2-3%, здесь легко может давать 20-30% и больше.
это, кстати, одна из ловушек: вы пишите примитивный тестовый код, он с применением тонкой оптимизации даёт вам выигрыш в 30-50%, вы усложняете код и продолжаете поддерживать общую идею тонкой оптимизации, удерживая в голове её «стоимость» в 30-50%. но эффект уже давно мог быть размыт и в реальной ситуации составлять менее 2-3%, а для вас любое изменение алгоритма — всё ещё будет обозначать тотальную концентрацию и кучу оптимизационных экспериментов.
у меня есть сложная симуляция (развитие вот этого начинания: habrahabr.ru/post/153169/), код которой расширялся и менялся десятки раз, и я множество раз проводил повторные оптимизации.
за это время я выделил для себя такие принципы:
— не стоит переоценивать теоретическую предсказуемость изменений производительности при изменениях кода. если есть 2-3 решения и хочется хороший результат — лучше реализовать их все и промерять, результаты часто оказываются очень неожиданными в силу того, что архитектура современных GPGPU очень нелинейной стала, как и поведение nvcc.
например, добавил float4 в структуру в которой их уже 8, и получил -30% производительности, хотя до этого пару раз добавлял без всякого оверхеда. значит, вылез за пределы какого-то кеша на своих данных, или количества регистров
— в итоге, ни один реальный алгоритм мне не удалось оптимизировать с использованием sharedMemory или __syncthreads. эти фокусы работают только на очень простых данных, либо на очень старых устройствах.
— разделять данные { float3 xyz; float3 fxfyfz } на два отдельных вектора — бывает полезно попробовтаь
— не стоит бояться atomic float'ов, часто они работают быстрее варианта с денормализованными данными (сгенерировать много данных для более простого пробега по ним бывает менее оптимально, несмотря на WARP блокировки — видимо, в силу того, что более компактные структуры данных лучше кешируются).
— эксперименты с параметрами CUDA компилятора часто приводят к очень интересным результатам: CC 1.x на простых симуляциях был сильно быстрее чем CC 2.0, но CC 1.x не умел atomicFloat'ы. зато CC 3.x можно заставить одновременно использовать atomicFloat'ы и генерировать менее прецезионный код ключиками "--use_fast_math –Xptxas –v,–abi=no". обещают эту фичу выпилить (там не по самым строгим стандартам считаются float'ы), но 180-250% прозиводительности заставляют меня до последнего генерировать не до конца ГОСТ, зато быстрый код.
>У нас проблема другая, девайсы с двойной точностью от нвидиа становятся с совсем невменяемой ценой(хорошо что есть пока titan). А карты amd с их новой GCN1.1 работают медленнее старых 7970 и 280Х, не смотря на большее кол-во ядер.
я тоже запасся двумя GTX Titan, однако, до пользы от применения двойной точности у меня ещё ни разу не дошло. греет душу, что если понадобится — есть на чём посчитать :-)
>Да и устройства с opencl 2.0 я увидел реально сосвсем недавно, кажись как вышел amd драйвер омега или как его там. До этого всегда было 1.2 или даже 1.1 на нвидиа.
Жесть конечно. Начинаю понимать, почему convnet и много других интересных вещей сходу пишутся под nivida. жить без atomic float'ов в XXI веке — это знатное извращенство.
при условии, что количество резинок, связанных с одной силовой точкой, может быть произвольным, и на каждом шаге симуляции нужно «повлиять» на каждую силовую точку вектором силы каждой растянутой «резинки», связанной с силовой точкой — стандартный способ избежать atomic float'ов, когда kernel совершает проход по множеству точек, и каждая точка неконкурентно аккумулирует вектора сил всех связанных с ней резинок — не подходит (количество резинок у каждой силовой точки значительно отличается, что будет запирать синхронные WARPы. к тому же, необходимо будет использовать динамические списки резинок — т.е. гораздо более сложный код менеджмента модели).
при наличии atomic float'ов — мы просто совершаем пробег по множеству резинок, каждая из которых добавляет свой вектор силы к обоем силовым точкам, к которым привязана (через atomicAdd float). т.к. две резинки могут одновременно попытаться добавить свой вектор силы к одной и той же силовой точке, без atomic float'ов такой подход не работает.
приятно то, что atomic float'ы в современных nvidia картах настолько производительно реализованы, что в большинстве случаев попытки обойти их использование более хитрым и производительным алгоритмом приведут к уменьшению производительности.
т.е. при желании решать реальные задачи, а не фигурно извращаться с архитектурой GPGPU — atomic float'ы + CUDA + современные nvidia GPU (и чем дальше, тем лучше с этим) позволяют просто писать SIMD код в лоб, при этом имея производительность на грани теоретического максимума.
— это наиболее простой и понятный пример применения atomic float'ов.
в моей практике была куча ситуаций, когда происходило такое распараллеленное аккумулирование векторов сил на силовые точки. во всех случаях сначала писался код в лоб с atomicAdd (т.к. это по сути мнемонический эквивалент предполагаемой операции всегда)
Затем в некоторых случаях производились попытки оптимизировать это, «вывернув» структуры данных под то, чтобы каждая силовая точка становилась аккумулятором для списка внешних воздействий. это всегда усложняло код (денормализация данных под каждый конкретный kernel), но, как ни странно — в большинстве случаев не только не увеличивало производительность, а, наоборот, уменьшало её (я для себя пришёл к выводу, что денормализованные данные занимают большое количество памяти, что приводит к резкому уменьшению эффективности работы кешей).
Таким образом, здравый смысл и добро восторжествовали, и сегодня в CUDA + NVidia окружении простой код в большинстве случаев работает наиболее эффективно, и «камень с души» о непроизведённой тонкой оптимизации оказывается снят в общем случае. Atomic float'ы рулят!
p.s. субьективно — начиная с GTX 4 серии (т.е. с того момента, как в CC 2.0 практически сошла на нет необходимость возни c global memory coalescing) смысла в попытках обеспечить когерентность чтений, использовать shared memory в кернелах, использовать хитрые алгоритмы с синхронизациями и прочий ловлевел hardcore — канули в лета, и я очень рад, что это так.
для примера: я очень плотно занимался поиском оптимального алгоритма для SPH симуляций. в CUDA samples с давних времён был включен классический пример «particles», в котором ещё остались оптимизации под СС 1.2 (GTX 2 серии и раньше, когда CUDA только зарождался). но все эти ухищрения только мешали раскрыться потенциалу GTX 7 серии (я экспериментировал на GTX Titan).
в итоге, оптимальной оказалась практика, предложенная Rama Hoetzlein (он же провёл очень хороший обзор эволюции решений этой задачи здесь: on-demand.gputechconf.com/gtc/2014/presentations/S4117-fast-fixed-radius-nearest-neighbor-gpu.pdf). К сожалению, его собственное решение fluids3.com/ содержит несколько эммм досадных недоразумений в коде, в результате чего его код из коробки выполняется медленнее, чем «particle» демка из cuda samples. Но сделанный мной гибрид обоих решений сумел быть существенно более производительным, чем оба исходных варианта.
Это я всё к чему. Итоговый код не содержит никаких низкоуровневых фокусов с __syncthreads, sharedMem, разделений структур на отдельные вектора с денормализацией и сортировкой по ключам, хитрых fastRadixSort; и при этом выполняется в разы быстрее на современных Nvidia GPU.
Поэтому, если вы видите применение низкоуровневых фич CUDA, настоятельно рекомендую убедиться в том, что автор — не писал это «по книжкам» под допотопные устройства году эдак в 2009-2010 и/или не является нанотехнологически-академическим теоретиком из серии произвели исследование на миллион и выяснили «на GTX 9800 мой код даёт x10 ускорение». Велика вероятность, что на GTX 780 он будет выполняться в лучшем случае с той же скоростью, а то и медленнее решения в лоб на тех же пресловутых atomic float'ах. И здесь по опыту — очень легко попасть в ловушку устаревших мировоззрений сумрачного гения, потратить кучу времени, заморочить голову и в итоге так и не получить оптимального кода под свою задачу.
На этом всё. Извините, накипело. Надеюсь, мой опыт кому-то будет полезен.
я это всё проверял на примере своих движков и это хорошо работает в комбинациях «много тел составленных из частиц и связей» взаимодействуют «с большими количествами автономных частиц, также взаимодействующих друг с другом»
в 2015 году nVidia реализовала в готовом виде трёхмерный аналог:
Nvidia FLEX
демо можно скачать поставить и убедиться в том, что это в реалтайме шикарно работает. они делают именно это — все полигональные тела «растеризуют» в воксельные сетки, соединённые «пружинами», чтобы тела своей «примерной формой» быстро и эффективно могли взаимодействовать друг с другом и со свободными облаками частиц
плюс повреждения и разные характеристики прочностей = именно то, что нужно (деформируемая броня для танка / любых других объектов с переменными прочностными и упргостными характеристиками)
CUDA Samples / Particles
только нужно обязательно переходить на VBO (избегать копирования данных на хост и обратно) и заменять fast_radix_sort в построении сетки на inclusive_scan (лучшая научная работа по теме оптимизации регулярных сеток для SPH-подобных симуляций:
FAST FIXED-RADIUS NEAREST NEIGHBORS:
INTERACTIVE MILLION-PARTICLE FLUIDS
имплементация от автора:
fluids_v3
(тормозная за счёт того, что он с реализацией напутал, но конкретно его идея замены fast-radix-sort'а inclusive_scan'ом — шикарна, x10 прирост производительности построения сетки)
на GTX 1080 — я ожидаю возможным 2-2.5млн+ частиц при максимально эффективной известной мне реализации
200-500 сотен тысяч частиц в чистом виде можно считать даже на GTX 580
в живую в браузере
Специализированные страницы переносятся в uKit как страницы, собираемые из виджетов и блоков, новости, если они успешно распознаны — идут в блог (у uKit есть специальный тип страниц — блог/новости).
В случае галереи и каталога, зависит от того, насколько они объёмны. При небольшом количестве изображений формируется стандартная страница на основе виджета «галерея»/«прайс»/«каталог», если контента много, будет формироваться множество страниц с разделами (если удастся эффективно синтезировать подструктуры).
Возможно, будем фильтровать изображения галереи, рекомендуя не использовать избыточную информацию:
В целом, система должна из «конвертера» постепенно эволюционировать в экспертно-рекомендательное решение, способное не только выполнить конвертацию, но и объяснить пользователю, что и почему на его сайте не стоит переносить «как было», и действовать исходя из решений, который пользователь примет уже в процессе обработки его сайта. Но это следующий шаг.
Форум штука специфическая, и на текущем этапе мы не ставим себе цели переносить форумы, как минимум по причинам необходимости переноса авторизационной информации участников форума, что невозможно сделать извне. Однако, возможно использование информации со страниц форума для дополнительных эвристик по тематике сайта.
Условно, большинство сайтов формируют страницу как «дизайн» + контент. Чтобы выделить контент, мы идём от обратного — ищем всё, что общее на всех страницах (часто кроме главной), после чего всё что остаётся — считаем контентом
если не секрет, производительность при моделировании на GPU при решении практических задач, скажем, распознавания образов существующими свёрточными нейросетями, оказывается на порядки ниже, примерно равной, или на порядки выше? (по расходу памяти и скорости работы/обучения)
насколько я понимаю, голографическая модель даст взрывной эффект экономии ресурсов на высоком уровне абстракции, потому что там «почти будет решаться NP-задача голографическими сайд-эффектами», но конкурировать по производительности с существующими нейросетевыми моделями эта штука не сможет, так как очень дорогая для моделирования на существующем железе. верно?
голографический принцип в организации сознания, по всей видимости, имеет место быть, и Вы, похоже, разобрались
а) как он «виртуализирован» на биологической основе
б) как свойства этого «голографического эфира» порождают осознание
«виртуализирован», потому что сам голографический принцип функционирования сознания, возможно, существует и за пределами биологического мозга, если предположить, что весь материальный мир происходит как «сон-симуляция» в некотором сверхпространстве осознания высшего порядка и Вселенная обладает самоосознанием.
Тогда биологический мозг интересен в первую очередь именно как способ создать фрактальную рекурсию, проекцию давно известного принципа о том, что пространство, обладающее определёнными свойствами клеточного автомата для протекания в нём голографических волновых-интерференционных процессов, будет порождать процессы самоосознания. И весь вопрос тогда будет в том, как «локальный кусочек такого пространства» виртуализировать в теле организма на органической основе. Похоже на попытку сделать компьютер внутри компьютера из кубиков Minecraft
Под исходным глобальным пространством («океаном голографического осознания») я предполагаю клеточный автомат квантовой структуры физического континуума (отсылка к идее «голографической Вселенной»)
Если не секрет, код на видеокарте — CUDA или OpenCL?
Чистый C++ или из под какого-то другого языка и/или GPGPU фреймворка?
непосредственно момент получения души эмбрионом (промотать страницу чуть ниже):
http://alexgrey.com/art/paintings/soul/buddha-embryo/
общий процесс пермутаций души, включая состояния в течение биологической инкарнации, бардо («после смерти») и сверхсознания (состояния «Я есть Бог»):
http://alexgrey.com/art/paintings/soul/
p.s. представления близки к буддийским, но не каноничны
у меня есть представление о той планке качества, начиная от которой я готов буду показать результаты многолетнего развития проекта сообществу. надеюсь, это произойдёт в течение ближайших 1-2 лет.
говоря короче, я считаю, что ранняя публичность в любой форме может негативно сказаться на судьбе проекта в целом.
Я думаю, начинать с этой концепции плохо, и вот почему:
Экспериментируя с тем же HTM Джеффа Хокинса (мы перевели модель на GPU и пытались добиться проявления поведенческих паттернов, т.е. животного уровня самоосознания — с тем чтобы применить HTM для контроля виртуальных персонажей), мы пришли к выводу, что «голографичность» крайне усложняет постановку сложных экспериментов, когда автоассоциативную темпорально-пространственную иерархическую модель пытаешься заставить решать какие-то задачи (скажем, смоделировать центр удовольствия).
Хорошим вариантом видится реализация идей, изложенных в книге «об интеллекте», сначала в представлении, где каждый нейрон и контексты имеют одиночные специализированные представления (конечно, это приведёт к снижению производительности и большому потреблению памяти, но сеть станет более прозрачной для исследователя), а затем, когда сеть начнёт проявлять необходимые свойства — произвести что-то вроде её «голографической свёртки», заменив специализированные нейроны на разреженные голографические представления. Это, конечно, не факт что будет легко и всегда возможно, но HTM (и, я думаю, другие сети с разреженным представлением данных) слишком чёрный ящик для экспериментов, особенно любительских.
p.s. насколько я помню, после написания книги «Об интеллекте», Джефф Хокинс реализовал именно сеть без разреженного кодирования информации, но столкнулся с колоссальными объёмами оперативной памяти, необходимой для реализации его концепций — и это, как я понимаю, стало толчком к созданию HTM)
en.wikipedia.org/wiki/Hierarchical_temporal_memory
Я также интересуюсь созданием нейросетей с динамическим образованием нейронов (считаю, что основное преимущество, которое цифровые модели имеют перед биологическими — это то, что цена создания новой ноды (нейрона) в графе — сравнима с ценой передачи нервного импульса. Мозг себе такого в физической реализации позволить не может, только создаёт новые синапсы, и то очень медленно по сравнению со скоростью передачи информации. Я думаю в этой области для цифровых моделей — огромный потенциал)
существует похожая opensource разработка N.A.R.S., рекомендую познакомиться как минимум с визуалом. NARS тестируется на задачах эвристической имитации поведения игровыми персонажами в играх уровня 8 битных приставок (понять правила игры и успешно её проходить, хороший тест для «действующего» ИИ)
youtu.be/pdaUNX7iKlQ?t=6m10s
github.com/opennars/opennars/wiki
sites.google.com/site/narswang/home
Интересно, каким образом WebGL используется для ускорения вычислений?
— либо там ещё и WebCL
— либо там для вычислений используется графическая метафора (т.е. рисуем картинку, а затем исходя из того, как картинка выглядит — понимаем каков результат наших вычислений)
— либо я чего-то не знаю о WebGL
знающие люди, прокомментируйте, пожалуйста
>но инструкторы все-таки советовали перемещать данные в shared memory
Думаю, доля смысла в этом есть. но очень важно не спугнуть новичков всеми этими наворотами!
Я до сих пор не видел хорошей статьи, в которой главным образом утверждалась бы аксиома «не бойтесь и пробуйте решать ваши реальный задачи в лоб без вникания в моменты тонкой оптимизации! на современных устройствах оптимизации перестали быть критически значимыми». сразу начинают нагонять страху кучей моментов, которые якобы должен удерживать в голове GPGPU программист. А в результате — community чуть менее чем никакое, приток новичков плохой, GPGPU развивается в разы медленнее, чем мог бы.
когда я 3 года назад входил «в тему», мне понадобилось много самурайского духа, чтобы сначала решиться и вкурить все эти особенности архитектуры GPGPU, а затем ещё столько же, чтобы осознать, что все эти фичи в 95% случаев не критичны и в первую очередь нужно просто решиться писать GPGPU код, простой и прямой как молоток. и всё будет хорошо работать.
здесь слишком простой код, и то, что в моих «реальных» задачах даёт размытую на общем фоне оптимизацию в 2-3%, здесь легко может давать 20-30% и больше.
это, кстати, одна из ловушек: вы пишите примитивный тестовый код, он с применением тонкой оптимизации даёт вам выигрыш в 30-50%, вы усложняете код и продолжаете поддерживать общую идею тонкой оптимизации, удерживая в голове её «стоимость» в 30-50%. но эффект уже давно мог быть размыт и в реальной ситуации составлять менее 2-3%, а для вас любое изменение алгоритма — всё ещё будет обозначать тотальную концентрацию и кучу оптимизационных экспериментов.
у меня есть сложная симуляция (развитие вот этого начинания: habrahabr.ru/post/153169/), код которой расширялся и менялся десятки раз, и я множество раз проводил повторные оптимизации.
за это время я выделил для себя такие принципы:
— не стоит переоценивать теоретическую предсказуемость изменений производительности при изменениях кода. если есть 2-3 решения и хочется хороший результат — лучше реализовать их все и промерять, результаты часто оказываются очень неожиданными в силу того, что архитектура современных GPGPU очень нелинейной стала, как и поведение nvcc.
например, добавил float4 в структуру в которой их уже 8, и получил -30% производительности, хотя до этого пару раз добавлял без всякого оверхеда. значит, вылез за пределы какого-то кеша на своих данных, или количества регистров
— в итоге, ни один реальный алгоритм мне не удалось оптимизировать с использованием sharedMemory или __syncthreads. эти фокусы работают только на очень простых данных, либо на очень старых устройствах.
— разделять данные { float3 xyz; float3 fxfyfz } на два отдельных вектора — бывает полезно попробовтаь
— не стоит бояться atomic float'ов, часто они работают быстрее варианта с денормализованными данными (сгенерировать много данных для более простого пробега по ним бывает менее оптимально, несмотря на WARP блокировки — видимо, в силу того, что более компактные структуры данных лучше кешируются).
— эксперименты с параметрами CUDA компилятора часто приводят к очень интересным результатам: CC 1.x на простых симуляциях был сильно быстрее чем CC 2.0, но CC 1.x не умел atomicFloat'ы. зато CC 3.x можно заставить одновременно использовать atomicFloat'ы и генерировать менее прецезионный код ключиками "--use_fast_math –Xptxas –v,–abi=no". обещают эту фичу выпилить (там не по самым строгим стандартам считаются float'ы), но 180-250% прозиводительности заставляют меня до последнего генерировать не до конца ГОСТ, зато быстрый код.
я тоже запасся двумя GTX Titan, однако, до пользы от применения двойной точности у меня ещё ни разу не дошло. греет душу, что если понадобится — есть на чём посчитать :-)
>Да и устройства с opencl 2.0 я увидел реально сосвсем недавно, кажись как вышел amd драйвер омега или как его там. До этого всегда было 1.2 или даже 1.1 на нвидиа.
Жесть конечно. Начинаю понимать, почему convnet и много других интересных вещей сходу пишутся под nivida. жить без atomic float'ов в XXI веке — это знатное извращенство.
1. есть множество силовых точек, связанных «резинками» (например, как в таких задачах en.wikipedia.org/wiki/Force-directed_graph_drawing или в задачах на симуляцию физики мягкого тела (мой случай))
при условии, что количество резинок, связанных с одной силовой точкой, может быть произвольным, и на каждом шаге симуляции нужно «повлиять» на каждую силовую точку вектором силы каждой растянутой «резинки», связанной с силовой точкой — стандартный способ избежать atomic float'ов, когда kernel совершает проход по множеству точек, и каждая точка неконкурентно аккумулирует вектора сил всех связанных с ней резинок — не подходит (количество резинок у каждой силовой точки значительно отличается, что будет запирать синхронные WARPы. к тому же, необходимо будет использовать динамические списки резинок — т.е. гораздо более сложный код менеджмента модели).
при наличии atomic float'ов — мы просто совершаем пробег по множеству резинок, каждая из которых добавляет свой вектор силы к обоем силовым точкам, к которым привязана (через atomicAdd float). т.к. две резинки могут одновременно попытаться добавить свой вектор силы к одной и той же силовой точке, без atomic float'ов такой подход не работает.
приятно то, что atomic float'ы в современных nvidia картах настолько производительно реализованы, что в большинстве случаев попытки обойти их использование более хитрым и производительным алгоритмом приведут к уменьшению производительности.
т.е. при желании решать реальные задачи, а не фигурно извращаться с архитектурой GPGPU — atomic float'ы + CUDA + современные nvidia GPU (и чем дальше, тем лучше с этим) позволяют просто писать SIMD код в лоб, при этом имея производительность на грани теоретического максимума.
— это наиболее простой и понятный пример применения atomic float'ов.
в моей практике была куча ситуаций, когда происходило такое распараллеленное аккумулирование векторов сил на силовые точки. во всех случаях сначала писался код в лоб с atomicAdd (т.к. это по сути мнемонический эквивалент предполагаемой операции всегда)
Затем в некоторых случаях производились попытки оптимизировать это, «вывернув» структуры данных под то, чтобы каждая силовая точка становилась аккумулятором для списка внешних воздействий. это всегда усложняло код (денормализация данных под каждый конкретный kernel), но, как ни странно — в большинстве случаев не только не увеличивало производительность, а, наоборот, уменьшало её (я для себя пришёл к выводу, что денормализованные данные занимают большое количество памяти, что приводит к резкому уменьшению эффективности работы кешей).
Таким образом, здравый смысл и добро восторжествовали, и сегодня в CUDA + NVidia окружении простой код в большинстве случаев работает наиболее эффективно, и «камень с души» о непроизведённой тонкой оптимизации оказывается снят в общем случае. Atomic float'ы рулят!
p.s. субьективно — начиная с GTX 4 серии (т.е. с того момента, как в CC 2.0 практически сошла на нет необходимость возни c global memory coalescing) смысла в попытках обеспечить когерентность чтений, использовать shared memory в кернелах, использовать хитрые алгоритмы с синхронизациями и прочий ловлевел hardcore — канули в лета, и я очень рад, что это так.
для примера: я очень плотно занимался поиском оптимального алгоритма для SPH симуляций. в CUDA samples с давних времён был включен классический пример «particles», в котором ещё остались оптимизации под СС 1.2 (GTX 2 серии и раньше, когда CUDA только зарождался). но все эти ухищрения только мешали раскрыться потенциалу GTX 7 серии (я экспериментировал на GTX Titan).
в итоге, оптимальной оказалась практика, предложенная Rama Hoetzlein (он же провёл очень хороший обзор эволюции решений этой задачи здесь: on-demand.gputechconf.com/gtc/2014/presentations/S4117-fast-fixed-radius-nearest-neighbor-gpu.pdf). К сожалению, его собственное решение fluids3.com/ содержит несколько эммм досадных недоразумений в коде, в результате чего его код из коробки выполняется медленнее, чем «particle» демка из cuda samples. Но сделанный мной гибрид обоих решений сумел быть существенно более производительным, чем оба исходных варианта.
Это я всё к чему. Итоговый код не содержит никаких низкоуровневых фокусов с __syncthreads, sharedMem, разделений структур на отдельные вектора с денормализацией и сортировкой по ключам, хитрых fastRadixSort; и при этом выполняется в разы быстрее на современных Nvidia GPU.
Поэтому, если вы видите применение низкоуровневых фич CUDA, настоятельно рекомендую убедиться в том, что автор — не писал это «по книжкам» под допотопные устройства году эдак в 2009-2010 и/или не является нанотехнологически-академическим теоретиком из серии произвели исследование на миллион и выяснили «на GTX 9800 мой код даёт x10 ускорение». Велика вероятность, что на GTX 780 он будет выполняться в лучшем случае с той же скоростью, а то и медленнее решения в лоб на тех же пресловутых atomic float'ах. И здесь по опыту — очень легко попасть в ловушку устаревших мировоззрений сумрачного гения, потратить кучу времени, заморочить голову и в итоге так и не получить оптимального кода под свою задачу.
На этом всё. Извините, накипело. Надеюсь, мой опыт кому-то будет полезен.