T>>Память вредна. T>>Поток данных — data flow, — полезен.
E>Где-то уже были аннонсированы версии Windows, Linux, Solaris, FreeBSD, заточенных под архитектуры с data flow?
Это ты что хотел сказать?
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[5]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, thesz, Вы писали:
T>>>Память вредна. T>>>Поток данных — data flow, — полезен.
E>>Где-то уже были аннонсированы версии Windows, Linux, Solaris, FreeBSD, заточенных под архитектуры с data flow?
T>Это ты что хотел сказать?
подозреваю это был намек на тонкое обстоятельство что пока не будет операционных систем хоть как-то поддерживающих то dataflow ничего не светит
Re[5]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, thesz, Вы писали:
T>>>Память вредна. T>>>Поток данных — data flow, — полезен.
R>>Там проблем ещё больше. Нет?
T>Нет.
R>>И знаешь как говорится: лучше двое старых граблей, чем одни новые.
T>Двое новых граблей, обычно, имеют длину рукоятки чуть меньше, чем по пояс.
Здравствуйте, thesz, Вы писали:
R>>Плюс, Niagara II имеет 64 аппаратных потока.
T>Там задача другая. А вот числодробилка от Sun под названием Rock
будет иметь поменьше потоков.
Задача другая чем у чего? Чем у массовых процессоров?
R>>С памятью — это известная проблема. Некоторые алгоритмы даже и на
одном ядре в память упираются.
T>Cache oblivious algorithms to the rescue?
Какой Cache oblivious алгоритм сложения массивов?
R>>По-поводу того, что люди думают. Думают о разном. R>>Думают и о "сэндвичных" архитектурах, где ядра перемешаны с
локальной памятью. Прецеденты уже имеются. Да и IBM Cell BE в
некотором роде такая архитектура.
T>Проблемы с компиляцией.
Ты пытался копилировать под него "обычную" программу? И надеялся, что
она будет хорошо работать?
R>>Думают о NUMA, т.е. в ядре имеется несколько контроллеров памяти,
каждый присоединён к своей локальной памяти — очевидная
масштабируемость пропускной способности к памяти.
T>Сложность реализации и балансировки.
А у dataflow значит нет проблем со сложность реализации и других. Ну здорово! Жалко, что мужики ещё не знают, и всё ещё мутят там какие-то подходы для увеличения гранулярности, прикручивают явный поток управления на высоком уровне и т.д. Память-то, кстати, тоже у всех dataflow процессоров общего назначения имеется.
П можешь привести хоть один промышленный dataflow процессор общего назначения (не спец. кристалл и не ПЛИС), который использует dataflow и на высоком и на низком уровне? Если это такая замечательная штука без проблема, должны же быть какие-то.
R>>Думают о неоднородных архитектурах. Причём неоднородных как по
функциональным возможностям, так и по тактовой частот. Т.е. в
процессоре несколько ядер, но они различаются по поддерживаим функциям
и/или частоте. Опять же Cell BE.
T>Проблемы с компиляцией.
Никто обратного и не утверждает. Проблем с компиляцией нет только у симметричных многоядерных императивных процессоров.
R>>Думают, что в них добавлять — то ли HTM, то ли аппаратную поддержку
обмена сообщениями. Кстати, аппаратный обмен сообщениями тоже поможет
решить проблему пропускной способности — ядра будут обмениваться
данными не через память, а напрямую. Т.е. такой мини-кластер на
процессоре (CoC — Cluster on a Chip).
T>О! Неужто до data flow додумались?..
А ты думал, ты один в мире про dataflow знаешь? Ты никакого prior art не видел?
R>>Но я думаю, что часть "транзисторного потенциала" в контексте
массовых процессоров в следующую декаду будет так же потрачена на
интеграцию "перифирии" в процессоры. Т.е. прямо в процессоре будет
графический процессор, аудио процессор, сетевая карта + ряд
специализированных ускорителей (XML).
T>Смысла нет. Кристалл растёт, выход рабочих образцом уменьшается.
Очень дорого так делать.
T>Я бы ставил на обратное — на микросборки и межкристальный обмен
наподобие HyperTransport.
Кристалл и так будет расти. Или ты ставишь на то, что со следующего года число транзисторов не будет расти?
Если ты не заметил, то на кристалл уже затащили всё, что было рядом — сопроцессоры, кэши, контроллеры памяти, контроллеры меж-процессорного взаимодействия (этот же HyperTransport и QPI). Ну и кто жалуется?
R>> Что ещё надо производителям ноут/нет-буков? При этом
неиспользуемые ядра графического процессора могут прозрачно
использовтаься как обычные ядра. А сетевая карта будет закачивать
данные прямо в кэш процессора.
T>Вот в ноутбуке это прямо-таки необходимо, ага.
T>Ну, ладно, не буду мешать полёту мысли.
Забавно слышать про полёт мысли от человека, который помешан на dataflow и пророчит ему мировое господство
Здравствуйте, remark, Вы писали:
R>Но я думаю, что часть "транзисторного потенциала" в контексте массовых процессоров в следующую декаду будет так же потрачена на интеграцию "перифирии" в процессоры. Т.е. прямо в процессоре будет графический процессор, аудио процессор, сетевая карта + ряд специализированных ускорителей (XML). Что ещё надо производителям ноут/нет-буков? При этом неиспользуемые ядра графического процессора могут прозрачно использовтаься как обычные ядра. А сетевая карта будет закачивать данные прямо в кэш процессора.
Ох сомнения берут. Например аудио процессор... ну так, для поддержки какого-нибудь AC97 ещё куда ни шло. Что б было. А если по серьёзнее взяться — то оно сразу же не подходит, выключается, душится и забывается что там такое есть.
Ну и получается что привет внешним устройствам на FireWire, PCI и т.п.
С другими компонентами думаю приблизительно так же...
Re[4]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, remark, Вы писали:
R>>Но я думаю, что часть "транзисторного потенциала" в контексте массовых процессоров в следующую декаду будет так же потрачена на интеграцию "перифирии" в процессоры. Т.е. прямо в процессоре будет графический процессор, аудио процессор, сетевая карта + ряд специализированных ускорителей (XML). Что ещё надо производителям ноут/нет-буков? При этом неиспользуемые ядра графического процессора могут прозрачно использовтаься как обычные ядра. А сетевая карта будет закачивать данные прямо в кэш процессора.
F> Ох сомнения берут. Например аудио процессор... ну так, для поддержки какого-нибудь AC97 ещё куда ни шло. Что б было. А если по серьёзнее взяться — то оно сразу же не подходит, выключается, душится и забывается что там такое есть. F>Ну и получается что привет внешним устройствам на FireWire, PCI и т.п.
Ну а подавляющее большинство сейчас посерьёзнее и не берётся. Аудио карта и на материнке, так, вообще-то по-хорошему — сакс. Но ведь использует огромное кол-во людей.
Понятно, что это решение не для профессиональных музыкантов, а так просто — в игрушки поиграть или на неприхотливое ухо.
F>С другими компонентами думаю приблизительно так же...
Здравствуйте, remark, Вы писали:
R>Ну а подавляющее большинство сейчас посерьёзнее и не берётся. Аудио карта и на материнке, так, вообще-то по-хорошему — сакс. Но ведь использует огромное кол-во людей. R>Понятно, что это решение не для профессиональных музыкантов, а так просто — в игрушки поиграть или на неприхотливое ухо.
Ну и неплохое решение кстати. Можно музыку послушать, вот например на работе.
F>>С другими компонентами думаю приблизительно так же... R>А более конкретно? Что ты имеешь в виду?
Ну приблизительно тоже самое имею ввиду и с видео. Одним и встроенной хватает — другим нет. Третьим нужна какая-то третья.
Миру —
Re[6]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, thesz, Вы писали:
T>>>>Память вредна. T>>>>Поток данных — data flow, — полезен.
E>>>Где-то уже были аннонсированы версии Windows, Linux, Solaris, FreeBSD, заточенных под архитектуры с data flow?
T>>Это ты что хотел сказать?
SD>подозреваю это был намек на тонкое обстоятельство что пока не будет операционных систем хоть как-то поддерживающих то dataflow ничего не светит
data flow — это архитектура процессора.
Типа суперскаляра.
Вот скажи, много ли потребовалось от windows для поддержки суперскалярных архитектур наподобие Пентиума?
Вот от компиляторов потребовалось.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Может массовых процессоров 32+ ядрами и не будет?
T>>Это ты что хотел сказать?
E>То, что серьезные революции в аппаратуре могут не выжить, если для них не будет серьезной поддержки со стороны доминирующих ОС.
Суперскаляр выжил, значит, и другие смогут.
data flow такая же странная архитектура, как и суперскаляр.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[6]: Может массовых процессоров 32+ ядрами и не будет?
R>>>И знаешь как говорится: лучше двое старых граблей, чем одни новые. T>>Двое новых граблей, обычно, имеют длину рукоятки чуть меньше, чем по пояс. R>Именно!
Это у тебя все аргументы такие? Типа, "вдвое большее число вдвое худших обстоятельств лучше, как говорится, чем одно привычное".
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
SEAForth хорошо заточен под так называемые систолические алгоритмы (systolic). В новой драконовской книге они названы "конвейерными".
Далеко не все алгоритмы могут быть разложены таким образом. Рекурсивные — точно не могут, алгоритмы на массивах — с большим трудом.
Далее, автором является Chuck Moore (c18, хе!), а он, при всём уважении к его заслугам, не трудится сделать жизнь обычных людей хоть чуть более простой.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[7]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, thesz, Вы писали:
R>>>>И знаешь как говорится: лучше двое старых граблей, чем одни новые. T>>>Двое новых граблей, обычно, имеют длину рукоятки чуть меньше, чем по пояс. R>>Именно!
T>Это у тебя все аргументы такие? Типа, "вдвое большее число вдвое худших обстоятельств лучше, как говорится, чем одно привычное".
Ты не догадался, что новые грабли — это dataflow?
А у тебя какие аргументы — "нет", "тут проблемы", "да"?
Здравствуйте, eao197, Вы писали:
E>Multicore Is Bad News For Supercomputers -- для некоторых классов задач память становится преградой для повышения производительности при увеличении числа ядер.
Не понятно, в чём проблема — тот же TILE64 имеет 64 ядра и 4 встроенных в процессор контроллера памяти. Допустим, что проблемы начинаются на 16 ядрах, значит, если поставить 4 контроллера памяти, то можно делать до 64 ядер. Когда массовые процессоры дойдут до 64 ядер, то поставят 8 контроллеров...
Это, конечно, всё не так приятно, как планомерное повышение частоты одного ядра в одном процессоре; но тем не менее т.н. Memory Wall тут пока не видится. Скорее даже наоборот — многоядерные процессоры решают Memory Wall, позволяя распараллеливать доступ к памяти.
Здравствуйте, remark, Вы писали:
E>>Multicore Is Bad News For Supercomputers -- для некоторых классов задач память становится преградой для повышения производительности при увеличении числа ядер.
R>Вот аналогичная статья, которая пророчит, что уже больше 16 или даже 8 ядер — бесполезно: R>http://arstechnica.com/news.ars/post/20081207-analysis-more-than-16-cores-may-well-be-pointless.html
R>Не понятно, в чём проблема — тот же TILE64 имеет 64 ядра и 4 встроенных в процессор контроллера памяти. Допустим, что проблемы начинаются на 16 ядрах, значит, если поставить 4 контроллера памяти, то можно делать до 64 ядер. Когда массовые процессоры дойдут до 64 ядер, то поставят 8 контроллеров... R>Это, конечно, всё не так приятно, как планомерное повышение частоты одного ядра в одном процессоре; но тем не менее т.н. Memory Wall тут пока не видится. Скорее даже наоборот — многоядерные процессоры решают Memory Wall, позволяя распараллеливать доступ к памяти.
Не знаю, я не разбираюсь в железе, но с точки зрения программиста раставлять по структурам данных специальные padding-и для того, чтобы не было cache line ping-pong -- это маразм, имхо. И мне кажется, что данные статьи как раз об этом свидетельствуют -- пока от многоядерности не выиграют обычные программы, не имеющие специальных средств защиты от подобных ping-pong-ов, смысла увеличивать число ядер не будет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[8]: Может массовых процессоров 32+ ядрами и не будет?
T>>>>Двое новых граблей, обычно, имеют длину рукоятки чуть меньше, чем по пояс. R>>>Именно! T>>Это у тебя все аргументы такие? Типа, "вдвое большее число вдвое худших обстоятельств лучше, как говорится, чем одно привычное". R>Ты не догадался, что новые грабли — это dataflow?
Там выше моя первая строка, она должна была содержать прилагательное "старый" по отношению к граблям.
Ручки-то у граблей укорачиваются от работы.
R>А у тебя какие аргументы — "нет", "тут проблемы", "да"?
Если объяснять подробно, то получится долго и нудно.
Возьми тот же Cell. Ему не менее 4 лет, AFAIK, за ним стоит здоровенная корпорация IBM, а нормального компилятора, раскидывающего по SPE куски задачи, нет, как нет, и не предвидится.
Это умеренно сложная архитектура.
Что же будет, если ядер будет побольше, ядра будут поменьше, да ещё и по-гетерогенней?
Просто ради прикола возьми любую из понравившихся тебе архитектур, возьми любую хорошо знакомую тебе задачу и уложи вторую на первую. Потом попробуй обобщить на класс задач.
Возможно, ты увидишь проблемы с компиляцией, как их вижу я. Возможно, ты увидишь их ясней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[9]: Может массовых процессоров 32+ ядрами и не будет?
Здравствуйте, thesz, Вы писали:
T>>>>>Двое новых граблей, обычно, имеют длину рукоятки чуть меньше, чем по пояс. R>>>>Именно! T>>>Это у тебя все аргументы такие? Типа, "вдвое большее число вдвое худших обстоятельств лучше, как говорится, чем одно привычное". R>>Ты не догадался, что новые грабли — это dataflow?
T>Там выше моя первая строка, она должна была содержать прилагательное "старый" по отношению к граблям.
T>Ручки-то у граблей укорачиваются от работы.
Да, по-моему, получилось как раз правильно. Какой мировой опыт разработки различного ПО под dataflow архитектуры по сравнению с традиционной архитектурой? Если так смотреть, то давай бросаться на все подряд "серебряные пули" — XML, COSA, STM и т.д. Все ж они superior. XML — идеальный способ хранения/передачи данных. COSA — идеальная модель программирования. STM — идеальная модель для параллелизма.
В любой новой технологии меня в первую очередь интересуют минусы, недостатки, подводные камни. С плюсами и так всё понятно, о них и так все кричат, да даже если плюс и не заметим, то ничего страшного не случится. А вот с минусами гораздо хуже. О них склонны умалчивать, не называть, или ещё хуже — не знать. А уж если технологию преподносят как вообще без минусов, то сразу "до свиданья" — либо тебе что-то продают, либо это что-то не готовое для реальной жизни.
R>>А у тебя какие аргументы — "нет", "тут проблемы", "да"?
T>Если объяснять подробно, то получится долго и нудно.
T>Возьми тот же Cell. Ему не менее 4 лет, AFAIK, за ним стоит здоровенная корпорация IBM, а нормального компилятора, раскидывающего по SPE куски задачи, нет, как нет, и не предвидится.
T>Это умеренно сложная архитектура.
T>Что же будет, если ядер будет побольше, ядра будут поменьше, да ещё и по-гетерогенней?
T>Просто ради прикола возьми любую из понравившихся тебе архитектур, возьми любую хорошо знакомую тебе задачу и уложи вторую на первую. Потом попробуй обобщить на класс задач.
T>Возможно, ты увидишь проблемы с компиляцией, как их вижу я. Возможно, ты увидишь их ясней.
Я не увижу никаких проблем с компиляцией. По очень простой причине. Я и не жду от компилятора никакой магии.
Задача компилятора — трансляция кода с более высокоуровнего языка в более низкоуровневый. Ну делать оптимизации на *низком* уровне, локальные. Ну делать кое-какие проверки, формальные и тоже локальные. Всё.
А где у нас "компиляторы", которые разбивают и раскидывают по ядрам куски кода для симметричных мало-ядерных процессоров? А где у нас "компиляторы", которые хотя бы для однопоточного случая создают производительные/оптимальные/устойчивые к сбоям программы? Я имею в виду не на низком уровне там битики переставить или операции местами поменять, а на высоком уровне — что б алгоритм оптимальный был, что б сервер производительный получился, что б сервер устойчивый получился, что б игра красивая получилась. Где такие "компиляторы"? А где "компиляторы", которые семантическую корректность программы гарантируют?
Тут везде, по-твоему, "проблемы с компиляцией"? По-моему, это — просто задачи разработчика.
Если у нас Cell или NUMA, то во-первых, надо алгоритм соответствующий подобрать. Не каждый на них ляжет. И если алгоритм не подходящий, то тут уж никакой компилятор не поможет, ни с проблемами, ни без проблем. Потом надо *самому* побить код на куски. АФАИК, никакой компилятор (за исключением вырожденных случаев типа FORTRAN в отношении простых циклов) не бьёт сам на куски.
Программировать под такие архитектуры, конечно, сложнее. Но никто обратного и не утверждает. Никто не говорит, что создание высокопроизводительного ПО просто. Никто не говорит, что создание надёжных серверов просто. Никто не говорит, что создание хороших игр просто. Эти задачи обладают высокой внутренней сложностью, которую никакой компилятор не уберёт (за исключением, разьве что, DSL для типовых задач). Снизу помощи сколько угодно — тут и компилятор, тут и библиотеки поддержки (те же агентные библиотеки/языки с поддержкой NUMA, топологии системы, гетерогенности и т.д.), сверху — только голова.
Здравствуйте, thesz, Вы писали:
T>Если объяснять подробно, то получится долго и нудно.
T>Возьми тот же Cell. Ему не менее 4 лет, AFAIK, за ним стоит здоровенная корпорация IBM, а нормального компилятора, раскидывающего по SPE куски задачи, нет, как нет, и не предвидится.
T>Это умеренно сложная архитектура.
T>Что же будет, если ядер будет побольше, ядра будут поменьше, да ещё и по-гетерогенней?
T>Просто ради прикола возьми любую из понравившихся тебе архитектур, возьми любую хорошо знакомую тебе задачу и уложи вторую на первую. Потом попробуй обобщить на класс задач.
T>Возможно, ты увидишь проблемы с компиляцией, как их вижу я. Возможно, ты увидишь их ясней.
буду признателен за ссылки или хоть что нибудь.
я бы очень хотел алгоритмы иметь отдельно от clutter который порождает решение всех мелких вопросов без которых с++ не компилируется.
моя проблема в том что такие инструменты как например scheme имеют модель исполнения которую никак просто не уложишь на аппаратуру. Если было нужно для бизнес задач то я бы и глазом не моргнул — пустил бы интерпретатор и поставил галочку "сделано". Проблема в том что оно должно обрабатывать большие (>10**9 полигонов) объемы векторной геометрии. И соответственно между моделью на языке высокого уровня и железом нужно копаться.
Так что есть серьезная нужда запускать, тестировать и анализировать алгоритмы в высокоуровневом описании, а затем не меняя смысла раскладывать это уже по элементам аппаратуры.
У меня есть пара хороших знакомых, которые в этих вопросах явно получше меня и они обеими руками за построение отображение "текст на яву" <-> "текст на С" (грубо говоря современный ассемблер). Не буду делать вид что это просто или что я понял как они это могут сделать. Так что любые клочки информации приветствуются.
Подход remark мне кажется реально бессмысленным — с каждым патчем архитектуры железки нужно проделывать полный реверс анализ факторов (например изменилась ассоциативность L2 и привет всем padding'ам в структурах и пока еще это всплывет). Фактически речь идет о поддержке софта под один компьютер, что с точки зрения экономики полный ...
Re[10]: Может массовых процессоров 32+ ядрами и не будет?
T>>Если объяснять подробно, то получится долго и нудно. T>>Возьми тот же Cell. Ему не менее 4 лет, AFAIK, за ним стоит здоровенная корпорация IBM, а нормального компилятора, раскидывающего по SPE куски задачи, нет, как нет, и не предвидится. T>>Это умеренно сложная архитектура. T>>Что же будет, если ядер будет побольше, ядра будут поменьше, да ещё и по-гетерогенней? T>>Просто ради прикола возьми любую из понравившихся тебе архитектур, возьми любую хорошо знакомую тебе задачу и уложи вторую на первую. Потом попробуй обобщить на класс задач. T>>Возможно, ты увидишь проблемы с компиляцией, как их вижу я. Возможно, ты увидишь их ясней. SD>буду признателен за ссылки или хоть что нибудь.
Ссылки на что? Алгоритмы анализа и преобразования кода?
Они грубо делятся на обработку программ над массивами (Фортран, умеренно просто) и обработку программ общего назначения (C/C++, ОЧЕНЬ СЛОЖНО). В обоих случаях надо определить наличие зависимости между циклами или вызовами, во втором случае всё осложняется произвольной рекурсией и перекрытием (aliasing).
Здравствуйте, SleepyDrago, Вы писали:
SD> Подход remark мне кажется реально бессмысленным — с каждым патчем архитектуры железки нужно проделывать полный реверс анализ факторов (например изменилась ассоциативность L2 и привет всем padding'ам в структурах и пока еще это всплывет). Фактически речь идет о поддержке софта под один компьютер, что с точки зрения экономики полный ...
Это, действительно, бессмыслица. И, к счастью, это не мой подход.
Ну там можно попробовать переменные использовать, настраивать как-то свой код.
З.ы. ассоциативность не влияет на padding'и.
З.з.ы. padding'и — это не мой подход. С ними так и так проблемы всплывут на NUMA системах. А если их не использовать, то и изменение размера кэш-линии не повлияет.
