У нас есть процессоры?

 
1 7 8 9 10 11 12 13
+
-
edit
 

Varkadak

втянувшийся

А существует в природе какой-нибудь классный учебник на тему процессоров?

Хотелось бы чего-то уровня Левантовский, "Механика космического полета в элементарном изложении", но про процессоры.

Можно на английском.
 
EU Татарин #25.06.2014 12:40  @yacc#21.06.2014 02:02
+
-
edit
 

Татарин

координатор
★★★★☆
Татарин>> Код компиляторов плохо поддаётся оптимизации под VLIW
yacc> Саша тебе говорит другое. В нескольких словах - компиляция кода распараллеливается - целевые cpp распределяются по машинам. И если архитектура такая, что особо параллелить нечего - то компиляция будет тормозить.
Я понимаю, о чём говорит Саша, я не понимаю, как это связано с предметом обсуждения. :)
Есть факт: производительность на VLIW-процессорах компиляторов мала (почему - понятно, суть архитектуры и особенности кода компиляторов) и может быть недостаточна для типично офисной задачи - работы программиста.
Собссно, всё. Зачем тут обсуждать гриды? :)
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
EU Татарин #25.06.2014 13:02  @Santey#21.06.2014 09:23
+
-
edit
 

Татарин

координатор
★★★★☆
Santey> Похоже, ты что то путаешь. Вот, советую ознакомиться:
Нет, я ничего не путаю.

Santey> Порядка сотни процентов (но никак не сотЕН и тысЯЧ) были вплоть до 180нм, далее уже только десятки процентов. После 180нм "вылизывание" самого ядра при том же техпроцессе дает прирост ТЧ даже больший, чем совершенствование техпроцесса.
Причём тут схемотехническое "вылизывание" ядра?
Было конкретное утверждение насчёт конкретного сравнения конкретных процессоров - стандартные библиотеки тормозат "Эльбрус". Да, тормозят. Но вовсе не настолько, чтоб компенсировать фору в техпроцессе. Насчёт этого возражения есть?

Santey> Опять же, наличие 2-гигагерцового Pentium-M с ТП 90нм (в сравнении с 500МГц Эльбрусом на том же уровне ТП) ясно свидетельствует о том, что в настоящее время ТП вносит отнюдь не решающий вклад в рост ТЧ.
О, боже... :) Конечно, решающий.
И конечно, тактовая частота зависит от архитектуры целиком и полностью. Техпроцесс определяет (в том числе, если грубо) скорость нарастания/падения фронтов на гейте. Откуда для блока вытекает максимально возможная частота, на которой он может работать синхронно. Потому что разное количество гейтов на разных путях прохождения инфы даёт разную задержку.
Но вот разница в количестве гейтов зависит целиком от архитектуры.

Кольцевой генератор вообще на десятках-сотнях ГГц на нынешних техпроцессах запустится. Это ж не значит, что на том же ТП легко сделать процессор с такой тактовой частотой. :)
Хотя... какой-нить Z80 с его 8500 транзисторами наверняка полетел бы замечательно... :D

Santey> Снова ты не прав. Признаться, удивлен, что ты не в курсе насчет того, что Intel Pentium-M и Intel Core - это одна и та же архитектура.
?! Я говорил о конкретном Пентиуме-М.
А "Пентиум-М" и "Интел Коре" - это торговые марки. Под которыми живут самые разные архитектуры. Не, ну в принципе-то - да, изменения были эволюционные, и, наверняка, наследие можно проследить. Но архитектуры это разные.

И уж точно разные архитектуры у того Пентиума и у того Эльбруса.
Предельно некорректно сравнивать в духе "что было бы, если б Эльбрус работал на той же частоте". За "ту же частоту" создателям процессора приходится бороться всеми методами, и не в последнюю очередь - при строительстве логики.

Santey> Поэтому никакая он не древность в плане архитектуры. Совсем наоборот: основан одной из лучших на данный момент архитектур для x86.
К х86 он имеет отношение слабое. Кстати, на графиках - родной код, достаточно "удобные" для VLIW тесты и, НЯП, опять приведено к равной частоте.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
EU Татарин #25.06.2014 13:11  @101#21.06.2014 16:00
+
-
edit
 

Татарин

координатор
★★★★☆
Татарин>> Код компиляторов плохо поддаётся оптимизации под VLIW: много условных переходов, нечем забить ИУ.
101> Если вы не закладываете явный параллелизм в исполняемый код, то пенять на компилятор не нужно.
Во-первых, нужно.
Потому что компилятор компилирует тот код, что написали, а процессор потом исполняет то, что накомпилялось. Потом сравнивают скорости исполнения на разных процессорах и смотрят, что получилось.
Переписывать весь Линукс со всем набором прикладушек "под явный параллелизм" никто никогда не будет (и даже давным-давно известные рекомендации по общей оптимизации кода основной массой программистов не выполняются). Имеем, что имеем.

Во-вторых, про то и шла речь, что сами компиляторы - пример очень плохо распараллеливаемого кода. Для любой архитектуры. Просто вот задача (пока?) такая, так компиляторы (пока?) устроены.

101> Касаемо производительности, то слышал такие оценки: 800 МГц 4 ядерный Эльбрус на некой матричной задаче дал скорострельность в 1.5 раза ниже, чем современный 3 ГГц Интел на 4 ядрах.
Беда в том, что "на некой матричной задаче" Эльбрус будет сосать со свистом у простенького специализированного ДСП или ускорителя, как и любой универсальный ЦПУ. Для любого проца есть удобные ему задачи. Для большинства задач можно сделать быстрый на них ЦПУ.
Это процессор общего назначения, и нужно смотреть его производительность на типичных для него задачах, для которых он делался, и если уж сравниваем с х86 - то на задачах, характерных для х86.
Только так.

101> Эльбрусовцы с нетерпением ждут инженерный образец на 8 ядер с частотой 1.6 ГГц в этом году.
Да. На 28 нанометрах.
Кстати, нынешние образцы тоже изначально планировали на гигагерц (по лабораторным симуляциям для данного техпроцесса). Не срослось.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
RU yacc #25.06.2014 13:16  @Татарин#25.06.2014 12:40
+
-
edit
 

yacc

старожил
★★☆
Татарин> я не понимаю, как это связано с предметом обсуждения. :)
Ну не я же предложил в пример проект на С++ ? :)
Если проект параллелился, то распределнными вычислениями его в разумное время можно компилировать и на более слабых процессорах.
 
EU Татарин #25.06.2014 13:31  @yacc#25.06.2014 13:16
+
-
edit
 

Татарин

координатор
★★★★☆
yacc> Если проект параллелился, то распределнными вычислениями его в разумное время можно компилировать и на более слабых процессорах.
Это реальная тоска. :)
Особенно, когда при компиляции тебе нужно играть с билд-машиной.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
EU Татарин #25.06.2014 13:32  @Татарин#25.06.2014 13:31
+
-
edit
 

Татарин

координатор
★★★★☆
Новость в тему:

Новый 8-ядерный микропроцессор Эльбрус-8С

Компания ЗАО "МЦСТ" запустила в производство опытную партию универсальных микропроцессоров Эльбрус-8С. Расчётная рабочая частота чипа - 1.3 ГГц, технология производства – 28 нм,   вычислительная мощность составляет 250 гигафлопс. Получение готовых образцов микросхем ожидается в октябре 2014 года. Микропроцессор Эльбрус-8С - полностью российская разработка. Кристалл микропроцессора спроектирован по технологии 28 нм, имеет 8 процессорных ядер с улучшенной 64-разрядной архитектурой Эльбрус 3-го поколения, кэш-память 2-го уровня общим объёмом 4 мегабайта и 3-го уровня объёмом 16 мегабайт. // Дальше — www.mcst.ru
 
Компания ЗАО "МЦСТ" запустила в производство опытную партию универсальных микропроцессоров Эльбрус-8С. Расчётная рабочая частота чипа - 1.3 ГГц, технология производства – 28 нм, вычислительная мощность составляет 250 гигафлопс. Получение готовых образцов микросхем ожидается в октябре 2014 года.
 
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
RU yacc #25.06.2014 13:37  @Татарин#25.06.2014 13:31
+
-
edit
 

yacc

старожил
★★☆
Татарин> Это реальная тоска. :)
Татарин> Особенно, когда при компиляции тебе нужно играть с билд-машиной.
У нас был проект движка DB, так все компы разработчиков были включены в грид. Когда я компилировал проект у себя, он распараллеливался на другие машины. Также использовалась и моя.
Почти во столько раз быстрее, сколько машин в гриде. Тоска была компилировать вне грида у себя локально :)
 
RU 101 #25.06.2014 16:34  @Татарин#25.06.2014 12:40
+
-
edit
 

101

аксакал

Татарин> Есть факт: производительность на VLIW-процессорах компиляторов мала (почему - понятно, суть архитектуры и особенности кода компиляторов) и может быть недостаточна для типично офисной задачи - работы программиста.


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

Под офисными приложениями я в первую очередь имею в виду цифровой документооборот - текстовые процессоры/редакторы, графика, моделирование. Это 90% того, чем занимается машиностроение.
С уважением  1414
RU Santey #25.06.2014 16:51  @Татарин#25.06.2014 13:02
+
-
edit
 

Santey

опытный

Татарин> О, боже... :) Конечно, решающий.

Я привел таблицу, из которой хорошо видно, что, начиная с определенного значения технологических норм, переход на новый техпроцесс давал выигрыш по ТЧ в районе 15%.

Опять же, для Эльбруса-8С, о котором уже упоминалось в ветке, при переходе с 65нм на 24нм ТЧ выросла с 800МГц до 1.3ГГц (пока расчетное значение). Т.е. далеко не на сотни и, тем более, не тысячи процентов. Не смотря на скачок сразу на несколько "ступенек" по части нормы техпроцесса.

Татарин> И конечно, тактовая частота зависит от архитектуры целиком и полностью. Техпроцесс определяет (в том числе, если грубо) скорость нарастания/падения фронтов на гейте.

Это все понятно. Но full custom позволяет выбрать оптимальное взаимное расположение транзисторов, подобрать их оптимальную пространственную ориентацию, размерность, выбрать оптимальные соединения их друг с другом (и, стало быть, уменьшить длину этих соединений). Так пишут в умных книжках :). Сообщается, что после full custom плотность элементов на той же площади возрастает в разы (в сравнении со standard cell). Следовательно, значительно уменьшается и длина соединений.
Ну и напоследок выдержка из одного документа:

We find that full-custom design outperforms standard-cell design mainly through a more aggressive circuit design (domino technique and detailed sizing). The more aggressive circuit technique exhibits delay reductions of 50-70% compared to the ordinary static technique.
 


Т.е. выигрыш по задержкам составил 50-70% (сравнение производилось на примере проектирования 64-битных сумматоров).
 30.030.0
Это сообщение редактировалось 25.06.2014 в 17:26
RU Santey #25.06.2014 17:19  @Татарин#25.06.2014 13:02
+
-
edit
 

Santey

опытный

Santey>> Снова ты не прав. Признаться, удивлен, что ты не в курсе насчет того, что Intel Pentium-M и Intel Core - это одна и та же архитектура.
Татарин> ?! Я говорил о конкретном Пентиуме-М.

Не понял смысла этой фразы. На странице с результатами тестирования, ссылку на которую я привел, ясно сказано, что для сравнения использовался вполне конкретный Intel Pentium-M ULV 1ГГц. Если ты завел речь о неком другом конкретном Pentium-M - то в какой связи?

Татарин> А "Пентиум-М" и "Интел Коре" - это торговые марки. Под которыми живут самые разные архитектуры.

Одна и та же архитектура P6. Тут и спорить не о чем. Стоит поинтересоваться вопросом у Гугла, и все сомнения отпадут чудесным образом. Микроархитектура, само собой, менялась.
А в случае c Core Solo речь может идти даже об одном и том же ядре под названием "Yonah". Потому как на Pentium-M ULV применяется именно оно, если верить таблице на страничке Ноутбуки: все о новой платформе NAPA. Cтатьи, тесты, обзоры
 30.030.0
Это сообщение редактировалось 25.06.2014 в 17:54
RU Santey #25.06.2014 17:23  @Татарин#25.06.2014 13:32
+
+1
-
edit
 

Santey

опытный

Татарин>
Компания ЗАО "МЦСТ" запустила в производство опытную партию универсальных микропроцессоров Эльбрус-8С. Расчётная рабочая частота чипа - 1.3 ГГц, технология производства – 28 нм, вычислительная мощность составляет 250 гигафлопс.
 


Е-мое, вот это новость! Парни из МЦСТ просто жгут в последнее время, такой темп набрали! Просто красавцы, так держать!
Видимо, с какого то момента финансирование в требуемых объемах все таки пошло.
 30.030.0
RU Серокой #25.06.2014 17:25  @Santey#25.06.2014 17:23
+
-
edit
 

Серокой

координатор
★★★★
Santey> Видимо, с какого то момента финансирование в требуемых объемах все таки пошло.

Плюс поувольняли кучу инженеров. :)
Больше не раскалятся ваши колосники. Мамонты пятилеток сбили свои клыки. ©  

101

аксакал

Татарин>>
Santey> Е-мое, вот это новость! Парни из МЦСТ просто жгут в последнее время, такой темп набрали! Просто красавцы, так держать!
Santey> Видимо, с какого то момента финансирование в требуемых объемах все таки пошло.

Финансирование давно уже идет. Вы думаете комплексы от Алмаз-Антей на чем построены?
С уважением  1414

Santey

опытный

101> Финансирование давно уже идет. Вы думаете комплексы от Алмаз-Антей на чем построены?

Вопрос в степени масштабности этого финансирования, и насколько оно достаточно для решения серьезных задач и создания массового продукта.
Судя по хронологии успехов мцст-вцев, финансирование заметно выросло в последние лет 6-7, что радует. Главное не останавливаться на достигнутом и не терять темпа. Совершенствовать микроархитектуру, а не только наращивать число ядер и увеличивать ТЧ.
 30.030.0
+
+1
-
edit
 

Santey

опытный

Набрел на досуге на документец, повествующий о процах МЦСТ, в котором есть одна картинка, дающая представление, насколько должна вырасти тактовая частота Эльбрусов после перехода на full custom.
Смотрим рисунок 5(а): для Эльбруса-4С предполагалось достичь 1Ггц (в реале получилось 800МГц), для Эльбруса-8С при 45нм и заказной технологии (она же full custom) нарисовано уже 2 ГГц, на самом деле для этого камня ожидается 1.3ГГц - видимо, на full custom то ли денег не нашлось, то ли времени не хватило. Исходя из картинки, выходит, что в случае с Эльбрусами full custom позволяет поднять ТЧ процентов на 50.
 30.030.0
RU 101 #26.06.2014 17:59  @Татарин#25.06.2014 13:11
+
-
edit
 

101

аксакал

Татарин> Переписывать весь Линукс со всем набором прикладушек "под явный параллелизм" никто никогда не будет (и даже давным-давно известные рекомендации по общей оптимизации кода основной массой программистов не выполняются). Имеем, что имеем.

Ну, Эльбрусовцы целуют крест, что ключевые библиотеки Линукса они уже переписали и даже референсные дровишки под AMDшные видюхи тоже перелопатили.


Татарин> Во-вторых, про то и шла речь, что сами компиляторы - пример очень плохо распараллеливаемого кода. Для любой архитектуры. Просто вот задача (пока?) такая, так компиляторы (пока?) устроены.

Компиляторы не есть массовый продукт, поэтому можно и потерпеть.

Татарин> Беда в том, что "на некой матричной задаче" Эльбрус будет сосать со свистом у простенького специализированного ДСП или ускорителя, как и любой универсальный ЦПУ.

Если бы это было так просто, то все давно бы уже радостно улулюкали. Матричные задачи очень разные при, казалось бы, некой общей сути. В итоге всяческих свистоплясок все опять вернулось на круги своя к процессорам общего назначения с векторизацией. И это всем выгодно по ряду причин, в том числе ценовым и архитектурным.
Кстати, тот же самый GPU так до сих пор и не стал массовым средством перелопачивания матриц. Есть ряд задач. где он что-то может, но наиболее интересующие промышленность задачи в части мат.моделирования он пока потянуть в полной мере не может.
С уважением  1414
EU Татарин #27.06.2014 13:26  @101#26.06.2014 17:59
+
+1
-
edit
 

Татарин

координатор
★★★★☆
101> Ну, Эльбрусовцы целуют крест, что ключевые библиотеки Линукса они уже переписали и даже референсные дровишки под AMDшные видюхи тоже перелопатили.
Оставим эти заявления про "переписывание" на совести их пресс-релизеров.
Они перекомпиляли под Эльбрус, да (пришлось, очевидно, что-то поправлять). Нашли попутно какие-то ошибки - тоже поправили. Но "переписать основные библиотеки" без потери совместимости и не наплодив кучу новых багов - это за пределами возможностей команды в пару десятков человек. Им только перекомпиляцией заниматься и заниматься...

101> Компиляторы не есть массовый продукт, поэтому можно и потерпеть.
Хорошо. Экселевские таблички с формулами - массовый продукт? или как?
Там тоже код очень плохой для VLIW (в силу организациии тех табличек).

101> Если бы это было так просто, то все давно бы уже радостно
А всё именно так просто и все именно улюлюкают.
Там, где требуются массовые вычисления какой-нить характерной задачи, там проще сделать свой (заточеный под неё) ASIC или даже прописать ПЛМ.

101> Кстати, тот же самый GPU так до сих пор и не стал массовым средством перелопачивания матриц. Есть ряд задач. где он что-то может, но наиболее интересующие промышленность задачи в части мат.моделирования он пока потянуть в полной мере не может.
Если было бы сказано " все интересуюшие промышленность задачи" - я б согласился безоговорочно.
А так... как раз-таки с наиболее интересующими GPU вполне дружат. :)
Тянут.

Слегка оффтоп, но там беда, скорее, в другом: у промышленноти очень много всяких интересных задач, а переписывать каждый раз задачу под специфику CUDA (или там OpenCL) - дико сложно и дорого. И на порядки сложно и дорого там, где идёт речь о чем-нить существенном.
Взять например, расчёт по оптимизации нейтронного поля в реакторе - там (если по уму) впечатляющие мощности нужны (особенно, в резонансной области). Но GPU там не использовать. :) Почему? Потому что перевод этих кодов даже с Фортрана - это работа лет на 10 по сертификации (в смысле - в том числе, работа с реальным железом и сверке). И даже без сертификации цена ошибки может быть очень велика.

Просто как пример - завершившаясяв прошлом году история с реакторами на Сан-Офре. Продляли срок эксплуатации, меняли старые парогенераторы на новые, заказаные у Мицубиши Хеви Индастриз. Поменяли, через некоторое время обнаружили зашкаливающий фреттинг-износ (просто трубки теплообменника друг о друга трутся при эксплуатации). После года инженерно-судебных разборок оказалось, что новые парогенераторы считали старым, таки верифицированым кодом, но новый интерфейс к нему слишком "обобщал" понятие параметра шага, поэтому японские инженеры сами того не подозревая сунули (грубо говоря) не ту цифру не туда (шаг решётки этих парогенераторов - на атоминфо.ру отслеживалась вся история и была статья с подробным разбором полётов). Ещё раз подчёркиваю: поменяли только интерфейс, расчётное ядро не трогали (да и не дал бы никто).
Итоги "увеличесния удобства": парогенераторы стоимостью 600М долларов - на свалку. Все работы по обоснованию продления эксплуатации в пару сот миллионов - в пень. Дорогая операция по их замене (и дорогущее время простоя АЭС) - псу под хвост. Два блока АЭС стоимостью в несколько миллиардов закрыты... и мультипликативный эффект для экономики штата из-за подорожания энергии, увольнения людей и снижением налоговой базы считать не будем.
Кстати, оборудование первого контура, так что ядерной безопасности вся эта байда тоже касалась напрямую. Но диагностика, всякие там сафети-гуардс и сверхконсервативный (в остальном :)) подход атомщиков спасли.

А теперь, имея перед глазами такой пример (совсем недавний, и история ещё не закончилась - там остальные блоки тепрь под угрозой закрытия) - захочешь ли ты вкладывать миллионы, десятки (в плохих случаях - сотни миллионов) в перенос расчётного кода на платформу GPU (потому что "быстрее и дешевле")? Или пусть пока в Фортране побудет, по возможности быстрое железо мы докупим, да и подождать лишнюю неделю окончания расчётов - тоже не зудит? :)

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

И только поэтому во многих областях спецвычислители не входят в жизнь - внедрение дорого.
Только поэтому.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  35.0.1916.15335.0.1916.153
RU 101 #27.06.2014 18:54  @Татарин#27.06.2014 13:26
+
-
edit
 

101

аксакал

Татарин> Оставим эти заявления про "переписывание" на совести их пресс-релизеров.

Это не пресс-релизы, это информация с рабочей встречи с эльбрусовцами.

Татарин> Им только перекомпиляцией заниматься и заниматься...

Не ошибается тот, кто ничего не делает.

Татарин> Там тоже код очень плохой для VLIW (в силу организациии тех табличек).

Ну плохой и бог с ним. Для реальных прикладных задач возможностей гигагерцовых многядерников вполне хватит. Оно уже давно избыточно для всего этого.

Татарин> Там, где требуются массовые вычисления какой-нить характерной задачи, там проще сделать свой (заточеный под неё) ASIC или даже прописать ПЛМ.

И тем не менее, этого не происходит.

Татарин> Если было бы сказано " все интересуюшие промышленность задачи" - я б согласился безоговорочно.
Татарин> А так... как раз-таки с наиболее интересующими GPU вполне дружат. :)
Татарин> Тянут.

Не тянут, в том-то и дело.
Основными интересующими промышленность в лице машиностроения задачами являются задачи прочности (метод конечных элементов), задачи течения жидкости/газа (конечные разности) и задачи акустики (все выше перечисленное + метод граничных элементов).
На сегодняшний день не создано еще ни одного достойного приложения на GPU, которое бы клало на лопатки CPU с AVX.
Все реляции отдельных коллективов при ближайшем рассмотрении оказываются или крайне специализированными реализациями, или упрощенными методами с рядом ограничений или же несут серьезные ограничения по размерности задачи.


Татарин> Взять например, расчёт по оптимизации нейтронного поля в реакторе - там (если по уму) впечатляющие мощности нужны (особенно, в резонансной области). Но GPU там не использовать. :) Почему? Потому что перевод этих кодов даже с Фортрана - это работа лет на 10 по сертификации (в смысле - в том числе, работа с реальным железом и сверке). И даже без сертификации цена ошибки может быть очень велика.

Да забудь ты про Фортран. Кому надо те уже дано на Си сидят. Но на GPU один фиг не спешат при этом.

Татарин> Просто как пример - завершившаясяв прошлом году история с реакторами на Сан-Офре. Продляли срок эксплуатации, меняли старые парогенераторы на новые, заказаные у Мицубиши Хеви Индастриз. Поменяли, через некоторое время обнаружили зашкаливающий фреттинг-износ (просто трубки теплообменника друг о друга трутся при эксплуатации). После года инженерно-судебных разборок оказалось, что новые парогенераторы считали старым, таки верифицированым кодом, но новый интерфейс к нему слишком "обобщал" понятие параметра шага, поэтому японские инженеры сами того не подозревая сунули (грубо говоря) не ту цифру не туда (шаг решётки этих парогенераторов - на атоминфо.ру отслеживалась вся история и была статья с подробным разбором полётов). Ещё раз подчёркиваю: поменяли только интерфейс, расчётное ядро не трогали (да и не дал бы никто).

Знаю про этот случай, т.к. был на докладе по этому вопросу в одной росатомовской тусовке и там причины немного в другом озвучивались и япошки обо всем знали, как выяснилось, но стоически молчали по Достоевскому. Ну да не суть.
Этот пример тут вообще не в кассу.

Татарин> А теперь, имея перед глазами такой пример (совсем недавний, и история ещё не закончилась - там остальные блоки тепрь под угрозой закрытия) - захочешь ли ты вкладывать миллионы, десятки (в плохих случаях - сотни миллионов) в перенос расчётного кода на платформу GPU (потому что "быстрее и дешевле")?

Я тебе по секрету скажу, что мы участвовали в подобной работе. Просто такую работу нужно делать аккуратно со знанием дела. Все это заняло не более года. Но в итоге заказчик отказался от внедрения, т.к. переход на GPU на реальных постановках не дал практически никакого значимого выигрыша.
С уважением  1414
EE Татарин #03.12.2014 03:29  @101#27.06.2014 18:54
+
+1
-
edit
 

Татарин

координатор
★★★★☆
По наводке DZ запротоколирую тут учебник по архитектуре "Эльбруса".

Полное описание, достаточно много рассказано о железе.
...А неубитые медведи делили чьи-то шкуры с шумом. Боюсь, мы поздно осознали, к чему всё это приведёт.  39.0.2171.7139.0.2171.71
Это сообщение редактировалось 03.12.2014 в 11:32
US Иван Нью-Джерсийский #03.12.2014 03:56
+
-
edit
 
Тупой вопрос.
Можно ли ожидать в продаже российские процы для настольных ПК? Если да, то когда?
 33.033.0

U235

старожил
★★★★★

И.Н.> Можно ли ожидать в продаже российские процы для настольных ПК? Если да, то когда?

В обозримом будущем вряд-ли ПК с российскими процессорами дойдут до пользователей, если не случится каких-то глобальных катаклизмов с Intel. Ибо тягаться с ними на открытом рынке пока никак. Но наверняка будут настольные ПК, защищенные ноутбуки и суперкомпьютеру на отечественных процессорах для военных и прочих спецслужб.
Те, кто ввергает в ад других, никогда не достигнут рая  33.033.0
US Иван Нью-Джерсийский #03.12.2014 05:49  @U235#03.12.2014 04:03
+
-
edit
 
U235> В обозримом будущем вряд-ли ПК с российскими процессорами дойдут до пользователей

Хм. А почему бы МСЦТ не завести дочернее предприятие, занимающееся сбытом процессоров? Чисто экспериментально, со скидкой, закинуть удочку на предмет спроса на них? Да и бета-тест, может, получился бы. Наверное. %)
 33.033.0

AXT

инженер вольнодумец
★☆
И.Н.> Хм. А почему бы МСЦТ не завести дочернее предприятие, занимающееся сбытом процессоров?

Несовместимость с прочим железом. Компьютер — это не только процессор, это набор компонентов. Надо будет делать всю платформу. А это по силам только гигантам. И, кстати, Windows уже давно проверяет, на каком процессоре запускается. Всё, что не Intel или AMD идёт лесом. Был анекдотический случай, когда Intel была вынуждена абсурдным способом делать так, чтобы винда запускалась на новых процах.
 13.0.782.22013.0.782.220
US Иван Нью-Джерсийский #03.12.2014 08:06  @Sandro#03.12.2014 08:02
+
-
edit
 
AXT> Несовместимость с прочим железом. Компьютер — это не только процессор, это набор компонентов. Надо будет делать всю платформу.

Почему всю? Разве не только мамку?
ОК, разве нельзя проц подогнать под стандарты?

AXT> А это по силам только гигантам. И, кстати, Windows уже давно проверяет, на каком процессоре запускается. Всё, что не Intel или AMD идёт лесом.

Ну, не обязательно "Винду". Можно "Линукс" попробовать или QNX с нормальной графической оболочкой. Не?
 33.033.0
1 7 8 9 10 11 12 13

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru