Pull to refresh

Comments 10

«Почему стоит использовать ускорители? Во-первых, не все задачи можно распараллелить: к примеру, биржевые системы работают в один поток. И в большинстве случаев биржевые системы достигли потолка производительности текущих аппаратных комплексов. GPU-ускорители могут дать им новый уровень скорости вычислений, превышающий в разы текущие показатели. Во-вторых, существенная часть повышения производительности серверов от поколения к поколению лежит на процессоре. А технологический процесс производства процессоров имеет свои ограничения: сейчас используется 14 нм, компания IBM анонсировала возможность использования 7 нм3. Что будет дальше? Очевидно, что предел наступит не завтра, но в обозримом будущем.»
Но если я что-то понимаю, то на GPU много ядер как раз и работают параллельно. И многие задачи как параллелят для GPU. Т.е. если задачу по каким то причинам не распараллелить, то гораздо лучше использовать CPU, т.к. у него частота больше, кэш, да еще и предсказатель переходов.
Да и техпроцесс у последних GPU вроде пока 22нм, а не 14, как у CPU.
Т.е. весь абзац в моих понятиях полностью противоположен.
Или тут какой то совсем уж скрытый замысел? Что-нить вроде «теперь каждое ядро CUDA будет простеньким процессором, мы нашли способ переносить гигантский поток информации по сети прямо в ядра, поэтому данные и команды будут поступать прямо из облака в память видеокарты и все меньше, чем за такт!»
С такими трендами как описанны выше уже недалеко до кибернауки, вернее киберинфраструктуры.

Каждые 2 года одно и то же.
(Парсер не подведи!)


Я вообще удивляюсь как IBM что-то еще продавать может. Уровень компетенций просто зашкаливающе низок… Данная статья — реально же стыдно в блоге компании такое писать.
Коллеги, вы что курили и где _это_ продают? :))

Статья шедевральна, право. Становится куда более понятно почему IBM так активно теряет рынок и массово увольняет сотрудников…



«Подход web-scale также делает необходимым глубокую оптимизацию кода под аппаратное обеспечение. Это означает отказ от любых технологий виртуализации, так как это вносит дополнительный слой взаимодействия (и, потенциально, задержки) с «железом». „


PCI passthrough я так понимаю вы в своем дремучем сне мимо пропустили?

Про задержки — вы лучше расскажите как вы на традиционной архитектуре обеспечите data locality (ответ: никак), чтобы задержки уменьшить?

“Гиперконвергентность не позволяет создать оптимальную инфраструктуру для каждой задачи в отдельности»


Да вы что? Вам руки связывают выбирать конкретную конфигурацию (скажем на Нутаникс есть боле 5000 тысяч (!) конфигураций оборудования доступных) под конкретные задачи?

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


Вот ведь как оно оказывается… Пентаногам да ФБР — все ОК, а IBM сказки рассказывает “про надежность».

Задуматься о том что единственная компания из крупных онлайнов, кто использует традиционный 3-tier подход, это Yahoo (банкрот, сидят на Netapp), а остальные (google, facebook, amazon, apple, ms azure и прочие) как раз на webscale… Нет, видимо не судьба.

Архитектуры построенные правильно по webscale принципам — практически неубиваемы, в отличии от традиционных подходов предлагаемых IBM в том числе.

5 миллионов или 5 тысяч конфигураций?

Описался, спасибо :)

5 тысяч.
Речь ни в коей мере не идет о том, что системы стоит строить только по принципу трехзвенной архитектуры и использовать только вертикально-масштабируемые системы. Другими словами, принцип «используйте только их» — неправильный. Конечно, они используются и будут использоваться, но все больше компаний выбирает горизонтально-масштабируемые системы, и количество таких компаний только растет. И идея создания OpenPower, посвящена именно этому — сделать scale-out системы с возможностью ускорения.
Далее, я принципиально разделяю гиперковергентные системы и web-scale IT. Первое — это заранее сконфигурированные блоки, которые обеспечивают должную отказоустойчивость и масштабируемость.
Второе — технологии и подходы, которыми первыми начали использовать именно web-компании, а именно упоминавшиеся Google и Facebook. Их инфраструктура строится на принципе создания кастомизированного железа с оптимизацией под прикладную задачу.

Про конфигурации:
ни в коей мере не буду спорить, что количество конфигураций велико. Вопрос в другом: одно дело вставлять процессоры разной частоты и поколений, другое — создать систему на 48+ ядер и объемом хранения, скажем, 40 Тб? Это вполне реальные показатели критичной системы крупной организации. Очевидно, что для решения этой задачи для процессоров необходимо разделить систему на части, а для хранения — добавить еще один модуль. Удобно ли это? не всегда. Особенно, если делить существующую систему на части. Именно поэтому я придерживаюсь точки зрения, что более эффективно переложить системы меньшего объема и загруженности на блоки инфраструктуры на базе гиперконвергентных систем.

Владимир Алексеев из IBM — я предлагаю провести публичный круглый стол.

Например между IBM и лидером мирового webscale рынка Nutanix (на котором IBM фактически вообще не представлена).

Ответственно заявляю, что ваша данная статья — это позор компании IBM, и в целом предлагаю пригласить на дискуссию адекватных специалистов (не маркетологов как вы).
UFO just landed and posted this here
Sign up to leave a comment.