Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 102
сколько интересно он в мм по размеру будет?)
Остается подождать появления реально работающего 1000-ядерного процессора
Остаётся как-следует распараллелить массовое ПО ещё…
Сказано же: «для серьезных научных разработок»
Большую часть программ можно будет просто запускать по программе на ядро и все.
Распараллеливаться будут только тяжелые приложения, которых не так уж много и они по большей части это уже умеют.
Распараллеливаться будут только тяжелые приложения, которых не так уж много и они по большей части это уже умеют.
Ну банальные Excel, Word, Firefox, Visual Studio распараллеливаится умеют? Тормозить умеют, значит их следует относить скорее к «тяжёлым» приложениям, чем к «лёгким» (типа текстовых редакторов, где тормозить нечему).
Не замечал тормозов. В принципе, все эти программы так или иначе используют потоки (threads), т.е. уже параллельны.
Не замечал тормозов.
На сколько я понимаю для таких много-много-ядерных процессоров будут характерны более низкие частоты (хорошо если хотябы 1.66-1.83 Ггц, упоминаемые в статье) и существенно меньшие объёмы кэша на ядро (что, мягко говоря, не менее важно). Думаю если более-менее жирненькая программа будет усиленно мучать одно такое ядро, тормоза так или иначе можно будет заметить.
В принципе, все эти программы так или иначе используют потоки (threads), т.е. уже параллельны.
В принципе. Но, думается мне, не очень активно (хотя не проверял, утверждать не буду).
Ещё вопрос в том, что такое для человека тормоза.
а) Субъективно, это когда остальные задачи начинают работать медленнее, когда система занята какой-то крупной и высоко-ресурсоёмкой, снижение отзывчивости т.е.
б) С другой стороны, под тормозами может пониматься медленная работа конкретной задачи вообще.
Так вот, пункт А на этих процессорах, думается мне, будет минимизирован.
Пункт Б действительно решается параллелизацией ресурсоёмких алгоримов.
а) Субъективно, это когда остальные задачи начинают работать медленнее, когда система занята какой-то крупной и высоко-ресурсоёмкой, снижение отзывчивости т.е.
б) С другой стороны, под тормозами может пониматься медленная работа конкретной задачи вообще.
Так вот, пункт А на этих процессорах, думается мне, будет минимизирован.
Пункт Б действительно решается параллелизацией ресурсоёмких алгоримов.
Каким образом отзывчивость повысится от повышения колличества ядер? Интерфейс в любом случае работает в одном потоке (хотя вроде были эксперименты где каждый виджет — отдельный поток, и довольно давно), в другом потоке (хорошо если потоках) решаются задачи и комуницируют с потоком представления с такой дискретностью, с какой их запрограммировали, плюс ещё как решит шедулер ядра ОС. А сами задачи да, будут решаться быстрее, но тоже только если их специально под это дело распишут. В общем без модификации софта сомневаюсь что что-то станет заметно лучше, сколько ядер ни пихай, а может даже стать хуже (не забываем про уменьшение кэшей ядер и снижение частот).
Что касается кэша, то скорее всего товарищи пойдут по пути почившего в бозе Sun с их ниагарой и IBM: то есть сделают режим, в котором половина процессорных ядер вырубается, а кэш отдается активным ядрам
Файрфокс скоро будет, по типу хрома, использовать multiprocessing, что очень легко по ядрам разводится самой ОС.
Про остальное из того, что вы назвали — не знаю, не пользуюсь. Сомневаюсь честно говоря, у майкрософта постоянно проблемы с догонянием прогресса.
Фотошоп к примеру уже пару версий назад научился несколько ядер использовать. Да и вообще у довольно существенной части софта с этим никаких проблем нет.
Про остальное из того, что вы назвали — не знаю, не пользуюсь. Сомневаюсь честно говоря, у майкрософта постоянно проблемы с догонянием прогресса.
Фотошоп к примеру уже пару версий назад научился несколько ядер использовать. Да и вообще у довольно существенной части софта с этим никаких проблем нет.
Банальный Excel умеет распараллелиться и работать на кластере.
www.microsoft.com/downloads/en/details.aspx?FamilyID=F134B503-3E55-4E3C-8A01-95264B46B8F1
www.microsoft.com/downloads/en/details.aspx?FamilyID=F134B503-3E55-4E3C-8A01-95264B46B8F1
Как очень метко в SICP на странице 225 сказали Абельсон и Сассман.
"… Программирование с использованием присваивания заставляет нас тщательно следить за порядком присваиваний, так, чтобы в каждом использовалась правильная версия значения переменных, которые меняются. В функциональных программах такие сложности просто не возникают. Поэтому странно и смешно, что вводные курсы программирования часто читаются в глубоко императивном стиле."
Так же хотелось бы добавить историю знакомого преподавателя про то как школьник не понимал на что ругается компилятор в следующем коде (пример):
printf("%d", i);
int i = 42;
Ведь переменной же присваивается значение.
Таким образом, декларативное функциональное программирование ближе и к распараллеливанию и к школьникам. ;)
"… Программирование с использованием присваивания заставляет нас тщательно следить за порядком присваиваний, так, чтобы в каждом использовалась правильная версия значения переменных, которые меняются. В функциональных программах такие сложности просто не возникают. Поэтому странно и смешно, что вводные курсы программирования часто читаются в глубоко императивном стиле."
Так же хотелось бы добавить историю знакомого преподавателя про то как школьник не понимал на что ругается компилятор в следующем коде (пример):
printf("%d", i);
int i = 42;
Ведь переменной же присваивается значение.
Таким образом, декларативное функциональное программирование ближе и к распараллеливанию и к школьникам. ;)
И всё бы ничего, если бы не было необходимости обрабатывать изображения, большие матрицы или там банально выводить данные в файл. Мир существенно не функциональный, к счастью.
Ничего из этого во *вводный* курс *программирования* не входит.
И… какая вам разница какой мир? Почему вы считаете, что если бы мир был функциональным, было бы хуже? Думаю, ответа мы никогда не узнаем.
И… какая вам разница какой мир? Почему вы считаете, что если бы мир был функциональным, было бы хуже? Думаю, ответа мы никогда не узнаем.
Вопрос не в том, что лучше, а что хуже. Вопрос исключительно в том, что эффективно и адекватно реальности, а что нет. Вот есть у меня такое смутное ощущение, что функционально программирование, не смотря на всю его мощь, выразительность, гибкость и всё такое, не адекватно физической реальности. Вот. Есть для этого некоторые философские основания.
Насчёт вводных курсов… Ну и зачем, спрашивается, человеку мозг форматировать тем, что для реального программирования не очень подходит? Ни наю. Но даже в Lisp в итоге появился сакральный set. Хотя, конечно, если, например, речь идёт о подготовке математика с уклоном в теоретическую математику, то, конечно, вводить его в программирование нужно именно через ФП. При чём, через какой-нибудь особо хардкорный вариант типа Coq. Хотя…
Вот чёрт его знает. Должен ли хороший математик пребывать в безмятежности и вере в то, что алгоритм и в реальной жизни — это машина Тьюринга, и что она универсальная, и что lambda-исчисление это максимум? Так что, может быть, и математика нужно учить ассемблеру, чтобы видел несоответствия.
Но опять же, вопрос в том: кого готовим?
Насчёт вводных курсов… Ну и зачем, спрашивается, человеку мозг форматировать тем, что для реального программирования не очень подходит? Ни наю. Но даже в Lisp в итоге появился сакральный set. Хотя, конечно, если, например, речь идёт о подготовке математика с уклоном в теоретическую математику, то, конечно, вводить его в программирование нужно именно через ФП. При чём, через какой-нибудь особо хардкорный вариант типа Coq. Хотя…
Вот чёрт его знает. Должен ли хороший математик пребывать в безмятежности и вере в то, что алгоритм и в реальной жизни — это машина Тьюринга, и что она универсальная, и что lambda-исчисление это максимум? Так что, может быть, и математика нужно учить ассемблеру, чтобы видел несоответствия.
Но опять же, вопрос в том: кого готовим?
и давно пора бы, хотя при первом знакомстве мозг сильно рвало конечно)
Проще. Все захватят языки высокого уровня в которых параллелизм будет обеспечиваться интерпретатором или виртуальной машиной.
Ну и да, конечно будут гуру, которые будут писать эти интерпретаторы и виртуальные машины.
Ну и да, конечно будут гуру, которые будут писать эти интерпретаторы и виртуальные машины.
Мне вот интересно, как там с кэшем дела обстоят. Пару килобайт на ядро? Или они научились память прямо на кристалл сажать?
Новость хорошая, но мне даже 48 ядер не светит в ближающее года три :)
А так молодцы, не стоят на месте
А так молодцы, не стоят на месте
NVIDIA рассказывает о процессоре с 1000 ядрами
Участие тех или иных суперкомпьютеров в рейтинге мощнейших систем мира уже становится поводом для соперничества между производителями центральных процессоров и графических решений, которые в подобных системах играют роль ускорителей вычислений. Примечательно, что активно использующие графические ускорители суперкомпьютеры уже занимают лидирующие позиции в соответствующем рейтинге, и отрицать их значимость для отрасли просто бесполезно.
Министерство обороны США тоже стимулирует разработки в сфере совершенствования архитектуры суперкомпьютеров, поскольку к 2018 году это ведомство рассчитывает получить компоненты для создания суперкомпьютера, способного осуществлять вычисления со скоростью в тысячи петафлопс. В объявленном американцами конкурсе уже участвуют команды Intel, NVIDIA и двух национальных научных лабораторий.
Команда NVIDIA, если верить сообщениям ресурса EE Times, на этой неделе решила поделиться с общественностью концептуальным описанием процессора с тысячью ядрами, который обладает производительностью на уровне 10 терафлопс. Проект получил условное обозначение Echelon.
Каждое из восьми вычислительных ядер, объединяемых в один потоковый модуль, может выполнять операцию с плавающей запятой, затрачивая лишь 10 пикоджоулей энергии — это в двадцать раз меньше, чем у современных графических решений семейства Fermi. Один процессор может содержать до 128 потоковых модулей, состоящих из восьми ядер. Таким образом, в совокупности чип Echelon может иметь тысячу ядер — 1024 штуки, если быть точнее. За один цикл каждое ядро может выполнять четыре операции с плавающей запятой двойной точности. Современные продукты NVIDIA за цикл выполняют только одну такую операцию.
Echelon получит специфическую архитектуру кэш-памяти. Все 256 мегабайт «набортной» памяти типа SRAM могут динамически перестраиваться, разделяясь на шесть уровней кэша, причём каждый блок может иметь переменный объём. Вычислительные блоки чипа могут делиться с «соседями» той частью информации, которая ими тоже востребована. Нельзя утверждать, что проект Echelon обязательно будет реализован в таком виде, но ценные наработки обязательно пригодятся компании NVIDIA при создании других продуктов. Восьмиядерный процессор с такой архитектурой вполне может стать основой для смартфона, как считают в NVIDIA.
via Overclockers.ru
Участие тех или иных суперкомпьютеров в рейтинге мощнейших систем мира уже становится поводом для соперничества между производителями центральных процессоров и графических решений, которые в подобных системах играют роль ускорителей вычислений. Примечательно, что активно использующие графические ускорители суперкомпьютеры уже занимают лидирующие позиции в соответствующем рейтинге, и отрицать их значимость для отрасли просто бесполезно.
Министерство обороны США тоже стимулирует разработки в сфере совершенствования архитектуры суперкомпьютеров, поскольку к 2018 году это ведомство рассчитывает получить компоненты для создания суперкомпьютера, способного осуществлять вычисления со скоростью в тысячи петафлопс. В объявленном американцами конкурсе уже участвуют команды Intel, NVIDIA и двух национальных научных лабораторий.
Команда NVIDIA, если верить сообщениям ресурса EE Times, на этой неделе решила поделиться с общественностью концептуальным описанием процессора с тысячью ядрами, который обладает производительностью на уровне 10 терафлопс. Проект получил условное обозначение Echelon.
Каждое из восьми вычислительных ядер, объединяемых в один потоковый модуль, может выполнять операцию с плавающей запятой, затрачивая лишь 10 пикоджоулей энергии — это в двадцать раз меньше, чем у современных графических решений семейства Fermi. Один процессор может содержать до 128 потоковых модулей, состоящих из восьми ядер. Таким образом, в совокупности чип Echelon может иметь тысячу ядер — 1024 штуки, если быть точнее. За один цикл каждое ядро может выполнять четыре операции с плавающей запятой двойной точности. Современные продукты NVIDIA за цикл выполняют только одну такую операцию.
Echelon получит специфическую архитектуру кэш-памяти. Все 256 мегабайт «набортной» памяти типа SRAM могут динамически перестраиваться, разделяясь на шесть уровней кэша, причём каждый блок может иметь переменный объём. Вычислительные блоки чипа могут делиться с «соседями» той частью информации, которая ими тоже востребована. Нельзя утверждать, что проект Echelon обязательно будет реализован в таком виде, но ценные наработки обязательно пригодятся компании NVIDIA при создании других продуктов. Восьмиядерный процессор с такой архитектурой вполне может стать основой для смартфона, как считают в NVIDIA.
via Overclockers.ru
Новость в новости.
Echelon? Сразу вспоминается Echelon Conspiracy.
внизу сайта написано: Copyright © 2001-2009 Overclockers.ru. Копирование материалов сайта запрещено.
далее по ссылке: Мы категорически против перепечатки материалов, размещённых на сайте Overclockers.ru. Наличие ссылки на оригинал не является оправданием для кражи. Если Вам понравилась наша новость или статья, то разместите анонс на своём сайте и дайте ссылку на источник – это будет полезно для Overclockers.ru и приятно автору.
думаю, что диапазон годов 2001-2009 позволяет ))
далее по ссылке: Мы категорически против перепечатки материалов, размещённых на сайте Overclockers.ru. Наличие ссылки на оригинал не является оправданием для кражи. Если Вам понравилась наша новость или статья, то разместите анонс на своём сайте и дайте ссылку на источник – это будет полезно для Overclockers.ru и приятно автору.
думаю, что диапазон годов 2001-2009 позволяет ))
Только надо понимать, что Процессоры nVIDIA и процессоры Intel — это разные по своей сути процессоры. И кэши там разные, и вообще всё.
Так что…
Так что…
нужно уже думать над тем как сделать лучше ядра, а не над тем как их уместить больше на единице площади…
уже пора подумать о воспитании Джона Коннара
У Эрлангистов сейчас множественные оргазмы, я думаю.
Во-первых, под одно ядро ещё пишут, во-вторых, джависты и скалисты — в глубокой депрессии и качают RWH.
Недавно погрузил в задумчивость AutoCAD2011. Нагрузочка процессора ровно-ровно в 50% намекала, что AutoCAD2011 еще не очень ориентирован на многоядерность. Хотя подобной программе должно быть положено.
640к хватит всем на все времена?
640к ядер? На пару лет хватит еще :)
>> 640K ought to be enough for anybody © en.wikiquote.org/wiki/Bill_Gates
Это ничего, у линукса теоретический предел пока 4096 :)
а мне вот статья о количестве нейронов в человеческом мозге сразу вспомнилась, может быть уже недолго осталось ждать модели 1:1)
Осталось выяснить, это 1.8Ггц атома или зеона :)
такой процессор не сможет нормально обрабатывать внешний поток данных, разве что моделировать какую-то постоянную среду, и то, кэш должен быть при каждом ядре
Вот и я о том же думал. Ведь даже 48 ядер, обращающихся по одной шине к памяти, будут друг другу мешать, а про 1000 и говорить нечего. А шину вроде как сложнее расширить, нежели ядер нарезать.
Это зависит от архитектуры шины. На картинках был изображен грид из контроллеров памяти, соединенных своеобразными маршрутизаторами. Если эта картинка не бред пиарастов, то можно предположить технологию по типу NUMA.
Если совсем на пальцах: Оперативная память не монолитная, а модульная. Каждая группа процессоров (скажем 8 штук) имеет свой контроллер памяти и собственно память, физически разведенную к нему. Остальные процессоры обращаются к этому куску памяти опосредованно.
Это позволяет распараллелить работу с памятью ценой бо́льших задержек при далеком обращении и быстром локальном.
Если приложение написано нормально и принцип локальности данных хорошо соблюдается, то это не будет большой проблемой.
Если совсем на пальцах: Оперативная память не монолитная, а модульная. Каждая группа процессоров (скажем 8 штук) имеет свой контроллер памяти и собственно память, физически разведенную к нему. Остальные процессоры обращаются к этому куску памяти опосредованно.
Это позволяет распараллелить работу с памятью ценой бо́льших задержек при далеком обращении и быстром локальном.
Если приложение написано нормально и принцип локальности данных хорошо соблюдается, то это не будет большой проблемой.
С чего бы они друг другу мешали? Процессор разбит на тайлы — к контроллеру памяти имеют доступ крайние тайлы, маршрутизатор в каждом тайле передаёт данные соседям.
Такие процессоры уже доступны коммерчески
ru.wikipedia.org/wiki/Tilera (100 ядер)
первым был 16-ядерный project RAW — IBM, 1997-1999г
Такие процессоры уже доступны коммерчески
ru.wikipedia.org/wiki/Tilera (100 ядер)
первым был 16-ядерный project RAW — IBM, 1997-1999г
Мешают они потому, что пропускная способность шины ограничена, и чтобы все процессоры были при деле, а не ожидали получения данных, они должны иметь либо большие кэши, либо очень широкую шину (чем больше будет ядер — тем сложнее она будет). Даже при разбиении процессора на модули с отдельной памятью и контроллером будут огромные проблемы с разводкой печатной платы для 1000-ядерного проца.
Даже сейчас процы обрабатывают гораздо больше чем позволяет подсистема памяти,
даже GPU. И ничего, как-то работают. В новом GPU от AMD 1920 ядер при 150ГБ/с.
Обьём промежуточных данных обычно гораздо больше входных/выходных. Они прекрасно себе будут жить внутри чипа.
>> Даже при разбиении процессора на модули с отдельной памятью и контроллером
Разные тайлы могут иметь свой контроллер, а могут и общий. Зависит от баланса.
>>будут огромные проблемы с разводкой печатной платы для 1000-ядерного проца.
С какого бока? Внешне он ничем не будет отличаться от 1 ядерного.
даже GPU. И ничего, как-то работают. В новом GPU от AMD 1920 ядер при 150ГБ/с.
Обьём промежуточных данных обычно гораздо больше входных/выходных. Они прекрасно себе будут жить внутри чипа.
>> Даже при разбиении процессора на модули с отдельной памятью и контроллером
Разные тайлы могут иметь свой контроллер, а могут и общий. Зависит от баланса.
>>будут огромные проблемы с разводкой печатной платы для 1000-ядерного проца.
С какого бока? Внешне он ничем не будет отличаться от 1 ядерного.
64 разряда — это 8 байт, на 1000 ядер — 8 кб, при частоте 2 ГГц выходит 16 Тб в секунду — чем они вообще думают?
NVidia говорит, что у них будет за такт 4 операции — это, простите, сколько в бодах? это уже какие-то балабольные понты рассчитанные на хомячков, не больше
NVidia говорит, что у них будет за такт 4 операции — это, простите, сколько в бодах? это уже какие-то балабольные понты рассчитанные на хомячков, не больше
Во первых FSB шина так и делает — 4 операции за такт. Уже много лет так.
Во вторых в нынешних около-топовых десктопных материнках скорость трансфера FSB шины, ну допустим 6.4GT/s по 8 байт каждый трансфер = что то около 51 гигабайта в секунду.
Да, для 1000 ядер нужна скорость в ~15-30 раз больше(в зависимости от скорости каждого ядра). Ну и что? Никто ведь не говорит, что они собираются выпустить 1000-ядерный процессор завтра.
Можно в сделать две шины, как это в некоторых материнках для дуал-ксеонов сделано. Вариантов много есть.
Во вторых в нынешних около-топовых десктопных материнках скорость трансфера FSB шины, ну допустим 6.4GT/s по 8 байт каждый трансфер = что то около 51 гигабайта в секунду.
Да, для 1000 ядер нужна скорость в ~15-30 раз больше(в зависимости от скорости каждого ядра). Ну и что? Никто ведь не говорит, что они собираются выпустить 1000-ядерный процессор завтра.
Можно в сделать две шины, как это в некоторых материнках для дуал-ксеонов сделано. Вариантов много есть.
О, для рендеринга это просто рай. =)
слава лераби не дает им покоя
Intel Core Дох* — дох*яядерный процессор!
При 1000 ядер и частоте 1,8 ГГц один процессор сможет снабжать один квартал теплой водой или все же придется установить 2 таких?
Посчитал :)
1000 ядер с тепловыделением, скажем, по 8 ватт (у одноядерного Atom'a со схожей частотой примерно такой TDP, округлял в большую сторону), выдают тепловую мощность 8000 ватт. Чтобы отопить среднестатистическую однушку общей площадью 30 квадратов, надо с батарей рассеивать около 3000 ватт. Если КПД у нас 75%, что оптимистично, то хватит на отопление двух таких квартир. Для надёжности умножим на два, т.к. процессоры не единственный источник тепла в системе. Итого: можно отопить 120 квадратов жилья.
1000 ядер с тепловыделением, скажем, по 8 ватт (у одноядерного Atom'a со схожей частотой примерно такой TDP, округлял в большую сторону), выдают тепловую мощность 8000 ватт. Чтобы отопить среднестатистическую однушку общей площадью 30 квадратов, надо с батарей рассеивать около 3000 ватт. Если КПД у нас 75%, что оптимистично, то хватит на отопление двух таких квартир. Для надёжности умножим на два, т.к. процессоры не единственный источник тепла в системе. Итого: можно отопить 120 квадратов жилья.
А сколько АЛУ в современных видеокартах? Уже давно больше 1000.
ИнтЕл просто судорожно хочет сделать какой-нить AMD\nVidia подобный видеочип, на которых сейчас серьёзные вещи и считают. А поддержка x86 инструкций… нужна ли она вообще?
ИнтЕл просто судорожно хочет сделать какой-нить AMD\nVidia подобный видеочип, на которых сейчас серьёзные вещи и считают. А поддержка x86 инструкций… нужна ли она вообще?
>А сколько АЛУ в современных видеокартах? Уже давно больше 1000.
Они там маааленькие
Они там маааленькие
Вы правда думаете, что видео-чипы выйдут победителями сражения с intel? Вы, к сожалению, очень ошибаетесь.
Область моей деятельности связана с вычислительной гидро- и аэро-динамикой.
Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.
Второе, казалось бы, новые технологии должны заставить ученых шевелиться и переписывать, но там безумное количество формул, в которых каждый символ отлажен и выверен годами. При переносе появятся сразу ошибки, которые быстро не выявятся.
Третье, новые алгоритмы, оптимизированные под видео-чипы, требует математического доказательства. Учитывая методы выполнения расчетов на видеокартах, получается нетривиальная задача.
Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.
Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридный, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.
Мое мнение в итоге: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, интел выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены.
Область моей деятельности связана с вычислительной гидро- и аэро-динамикой.
Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.
Второе, казалось бы, новые технологии должны заставить ученых шевелиться и переписывать, но там безумное количество формул, в которых каждый символ отлажен и выверен годами. При переносе появятся сразу ошибки, которые быстро не выявятся.
Третье, новые алгоритмы, оптимизированные под видео-чипы, требует математического доказательства. Учитывая методы выполнения расчетов на видеокартах, получается нетривиальная задача.
Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.
Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридный, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.
Мое мнение в итоге: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, интел выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены.
Отлично! Скоро можно будет ИНС запустить в параллель ;)
Где-нибудь в Pixar и DreamWorks уже судорожно потерают руки.
Не факт. Натыкать столько ядер на кристал — не проблема. Проблема в том, как эти ядра накормить данными. Если у вас будет 1000 ядер, но каждое будет активно работать только .1% времени. То тольку-то от этой тысячи? Нужна существенно неоднородная архитектура. Хм. Вот. Хотя, наверное Pixar умеет рендерить на кластерах.
Как же будет выглядеть диспетчер задач Windows? :)
О! Еще один шаг к Skynet :)
Не такой ли проц сидел в башке у Шварца?
Не такой ли проц сидел в башке у Шварца?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В Intel работают над созданием 1000-ядерного процессора