Comments 70
Как насчет облачных вычислений для развлечений? Не самая наукоёмкая часть, конечно, это не моделирование тонких взаимодействий и не создание прогноза погоды, но предоставление масштабируемых мощностей для игр «через интернет», где передается готовая картинка, а не только данные. Системы распознавания образов для игр в дополненной реальности? Только представьте — GTA через Google Street View. Все это требует не меньших мощностей для работы.
GTA наукоемкая? :D
Жаль, если вы не успели отхватить себе кусочек в Monopoly City Streets. И вряд ли вы могли обойти стороной MMORPG, раз уж подняли эту тему. И, наверняка, вы слышале о сервисе Last.FM и ему подобным. Все эти примеры, в большей или меньшей степени, используют «облачные» подходы. До GTA через Google Street View нам ещё, возможно, далековато. Но есть ощущение, что индустрия развлечений является одним из пионеров в освоении «облачных» вычислений.
И, да, расскажите пожалуйста поподробней об «отказоустойчивости» новых Нехалемов. Хотя бы в общих чертах, как это дело работает? Уж очень интересно.
Одной из ключевых функций отказоустойчивости новых моделей Xeon серии 7500 (кодовое название Nehalem-EX) является механизм Machine Check Architecture (MCA) Recovery. Этот механизм позволяет системе выдерживать ошибки в памяти, которые невозможно исправить с помощью традиционного ECC или других способов — в противном случае происходит «синий экран». А с использованием MCA Recovery система, взаимодействуя с ОС, локализует ошибку, делает соответствующую запись в системном журнале событий, но продолжает функционировать. Приложение, связанное с областью памяти, где возникла ошибка, должно будет перезапуститься. В качестве ссылки на «живой» пример могу дать неофициальную заметку с официального мероприятия, где упомянутый функционал можно разглядеть на картинке. Там было сравнение Xeon серии 7500 и Xeon серии 7400 с искусственным созданием непоправимой ошибки в памяти. Первая система «выжила», а вторая — нет. Из других функций стоит отметить «SMI lane fail-over» и «QPI self-healing» — но это уже ближе к уровню чипсета и потенциальных помех и сбоев на уровне материнских плат.
По поводу увеличения степени параллельности вычислений, есть ли у Intel какие либо идеи по поддержке на аппаратном уровне возможностей, которые могли были бы быть использованы в сфере искусственного интеллекта? Есть ли у Intel какие либо идеи в отношении высокоскоростных шин со сложной навигацией рассчитанной тысячи и десятки тысяч элементов(ядер)? Сейчас эта область возможно и не так массово развита, но при должном внимании обещает быть перспективной.
Что касается вообще высокопроизводительных вычислений, какие основные стратегии развития у Intel: увеличение скорости/улучшение архитектуры кристаллов или основной упор всё же на распараллеливание? Планируется ли поддержка навигации параллельных потоков на аппаратном уровне для большого числа ядер (а-ля HyperThreading), как, если я не ошибаюсь, сейчас сделано в IBM z-Series (разве это не повысит отказоустойчивость в случае выхода из строя одного ядра в многопроцессорной системе?)
Следующий вопрос может и достаточно специфичен для HPC, и относится больше к FPGA, однако в какой-то части это продолжение Turbo Boost: планируете ли вы создание процессоров с определенным числом логических(в смысле-виртуальных) специализированных блоков на shared физических вентилях, чтобы можно было при необходимости «отключать» ненужные в данный момент логические блоки, «отбирая» у них ресурсы под текущую задачу (надеюсь не слишком запутанно объяснил).
Что касается вообще высокопроизводительных вычислений, какие основные стратегии развития у Intel: увеличение скорости/улучшение архитектуры кристаллов или основной упор всё же на распараллеливание? Планируется ли поддержка навигации параллельных потоков на аппаратном уровне для большого числа ядер (а-ля HyperThreading), как, если я не ошибаюсь, сейчас сделано в IBM z-Series (разве это не повысит отказоустойчивость в случае выхода из строя одного ядра в многопроцессорной системе?)
Следующий вопрос может и достаточно специфичен для HPC, и относится больше к FPGA, однако в какой-то части это продолжение Turbo Boost: планируете ли вы создание процессоров с определенным числом логических(в смысле-виртуальных) специализированных блоков на shared физических вентилях, чтобы можно было при необходимости «отключать» ненужные в данный момент логические блоки, «отбирая» у них ресурсы под текущую задачу (надеюсь не слишком запутанно объяснил).
Давайте попробую ответить на вопросы по одному...
Интел обычно открыт к идеям и даже целенаправленно их ищет, идеи по оптимизации каких-либо классов вычислительных проблем в процессорах или ПО. По-моему, вычислительные задачи для построения искусственного интеллекта достаточно широки, и на сегодняшний день не консолидированы настолько чтобы строить под них специализированное аппаратное обеспечение. Другими словами, научные исследования идут полным ходом, и если сейчас начать делать спец. поддержку в железе, то к тому моменту, когда это железо будет отгружаться (эдак лет через 4-5), то наука, либо альтернативные вычислительные методы, могут уже уйти значительно дальше.
Есть, и именно это одна из тем исследований в рамках Tera-scale Computing Research Program. Опубликованные результаты касаются чипов с количеством ядер до 100 (в чипе Polaris их было 80, в Rock Creek — 48), и в июне в Гамбурге мы анонсировали, что сопроцессор Knights Corner будет содержать более 50 ядер на чипе. И мы конечно же думаем как объединять вместе тысячи таких процессоров, что вместе даст десятки тысяч ядер. Вопрос в интеграции десятков тысяч ядер на один кристалл пока не стоит, построение суперкомпьютерных систем с сотнями тысяч ядер — дело достаточно близкого будущего. Те кто уже сейчас думают как построить ExaFLOP (ожидают в 2018-2019 годах) суперкомпьютере говорят о сотнях тысяч ядер и миллионах программных потоках.
Большой вопрос и будет наверное большой ответ…
Если коротко, то мы стараемся предлагать сбалансированные решения… не бывает одного единственного правильного подхода для решения всех задач. А именно: некоторым задачам необходимо быстрое вычислительное ядро. Ядро может быть «быстрым» либо из-за низкого времени обработки инструкций = высокой частоты (и для этого у нас есть Турбо), либо за счет большей пропускной способности каждого ядра (больше инструкций за такт, либо обработки большего количества данных каждой инструкции как в MMX/SSE/AVX).
Итого — производительность каждого ядра будет расти, и не только из-за частоты!
Далее, есть задачи, которые хорошо параллелятся, и для них более эффективно сделать процессор с большим количеством ядер. В этом контексте очень важным был анонс семейства Many Integrated Core (MIC) архитектуры на Международной Суперкомпьютерной Конференции в Гамбурге в июне этого года. Здесь мы говорим о со-процессорах, в которые были вложены идеи и наработки Ларрфби, Поляриса и Рок-Крика, для применения в потоковых вычислениях.
В конце-концов, есть пользователи которыми производительность не на первом месте! А боле важным является время работы нетбука от батарейки: для этого мы сделали семейство Атом.
В настоящий момент конкретных планов по созданию процессоров с функционалом FPGA/ПЛИС нет. Причина во многом в технической сложности интеграции ПЛИС логики, с оптимизированным ядром на одном кристалле (хотя есть реализации интеграции ПЛИС с процессорами в одном сервере с помощью внешних системных шин).
С точки зрения перераспределения ресурсов, то Вы правы, что технология Турбо по сути позволяет перераспределять такой важный ресурс как энергопакет (как я писал выше -он ограничен) от неактивных ядер — к активным, что позволяет поднять частоту активных ядер, если какие-то ядра или даже блоки в одном ядре не используются (и как правило выключаются с помощью Power Gates).
По поводу увеличения степени параллельности вычислений, есть ли у Intel какие либо идеи по поддержке на аппаратном уровне возможностей, которые могли были бы быть использованы в сфере искусственного интеллекта?
Интел обычно открыт к идеям и даже целенаправленно их ищет, идеи по оптимизации каких-либо классов вычислительных проблем в процессорах или ПО. По-моему, вычислительные задачи для построения искусственного интеллекта достаточно широки, и на сегодняшний день не консолидированы настолько чтобы строить под них специализированное аппаратное обеспечение. Другими словами, научные исследования идут полным ходом, и если сейчас начать делать спец. поддержку в железе, то к тому моменту, когда это железо будет отгружаться (эдак лет через 4-5), то наука, либо альтернативные вычислительные методы, могут уже уйти значительно дальше.
Есть ли у Intel какие либо идеи в отношении высокоскоростных шин со сложной навигацией рассчитанной тысячи и десятки тысяч элементов(ядер)?
Есть, и именно это одна из тем исследований в рамках Tera-scale Computing Research Program. Опубликованные результаты касаются чипов с количеством ядер до 100 (в чипе Polaris их было 80, в Rock Creek — 48), и в июне в Гамбурге мы анонсировали, что сопроцессор Knights Corner будет содержать более 50 ядер на чипе. И мы конечно же думаем как объединять вместе тысячи таких процессоров, что вместе даст десятки тысяч ядер. Вопрос в интеграции десятков тысяч ядер на один кристалл пока не стоит, построение суперкомпьютерных систем с сотнями тысяч ядер — дело достаточно близкого будущего. Те кто уже сейчас думают как построить ExaFLOP (ожидают в 2018-2019 годах) суперкомпьютере говорят о сотнях тысяч ядер и миллионах программных потоках.
Что касается вообще высокопроизводительных вычислений, какие основные стратегии развития у Intel: увеличение скорости/улучшение архитектуры кристаллов или основной упор всё же на распараллеливание? Планируется ли поддержка навигации параллельных потоков на аппаратном уровне для большого числа ядер (а-ля HyperThreading), как, если я не ошибаюсь, сейчас сделано в IBM z-Series (разве это не повысит отказоустойчивость в случае выхода из строя одного ядра в многопроцессорной системе?)
Большой вопрос и будет наверное большой ответ…
Если коротко, то мы стараемся предлагать сбалансированные решения… не бывает одного единственного правильного подхода для решения всех задач. А именно: некоторым задачам необходимо быстрое вычислительное ядро. Ядро может быть «быстрым» либо из-за низкого времени обработки инструкций = высокой частоты (и для этого у нас есть Турбо), либо за счет большей пропускной способности каждого ядра (больше инструкций за такт, либо обработки большего количества данных каждой инструкции как в MMX/SSE/AVX).
- С частотой цикла все понятно: в массовом сегменте около 2.5-3ГГц с добавлением за счет турбо. Ограничение в термопотреблении — мы очень внимательно усвоили уроки последних поколений NetBurst, и теперь все процессоры ограничены 60-80-95-130 ваттными термальными пакетами.
- С обработкой большего количества инструкций за такт (или суперскалярность) все идет неплохо: мы добавляем новые вычислительные устройства в каждом поколении, причем это не только устройства для вычислительных инструкций, но и для load/store, shuffle, и пр. С точки зрения истории в Мероме было добавлено второе устройство для чисел с плавающей запятой, и это дало 2-х кратное преимущество перед NetBurst. В будующем стоит ждать продолжения развития ядер по этому пути.
- Обработка SIMD была добавлена уже давно… еще в Pentium c MMX. Потом получила развитие в шести поколениях SSE (1,2,3,S-3,4.1,4.2). И будет в дальнейшем развиваться в виде расширений AVX уже в следующем году.
- Также, мы также добавляем инструкции для специализированных приложений. В частности в Нехалеме и Вестмере были добавлены инструкции для оптимизации работ со строками, а также набора инструкций для крипто-алгоритмов AES.
Итого — производительность каждого ядра будет расти, и не только из-за частоты!
Далее, есть задачи, которые хорошо параллелятся, и для них более эффективно сделать процессор с большим количеством ядер. В этом контексте очень важным был анонс семейства Many Integrated Core (MIC) архитектуры на Международной Суперкомпьютерной Конференции в Гамбурге в июне этого года. Здесь мы говорим о со-процессорах, в которые были вложены идеи и наработки Ларрфби, Поляриса и Рок-Крика, для применения в потоковых вычислениях.
В конце-концов, есть пользователи которыми производительность не на первом месте! А боле важным является время работы нетбука от батарейки: для этого мы сделали семейство Атом.
Следующий вопрос может и достаточно специфичен для HPC, и относится больше к FPGA, однако в какой-то части это продолжение Turbo Boost: планируете ли вы создание процессоров с определенным числом логических(в смысле-виртуальных) специализированных блоков на shared физических вентилях, чтобы можно было при необходимости «отключать» ненужные в данный момент логические блоки, «отбирая» у них ресурсы под текущую задачу (надеюсь не слишком запутанно объяснил).
В настоящий момент конкретных планов по созданию процессоров с функционалом FPGA/ПЛИС нет. Причина во многом в технической сложности интеграции ПЛИС логики, с оптимизированным ядром на одном кристалле (хотя есть реализации интеграции ПЛИС с процессорами в одном сервере с помощью внешних системных шин).
С точки зрения перераспределения ресурсов, то Вы правы, что технология Турбо по сути позволяет перераспределять такой важный ресурс как энергопакет (как я писал выше -он ограничен) от неактивных ядер — к активным, что позволяет поднять частоту активных ядер, если какие-то ядра или даже блоки в одном ядре не используются (и как правило выключаются с помощью Power Gates).
Спасибо, ещё один вопрос:
Рассматривает ли Intel перспективу построения «трехмерных»(многослойных) процессоров? Как я понимаю, кроме сложности в техпроцессе большим препятствием на пути у этой технологии стоит максимально допустимый термопакет, однако и потенциальные плюсы технологии тоже достаточно весомые, есть ли какие-либо наработки в этой области?
Рассматривает ли Intel перспективу построения «трехмерных»(многослойных) процессоров? Как я понимаю, кроме сложности в техпроцессе большим препятствием на пути у этой технологии стоит максимально допустимый термопакет, однако и потенциальные плюсы технологии тоже достаточно весомые, есть ли какие-либо наработки в этой области?
Да, Интел рассматривает такой подход, и есть наработки в этой области: можно поискать по теме through-silicon-via 3D stacking — более 500 статей на сайте intel.com.
Вкратце, проблема не только в создании таких устройств, и не только в термальном пакете всего процессора, но и как охлаждать такие микросхемы. Здесь можно почитать про технические проблемы в области трехмерного стэкинга.
Вкратце, проблема не только в создании таких устройств, и не только в термальном пакете всего процессора, но и как охлаждать такие микросхемы. Здесь можно почитать про технические проблемы в области трехмерного стэкинга.
Наукоемкие отрасли, требующие огромных вычислительных мощностей это хорошо. Но как Интел будет продвигать, да и вообще аргументировать необходимость современных многоядерных решений для домашних пользователей?
Мне кажется, нынешние разработчики ПО сами к этому вынудят :)
А как же 640 КБ, которых хватит всем? ))
К сожалению, большинство нынешних разработчиков ПО не хочет заморачиваться на оптимизации кода. Все упирается в линейную производительность железа. А когда раньше было 64кб памяти в спектрумах — там и проявлялся интеллект, выдумка и изобретательность наряду с оптимизацией. Даже сейчас есть большая проблема написания «нормально оптимизированных» приложений под 2 ядра, а куда уж говорить про большее количество…
Ну и раз уж тут проводится конкурс вопросов, задам и своих пару:
— как решается проблема поиска программистов для многопроцессорных систем?
— как эти программисты участвуют в процессе разработки многоядерных систем?
— как разработчики многоядерных систем участвуют в отборе/подготовке программистов?
— как решается проблема поиска программистов для многопроцессорных систем?
— как эти программисты участвуют в процессе разработки многоядерных систем?
— как разработчики многоядерных систем участвуют в отборе/подготовке программистов?
— как решается проблема поиска программистов для многопроцессорных систем?
В Интел — традиционно: через хэдхантеров, через работу с университетами и наем выпускников, да и просто через знакомых :). По-моему (как менеджера в Интел, руководящего инженерами, в частности, занимающихся разработок ПО), быть программистом для многопроцессорных систем — не самое важное в кандидате. Важно как человек умеет осваивать новые навыки, уже в процессе работы. См. мой ответ на третий вопрос ниже.
— как эти программисты участвуют в процессе разработки многоядерных систем?
В Интел: самым непосредственным образом. Программные инженеры участвуют во всей цепочке создания платформы: от процесса планирования продуктов, моделирования логики, до тестирования и валидации результатов на реальных приложениях, сравнивая их с модельными ожиданиями.
— как разработчики многоядерных систем участвуют в отборе/подготовке программистов?
Сложно полностью ответить на этот вопрос, так как общих правил здесь я не знаю. И наверное просто нет, да они и не нужны. Важно понимать, что в нашей отрасли, люди в ней работающие создают многие методы и инструменты впервые (хотя с опорой на очень многолетний накопленный опыт). Так что важно не только что человек умеет, а как он может и готов учиться в процессе работы, решать ранее никем не решенные проблемы, систематизировать знания и методы уже созданные кем-то другим, передавать знания коллегам. Этим навыки (что называется «учиться учиться») обычно оттачиваются в институтах. И человек который их освоил, по-моему, нигде не пропадет и сможет получить ту работу, которую сам хочет (ну, например, разрабатывать многоядерные процессоры :))
Для оптимизации кода нужно в первую очередь оптимизировать сами компилляторы. Или же писать на ассемблере.
Под спектрумы основная масса программ как раз на ассемблере и писалась, и поскольку они были относительно небольшие — 64Кб — потому они относительно легко и поддавались оптимизации.
А теперь представьте какое-нить более-менее современное ПО, написанное на ассемблере? Ну да, про MenuetOS я в курсе ;)
Там, где даже сейчас над кодом работают сотни и тысячи программистов — если все это писать на ассемблере и оптимизировать — то команда вырастет еще раз так в 1000. Проект просто никогда не окупится.
Так что такой подход годится для всяких военных, космических кораблей, и пр. — там, где не особо считают деньги. А в коммерческом секторе — увы и ах.
Под спектрумы основная масса программ как раз на ассемблере и писалась, и поскольку они были относительно небольшие — 64Кб — потому они относительно легко и поддавались оптимизации.
А теперь представьте какое-нить более-менее современное ПО, написанное на ассемблере? Ну да, про MenuetOS я в курсе ;)
Там, где даже сейчас над кодом работают сотни и тысячи программистов — если все это писать на ассемблере и оптимизировать — то команда вырастет еще раз так в 1000. Проект просто никогда не окупится.
Так что такой подход годится для всяких военных, космических кораблей, и пр. — там, где не особо считают деньги. А в коммерческом секторе — увы и ах.
Небольшое пояснение:
Каковы объемы рынков HPC и настольных компьютеров? Мне кажется что настольные решения занимают доминирующую часть, а следовательно только HPC рынка мало для успешного бизнеса многоядерных решений которые так активно сейчас рекламируются. Мэйнстриму (настольным решениям да и вообще обычным пользователям для которых компьютер должен просто работать, печатать тексты, смотреть видео, и работать с интернет) вряд ли нужны современные вычислительные возможности многоядерных решений. Какова политика Интел в этом сегменте рынка?
Каковы объемы рынков HPC и настольных компьютеров? Мне кажется что настольные решения занимают доминирующую часть, а следовательно только HPC рынка мало для успешного бизнеса многоядерных решений которые так активно сейчас рекламируются. Мэйнстриму (настольным решениям да и вообще обычным пользователям для которых компьютер должен просто работать, печатать тексты, смотреть видео, и работать с интернет) вряд ли нужны современные вычислительные возможности многоядерных решений. Какова политика Интел в этом сегменте рынка?
Как аргументировать простого человека что ему нужен современный компьютер последней модели а не самый обыкновенный из доступных?
А как сейчас маркетологи впаривают?
Я тоже подумал что это больше дело маркетологов. А вообще мне лично сейчас уже 4х ядер иногда мало.
Частоты или ядер?
Производительности
Ну к вашим услугам топовые камни на 1336, не? 8 потоков, 3+ ггц, трехканальная память.
Ты хотел сказать 6 ядер и 12 потоков, но ошибся )
>А вообще мне лично сейчас уже 4х ядер иногда мало.
Да, мне тоже мало. Но не стоит забывать что люди на Хабре на порядок более подкованы в IT и потребности у них значительно выше чем у подавляющего большинства пользователей.
Да, мне тоже мало. Но не стоит забывать что люди на Хабре на порядок более подкованы в IT и потребности у них значительно выше чем у подавляющего большинства пользователей.
Я не маркетолог, и сразу не отвечу насколько велики рынки настольных компьютеров и НРС. Но сразу соглашусь, что настольные+мобильные компьютеры занимают подавляющее большинство рынка. Однако для нас размер рынка не единственный критерий создания каких-либо продуктов и технологий. НРС, прежде всего, область где создаются передовые технологии (как аппаратные так и программные), некоторые из которых, в дальнейшем, попадают в клиентский сегмент и владение этими технологиями является залогом успеха в массовом сегменте.
Для примера: некоторые технологии из области НРС прошлого, которые нашли применение в клиентских устройствах сегодняшнего дня.
список можно продолжать очень долго…
Для примера: некоторые технологии из области НРС прошлого, которые нашли применение в клиентских устройствах сегодняшнего дня.
- — Векторные процессоры были «изобретены» в мире НРС, и сейчас технологии векторизации, типа Intel Wireless MMX используются в мобильных телефонах
- — Многопроцессорные системы далеко не новость в мире НРС, и сейчас многие персональные компьютеры являются многопроцессорными
- — Многое их того, что сейчас называется модно «облачные вычисления», было основано НРС людьми в виде Грид технологий
список можно продолжать очень долго…
Производительность отдельных ядер расти (почти) не будет — гонка мегагерц кончилась бесповоротно.
Так что для роста производительности остается только параллельность (и оптимизация кода, конечно, только это дорого).
Так что для роста производительности остается только параллельность (и оптимизация кода, конечно, только это дорого).
Как я написал в предыдущем посте — производительность процессоров будет расти не только за счет увеличения количества ядер. Причина — на нее указали в посте ниже: не все приложения одинаково параллельны, потому-что не все разработчики хотят переделывать преложения для использования более одного или нескольких ядер :). Есть разные классы задач, и для разного класса задач есть разные процессоры и системы.
Что может быть интересно домашним пользователям в следующем поколении процессоров Sandy Beidge с набором инструкций AVX? Ну например, значительное увеличение (2х раза в пике) вычислений с плавающей запятой за такт каждого ядра, что очень сильно поможет различного рода мультимедийным приложениям, кодекам, и пр.
Что может быть интересно домашним пользователям в следующем поколении процессоров Sandy Beidge с набором инструкций AVX? Ну например, значительное увеличение (2х раза в пике) вычислений с плавающей запятой за такт каждого ядра, что очень сильно поможет различного рода мультимедийным приложениям, кодекам, и пр.
Добавлю свои пять копеек. Действительно, аргументация необходимости многоядерных решений для «домашних» пользователей — вопрос достаточно нетривиальный. Наверное, справедливо будет сказать, что впервые индустрия (не только Интел) столкнулась с этим вопросом в период появления первых моделей двухъядерных моделей процессоров. Даже если не ограничиваться рамками архитектуры x86 — например, вспомнить про Cell — этот продукт нашёл успешное применение в одной известной игровой приставке.
Я клоню к тому, что новые возможности порождают новые возможности. Интел, в свою очередь, поощряет «изобретателей» новых сценариев использования самыми разными способами. Это может быть и упоминание в публичной презентации кого-нибудь из руководящего состава Интел, это и помощь в оптимизации и развитии идей на базе использования многоядерных процессоров — см. пример выше про RFD, хотя это, пожалуй, не для домашнего использования :). Другими словами, хоть это до определённой степени будет маркетинговая точка зрения — ключ к спросу на многоядерные решения в большой степени спрятан за новыми сценариями использования.
Какими могут быть эти сценарии? Наверняка, вы сами сможете привести примеры. Навскидку, вспомните такие пакеты, как Google Earth, системы редактирования фото- и видеоматериалов, современные «тяжёлые» игры, возможности IP-телефонии с несколькими абонентами и видеозвонки в Skype, видео высокой чёткости и BluRay — все эти сценарии использования получили дополнительный толчок развития именно с использованием многоядерности. User experience качественно меняется, а для «домашних» пользователей это немаловажно.
Я клоню к тому, что новые возможности порождают новые возможности. Интел, в свою очередь, поощряет «изобретателей» новых сценариев использования самыми разными способами. Это может быть и упоминание в публичной презентации кого-нибудь из руководящего состава Интел, это и помощь в оптимизации и развитии идей на базе использования многоядерных процессоров — см. пример выше про RFD, хотя это, пожалуй, не для домашнего использования :). Другими словами, хоть это до определённой степени будет маркетинговая точка зрения — ключ к спросу на многоядерные решения в большой степени спрятан за новыми сценариями использования.
Какими могут быть эти сценарии? Наверняка, вы сами сможете привести примеры. Навскидку, вспомните такие пакеты, как Google Earth, системы редактирования фото- и видеоматериалов, современные «тяжёлые» игры, возможности IP-телефонии с несколькими абонентами и видеозвонки в Skype, видео высокой чёткости и BluRay — все эти сценарии использования получили дополнительный толчок развития именно с использованием многоядерности. User experience качественно меняется, а для «домашних» пользователей это немаловажно.
Интел активно развивает Библиотеки, компиляторы и прочие инструменты для многопоточного программирования, но все они предназначены для работы на одном, пусть и многопроцессорном, компьютере а не на кластере. Я имею ввиду продвижение таких технологий как OpenMP. Будет ли Интел развивать/разрабатывать библиотеки именно для использования в кластерах (например MPI или подобное).
Разработчикам часто приходится смешивать эти технологии, но это порой не всегда удобно. Интел имеет в планах разработку неких унифицированных решений, сочетающих в себе обе части «баррикад»?
Разработчикам часто приходится смешивать эти технологии, но это порой не всегда удобно. Интел имеет в планах разработку неких унифицированных решений, сочетающих в себе обе части «баррикад»?
Cluster OpenMP есть же.
Ну и у Intel, конечно же, есть своя реализация MPI.
Ну и у Intel, конечно же, есть своя реализация MPI.
> Будет ли Интел развивать/разрабатывать библиотеки именно для использования в кластерах (например MPI или подобное).
Дык у них уже давно поставляется mpi-реализация в составе intel cluster toolkit, основанная на mpich.
Дык у них уже давно поставляется mpi-реализация в составе intel cluster toolkit, основанная на mpich.
У нас есть целый набор инструментов для разработчиков кластерных продуктов входящих в состав Intel Cluster Toolkit. Среди них:
Среди всего набора библиотек в Cluster MKL (Math Kernel Library) входит реализация библиотеки распределенных алгоритмовScaLAPACK.
Также, важное место занимает программа Intel Cluster Ready, которая на направлена на обеспечение переносимости приложений в бинарной форме между сертифицированными кластерными конфигурациями — это важно для независимых разработчиков коммерческого ПО для НРС. Как неотъемлемая часть этой программы мы предоставляем инструмент, который называется Intel Cluster Checker, которые кроме сертификации, очень полезен системным администраторам для анализа технического состояния кластера.
- — Библиотека Intel MPI. Как и было сказано, по интерфейсу совместимая с MPICH2, но имеющая уникальную реализацию коммуникационной части (в частности могут использоваться DAPL провайдеры, доступные для большого количества интерконнектов)
- — Набор инструментов для сбора статистики и анализа эффективности работы MPI приложений: Intel Trace Collector & Analizer
- — коллекция тестов производительности Intel MPI Benchmarks (она идет с открытым кодом)
Среди всего набора библиотек в Cluster MKL (Math Kernel Library) входит реализация библиотеки распределенных алгоритмовScaLAPACK.
Также, важное место занимает программа Intel Cluster Ready, которая на направлена на обеспечение переносимости приложений в бинарной форме между сертифицированными кластерными конфигурациями — это важно для независимых разработчиков коммерческого ПО для НРС. Как неотъемлемая часть этой программы мы предоставляем инструмент, который называется Intel Cluster Checker, которые кроме сертификации, очень полезен системным администраторам для анализа технического состояния кластера.
В свете развития многоядерных решений, каковы планы Интел когда ядер будет не один десяток? Это будут полноценные, все одинаковые, х86 совместимые ядра?(средний вариант) Или это будет множество простых, пусть даже RISC ядер, но из-за большого числа которых в целом будет достигаться высокая производительность(как мне кажется, самый простой с точки зрения реализации сценарий)? Или это будут гетерогенные структуры с множеством различных специализированных и универсальных ядер одновременно(самый сложный в реализации, но довольно перспективный)?
Думаю как раньше перешли от первых процессоров к суперскалярной архитектуре, так и сейчас произойдёт что-то похожее, только уже на уровне ядер.
Все эти варианты рассматриваются как жизнеспособные. У каждого есть достоинства и недостатки, и в итоге будет не одна архитектура для всего, а несколько архитектур, нацеленных на разные задачи. Есть несколько моментов, которым мы будет стараться придерживаться:
- — будет обеспечиваться поддержка обратной совместимости приложений: т.е. старые приложения будут работать на новых процессорах не хуже чем на старых без перекомпиляции
- — новая функциональность (новые наборы инструкций, архитектуры системы, и пр.) будет давать больший прирост производительности или функционала, чем эволюционное наращивание частоты или количества ядер. Однако, скорее всего, для эффективного использования нового функционала потребуется переделывать приложения: от перекомпиляции до переписывания отдельных частей.
- — любой новый функционал будет обеспечиваться полным набором инструментов для разработчиков ПО… мы никого не будем заставлять писать на ассемблере :)
Вопрос о изобретении велосипеда.
Казалось бы 30 лет программе, штат разработчиков, а тут молодая команда с свежими решениями.
Браво!
Казалось бы 30 лет программе, штат разработчиков, а тут молодая команда с свежими решениями.
Браво!
А еще у меня не по теме вопрос — где можно взять таких чужого и хищника как на первом фото? :)
Сделать. Алиен походу хэндмэйд.
В Москве на Охотном ряду торгуют подобными. Только они раз в 5 больше.
Надеюсь, коллеги выше не ошиблись.
Хищник был подарком моего друга и коллеги г-на Рогачкова. Алексей, как вы знаете, увлечён другой кинотематикой, но обо мне не забыл.
Хищник был приобретён предположительно в одном из городов Северной Америки. Чужого мне удалось найти в сувенирной лавке в Амстердаме, если не ошибаюсь — по середине улицы Damrak. Чужой сделан действительно вручную, из гаек, винтиков, гвоздей, свечей накаливания и обрывков велосипедных цепей… где-то в Тайланде. Как вы понимаете, когда ЭТИ ДВОЕ встретились, была серьёзная заварушка. :)
Хищник был подарком моего друга и коллеги г-на Рогачкова. Алексей, как вы знаете, увлечён другой кинотематикой, но обо мне не забыл.
Хищник был приобретён предположительно в одном из городов Северной Америки. Чужого мне удалось найти в сувенирной лавке в Амстердаме, если не ошибаюсь — по середине улицы Damrak. Чужой сделан действительно вручную, из гаек, винтиков, гвоздей, свечей накаливания и обрывков велосипедных цепей… где-то в Тайланде. Как вы понимаете, когда ЭТИ ДВОЕ встретились, была серьёзная заварушка. :)
> Создание сеток, как правило, не параллелится на кластер из нескольких узлов.
Это откуда такие фантастические выводы были сделаны, интересно? :)
Это откуда такие фантастические выводы были сделаны, интересно? :)
> Соответственно если в процессе этой работы сервер отказывает — вылетает диск, вылетает модуль памяти, просто что-то происходит, то всю работу приходится начинать сначала.
Почему нельзя просто использовать контрольные точки с сохранением, например, на NFS-раздел?
Почему нельзя просто использовать контрольные точки с сохранением, например, на NFS-раздел?
> Почему нельзя просто использовать контрольные точки с сохранением, например, на NFS-раздел?
Потому что сброс 1ТБ данных на диск сильно затормозит работу?
Потому что сброс 1ТБ данных на диск сильно затормозит работу?
Нет. Я не предлагаю сбрасывать дамп всей памяти в незажатом виде по одному медленному NFS-каналу. Почти всегда можно компактнее описать точку восстановления, по которой возможно воссоздать текущее состояние, затратив на это, скажем, не больше нескольких часов. Хотя, тут многое зависит от задачи, но вообще не упоминать контрольные точки — это не верно.
Я думаю не секрет, что те суперкомпьюетры, которые были 40 лет назад намного отстают от производительности от сегодняшних настрольных решений. Так вот у меня вопрос в этом направлении.
Суперкомпьютеры — это здоров, и располагать такими вот вычислительными мощностями — это просто огромный пропрыв как для прикладной так и для научной деятельности. Но для большинства людей (ученых и инженеров я имею ввиду, так как домохозяйкам например это не нужно) не доступны эти технологии и инструменты. Есть ли проекты по «сближению с реальным миром» многоядерных систем.
Есть ли апаратные «эмуляторы». Например небольшой эмулятор суперкомпьюетера, который имеет 64 третих пентиума и имеет размер двух системных блоков, чтоб вести прототипизирование проектов?
Ведет ли Intel работы по оптимизации ядра Linux для таких мощных многоядерный систем? или какая ОС рекомендуется Intel для малобюджетных проектов или исследовательских проектов на многопроцессорных архитектурах? Если ведется, то есть ли этот код в мейнстриме ядра (если честно, то не видел).
Есть ли в Вашем опыте примеры применения суперкомпьютеров для решения каких-нибудь совсем неординарных задачь? Интересно было бы узнать о таких.
Какая страна «самая продвинутая» в применении таких технологий?
Суперкомпьютеры — это здоров, и располагать такими вот вычислительными мощностями — это просто огромный пропрыв как для прикладной так и для научной деятельности. Но для большинства людей (ученых и инженеров я имею ввиду, так как домохозяйкам например это не нужно) не доступны эти технологии и инструменты. Есть ли проекты по «сближению с реальным миром» многоядерных систем.
Есть ли апаратные «эмуляторы». Например небольшой эмулятор суперкомпьюетера, который имеет 64 третих пентиума и имеет размер двух системных блоков, чтоб вести прототипизирование проектов?
Ведет ли Intel работы по оптимизации ядра Linux для таких мощных многоядерный систем? или какая ОС рекомендуется Intel для малобюджетных проектов или исследовательских проектов на многопроцессорных архитектурах? Если ведется, то есть ли этот код в мейнстриме ядра (если честно, то не видел).
Есть ли в Вашем опыте примеры применения суперкомпьютеров для решения каких-нибудь совсем неординарных задачь? Интересно было бы узнать о таких.
Какая страна «самая продвинутая» в применении таких технологий?
Ведет ли Intel работы по оптимизации ядра Linux для таких мощных многоядерный систем? или какая ОС рекомендуется Intel для малобюджетных проектов или исследовательских проектов на многопроцессорных архитектурах? Если ведется, то есть ли этот код в мейнстриме ядра (если честно, то не видел).
ru.wikipedia.org/wiki/Beowulf_(%D0%BA%D0%BB%D0%B0%D1%81%D1%82%D0%B5%D1%80)
ru.wikipedia.org/wiki/OpenMosix
Хоть на коленке из старых Р3. Была даже попытка флешмоба, когда пытались на ноутах войти в Тор-500
Ведет ли Intel работы по оптимизации ядра Linux для таких мощных многоядерный систем?О да! Intel в 2009 году был «вкладчиком» №2 в код ядра после RedHat. Почти 7% изменений кода были сделаны Intel для оптимизации под многоядерность и новые функциональные возможности процессоров.
Но для большинства людей (ученых и инженеров я имею ввиду, так как домохозяйкам например это не нужно) не доступны эти технологии и инструменты. Есть ли проекты по «сближению с реальным миром» многоядерных систем.
Такие проекты есть, и в доступности высокопроизводительных инструментов и состоит основной смысл разработки этих инструментов (в частности работ в направлении уменьшения стоимости и увеличения доступности суперкомпьютеров. Надо сразу оговориться: суперкомпьютеры не предназначены для индивидуального потребления — по определению. Если компьютер делается доступным индивидуального разработчика, инженера, или домохозяйки, то он, скорее, будет назван «персональным компьютером». Суперкомпьютеры создаются коллективно многими людьми и организациями для решения задач, которые не могут быть решены персональными компьютерами в разумное время. Так что по-определению, суперкомпьютер есть ресурс коллективного пользования.
Разные организации (индивидуальные коммерческие компании, институты, межведомственные центры) или даже страны (как часть государственной политики) формируют различные условия использования суперкомпьютерными ресурсами.
В России, кроме коммерческих компаний, использующих суперкомпьютеры исключительно для своих собственных нужд, есть несколько академических центров, в которых можно получить доступ к вычислительным ресурсам для счета. Старейший их них это Межведомственный Суперкомпьютерный Центр РАН , и есть также центры в МГУ, в Сибирском отделении РАН в Новосибирске, в Южно-Уральском Государсвенном Университете, и многих других центрах. Доступ к ним возможен, если у Вас есть реально важная задача для расчетов.
С точки зрения разработчика ПО, то здесь реализуется вся сила стандартной архитектуры! Так как процессоры и программное ПО (будь то Linux или Windows) одинаковы с точки зрения интерфейсов разработчика на одном дэсктопу и на кластере: а именно, разрабатывать MPI приложение, и даже отлаживать его можно на обычном дэсктопе, а для серьезных расчетов его очень просто перенести на суперкомпьютер… почти также легко как скопировать файлы и перекомпилировать (компиляторы, в принципе тоже одинаковые!) — не надо решать проблемы с кросс-компиляцией для суперкомпьютера, отладкой на удаленной системе, перенос данных между big <> little endian форматами, и пр.
Есть ли апаратные «эмуляторы». Например небольшой эмулятор суперкомпьюетера, который имеет 64 третих пентиума и имеет размер двух системных блоков, чтоб вести прототипизирование проектов?
И такое есть. Я бы не стан называть их эмуляторами — этот сегмент называется deskside personal supercomputers. Вот пример от компании КРЭЙ, SGI, и российской компании Т-Платформы.
Ведет ли Intel работы по оптимизации ядра Linux для таких мощных многоядерный систем? или какая ОС рекомендуется Intel для малобюджетных проектов или исследовательских проектов на многопроцессорных архитекторах? Если ведется, то есть ли этот код в мейнстриме ядра (если честно, то не видел).
Да, ведется и Интел является одним из ведущих компаний поддерживающих разработку ПО с открытым кодом, и инвестирует в разработку ядра Линукс. Далеко не полный список проектов нашего Центра по поддержке разработки ПО с открытым кодом доступно на нашем сайте. Там также есть список экспертов, и рекомендую почитать про проекты Энди Клина, который в частности специализируется на поддержке МСА в ядре Линукса для в процессоров 7500 серии.
Есть ли в Вашем опыте примеры применения суперкомпьютеров для решения каких-нибудь совсем неординарных задачь? Интересно было бы узнать о таких.
Таких проектов много, и думаю все будет зависеть от индивидуальных оценок каждого, что есть более интересно. Вот пример того как будет выглядеть покупки одежды в будущем, который понравился моей супруге (к слову она работает в области связанной с модной) :). Но это не только фантастика (хотя в таком виде еще не работающая), но предмет реальных разработок. В частности, в Южно-Уральском Государственном университете разрабатывается задача с емким названием «Деформационные изменения структуры трикотажных полотен на различных участках фигуры человека» (можно посмотреть на слайде 13 в этой презентации… и там, кстати, другие примеры использования суперкомпьютеров небезынтересные). Эта задача посвящена моделированию трикотажных изделий и тела человека с учетом физико-механических свойств трикотажных изделий. С использованием суперкомпьютерных вычислений построены виртуальные модели торса женской фигуры и платья, исследованы свойства трикотажных полотен, проверены возможности масштабируемости данной задачи. , и она получила специальную премию «За использование суперкомпьютерных вычислений в новых отраслях» от компании «РСК СКИФ» на конкурсе «СУПЕРГРИД: Суперкомпьютерные и Грид-технологии в индустрии и экономике».
Какая страна «самая продвинутая» в применении таких технологий?
В данном примере, я думаю, ответ очевиден!
огромнейшее спасибо за исчерпывающие ответы
«Так что по-определению, суперкомпьютер есть ресурс коллективного пользования.»
Вот тут есть небольшое уточнение. Сегодня очень многие технологии «смывают границы», как пример: мобильные и настольные технологии уже настолько сблизились, что в очень скором будущем это будет одна платформа, например MeeGo — «первая ласточка».
Я вот к чему, не считаете ли Вы, что суперкомпьютеры тоже могут сближаться с персональными. Как пример можно рассмотреть www.onlive.com/, или Google OS. Когда самого PC уже нет, а есть только терминалы для доступа к «виртальному PC». Я думаю для решения таких задач нужны просто гигантские мощности и каналы. Насколько по Вашему такое применение суперкомпьютеров приоритетно и актуально?
«Так что по-определению, суперкомпьютер есть ресурс коллективного пользования.»
Вот тут есть небольшое уточнение. Сегодня очень многие технологии «смывают границы», как пример: мобильные и настольные технологии уже настолько сблизились, что в очень скором будущем это будет одна платформа, например MeeGo — «первая ласточка».
Я вот к чему, не считаете ли Вы, что суперкомпьютеры тоже могут сближаться с персональными. Как пример можно рассмотреть www.onlive.com/, или Google OS. Когда самого PC уже нет, а есть только терминалы для доступа к «виртальному PC». Я думаю для решения таких задач нужны просто гигантские мощности и каналы. Насколько по Вашему такое применение суперкомпьютеров приоритетно и актуально?
Опасаясь начать диалектический спор о сути вычислений, я все-таки приведу высказывание одного моего знакомого из Микрософта, суть которого можно описать почти буддийской репликой: нет ничего нового в современных моделях вычислений: мир развивается по спирали, и все «новые» технологии — это хорошо забытые старые, просто на некотором новом этапе развития.
Далее, поясню что я имею ввиду под спиралью развития (и прошу прощения за упрощенный вариант истории развития компьютерной отрасли… эта тема достойна отдельной книги):
Вначале компьютеры были настолько дороги, что их было всего несколько штук на весь мир. Томас Ватсон, будучи главой уже тогда могущественной компании IBM в 1943 году сказал (хотя споры об авторстве еще продолжаются), что всего весь мировой рынок «наверное составляет 5 таких компьютеров» (I think there is a world market for maybe five computers). Тогда, на этих компьютерах считались уникальные задачи, и количество людей, способных с ними работать можно было пересчитать по пальцам. Количество государств имевших компьютеры… можно говорить в единственном числе. Это были своего рода «персональные компьютеры», так как их было мало, да и людей с ними работавших было не намного больше.
С развитием индустрии, стало появляться больше пользователей (хотя писали в основном на машинном языке), и в итоге появились мэйнфреймы — системы, с разделяемым доступом, на которых могли работать много пользователей одновременно (для исторической справедливости надо отметить, что первая система управления очередью задач появилась где-то до мэйнфреймов, и вначале была, скорее всего, на бумаге). Главное, что появилось — это высокоуровневые языки программирования (COBOL, etc), что открыло доступ к компьютерам большего количества людей. Протоколы доступа с терминалов были достаточно просты: что нужно кроме простого терминала с поддержкой текстовых строк на монохромном дисплее?С ростом рынка (и как следствие удешевлением компонент), и развитием технологий (прежде всмего степени интеграции транзисторов на интегральных схемах) появились мини-компьютеры — прежде всего о VAX от DEC, которые все-равно были размером с холодильник! Но протоколы усложнялись и стали зарождаться идеи клиент-серверных моделей вычислений и усложнение/универсализация коммуникационных протоколов. Начавшееся развитие персональных компьютеров поддержало развитие этих идей, так как появилось большее разнообразие «клиентов». Однако, РС по большей части были действительно персональными (хотя далеко не каждая семья могла позволить себе такой персональный компьютер). Они никак не были соединены друг с другом и мы использовали кассеты для переноса данных с одного компьютера на другой. В какой-то степени можно сказать, что вернулась эра когда когда компьютер стал «персональным»… в отличие от терминала, он был самодостаточным: не требовал подключения к «мэйнфрейму»/серверу для работы.
Со временем стандартизировались протоколы (такие как Ethernet, TCP/IP и пр.), и персональные компьютеры стали объединяться в сети. Появился Интернет и затем еще более высокоуровневые протоколы типа HTTP, SIP, etc. Пользователи захотели чтобы их персональные компьютеры стали легче, и их можно было носить с собой, и не заряжать батарейку хотя бы один день. Утвердился новый вид терминала: браузер! Он, конечно был уже не такой простой как терминалы «мэйнфреймов», но по модели работы — очень похоже. Только вместо мэйнфрейма — большое облако (будь то Яндекс, или Гугл, или Хабра). Например, я сейчас сижу перед «терминалом» под названием Firefox подсоединенному к «мэнфрейму» на Хабре, при помощи стэка очень сложных протоколов и пишу этот текст… который Вы читаете с другого «терминала», поддерживающего протокол HTML 4.1. Так что «терминалы», будь то на базе MeeGo, или другой платформы будут «утончаться» (потому, что этого хотят пользователи), а нагрузка на «mainframe» будет только расти: будет требоваться решать больше задач в бэк-энде, на серверной ферме, в центре обработки данных. Многие из этих задач будут требовать решения в реальном режиме времени. Например, представим такую модификацию типичной НРС задачи как рендеринг фильма класса АВАТАР… точнее пофантазируем, что Вы можете «заказать» сюжет фильма, а компания, которая их «рисует индивидуально на заказ» в режиме реального времени будет «рендерить» это фильм для Вас… и возможно изменять сюжет по вашему желанию, и возможно с Вашим в нем участием, или просто чтобы продать Вам что-нибудь: реклама, точно, будет всегда!
Можно ли это назвать сближением персонального компьютера и высокопроизводительного дата-центра? Я думаю, персональная часть будет всегда сосуществовать с централизованной обработкой данный. Во-первых: контент проще создавать и потреблять на «персональном» устройстве. Во-вторых, экономически скорее всего будет консолидировать обработку в одном месте. В третьих: любое предсказание ошибочно так как не учитывает неизвестных факторов (то ли еще будет изобретено!): например, скорость развития «peer-to-peer computing» может внести свои коррективы. Если бы 3 миллиарда компьютеров которые уже есть в мире могли быть объединены быстрой сетью и эффективно можно было-бы искать контент без необходимости использования центральной базы типа Гугла, Яндекса, и общаться с друзьями без посредничества Твиттера и Одноклассников, то возможно все компьютеры опять стали бы персональными! Возможно звучит как утопия, так как таких сетей не существует… пока: не стоит ожидать что этого не будет никогда.
Далее, поясню что я имею ввиду под спиралью развития (и прошу прощения за упрощенный вариант истории развития компьютерной отрасли… эта тема достойна отдельной книги):
Вначале компьютеры были настолько дороги, что их было всего несколько штук на весь мир. Томас Ватсон, будучи главой уже тогда могущественной компании IBM в 1943 году сказал (хотя споры об авторстве еще продолжаются), что всего весь мировой рынок «наверное составляет 5 таких компьютеров» (I think there is a world market for maybe five computers). Тогда, на этих компьютерах считались уникальные задачи, и количество людей, способных с ними работать можно было пересчитать по пальцам. Количество государств имевших компьютеры… можно говорить в единственном числе. Это были своего рода «персональные компьютеры», так как их было мало, да и людей с ними работавших было не намного больше.
С развитием индустрии, стало появляться больше пользователей (хотя писали в основном на машинном языке), и в итоге появились мэйнфреймы — системы, с разделяемым доступом, на которых могли работать много пользователей одновременно (для исторической справедливости надо отметить, что первая система управления очередью задач появилась где-то до мэйнфреймов, и вначале была, скорее всего, на бумаге). Главное, что появилось — это высокоуровневые языки программирования (COBOL, etc), что открыло доступ к компьютерам большего количества людей. Протоколы доступа с терминалов были достаточно просты: что нужно кроме простого терминала с поддержкой текстовых строк на монохромном дисплее?С ростом рынка (и как следствие удешевлением компонент), и развитием технологий (прежде всмего степени интеграции транзисторов на интегральных схемах) появились мини-компьютеры — прежде всего о VAX от DEC, которые все-равно были размером с холодильник! Но протоколы усложнялись и стали зарождаться идеи клиент-серверных моделей вычислений и усложнение/универсализация коммуникационных протоколов. Начавшееся развитие персональных компьютеров поддержало развитие этих идей, так как появилось большее разнообразие «клиентов». Однако, РС по большей части были действительно персональными (хотя далеко не каждая семья могла позволить себе такой персональный компьютер). Они никак не были соединены друг с другом и мы использовали кассеты для переноса данных с одного компьютера на другой. В какой-то степени можно сказать, что вернулась эра когда когда компьютер стал «персональным»… в отличие от терминала, он был самодостаточным: не требовал подключения к «мэйнфрейму»/серверу для работы.
Со временем стандартизировались протоколы (такие как Ethernet, TCP/IP и пр.), и персональные компьютеры стали объединяться в сети. Появился Интернет и затем еще более высокоуровневые протоколы типа HTTP, SIP, etc. Пользователи захотели чтобы их персональные компьютеры стали легче, и их можно было носить с собой, и не заряжать батарейку хотя бы один день. Утвердился новый вид терминала: браузер! Он, конечно был уже не такой простой как терминалы «мэйнфреймов», но по модели работы — очень похоже. Только вместо мэйнфрейма — большое облако (будь то Яндекс, или Гугл, или Хабра). Например, я сейчас сижу перед «терминалом» под названием Firefox подсоединенному к «мэнфрейму» на Хабре, при помощи стэка очень сложных протоколов и пишу этот текст… который Вы читаете с другого «терминала», поддерживающего протокол HTML 4.1. Так что «терминалы», будь то на базе MeeGo, или другой платформы будут «утончаться» (потому, что этого хотят пользователи), а нагрузка на «mainframe» будет только расти: будет требоваться решать больше задач в бэк-энде, на серверной ферме, в центре обработки данных. Многие из этих задач будут требовать решения в реальном режиме времени. Например, представим такую модификацию типичной НРС задачи как рендеринг фильма класса АВАТАР… точнее пофантазируем, что Вы можете «заказать» сюжет фильма, а компания, которая их «рисует индивидуально на заказ» в режиме реального времени будет «рендерить» это фильм для Вас… и возможно изменять сюжет по вашему желанию, и возможно с Вашим в нем участием, или просто чтобы продать Вам что-нибудь: реклама, точно, будет всегда!
Можно ли это назвать сближением персонального компьютера и высокопроизводительного дата-центра? Я думаю, персональная часть будет всегда сосуществовать с централизованной обработкой данный. Во-первых: контент проще создавать и потреблять на «персональном» устройстве. Во-вторых, экономически скорее всего будет консолидировать обработку в одном месте. В третьих: любое предсказание ошибочно так как не учитывает неизвестных факторов (то ли еще будет изобретено!): например, скорость развития «peer-to-peer computing» может внести свои коррективы. Если бы 3 миллиарда компьютеров которые уже есть в мире могли быть объединены быстрой сетью и эффективно можно было-бы искать контент без необходимости использования центральной базы типа Гугла, Яндекса, и общаться с друзьями без посредничества Твиттера и Одноклассников, то возможно все компьютеры опять стали бы персональными! Возможно звучит как утопия, так как таких сетей не существует… пока: не стоит ожидать что этого не будет никогда.
Boomburum, повторяй за мной:
Fugue Icons icons are licensed under a Creative Commons Attribution 3.0 license.
If you can’t or don’t want to provide attribution, please purchase a royalty-free license.
Fugue Icons icons are licensed under a Creative Commons Attribution 3.0 license.
If you can’t or don’t want to provide attribution, please purchase a royalty-free license.
Искренне буду рад узнать, что напрасно цитировал эти две строчки.
Дождемся официального комментария? :)
Дождемся официального комментария? :)
Сделал ссылку на автора иконок, надеюсь вам полегчало
Если мои комментарии показались резкими, то сообщаю: они такими не были. Даже смайл поставил.
Кстати, наверно, разумным будет не выкладывать иконки на «Народ», как сейчас, а линковать прямо с сайта автора: p.yusukekamiyamane.com/icons/search/fugue/icons/user-green.png.
Кстати, наверно, разумным будет не выкладывать иконки на «Народ», как сейчас, а линковать прямо с сайта автора: p.yusukekamiyamane.com/icons/search/fugue/icons/user-green.png.
Мне одному кажется, что Василий слегка похож на старину Билли? Этакий русифицированый вариант )
Еще один вопрос, надеюсь что не поздно. Закон Мура… Число транзисторов на единицу площади… Это все здорово и отлично, процессоры становятся многоядерными, объемы памяти растут… Казалось бы все отлично, но… Хоть объемы памяти и растут, но время доступа к ней, латентность улучшается значительно более медленными темпами чем по закону Мура. Сейчас, память становится узким местом высокопроизводительных систем. Как на данном этапе решается этот вопрос? Интел ведет новые разработки в области памяти и если да, то какие?
Спасибо
Спасибо
Да, это действительно серьезная проблема. Но дополнительные транзисторы на кристалле, достающиеся с каждом переходом тех-процесса, можно использовать не только для увеличения пропускной способности логики (т.е. делать больше операций за такт), но и для увеличения параметров кэш памяти на кристалле: в частности увеличивать объем кэша и и пропускную способность. Согласен, что не для всех приложений кэш помогает, но все-же иногда помогает, особенно если есть возможность оптимизировать приложения для использования локальной кэш памяти процессора.
В дальнейшем, я считаю, что должна быть серьезно пересмотрена архитектура подсистемы памяти. Разновидности стандартов DDR2, DDR3, ожидаемый в будущем DDR4, а также, используемую в графических ускорителях GDDR5, имеют фундаментальные недостатки. Однако, полностью перейти на новые архитектуры памяти в ближайшие несколько лет не представляется возможным, так как замена еще не готова… так что после DDR3 будет DDR4. А потом — посмотрим.
В дальнейшем, я считаю, что должна быть серьезно пересмотрена архитектура подсистемы памяти. Разновидности стандартов DDR2, DDR3, ожидаемый в будущем DDR4, а также, используемую в графических ускорителях GDDR5, имеют фундаментальные недостатки. Однако, полностью перейти на новые архитектуры памяти в ближайшие несколько лет не представляется возможным, так как замена еще не готова… так что после DDR3 будет DDR4. А потом — посмотрим.
Sign up to leave a comment.
Проблемы суперкомпьютера в средней полосе