LINUX.ORG.RU
ФорумTalks

[arm][попил] Smooth-Stone получил 48 лямов на разработку серверных ARM

 


0

0

http://www.smooth-stone.com/smooth-stone-48m-funding/

Забавно. Я думал, серверную тему будут только года через два поднимать.

Хотя все равно непонятно, что эти кексы планируют на тему адресации больше 4 гигов и быстрых шин. Конкретики нет, только маркетинговый булшит. Однако деньги выделены.

★★★★★
Ответ на: комментарий от Yareg

Фик знает. Если начать устраивать такую же херню, как у интела, то выигрыша не будет.

А в то что совсем новую оптимизированную архитектуру можно слепить и запустить в производство за 1-2 года - верится с трудом.

Vit ★★★★★
() автор топика
Ответ на: комментарий от anon_666

Лично я вижу только один - ARM «пилят», а MIPS - нет. Соответственно, ARM сейчас повсеместно, а MIPS - нет.

Deleted
()
Ответ на: комментарий от Vit

> А в то что совсем новую оптимизированную архитектуру можно слепить и запустить в производство за 1-2 года - верится с трудом.

зачем-же новую. конвеерные вычисления - заточат ARM под конвеерную еденицу, получится почти NvidiaTesla на ARM`ах :) Процессоры маленькие и холодные, то есть на один чип их можно вхреначить тьму. И чипов на плату штук сорок. Учитывая что ограничений и лишних сущностей от граф.ядер не будет изначально, да и писать для arm`ов люди умеют - могут получаться нехреновенькие суперкомпьютеры для числодробилок.

или новая реинкарнация транспьютеров - дешёвая сеть из независимых ядер - тоже очень даже нихреновая вещь и ниша на рынке для такого есть.

то есть баблосы им не просто так дали. Не только ради отката :)

MKuznetsov ★★★★★
()
Ответ на: комментарий от shoewreck

Очевидно же, что этого недостаточно.

Deleted
()
Ответ на: комментарий от MKuznetsov

> зачем-же новую. конвеерные вычисления

По ссылке написано про датацентры.

В серваках 4 гигабайта - спорный вопрос. Напиливать 64 гига на виртуалки гораздо удобнее, чем иметь 16 жестких кусков и пытаться в них утрамбовать.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Reset

Можно сделать костыль по типу PAE, логическое адресное пространство не расширится, но можно вместе с указателем хранить дополнительный номер и просить ОС перемапить область памяти... Но не нужно.

Yareg ★★★
()
Ответ на: комментарий от Yareg

только хотел сказать про PAE. но кто знает, может у них там реально есть что-то на тему ARM64?

leg0las ★★★★★
()
Ответ на: комментарий от Vit

>А в то что совсем новую оптимизированную архитектуру можно слепить и запустить в производство за 1-2 года - верится с трудом.

MIPS64 давно уже «слеплен». и производство запущен. Осталось адаптировать к серверам и запустить в массовое производство. Но это никому не интересно - слишком предсказуемо, бабла особо не отмоешь в мутной воде

Led ★★★☆☆
()
Ответ на: комментарий от anon_666

>У арма свои плюсы.

Ага. Как у Шевроле:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

> Осталось адаптировать к серверам и запустить в массовое производство.

кхм ...

Вот есть такая конторка:
http://www.caviumnetworks.com/OCTEON_MIPS64.html
лепят себе сдуру 1...32 ядреные MIPS64 , не читают абсолютно лор,
паразиты ...
Да, вот еще одни «не читавшие лор» выпускают себе на OCTEON сервера:

http://www.movidis.com/products/nap.html

Мало того, они имеют наглость это делать с 2006 года и предустанавливая Debian на сервера:

http://www.itjungle.com/breaking/bn081406-story03.html



elipse ★★★
()
Ответ на: комментарий от elipse

> Мало того, они имеют наглость это делать с 2006 года и предустанавливая Debian на сервера:

Мало того, у них железо так и осталось на уровне 2006 года :)

Не, кроме шуток, старовато все-таки, несмотря на большое количество ядер. На CN68xx нема серваков, цена непонятна, где покупать - тоже.

Vit ★★★★★
() автор топика
Ответ на: комментарий от grim

>Есть серверные фермы на атомах. 32 бита и прочее Г.

Вообще-то это только атомы для недобуков - 32-битные. Десктопные атомы - 64-битные

Led ★★★☆☆
()
Ответ на: комментарий от elipse

> Вот есть такая конторка

Ок, насчёт «адаптировать к серверам» - не совсем прав - частично адаптировано. Вот только не дочитал как там с периферией: infiniband, SATA, SAS, IPMI, etc.

Жаль, что таких «конторок» и объёмы их производства исчезающе мало

Led ★★★☆☆
()
Ответ на: комментарий от Vit

>старовато все-таки, несмотря на большое количество ядер.

Ну, 1,5ГГц для 32-ядерника - это не так уж и плохо

Led ★★★☆☆
()
Ответ на: комментарий от Led

А теперь смотрите конкретные серверы. Там старые процессоры, 16 ядер на 600 мегагерц. Получается примерно как современный 4-ядерник, плюс-минус лапоть. Ничего особенного, плюс экзотика и не купить.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Yareg

Без расширения виртуального адресного пространства толку никакого не будет.

Reset ★★★★★
()
Ответ на: комментарий от Led

> частично адаптировано.
http://www.emediaworld.com/press_release/release_detail.php?id=880411

(April 14, 2010) -  Cavium Networks
Cavium Networks will be demonstrating the following OCTEON based secure, scalable, and content aware IP storage reference designs:

High-performance LINUX iSCSI to Disk (SAS & SATA): Multi-function, fully configurable storage SoC for Cloud Computing that provides 10Gbps line rate performance executing iSCSI, RAID, Security and Compression on a single OCTEON Plus processor.
SMB & Enterprise NAS designs: Scalable SMB to Enterprise NAS solutions
De-Duplication: Demonstration of high-performance block-level Data De-Duplication engine on OCTEON Plus
Deep Packet Inspection technology to enable «Content Aware IP Storage.»
--------------------
еще mips64 -ы клепают давно:
http://www.rmicorp.com/products/xls.htm
http://www.pmc-sierra.com/mips-processors/

http://www.toshiba.com/taec/Catalog/Line.do;jsessionid=FA31553DB0F086A9C401DE...

elipse ★★★
()
Ответ на: комментарий от Vit

>Мало того, у них железо так и осталось на уровне 2006 года :)

Ээээ, а кто там нам еще предлагает 16 ядер Mips64 флаконе на 30 watts с 2006 года ?

На CN68xx нема серваков, цена непонятна, где покупать


ну делай и покупай )):
http://www.phoenicselectronics.com/cavium.asp

elipse ★★★
()
Ответ на: комментарий от Vit

>Там старые процессоры, 16 ядер на 600 мегагерц.

еще касательно мегагерцев:
Intel XScale (ARM) , в свое время, смогли конкурировать с Тошибой mips64 400...450 мгц начиная с тактовых 600 ...650 мгц.
Для mips64 800 мегагерц, это как для сегодняшних армов ~ 1200 мгц.

elipse ★★★
()
Ответ на: комментарий от elipse

Ну давайте еще вспомним, кто в войну кровь проливал :) . У меня подход простой: я готов крутить сервак на мипсе, не вопрос. Ради фана. Если он будет сравнимой мощности и за сравнимые деньги.

Но фишка в том, что железку я купить не могу, и на колокейшен арендавать тоже не укого. Получается, что теоретически мипс крут, а практически фейл. Надеюсь, что с ARM такого не случится.

Vit ★★★★★
() автор топика
Ответ на: комментарий от MKuznetsov

>получаться нехреновенькие суперкомпьютеры для числодробилок.

С плавающей точкой в эмуле ? (:

sS ★★★★★
()
Ответ на: комментарий от elipse

> c чем сравнимые ?

С типовым 4-ядерным штеудом. Прайс на коло например такой:
http://www.hetzner.de/hosting/produktmatrix/rootserver-produktmatrix/

Почем бытовуха типа супермикр - не помню уже. Арендовать стало выгоднее.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

http://sicortex.com/products/deskside_development_system
The SC072-PDS is a 100 GFlops 72-processor deskside computer from the defunct SiCortex corporation.

пишут что:
The SiCortex SC072-PDS seems to be going for less than $2000 on ebay
these days.

http://groups.google.com/group/sicortex-users/browse_thread/thread/c5963e9464...

для настоящего красноглязия это сущие пустяки,
а штеуды идут лесом))

elipse ★★★
()
Ответ на: комментарий от Reset

>Ага, а теперь смотрим gflops'ы на intel'евских 4х ядерниках

ну в два раза меньше у штеуда, и?

Надо ли говорить, что на 4 ядра проще распараллелить чем на 72?


угу, на 6 ядер уже грыжа буить, а 12 - век воли невидать ))

elipse ★★★
()
Ответ на: комментарий от elipse

ну в два раза меньше у штеуда, и?

intel дешевле на порядок и выжать из него 45gflops будет существенно проще

Reset ★★★★★
()
Ответ на: комментарий от Reset

Ну я не понял.) Где логика, зин ?

Если, мне надо будет «дешевле» - то для этого есть amd.

Если ты продаешь сервисы , то почему ты не любишь старые горячие штеуды
«ведро за даром на базаре» ?))

elipse ★★★
()
Ответ на: комментарий от elipse

У тебя неадекватное сочетание цена/производительность. На intel'е мы запросто достигнем пика, используя mkl. А на твоем чуде из 72 процов? Сомневаюсь, что выжмем хотя бы 50%.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Канэшно нет, это еще и много благотворительности ))

elipse ★★★
()
Ответ на: комментарий от Reset

>да мне нахер твои сервисы не нужны, мне нужна числодробильня

распаралелленая на 4 ядра - это «числодробильня»? Спасибо посмешил:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

А распараллеливание на 72 ядра, которое далеко не факт, что будет быстрее чем на 4 уже числодробильня?

Reset ★★★★★
()
Ответ на: комментарий от Reset

>А распараллеливание на 72 ядра, которое далеко не факт, что будет быстрее чем на 4 уже числодробильня?

«Числодробильня» праллелится на десятки-сотни-тысячи узлов, в каждом из которых минимум 4 ядра (обчно больше)

Led ★★★☆☆
()
Ответ на: комментарий от Led

Это в идеальном случае. В реальном же случае, куски кода (даже небольшие), который не параллелится принципиально приводят к тому, что ускорение по сравнению с однопроцессной версией стремится к константе при увеличении числа процессов.

Reset ★★★★★
()
Ответ на: комментарий от elipse

> угу, на 6 ядер уже грыжа буить, а 12 - век воли невидать ))

Берем мощное ядро, где задача выполняется 0.01 секунды. Время отклика меленькое. Берем 100 дохлых ядер, которые выполняют 100 задач параллельно, по секунде на каждую. Производительность та же самая, а latency выросло в 100 раз.

На практических задачах типа вебсервера, имеем шансы получить жопу.

С программной точки зрения 1 толстую железку нарезать на части под задачи всегда выгоднее, чем распихивать задачи по куче мелких железкок.

Проблема в том, что на практике задачи дробятся (параллелятся) на части не до бесконечности, а только до какого-то предела.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

>На практических задачах типа вебсервера, имеем шансы получить жопу.

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

Проблема в том, что на практике задачи дробятся (параллелятся) на части не до бесконечности, а только до какого-то предела.

Ага, только 4, как сказал Reset:)

Led ★★★☆☆
()
Ответ на: комментарий от Reset

>В реальном же случае, куски кода (даже небольшие), который не параллелится принципиально приводят к тому, что ускорение по сравнению с однопроцессной версией стремится к константе при увеличении числа процессов.

Ты рассказываешь о каких-то неЗемных кластерных вычислениях. ты с какой планеты?:)

Led ★★★☆☆
()
Ответ на: комментарий от Reset

>ускорение по сравнению с однопроцессной версией стремится к константе при увеличении числа процессов.

за счёт чего? А, наверное, за счёт того, в однопроцессорной системе один кэш на все это множество процессов и все эти процессы «мирно, дружно, эффективно» его используют!:)

Led ★★★☆☆
()
Ответ на: комментарий от Led

На этот счет теорема есть и точный вид константы к которому будет стремится ускорение любой параллельной программы с небольшим куском непараллельного кода (а такой код есть в 99% случаев) известен точно. Поэтому подучи матчасть для начала и посчитай что-нибудь на кластере, а потом говори.

Reset ★★★★★
()
Ответ на: комментарий от Led

Кеш (и вообще иерархическая организация памяти) это другая история, которая тоже приводит к печальным последствиям. Из-за этих особенностей, в частности, очень плохо параллелятся blas level 1 и 2 у которых в теории всё отлично.

Reset ★★★★★
()
Ответ на: комментарий от Led

Не только на 4, но для предложенного случая обычный intel'евский 4х ядерник (или amd'шный если к intel'ю религиозная неприязнь) будет давать лучший результат чем система из 72х дохлых ядер.

Reset ★★★★★
()
Ответ на: комментарий от Reset

>Кеш (и вообще иерархическая организация памяти) это другая история

Кэш - это вынужденная практика, связанная с тем, что на кристал CPU много памяти или не поставишь, или это будет неоправданно дорого.

которая тоже приводит к печальным последствиям.

Реальная практика показывает, что использование кэша на кристале CPU (а в особенности индивидуальный кэш на каждое ядро) приводит к ЗНАЧИТЕЛЬНОМУ выиграшу в ПРАКТИЧЕСКОЙ производительности по сравнению с отсутствием кэша (наличие которого ты называешь проблемой)

Кроме теорем рекомендую посмотреть ещё и на практику:)

Led ★★★☆☆
()
Ответ на: комментарий от Reset

>Не только на 4, но для предложенного случая обычный intel'евский 4х ядерник (или amd'шный если к intel'ю религиозная неприязнь) будет давать лучший результат чем система из 72х дохлых ядер.

ДАЛЕКО не всегда.

Led ★★★☆☆
()
Ответ на: комментарий от Led

Проблема не кеш, а иерархическая организация памяти, под которую надо «задрачивать» программу, чтобы она быстро работала и параллелилась. Не во всех случаях это можно сделать. Курим, например, про производительность dgemm и dgemv и почему в mkl dgemv специально не стали параллелить.

Reset ★★★★★
()
Ответ на: комментарий от Led

Да, без кеша, конечно же, совсем жопа бы была при теперешней разнице в производительности памяти и проца.

Reset ★★★★★
()
Ответ на: комментарий от Led

Ага, если надо подбирать пароли, то 72 ядра будет лучше, только вот это очень уж специфическая задача :)

Reset ★★★★★
()
Ответ на: комментарий от Reset

Тебе никто не рассказывал, что на N процессоров можно запустить N «непараллеллящихся» задач - разных или одинаковых, но с разными исходными данными? Или ты будешь доказывать, что запускать их на одном процессоре (по очереди или скопом) эфективнее?

Led ★★★☆☆
()
Ответ на: комментарий от Led

> неудачный пример. На практике вебсервера обслуживают каждый запрос отдельным трэдом или процессом.

Пример вполне удачный. Вы тему не вкурили. На 100 дохлых ядрах средняя задержка отклика будет выше, чем на 1 мощном. Даже при 100% загрузке. А когда загрузка не 100%, то выигрыш еще больше.

Вебсервер - вполне понятный пример, где увеличение задержки нежелательно. Числодробилка - пример, где пофик.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Led

> Или ты будешь доказывать, что запускать их на одном процессоре (по очереди или скопом) эфективнее?

Еще раз. Все зависит от критерия удачности. Если критерием удачности является время отклика - то да, на 1 процессоре (суммарной мощности) будет эффективнее.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

Ха ха, На 100 дохлых ядрах средняя задержка отклика будет выше, чем на 1 мощном.

Что есть дохлые ядра ?
И почему сразу допускаете невозможность построения схемы «один сайт - один СPU» на многоядерной такой конфигурации ?
Для систем реального времени «одна задача - один CPU» - это как идеал,
тут же, какие-то махинации с логикой в пользу штеуд.
i5 лучше чем i4
i6 лучше чем i5
i7 лучше чем i6
ога, любимые развлечения ...

Накладные расходы на коммутацию ресурсов уже отменили ?))


elipse ★★★
()
Ответ на: комментарий от elipse

>Ха ха, На 100 дохлых ядрах средняя задержка отклика будет выше, чем на 1 мощном.

И еще, призаданной пропускной способности исходящего канала,
как время отклика одно процессора «изнутри» связано с быстродействием всей системы «извне» ?
Неужели таки линейно ?))

elipse ★★★
()
Ответ на: комментарий от elipse

Мне очень интересно, как связана производительность в gflops'ах с производительностью сайтов? Неужели для веб-сервера уже floating point нужна?

Reset ★★★★★
()
Ответ на: комментарий от elipse

У вебсервера, если это не файлопомойка, ограничением по каналу часто можно пренебречь. Обычное дело при построении грубой оценки - какие-то факторы главные, какие-то побочные.

И почему сразу допускаете невозможность построения схемы «один сайт - один СPU» на многоядерной такой конфигурации ?


Если говорить о говнохостингах, когда на серваке тысяча страничек - проблем нет. Для числодробилок проблем тоже нет.

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

Vit ★★★★★
() автор топика
Ответ на: комментарий от elipse

А ты уверен, что время генерации html всегда << времени загрузки? Если сложная страница на intel'е генерится 0.1 секунду, то на одном дохлом ядре будет уже 10 секунд. Да пользователь не будет столько ждать, он подумает, что сайт сдох и закроет вкладку.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Конечно же не уверен, иначе бы не существовали такие вещи как буферизация, кеш страниц ,очередь отложенных запросов и пр.
Как раз именно тут вы считаете, что «тупая сила» CPU решает абсолютно все .

elipse ★★★
()
Ответ на: комментарий от Vit

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

Возможно.
Это надо уже смотреть конкретно.
Ресурсы системы можно убить разными способами))

elipse ★★★
()
Ответ на: комментарий от elipse

Па любасу, мипсы все просрали из-за фигового маркетинга. Заигрались в илитарность, когда штеуд с 486 перебивался.

Надеюсь, у ARM подобной лажи в маркетинге не случится. Хотя прямо сейчас у них процов серверного класса нет (в самом первом посте перечислил проблемы).

А когда ARM в серваки попрет, и люди привыкнут, что x86 не нужен, может и мипсу перепадет.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

>Па любасу, мипсы все просрали из-за фигового маркетинга.

нифига, вспомни лучше какой был горбатый gcc для 64 бит в 2006 году (и ранее)
и сколько проделано было работы для портирования софта под Amd64.

elipse ★★★
()
Ответ на: комментарий от elipse

Это к чему? Я ж писал выше. Простому пацану вроде меня мипс не купить. Пусть он хоть даром стоит. Негде (без гимора). И на хостингах не предлагают.

Это я и называю - просрали. Процы хорошие есть, а пользоваться не получается.

Vit ★★★★★
() автор топика
Ответ на: комментарий от Vit

>Простому пацану вроде меня мипс не купить.

ну, а я купил когда Штеуды были еще утюгами .

Негде (без гимора). И на хостингах не предлагают.


ну или ты смотриш на всех, или что-то делаешь свое.

Это я и называю - просрали.


Не знаю, у ms была винда для мипсов.
Конкуренции в лоб с Intel ранее не выдержал никто.

А призводители чипсетов не всегда вкладывают в софт
- одни физически это не могут, а другим это не надо.
Любая открытая архитектура cpu (спарки, мипсы,...) - бац и сразу «просрали».
А как только что-то закрытое (arm, x86 ...) - сразу какая-то возня, рекламный пудреж мозгов, развитие там и все такое .
Хотя по реальным TTX mips дает фору армам еще на пару лет.

Сомнительно, что arm пустят дальше переносных мыльниц.
Будет много трепа и все.


elipse ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.