Компания NVIDIA объявила о переводе поддержки тулкита CUDA для 32-разрядых Linux-систем (x86) в разряд устаревших. Разработка и обеспечение работы приложений CUDA и OpenCL на 32-разрядной платформе Linux-x86 не гарантируется в будущем.Поддержка уже выпущенных версий тулкита CUDA для платформы Linux-x86 будет сохранена, но будущие выпуски скорее всего не будут доступны для Linux-x86. Пакет GPU-драйверов с поддержкой CUDA входит в состав ветки проприетарных драйверов NVIDIA 331.x для Linux, но в будущих ветках возможно его исключения из поставки, в том числе и из состава сборки для архитектуры x86_64. Поддержка CUDA для Linux на 32-разрядной архитектуре ARM, а также не связанных с CUDA компонентов драйвера NVIDIA для Linux (x86/x86_64), будет продолжена в полном объёме.
URL: https://devtalk.nvidia.com/default/topic/633730/unix-graphic.../
Новость: http://www.opennet.me/opennews/art.shtml?num=38388
>The CUDA driver might not be included in future releases of the NVIDIA Linux-x86 >and Linux-x86_64 GPU driver packages.Как я люблю местных оптимистов...
и что? он и сейчас не поставляется с драйверами. Куду нужно ставить отдельно
Тулкит и сдк да отдельно, а вот рантайм и драйвер идет вместе с nvidia-driversТак что учи матчасть аноним ;)
это в винде CUDA ставится с дровами. В Linux его отдельно ставить всегда нужно было.
Я вообще то про линукс и говорю. Отдельно ставится sdk и тулкит. Однако сам драйвер идет в нвидия драйверс вместе с opencl и cuda рантаймом
Ты всё путаешь. Вместе с драйвером NVIDIA в систему устанавливается несколько файлов libcuda*.so. А CUDA Toolkit устанавливает:libcudablas.so libcufftw.so.5.5 libnppc.so.5.5
libcudablas.so.5.5 libcufftw.so.5.5.22 libnppc.so.5.5.22
libcudablas.so.5.5.22 libcuinj64.so libnppi.so
libcudadevrt.a libcuinj64.so.5.5 libnppi.so.5.5
libcudart.so libcuinj64.so.5.5.22 libnppi.so.5.5.22
libcudart.so.5.5 libcurand.so libnpps.so
libcudart.so.5.5.22 libcurand.so.5.5 libnpps.so.5.5
libcudart_static.a libcurand.so.5.5.22 libnpps.so.5.5.22
libcufft.so libcusparse.so libnvToolsExt.so
libcufft.so.5.5 libcusparse.so.5.5 libnvToolsExt.so.1
libcufft.so.5.5.22 libcusparse.so.5.5.22 libnvToolsExt.so.1.0.0
Да, мы такие...Даешь почётные похороны х86 !
И Нвидиа нам в этом поможет: "Компания NVIDIA объявила о переводе поддержки тулкита и драйвера CUDA для 32-разрядых Linux-систем (x86) в разряд устаревших. Разработка и обеспечение работы приложений CUDA и OpenCL на 32-разрядной платформе Linux-x86 прекращается."
>И Нвидиа нам в этом поможетВот такая жизнь с блобьём — одни блобы за уши тащат, другие за йайца тормозят.
Ау! Те кому надо уже скомпиляли себе и/или поставили. А сабж — это шантаж какой-то.
До того как x86 загнётся, nVidia отловит ещё не один смачный фак от Торвальдса и Ко =)
Да и Ваше мнение тоже
Ботаник согнувшись показал средний палец.Для нердов, живущих за компьютером - незабываемые впечатления. )
А у д@лб@#бов - сказочный батхерт...
> До того как x86 загнётся,С x32 не перепутал?
> Даешь почётные похороны х86 !Ещо в 2005 похоронил!
Плохо закoпал, значит. Видишь, местные некроманты откопали и гальванизировали.:)
>>The CUDA driver might not be included in future releases of the NVIDIA Linux-x86 >and Linux-x86_64 GPU driver packages.
> Как я люблю местных оптимистов...а не является ли это следствием этого:
http://www.opennet.me/opennews/art.shtml?num=38316
?
>> Как я люблю местных оптимистов...
> а не является ли это следствием этого:
>/opennews/art.shtml?num=38316
> ?Неее. Вот /opennews/art.shtml?num=38378 этого.
Складывается впечатление, что вычисления на видеокартах нужны только для того, чтобы единственная компания не вылетела с рынка. Причём если кликнуть, кто согласится писать код под всё это дело, не отзовётся никто. Это вам не клепать сайты на PHP или мобильные софтинки под айфон, тут реально нужен мозг.
GPU используется в BOINC - наиболее полезный проект из всех для GPU.
> GPU используется в BOINC - наиболее полезный проект из всех для GPU.и чем же он полезен для обычного человека?
Ничем. Иди водочки накати.
> и чем же он полезен для обычного человека?Совершенно бесполезен, точно так же, как и вся прочая научная деятельность.
пользы от этих расчётов обычные люди не получают:SETI@home
Rosetta@home
World Community Grid
Einstein@Home
Climate Prediction
LHC@home
MilkyWay@home
SIMAP@home
PrimeGrid
Spinhenge@homeэто не наука, это бред какой-то
>>пользы от этих расчётов обычные люди не получают:обычные люди (читай тупое стадо потребителей) пользуются каждый день приборами, которые содержат реализованные на практике открытые эффекты и законы фундаментальной физики, изучение которых бы такие как ты лет 50 назад посчитали бы пустой тратой денег на жадных учёных из госказны, и от которых простому человеку никакого толку.
SETI уже закрыт, к слову.
Так сабж с картами невидиа будет кому продавать? Учёным?
Ага, счаз.
Речь как раз о ширпотребе.
Каждому покупателю инвидии -- адронный коллайдер, маааахоньний, на 2кВт, в пода^Wнагрузку!+++Инвидия -- мы согреваем Землю!</на правах>
Логично.
Профит энвидии тогда назовём чОрной дырой.
> Логично.
> Профит энвидии тогда назовём чОрной дырой.Чорная Меса уже где-то была..... не?
> пользы от этих расчётов обычные люди не получают:Да-да, именно! Так же как и от науки.
>[оверквотинг удален]
> Rosetta@home
> World Community Grid
> Einstein@Home
> Climate Prediction
> LHC@home
> MilkyWay@home
> SIMAP@home
> PrimeGrid
> Spinhenge@home
> это не наука, это бред какой-тоЧто значит "не наука"? Я не буду про все эти проекты говорить, но SETI -- вполне себе научное начинание, да из области UFO-логии, но научное, которое длится уже достаточно долго, чтобы можно было бы рассматривать отсутствие результата как результат. Эйнштейн с МлечнымПутём -- это астрономические проекты, которые могут уточнить, подтвердить или опровергнуть современные научные представления. Обсчёт коллайдера -- это не просто наука, но высоко-баблосная наука. Розетта, AFAIR, это обсчёт пространственной конфигурации белков -- тоже данные весьма полезные для учёных. Но при этом бесполезные хомячку, который участвует в них. Но для хомячка, как известно, и наука в целом бесполезна. Хомячок может оценить достижения инженеров, и то, оценивает их он по уровню активности маркетологов, вокруг данного достижения, а не по уровню сложности или ювелирности работы проделанной инженерами. Даже практическая применимость достижения уходит на второй план, перед эффективностью рекламы и прочих потреблятских технологий.
Не, ну а чё вы хотели? Чтобы на вашей видеокарте обсчитывали бы запасы нефти или аэродинамику самолёта? Но, во-первых, это не наука, а применение науки, то есть, скорее, инженерное дело. Во-вторых, не будут: нефть и самолётостроение имеют возможность заработать себе денег (или получить гранты) на аренду суперкомпьютера. И такой путь эффективнее. К boinc прибегают те, у кого нет возможности арендовать суперкомпьютер.
Молодцы, наконец-то! x86 давно пора уничтожить.
> Молодцы, наконец-то! x86 давно пора уничтожить.если идёт речь про x86_32 -- то это да. :)
но к сожалению -- Nvidia имеет совсем маленькиое влияние (тем более на Linux -- Nvidia и её приприетарные поделки мало кому нужны).
так что -- тот факт, что Nvidia что-то там отказалась делать для x86_32 -- не придвинет смерть x86_32.
а жаль. 32-битные некроморфы то и дело высовываются из своих могил и портят жизнь нормальным людям :( ..
Господину не-некрофилу напоминаю, что 64х-битный файрфокс жрет памяти минимум в полтора разы больше, чем 32х-битный. Цифирки я когда-то приводил, для него и для оперы - там результат был аналогичный. Больше того - допустим, у меня на десктопе сейчас НИ ОДНОЙ софтины, которая имет обоснованную необходимость сожрать больше пары гиг памяти. Хотя нет, вру - при сборке хромиума больше выжирается - но, что характерно, она как-то на 32х-битной системе отрабатывает. И про mmap рассказывать мне тоже не надо - нет у меня таких задач. А у нормального юзера, который хром дома не собирает, тем более их нет.Вот x32 - вещь хорошая, это да.
домашний сервачек на пентиуме 4, а он только 32 умеет. куда не нужна конечно, но все равно, не нужно начинать моду на убийство 32 :(
> Господину не-некрофилу напоминаю, что 64х-битный файрфокс жрет памяти минимум в полтора
> разы больше, чем 32х-битный. Цифирки я когда-то приводил, для него и
> для оперы - там результат был аналогичный. Больше того - допустим,
> у меня на десктопе сейчас НИ ОДНОЙ софтины, которая имет обоснованную
> необходимость сожрать больше пары гиг памяти. Хотя нет, вру - при
> сборке хромиума больше выжирается - но, что характерно, она как-то на
> 32х-битной системе отрабатывает. И про mmap рассказывать мне тоже не надо
> - нет у меня таких задач. А у нормального юзера, который
> хром дома не собирает, тем более их нет.
> Вот x32 - вещь хорошая, это да.Не боишься ли ты генту? Попробуй x32_x32 (лежит в папке ср stage3 для x86_64, сборок LiveDVD ещё нет). Это 64-битные бинарники и 32-битная адресация памяти. То есть только плюсы 64-битных компов без минусов. Естественно для компов где 2-4 Гб памяти. А Debian-а для этой архитектуры ещё нет.
>Попробуй x32_x32Наверное всё-же x86_x32?
>То есть только плюсы 64-битных компов без минусов. Естественно для компов где 2-4 Гб памяти.Ничего подобного.
Ядро вполне себе 64-битное. С соответсвующим количеством ОЗУ.
Это только каждому процессу (x32 который) 4Гб выдаётся, что разумеется плюс для типичного приложения десктопа.
Да и вообще, стоит в USE = "abi_x86_32 abi_x86_64 abi_x86_x32"
Первое для стимовских игрушек, второе для системы, третье джаст4фан.
Пока с последним далеко не всё собирается, а блобы невидии так вообще не планируются даже.
А жаль.
Не боюсь, я и так гентушник. Но пока пересобирать систему неохота. А что такое x32 я знаю, поэтому о нем и упомянул. И, кстати, этот режим отлично годится для компов с любым количеством памяти - ядро-то 64-х-разрядное, это в юзерспейсе наколдовали (ну плюс сисколлы подправили). Ограничение получается только одно - один пользовательский процесс не может адресоввать более 4-х гигабайт.
Нет, это не юзерспейс. Ядро там тоже меняли, конкретно 3.4. Я пытался из старого дистрибутива Linux начать установку, а она не смогла выполнить /bin/bash из stage3 для x32_x32. "file /bin/bash" показывает что нужно ядро 3.4. http://www.opennet.me/opennews/art.shtml?num=33142
Не меняли, а ввели поддержку архитектуры х32.
Как и в глибц.
И это большая разница. Всё-таки формат исполняемых файлов другой, указатели короче и тд.Но само ядро — 64-битное. С 64-битными указателями.
Ещё раз повторю — вон у меня в системе живут сразу 3-и архитектуры. 32, 64 и х32.
В ядре же только поддержку 2-х дополнительных включил и всё.
> Ещё раз повторю — вон у меня в системе живут сразу 3-икопии системных библиотек. Welcome to library hell, Luke.
>>Ещё раз повторю — вон у меня в системе живут сразу 3-и
>копии системных библиотек.ай-ай-й=ай.
а то я без вас этого не знал.
>Welcome to library hеll, Luke.libhеll — это совершенно другое понятие, применяемое к совершенно другим случаям, мой юный падаван.
> libhеll — это совершенно другое понятие, применяемое к совершенно другим случаям,
> мой юный падаван.А ты не оперируй устоявшимися шаблонами, мой старый маразматичный друг (ничего личного xD). Держать в системе ТРИ копии системных библиотек, делающих одно и то же - тот самый hell и есть. Только в другой ипостаси слегка.
>Держать в системе ТРИ копии системных библиотек, делающих одно и то же - тот самый hell и есть. Только в другой ипостаси слегка.Нет. Учите матчасть.
А то так в учениках джедаев всю жизнь и проходите.
Пока это три независимых сета и приложение не может их перепутать (а оно здесь не может - ABI разный) - хелла в упор не вижу.Теоретически можно возмутиться, что они в памяти будут место лишее занимать, но тут же идея в том, что в основном используется одна архитектура (x32), остальное - по необходимости, то есть очень иногда.
> Пока это три независимых сета и приложение не может их перепутать (а
> оно здесь не может - ABI разный) - хелла в упор не вижу.В целом прямого хелла нет - перепутать почти невозможно, угу. Но определенные грабли вижу в необходимости билдить и использовать аж целых 3 набора либ (а по-хорошему - пакетов с либами) для поддержания одного и того же набора апликух. Плюс так и вижу часть (в основном, как ни странно, BSD-licensed) софтинок, упорно собирающих либы в /usr/lib вне зависимости от архитектуры. Их придётся допиливать :)
>> libhеll — это совершенно другое понятие, применяемое к совершенно другим случаям,
>> мой юный падаван.
> А ты не оперируй устоявшимися шаблонами, мой старый маразматичный друг (ничего личного
> xD). Держать в системе ТРИ копии системных библиотек, делающих одно и
> то же - тот самый hell и есть. Только в другой
> ипостаси слегка.Вы предлагаете расширить понятие dependancy hell, чтобы включить в него любую проблему с зависимостями? Давайте тогда включим также и проблему упавшего интернета в это понятие, поскольку когда интернет лежит, никакие зависимости разрешить не удаётся. Да и вообще, поставим знак равенства между dependancy и dependancy hell. Любая зависимость -- это зло, которое усложняет нам жизнь.
Сам факт того, что надо всегда иметь три синхронных "копии" одной и той же библиотеки в системе - уже вымораживает.А уж если надо какую-то проприетарь подключить... не факт, что она будет работать именно в x32 приложении - под x32 либов может и не оказаться. И получится, что вон то работает одинаково в x32/x64/x86, вон то - работает только в x86, а вот это - только в x64 версии одного и того же приложения. Хелл сферический, в вакууме.
Вам же нужен не компьютер а пишущая машинка. Вот и сидите на своём x32 без CUDA, вы ж и слов-то таких не знаете, верно?
Куда должна сдохнуть. Средство, поддерживаемое одним вендором - это всегда проблемы - либо в настоящем, либов будущем. Сравни с OpenCL, который можно гонять на чем угодно.
> Господину не-некрофилу напоминаю, что 64х-битный файрфокс жрет памяти минимум в полтора
> разы больше, чем 32х-битный.На машинах где 64 бита имеет смысл это не является проблемой. Я еще ни разу не видел чтобы фокс вылез да 2Гб памяти. Даже с 400 вкладок (!!!). Да, это про 64-битный.
Вот только не нужно чужую память считать, ок?
Мне моя дорога, как... память :D
>Я еще ни разу не видел чтобы фокс вылез да 2Гб памяти.А то б не вылез за 1.
К тому же есть ещё один плюс — программы, где есть утечка, не выжрут всю память, включая своп до полного непотребства. Да и быстрее будет. С учётом кэшэй ЦПУ. Он то у вас не расширяется за копейки?Зыж
За 2 не вылез? Тем более зачем вам развлекать фокс 64-битными указателями, когда ему и 32-битных то за глаза? :D
А чего не 128? Или 256? Вам же не жалко? :D
Смею вам не поверить. Он даже на 32-х битах это проделывает иногда. И полутора сотен вкладок для этого хватает. Ну, то есть, вероятн, есть какие-то дополнительные условия, но то, что я саам мерял - соотношение в полтора раза, то есть потерянная память без какого-либо профита.
>> Господину не-некрофилу напоминаю, что 64х-битный файрфокс жрет памяти минимум в полтора
>> разы больше, чем 32х-битный.
> На машинах где 64 бита имеет смысл это не является проблемой. Я
> еще ни разу не видел чтобы фокс вылез да 2Гб памяти.
> Даже с 400 вкладок (!!!). Да, это про 64-битный.Всё зависит от вкладок. Где-то пробегала ссылка* на страничку, на которой файрфоксу не хватало 4Гб ОЗУ, даже если эта страничка -- единственная открытая в файрфокс. Эту хрень пофиксили, вроде в 26, но...
*) вот она эта ссылка, кстати: http://congressoamericano.blogspot.com/p/fotos-do-congresso-...
> Всё зависит от вкладок. Где-то пробегала ссылка* на страничку, на которой файрфоксу
> не хватало 4Гб ОЗУ, даже если эта страничка -- единственная открытая
> в файрфокс. Эту хрень пофиксили, вроде в 26, но...И вот тут-то x86 и x32 уже переходят в разряд неосиляторов, ибо там адресного пространства процессу не хватит.
> 32-битные некроморфы то и дело высовываются из своих могил и портят жизнь нормальным людям :( ..Хороший доктор тебе поможет.
> но к сожалению -- Nvidia имеет совсем маленькиое влияние (тем более на Linux -- Nvidia и её приприетарные поделки мало кому нужны).Ох уж эти мокрые сны..
> Молодцы, наконец-то! x86 давно пора уничтожить.Зачем ?
Да хотя бы затем, чтобы эпический костыль по имени O_LARGEFILE выкинуть, наконец.
Плюс в long mode слегка больше регистров общего назначения, что тоже не может не радовать.
а то что, это больше колл регистров нужно сохранять/выгружать в память межу переходами выполнения процессов? Но больше значет круче жи
> а то что, это больше колл регистров нужно сохранять/выгружать в память межу
> переходами выполнения процессов? Но больше значет круче жиЕсли когда-нибудь смотрели выход современных компиляторов - поймёте, что при бОльшем количестве регистров их приходится куда меньше свапить со стеком при выполнении. Это окупает затраты на переключение контекста на 100500%.
>Молодцы, наконец-то! x86 давно пора уничтожить.По моему не очень скромному мнению, избавляться надо не от 32-бит, а от одноядерных CPU. >=4 ядра на сегодня - это уже норма жизни.
Зависит от задач. У моей тачки 4 ядра, но полностью используются они исключительно редко. ИМХО, ядра, по своей сути, это костыль из-за отсутствия качественного роста производительности. Возможность параллелить задачи была возможна и ранее, на базе использования систем с 1 ядром.
Оба вы не правы.
В идеале для каждого потока (не процесса) должно быть а) своё ядро (а также своя озу, в/в и тд) и б) его неограниченная производительность.
Это недостижимо, но к этому нужно стремиться.
> Оба вы не правы.
> В идеале для каждого потока (не процесса) должно быть а) своё ядро
> (а также своя озу, в/в и тд) и б) его неограниченная
> производительность.
> Это недостижимо, но к этому нужно стремиться.На одном ядре - оно уже тут. Под ДОС-ом. Ж)
> На одном ядре - оно уже тут. Под ДОС-ом. Ж)Но ровно до тех пор, пока выполняется одна задача. Попытки запустить сразу две приводят к тому же, что и во всех остальных ОСях.
>> В идеале для каждого потока (не процесса)
> На одном ядре - оно уже тут. Под ДОС-ом. Ж)А поток и может только на одном ядре (логическом).
Поэтому и называется — поток.Зыж
Тяжелое детство? Учебники по очереди курили? И тебе на самокрутку уже не хватило? ;)
> А поток и может только на одном ядре (логическом).
> Поэтому и называется — поток.Уел. Молодец, чо. Только там чуть выше было ещё про отдельно-суверенные В/В и ОЗУ.
> Тяжелое детство? Учебники по очереди курили? И тебе на самокрутку уже не
Что ещё сказать... всё сказано выше. Важно и количество ядер, и их производительность, и отсутствие конкуренции за ресурсы.
Для всего остального как раз и написал — идеал не достижим. Как материальная точка, идеальный газ, этк.
> На одном ядре - оно уже тут. Под ДОС-ом. Ж)А вот зря ты так, MSDOS - самая реалтаймовая ОСь.
No OS - вот это самая реалтаймовая ось. No OS forever!
Все дело в том, что выполнение потоков весьма непредсказуемо. Множество потоков например блокируются при В/В, что отслеживает планировщик и позволяет "параллельно" выполнять их ценой некоторого ослабления гарантий что они отрабатывают внешние события за минимально возможное время. Это вполне терпимо в реальных условиях эксплуатации и позволяет экономить ресурсы системы и значительно снизить стоимость вычислительной системы.
Вариант с бесконечным количеством потоков же по своей сути - игра в тетрис одного человека за счет всех вычислительных ресурсов всех компьютеров мира. При реальном же использовании на сегодняшний день все ядра загружены неполно и неравномерно, кроме отдельных задач, требующих все ресурсы системы. В силу своей работы могу привести только один яркий пример - моделирование методом конечных элементов - по сути, решение достаточно большого количества систем уравнений. При этом некоторый прирост производительности достижим с использованием многоядерности, но все же в основном упирается в производительность 1 ядра, что конечно не мешает запустить решение нескольких несвязанных между собой задач если это конечно требуется.
Использование различных В/В и ОЗУ потребуют применения средств обмена данными (ведь программы не выполняются сами по себе в общем случае, а предполагают некоторое информационное окружение) между параллельно выполняющимися потоками и приведут к снижению производительности.
Я конечно не эксперт в подобных "предсказаниях", но ИМХО все зависит от задач и требует специализированных решений в каждом конкретном случае, как и делается сегодня, а в большинстве случаев все так, как и описал.
>Все дело в томВсё дело в том, что ОСи сейчас многозадачные.
Вот и весь сказ.
> Это недостижимо, но к этому нужно стремиться.Апач вот как раз и написали под это. Поэтому на несуществующих компьютерах он почти бесконечно масштабируется. А на реальных компьютерах - курит бамбук.
Вот зачем врать то?
Апач нормально работает. И работал. Уже десятилетиями как верой и правдой.
Тоже мне нашёл пример плохой программы. Марш на ИИС тогда.Зыж
И не нужно всякими писю...нжинксами мериться.
И написана не вами, и далеко не всегда апач заменит.
CUDA абсолютно безполезна для научных расчётов, потому что нормальную производительность показывает только с одинарной точностью float, для double всё совсем плохо, так что нет преимущества перед счётом на CPU.
> CUDA абсолютно безполезна для научных расчётов, потому что нормальную производительность
> показывает только с одинарной точностью float, для double всё совсем плохо,
> так что нет преимущества перед счётом на CPU.Это кажется в GeForce 6xx убрали, а в 4xx и 5xx ещё было.
>Это кажется в GeForce 6xx убрали, а в 4xx и 5xx ещё было.Нет, в старых сериях ядер ещё меньше и с ними всё ещё хуже.
У Титана вроде бы 1.5 Тфлопа в double.
>У Титана вроде бы 1.5 Тфлопа в double.http://en.wikipedia.org/wiki/GeForce_700_Series
Да это так, у Титана:
float: 4500 GFLOPS
double: 1500 GFLOPSТак что с double всего в 3 раза хуже чем с float, но вот все остальные карты имеют производительность с double в 20 и более раз хуже чем с float.
Это при том что производительность на топовом CPU Intel Core-i7 где-то в районе 100 GFLOPS, так что считать на GPU имеет смысл только если это Titan. Например, у GeForce GTX 780 Ti производительность уже всего лишь 210 GFLOPS, что всего примерно в два раза выше чем у CPU Intel Core-i7.
Титан по этому показателю на уровне 7970, которая дешевле в 3 раза, так что
> считать на GPU имеет смысл только если это не GPU от Nvidiaпофиксил.
> Титан по этому показателю на уровне 7970, которая дешевле в 3 раза,
> так что
>> считать на GPU имеет смысл только если это не GPU от Nvidia
> пофиксил.А чё, не NVidia уже работает под Linux?
Ну чушь не нес бы.Куча майнеров сидит на линуксе, правда, с каталистом. Отлично opencl с ним работает.
> А чё, не NVidia уже работает под Linux?С разморозкой, пля. На дворе 2013 год а не конец прошлого века. Иди вон у майнеров *coin'ов поинтересуйся что они про твою нвидию думают как числокрушилки. И да, в свое время у некоторых психов были целые склады забитые самопальными инсталляциями где GPU понатыкано по 5-6 штук в мамку, etc. Выглядит сие как подпольный датацентр скайнета :). Зато теперь "скайнетчики" вероятно отнюдь не бедные буратины, с учетом курса биткоинов. А после появления ASICов можно или продать железо или перейти на майнинг лайткоинов, крякинг хэшей, etc. И во всех этих задачах нвиидия в пролете как мухи в самолете.
Казалось бы ещё года не прошло (или прошло?) как обсуждали китайский кластер, где они невидию прокинули на эндцать лямов, а павлин уже забыл (хоть точно помню что он там отмечался).
Старый стал. Хвост уже не так торчит.
> Казалось бы ещё года не прошло (или прошло?) как обсуждали китайский кластер,
> где они невидию прокинули на эндцать лямов,Не знаю насчет кластеров, а китайцы хотели GPU для своих MIPSовых компьютеров в школы, при том речь шла о заказе на ~полмиллиарда баксов. А оказалось что лoxи из нвидии просто не могут выкатить проприетарный драйвер под MIPS. А другого можно считать что нет, т.к. nouveau на данный момент скорее функционирует чем работает. Ну и профукала нвидия заказ. Кто же будет покупать GPU без драйверов?
дубинушка, в топ 500 глянь. на жирфорсиках да, дабл порезан по самое не могу в погоне за неотстрелом себе ноги и тдп.
> дубинушка, в топ 500 глянь. на жирфорсиках да, дабл порезан по самое
> не могу в погоне за неотстрелом себе ноги и тдп."за неотстрелом ноги" совсем не в тему, якобы чтобы пользователи сами себе не навредили расчётами? какой-то идиoтский тезис
> "за неотстрелом ноги" совсем не в тему, якобы чтобы пользователи сами себе
> не навредили расчётами? какой-то идиoтский тезисс другой стороны, чтобы не навредить самой себе «невидаль» конечно порезала производительность игровых карт
Это он про Nvidia. Если жирафы будут иметь полноценный double, теслы станут не нужны.
Могут совсем разработку CUDA прекратить, даже никто и не заметит этого. Что была, что нет, и никакой разницы.
> Могут совсем разработку CUDA прекратить, даже никто и не заметит этого. Что
> была, что нет, и никакой разницы.Вот нравятся мне такие люди. Говно всем громко крикнуло, что оно говно! :D
http://www.nscf.ru/nauchno-prakticheskaya-konferenciya/priny.../Компьютерное моделирование динамики затопления территорий в случае ЧС
с использованием технологий параллельных вычислений MPI-OpenMP-CUDA
на гибридных суперкомпьютерах с графическими ускорителеями TESLAОрганизация поиска данных в суперкомпьютерных системах на базе NoSQL-подхода
и технологии NVIDIA CUDA, НИЯУ МИФИ, МоскваОператорная библиотека для решения трёхмерных сеточных задач математической физики
с использованием графических плат с архитектурой CUDA, ИПМ им. М.В.Келдыша РАН, Москваhttp://www.nonlinearwaves.sci-nnov.ru/lectors.html
А.Б. Борисов, Ф.Н. Рыбаков (ИФМ УрО РАН). Многомерные пространственные структуры
в магнетиках. Аналитическая теория и численные вычисления с использованием архитектуры CUDA.А вот тут они ещё на работу принимали http://hh.ru/vacancy/2408307
проплаченная маркетинговая хрень, так как моделирование динамики затопления территорий никак не поможет предотвратить само затоплениеостальные CUDA-приложения вот никак нельзя перенести на opencl? если можно, то и вывод очевиден - она не нужна, проприетарщина и vendor-lock во всех смыслах
>так как моделирование динамики затопления территорий никак не поможет предотвратить само затоплениеДоклад не видел, но моделирование ни как не позволит само по себе предотвратить ЧС в принципе. Однако, зная как поведет себя моделируемая система можно предпринять ряд мер по ее изменению с целью улучшить критичные характеристики. В данном случае, видимо предполагалось планирование мер по уменьшению тяжести последствий или их предупреждению.
В любом случае, вариант "не понимаю значит ненужно" неприемлем для человека разумного.
> проплаченная маркетинговая хрень,
> так как моделирование динамики затопления территорий
> никак не поможет предотвратить само затоплениеОтводные каналы роют, в нужных местах по результатам расчётов,
доп. дамбы, график спуска вод в существующих дамбах.> если можно, то и вывод очевиден - она не нужна, проприетарщина
> и vendor-lock во всех смыслахХочешь тебе подарю Nvidia Titan? Но только на контрактной основе,
- должен будешь писать отчёты, бенчмарки в течении года.
Методичку пришлю после рассмотрения резюме.
> Хочешь тебе подарю Nvidia Titan? Но только на контрактной основе, будешь
> писать отчёты, бенчмарки в течении года.Купи себе firepro и 9990, нищебpод%D. "Подарю." Ты ещё свои отчёты не отработал.
> Гoвнo всем громко крикнуло, что оно гoвнo!Так не кричи, чего разорался?
Кто-нибудь знает, как у ATI обстоят дела в Linux с вычислениями в double?
Х....о http://boinc.berkeley.edu/wiki/ATI_RadeonRadeon HD 6990
single precision 5099
double precision 1275Radeon HD 5970
single precision 5440
double precision 1088
---Ты не переживай, у AMD и Интел, АМД и Нвидия, есть договорённости о равномерном высасывания бабла из народа.
В лидерах никто из них никогда не будет.
> Х....о http://boinc.berkeley.edu/wiki/ATI_Radeon
> Radeon HD 6990
> single precision 5099
> double precision 1275
> Radeon HD 5970
> single precision 5440
> double precision 1088
> ---Х..о - это ты "хорошо" имел в виду, надо полагать, так как цифирки весьма достойные. Ну и пара моментов.
Во-первых, там старые данные - нет 7990 и 8990.
Во-вторых, эта самая 7990 стоит слегка дешевле титана (данные с newegg.com) и при этом дает 8200/1894 (singe/double), что больше, чем у титана.
>[оверквотинг удален]
>> double precision 1275
>> Radeon HD 5970
>> single precision 5440
>> double precision 1088
>> ---
> Х..о - это ты "хорошо" имел в виду, надо полагать, так как
> цифирки весьма достойные. Ну и пара моментов.
> Во-первых, там старые данные - нет 7990 и 8990.
> Во-вторых, эта самая 7990 стоит слегка дешевле титана (данные с newegg.com) и
> при этом дает 8200/1894 (singe/double), что больше, чем у титана.У тя есть Титан, есть 7990? Нет! Ну а чё толку, в этих вакуумных числах.
Бери программу, замеряй, в реальности будет одно и тоже. +/- погрешность.
Более того, на реальных задачах оно просядет раза в два. Чтоб разогнать софтину
до аппаратных лимитов, нужно быть инженером Nvidia/AMD.
Про научные расчёты речь, а там без double никуда, для игр важна только производительность с float.
Вы вообще в курсе зачем учёным GPU?
В контру играть?
Ты, если что, эти цифирки первым приводить начал - а как показали, что они не в пользу нвидии - теперь пытаешься отмазаться.Ты мне вот что скажи - факты явно против нвидии - амд по железу на уровне, если не впереди, нормально взаимодействует с сообществом - в общем, имеет объективные плюсы. А чем тебе нвидиа-то глянулась, что ты так её защищаешь?
> Бери программу, замеряйНу вот, например, замерили:
http://www.tomshardware.com/reviews/radeon-hd-7990-review-be...,3486-16.html> в реальности будет одно и тоже. +/- погрешность.
Два последних теста (FP64) вполне отчетливо показывают, что в реальной реальности у 7990 и Titan не совсем одно и то же.
> Ты не переживай, у AMD и Интел, АМД и Нвидия, есть договорённости
> о равномерном высасывания бабла из народа.Остается только вопрос: накукуй обычному народу вообще плавучка в таких количествах? Что они там считать будут? Ну, кроме игр.
А для APU от AMD есть какие-то цифры по производительности в double?
> А для APU от AMD есть какие-то цифры по производительности в double?Цифр нет. Есть _впечатление, что встроенные в АПУ какие-нибудь 6350/7650 [_M_, даже местами, но вторая цифра важнее] вряд дадут больше, чем в 10-5-3+- раз **меньше**, чем топовый дискретный 9990-или-как-там-его.
Чисто с потолка.
Это ясно, но они же для встраиваемых приложений, т.е. другие цели, поэтому супер производительности никто от них и не ждёт, но всё равно, вычислительные ресурсы с плавающей точкой, возможно, могли бы радовать по сравнению с плавающей точкой в CPU.
Чисто ради интереса, есть ли приложение, собранное для х86, в котором используется CUDA? Я не знаю таких, правда. Гугл молчит.
С недавнего времени LibreOffice использует OpenCL, который использует API CUDA на NVIDIA
видеокартах. Darktable тоже.
Не успел обрадоваться поддержке OpenCL, как на тебе.
:(
да NVIDIA правы, надо тоже прекращать поддерживать CUDA
дерьмо а не технология. Всё больше не покупаем CUDу
кто-нить знает адресок фтп сервера нвидии, где можно скачать любой самый древних драйвер?