Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 122
Интересна итоговая мощность
Думаю, не сравнится с 4к долларовым ПК )
Вообще странно всё это. Такое впечатление, что сделали ради лулзов. Больше всего поражает, что даже в пресс-релизе университета ни слова о производительности, лишь упоминание того, что первым тестом было вычисление числа пи.
Нет, ну что вы. Конечно же, это было сделано абсолютно серьёзно. Было задействовано множество ученых, инженеров и программистов.
Можно сказать, это наше будущее.
Можно сказать, это наше будущее.
Ваш сарказм не уместен.
В пресс-релизе говорится, что такая система вполне себе неплохое средство для обучения студентов высоко-производительным (читайте «распараллеленным») вычислениям.
А для того, чтобы прогнать несколько тестов, собрать результаты и отобразить их в сравнительной таблице, «множество ученых, инженеров и программистов» и ни к чему.
В пресс-релизе говорится, что такая система вполне себе неплохое средство для обучения студентов высоко-производительным (читайте «распараллеленным») вычислениям.
А для того, чтобы прогнать несколько тестов, собрать результаты и отобразить их в сравнительной таблице, «множество ученых, инженеров и программистов» и ни к чему.
А что им еще для тестов было на нем считать? Linpack гонять не вариант. Интерконнект между узлами всего 100 Мегабит. Памяти на каждом узле кот наплакал. То есть даже тест с нормальным размером матрицы не погоняешь, а если с мелкими запустишь, так интерконнект все результаты испортит. Вот и тестируют на вычислениях числа Pi :)
Т.е. 256МБ рамы — это уже кот наплакал?
У меня в университете был предмет, связанный с распараллеленными вычислениями. И на практических занятиях мы гоняли те же матрицы по 100mbps сети — никто не умер.
У меня в университете был предмет, связанный с распараллеленными вычислениями. И на практических занятиях мы гоняли те же матрицы по 100mbps сети — никто не умер.
Ага. Был у нас первый кластер на альфах 21164 (533 MHz). Памяти на каждой было как раз по 256Мб и 100 Mbit интерконнект. Году так в 99. По нынешним меркам у него ооочень чахлая производительность была. Его уже лет 5 как музейный экспонат только используют. Даже студентов учить уже слишком медленный он.
У нас такие на офисе. На них работают люди. Работают. Люди. Это не музей.
Смотря для каких задач. Для офиса — этого достаточно.
Смотря для каких задач. Для офиса — этого достаточно.
Бедный-бедный-бедный офис =(
А почему бы им не работать на таких машинах, если они справляются с поставленными задачами? У меня есть знакомые, которые и на 286-х работают. На этих машинках бегают программки для управления станком. Собственно зачем их менять, если все и так прекрасно работает.
У нас эти машины перестали справляться и были списаны.
У нас эти машины перестали справляться и были списаны.
К сожалению, да. Сегодня на настоящих HPC машинах минимальным является 1 Gb RAM на ядро, а чаще всего — 2 Gb. А про интерконнект вообще даже не стоит сравнивать — стоимость Infiniband доходит до половины стоимости всей системы и счёт идёт на микросекунды задержки.
А причём тут производительность? На такой системе студенты могут пробовать и обкатывать полноценные кластерные проекты. Настоящий кластер из 64 компов обошёлся бы на порядок-два дороже,
Дело в том, что для обучения можно наклепать виртуалок и получить близкую производительность на современной машине. Поэтому для обучения тоже не очень интересный вариант. Например, студенты некоторые задачки компилировать сдохнут на R-Pi.
Кросс-компиляцию вчера запретили?
Представил себе лабы по программированию для mpi. «А сейчас, господа, мы с вами будем учить что такое кросс-компиляция» :) Немного не по профилю предмета — это раз.
Каждый раз после исправления ошибки в коде таскать код с рабочей станции на кластер — это два.
Зачем изобретать трудности, а потом их преодолевать? :(
Каждый раз после исправления ошибки в коде таскать код с рабочей станции на кластер — это два.
Зачем изобретать трудности, а потом их преодолевать? :(
Во-первых, код таскать в любом случае придется, потому что в кластере-то 64 узла, и код должен быть на каждом из них.
А во-вторых, «таскание кода» прекрасно поддается автоматизации.
А во-вторых, «таскание кода» прекрасно поддается автоматизации.
Ну ок. Будем считать что убедили. Начинайте проводить лабы по mpi на R-Pi :)
Кластерные ФС уже не в моде, да.
Пожалуйста, читайте ветку с начала, а не с конца.
Я не утверждал, что «таскание» кода на все 64 узла — это сложная задача. Я утверждал, что эта задача не проще «таскания» кода с рабочей станции на сервер.
Кластерная ФС решает сразу обе задачи, за что ей честь и хвала.
Я не утверждал, что «таскание» кода на все 64 узла — это сложная задача. Я утверждал, что эта задача не проще «таскания» кода с рабочей станции на сервер.
Кластерная ФС решает сразу обе задачи, за что ей честь и хвала.
Проще. Кластерную ФС должен настроить администратор кластера. А за таскание кода и данных с рабочей станции на кластер отвечает каждый самостоятельно.
В любом случае, один раз настроить кросс-компиляцию проще, чем регулярно «сдыхать компилировать некоторые задачки на R-PI»
… а потом ещё настроит и эмулятор, потому что всё равно придётся бинарник копировать. Я считаю что если есть компьютер целевой платформы достаточной мощности для разработки, то лучше разрабатывать нативно.
Ась? А эмулятор-то зачем?!
1. Кросс-компиляция, копирование на девайс, запуск.
2. Копирование на девайс, компиляция, запуск.
3. Кросс-компиляция, запуск под эмулятором.
4. Компиляция, запуск. (Всё на девайсе.)
Выбирайте какой вариант проще. Я считаю что если уже возиться с кросс-компиляцией, то лучше вариант (3). А если запускать на девайсе, (а мы говорим о ресурсоёмких задачах), то можно и компилировать там же — вариант (2). Вариант (1) сочетает недостатки всех подходов.
2. Копирование на девайс, компиляция, запуск.
3. Кросс-компиляция, запуск под эмулятором.
4. Компиляция, запуск. (Всё на девайсе.)
Выбирайте какой вариант проще. Я считаю что если уже возиться с кросс-компиляцией, то лучше вариант (3). А если запускать на девайсе, (а мы говорим о ресурсоёмких задачах), то можно и компилировать там же — вариант (2). Вариант (1) сочетает недостатки всех подходов.
Вы вообще что-нибудь разрабатывали с использование кросс-компиляции? В этом нету ничего сложного. Более того, руками ничего копировать не надо. Все один раз настраивается (запустить специальный сервис на целевой и вбить адрес на инструменталке), далее из IDE запускается либо отладка, с подключение к удаленному отладчику, либо просто запуск. Исполняемые файлы заливаются сами. Так например это все происходит при разработки под QNX. При том, что там целевые машины могут быть вполне приличными, просто разработчики перестали делать IDE непосредственно под QNX, наверно она просто не пользовалась особой популярность.
Вот в только таких хорошо отлаженных случаях кросс-компиляция работает хорошо — когда этот юзкейс предусмотрен и оттестирован разработчиками тулчейна и IDE.
Целевая платформа все-таки ARM, тут все же наверно в большинстве своем и так используется кросс-компиляция. Основная проблема это все один раз настроить. Далее сама кросс-компиляция практически ничем не отличается от обычной, за исключение того, что используются другие пути. Вот доставить какие-нибудь библиотеки для дальнейшего использования на целевой платформе, да, может быть сложно.
Честно говоря, не могу представить проект НЕ для лулза из ЛЕГО, помоему два этих слова в одном анонсе исключают любую серьезность, ну и как же можно не обрптить внимание на кавычки в слове Суперкомпьютер?
не нужно кавычек, лего часто используется для прототипирования девайсов в лабах.
Я думаю если бы они делали суперкомпьютер без кавычек, то лего было бы совсем неуместно. Предлагаю взглянуть на реальный СК (http://habrastorage.org/storage1/478c60c2/5ec9e42f/adb8d0e4/0052ebc6.jpg), ну и сколько по времени и деньгам уйдет сборка корпуса для нашего суперкомпьютера? Лего то нынче не дешевый.
суперкомпьютеры видел, спасибо. по существу (про прототипирование) есть что возразить?
Ну хотя бы то что именно суперкомпьютер прототипировать из лего это фейл =), а то что лего удобный инструмент, для мелочей то вполне согласен. Но опять же прошу обратит внимание я не о лего в частности говорил а о том что слова Суперкомпьютер и Лего в одном анонсе исключают любую серьезность.
прототипы чего угодно из чего угодно это по большей части фейл, просто потому что это прототипы, поиск решений. про «ислючает серьезность»: вы просто играете словами или действительно считаете, что прототипирование это несерьезно? или с лего несерьезно? а с липкой лентой типа скотч?
Ну да, конечно. Если так считать, то можно еще разделить на суммарное расстояние между ядрами.
Вы не учли один интересный факт. В i7 6 ядер. А тут 64 ядра + свое отдельное железо. Правда тут будет выгодно параллелить задачу вроде подбора хэша. Хотя машинка выбрана не особо. Сейчас можно например собрать компьютер из 128 каких нибудь Snapdragon S4 с 4 ядрами на частоте 1.5 ггц. Вот это будет мощь. И по идее вполне уместится в большую сумку.
Ну это в теории. Также как значения пиковой производительности больших супер-компьютеров. Просто берут и суммируют производительность всех узлов. Но в реальности хорошо если на линпаке процентов 70-80 от пика получится выжать. На реальных задачах и того меньше. Точнее говоря на реальных задачах после определенного числа узлов или прироста нет, или наоборот падение идет.
Судя по 3-ей фотографии он еще и 64 монитора заказал)
Дак вот почему на Raspberry большая очередь была.
Игрушечный суперкомпьютер по стоимости неплохого обычного.
Хотя, может по характеристикам ВНЕЗАПНО обогнал и десктоп.
Хотя, может по характеристикам ВНЕЗАПНО обогнал и десктоп.
А это идея, нужно делать суперкомпьютер из LM4F120, пока они копейки с доставкой стоят.
Единственный минус — почти все ресурсы «супер компьютера» уйдут на взаимодействие плат друг с другом)
Единственный минус — почти все ресурсы «супер компьютера» уйдут на взаимодействие плат друг с другом)
Если следовать вашей логике и дальше, монжо назаказывать тысячь 16 микрух pic16, собрать в кучу, и… вернуться к компьютерам, размером с комнату.
А если серёзно, то у 64 RPI есть шансы уменьшить расходы на взаимодействие если использовать алгоритмы, предназначенные для операций над матрицами, векторами и прочим, что можно безболезненно распараллелить (прямо как в GPU).
И сколько там у rpi памяти?
256 мегабайт?
256*16 = 16 384
по сути — 16 гигабайт памяти
А если серёзно, то у 64 RPI есть шансы уменьшить расходы на взаимодействие если использовать алгоритмы, предназначенные для операций над матрицами, векторами и прочим, что можно безболезненно распараллелить (прямо как в GPU).
И сколько там у rpi памяти?
256 мегабайт?
256*16 = 16 384
по сути — 16 гигабайт памяти
Вот почему их поначалу не хватало. Так как один кадр сразу 64 штуки купил)
А как у них с выделением тепла? Поскольку с отводом оного, я смотрю, тут туговато будет.
Теоретически — да.
Постройка игрушечного дата-центра
Вот что такое… у когото 64 Raspberi, а ктото одну никак не дождется…
Уважаю профессора Кокса. С таким папой не соскучишься :)
Чувак какими-то связями 64 RPI сынуле поиграться раздобыл, но на это насрать вообще. Он за счёт универа ещё и Lego 64 коробки сынуле достал, в каждой коробке минимум по 4 лего-человечка( я бы в детстве убил за такую армию). Молодец чё..))…
Лучше с этим, у вашего как-то не очень.
Ну на счет использования мануала как how-to по R-Pi это громко сказано. В нем подробно расписано как собрать mpich, но вот по оптимизации системы инфы ноль. Раз уже хотим использовать R-Pi как вычислительные ноды, то надо как минимум по памяти оптимизацию сделать, т.е. вырубить все ненужное и отдать GPU минимум оперативки, заменить ssh на dropbear, проц разогнать и т.п.
Ну и плюс не повредило бы хотя бы C3 прикрутить, а то рулить зоопарком из 64 узлов это еще то удовольствие будет. Запустить например одну и ту же команду на всех узлах, или скопировать один и тот же конфиг. На самом деле у него еще куча заморочек вылезет — тут я точно могу сказать, т.к. ковыряюсь с кластерами уже лет 15, в основном как админ конечно, но все же… :)
Ну и плюс не повредило бы хотя бы C3 прикрутить, а то рулить зоопарком из 64 узлов это еще то удовольствие будет. Запустить например одну и ту же команду на всех узлах, или скопировать один и тот же конфиг. На самом деле у него еще куча заморочек вылезет — тут я точно могу сказать, т.к. ковыряюсь с кластерами уже лет 15, в основном как админ конечно, но все же… :)
А оно разве не расплавит лего, когда будет выделять тепло?
Вот имя чувака, который создал искусственный дефицит малины!
Эксперимент проплачен Лего!
и все это собранно без гвоздей Синей Изоленты? :)
И сколько такая штука электричества ест? Киловатта полтора?
Как насчет охлаждения? Загорится же эта пластиковая хреновина.
А куда идут все эти кабели?
Вариант, судя по фото — концы валяются на полу. Завтра они с сыном коммутатор из Лего доделают — туда и воткнут :)
Вариант, судя по фото — концы валяются на полу. Завтра они с сыном коммутатор из Лего доделают — туда и воткнут :)
Напомнило анекдот:
«Я изобрёл и построил электромобиль. На всё изобретение у меня ушло 10.000$. Одна тысяча — на электромобиль и девять на провода.»
«Я изобрёл и построил электромобиль. На всё изобретение у меня ушло 10.000$. Одна тысяча — на электромобиль и девять на провода.»
Ну пипец.
Следующий шаг — дата-центр на ардуинах.
Следующий шаг — дата-центр на ардуинах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Суперкомпьютер» из 64 Raspberry Pi и Lego