вот та же самая мысль пришла в голову, ставящая под сомнение путешествия во времени. Но с другой стороны, если имеются какие-то другие измерения, как например существующие одновременно реальности в любой момент времени существования нашей вселенной. Наверное фигню написал ))
сталкивался с реальным случаем, когда мошенники по банковским картам, названивая клиентам с информацией о блокировке их карт, говорил гораздо лучше и поставленее, чем их настоящая служба поддержки по тем же самым карточкам
с вашей-то логикой можно смело задавать вопрос, правда риторический: прогресс идет семимильным шагами, почему спустя 50 лет после начала освоения космоса мы ещё не слетали на Пандору?
короче пришли к тому, с чего и начали: CUDA хороша своей заточенностью под свои же девайсы, а OpenCL хорош своей универсальностью (не учитывая этих самых мнимых расширений). И попытка выложить исходные коды CUDA лишь сыграть на поле OpenCL — на поле универсальности, но придется столкнуться с его недостатками, учитывая, что OpenCL — это стандарт, поддерживаемый целой группой, а у CUDA — только исходники, хорошее пространство для энтузиастов.
Кстати, писал на OpenCL на NVIDIA. Видимо хорошо пересадили (т.к. сама NVIDIA участвовала в разработке стандарта OpenCL), потому как разницы существенной с аналогичным кодом на CUDA я не заметил. Ну оно в принципе и понятно
а к чему вообще аргумент, что это не должно волновать NVIDIA?
Не припомню я, чтоб в opencl были какие-то специфичные расширения — спецификация всё-таки одна и для всех, не все её (например NVIDIA) реализуют сразу, например версию 1.1. Да и вот с CUDA может сложиться, что все её фишки нельзя уложить на другие платформы, а в случае с opencl сразу создавать рабочая группа Khronos во главе с Apple, как раз-таки чтобы объять несколько производителей и сделать стандарт более универсальным между разными архитектурами
к тому же CUDA ограничена только адаптерами NVIDIA. А ведь помимо этого имеются ещё и AMD-адптеры. Ну и спеки OpenCL могут быть реализованы на любом (не придирайтесь к слову) оборудовании, если будет желание производителей
слишком смелый прогноз.
У CUDA host API имеется 2 режима: driver и runtime. Вы говорите про легкость именно runtime режима. Взгляните на driver-режим, сразу нахлынет дежавю с отсылкой на opencl
жутко запутанный ввиду своей ориентированности не под определенную архитектуру. У той же CUDA есть режим работы (не приведу сейчас название, давно не трогал её), где также будет вся эта многословность.
так при чем тут язык-то? я вам говорю, что определенный производитель железа решил реализовать спецификации OpenCL на своем оборудовании. И вот от того, что он криво написал эту прокладку перед железом, язык виноват не будет
а чем кривущ OpenCL? Его проблемы не могут быть связаны с реализацией реализаторами под свою платформу? NVIDIA сразу точила под только свою архитектуру. OpenCL же всего лишь спецификация, который каждый может реализовать по своему, как пример: NVIDIA поверх CUDA. И не возникнет ли схожей кривущести при реализации CUDA на других архитектурах?
действительно.
а интересно бывает обычно тогда, когда появляется что-то новое, неизученное, когда снова есть что изучать, ну оттачивать текущие навыки до блеска
Прошлый топик был интереснее и информативнее… Опять сиквел провалился
Вопрос к гуру: что произойдет, если один и тот же объект хранится в разных списках? Вернее можно ли добавить его в 2 разных списка? На это ругнется компилятор?
насколько я знаю от докторов наук в нашем универе, которые в придачу получили степени докторов философии во Франции, европейская степень доктора философии соответствует нашим кандидатам. Так и придачу, кроме докторов опять этой самой философии больше ничего нет, типа Властелина наук, а вот каких — уже не важно. Ну а у нас доктора наук -ещё есть разница каких. К тому же наши доктора, самые матёрые доктора в мире, на западе им даже аналога нет. Ну по званию конечно же.
1. Так вот почитал я статью от уважаемого XaocCPS, там получается, что код, который импортирует модуль (подключает к себе), уже знает о существовании класса (не используется рефлексия), и обращается к нему именно по имени класса, а не интерфейса.
2. Я в курсе, что из разных. А что народ в тредах выше кипишит, что им придется зависимости одни и теже подтягивать, увелчивая расходы памяти
начитался в комментах про MEF и возникло несколько вопросов:
1. правильно ли я понимаю, что в MEF 1.0 нет возможности в рантайме подключать модули, которые неизвестны исполняемому коду? Типа рефлексии. Ну не могу я знать заранее, какие модули будут использоваться.
И второй вопрос, не про MEF:
2. Чтобы не грузить несколько одну и ту же библиотеку, можно ли написать поверх неё обёртку, подключать как обычный плагин. Сам же плагин будет работать на основе Синглтона. А раз домен приложения один, то и создавать несколько экземпляров, а от того и грузить одну и туже библиотеку не придется. В качестве примера COM-библиотеки Microsoft.Interopl.Office. Word, Excel…
Кстати, писал на OpenCL на NVIDIA. Видимо хорошо пересадили (т.к. сама NVIDIA участвовала в разработке стандарта OpenCL), потому как разницы существенной с аналогичным кодом на CUDA я не заметил. Ну оно в принципе и понятно
Не припомню я, чтоб в opencl были какие-то специфичные расширения — спецификация всё-таки одна и для всех, не все её (например NVIDIA) реализуют сразу, например версию 1.1. Да и вот с CUDA может сложиться, что все её фишки нельзя уложить на другие платформы, а в случае с opencl сразу создавать рабочая группа Khronos во главе с Apple, как раз-таки чтобы объять несколько производителей и сделать стандарт более универсальным между разными архитектурами
У CUDA host API имеется 2 режима: driver и runtime. Вы говорите про легкость именно runtime режима. Взгляните на driver-режим, сразу нахлынет дежавю с отсылкой на opencl
так при чем тут язык-то? я вам говорю, что определенный производитель железа решил реализовать спецификации OpenCL на своем оборудовании. И вот от того, что он криво написал эту прокладку перед железом, язык виноват не будет
а интересно бывает обычно тогда, когда появляется что-то новое, неизученное, когда снова есть что изучать, ну оттачивать текущие навыки до блеска
Вопрос к гуру: что произойдет, если один и тот же объект хранится в разных списках? Вернее можно ли добавить его в 2 разных списка? На это ругнется компилятор?
1. Написать работу (быть может и слабую);
2. Ооооочень хорошо проставиться диссертационному совету;
Слышал мнения некоторых, претендующих на ученую степень, что их отпугивает именно второй пункт, не тянут…
2. Я в курсе, что из разных. А что народ в тредах выше кипишит, что им придется зависимости одни и теже подтягивать, увелчивая расходы памяти
1. правильно ли я понимаю, что в MEF 1.0 нет возможности в рантайме подключать модули, которые неизвестны исполняемому коду? Типа рефлексии. Ну не могу я знать заранее, какие модули будут использоваться.
И второй вопрос, не про MEF:
2. Чтобы не грузить несколько одну и ту же библиотеку, можно ли написать поверх неё обёртку, подключать как обычный плагин. Сам же плагин будет работать на основе Синглтона. А раз домен приложения один, то и создавать несколько экземпляров, а от того и грузить одну и туже библиотеку не придется. В качестве примера COM-библиотеки Microsoft.Interopl.Office. Word, Excel…