Комментарии 115
38200 без НДС? Не, я пока щупать не буду.
Вполне может так быть, что цены для энтузиастов будут меньше. Насколько я слышал краем уха, вопрос обсуждается
вообще, я ожидал прочитать тут не дифирамбы, а описание процессора, особенности архитектуры, языки программирования под него с утилизацией особенностей…
Ок. Я расскажу, но попозже. Пока времени нет на развёрнутый текст. Если кратко, то особенность архитектуры в том, что недетерменированный (не VLIW-ный) параллелизм заложен прямо в ISA: инструкции, фактически, описывают ярусно-параллельное представление программы. Особых языков никаких пока нет, вопрос о разработке их пока обсуждается (там есть некоторые особенности, которыми можно воспользоваться). Стандартные же языки: Си, Фортран, etc (даже Haskell) должны неплохо вписываться в архитектуру. Компилятор Си89 сейчас отлаживается.
В архитектуре я разбираюсь не очень, но ваши слова оставили несколько вопросов.
Что за недетерменированный параллелизм? ISA — это ведь шина ввода/вывода? Реализована какая-то параллельность на ней? Ну а в самом процессоре какой параллелизм, за счет чего, или он только на шине? :-)
Что за недетерменированный параллелизм? ISA — это ведь шина ввода/вывода? Реализована какая-то параллельность на ней? Ну а в самом процессоре какой параллелизм, за счет чего, или он только на шине? :-)
Когда будете рассказывать, пожалуйста, раскрывайте все потенциально неизвестные широкой публике термины.
38200 за один голый чип?! или за отладочную плату?
Где вы увидели такие цифры?
multiclet.com/index.php?option=com_content&view=article&id=93&Itemid=62&lang=ru
multiclet.com/index.php?option=com_content&view=article&id=93&Itemid=62&lang=ru
Сам микропроцессор стоит всего 462 руб. в партии до 100 шт. Это прекрасная, вменяемая цена.
38200 руб. — отладочная плата со всем фаршем. Дороговато, но в мелкосерийном производстве дешевле не сделаешь.
38200 руб. — отладочная плата со всем фаршем. Дороговато, но в мелкосерийном производстве дешевле не сделаешь.
Лично я бы с удовольствием прочитал Вашу статью с подробностями про эту интересную железку.
А на MCp есть апноты и примеры кода?
Может пока кто расскажет, где можно скачать эмулятор и попробовать свои силы в подобном программировании? Выглядит очень интересно.
я несколько раз задавал вопросы в вашу пресс-службу, но так и не получил ответа. Очень печально, так как слежу за вашей компанией еще со времен уральской архитектурной лаборатории. А процессор ваш последнее время напоминает призрак Неуловимого Джо, который только сколковцам для отчетности нужен.
На Иннопроме-11 Мультиклет обещал выпустить первую партий процессоров в феврале 2012 (http://it-eburg.com/text/article/uralskii_processor_soidet_s_konveiera_v_2012/), до этого производство было назначено на 2011 (http://it-eburg.com/text/article/uralskii_processor_profinansirujut_akcionery/), в материале Известий (еще зимой) говорится что у вас уже есть партия в 10 тыс. процессоров сделанных в Индонезии, а через месяц в Областной новое заявление, что вы надеетесь приступить к выпуску только весной.
Сейчас опять какие то процессоры для кого то выпущенные кем то. В Екатеринбурге микропроцессорного производства нет. Анонсировались договоренности с Уральским оптико-механическим заводом, с каким-то зеленоградскими НИИ. Процессор же не сферический конь в вакууме и сам по себе никому не нужен. Ему необходима экосистема разработчиков железа и софта. Кто заказчик? Во что его можно встроить? Военка? Для каких целей? откуда взялась цифра в 10 тыс? Расскажите про реальные примеры, а то пока только видно как вы сколковским статусом размахиваете.
Пардон, если получилось с наездом.
На Иннопроме-11 Мультиклет обещал выпустить первую партий процессоров в феврале 2012 (http://it-eburg.com/text/article/uralskii_processor_soidet_s_konveiera_v_2012/), до этого производство было назначено на 2011 (http://it-eburg.com/text/article/uralskii_processor_profinansirujut_akcionery/), в материале Известий (еще зимой) говорится что у вас уже есть партия в 10 тыс. процессоров сделанных в Индонезии, а через месяц в Областной новое заявление, что вы надеетесь приступить к выпуску только весной.
Сейчас опять какие то процессоры для кого то выпущенные кем то. В Екатеринбурге микропроцессорного производства нет. Анонсировались договоренности с Уральским оптико-механическим заводом, с каким-то зеленоградскими НИИ. Процессор же не сферический конь в вакууме и сам по себе никому не нужен. Ему необходима экосистема разработчиков железа и софта. Кто заказчик? Во что его можно встроить? Военка? Для каких целей? откуда взялась цифра в 10 тыс? Расскажите про реальные примеры, а то пока только видно как вы сколковским статусом размахиваете.
Пардон, если получилось с наездом.
Ой. Я не сотрудник фирмы, работаю по договору. Ничего об этих деталях сказать не могу. Знаю только, что процессор точно есть, и что есть заказчики, ибо даже мне влетело за то, что в феврале не было изделий, хотя я ещё не работал на них. Опытную партию делали в Малазии, кажется (точно не знаю). В Екатеринбурге же сидят разработчики архитектуры и программисты.
Кажется, сайт разработчиков не выдержал лучей славы и завалился с «Database Error: Unable to connect to the database:Could not connect to MySQL».
Нужно же людей к славе приучать :)
НЛО прилетело и опубликовало эту надпись здесь
Да, nginx спасет от падения криво настроенного MySQL-сервера.
Конечно…
Конечно…
проблема в том, что коннекты кончились у мускула.
переход на nginx улучшает ситуацию — скрипты отрабатывают и отдают nginx'у на максимальной своей скорости, а клиенту медленно отдаёт уже nginx когда коннект уже свободен.
в случае прямого апача — коннект и скрипт висит пока клиент не заберёт всё.
переход на nginx улучшает ситуацию — скрипты отрабатывают и отдают nginx'у на максимальной своей скорости, а клиенту медленно отдаёт уже nginx когда коннект уже свободен.
в случае прямого апача — коннект и скрипт висит пока клиент не заберёт всё.
Все клетки сбойнули
А какой рынок предполагается? В смысле, куда процессоры планируется ставить?
Что у него с производительностью и тех.процессом?
НЛО прилетело и опубликовало эту надпись здесь
Горжусь!!! Спасибо вам за будущее!
Я в этой теме дилетант, так что вопросы могут показаться глупыми, так что будьте терпеливы :)
А чем этот процессор от Cell принципиально отличается, кроме устойчивого запаха нафталина (100МГц, QFP, USB 1.1, Ethernet 10/100)? Идеи OoOE тоже были опробованы давно и основной проблемой было не создание процессора, а разработка под него. Даже сейчас многопоточные приложения — это специфика, а не массовость. Было бы понятно, имей он в арсенале LISP-машину или иной лямбда-язык, которые в силу своего дизайна имеет иммунитет к order of execution. Но когда я вижу, что допиливается императивный C89, то вопросов становится все больше.
А как считалась производительность? Как теоретически выдаваемая всеми четырьмя юнитами без затрат на синхронизацию?
А чем этот процессор от Cell принципиально отличается, кроме устойчивого запаха нафталина (100МГц, QFP, USB 1.1, Ethernet 10/100)? Идеи OoOE тоже были опробованы давно и основной проблемой было не создание процессора, а разработка под него. Даже сейчас многопоточные приложения — это специфика, а не массовость. Было бы понятно, имей он в арсенале LISP-машину или иной лямбда-язык, которые в силу своего дизайна имеет иммунитет к order of execution. Но когда я вижу, что допиливается императивный C89, то вопросов становится все больше.
А как считалась производительность? Как теоретически выдаваемая всеми четырьмя юнитами без затрат на синхронизацию?
Очень сильно отличается. Cell — это многопроцессорная система, многоядерная. То есть, у него интерфейс через множество потоков исполнения. Этот процессор — одноядерный, у него один поток исполнения, но код этого потока выполняется параллельно. Идеи ОоОЕ — это сейчас основные идеи в производительных CPU. Они были опробованы и успешно служат народному хозяйству, возьмите любой процессор AMD или Intel (кроме Atom). Здесь просто особый вариант OoOE, более эффективный по энергии.
C89 делается, потому что заказчикам нужен C89. Дальнейшее развитие системного обеспечения обсуждается. Ну… И C89 тоже выигрывает от архитектуры, например, вполне возможна параллельная вычитка значений из памяти в циклах, параллельное вычисление выражений и т.д.
Производительность считалась на потактовой модели, на реальных кодах. Если не ошибаюсь, то это было преобразование Фурье
C89 делается, потому что заказчикам нужен C89. Дальнейшее развитие системного обеспечения обсуждается. Ну… И C89 тоже выигрывает от архитектуры, например, вполне возможна параллельная вычитка значений из памяти в циклах, параллельное вычисление выражений и т.д.
Производительность считалась на потактовой модели, на реальных кодах. Если не ошибаюсь, то это было преобразование Фурье
это будет особый диалект C89 или библиотеки? то есть будут какие то специальный конструкции для паралельных вычислений циклов/выражений?
Это обычный C89. Со стороны языка ничего специального не нужно, чтобы пользоваться тонкостями архитектуры. Вся забота об этом на компиляторе. Наверное, в будущем появятся какие-то специальные конструкции, которые будут давать дополнительный контроль программисту, но сама концепция процессора ничего такого от языка программирования не требует. В этом, наверное, одно из достоинств.
А чем принципиальным клетки «FU» из вашего поста, которые «параллельно сворачивают» отличаются от PE Cell'а, которые также распараллеливает выполнение? Делают это мультипарадигменно, от примитивного распределения процессов по PE и стандартной многозадачности на блокировках до реализации распределенной очереди исполнения с тем же out-of-order. Хорошо бы, конечно, увидеть пример «набора предложений, каждое из которых задаёт граф потока данных», чтобы понять, куда шагнула индустрия. А то пока звучит как рекламный слоган и тонкости реализации не совсем понятны :)
PU в Cell — это полноценный процессор. А клетка (если бы меня спросили, я бы им тоже указал на неудачные ассоциации с Cell) — это именно функциональное устройство одного процессора. Тут речь не идёт о параллельном исполнении программ, речь идёт о параллелизме на уровне инструкций. Код предложения выглядит вот так вот:
Здесь чтения (rdx) и преобразования во float (cslf) выполняются параллельно.
fn6.P1:
jmp fn6.PF
rdsb fn6.z.8A ; 1: fn6.z.8A -> BP[20]
rdsl fn6.x.0A ; 2: fn6.x.0A -> BP[12]
rdsl fn6.y.4A ; 3: fn6.y.4A -> BP[16]
cslf @2 ; 4: @2 -> 2
cslf @4 ; 5: @4 -> 1
addf @2, @3 ; 6: @2 -> 4, @3 -> 3
addf @1, @2 ; 7: @1 -> 6, @2 -> 5
cfsl @1 ; 8: @1 -> 7
wrsl @1, fn6.RV ; 9: @1 -> 8
complete
Здесь чтения (rdx) и преобразования во float (cslf) выполняются параллельно.
Мы, наверно, о разных Cell говорим. Тот, который я знаю, не содержит PU в принципе. Он содержит PPE и SPE, ни один из которых не является «полноценным процессором», а являются вполне себе специфичными «функциональными устройствами» процессора Cell. А также указал на мультипарадигменность вычислительной модели, а не о «параллельном исполнении программ». Последний был упомянут, как частный, примитивный случай.
Я, наверно, бесконечно отстал в современных трендах, но все равно в упор не могу понять преимуществ. В примере кода, а точнее в комментариях к нему я вижу обычный конвейер, присущий практически всем современным, да и не очень процессорам. С теми же детскими болячками и той же сложностью в разработке. Но не исключено, что я просто пока не вижу из-за собственной зашоренности убеждением, что только смена программной модели с императивной на декларативную позволит решить эти вопросы.
Я, наверно, бесконечно отстал в современных трендах, но все равно в упор не могу понять преимуществ. В примере кода, а точнее в комментариях к нему я вижу обычный конвейер, присущий практически всем современным, да и не очень процессорам. С теми же детскими болячками и той же сложностью в разработке. Но не исключено, что я просто пока не вижу из-за собственной зашоренности убеждением, что только смена программной модели с императивной на декларативную позволит решить эти вопросы.
PPE — вполне себе полноценный процессор. PU — это Processing Unit, общепринятое обозначение (CPU, GPU, FixPU и так далее). PPE и SPE — это PU. SPE, кстати, тоже вполне себе самостоятельный процессор, специализированный просто. Не знаю, почему вы их таковыми не считаете. Ибо всеми признаками PU он обладает: выполняет программу, обрабатывая данные. Клетка в MCp — это не PU, в этом разница.
А какие преимущества вы ожидаете увидеть? Повторюсь, MCp — это вариант OoOE, обладающей хорошей энергоэффективностью и устойчивостью к сбоям своих функциональных устройствах (в этом его преимущества). Никакой магии здесь, конечно же, нет. Если вы поставите несколько таких процессоров, то для них придётся писать специальный код, возможно в парадигме, которую IBM предлагает для Cell, возможно, в какой-то другой.
В комментариях к коду не конвейер, а ссылки на результаты. Конвейеров в процессоре пока нет.
А какие преимущества вы ожидаете увидеть? Повторюсь, MCp — это вариант OoOE, обладающей хорошей энергоэффективностью и устойчивостью к сбоям своих функциональных устройствах (в этом его преимущества). Никакой магии здесь, конечно же, нет. Если вы поставите несколько таких процессоров, то для них придётся писать специальный код, возможно в парадигме, которую IBM предлагает для Cell, возможно, в какой-то другой.
В комментариях к коду не конвейер, а ссылки на результаты. Конвейеров в процессоре пока нет.
Общепринятое обозначение PU (в том числе и приводимые примеры CPU, GPU и т.п.) всегда использовались к конечным Unit'ам, говоря языком потребительским — к чипам. Ни разу не встречал определения, что Intel i7 содержит внутри 4 PU, а NVidia GTX 690 — 1536 PU, хотя первый называется CPU, а второй — GPU. Честно говоря, совершенно не хотелось бы погружаться в разбор терминов, но поскольку никакой более внятной информации нет — приходить искать понимания, опираясь на них. И чтобы мне попробовать понять, что же такое «клетка в MCp», хочется задать следующий вопрос. Если, согласно Вашим определениям, «клетка в МСр — это не PU», а «PU выполняет программу, обрабатывая данные», то кто же выполняет тот код, что Вы привели? Ибо в нем я явно усматривают признаки программы, обрабатывающей данные (чтение данных, преобразование во float).
Преимущества… Как вариант — преимущества над тем же Cell. Там тоже OoOE, тоже устойчивость. По поводу энергоэффективности сложно сказать, поскольку они используют взрослый и стандартизированный linpack, в Вашем случае «вроде бы БФП», но в самом топе Green500 суперькомпьютеров Cell постоянно присутствует. Цена — гораздо дешевле выпаивать Cell'ы из Sony PS3. Размер, не смотря на то, что Cell даже номинально в 10 раз быстрее, меньше. Я уж не говорю про интерфейсы и дальнейшую масштабируемость.
В идеале, конечно, хотелось услышать, что мы вообще сломали все устарелые парадигмы как в разработке самих процессоров, так и в разработке под них (что гораздо важнее).
По поводу конвейера не совсем понял. Он предполагает одновременное исполнение инструкций, Вы в комментарии пишете про параллельное исполнение инструкций. Резонный вопрос — в чем разница между двумя параллельными выполнениями. Ведь может так статься, что под этой рекламной завесой кроется банальный пайплайнинг, который был еще у первых пентиумов, не говоря про старые RISC-процессоры, которые тоже, кстати, давали очень хорошие показатели в гигафлопсах на ватт, но понятно, какой ценой.
ЗЫ. Где может показаться наличие агрессивной критики, просто я к правде иду через стресс-тесты :)
Преимущества… Как вариант — преимущества над тем же Cell. Там тоже OoOE, тоже устойчивость. По поводу энергоэффективности сложно сказать, поскольку они используют взрослый и стандартизированный linpack, в Вашем случае «вроде бы БФП», но в самом топе Green500 суперькомпьютеров Cell постоянно присутствует. Цена — гораздо дешевле выпаивать Cell'ы из Sony PS3. Размер, не смотря на то, что Cell даже номинально в 10 раз быстрее, меньше. Я уж не говорю про интерфейсы и дальнейшую масштабируемость.
В идеале, конечно, хотелось услышать, что мы вообще сломали все устарелые парадигмы как в разработке самих процессоров, так и в разработке под них (что гораздо важнее).
По поводу конвейера не совсем понял. Он предполагает одновременное исполнение инструкций, Вы в комментарии пишете про параллельное исполнение инструкций. Резонный вопрос — в чем разница между двумя параллельными выполнениями. Ведь может так статься, что под этой рекламной завесой кроется банальный пайплайнинг, который был еще у первых пентиумов, не говоря про старые RISC-процессоры, которые тоже, кстати, давали очень хорошие показатели в гигафлопсах на ватт, но понятно, какой ценой.
ЗЫ. Где может показаться наличие агрессивной критики, просто я к правде иду через стресс-тесты :)
Код выполняет процессор, внутри у которого эти самые клетки, объединённые коммутационной средой. В принципе, процессор может быть сделан и из одной такой клетки, но её, всё равно, нужно подключать к коммутационной среде. Если клетка одна, то код будет загружен в буфер инструкций этой клетки, и будет выполнен в стиле: одна инструкция за другой (RISC конвейера нет). Если клеток много, то код будет разбросан по этим клеткам, и они параллельно будут исполнять готовые к исполнению инструкции. Готовые — это те, для которых вычислены аргументы. Тут некий вариант потоковой парадигмы.
От Cell эта конструкция отличается тем, что она выполняет 1 программу (один поток инструкций), а не набор разных программ, которые распределяются между PE некой программной же средой времени исполнения.
Является ли это преимуществом? Для тех задач, на которые MCp нацелен — да, является. Если для распределения данных между вычислительными устройствами не нужно выполнять дополнительный код, это позволяет экономить энергию. Кстати, вот преобразование Фурье — это критерий. У БФП сложные информационные связи в алгоритме, и MCp хорошо с ними справляется, а вот для Cell код БФП будет существенно сложнее и затратрее. Будет ли MCp лучше Cell в потоковых и матричных вычислениях? Не знаю.
Про размеры, техпроцессы, переферию и прочее — это не вопрос архитектуры. Это вопрос доступных технологий. Да, у IBM технологии намного сильно круче. Никто и не спорит.
По поводу конвейера я тоже не понял. Конвейер — это же и есть pipeline. Он параллельно выполняет инструкции, находящиеся на разных стадиях этого конвейера. В MCp такого конвейера нет. Инструкции выполняются разными «клетками» независимо.
От Cell эта конструкция отличается тем, что она выполняет 1 программу (один поток инструкций), а не набор разных программ, которые распределяются между PE некой программной же средой времени исполнения.
Является ли это преимуществом? Для тех задач, на которые MCp нацелен — да, является. Если для распределения данных между вычислительными устройствами не нужно выполнять дополнительный код, это позволяет экономить энергию. Кстати, вот преобразование Фурье — это критерий. У БФП сложные информационные связи в алгоритме, и MCp хорошо с ними справляется, а вот для Cell код БФП будет существенно сложнее и затратрее. Будет ли MCp лучше Cell в потоковых и матричных вычислениях? Не знаю.
Про размеры, техпроцессы, переферию и прочее — это не вопрос архитектуры. Это вопрос доступных технологий. Да, у IBM технологии намного сильно круче. Никто и не спорит.
По поводу конвейера я тоже не понял. Конвейер — это же и есть pipeline. Он параллельно выполняет инструкции, находящиеся на разных стадиях этого конвейера. В MCp такого конвейера нет. Инструкции выполняются разными «клетками» независимо.
> Код выполняет процессор, внутри у которого эти самые клетки, объединённые коммутационной средой.
Для меня камнем преткновения является термин «клетки». Я пытаюсь понять, что это, а Вы настойчиво его используете. Это уже не конвеер, но еще не PU. Может ему пока термина не придумали?
> Если клетка одна, то код будет загружен в буфер инструкций этой клетки, и будет выполнен в стиле: одна инструкция за другой (RISC конвейера нет). Если клеток много, то код будет разбросан по этим клеткам, и они параллельно будут исполнять готовые к исполнению инструкции. Готовые — это те, для которых вычислены аргументы. Тут некий вариант потоковой парадигмы.
Это звучит очень похоже на instruction pipelining. Если нет pipeline hazard'а (втч «вычислены аргументы») то инструкции распараллеливаются по конвейерам.
> которые распределяются между PE некой программной же средой времени исполнения.
А вот это уже интересней. И именно это хотелось бы увидеть.
> У БФП сложные информационные связи в алгоритме.
Какой-то сложный алгоритм был выбран :) БФП — один из классических примеров в том же CUDA SDK, что демонстрирует, насколько он неприхотлив и как хорошо параллелится. Его же использовали для еще одних наших «инновационных» процессоров NeuroMatrix, которые… не на многое способны. Имхо, очень примитивный полигон.
Для меня камнем преткновения является термин «клетки». Я пытаюсь понять, что это, а Вы настойчиво его используете. Это уже не конвеер, но еще не PU. Может ему пока термина не придумали?
> Если клетка одна, то код будет загружен в буфер инструкций этой клетки, и будет выполнен в стиле: одна инструкция за другой (RISC конвейера нет). Если клеток много, то код будет разбросан по этим клеткам, и они параллельно будут исполнять готовые к исполнению инструкции. Готовые — это те, для которых вычислены аргументы. Тут некий вариант потоковой парадигмы.
Это звучит очень похоже на instruction pipelining. Если нет pipeline hazard'а (втч «вычислены аргументы») то инструкции распараллеливаются по конвейерам.
> которые распределяются между PE некой программной же средой времени исполнения.
А вот это уже интересней. И именно это хотелось бы увидеть.
> У БФП сложные информационные связи в алгоритме.
Какой-то сложный алгоритм был выбран :) БФП — один из классических примеров в том же CUDA SDK, что демонстрирует, насколько он неприхотлив и как хорошо параллелится. Его же использовали для еще одних наших «инновационных» процессоров NeuroMatrix, которые… не на многое способны. Имхо, очень примитивный полигон.
Клетка — это функциональное устройство, можно считать его ALU, у которого есть свой буфер инструкций и подключение к коммуникационной среде (коммутатор), в которую выдаются результаты выполнения инструкций из этого буфера. Клетка выполняет готовые к выполнению инструкции (уж простите за тафтологию), а инструкция становится готовой к выполнению как только клетка получает из коммутатора необходимые для этой инструкции операнды.
Если Вы знаете об архитектуре POWER, то можете смотреть на клетку примерно как на ALU, спаренный со станцией резервирования.
К сожалению, я не знаю, что вы имеете в виду под instruction pipelining. Википедия говорит про instruction pipeline то же, что и я подразумеваю: risc-овый конвейер. В MCp другая идея суперскалярности, независимые инструкции могут запускаться на разных клетках, как в OoOE процессорах.
Если Вы знаете об архитектуре POWER, то можете смотреть на клетку примерно как на ALU, спаренный со станцией резервирования.
К сожалению, я не знаю, что вы имеете в виду под instruction pipelining. Википедия говорит про instruction pipeline то же, что и я подразумеваю: risc-овый конвейер. В MCp другая идея суперскалярности, независимые инструкции могут запускаться на разных клетках, как в OoOE процессорах.
>>всегда использовались к конечным Unit'ам, говоря языком потребительским — к чипам
Unit это просто функционально завершенный блок, как например Load-Store Unit (LSU), так и целый процессор/ядро.
>>Преимущества… Как вариант — преимущества над тем же Cell. Там тоже OoOE, тоже устойчивость.
У CELL нет OoOe ни в каком виде. Разве что неблокирующие чтение в PPU.
CELL и MCp находят параллелизм в двух ортогональных направлениях.
CELL — TLP (thread level parallelism)
MCp — ILP (instruction level parallelism)
Unit это просто функционально завершенный блок, как например Load-Store Unit (LSU), так и целый процессор/ядро.
>>Преимущества… Как вариант — преимущества над тем же Cell. Там тоже OoOE, тоже устойчивость.
У CELL нет OoOe ни в каком виде. Разве что неблокирующие чтение в PPU.
CELL и MCp находят параллелизм в двух ортогональных направлениях.
CELL — TLP (thread level parallelism)
MCp — ILP (instruction level parallelism)
> Unit это просто функционально завершенный блок
Передо мной стояла задача понять архитектуру, а манипуляция абстрактными определениями только ее усложняет. Это как с видео-чипами, формально конвейеры, пиксельные и вершинные процессоры, блоки наложения текстур, блоки растровых операций и т.п. — все юниты (TMU, ROP/U и т.п.). Но почему-то для них используют специализированные термины. В целом и общем я готов их всех называть юнитами, то мне хочется понять, почему «клетка» — не юнит.
> У CELL нет OoOe ни в каком виде
Они что, OoOE из Cell'а вырезали? Я всегда думал, что он, как наследник Power Architecture понесет его за собой, все таки еще с POWER1 это было фишкой линейки. Когда последний раз читал про Cell, там шла речь о том, что PPE выполнен на базе POWER4, в которой OoOE был… Возможно я безнадежно отстал и выбрал неудачное сравнение.
> MCp — ILP (instruction level parallelism)
Я предложил ТС instruction pipelining как вариант ILP, но он говорит, что не то. Вариант суперскалярной архитектуры отметен в самой статье, это не статичный OoOE, вот я и пытаюсь понять, чтож за ноухау.
Передо мной стояла задача понять архитектуру, а манипуляция абстрактными определениями только ее усложняет. Это как с видео-чипами, формально конвейеры, пиксельные и вершинные процессоры, блоки наложения текстур, блоки растровых операций и т.п. — все юниты (TMU, ROP/U и т.п.). Но почему-то для них используют специализированные термины. В целом и общем я готов их всех называть юнитами, то мне хочется понять, почему «клетка» — не юнит.
> У CELL нет OoOe ни в каком виде
Они что, OoOE из Cell'а вырезали? Я всегда думал, что он, как наследник Power Architecture понесет его за собой, все таки еще с POWER1 это было фишкой линейки. Когда последний раз читал про Cell, там шла речь о том, что PPE выполнен на базе POWER4, в которой OoOE был… Возможно я безнадежно отстал и выбрал неудачное сравнение.
> MCp — ILP (instruction level parallelism)
Я предложил ТС instruction pipelining как вариант ILP, но он говорит, что не то. Вариант суперскалярной архитектуры отметен в самой статье, это не статичный OoOE, вот я и пытаюсь понять, чтож за ноухау.
>> почему «клетка» — не юнит.
Вы говорили о PU — то бишь более-менее самостоятельный процессор / ядро.
«Клетка» (как я понимаю) это скорее ALU чем что-то большее.
Вообще терминологию каждый производитель выбирает как ему удобнее.
>>Они что, OoOE из Cell'а вырезали
В смысле вырезали? Его там никогда не было. Не нужно забывать что процессор предназначался для консолей с естественными ограничениями по цене/TDP.
>>Я всегда думал, что он, как наследник Power Architecture
Вы путаете архитектуру и микро-архитектуру.
Архитектура не задает детали реализации процессора.
Там только ISA/Протоколы взаимодействия.
CELL PPE реализует Power ISA v2.03 — гибрид Power и PowerPC
>>с POWER1 это было фишкой линейки
POWER6 / Z10 — in-order.
Все суперкомпьютеры BlueGene (включая #1 в мире) — in-order
>>PPE выполнен на базе POWER4
Это не так. В основе PPE/Xenon, насколько я знаю, лежит экспериментальное PPC ядро (1998г. первый процессор с частотой >1GHz)
www.v3.co.uk/v3-uk/news/1949619/ibm-breaks-1ghz-barrier
С POWER4 его роднит лишь двух-тактовая латентность базовых ALU операций.
Вы говорили о PU — то бишь более-менее самостоятельный процессор / ядро.
«Клетка» (как я понимаю) это скорее ALU чем что-то большее.
Вообще терминологию каждый производитель выбирает как ему удобнее.
>>Они что, OoOE из Cell'а вырезали
В смысле вырезали? Его там никогда не было. Не нужно забывать что процессор предназначался для консолей с естественными ограничениями по цене/TDP.
>>Я всегда думал, что он, как наследник Power Architecture
Вы путаете архитектуру и микро-архитектуру.
Архитектура не задает детали реализации процессора.
Там только ISA/Протоколы взаимодействия.
CELL PPE реализует Power ISA v2.03 — гибрид Power и PowerPC
>>с POWER1 это было фишкой линейки
POWER6 / Z10 — in-order.
Все суперкомпьютеры BlueGene (включая #1 в мире) — in-order
>>PPE выполнен на базе POWER4
Это не так. В основе PPE/Xenon, насколько я знаю, лежит экспериментальное PPC ядро (1998г. первый процессор с частотой >1GHz)
www.v3.co.uk/v3-uk/news/1949619/ibm-breaks-1ghz-barrier
С POWER4 его роднит лишь двух-тактовая латентность базовых ALU операций.
Надо же. Видимо и вправду на определённом этапе НТП очередные идеи просто витают в воздухе. Я думал о подобной системе (хотя возможно у вас она всё-таки другая — одна ссылка не содержит ничего полезного, а другая не открывается) ещё в далёком 2000-ом году. Как сейчас помню обдумывал эту концепцию непосредственно перед защитой диплома совсем на другую тему :)
Ключевой идеей у меня был переход от управления потоками команд к управлению потоками данных. На мой взгляд это можно было осуществить через N-мерную структуру из относительно несложных программируемых блоков. На первом этапе передаваемые данные должны были формировать структуру для последующей потоковой обработки собственно данных. На втором этапе (буквально на следующем же такте после формирования этой структуры) должна была начинаться потоковая обработка получаемых данных неограниченной длины (разрядности). Вплоть до получения сигнала завершения цикла. Далее следующее перепрограммирование и по циклу. Помнится я даже пытался смоделировать это на каком-то языке.
Однако как программировать такую систему на стандартном языке — я не представляю. Возможно у вас всё-таки совсем другая.
К сожалению по научному пути я не пошёл, а ушёл в «зарабатывание денег» тупо кодируя всякую мутотень то на немцев, то на русских банкиров, то на японцев… PHP, Java, C++, SQL, всякие топорные решения тривиальных проблем вроде мутного EJB, ненавистного мне Hibernate и т. п… В общем «прогресс» буржуйского разлива. Но за это неплохо платили, да. И деньги тогда было очень к месту. Только где теперь эти деньги?..
В общем надеюсь у вас получится. Может быть и я когда-нибудь ещё смогу приложить к этому руку )
Ключевой идеей у меня был переход от управления потоками команд к управлению потоками данных. На мой взгляд это можно было осуществить через N-мерную структуру из относительно несложных программируемых блоков. На первом этапе передаваемые данные должны были формировать структуру для последующей потоковой обработки собственно данных. На втором этапе (буквально на следующем же такте после формирования этой структуры) должна была начинаться потоковая обработка получаемых данных неограниченной длины (разрядности). Вплоть до получения сигнала завершения цикла. Далее следующее перепрограммирование и по циклу. Помнится я даже пытался смоделировать это на каком-то языке.
Однако как программировать такую систему на стандартном языке — я не представляю. Возможно у вас всё-таки совсем другая.
К сожалению по научному пути я не пошёл, а ушёл в «зарабатывание денег» тупо кодируя всякую мутотень то на немцев, то на русских банкиров, то на японцев… PHP, Java, C++, SQL, всякие топорные решения тривиальных проблем вроде мутного EJB, ненавистного мне Hibernate и т. п… В общем «прогресс» буржуйского разлива. Но за это неплохо платили, да. И деньги тогда было очень к месту. Только где теперь эти деньги?..
В общем надеюсь у вас получится. Может быть и я когда-нибудь ещё смогу приложить к этому руку )
Сама концепция известна вроде бы очень давно.
Насчёт реализаций — не знаю.
Насчёт реализаций — не знаю.
Нисколько не сомневаюсь. Однако в то время я ещё не обладал достаточными навыками для эффективного поиска, не знал свободно языка, да и с интернетом у меня был большой напряг. Поэтому размышлял над построением собственного велосипеда прямо с нуля.
Сейчас уже и время не то, и я не тот. Просто вспомнилось.
Сейчас уже и время не то, и я не тот. Просто вспомнилось.
Еще один Эльбрус, но проще?
Вес меньше — теперь не 46 ножек и 4 ручки для переноски, а только одна!
Эльбрус секретный, поэтому сложно судить. Но я думаю, да, MCp попроще будет, ну, и идеология другая. Эльбрус — это VLIW.
Ну эльбрусы разные бывают. Вот первые эльбрусы исполняли байткод.
Эльбрус-3 был VLIW но также как MCp адресовался к результатам предыдущих команд.
Эльбрус-3 был VLIW но также как MCp адресовался к результатам предыдущих команд.
К сожалению, все мои попытки получить какую-нибудь документацию к современным Эльбрусам успехом не закончились. Поэтому ничего не могу сказать
Отчего же, МЦСТ (Разработчик всяких Эльбрусов) охотно делится всякой информацией относительно них, предлагает предзаказ на платы (около 120к-140к) и даже доступ по сети к работающим устройствам на базе Эльбрусов, в т.ч. и нового 2C+. Но для конечного заказчика эти велосипеды — весьма дорогостоящее занятие — в случае клеток — оси нет, софта тоже, с МЦСТ, фактически то же, только еще и процессоров пока нет.
Сказки дедушки Бабаяна, часть 2 я, первая на ixbt
Странный тон статьи. Кому то привиделись здесь дифирамбы, а мне наоборот показалось, что вы извиняетесь за русских инженеров, которые (вы не подумайте, совершенно случайно) разработали процессоры со своей архитектурой (нет-нет, не ругайте сразу, на мировые рынки мы не замахиваемся) и запустили партию в производство (но только для военных и энтузиастов). Надо потихоньку привыкать гордиться достижениями своей страны.
Пишите дальше, очень интересно!
Пишите дальше, очень интересно!
Я, в свою очередь, спрошу, чем MCp принципиально отличается от GA144, и почему военные не смогли осилить Forth.
Эмс. Ну, наверное, всем отличается. MCp — это не куча маленьких полноценных процессоров, это один процессор с кучей функциональных устройств. Которые сложнее, чем процессоры GA144. Наверное, на очень высоком абстрактном уровне проекты похожи: давайте исполнять программы не большим целостным процессором, а кучей маленьких одинаковых, взаимозаменямых, устройств. Но коммутационная среда и детали реализации очень разные.
Про Forth надо спрашивать у военных, я не в курсе.
Про Forth надо спрашивать у военных, я не в курсе.
А почему вы пилите компилятор C89, а не напишите бэкенд к llvm, что бы не парится фронтендом? Сильно специфичные оптимизации, которые в llvm делать неудобно?
Да. Оптимизации нужны специфичные. Но фронтенд и так готовый был взят, который выдаёт тетрадное представление программы, которое уже и транслируется.
Кстати, voidlizard дело говорит. LLVM «легко» расширить своими специфичными оптимизациями, а профита просто вагон был бы. Уточните у разработчиков, почему отказались от LLVM в принципе и рассматривали ли вы его вообще?
Рассматривался, и показалось, что не так уж «легко» его расширять. Существующие кодогенераторы заточены на регистровые машины, а MCp совсем не регистровый. Пришлось бы полностью писать новый кодогенератор. А для промежуточного представления LLVM это не так уж и просто, там SSA представление с phi-узлами вместо ветвлений… А потом ещё не понятно, насколько сложно потом будет верификацию к этому делу прикрутить. Собственно вот. Плюшки LLVM в нашем случае не особо понятны, а проблемы вполне были обозримыми, поэтому и отказались.
Выше отвечали, что заказчику нужен С89.
То есть можно допустим иметь процессор на много много клеток, и без адаптации кода он будеть работать намного быстрее? (код)
То есть, извините за тупой вопрос, можно и линукс вот так запустить, и иметь теоретически бесконечный прирост производительности в зависимости о процессора?
То есть, извините за тупой вопрос, можно и линукс вот так запустить, и иметь теоретически бесконечный прирост производительности в зависимости о процессора?
Нет. В реальных программах есть же зависимости, которые не позволяют вообще всё делать параллельно. Так что, бесплатно не получится. Но много-много клеток сделать можно, это обеспечит, например, устойчивость к поломкам или возможность динамически распределять ресурсы между несколькими программами.
Но если код допускает распараллеливание, то простое увеличение числа клеток позволяет без дополнительного софта увеличить производительность?
Например, код типа:
выполнится в 4 раза быстрее чем на одной клетке, если число клеток больше трёх? Без всякого специального выделения потоков, процессов и т. п. Просто серез «такт» получим в четырех регистрах ноли?
Например, код типа:
MOV AX, 0
MOV BX, 0
MOV CX, 0
MOV DX, 0
выполнится в 4 раза быстрее чем на одной клетке, если число клеток больше трёх? Без всякого специального выделения потоков, процессов и т. п. Просто серез «такт» получим в четырех регистрах ноли?
Это верно, конечно. Просто в реальных программах не так уж и много подобных конструкций.
Я принцип работы этих клеток хочу понять.
У каждой есть буфер с инструкциями, для которых записано, каких аргументов они ждут. Когда клетка получает все необходимые для какой-то инструкции данные, она эту инструкцию выполняет, а результат записывает в коммутатор. Ну, и этот цикл повторяется.
Когда все инструкции из одного предложения таким образом выполнены, в клетки загружается новый код (на самом выполнение и загрузка нового кода могут идти одновлеменно, но это оптимизации). И так далее
Когда все инструкции из одного предложения таким образом выполнены, в клетки загружается новый код (на самом выполнение и загрузка нового кода могут идти одновлеменно, но это оптимизации). И так далее
Написано, что процессор общего назначения. Чем он принципиально для меня, как для потребителя лучше?
(не системщик, но разницу между мьютексами и бин. семафорами знаю)
(не системщик, но разницу между мьютексами и бин. семафорами знаю)
Так я ж писал. Ничего магически-мистического нет в нём. Второй закон термодинамики он не нарушает :) Его конкурентные преимущества (ничего переломного, просто преимущества) — это энергоэффективность и устойчивость к собственным поломкам.
Читал, но думал еще информация будет.
Вот энергоэффективность — это весьма хорошо. А вот устойчивость к поломкам важна ли юзеру?.. Не помню, когда у меня последний раз своей смертью умирал проц. А планируется возможность принудительного отключения какого-то процента ячеек для большего энергосбережения?
Сидишь, читаешь книгу с ноута, и в моменты между действиями пользователя 99.9% ячеек спят =)
Вот энергоэффективность — это весьма хорошо. А вот устойчивость к поломкам важна ли юзеру?.. Не помню, когда у меня последний раз своей смертью умирал проц. А планируется возможность принудительного отключения какого-то процента ячеек для большего энергосбережения?
Сидишь, читаешь книгу с ноута, и в моменты между действиями пользователя 99.9% ячеек спят =)
Ну… Устойчивость к поломкам и «отключабельность» — это в некотором смысле одно и то же. Не важно же, по какой причине отключился кусок процессора из-за поломки или по просьбе пользователя. Поэтому, «отключабельность» тоже возможна. Но пока этого нет, насколько мне известно.
Энергоэффективность и отказоустойчивость заявлена скорее всего применительно к космосу, т.е. при воздействии радиации, перегрузок и перепадов температур. В таком случае вполне вероятно, что чип может повредиться внутри частично и сохранит работоспособность во время полёта, а не потопит корабль в океане.
Проблема видится в том, как этот механизм реализован, на сколько он децентрализирован и устойчив.
Проблема видится в том, как этот механизм реализован, на сколько он децентрализирован и устойчив.
Все же хотелось бы понять вот что: процессор отличается от функционального устройства тем, что самостоятельно ведет поток исполнения программы. Обычно этот поток связан со счетчиком команд. Здесь команды выполняютсчя параллельно в рамках параграфа, соответственно поток связан с указателем параграфов. Параграф, можно считать, эдакая сверхширокая команда.
Так вот: в чем проявляется параллелизм на уровне клеткок? Они одновременно исполняют инструкции из разных параграфов, или одного и того же?
Так вот: в чем проявляется параллелизм на уровне клеткок? Они одновременно исполняют инструкции из разных параграфов, или одного и того же?
Нужно ли будет использовать какие-то специальные способы оптимизации (специальные инструкции или какую-то схему распараллеливания) или эта работа полностью перекладывается на компилятор, и обычные программы на С начинают работать быстрее за счёт внутриклеточного распараллеливания? Пока слабо верится, что можно будет обойтись без оптимизации руками.
Жаль сервер всё лежит, а какие показатели энергопотребления у него?
Жаль сервер всё лежит, а какие показатели энергопотребления у него?
Бенчмарки то где, уровень энергопотребления?
Пока сервер лежит, кэш яндекса работает)
Даташит отладочной платы, кому интересно:
http://www.multiclet.com/docs/Datasheet_MCp0411100101.pdf
Правда там нет ничего интересного о характеристиках самого проца. Набор входов/выходов довольо ограничен, за-то есть ethernet. Интересно, как скажется на производительности интенсивный ввод/вывод при обработке сигналов в реальном времени.
Даташит отладочной платы, кому интересно:
http://www.multiclet.com/docs/Datasheet_MCp0411100101.pdf
Правда там нет ничего интересного о характеристиках самого проца. Набор входов/выходов довольо ограничен, за-то есть ethernet. Интересно, как скажется на производительности интенсивный ввод/вывод при обработке сигналов в реальном времени.
Во всём этом меня смущает частота упоминания правительства. Делаете? Делайте! При чём тут единая россия, кремль и прочие госслужащие?
Миллионны и года потрачены, а сервер лежит уже сутки.
Ошибка видимо на клеточном уровне…
Ошибка видимо на клеточном уровне…
Просто учитывайте разницу во времени
Какая разница? Вы о чем? Это просто должно работать 24/7/365.
У вас там вообще по сути одна статика должна быть (пусть бы и сгенерированная).
Статику — сотни тысяч посещений в сутки можно держать на сервере за $100 в месяц.
А вы говорите — выходной. На спичках экономите.
Если выход на рынок не нужен, и все делалось только ради гос-поддержки и военных заказов,
то тогда зачем вообще все эти анонсы на разных сайтах?
Вы уж определитесь, вы частная компания или на бюджетную зарплату живете.
Я безумно рад что вы делаете довольно интересное железо (тем более в наших условиях), но время сейчас другое.
Страны советов уже 20 лет как нет, а отношение к работе все не поменяете.
У вас там вообще по сути одна статика должна быть (пусть бы и сгенерированная).
Статику — сотни тысяч посещений в сутки можно держать на сервере за $100 в месяц.
А вы говорите — выходной. На спичках экономите.
Если выход на рынок не нужен, и все делалось только ради гос-поддержки и военных заказов,
то тогда зачем вообще все эти анонсы на разных сайтах?
Вы уж определитесь, вы частная компания или на бюджетную зарплату живете.
Я безумно рад что вы делаете довольно интересное железо (тем более в наших условиях), но время сейчас другое.
Страны советов уже 20 лет как нет, а отношение к работе все не поменяете.
Да ладно вам. Вон у Amazon-а тоже сервера падают. Падают они от хабраэффекта и у профессиональных веб-разработчиков, разрабатывающих именно веб-сервисы. По каким причинам сайт МультиКлета должен быть намного надёжнее? WEB — это не профильная технология для фирмы.
Ну… И это никакой не анонс и не привлечение клиентов. Пост был сделан для рассказа о том, что у нас такие проекты в стране есть, не смотря ни на что.
Ну… И это никакой не анонс и не привлечение клиентов. Пост был сделан для рассказа о том, что у нас такие проекты в стране есть, не смотря ни на что.
Насколько я понимаю, принцип работы этого процессора чем-то схож с принципом работы dataflow-архитектуры. Или даже таковым является. Я прав?
Вот тут еще есть информация про dataflow.
Вот тут еще есть информация про dataflow.
Угу. Но только есть различные тонкости в том, как описывать программу для dataflow-процессора. В MCp, вроде как, впервые (выдан же патент) удалось программу закодировать в неком «правильном» виде. Насколько я знаю, в предыдущих dataflow-машинах сложно было писать программы, потому что в инструкции описывался токен, который надо передать в коммутатор вместе с результатом исполнения (то есть, в инструкциях, как бы, должны были стоять ссылки вперёд) и который потом будет использован для выбора новой инструкции. И было очень сложно кодировать в такой парадигме циклы, ветвления. Потому что, фактически, нужно было описывать статический граф потока данных, а это очень громоздкая и неудобная конструкция, если необходимо задавать ветвления.
MCp же это некий гибрид потоковой архитектуры и классической, когда у инструкции есть не одинкритерий для запуска (пришёл токен), а два: пришёл токен и она следующая в потоке исполнения. И это радикально упрощает программирование и повышает гибкость. Примерно так (если, конечно, я верными знаниями обладаю по потоковым машинам предыдущих поколений, я о них только в обзорах читал, подобных приведённому Вами).
MCp же это некий гибрид потоковой архитектуры и классической, когда у инструкции есть не одинкритерий для запуска (пришёл токен), а два: пришёл токен и она следующая в потоке исполнения. И это радикально упрощает программирование и повышает гибкость. Примерно так (если, конечно, я верными знаниями обладаю по потоковым машинам предыдущих поколений, я о них только в обзорах читал, подобных приведённому Вами).
«И было очень сложно кодировать в такой парадигме циклы, ветвления».
Однако, как я понимаю, в MCp параллелизм возможен только внутри параграфа, а параграф — линейный участок кода. То есть циклы и ветвления в MCp делаются как в фон-Неймановской машине и не распараллеливаются вовсе.
Однако, как я понимаю, в MCp параллелизм возможен только внутри параграфа, а параграф — линейный участок кода. То есть циклы и ветвления в MCp делаются как в фон-Неймановской машине и не распараллеливаются вовсе.
Не совсем так. В готовой версии процессора, несколько подряд идущих параграфов при определённых условиях могут выполняться одновременно (к тому же параллельно могут загружаться инструкции для исполнения). В некоторых случаях несколько итераций цикла могут выполняться параллельно. За счёт этого, например, достигается высокая эффективность на БПФ.
В будущих версиях, возможно, будет некий вариант многопоточности, когда и параграфы можно будет исполнять параллельно, и если компилятор справится с автораспараллеливанием циклов, то и циклы будут выполняться параллельно.
У ветвлений же семантика строго последовательная, поэтому их иначе и не выполнить.
В будущих версиях, возможно, будет некий вариант многопоточности, когда и параграфы можно будет исполнять параллельно, и если компилятор справится с автораспараллеливанием циклов, то и циклы будут выполняться параллельно.
У ветвлений же семантика строго последовательная, поэтому их иначе и не выполнить.
На сайте разработчиков пугает:… ядро с принципиально новой… Это с Bolgen Os никак не связано?
Чем обусловлен ваш выбор Coq в качестве proof-asstant'а? Почему например не agda?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Первая опытно-промышленная партия отечественных мультиклеточных процессоров MCp