Calxeda объявила о сотрудничестве с Canonical и другими Open Source-компаниями
3
Иллюстрация с сайта Calxeda.Com
Американский стартап Calxeda, ранее известный как Smooth-Stone, объявил о запуске партнерской программы, в рамках которой стало известно о сотрудничестве с такими компаниями, как Canonical, Couchbase, Eucalyptus Systems и Opscode.
Компания Calxeda была основана в 2008 году благодаря инвестициям ARM. Она задается целью производства компьютеров с чипами на базе разработок ARM для дата-центров с пониженным энергопотреблением. Позавчера, 14 июня, была анонсирована партнерская программа Trailblazer и представлены её первые 10 участников. Судя по этому списку, в Calxeda делают ставку на решения с открытым исходным кодом.
Так, среди первых партнеров Calxeda можно увидеть хорошо знакомые в Open Source-мире имена компаний:
- Canonical, стоящая за популярным Linux-дистрибутивом Ubuntu;
- Couchbase, объединившая в феврале этого года двух производителей популярных NoSQL-БД: CouchOne (CouchDB) и Membase;
- Eucalyptus Systems, специализирующаяся на облачных вычислениях и возглавляемая экс-главой MySQL AB Мартеном Микосом (Marten Mikos);
- Opscode, известная благодаря Open Source-средству управления конфигурациями Chef.
Представители Calxeda сообщают, что их система-на-чипе (SoC) вмещает 480 ядер от ARM (120 узлов по 4 ядра) в 2-юнитовом (2U) форм-факторе. При этом среднее энергопотребление составляет около 5 ватт на 1 узел (с 4 ядрами), т. е. общее потребление системы — около 600 ватт. Для сравнения, системы на базе архитектуры x86 со схожей производительностью потребляют около 4000 ватт.
Запущенная партнерская программа, объединившая ряд Open Source-компаний, говорит о явном намерении Calxeda создавать центры обработки данных, управляемые программным обеспечением с открытым кодом.
Постоянная ссылка к новости: http://www.nixp.ru/news/11244.html. Дмитрий Шурупов по материалам eweek.com.
Canonical присоединилась к консультативному совету проекта GNOME
The Register: В Canonical проходят сокращения, оптимизирующие компанию для новых инвесторов
4
Canonical предложила пользователям Ubuntu Linux коммерческую поддержку Docker
Canonical помогает Cloudbase с поддержкой Windows Hyper-V в облаках OpenStack
Canonical сотрудничает с Acer, GE, DataArt и Microsoft для развития интернета вещей с Ubuntu Snappy
HP покупает пионера облачных вычислений с открытым исходным кодом — Eucalyptus 3 2
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Greenpeace одобряет :)
Интересно, насколько такая железка будет выйгрышна по cash перед привычным x86?
Насколько не скажу, но думаю будет. В новостях где-то проскакивало, что яндекс собирал себе дата-центр на армах. Вряд ли он делал это в качестве реверанса гринпису. ;)
ARM, грубо говоря, ровесница x86.
Да, она намного энергооэффективная x86, но и производительность совсем не та.
Картина та же: старая технология в новой обгортке. Не взирая на это — она найдет свое место на рынке. Например, я бы заменил свой i3 с 2х86 и TDP 35W на… 52хARM с тем же TDP 35W :)
Я давным-давно хочу десктоп на арме. Мне нафиг не нужна производительность современного x86. Поставил я как-то boinc, и теперь чуть ли не 100% аптайма потребляется им. А вот arm… Если мой существующий десктоп (одноядерник на AM2+) держится на батарейке UPS’а полтора часа, то сколько бы продержался бы десктоп на arm’е?
Да и, если честно, мне уже надоело раз в полгода разбирать блок питания, чтобы помыть вентиляторы — без этого системник гудит как сволочь. А с arm’ом, можно будет вообще выкинуть эти вентиляторы.
ps. А где можно почитать сравнение производительности ARM и x86? Мои скудные сведения об ARM (сводящиеся к статье на en.wikipedia.org) не позволяют мне прикинуть «на глаз», кто будет быстрее: с одной стороны RISC, с другой процессор весь оплетённый конвеерами и микрокодом, с системой команд, которая из-за обратной совместимости давным-давно достигла высшей степени захламлённости. Такой мощности захламлённость я встречал лишь в коде BIOS’а платформы x86.
Ну RISC очень сильно проигрывает при операциях с float-ами и специальными операциями с длинными целыми (ну там типа MMX и пр). В этой области RISC еще не скоро догонят CISC.
«типа MMX» — вероятно имеются в виду SIMD операции, то бишь векторные? Но встаёт вопрос: насколько десктопу нужны float’ы и векторные инструкции? Мне кажется, что они нужны исключительно для декодирования видео. Ну да, ещё игроманство. Во всех остальных местах, где они применяются, они применяются настолько эпизодически, что можно игнорировать их влияние на производительность. Но это всё умозрительные выводы. Хочется знать поточнее.
Почему-же. А MMX/SSE-optimized memcpy? Рендеринг и антиалиасинг фонтов? Декодер всяких там flac ogg mp3 и пр? Ту-же pdf-ку отрендерить. Или svg и пр. Для десктопа выгодней выглядит мини Via-системы с впаянным процом: www.viagallery.com/index.php?option=com_flickr4j&Task=tags&Tag=Mini-ITX
MMX/SSE memcpy не использует MMX и SSE. ;)
Он использует 128-битные команды пересылки данных в и из регистров mmx/sse. Про arm я не знаю, но ведь там могут быть просто специальные команды, предназначенные для реализации быстрого memcpy. Скажем, x86 отказался в определённый момент от оптимизации строковых инструкций movs/lods/stos, и сегодня они присутствуют в системе команд x86 только для обратной совместимости. А если бы не отказался и продолжал оптимизировать, то все оптимизированные memcpy на x86 не использовали бы sse, а сводились бы к rep movs.
А может в ARM есть настолько злой DMA контроллер, что его можно из user-space использовать, и копировать память мегабайтами не нагружая процессор вовсе? Я не знаю платформы ARM, и я могу лишь гадать о том, насколько быстрым там может быть memcpy.
Рендер шрифтов — это 2d-графика. В которой использование четырёх-компонентных векторов больше похоже на оверхед. Да и вообще, этим должен заниматься акселератор на видеокарте, то есть GPU. И, наконец, сколько шрифтов используется одновременно на десктопе? Их можно отрендерить превентивно, на все нужные размеры с необходимым dpi, выполнить все вычисления одноразово, и потом отрисовывать без вычислений. Я не знаю, делается это или нет на десктопе. И это моё незнание привносит 3 дополнительных кубометра тумана неточности в мои умозрительные выводы.
Кстати, вот есть скажем связка библиотек pango/cairo для отрисовки графики. Вы уверены, что эта связка использует mmx или sse? Я, почему-то, сомневаюсь в этом и, как следствие, подозреваю, что все gtk+2 приложения отрисовывают шрифты не используя векторых инструкций процессора. То есть, быть может, gcc где-нибудь и догадался использовать sse команды, при компиляции pango/cairo, но я не думаю, что gcc настолько силён, чтобы это существенно повлияло бы на такой задаче.
Насчёт декодеров — да, тут я согласен. Но даже если на arm из-за этого, существенно страдает производительность десктопа, то на мой взгляд это не критично. Такое декодирование идёт в один-два потока максимум (ну не будет же пользователь слушать сразу три mp3-трека). А значит в случае проблем с производительностью, можно компенсировать отсутствие SSE добавив к процессору пару десятков мегагерц.
Не, ну зачем вы доказываете мне, что arm медленее? Я готов согласиться с этим, без каких-либо споров. Мне интересна оценка того, насколько он медленнее, на разных задачах. Сегодня двухгигагерцовый процессор — это норма. Но нафига десктопу два гигагерца? Тормоза десктопа, как правило вылезают из тормознутости жёсткого диска, из-за тормознутости оперативной памяти, из-за тормознутости ethernet… Бывает, что не хватает процессора, но в нормальной ситуации — это редкость.
> о есть, быть может, gcc где-нибудь и догадался использовать sse команды, при компиляции pango/cairo, но я не думаю, что gcc настолько силён
Ну, во-первых, таки силен. Во-вторых, начиная с 7.2 X.org (могу ошибаться, где-то 2-3 года назад) рендеринг фонтов перенесли вообще на сторону клиента со стороны Х-сервера. Соответственно, не совсем получится возложить эту операцию на видео-карту (которой владеет Х-сервер и пользовательским процессам как-бы зясь обращаться к аппаратуре)
> Не, ну зачем вы доказываете мне, что arm медленее? Я готов согласиться с этим, без каких-либо споров. Мне интересна оценка того, насколько он медленнее, на разных задачах. Сегодня двухгигагерцовый процессор — это норма. Но нафига десктопу два гигагерца? Тормоза десктопа, как правило вылезают из тормознутости жёсткого диска, из-за тормознутости оперативной памяти, из-за тормознутости ethernet… Бывает, что не хватает процессора, но в нормальной ситуации — это редкость.
Все это к тому, что для десктопа ARM — не совсем правильный выбор. Современный тех-процесс позволяет впихнуть пару блоков для работы с float и мультимедиа практически не увеличив при этом потребление энергии. А так получается мы всеми силами избавляемся от «ненужного» веса, а потом весь этот вес эмулируем программно… Сейчас доступны вполне адекватные решения low-perf процессоров типа С3-7, Atom и пр. А гигагерцы гонят по вполне понятной причине — продать подороже.
Итог всего словесного поноса — пакетики маршрутизировать и php + mysql стандартный гонять — это вполне. Для десктопа получается что мы героически создаем себе трудности и потом героически их преодолеваем.
PS.
Хотя для ARM-ов есть со-процессоры VFP (плавучка+моушен).
Рендеринг шрифтов переехал на сторону клиента давным-давно. Что gtk, что qt, по-моему, всегда отрисовывали шрифты самостоятельно. Всё остальное касается исключительно нативных X-клиентов, которые пользуются возможностями Xorg для отрисовки шрифтов.
Но это не значит, что рендеринг шрифтов не ускоряется видеокартой. Скажем рендеринг вращающихся шестерёнок Xorg вообще не умеет производить, но и тем не менее, glxgears умудряется сваливать основную работу на видеокарту.
Ну, всё не настолько плачевно. Да, arm тянется за максимальной простотой архитектуры процессора. Но есть ведь Cortex, на борту которого, есть не просто FPU, но и SIMD. Но даже если их и нет, то ведь x86 тоже эмулирует, пускай и аппаратно, но он эмулирует CISC процессор, хотя сердце его (согласно откровениям Intel) уже давно RISC. Декодер инструкций, декодирует каждую инструкцию в микрооперации, которые затем выполняются ядром процессора. Transmeta на этой идее даже процессор с полностью настраиваемой системой команд создала. Так что эмуляция может быть не столь и плачевна, если речь про энергопотребление.
Может быть, может быть… Но у меня нету в этом твёрдой уверенности. Скажем гляжу я на NVidia Tegra и тону в сомнениях. Вообще, конечно же, Tegra позиционируется как SoC для смартфонов, но какая же няшка, судя по описаниям. С таким чипом, по-моему, системник не нужен, просто подключить монитор, клавиатуру и жёсткий диск, и на этом успокоиться.
ps. А вообще, поскольку из конструктива лишь слова неподкреплённые цифрами, я предлагаю закругляться, в качестве жирной точки в обсуждении, предлагаю пожертвовать по 100$ на создание OpenRISC: opencores.org/donation
Долой x86 и ARM! Даёшь опенсурц процессор в массы! =)