Pull to refresh

Comments 102

сколько интересно он в мм по размеру будет?)
Остается подождать появления реально работающего 1000-ядерного процессора

Остаётся как-следует распараллелить массовое ПО ещё…
Сказано же: «для серьезных научных разработок»
Большую часть программ можно будет просто запускать по программе на ядро и все.

Распараллеливаться будут только тяжелые приложения, которых не так уж много и они по большей части это уже умеют.
Ну банальные Excel, Word, Firefox, Visual Studio распараллеливаится умеют? Тормозить умеют, значит их следует относить скорее к «тяжёлым» приложениям, чем к «лёгким» (типа текстовых редакторов, где тормозить нечему).
Не замечал тормозов. В принципе, все эти программы так или иначе используют потоки (threads), т.е. уже параллельны.
Не замечал тормозов.

На сколько я понимаю для таких много-много-ядерных процессоров будут характерны более низкие частоты (хорошо если хотябы 1.66-1.83 Ггц, упоминаемые в статье) и существенно меньшие объёмы кэша на ядро (что, мягко говоря, не менее важно). Думаю если более-менее жирненькая программа будет усиленно мучать одно такое ядро, тормоза так или иначе можно будет заметить.
В принципе, все эти программы так или иначе используют потоки (threads), т.е. уже параллельны.

В принципе. Но, думается мне, не очень активно (хотя не проверял, утверждать не буду).
Ещё вопрос в том, что такое для человека тормоза.
а) Субъективно, это когда остальные задачи начинают работать медленнее, когда система занята какой-то крупной и высоко-ресурсоёмкой, снижение отзывчивости т.е.
б) С другой стороны, под тормозами может пониматься медленная работа конкретной задачи вообще.
Так вот, пункт А на этих процессорах, думается мне, будет минимизирован.
Пункт Б действительно решается параллелизацией ресурсоёмких алгоримов.
Каким образом отзывчивость повысится от повышения колличества ядер? Интерфейс в любом случае работает в одном потоке (хотя вроде были эксперименты где каждый виджет — отдельный поток, и довольно давно), в другом потоке (хорошо если потоках) решаются задачи и комуницируют с потоком представления с такой дискретностью, с какой их запрограммировали, плюс ещё как решит шедулер ядра ОС. А сами задачи да, будут решаться быстрее, но тоже только если их специально под это дело распишут. В общем без модификации софта сомневаюсь что что-то станет заметно лучше, сколько ядер ни пихай, а может даже стать хуже (не забываем про уменьшение кэшей ядер и снижение частот).
Что касается кэша, то скорее всего товарищи пойдут по пути почившего в бозе Sun с их ниагарой и IBM: то есть сделают режим, в котором половина процессорных ядер вырубается, а кэш отдается активным ядрам
Файрфокс скоро будет, по типу хрома, использовать multiprocessing, что очень легко по ядрам разводится самой ОС.

Про остальное из того, что вы назвали — не знаю, не пользуюсь. Сомневаюсь честно говоря, у майкрософта постоянно проблемы с догонянием прогресса.

Фотошоп к примеру уже пару версий назад научился несколько ядер использовать. Да и вообще у довольно существенной части софта с этим никаких проблем нет.
UFO just landed and posted this here
Как очень метко в SICP на странице 225 сказали Абельсон и Сассман.

"… Программирование с использованием присваивания заставляет нас тщательно следить за порядком присваиваний, так, чтобы в каждом использовалась правильная версия значения переменных, которые меняются. В функциональных программах такие сложности просто не возникают. Поэтому странно и смешно, что вводные курсы программирования часто читаются в глубоко императивном стиле."

Так же хотелось бы добавить историю знакомого преподавателя про то как школьник не понимал на что ругается компилятор в следующем коде (пример):

printf("%d", i);
int i = 42;

Ведь переменной же присваивается значение.

Таким образом, декларативное функциональное программирование ближе и к распараллеливанию и к школьникам. ;)
И всё бы ничего, если бы не было необходимости обрабатывать изображения, большие матрицы или там банально выводить данные в файл. Мир существенно не функциональный, к счастью.
Ничего из этого во *вводный* курс *программирования* не входит.

И… какая вам разница какой мир? Почему вы считаете, что если бы мир был функциональным, было бы хуже? Думаю, ответа мы никогда не узнаем.
Вопрос не в том, что лучше, а что хуже. Вопрос исключительно в том, что эффективно и адекватно реальности, а что нет. Вот есть у меня такое смутное ощущение, что функционально программирование, не смотря на всю его мощь, выразительность, гибкость и всё такое, не адекватно физической реальности. Вот. Есть для этого некоторые философские основания.

Насчёт вводных курсов… Ну и зачем, спрашивается, человеку мозг форматировать тем, что для реального программирования не очень подходит? Ни наю. Но даже в Lisp в итоге появился сакральный set. Хотя, конечно, если, например, речь идёт о подготовке математика с уклоном в теоретическую математику, то, конечно, вводить его в программирование нужно именно через ФП. При чём, через какой-нибудь особо хардкорный вариант типа Coq. Хотя…

Вот чёрт его знает. Должен ли хороший математик пребывать в безмятежности и вере в то, что алгоритм и в реальной жизни — это машина Тьюринга, и что она универсальная, и что lambda-исчисление это максимум? Так что, может быть, и математика нужно учить ассемблеру, чтобы видел несоответствия.

Но опять же, вопрос в том: кого готовим?
и давно пора бы, хотя при первом знакомстве мозг сильно рвало конечно)
Штирлиц склонился над картой — его сильно рвало на родину
Проще. Все захватят языки высокого уровня в которых параллелизм будет обеспечиваться интерпретатором или виртуальной машиной.

Ну и да, конечно будут гуру, которые будут писать эти интерпретаторы и виртуальные машины.
Возможность паралелить зависит от составителя алгоритма. Такие автопаралелизирующие языки разве что будут искусственно навязывать стили программирования вроде Map/Reduse
Мне вот интересно, как там с кэшем дела обстоят. Пару килобайт на ядро? Или они научились память прямо на кристалл сажать?
Вероятнее всего некий аналог NUMA. Но уже в миниатюре и возможно для кэшей.
UFO just landed and posted this here
Напомнило старый несмешной анекдот про нового русского, у которого вместо кафеля были процессоры в ванной.
расскажите чтоли, заитриговали, я как раз несмешные люблю)
Это в общем-то весь анекдот и есть.
вы знаете, может быть это и нелогично как-то, но я поржал)
— братан, да ты не догоняешь — каждая плитка это двести зеленых…
Ну это анекдот времен, когда на процессорах не было металлической крышки. Просто керамический квадратик с одной стороны с маркировкой.
ну, я так думаю, с металической инкрустацией будет даже прикольнее
Могут его увеличить не в ширину, а в толщину.
Неплохой проект офисного центра вышел :)
Заодно тёплый пол получится. :)
И с замечательным массажным эффектом!
почему-то подумалось про тёплые полы)
Новость хорошая, но мне даже 48 ядер не светит в ближающее года три :)
А так молодцы, не стоят на месте
Там итерация разработки процессора занимает лет 10, так что это еще не скоро.
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
Новость в новости.
Извините, не удержался. Подумал, что эта информация будет не лишней в данной новости.
Действительно интересная информация, спасибо
Вот если бы еще подробнее узнать про динамические кэши…
внизу сайта написано: Copyright © 2001-2009 Overclockers.ru. Копирование материалов сайта запрещено.
далее по ссылке: Мы категорически против перепечатки материалов, размещённых на сайте Overclockers.ru. Наличие ссылки на оригинал не является оправданием для кражи. Если Вам понравилась наша новость или статья, то разместите анонс на своём сайте и дайте ссылку на источник – это будет полезно для Overclockers.ru и приятно автору.

думаю, что диапазон годов 2001-2009 позволяет ))
копирайты вроде на новости не распространяются? (по закону)
Точнее перепечатка их разрешена, указание первоисточника никто не отменял.
Только надо понимать, что Процессоры nVIDIA и процессоры Intel — это разные по своей сути процессоры. И кэши там разные, и вообще всё.

Так что…
нужно уже думать над тем как сделать лучше ядра, а не над тем как их уместить больше на единице площади…
Собственно к наращиванию числа ядер и пришли потому, что уперлись в физические пределы частоты существующих техпроцессов.
я как бы про это и говорю, что порабы новое что-то придумать (принципиально)
уже пора подумать о воспитании Джона Коннара
Поздно. Уже надо его искать и назначать охрану, похоже.
У Эрлангистов сейчас множественные оргазмы, я думаю.
UFO just landed and posted this here
Во-первых, под одно ядро ещё пишут, во-вторых, джависты и скалисты — в глубокой депрессии и качают RWH.
UFO just landed and posted this here
Мой вам совет — избегайте навешивания ярлыков вроде «джавист», особенно на себя, и учите много разных языков. Ни в коем случае не используйте на работе и дома одно и то же. Если, конечно, ваш кодинг не ограничивается рабочим местом. :)
UFO just landed and posted this here
Ну так мир прекрасен! Нет причины пребывать в депрессии. Будут проблемы у платформы Java — попробуете свои силы в продвижении среди заказчиков Erlang'а и подучите ещё что-нибудь модное, Qt, например, которую принято уже считать платформой.
Недавно погрузил в задумчивость AutoCAD2011. Нагрузочка процессора ровно-ровно в 50% намекала, что AutoCAD2011 еще не очень ориентирован на многоядерность. Хотя подобной программе должно быть положено.
UFO just landed and posted this here
640к хватит всем на все времена?
640к ядер? На пару лет хватит еще :)
кэп не дремлет
Советую вам передохнуть.
Это ничего, у линукса теоретический предел пока 4096 :)
а мне вот статья о количестве нейронов в человеческом мозге сразу вспомнилась, может быть уже недолго осталось ждать модели 1:1)
ну я в плане не процессор 1:1 человеческий мозг, а о вычислительной системе подобного сорта
можно и на одном ядре собрать на программной эмуляции «транзисторов головного мозга» — но на 1000 ядер куда как шустрее будет — факт :))
Осталось выяснить, это 1.8Ггц атома или зеона :)
Если мне не изменяет память, 48 ядерный проц был сделан на базе Pentium II.
такой процессор не сможет нормально обрабатывать внешний поток данных, разве что моделировать какую-то постоянную среду, и то, кэш должен быть при каждом ядре
Вот и я о том же думал. Ведь даже 48 ядер, обращающихся по одной шине к памяти, будут друг другу мешать, а про 1000 и говорить нечего. А шину вроде как сложнее расширить, нежели ядер нарезать.
Это зависит от архитектуры шины. На картинках был изображен грид из контроллеров памяти, соединенных своеобразными маршрутизаторами. Если эта картинка не бред пиарастов, то можно предположить технологию по типу NUMA.

Если совсем на пальцах: Оперативная память не монолитная, а модульная. Каждая группа процессоров (скажем 8 штук) имеет свой контроллер памяти и собственно память, физически разведенную к нему. Остальные процессоры обращаются к этому куску памяти опосредованно.

Это позволяет распараллелить работу с памятью ценой бо́льших задержек при далеком обращении и быстром локальном.

Если приложение написано нормально и принцип локальности данных хорошо соблюдается, то это не будет большой проблемой.
С чего бы они друг другу мешали? Процессор разбит на тайлы — к контроллеру памяти имеют доступ крайние тайлы, маршрутизатор в каждом тайле передаёт данные соседям.

Такие процессоры уже доступны коммерчески
ru.wikipedia.org/wiki/Tilera (100 ядер)
первым был 16-ядерный project RAW — IBM, 1997-1999г

Мешают они потому, что пропускная способность шины ограничена, и чтобы все процессоры были при деле, а не ожидали получения данных, они должны иметь либо большие кэши, либо очень широкую шину (чем больше будет ядер — тем сложнее она будет). Даже при разбиении процессора на модули с отдельной памятью и контроллером будут огромные проблемы с разводкой печатной платы для 1000-ядерного проца.
Даже сейчас процы обрабатывают гораздо больше чем позволяет подсистема памяти,
даже GPU. И ничего, как-то работают. В новом GPU от AMD 1920 ядер при 150ГБ/с.
Обьём промежуточных данных обычно гораздо больше входных/выходных. Они прекрасно себе будут жить внутри чипа.

>> Даже при разбиении процессора на модули с отдельной памятью и контроллером
Разные тайлы могут иметь свой контроллер, а могут и общий. Зависит от баланса.

>>будут огромные проблемы с разводкой печатной платы для 1000-ядерного проца.
С какого бока? Внешне он ничем не будет отличаться от 1 ядерного.
Одно дело GPU, другое дело CPU. Вы разберитесь, для начала, в отличиях. В том как они считают, что считают, что могут и не могут считать.
Ядра у CPU — это совершенно не то же самое, что «ядра» у GPU.
Я-то прекрасно представляю.
Т.к. пишу и под GPU и под CELL и под классические CPU.
Вы бы хоть посмотрели как работает Tilera, прежде чем минусовать.

Так какие там проблемы с разводкой платы? =)))))
64 разряда — это 8 байт, на 1000 ядер — 8 кб, при частоте 2 ГГц выходит 16 Тб в секунду — чем они вообще думают?

NVidia говорит, что у них будет за такт 4 операции — это, простите, сколько в бодах? это уже какие-то балабольные понты рассчитанные на хомячков, не больше
Во первых FSB шина так и делает — 4 операции за такт. Уже много лет так.
Во вторых в нынешних около-топовых десктопных материнках скорость трансфера FSB шины, ну допустим 6.4GT/s по 8 байт каждый трансфер = что то около 51 гигабайта в секунду.

Да, для 1000 ядер нужна скорость в ~15-30 раз больше(в зависимости от скорости каждого ядра). Ну и что? Никто ведь не говорит, что они собираются выпустить 1000-ядерный процессор завтра.
Можно в сделать две шины, как это в некоторых материнках для дуал-ксеонов сделано. Вариантов много есть.
Не так всё просто. Контроллеров-то можно, наверное, хоть 20 сделать. Проблема в том, как провода от них разводить к модулям памяти. Там последовательные линии, задержки, всё такое вылезает.
Intel Core Дох* — дох*яядерный процессор!
При 1000 ядер и частоте 1,8 ГГц один процессор сможет снабжать один квартал теплой водой или все же придется установить 2 таких?
Посчитал :)

1000 ядер с тепловыделением, скажем, по 8 ватт (у одноядерного Atom'a со схожей частотой примерно такой TDP, округлял в большую сторону), выдают тепловую мощность 8000 ватт. Чтобы отопить среднестатистическую однушку общей площадью 30 квадратов, надо с батарей рассеивать около 3000 ватт. Если КПД у нас 75%, что оптимистично, то хватит на отопление двух таких квартир. Для надёжности умножим на два, т.к. процессоры не единственный источник тепла в системе. Итого: можно отопить 120 квадратов жилья.
А сколько АЛУ в современных видеокартах? Уже давно больше 1000.

ИнтЕл просто судорожно хочет сделать какой-нить AMD\nVidia подобный видеочип, на которых сейчас серьёзные вещи и считают. А поддержка x86 инструкций… нужна ли она вообще?
>А сколько АЛУ в современных видеокартах? Уже давно больше 1000.

Они там маааленькие
Вы правда думаете, что видео-чипы выйдут победителями сражения с intel? Вы, к сожалению, очень ошибаетесь.
Область моей деятельности связана с вычислительной гидро- и аэро-динамикой.

Первое, я не знаю, что должно произойти, чтобы ученые взяли свои библиотеки написанные на фортране лет 10-20 назад и переписали под новые условия. Эти библиотеки написаны не на С++, и не на Java, и даже не на обычном С — они написаны на fortran-е, причем так, что напрямую на видеочипы не переносятся.

Второе, казалось бы, новые технологии должны заставить ученых шевелиться и переписывать, но там безумное количество формул, в которых каждый символ отлажен и выверен годами. При переносе появятся сразу ошибки, которые быстро не выявятся.

Третье, новые алгоритмы, оптимизированные под видео-чипы, требует математического доказательства. Учитывая методы выполнения расчетов на видеокартах, получается нетривиальная задача.

Четвертое, сейчас большинство используют MPI и OpenMP. При выходе даже 48миядерного процессора от intel — эти средства будут быстро оптимизированы под новые условия — старые программы продолжат свою работу.

Пятое, количество реальных потоков в современных видеокартах, то есть на которых можно запустить счет, составляет 10-ки. Например, у меня в институте на новом супере (гибридный, то есть видеокарты и обычные процессоры на узлах) в видеокарту помещается не больше 32 таких потоков (а по-моему все-таки 16, но точно не помню). И сравнить с аналогичным по производительности 48миядерником, где мы, в отличии от видео-чипов, можем управлять каждым ядром, то видео-чипы смотрятся как-то бледно.

Мое мнение в итоге: на данный момент, из-за остановки роста производительности процессоров по частоте и смещения акцента в сторону многоядерности, видео-чипы выглядят привлекательнее для научных разработок. Но я думаю пройдет пару лет, интел выпустит свои многоядерники на рынок, доступный научным организациям и видео-чипы будут вытеснены.
Отлично! Скоро можно будет ИНС запустить в параллель ;)
Где-нибудь в Pixar и DreamWorks уже судорожно потерают руки.
Не факт. Натыкать столько ядер на кристал — не проблема. Проблема в том, как эти ядра накормить данными. Если у вас будет 1000 ядер, но каждое будет активно работать только .1% времени. То тольку-то от этой тысячи? Нужна существенно неоднородная архитектура. Хм. Вот. Хотя, наверное Pixar умеет рендерить на кластерах.
Как же будет выглядеть диспетчер задач Windows? :)
chrome.exe ядро 987 занято памяти: 640K загрузка процессора: 1%
firefox.exe ядра 200-736 занято памяти: 640K загрузка процессора: 536%
=)
О! Еще один шаг к Skynet :)
Не такой ли проц сидел в башке у Шварца?
UFO just landed and posted this here
Sign up to leave a comment.

Articles