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

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

Толку-то? Пул php-процессов я на таком крутить могу. Они памяти мало жрут. И запараллелить не проблема. Они памяти мало жрут.

А под mysql 8-16 гигов выделить - хрен. И параллелить не получится. Не умеет он. Ага.

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

А так, сейчас 20-30% конфигураций серверов для аренды содержат до 4Гб оперативы.

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

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

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

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

Клевый совет. Вообще-то разговор был о том, что на ARM больше 4 гигов не сделать.

А так, сейчас 20-30% конфигураций серверов для аренды содержат до 4Гб оперативы.

Это не так. Ссылка выше. Кривые хостинги рассматривать смысла нет.

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...

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

Ага, а теперь смотрим gflops'ы на intel'евских 4х ядерниках http://www.intel.com/support/processors/sb/cs-023143.htm

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

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

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

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

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

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

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

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

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

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

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

Нафига мне твои «пики», если ты продавать сервисы не умеешь ?))

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

Тут про сервера как бы речь шла , не ?

сервера это только сервисы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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